Диагностика и инциденты
Сквозной поиск запроса, triage, severity и управление восстановлением.
Диагностика и инциденты
Диагностика начинается с фактов: окружение, API, время, request ID, trace и наблюдаемый результат. Не перезапускайте компоненты до определения blast radius и сохранения evidence.
Сквозной поиск запроса
- Найдите входной вызов по
X-External-Request-ID. - Получите trace ID и проверьте Gateway span.
- Подтвердите routing rule и публикацию в Kafka.
- Проверьте consumer lag и получение сообщения обработчиком.
- Для orchestration найдите execution и failing task.
- Проверьте adapter call и ответ target system.
- Для async flow подтвердите callback delivery/retry/DLT.
Triage checklist
- когда началось и продолжается ли сейчас;
- какие environments, Consumers, API и operations затронуты;
- полный отказ или деградация;
- есть ли риск duplicate, data loss или security impact;
- были ли deployment/config/certificate/network changes;
- растут ли queue, lag, retry или DLQ;
- существует ли безопасный workaround.
Severity model
| Уровень | Пример |
|---|---|
| Critical | Массовая недоступность, security incident, риск потери/дублирования критичных операций |
| High | Значимая функция недоступна для нескольких Consumers, workaround отсутствует |
| Medium | Частичная деградация или ограниченный Consumer impact |
| Low | Некритичная ошибка без существенного влияния |
Точные определения и response targets должны быть утверждены incident policy/SLA matrix.
Stabilization options
- временно ограничить или остановить входной трафик;
- отключить проблемный route/API revision;
- остановить небезопасный retry/replay;
- переключить на подтверждённый fallback;
- откатить deployment/config;
- изолировать Consumer или target system;
- увеличить ресурсы только при доказанном saturation.
Не выполняйте replay вслепую
Перед повтором сообщений проверьте фактическое состояние target system и idempotency. Технический timeout не доказывает, что бизнес-операция не выполнилась.
Incident record
Фиксируйте timeline, impact, decisions, команды, версии, evidence links и владельца каждого действия. После восстановления сохраните root cause и corrective actions, а не только сообщение «перезапустили pod».
Закрытие
- сервис стабилен;
- backlog/lag обработан безопасно;
- Consumers уведомлены;
- временные изменения оформлены или отменены;
- monitoring подтверждает восстановление;
- заведены follow-up actions;
- runbook обновлён.