Проследите один медленный запрос до изменения размера

Выберите запрос с ясным ожидаемым результатом

Для иллюстративного эндпоинта отчёта зафиксируйте шаблон маршрута, приблизительный размер данных, контекст аутентификации и создаёт ли он фоновую работу. Используйте тестовый аккаунт и репрезентативные обезличенные данные. Не копируйте токены, идентификаторы клиентов или полные тела запросов в заметку об инциденте.

Отделите затраты на запуск первого запроса от повторяющегося установившегося поведения. Зафиксируйте окно в UTC и ревизию релиза. Определите, медленны ли все маршруты, затронуты ли только большие отчёты или задержка следует за одной внешней зависимостью. Эти различия делают следующее измерение полезнее, чем широкий сбор несвязанных метрик.

Постройте временную шкалу без двойного учёта

Трассировки OpenTelemetry связывают связанные спаны через передаваемый контекст между границами сервисов. Одного совпадения временных меток недостаточно. Вложенные синхронные спаны и параллельные вызовы могут пересекаться. Асинхронные дочерние спаны могут пережить родителя, поэтому сложение всех длительностей спанов может удвоить прошедшее время. Следуйте операциям, которые определяют момент завершения запроса.

Техническая справка: Трассировки OpenTelemetry · Поведение завершения спанов OpenTelemetry.

Наибольший интервал указывает, где проводить inspection, а не является первопричиной. Интервал базы данных, измеренный в API, может включать ожидание соединения до того, как запрос достигнет базы данных. Отсутствие телеметрии также не доказывает, что работа не выполнялась; проверьте выборку и покрытие инструментирования.

Сопоставьте наблюдения приложения и хоста

Соберите тайминги запросов, ошибки, использование соединений с базой данных, возраст очереди, загрузку CPU, памяти и диска за одно и то же окно. Отметьте параллельные резервные копии, миграции или релизы. Один скриншот утилизации может пропустить всплеск, повлиявший на запрос.

Используйте идентификаторы корреляции и временные метки в отредактированных логах с соответствующим сроком хранения и контролем доступа. Избегайте необработанных секретов, полезных нагрузок клиентов и неограниченных меток метрик. Инструментируйте границу, необходимую для гипотезы, и оценивайте накладные расходы. Новый агент трассировки сам по себе является изменением, которое стоит наблюдать.

Изучите запрос, не вызывая новый инцидент

Сначала определите форму запроса, характеристики размера входных данных и ожидания соединения или блокировки. PostgreSQL EXPLAIN описывает план; EXPLAIN ANALYZE фактически выполняет оператор и добавляет накладные расходы на инструментирование. Запись может изменить данные, тогда как дорогое чтение всё равно создаёт нагрузку. Используйте изолированную репрезентативную базу данных для первоначального исследования.

Стоимость плана — не прошедшие миллисекунды. Крошечная тестовая таблица может дать план, отличный от более крупного набора данных приложения. Изучите статистику, индексы и распределение и сравните ту же форму запроса после изменения. Никогда не вставляйте неизвестную запись в аналитическую команду на продакшене только ради получения тайминга.

Техническая справка: PostgreSQL EXPLAIN.

Предскажите, что должно улучшить одно изменение

Если преобладает ожидание пула, проверьте соединения воркеров или запросы, которые удерживают соединение без необходимости. Если преобладает выполнение запроса, изучите план и запрошенные строки. Если преобладает внешний API, проверьте таймауты, повторы и необходимость синхронного выполнения. Насыщение CPU во время сериализации указывает на другой эксперимент.

Напишите предсказание: снижение параллелизма экспорта должно уменьшить ожидание пула API, при этом экспорты будут занимать больше времени. Это показывает компромисс. Повторите ту же смесь запросов, сравните задержку и ошибки и убедитесь, что улучшение не просто переместило сбой в постоянно растущую очередь.

Сохраните результат и его неопределённость

Зафиксируйте исходное наблюдение, проверенное изменение, метод сравнения и оставшуюся неопределённость. Если доказательства противоречат гипотезе, отмените изолированное изменение, где это уместно, и исследуйте другую границу. Избегайте накопления постоянных настроек без объяснения.

Изменяйте размер, когда измерения выявляют ограничение ресурса, которое может устранить дополнительное выделение. Используйте бюджет рабочей нагрузки и зафиксируйте регрессию релиза в краткой сводке инцидента. Результат — обоснованный диагноз, а не обещанная задержка или бенчмарк провайдера.