Твой первый инцидент: как вести себя в war room, чтобы помочь (даже если ты джун)

Инцидент обычно начинается одинаково.

Ты открываешь чат, а там уже:

• “P99 улетел”,
• “у базы 95% CPU”,
• “кто выкатывал релиз?”,
• и где-то в стороне одинокое “я щас посмотрю”.

И ты такой(ая): “Я же джун. Я тут лишний?”

Нет. На инциденте лишними бывают только две вещи: хаос и молчание.

Если ты новичок, твоя суперсила не в том, чтобы мгновенно найти root cause. Твоя суперсила — ускорять расследование, не мешая ему.

Первые 3 минуты: сделай то, что большинство не делает

1) Отдели факты от предположений

Выпиши 4 строки:

• Симптом: что именно плохо (латентность, ошибки, конверсия, таймауты).
• Область: какой сервис/эндпоинт/поток.
• Время: когда началось.
• Масштаб: насколько плохо (порог, текущие значения, SEV).

Если хочется написать “наверное база умерла” — остановись. Замени на факт: “CPU DB 95%, P99 > 2s, старт 12 минут назад”.

2) Возьми роль (даже если тебе её не дали)

В инциденте всегда нужны руки на:

• таймлайн;
• сбор ссылок (дашборды, логи, релизы);
• коммуникации (короткие апдейты).

Самый полезный вопрос в этот момент:

“Я могу вести таймлайн и собирать факты/ссылки? Кому кидать апдейты?”

Это звучит просто, но экономит 20–40 минут, пока команда “разогревается”.

War room-этикет: как не превратиться в шум

Есть три правила, которые делают тебя любимым участником инцидента:

1. Один поток мыслей — один владелец. Если вы уже проверяете базу, не начинай параллельно спорить, “а может это сеть”. Принеси данные, не дискуссию.
2. Гипотезы маркируй словом “гипотеза”. И сразу приписывай, как проверяешь.
3. Короткие сообщения выигрывают. Инцидент-командир читает чат как приборную панель, а не как эссе.

Формат апдейта, который можно копировать

Если ты не уверен(а), что писать — пиши так:

• Status: что сейчас происходит (1 строка)
• Impact: кто страдает и как (если известно)
• Findings: 2–3 факта (метрика/лог/изменение)
• Next: что делаем дальше (1–2 шага)
• Owner: кто делает

Пример (нормальный):

“Status: P99 по /api/products держится ~5–7s. Findings: ошибок 5xx нет, но выросло время ответа от DB на SELECT X (с 40ms до 900ms). Next: проверяем последний деплой и запрос, который стал тяжелее. Owner: я соберу diff релиза и примеры логов.”

Пример (плохой):

“Кажется база умирает, я не знаю.”

Что джун реально может сделать полезного (список без геройства)

1) Свести “до/после”

Собери одно сообщение:

• до релиза: метрики были X,
• после релиза: стали Y,
• изменение началось в момент Z.

Это не “аналитика”. Это основа расследования.

2) Найти, что менялось

Даже если у тебя нет доступа к деплою — почти всегда есть:

• номер релиза;
• список PR/коммитов;
• фича-флаги.

Собери это в один список, чтобы остальные не искали.

3) Принести конкретные логи (не “там ошибки”)

Если нашел(ла) ошибку — принеси:

• 2–3 примера (время, request_id, сообщение),
• частоту (раз в секунду или раз в минуту),
• привязку к компоненту.

4) Вести таймлайн

Таймлайн — это “как мы думали” + “что мы сделали”. Он потом превращается в postmortem.

Шаблон таймлайна:

14:02 alert fired (P99 > 2s)
14:04 war room started
14:06 checked dashboards: DB CPU 95%
14:09 hypothesis: heavy query after release
14:12 action: disabled feature flag X
14:15 metric stabilized

Пиши сухо. Без эмоций. Это документ.

Самая частая ошибка новичка: “я нашел виноватого”

На инциденте не ищут виноватых. Ищут:

• как остановить кровотечение;
• как стабилизировать систему;
• как сделать так, чтобы это не повторилось.

Если хочется “объяснить”, делай это как инженер, а не как прокурор:

“Гипотеза: после релиза выросло время запроса X. Проверяю по графикам/логам.”

После: не исчезай, когда стало тихо

Когда “потушили”, начинается важная часть — разбор.

Твой вклад там:

• аккуратно оформить таймлайн;
• выписать, что ускорило (и что тормозило);
• предложить 1–2 action items, которые реально можно сделать.

Хороший action item:

• “Добавить алерт на рост latency по endpoint X + link на дашборд”.

Плохой action item:

• “Сделать систему надежнее”.