Учения по восстановлению: почему стоит практиковать отказ до того, как он попадёт в продакшен

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

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

Проблема письменных планов

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

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

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

Как выглядят учения по восстановлению

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

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

Failure drills — более короткие и сфокусированные. Вы выбираете один конкретный сценарий и проходите его за час-два. Например, симулируете, что последний деплой внёс баг в платёжный поток, и замеряете, сколько времени нужно команде на откат и проверку работоспособности предыдущей версии. Failure drills проще вписать в график и можно проводить чаще.

Tabletop exercises — самая лёгкая форма. Команда собирается у доски или над общим документом и устно проговаривает сценарий отказа. Реальные системы не затрагиваются. Это полезно для проверки принятия решений и коммуникации, но не проверяет, работают ли технические шаги на самом деле.

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

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

flowchart TD A[Симуляция отказа в стейджинге] --> B[Выполнение плана восстановления как написано] B --> C{Наблюдение результата} C -->|План сработал| D[Документирование успешных условий] C -->|План не сработал| E[Выявление пробелов] E --> F[Исправление скриптов, документации или доступа] D --> G[Обновление плана восстановления] F --> G G --> H[Планирование следующего учения] H --> A

Почему отказ во время учений ценен

Заманчиво относиться к учениям как к тесту на сдачу/провал. Если учение успешно — команда чувствует себя хорошо. Если провалилось — испытывает смущение. Но такая постановка упускает суть.

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

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

Вот почему учения должны быть разнообразными. Меняйте сценарии. Изменяйте время. Вводите неожиданные осложнения. Чем реалистичнее учение, тем полезнее обратная связь.

Что учения выявляют помимо технических шагов

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

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

Как часто проводить учения

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

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

Краткий чек-лист для первого учения

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

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

Не стремитесь к идеалу с первой попытки. Стремитесь к обучению.

Суть

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