Инструкции на случай инцидента для небольшого SaaS до первой аварии

Почему runbook'ы важны до первого простоя

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

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

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

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

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

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

Что должно быть в хорошем runbook'е

Runbook должен убрать догадки, когда люди под давлением. Если кто‑то открыл его во время инцидента, он должен сразу понять, кто ведёт, что запустило runbook и что делать в первую очередь.

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

Затем определите точный триггер. Назовите оповещение, ошибку или шаблон обращений поддержки, который запускает runbook. «Ошибка API платежей выше 5% в течение 10 минут» ясно. «Платежи выглядят плохо» — слишком расплывчато.

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

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

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

Оставьте небольшое место внизу для временных меток, выполненных действий и финального исправления. Эта заметка превращает один грубый инцидент в более полезный runbook для следующего раза.

Как написать runbook, которым действительно будут пользоваться

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

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

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

Протестируйте с кем‑то ещё

Черновик не готов только потому, что автор его понимает. Попросите другого человека следовать ему точно как написано. Наблюдайте, где он останавливается. Если он спрашивает, какой дашборд открыть, какую среду использовать или что значит термин — в черновике ещё есть пробелы.

Быстрый обзор обычно выявляет одни и те же проблемы:

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

Храните финальную версию в месте, где команда может быстро её открыть. Общая внутренняя вики, репозиторий или папка ops подойдут, если все могут открыть их во время инцидента. Укажите имя владельца и дату последнего обзора вверху. Старые runbook'ы создают новые проблемы, поэтому обновляйте их после каждого реального инцидента.

Короткий шаблон для ошибки деплоя

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

Этот runbook окупается почти сразу, потому что у проблем деплоя часто есть быстрая починка: откат изменений, которые их вызвали.

• Считайте это инцидентом, если релиз ломает вход, оформление заказа, ключевые страницы или публичные API.
• В первые 10 минут остановите новые деплои, подтвердите охват и назначьте лидера инцидента.
• Откатитесь на последнюю рабочую версию. Если релиз менял статические ресурсы, конфиг или сессии — очистите соответствующий кэш и понаблюдайте за уровнем ошибок.
• Отправьте клиентам обновление: что сломалось, кто это чувствует, что делает команда и когда ждать следующего обновления.
• После восстановления запишите плохой коммит или изменение конфига, проверку, которая это пропустила, и одно защитное правило для релизов.

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

Держите пост‑инцидентные заметки короткими, но конкретными. «Оформление заказа сломалось после коммита 8f3a. Тест не покрывал сочетание купона и налога. Добавили canary-релиз и smoke‑тест для оформления.» Этого достаточно для следующего дежурного.

Короткий шаблон для сбоя платежей

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

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

1. Назначьте одного владельца и проверьте статус провайдера, недавние логи ошибок и собственный мониторинг. Быстро подтвердите охват: все платежи, один регион, один тариф или только продления.
2. Пауза навязчивых повторов и любых задач, которые продолжают бить по провайдеру. Сохраните неуспешные события платежей в очередь или таблицу, чтобы позже можно было воспроизвести.
3. Протестируйте один путь оплаты самостоятельно. Попробуйте оформление заказа, продление и доставку вебхуков, если возможно. Запишите, что работает, а что нет.
4. Если есть резервный поток, переключитесь на него. Это может быть второй провайдер, ручная выставка счёта или временная обработка как «оплата ожидается» вместо жёсткой ошибки.
5. Опубликуйте короткое сообщение клиентам в приложении или статусе: скажите, что оформление может не пройти, попросите не пытаться списывать платёж снова и снова, и объясните поддержке, что отвечать при вопросах о дубликатах списаний.
6. Когда провайдер восстановится, воспроизведите очередь событий, повторите неудавшиеся списания один раз и проверьте состояние аккаунтов. Убедитесь, что пользователи получили нужный доступ после оплаты.

После простоя разберитесь с последствиями: пропущенные продления, дублирующие списания, запросы на возврат и тикеты от пользователей, которые потеряли доступ после оплаты.

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

Короткий шаблон для блокировки пользователей

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

Начните с проверки охвата. Один затронутый пользователь обычно указывает на состояние аккаунта, проблемы с браузером, MFA или некорректный ресет пароля. Волна отказов у многих пользователей чаще указывает на конфиг авторизации, SSO, лимиты запросов или недавний деплой.

Короткий runbook может выглядеть так:

• Триггер: повторные ошибки входа, множество писем с ресетом, блокировка админ‑доступа или резкий рост ошибок аутентификации.
• Проверка охвата: подтвердите, затрагивает ли это один аккаунт или многих. Проверьте логи авторизации, недавние правки прав, статус SSO и любые изменения авторизации из последнего деплоя.
• Безопасное восстановление: сначала верифицируйте пользователя, затем разблокируйте аккаунт, очистите битые сессии, при необходимости отправьте поток сброса пароля и проверьте лимиты или правила MFA прежде, чем что‑то отключать.
• Заметки для поддержки: запросите email аккаунта, тип устройства, браузер, точное сообщение об ошибке и время последнего успешного входа.
• После инцидента: исправьте правило или путь в коде, который вызвал блокировку — неправильное сопоставление SSO, баг в сессиях или ошибочное изменение ролей.

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

Закрывайте runbook двумя фактами: что видели пользователи и что изменила команда. Это сделает следующую блокировку быстрее для решения.

Короткий шаблон для восстановления данных

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

Используйте простой сценарий, который любое дежурное может выполнить в 2 часа ночи. Если миграция удалила строки, пакетная задача повредила записи или кто‑то случайно удалил данные, один и тот же порядок действий сработает.

1. Подтвердите триггер и охват. Запишите, что сломалось, какие таблицы или объекты затронуты и когда началось плохое изменение. Назначьте одного лидера восстановления, чтобы двое человек не внесли разные правки одновременно.
2. Заморозьте записи в затронутой области. Переведите приложение в режим обслуживания для этой функции, отключите воркер или заблокируйте записи на уровне БД при необходимости. Затем проверьте время последнего бэкапа или снапшота и зафиксируйте возможное окно потери данных.
3. Сначала восстановите в безопасную среду вне продакшена. Восстановите бэкап в отдельную БД или окружение, затем сравните количество записей, метки времени и несколько известных ID. Возьмите несколько реальных записей из тикетов поддержки или внутренних тестовых аккаунтов и убедитесь, что они выглядят правильно.
4. Сообщите клиентам, что изменилось. Говорите просто: какие данные пострадали, что вы восстановили и что ещё нужно проверить. Если какие‑то недавние изменения могут отсутствовать, скажите об этом прямо, вместо того чтобы ждать, пока пользователи это обнаружат.
5. Закройте инцидент после‑уходом: зафиксируйте время начала восстановления, время окончания, возраст бэкапа и подтверждённое окно потерь. Если восстановление заняло слишком много времени — исправьте это в следующий раз. Runbook, который теоретически восстанавливает данные, но выполняется три часа, недостаточно хорош.

Небольшой пример: если миграция удалила 1 200 заметок подписок в 14:10, остановите записи в этой таблице, восстановите снапшот на 14:00 в безопасное место, сравните счётчики, протестируйте несколько клиентских записей, затем восстановите недостающие строки проверенным скриптом.

Ошибки, которые тормозят команды

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

Runbook по деплою не должен объяснять вашу философию релизов. Он должен сказать, кто останавливает выкатывание, как подтвердить плохую версию, как откатиться и где публиковать статус. Если шаг требует суждения, пропишите триггер. «Если уровень ошибок превысил 5% в течение 10 минут — откат» гораздо лучше, чем «оценить влияние».

Ещё одна задержка — неясная ответственность в первые 30 минут. Команды часто предполагают, что кто‑то возьмёт на себя лидерство. В итоге поддержка ждёт инженеров, инженеры ждут операционников, и никто не решает. Пропишите одно имя или роль вверху каждого runbook'а для окна первичной реакции, даже если потом будет передача.

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

Проблемы с доступом тратят больше времени, чем команды ожидают. Многие runbook'ы предполагают, что все могут логиниться куда угодно во время кризиса. Реальные простои блокируют доступ к облачным дашбордам, платежным инструментам, админ‑панелям, VPN или даже командному чату. Добавьте резервные методы доступа, экстренные контакты и короткую заметку о том, где хранить recovery‑коды.

Бэкапы внушают ложное доверие. Зелёный статус «бэкап успешен» не говорит, занимает ли восстановление 8 минут или 8 часов. Тестируйте время восстановления по расписанию, фиксируйте результат и обновляйте runbook. Если команда никогда не восстанавливала реальные данные под давлением времени — план восстановления неполный.

Быстрая проверка перед закрытием

Runbook готов только тогда, когда кто‑то, кто его не писал, может использовать его под стрессом. Если новый сотрудник застрянет, документ всё ещё имеет пробелы.

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

Затем сверьте шаги с текущей конфигурацией. Старая номенклатура инструментов, удалённые админ‑роли и устаревшие права создают больше проблем, чем ожидают команды. Если runbook говорит «откройте старый дашборд» или предполагает доступ, которого у людей нет — исправьте это сейчас, а не во время простоя.

Короткий чек‑лист достаточен:

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

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

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

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

Простой пример инцидента

В 16:40 в пятницу команда выкатывает небольшое изменение в оформление заказа. Через десять минут поддержка видит паттерн: некоторые пользователи кладут товары в корзину, но оплата для них падает. Другие завершают заказ без проблем, что делает баг трудно обнаружимым и сложно объяснимым.

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

Простой ответ выглядит так:

1. Заморозьте релизы, чтобы никто не добавлял изменений во время расследования.
2. Откатите деплой оформления заказа до последней рабочей версии.
3. Отправьте одно короткое сообщение в поддержку: у некоторых пользователей ошибки при оформлении, команда сейчас откатывается, следующее обновление через 15 минут.
4. Попросите финансы сохранить список неудачных списаний и незавершённых заказов для повторной обработки или связи с клиентами после восстановления.
5. Подтвердите восстановление реальным тестовым заказом, затем мониторьте систему ещё 30–60 минут.

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

Финансы тоже должны быть в курсе. Если платежи падают во время инцидента, кто‑то должен сохранить список затронутых клиентов, суммы и метки времени. Это превращает грязные догадки в чистую задачу восстановления в понедельник.

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

Что делать дальше

Если у вас ещё ничего не записано, не пытайтесь задокументировать все крайние случаи за неделю. Начните с четырёх runbook'ов, которые в первую очередь защищают деньги и доступ:

• deploy failure
• payment outage
• user lockout
• data restore

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

После этого проведите короткую тренировку. 15 минут достаточно. Один человек ведёт, один следует runbook'у точно, и один наблюдает за пропущенными шагами, неясной формулировкой или решениями, зависящими от знаний, которые живут в голове одного человека.

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

Если хотите внешнюю проверку, Oleg Sotnikov at oleg.is может просмотреть ваши runbook'ы, поток инцидентов и пробелы в восстановлении. Такой обзор часто быстро выявляет слабые места: оповещения, которые никто не видит, шаги восстановления, которые никто не тестировал, или правила доступа, блокирующие людей, пытающихся помочь.

Поставьте первую версию в календарь уже сегодня. Четыре часа на написание и одна короткая тренировка могут сэкономить вам день паники позже.