Чеклист для продакшн-инцидентов для маленьких команд, которым нужна ясность

Что решает production runbook для маленькой команды

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

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

Этот чеклист сфокусирован на первом часе: быстрая триажа, решения об откате, коммуникация с клиентами и базовый цикл после инцидента, чтобы не допустить повторений. Он не заменяет глубокую отладку, долгосрочную архитектурную работу или полноценную программу безопасности. Он рассчитан на 2–5 человек, включая неспециалистов.

Простое правило помогает принимать лучшие решения под давлением:

• Исправляйте сначала то, что влияет на клиента, даже если решение временное.
• Выбирайте наименее рискованное изменение (часто откат) до сложного патча.
• Общайтесь рано и коротко, затем обновляйте по предсказуемому расписанию.
• Учитесь после того, как сервис стабилен.

Пример: если деплой вызывает ошибки при оформлении заказа, сначала откатите, чтобы остановить неудачные платежи. Разбирайтесь в изменении кода, когда доход и доверие перестанут утекать.

Задайте уровень серьёзности и роли заранее

Когда что-то ломается, команды тратят время на споры о серьёзности и о том, кто принимает решения. Простой шкалы серьёзности и чёткие роли превращают runbook в действие, а не в обсуждение.

Серьёзность простыми словами

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

• Minor: часть пользователей затронута, есть обходной путь, риск для данных отсутствует.
• Major: много пользователей затронуто, ключевая функция деградирована, риски для дохода или дедлайнов.
• Critical: сервис в основном недоступен, есть риск безопасности или вероятная потеря данных.

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

Роли, которые убирают узкие места

Назначьте роли сразу, даже если команда из двух человек. Один человек ведёт решения. Один человек делает обновления.

• Incident lead: отвечает за таймлайн, выбирает следующие шаги, предотвращает метания задач.
• Communicator: публикует обновления, отвечает стейкхолдерам, держит инженеров сфокусированными.
• Rollback approver: человек, который может сказать «да, откатываем сейчас» (часто incident lead и резерв).
• Scribe (опционально): фиксирует ключевые времена и действия для обзора.

Решите, как быстро дозвониться до rollback approver (звонок, смс, то, что вы реально отвечаете). Запишите резерв — инциденты любят отпуска.

Наконец, определите «сервис восстановлен» в одном предложении. Пример: «Пользователи могут войти и загрузить дашборд менее чем за 3 секунды, а уровень ошибок держится ниже 1% в течение 15 минут.» Это предложение предотвращает преждевременные торжества.

Подготовка, которая делает чеклист полезным

Чеклист работает только если он указывает на реальные места, к которым команда может получить доступ за минуты, а не «надо посмотреть логи». Цель — убрать догадки в стрессовой ситуации.

Начните с одностраничной карты системы. Держите просто: что где работает и от чего что зависит (веб-приложение, API, база данных, кэш, провайдер аутентификации, фоновые задачи, сторонние сервисы). Добавьте известные единичные точки отказа.

Запишите основные пользовательские пути, а не каждый эндпоинт. Большинство маленьких команд живут и умирают несколькими потоками: вход, регистрация, оформление заказа и одна–две ключевые операции. Если вы можете быстро их проверить, вы подтвердите влияние и поймёте, когда всё снова в порядке.

Держите короткий раздел «куда смотреть» и обновляйте его. Перечислите несколько метрик, которым вы доверяете (уровень ошибок, задержки, успешные входы, глубина очереди, подключения к БД), где дашборды, где логи (приложение и edge/CDN) и как увидеть версию и время последнего деплоя. Добавьте эталон «хорошего» — например вчерашние числа, чтобы видеть, что нормально.

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

Документируйте, где хранятся конфиги и секреты, не раскрывая их. Напишите «где и как ротировать», а не сами значения.

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

10-минутный чеклист инцидента (пошагово)

Когда что-то ломается, нужен короткий сценарий, которого можно придерживаться под давлением. Этот чеклист рассчитан на первые 10 минут, когда важнее скорость и безопасность, чем идеальная диагностика.

Начните с простого подтверждения воздействия. Что пытаются сделать пользователи и что не работает? Это у всех или у подмножества (регион, тариф, браузер, только новые аккаунты)? Если вы можете воспроизвести один раз — запишите точные шаги и сообщение об ошибке.

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

Работайте по одной небольшой гипотезе за раз. Выберите наиболее вероятный триггер (последний деплой, изменение конфига, сторонний сбой) и сделайте одну–две быстрой проверки, чтобы подтвердить или отбросить её.

• Минута 0–2: Подтвердить влияние (что сломано, кого затронуло, когда началось)
• Минута 2–4: Заморозить рискованные изменения (остановить деплои, избегать новых миграций, уменьшить поверхность воздействия)
• Минута 4–6: Быстрые проверки (статус последнего деплоя, уровень ошибок, подключение auth/БД, статус сторонних сервисов если нужно)
• Минута 6–8: Выбрать путь (смягчить через откат/отключение фичи или продолжать копать, если смягчение рискованно)
• Минута 8–10: Записать действия (временные метки, что изменили, что наблюдали и следующее решение)

Ведите непрерывный таймлайн в одном месте. Даже простая запись «10:07 откатили сборку 214, ошибки упали» экономит часы при разборе.

Куда смотреть сначала, когда что-то ломается

Начните с симптомов, а не с предположений. Подтвердите, что видят пользователи и как широко это распространено: всплески ошибок, медленные запросы, таймауты или поток обращений в поддержку. Если можно, зафиксируйте точное время начала — этот штамп направит дальнейший поиск.

Дальше привяжитесь к тому, что изменилось. Большинство инцидентов имеют триггер: деплой, изменение конфига, миграция БД, ротация секрета или переключение фич-флага. Даже если изменение кажется мелким, считайте его подозрительным, пока не исключите.

Простой порядок первичной триажи, работающий для маленьких команд:

• Подтвердите воздействие: уровень ошибок, задержки и какие эндпоинты/экраны падают.
• Проверьте изменения за последние 30–60 минут: деплои, правки конфигов, миграции, фоновые задачи.
• Посмотрите на ёмкость и насыщение: CPU, память, диск, медленные запросы, пределы подключений.
• Просканируйте логи на повторяющуюся ошибку (одно и то же сообщение, тот же стек, тот же путь).
• Проверьте зависимости: аутентификация, отправка email/SMS, платежи, CDN и API сторонних сервисов.

Сканируя логи, не читайте всё подряд. Ищите наиболее частую ошибку и следуйте за ней. Если вы видите повторы «token signature invalid» или «database connection refused», у вас уже сильный повод для дальнейшей проверки.

Также проверьте базовые тихо падающие вещи: просроченные сертификаты, отсутствующие переменные окружения и ограничения по rate limit. Это часто встречается в прототипах, не подготовленных для продакшна.

Когда найдёте вероятную причину, сразу запишите её (время, симптом, доказательства). Эта заметка станет вашим таймлайном и сохранит выравнивание команды.

Быстрые варианты смягчения до полного исправления

Когда продакшн горит, цель — не идеальное исправление, а снижение воздействия минимально рискованным изменением, а затем покупка времени для диагностики.

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

Обычные ходы для маленьких команд:

• Отключить новое поведение (feature flag, переключатель конфига или переменная окружения), чтобы вернуть пользователей на знакомый путь.
• Переключиться на режим fallback: режим только чтения или ограниченный набор функций, чтобы ядро оставалось доступным.
• Снизить нагрузку: ввести rate limit, временно блокировать абьюзеров или увеличить кеширование горячих эндпоинтов.
• Приостановить рискованные операции, если есть риск для данных (остановить записи, фоновые задачи или импорты) до выяснения причин.
• Добавить быстрый ограничитель: отвергать явно неправильный ввод, снизить конкуренцию или скорректировать таймауты только если вы уверены, что это помогает.

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

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

Как откатываться безопасно, не ухудшая ситуацию

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

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

Простая дорожная карта отката для runbook:

• Заморозьте новые деплои и остановите автопайплайны.
• Найдите последний известный рабочий релиз (commit, build ID, тег контейнера) и что изменилось с тех пор.
• Проверьте не кодовые изменения: переменные окружения, флаги, очереди задач, ключи третьих сторон, ограничения по rate limit.
• Решите стратегию для базы данных: безопасно ли откатывать схему или нужен форвард-хотфикс.
• Откатывайте по одному элементу и записывайте временные метки, чтобы сопоставить логи.

Миграции БД — обычная ловушка. Если миграция удаляет или изменяет данные, откат может провалиться или привести к краху приложения. В таких случаях предпочтительнее небольшой форвард-хотфикс (вернуть столбец, добавить слой совместимости или отключить новый код), чем попытка откатить схему.

После отката прогоните смоук-тесты основных потоков: вход, регистрация, оформление заказа/платёж и одну ключевую операцию, за которую платят пользователи. Если откат не сработал — не дергайтесь. Попробуйте один аккуратный откат к предыдущему known-good. Восстановите из проверенной бэкапы, если нужно. Если ни одно не безопасно — стабилизируйте (режим обслуживания, read-only), пока планируете контролируемое исправление.

Что сообщать во время инцидента (и чего избегать)

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

Установите внутренний ритм рано и придерживайтесь его. Малой команде обычно нужен один владелец обновлений и один канал, где лежат все заметки (даже если это одна ветка чата). Используйте устойчивый каденс, а не поток сообщений.

Внутренний чеклист для обновлений:

• Кто ответственен (incident lead) и кто чинит (назначенные)
• Текущий статус (investigating, mitigating, monitoring, resolved)
• Последние подтверждённые факты (что изменилось, что вы увидели)
• Следующее действие и кто за него отвечает
• Время следующего обновления (например, через 15 минут)

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

Избегайте трёх вещей: догадок («возможно база»), обвинений («X сломал это») и непроверенных сроков («всё будет через 5 минут»).

Лёгкий шаблон, который можно вставлять:

Status: [Investigating | Mitigating | Monitoring | Resolved]
Impact: [Who is affected and what they can’t do]
Workaround: [If available, one clear step]
What we know: [1-2 confirmed facts, no guesses]
Next update: [time]

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

Пример сценария: отказ логина сразу после деплоя

Двухчеловеческая команда. Вы запушили небольшой релиз в 9:05. К 9:08 поддержка пишет: «Не могу войти» и «сброс пароля не работает». Новые регистрации тоже падают. Всё остальное загружается.

Сначала подтвердите, что это реально и широко. Попробуйте войти сами (инкогнито, обычный аккаунт и новый аккаунт). Если не работает, проверьте самые быстрые сигналы:

• Статус провайдера аутентификации (авария, rate limit, деградация)
• Записки по последнему деплою: env vars, callback URL, настройки cookies, CORS, домены редиректа
• Логи приложения по эндпоинту логина (401 против 500 — это важно)
• Последние изменения конфига (ротация секретов, смена домена)
• Быстрая проверка БД: изменялась ли таблица users или хранилище сессий?

К 5-й минуте обычно появляется точка принятия решения. Если ошибки начались сразу после деплоя и вы не можете быстро объяснить почему — отдавайте приоритет откату. Если проблему можно изолировать новым путём, прикрытым фич-флагом — просто отключите его. Хотфикс выбирайте только когда точно знаете, что менять и можете быстро протестировать.

Коммуникация может быть простой и спокойной:

• 5 мин: «Исследуем проблему с логином, затрагивает многих пользователей. Следующее обновление через 20 минут.»
• 30 мин: «Причина, по-видимому, связана с деплоем в 9:05. Сейчас откатываем. Следующее обновление через 15 минут.»
• Resolved: «Вход восстановлен. Поделимся кратким отчётом о случившемся и мерах по предотвращению.»

Пока работаете, ведите небольшой документ заметок: точное время деплоя, время первого обращения пользователя, сообщения об ошибках, что пробовали, что помогло и что будете менять (тесты, проверки конфигов, алерты). Если кодовая база запутана под давлением, может стоить быстро привлечь внешнего эксперта для свежего взгляда.

Частые ошибки, которые замедляют восстановление

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

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

Откат часто пропускают, потому что это воспринимается как признание поражения. Наоборот: откат — контролируемое возвращение в known-good состояние, пока вы дебажите без давления. Если сомневаетесь, спросите: «Есть ли безопасный откат, который сейчас уменьшит вред?» Если есть — делайте.

Другой источник потерь — не ставить паузу на деплои. Коллега пушит маленькое изменение и перезаписывает вашу меру, или CI продолжает шлёпать билды, пока вы стабилизируете. Шаг «заморозить деплои» ставьте рано и делайте видимым.

Отсутствие ясного incident lead ведёт к дублированию и конфликтующей работе. Один человек должен координировать, вести краткий таймлайн и распределять задачи, чтобы двое не гонялись за одной и той же подсказкой.

Наконец, команды часто объявляют «починили» слишком рано. Валидируйте реальным пользовательским потоком (или проверкой, близкой к продакшну), подтвердите, что ключевые метрики вернулись к норме, и наблюдайте 10–15 минут перед закрытием. Многие «вторые падения» — вовсе не новые инциденты, а возвращение первого.

Предотвратите повторы практичным пост-инцидентным рутином

Рутина после инцидента должна быть короткой, конкретной и назначенной по срокам. Проведите её в течение 24–72 часов, пока логи, заметки и память ещё свежи. Цель — не поиск виноватых, а сделать следующий простой случай меньше, реже и легче управляемым.

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

Повестка на 30 минут, которая работает

Используйте простую структуру, чтобы не углубляться в мнения:

• Таймлайн: что видели пользователи, когда вы заметили, когда починили
• Влияние: кто затронут и на сколько долго
• Корневая причина и 2–3 основных фактора
• Что сработало хорошо (сохранить) и что не сработало (изменить)
• Задачи с владельцем и сроком

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

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

Если была вовлечена безопасность (секреты утекли, SQL injection риск, плохая аутентификация), включите чёткое восстановление и шаги проверки. Восстановление может быть ротацией ключей и патчем кода. Проверка — доказать, что всё исправлено: старые ключи больше не работают, повторно пройти путь атаки и проверить логи на подозрительную активность.

Быстрые проверки и следующие шаги

Когда всё шумит, короткий чеклист лучше длинного документа. Прикрепите его туда, где команда действительно будет пользоваться.

• Detect: подтвердите влияние, временное окно и что изменилось последним.
• Stabilize: остановите кровотечение (заморозьте деплои, отключите рискованные задачи, добавьте rate limits).
• Mitigate: примените самый быстрый безопасный обход, чтобы восстановить сервис.
• Roll back: откатитесь к последнему известному рабочему релизу, если фиксация непонятна или рискована.
• Verify + communicate: подтвердите восстановление реальными пользовательскими потоками и опубликуйте чёткое обновление.

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

• Куда смотреть первым делом: дашборды, логи, трекинг ошибок и история деплоев.
• Как откатиться: точные команды, кто может это сделать и как выглядит успех.
• Безопасные переключатели: feature flags, kill switches, шаги maintenance mode.
• Контакты: владелец on-call, путь эскалации, контакты вендоров/поддержки.
• Известные рискованные области: auth, платежи, фоновые задачи, миграции, секреты.

Привлекайте внешнюю помощь, когда инциденты повторяются, никто не понимает архитектуру достаточно быстро для отладки, или есть признаки безопасности (вытекшие секреты, странные запросы в БД, попытки инъекции). Если вы имеете дело с ломаюшимся AI-сгенерированным прототипом, команда по ремедиации вроде FixMyMess (fixmymess.ai) может помочь, диагностировав кодовую базу, восстановив логику, укрепив безопасность и подготовив её к надёжным деплойам.

Держите runbook живым: назначьте одного владельца, просматривайте его ежемесячно по 15 минут и обновляйте после каждого инцидента, пока детали ещё свежи.