Ответ
Мой алгоритм действий при инциденте на production строится по принципу «сначала стабилизировать, потом исправлять».
-
Быстрая диагностика и стабилизация:
- Первым делом смотрю на дашборды мониторинга (Grafana, Datadog) и логи (ELK, Loki) для определения масштаба и симптомов: возросла ли ошибка 5xx, упала ли скорость ответа, появились ли алерты.
- Если сервис полностью недоступен, проверяю здоровье инстансов и балансировщиков. В критичных случаях временно переключаю трафик на предыдущую стабильную версию (откат деплоя) или включаю деградированный режим работы (feature flags).
-
Локализация и исправление:
- Анализирую стек-трейсы в Sentry/Bugsnag и метрики для поиска корневой причины. Часто это помогает быстро найти проблемный коммит или конфигурационное изменение.
- Если проблема в коде, готовлю минимальный hotfix. Например, если обнаружил
NullPointerException:// Было: return user.getProfile().getName();
// Срочный фикс: return Optional.ofNullable(user) .map(User::getProfile) .map(Profile::getName) .orElse("Unknown");
* Фикс прогоняю через быстрые smoke-тесты на staging и деплою через канареечный релиз или сразу на все прод-ноды, если проблема критическая. -
Пост-обработка:
- После восстановления сервиса обязательно пишу постмортем. В нем фиксирую временную шкалу инцидента, корневую причину, предпринятые действия и, самое главное, action items по предотвращению повторения: добавить недостающий тест, улучшить мониторинг конкретного показателя, исправить архитектурную слабость.
- Информирую команду и заинтересованные стороны о результатах расследования.
Ответ 18+ 🔞
Слушай, вот у меня в голове чёткий план, как действовать, когда на проде всё ебётся. Принцип железный: сначала тушим пожар, а потом уже ищем, кто спичку бросил.
-
Быстрая диагностика и стабилизация:
- Первым делом — паника? Не, не слышал. Лечу смотреть на дашборды (Grafana, Datadog) и логи (ELK, Loki). Надо понять масштаб: ошибки 5xx зашкаливают, latency улетела в космос, алерты орут как резаные? Волнение ебать, но надо.
- Если сервис просто лёг и не дышит, проверяю инстансы и балансировщики. В совсем пиздецовом случае — быстрый откат на прошлую версию или включаю заглушки через feature flags. Главное — остановить кровотечение, а потом уже думать, почему нож оказался в спине.
-
Локализация и исправление:
- Тут включается режим детектива. Роюсь в стек-трейсах из Sentry и метриках, ищу корень зла. Часто виноват какой-нибудь свежий коммит, который все проглядели. Подозрение ебать чувствую к последним изменениям.
- Если баг в коде — готовлю срочный патч. Вот, например, классика —
NullPointerExceptionвылез, потому что кто-то был уверен, что объект всегда не null. Ёпта.// Было: наивно и опасно return user.getProfile().getName();
// Срочный фикс: пришлось обернуть в Optional, чтоб не падало return Optional.ofNullable(user) .map(User::getProfile) .map(Profile::getName) .orElse("Unknown");
* Этот костыль быстренько прогоняю через smoke-тесты на staging и вкатываю на прод. Если всё горит — то через канареечный релиз, если уже всё сгорело — то сразу на все ноды. **Терпения ноль ебать**, надо чинить. -
Пост-обработка:
- После того как всё устаканилось, самое важное — не разбежаться. Обязательно пишу постмортем. Не для галочки, а чтобы в будущем не наступать на те же грабли. Фиксирую таймлайн: когда началось, когда обнаружили, когда пофиксили. Ищу коренную причину — не «упал сервис», а «не было обработки случая, когда БД временно недоступна».
- И самое главное — action items. Не просто «будьте аккуратнее», а конкретика: «добавить интеграционный тест для сценария X», «настроить алерт на метрику Y», «переписать модуль Z, потому что он — сплошная манда с ушами». Потом с этим всем иду к команде и стейкхолдерам — отчитываюсь, что случилось и как будем жить дальше. Чтобы доверия ебать ноль не стало.
