Определите границы проблемы
Зафиксируйте время начала с часовым поясом, затронутые функции и окружения. Проверьте проблему снаружи и изнутри системы: отказ одного рабочего места и массовая недоступность требуют разного масштаба реакции.
Отдельно записывайте наблюдение и гипотезу. «Доля 5xx выросла после релиза» — наблюдение. «Причина в новой версии» — гипотеза, которую ещё нужно проверить.
Свяжите запрос, сервис и время
Для журналов полезен согласованный набор полей: время, сервис, окружение, уровень, идентификатор запроса, маршрут, статус и длительность. В системах с трассировкой добавляйте идентификаторы trace и span.
{
"timestamp": "2026-10-15T12:00:00Z",
"service": "example-api",
"level": "error",
"request_id": "example-request-01",
"route": "/reports/:id",
"status": 504,
"duration_ms": 30001
}Это вымышленная запись для примера. Не помещайте в журналы пароли, токены, полные тела запросов и персональные данные без определённой необходимости и правил обработки.
Ведите короткую хронологию
Для каждой проверки оставляйте время, действие и результат. При смене дежурного такая запись экономит повторные проверки и помогает не возвращаться к уже опровергнутой версии.
- Как обнаружен сбой и каково подтверждённое влияние.
- Какие изменения происходили перед началом.
- Какие графики, запросы и журналы подтверждают выводы.
- Какое действие выполнено и что изменилось после него.
- Кто продолжает работу и когда будет следующая проверка.
Восстановление ещё нужно подтвердить
После исправления повторите исходный сценарий, проверьте ошибки и задержку на достаточном интервале. Убедитесь, что фоновые задачи, очереди и отложенные операции тоже возвращаются в норму.
Сохраните причины, условия возникновения и конкретные действия с ответственными. Исправление процесса важнее поиска человека, который последним изменил конфигурацию.
Для первого прохода используйте памятку диагностики.
Документация и источники
Примеры иллюстративные. Имена сервисов и баз условные; команды и параметры нужно адаптировать к своему окружению.