Аналоговый вагон-ресторан инцидентов: бумажное меню, чтобы решить, ЧТО НЕ ЧИНИТЬ во время аварии

Когда прод лежит, ваш мозг работает хуже всего.

Когнитивная нагрузка зашкаливает, стресс растет, руководители бесконечно пингуют за обновлениями, десяток людей предлагает «быстрые» фиксы. Именно в этот момент команды тянутся к самым рискованным действиям: перезапуску ключевых баз данных, дерганию непонятных feature-флагов, частичному или массовому деплою, или «просто» откату всего подряд.

Так небольшие инциденты превращаются в полномасштабные аварии.

В этом посте — намеренно низкотехнологичный противоядие: Аналоговый вагон-ресторан инцидентов — простое, тактильное бумажное меню, которое вы используете в первые 15 минут инцидента, чтобы вместе решить, к чему вы не будете прикасаться.

Если соединить это меню с легким плейбуком инцидентов на базе практик SRE, вы получите более спокойные решения, меньше панических изменений и более устойчивый процесс реагирования на аварии.

Почему именно «вагон-ресторан» инцидентов?

Представьте старый железнодорожный вагон-ресторан.

Вы садитесь, вам приносят меню. В меню нет всего на свете — там ограниченный, заранее продуманный набор опций. Вы не придумываете блюдо с нуля под давлением — вы выбираете в безопасных, известных рамках.

Теперь перенесем эту метафору на обработку инцидентов:

поезд — это ваш продакшн, который уже едет;
вагон-ресторан — это ваше пространство управления инцидентом: Zoom, Slack, «вар-рум»;
меню — это физический лист бумаги со списком типичных, очень заманчивых, но рискованных действий.

В начале инцидента вместо того, чтобы бросаться в случайные фиксы, команда открывает меню и явно решает, чего она точно не будет трогать в первые 15 минут.

Этот маленький ритуал делает три сильные вещи:

Чуть-чуть притормаживает, чтобы не сорваться в панику.
Сужает пространство вариантов до более безопасных, заранее обдуманных шагов.
Выравнивает ожидания: все понимают, чего точно не будет (пока).

Бумажное меню: выбираем, к чему НЕ прикасаться

Меню — буквально бумага.

Почему аналоговое решение в цифровом мире?

Оно тактильное и его сложно проигнорировать.
Оно работает, даже если тулзы или дашборды лагают или лежат.
Оно меняет психологический контекст: вы не «хакаете прод», вы «делаете заказ».

Как выглядит меню

Один-два листа, распечатанных и лежащих у каждого, кто несет онколл, с такими секциями:

Секция A — Высокорисковые действия (по умолчанию: НЕ ТРОГАТЬ в первые 15 минут)

Перезапуск основного кластера базы данных
Фейловер в резервный регион
Полный откат основного монолита
Глобальные переключения feature-флагов, затрагивающие >50% трафика
Изменение DNS-записей или маршрутизации трафика на периметре
Полная очистка кешей / массовая инвалидация

Секция B — Среднерисковые действия (требуют явного одобрения)

Редеплой любого core-сервиса
Миграции схемы / откат схемы
Массовые data-fix-скрипты и bulk-операции с данными

Секция C — Безопасные дефолты (поощряемые ранние действия)

Включить дополнительный логгинг / трейсинг
Добавить временные алерты / дашборды
Снизить нагрузку (rate limiting, остановка очередей, частичная деградация)
Переключить заранее проверенные флаги «safe mode»

В начале инцидента Incident Commander (IC, ведущий инцидента) зачитывает вслух секцию A и говорит что-то вроде:

«В ближайшие 15 минут мы НЕ делаем ни одно из этих высокорисковых действий, если только не решим единогласно “бить стекло”. Согласны?»

Команда проставляет галочки напротив тех пунктов, которые явно запрещены прямо сейчас.

Этот маленький шаг переводит разговор с «Что бы нам попробовать?» на «Чего мы сознательно не будем пробовать пока?»

Меню + плейбук инцидента

Меню само по себе — не фокус. Лучше всего оно работает в паре с четким, но легким плейбуком инцидентов, который задает рамки первых 15 минут и дальнейших шагов.

В плейбуке минимум должны быть:

1. Чек-лист первых 15 минут

Цель первых 15 минут — стабилизация и наблюдаемость, а не героические подвиги.

Пример чек-листа:

Назначить роли (IC, коммуникации, писарь/scribe, эксперты по конкретным системам).
Сформулировать влияние простым языком: «Пользователи не могут X; уровень ошибок Y; началось около Z-времени».
Открыть бумажное меню и решить, к чему вы пока НЕ прикасаетесь.
Собирать факты, а не теории: дашборды, логи, последние изменения, алерты.
Усилить наблюдаемость: добавить логи, уточнить пробы, включить трейсинг.
Подумать о локализации проблем: rate limiting, частичная отключаемость фич, сброс не критичного трафика.
Отправить первый статус-апдейт по шаблону коммуникаций.

2. Матрица решений по восстановлению

Чтобы избежать спонтанных, рискованных фиксов, заранее определите критерии для типовых стратегий восстановления.

Например:

Когда перезапускать сервис
- Только если: сервис не отвечает и статлесс и нет незавершенных записей.
Когда делать фейловер региона
- Только если: влияние действительно региональное, автоматические проверки показывают, что целевой регион здоров, есть готовые план коммуникаций и план отката.
Когда откатываться
- Только если: инцидент сильно коррелирует с конкретным деплоем, а предыдущая версия считается заведомо рабочей.

Бумажное меню может прямо ссылаться на эту матрицу: «Перед выполнением чего-либо из секций A или B обратитесь к Матрице решений по восстановлению».

3. Шаблоны коммуникаций

Инцидент ощущается хуже, когда никто не понимает, что происходит. Нужны шаблоны сообщений:

Внутреннее обновление
Краткое резюме для руководства
Сообщение на публичную статус-страницу

Каждый шаблон подчеркивает честность по поводу неопределенности: «Мы расследуем, стабилизировали X, избегаем рискованных изменений Y, следующее обновление через Z минут».

4. Безопасные шаги восстановления

Опишите пошаговые безопасные маршруты восстановления:

Известные последовательности отката
Процедуры фейловера базы данных с ограничителями
Переключение трафика с четкими критериями отмены

Свяжите эти шаги с меню: к ним вы переходите после первых 15 минут, когда собрали достаточное количество информации.

SRE-принципы за метафорой вагона-ресторана

Вся эта история — дружелюбная метафора для довольно серьезных принципов SRE.

Четкие роли

Во время инцидента у кого-то должна быть роль Incident Commander. Остальные роли, например:

Operations Lead / Tech Lead
Communications Lead
Scribe (писарь)

IC держит в руках меню и плейбук и не дает команде вывалиться за рамки заранее согласованного поведения.

Предопределенные ранбуки

Ваш плейбук плюс сервисные ранбуки — это описания блюд в меню. Они превращают «мы могли бы попробовать X» в «вот как именно мы безопасно делаем X». Импровизированные, неописанные действия — там и рождаются усугубляющие инцидент ошибки.

Критерии вместо интуиции

Под давлением люди полагаются либо на интуицию, либо на самого громкого человека в комнате. Меню и матрица решений фиксируют критерии, а не чье-то мнение. Так вы избегаете ночного импульса «давайте просто все перезагрузим».

Сначала стабилизировать, потом чинить

Ключевой сдвиг в мышлении: стабилизация важнее фикса.

В вагоне-ресторане вы не ремонтируете локомотив прямо из-за столика — вы заказываете то, что позволит доехать до следующей станции.

В инцидентах стабилизация — это:

Сужение зоны поражения (rate limiting, отключение фич, управляемая деградация).
Обеспечение видимости происходящего (метрики, логи, трейсинг).
При необходимости — приоритет целостности данных над доступностью.

Только когда система перестает активно ухудшаться, стоит:

Пробовать инвазивные шаги восстановления.
Менять схемы, конфиги или долго живущую инфраструктуру.

Бумажное меню подкрепляет это, делая инвазивные действия осознанным выбором, а не рефлексом.

Тренажер и упражнение по лидерству

Вагон-ресторан инцидентов — это еще и инструмент обучения и лаборатория лидерства.

Используйте его в учениях

Проводите game day и chaos-упражнения, где:

IC обязан открыть меню в течение первых 2 минут.
Команда должна объяснить, почему она не трогает какие-то пункты.
Вы моделируете давление руководства: «Почему бы просто не сделать фейловер?» — IC тренируется отвечать: «Вот почему это не в меню первых 15 минут».

Тренируйте спокойные, явные решения

Ритуал проставления галочек на бумаге:

Делает лидерство видимым.
Создает ощущение безопасности: люди видят, что есть план.
Снижает градус обвинений потом — рискованные действия не были забыты, их сознательно отложили.

Вы тренируете людей делать осознанный выбор, а не реагировать автоматически.

Держите меню живым: пересмотр после каждого инцидента

Статичное меню со временем устаревает или становится опасно неполным.

После каждого заметного инцидента, на разборе постфактум:

Спросите, какие действия были особенно заманчивыми. Предлагал ли кто-то что-то, что стоило бы включить в список «не трогать вначале»?
Уберите неэффективные или вредные шаги. Если стандартное действие стабильно все ухудшает, поднимите его в «Высокий риск» или выкиньте совсем.
Повысите в статусе проверенно безопасные шаги. Если какой-то паттерн ответа стабильно безопасен и полезен, добавьте его в «Безопасные дефолты».
Распечатайте и раздайте заново. Обновите физическое меню. Убедитесь, что у каждого нового онколла есть свежая версия.

Со временем ваше меню превращается в выжатое знание команды: все «никогда больше так не делаем» и «всегда сначала пробуем это» на одном листе.

Как начать уже на этой неделе

Не нужен большой проект. Начните минимально:

Набросайте первую версию бумажного меню с:
- 5–10 высокорисковыми действиями (не трогать в первые 15 минут),
- 3–5 безопасными ранними шагами.
Распечатайте и положите рядом с каждым рабочим местом онколла.
Добавьте простой чек-лист первых 15 минут в документацию по инцидентам.
Проведите одну tabletop-сессию с использованием меню.
Отрефлективируйте и доработайте по фидбэку.

Вы удивитесь, как часто в реальных инцидентах кто-то скажет: «Давайте сначала посмотрим в меню».

Вывод: простой ритуал для лучших инцидентов

Современные системы сложны, но ритуалы инцидентов необязательно должны быть такими же.

Аналоговый вагон-ресторан инцидентов — бумажное меню, общая метафора и плейбук первых 15 минут — помогает командам:

Избегать панических, высокорисковых фиксов.
Фокусироваться на стабилизации и наблюдаемости до «глубокой хирургии».
Практиковать спокойное, основанное на критериях лидерство под давлением.
Превращать тяжелые уроки в живой, осязаемый артефакт.

В следующую аварию, когда адреналин зашкаливает и всем хочется «просто что-нибудь попробовать», зайдите мысленно в вагон-ресторан, откройте меню и решите — вместе — что вы пока не будете чинить.

Будущее вы, ваши графики аптайма и ваши пользователи скажут вам за это спасибо.