Дизайн эскалационных путей

Действуй как Director of Engineering. Спроектируй эскалационные пути для команды со структурой: {{team_structure}}, покрывающие {{service_count}} сервисов. Эскалация — это механизм «вовремя позвать правильного человека». Плохая эскалация → или senior'ы выгорают (всё льётся на них), или incidents растягиваются (никто не зовёт вовремя).

Тиры эскалации

L1: Primary on-call

• Кто: primary on-call engineer (любой уровень, обученный для primary).
• Что делает: acks alert, runs runbook первые 5 команд, applies known mitigations.
• SLA: ack 5 min, decision на эскалацию в 15 min если runbook не помогает.
• Полномочия: rollback, restart, scale — может делать без апрува. Hotfix deploy — требует L2 sign-off.

L2: Secondary / Service Owner / Senior on-call

• Кто: secondary on-call OR owner сервиса (если знают код глубже) OR senior SRE на ротации.
• Что делает: co-pilot для SEV1+, deeper diagnostics, decisions outside runbook, cross-team coordination.
• SLA: ack 10 min, response active в 15 min.
• Полномочия: hotfix deploy, traffic shift между регионами, manual DB intervention (с двойным подтверждением).

L3: Engineering Manager / Tech Lead

• Кто: manager owner-команды OR tech lead сервиса.
• Что делает: scope decisions (что не чиним сейчас), resource allocation (звать ли других inженеров), comms с executives.
• SLA: ack 15 min, in war room в 30 min для SEV1.
• Полномочия: временные изменения SLO, pause deploys company-wide, всё-команды pull-in.

L4: Director / VP Engineering

• Кто: director eng OR VP.
• Что делает: cross-team coordination на больших инцидентах, executive comms (CEO, board, customers, press), legal/compliance decisions.
• SLA: in loop при SEV1 > 1 час OR при customer-facing impact > 30 min.
• Полномочия: public statement, customer compensation, postpone major launches.

L5: C-level (CEO / CTO)

• Кто: CEO, CTO.
• Что делает: executive comms, regulatory / press / board notification, strategic decisions.
• Когда: SEV1 > 2 часа, regulatory event (data breach, безопасность), media exposure.

Критерии эскалации (когда и почему)

Эскалация по времени (no improvement):

• L1 → L2: 15 min после ack, если runbook не помог OR root cause unclear OR scope растёт.
• L2 → L3: 30 min от start, если SEV1 не mitigated OR scope > one service.
• L3 → L4: 60 min от start если SEV1 OR customer impact > 30 min.
• L4 → L5: 2 hours от start SEV1 OR regulatory/media/data event любой длительности.

Эскалация по characteristics (immediately, не по таймеру):

• Data loss / data corruption → L2 + L3 immediately, L4 в 15 min.
• Security incident (suspected breach) → L3 + L4 + security team immediately.
• Customer-facing > 1 hour outage → L4 immediately для exec comms.
• Multi-service impact (3+ services affected) → L3 immediately.

Эскалация по uncertainty (не знаешь что делать):

• Если за 15 min не сформулировал гипотезу — escalate. Не геройствуй.
• Если runbook не покрывает ситуацию — escalate.
• Если боишься что-то делать (irreversible action) — escalate перед действием, не после.

Как не перегрузить senior'ов

Senior'ы — bottleneck. Если их зовут на каждый инцидент → их burnout, потеря, и команда теряет mentors.

Правила защиты senior'ов:

1. Don't escalate prematurely. L1 сначала пробует runbook + первые 5 команд. Эскалация не «как только page», а после 15 минут.

2. Bundle questions. Не пинуй senior'а 5 раз по 1 вопросу. Собрал 3 вопроса → задал одним сообщением.

3. Escalate with context. Никогда не «нужна помощь, заходи». Всегда: «{symptom} с {time}, попробовали {X, Y}, текущая гипотеза {Z}, нужно решение по {specific question}». Senior может ответить через telegram, не открывая ноутбук.

4. Async когда возможно. Если SEV2 / SEV3 — Slack thread, не «срочно в Zoom». Zoom — только для SEV1.

5. Round-robin для shadow. На SEV2-SEV3 — приглашай разных мидл-инженеров вместо одного senior'а. Они учатся → следующий инцидент тушат сами.

6. Документируй решения senior'а. Каждое «такое решали так-то» — в runbook / wiki. Через 3 месяца не нужно его дёргать снова.

7. Senior on-call ≠ always-on. Если senior on rotation — после ротации, week off от incident calls (рекаверится).

8. Escalation budget. Если один senior получает > 3 escalations/week — сигнал: либо incidents растут, либо L1 / L2 не справляются → инвестировать в обучение или нанимать.

War room conventions

War room — это synchronous space, где принимаются решения по incident'у. Без правил он превращается в chaos.

Когда собираем:

• SEV1 всегда (немедленно при declare).
• SEV2 если scope unclear OR > 30 min без mitigation OR cross-team coordination нужна.
• SEV3 — не нужен, async в Slack thread.

Кто в war room:

• IC (всегда).
• Comms (всегда для SEV1 customer-facing).
• Scribe (всегда — иначе timeline пропадёт).
• SMEs: service owner + adjacent system owners если корреляция.
• L3 manager: для SEV1, для SEV2 если эскалирован.
• L4 director: для SEV1 > 1 час OR customer-facing > 30 min.
• Никаких observers без роли. «Поглазеть» создаёт шум, отнимает focus у активных участников. Если хочешь следить → читай incident channel, не заходи в Zoom.

Кто ведёт:

• IC ведёт всегда. IC задаёт questions, IC формулирует decisions, IC контролирует scope обсуждения.
• IC не дебажит руками — слишком теряется координация. IC говорит «@alice, run X», alice runs.
• IC может смениться (например, через 2 часа SEV1, fresh IC берёт ротацию). Handoff: 5 минут sync, передача timeline + active hypothesis.

Правила в war room:

• One conversation at a time. Нельзя 3 человека одновременно говорят. IC tappens muta.
• Decisions in chat, not just voice. Каждое решение в incident channel («Decision: rollback dep-12345»). Иначе исчезает.
• No blame language. «Кто это сделал» → «когда это произошло». Время для blame нет — да и blame не нужен, нужен fix.
• Updates каждые 15 min. «Status: mitigating, hypothesis Z, ETA next update HH:MM».
• Closing the room: не закрываем сразу после mitigate. Минимум 30 мин cooldown, потом final summary в incident doc, потом close.

Anti-patterns

• ❌ «Эскалирую сразу к VP» — VP не знает руками сервис, потерянное время. Иди по тирам.
• ❌ L1 не эскалирует «потому что неудобно беспокоить» — incident растягивается, impact растёт. Эскалация — это сервис, не оскорбление.
• ❌ War room на SEV3 — выжигает participants, создаёт «incident inflation».
• ❌ Senior'а зовут «на всякий случай» каждый инцидент — burnout за 6 месяцев, увольнение.
• ❌ Эскалация без контекста («help, что-то не так») — senior тратит 15 минут разбираясь, что вообще происходит.
• ❌ В war room нет Scribe → timeline пропадает → post-mortem fiction.
• ❌ Director зовёт executives в war room «чтобы наблюдали» — создаёт давление на IC, замедляет решения.
• ❌ Нет defined escalation timer — каждый эскалирует «когда чувствует». Несистемно, кто-то будит VP в 3 ночи зря, кто-то не будит когда надо.

Output format

## Escalation tiers
| Tier | Role | SLA to ack | SLA to active | Authority |
| L1 | Primary on-call | 5 min | 5 min | rollback, restart, scale |
| L2 | Secondary / Senior | 10 min | 15 min | hotfix deploy, traffic shift |
| L3 | Manager / Tech Lead | 15 min | 30 min | scope decisions, resource pull-in |
| L4 | Director / VP | 30 min | 60 min | public statements, postpone launches |
| L5 | C-level | 1 hr | 2 hr | regulatory / press / board |

## Escalation triggers (by time)
- L1→L2: 15 min from ack if runbook fails
- L2→L3: 30 min from start if SEV1 not mitigated
- L3→L4: 60 min from start if SEV1
- L4→L5: 2 hr SEV1 OR regulatory event

## Escalation triggers (immediate, ignore timer)
- Data loss → L2+L3 immediately, L4 in 15 min
- Security incident → L3+L4+security immediately
- Multi-service impact (3+) → L3 immediately

## War room
- SEV1: always (immediate)
- SEV2: conditional (scope/cross-team)
- SEV3: never (async in channel)

## Roles in war room
- IC (always leads)
- Scribe (always — timeline)
- Comms (always for SEV1)
- SMEs as needed
- L3+ as escalated
- No observers

## Senior protection
- No premature escalation (L1 tries runbook first)
- Bundle questions, escalate with context
- Async when possible (SEV2/3)
- Round-robin shadowing of seniors
- Track escalations/senior/week (red if > 3)

Принцип: эскалация — это система раннего привлечения помощи, а не «передача проблемы наверх». Хорошая эскалация = правильный человек в правильное время. Плохая — либо герой-одиночка горит, либо толпа в war room без фокуса.