Как разобрать инцидент после восстановления: хронология, причины и проверяемые действия

Сервис восстановлен, алерты завершились, и нужно понять, что изменить до следующего сбоя. В чате остались десятки сообщений, часть команд повторялась, а первое объяснение уже кажется очевидным. Если сразу написать «причина — неудачный релиз», можно потерять важные условия: почему проверка его пропустила и почему возврат занял так долго.

Разбор начинается с пользовательского воздействия. Какая операция не работала, для каких клиентов и на каком подтверждённом интервале? Статус процесса и число перезапусков полезны как сведения о системе, но не заменяют ответ о последствиях для пользователя.

Соберём события с источниками

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

Время	Наблюдение	Источник
10:02	Началось применение конфигурации	Журнал pipeline
10:04	Растут ошибки чтения заказов	Метрики клиентского маршрута
10:06	Отправлено уведомление	Журнал получателя алерта
10:09	Начат возврат конфигурации	Журнал изменения
10:12	Проверка операции успешна, ошибки снизились	Тестовый запрос и метрики

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

Разделим действие и его эффект

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

Также различайте время вычисления алерта, отправки и получения человеком. Задержка может находиться в выдержке for, группировке, доставке или реакции. Если записать только «мониторинг сработал поздно», действие по улучшению останется неопределённым.

Проверим причинное объяснение

Совпадение релиза и ошибок — сильная подсказка, но объяснение требует механизма. Сравните изменённое значение пула, количество экземпляров и лимит базы. Уточните, применился ли параметр ко всем процессам и какие соединения учитывает сервер базы. Число из конфигурации одного экземпляра нельзя напрямую сравнивать с общим лимитом без числа реплик.

Триггером может быть увеличение пула. Условиями — отсутствие проверки общего числа соединений, одинаковый лимит для разных окружений и неполный тест после релиза. Возврат конфигурации уменьшил давление, но полезно воспроизвести механизм на безопасном стенде. Если воспроизведение пока невозможно, сохраните гипотезу как гипотезу с указанием недостающих данных.

Сделаем действия проверяемыми

«Улучшить тесты» не задаёт завершённого состояния. Более точное действие: добавить проверку, которая отклоняет конфигурацию, если число реплик, умноженное на максимум пула, превышает согласованный бюджет соединений с учётом резерва для других клиентов. У действия должны быть владелец, срок, приоритет и тест, который падает на конфигурации инцидента.

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

Проверим, что разбор изменил систему

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

Обсуждение должно объяснять доступную человеку информацию в тот момент. Формулировка «инженер был невнимателен» не помогает изменить путь релиза. Полезный вопрос — какое устройство системы позволило обычному действию вызвать такой масштаб воздействия и какая проверяемая граница теперь это остановит.

Ещё по теме

• SLO и бюджет ошибок: считаем допустимые сбои сервиса на конкретном примере
• Высокий load average при свободном CPU: куда смотреть в Linux

Продолжить изучение

Хотите глубже разобраться в надёжности сервисов и работе с инцидентами? Посмотрите программу «DevOps Engineer PRO: от Junior до Middle».