Сообщить об ошибкеКороткий ответ
Восстановление начинают с метрик (когда начался рост latency/error rate и что предшествовало), сужают через логи ошибок за этот период и трассировки конкретных запросов, затем формулируют точную последовательность событий, корневую причину и конкретные action items с владельцами и сроками.
Как это работает подробнее
метрики дают общую картину «что» и «когда»; логи дают «что конкретно пошло не так» на уровне исключений; трассировки показывают «где в цепочке вызовов» возникла задержка — вместе они восстанавливают причинно-следственную цепочку, а не только симптом.
Пример кода
Пример конфигурации
14:02 — деплой v2.7.0 на 50% подов (canary)
14:05 — p99 latency /checkout растёт с 300мс до 4000мс
14:06 — error rate 504 коррелирует с db_connection_pool_in_use = 100%
14:08 — трассировки показывают задержку на span "db.query: SELECT ... FOR UPDATE"
14:20 — автоскейлер увеличивает число читающих реплик БД, пул разгружается
14:22 — error rate возвращается к норме
Причина: SELECT ... FOR UPDATE без индекса увеличил время удержания соединения.
Action items: (1) индекс — Иванов, до <date>; (2) алерт на pool > 80% — Петров, до <date>.Что использовать на практике
- Рекомендация. полезно сопоставить timeline с историей деплоев; 504 часто коррелируют с насыщенностью пула соединений к БД/внешнему сервису; самовосстановление за 20 минут может указывать на временную перегрузку, рассосавшуюся после снижения трафика.
- Компромисс. глубокое расследование с привлечением нескольких команд даёт точную корневую причину, но занимает больше времени; быстрый поверхностный разбор даёт результат быстро, но рискует повторением по той же скрытой причине. Критерий выбора глубины — тяжесть и частота повторения инцидентов и доступность данных.
Подводные камни
- Риск. писать постмортем с причиной, указывающей на человека, а не на процесс; ограничиваться action item без конкретики; не фиксировать точный интервал инцидента и показатели.