Дебаг прод-инцидента

Прод упал. Sentry разрывается. Slack #incidents звенит. У вас 30 минут, чтобы разобраться, иначе клиенты пойдут к конкурентам. Этот рецепт - как использовать Claude для быстрого root-cause анализа без паники.

Когда применять

• Сервис вернул 500 на критическом эндпоинте
• В Sentry полезли новые ошибки после деплоя
• Latency p99 прыгнул в 10x
• Очередь задач остановилась
• Пользователи жалуются на одинаковый сценарий

Шаги

Шаг 1. Собрать факты, не гипотезы

Первое - НЕ открывайте редактор. Сначала факты:

Промпт:
"Сейчас прод-инцидент. Не предлагай фиксы. Помоги собрать факты:
1. Какие endpoints упали? Дай команду посмотреть в access.log.
2. Когда начался инцидент? Точное время первой ошибки.
3. Что деплоилось за последние 24 часа? git log + CI history.
4. Есть ли паттерн: один пользователь, регион, размер запроса?
5. Что говорят метрики - DB, CPU, память?
Составь чек-лист команд для сбора этой информации."

Claude даст вам список команд. Запускайте их по порядку.

Шаг 2. Гипотезы по приоритету

Когда факты собраны:

Промпт:
"Вот факты:
- 500 на POST /api/payments начались 14:32
- В 14:30 задеплоился PR #1247 (изменения в payment service)
- 100% запросов с amount > 10000 падают
- DB и CPU в норме
- В Sentry traceback: ConnectionError в anthropic SDK

Составь топ-3 гипотезы по убыванию вероятности, для каждой - как
быстро проверить."

Получаете приоритизированный список. Не лезьте в код, пока не выбрана гипотеза.

Шаг 3. Минимальный воспроизводимый пример

Промпт:
"Воспроизведи баг локально. Сделай curl-запрос или pytest-тест
который точно повторяет проблему. Если не воспроизводится локально -
расскажи какие данные/окружение нужны."

Без воспроизводимого примера фикс - это лотерея. С ним - вы точно знаете, фиксит ли изменение.

Шаг 4. Поиск root cause

Промпт:
"Воспроизведено. Теперь найди root cause. Изучи:
- diff PR #1247 - что изменилось
- логи anthropic SDK с DEBUG-уровнем
- timeout настройки в коде
Не предлагай фикс, пока не покажешь МЕСТО где появилась проблема."

Главное правило: фикс симптома не считается фиксом. Если вы добавили try-except и подавили ошибку - проблема не решена.

Шаг 5. Hotfix vs full fix

• Hotfix - минимальное изменение, восстанавливающее работоспособность. Например, увеличить timeout с 5s до 30s. Не решает root cause, но снимает инцидент.
• Full fix - решение root cause. Например, перенести anthropic-вызов в очередь, чтобы не блокировать API.

В острый момент - hotfix. После - PR с full fix и postmortem.

Шаг 6. Постмортем

После того как прод восстановлен:

Промпт:
"Напиши postmortem по этому инциденту. Структура:
- Что произошло (timeline по минутам)
- Impact (сколько пользователей затронуто, сколько денег потеряно)
- Root cause (одной фразой)
- Hotfix vs full fix (что сделали сразу, что планируется)
- Что улучшить, чтобы не повторилось:
  - Мониторинг (какой алёрт пропустили)
  - Тесты (какой тест поймал бы это)
  - Процесс (что в code review/деплое подвело)"

Антипаттерны

| Что не делать | Почему | |---|---| | Сразу фиксить без гипотез | Получите 5 push'ей подряд, и хуже не станет только потому, что вам повезло. | | git revert HEAD --no-edit без анализа | Может откатить не только проблему, но и важные правки в том же коммите. | | Игнорировать алёрт «всё уже нормально» | Если проблема воспроизводится - она не сама пройдёт. | | Постмортем «виноват Вася» | Постмортемы blameless. Проблема не в человеке - в процессе. | | Не писать тест на регрессию | Через 3 месяца это повторится. |

Готовый чек-лист «прод упал»

[ ] Сообщить в #incidents (acknowledge - я смотрю)
[ ] Собрать факты: ошибки, время, deploys, паттерн, метрики
[ ] Составить топ-3 гипотезы
[ ] Воспроизвести локально (или объяснить почему нельзя)
[ ] Найти root cause
[ ] Hotfix → деплой → smoke
[ ] Сообщить в #incidents (resolved)
[ ] Postmortem в течение 48 часов
[ ] Регрессионный тест в течение недели

Полезные ссылки

• Sentry MCP - Claude читает Sentry напрямую
• Postgres MCP - быстрые SQL-запросы к проду
• Awesome SRE - сборник практик надёжности