Учебные дни: тестирование реагирования на инциденты

Updated Jul 2026

Что такое учебный день?

Учебный день (Game Day) — это запланированное учение по хаос-инженерии, во время которого команда отрабатывает процедуры реагирования на инциденты в контролируемых условиях. В отличие от автоматизированных хаос-экспериментов, валидирующих устойчивость системы, учебные дни валидируют человеческие процессы: коммуникацию, принятие решений, владение инструментами и точность рабочих инструкций (runbook).

Думайте об этом как о пожарной тренировке для вашей инженерной организации. Здание (система) может пережить пожар автоматически, но люди должны знать пути эвакуации (runbook), где находятся огнетушители (инструменты) и кто руководит реагированием (командир инцидента).

Почему QA-архитекторы должны руководить учебными днями

QA-архитекторы уникально позиционированы для проектирования и проведения учебных дней, потому что они:

1. Знают слабые места системы по результатам тестирования производительности и хаос-экспериментов
2. Понимают влияние на пользователей различных сценариев отказа
3. Могут проектировать реалистичные сценарии на основе истории инцидентов в продакшене
4. Находятся между разработкой и эксплуатацией, преодолевая коммуникационные разрывы
5. Имеют опыт проектирования тест-кейсов, а сценарии учебных дней — это именно они

Чек-лист учебного дня

Подготовка (за 1-2 недели)

1. Проектирование сценария -- Определите сценарий отказа и критерии успеха

   • Какой сбой вы будете моделировать?
   • Каково ожидаемое поведение системы?
   • Какова ожидаемая реакция людей?
   • Как вы будете измерять успех?

2. Брифинг участников -- Уведомите всех участников

   • Дежурные инженеры затронутых сервисов
   • Командир инцидента (ротируемая роль)
   • Ответственный за коммуникации
   • Опционально: наблюдатели (руководство, новые члены команды)

3. Меры безопасности -- Определите границы

   • Какой радиус поражения допустим?
   • Какова процедура аварийного отключения?
   • В какие часы будет проводиться учение?
   • Допустимо ли воздействие на клиентов? Если нет, используйте стейджинг.

4. Готовность инструментов -- Проверьте работоспособность всех инструментов реагирования

   • PagerDuty / Opsgenie настроены и маршрутизируют корректно
   • Каналы инцидентов в Slack/Teams готовы
   • Дашборды мониторинга доступны
   • Runbook актуальны и доступны

Во время учения

5. Внедрение сбоя -- Выполните хаос-эксперимент

   • Используйте Litmus, Gremlin или ручное вмешательство
   • Зафиксируйте точное время внедрения

6. Наблюдение за реакцией -- Отслеживайте метрики, не вмешиваясь

   • Время обнаружения: Через какое время кто-то заметил?
   • Время подтверждения: Через какое время дежурный отреагировал?
   • Время коммуникации: Через какое время команда собралась?
   • Время диагностики: Через какое время определена корневая причина?
   • Время восстановления: Через какое время сервис восстановлен?
   • Влияние на клиентов: Сколько пользователей затронуто, на какой срок?

7. Документируйте всё -- Выделенный наблюдатель ведёт записи

   • Что произошло и когда (хронология)
   • Что прошло хорошо
   • Что прошло плохо
   • Пробелы в инструментах, мониторинге или runbook

После учения (в течение 48 часов)

8. Разбор учения -- Безобвинительная ретроспектива
   • Пересмотрите хронологию со всеми участниками
   • Определите пункты действий (обновление runbook, пробелы в мониторинге, улучшения инструментов)
   • Назначьте ответственных и сроки для каждого пункта
   • Поделитесь результатами с более широкой организацией

Проектирование сценариев учебного дня

Шаблон сценария

## Game Day Scenario: [Name]

### Failure Type
[Pod kill / Network partition / Dependency failure / etc.]

### Target Service
[Service name and environment]

### Hypothesis
"When [failure], the system should [expected behavior], and the team should
[expected response] within [time limit]."

### Injection Method
[Litmus experiment / Gremlin attack / Manual kubectl / etc.]

### Success Criteria
- [ ] Detection within 5 minutes
- [ ] Incident channel created within 10 minutes
- [ ] Root cause identified within 20 minutes
- [ ] Service restored within 30 minutes
- [ ] Customer impact limited to < 1% of users

### Kill Switch
[Command to abort the experiment immediately]

### Blast Radius
[Which services, users, and regions are affected]

Идеи сценариев по уровню зрелости

Начальный уровень (первые 3 учебных дня):

Средний уровень:

Продвинутый уровень:

Измерение эффективности учебных дней

Отслеживайте эти метрики по учебным дням для измерения улучшения организации:

Проведение учебного дня: пошагово

T-60 минут: предварительный брифинг

Соберите участников на общий звонок. Сообщите:

• «Мы проводим учебный день, который начнётся через 60 минут.»
• «Это учебное упражнение, а не тест. Неправильных действий не существует.»
• «Мы внедрим сбой в среде [стейджинг/продакшен].»
• «Пожалуйста, реагируйте так, как вы бы реагировали на реальный инцидент.»
• Для продакшен-учений: «Воздействие на клиентов ожидается минимальным. Если воздействие превысит [порог], мы прекратим учение.»

T-0: Внедрение сбоя

Выполните хаос-эксперимент. Запустите таймер.

T+5 — T+30: Наблюдение без вмешательства

Ведущий наблюдает и документирует, но не направляет реагирование. Цель — увидеть, как команда реагирует естественно. Вмешивайтесь только если:

• Радиус поражения превышает согласованные границы
• Команда собирается предпринять деструктивное действие
• Учение длится значительно дольше запланированного

T+30 — T+60: Завершение

• Прекратите хаос-эксперимент, если он не разрешился естественным образом
• Убедитесь, что система вернулась в устойчивое состояние
• Соберите первичные впечатления участников

T+24ч — T+48ч: Разбор учения

Проведите безобвинительную ретроспективу:

1. Реконструкция хронологии -- Что произошло и когда?
2. Что прошло хорошо? -- Отметьте эффективные действия
3. Что нас удивило? -- Неожиданное поведение системы или пробелы в процессах
4. Пункты действий -- Конкретные улучшения с ответственными и сроками

Антипаттерны учебных дней

Построение программы учебных дней

Квартал 1: Фундамент

• Проводите 1 учебный день в месяц в стейджинге
• Фокус на отказах отдельных сервисов
• Установите процесс разбора учений
• Создайте начальные runbook на основе находок

Квартал 2: Расширение

• Проводите 2 учебных дня в месяц
• Включите мультисервисные сценарии
• Проведите первый учебный день в продакшене (в часы низкого трафика)
• Начните отслеживать тренды MTTD/MTTA/MTTR

Квартал 3: Зрелость

• Еженедельные учебные дни (ротация сервисов)
• Учебные дни в продакшене в обычные часы
• Включите сценарии инцидентов безопасности
• Кросс-командные учения (бэкенд + фронтенд + мобильные)

Квартал 4: Непрерывность

• Автоматизированные учебные дни (плановый хаос с оценкой реакции людей)
• Учебные дни интегрированы в онбординг дежурных
• Ежеквартальные учения «всей организацией» с участием всей компании
• Публикация отчёта об учебном дне для всей организации

Тезис для собеседования: «Я рассматриваю производительность и устойчивость как две стороны одной медали. Тестирование производительности показывает, как быстро система работает под нагрузкой; хаос-инженерия показывает, что происходит, когда нагрузка приходит во время сбоя. Я интегрирую оба подхода в CI — k6 валидирует наши SLO в стейджинге, а хаос-эксперименты Litmus проверяют, что мы остаёмся в рамках SLO даже при уничтожении подов. Для функций на базе LLM я добавляю специализированные метрики, такие как time-to-first-token и tokens-per-second, потому что традиционные перцентили задержки не отражают пользовательский опыт потокового ответа ИИ. Цель — не доказать, что система никогда не ломается, а доказать, что при поломке она ломается корректно в рамках нашего бюджета ошибок.»