DR-учения: полное тестирование плана аварийного восстановления

Disaster recovery drill: что ломается, если план не проверяли

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

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

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

Учения по аварийному восстановлению, или disaster recovery drill, вскрывают именно эти разрывы: несогласованный порядок запуска, просроченные доступы, неучтённые связи между сервисами. После прогона регламент превращается из описания намерений в последовательность действий, которую можно исполнить под давлением и без подсказок.

Ниже разбираем, как это закрывается и что именно проверяется на учениях.

Что даёт регулярная проверка плана восстановления

План восстановления, который ни разу не исполняли целиком, — это гипотеза. Учения превращают её в измеряемую величину: проходим сценарий от сигнала об аварии до возврата сервиса и фиксируем фактический RTO и RPO — не тот, что записан в документе, а тот, что получился на замере.

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

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

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

Форматы drill-учений: табличный прогон, частичный и полный отказ

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

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

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

Этапы проведения учений: от аудита до разбора результатов

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

1. Инвентаризация и аудит инфраструктуры. Собираем фактическую картину: какие сервисы работают, где размещены, кто владелец, какие данные хранят. Расхождения с документацией фиксируем сразу — обычно именно они и ломают восстановление.
2. Карта зависимостей. Определяем, что от чего зависит и в каком порядке поднимать: хранилище, очереди, интеграции, доступы. Без этого восстановление идёт наугад и упирается в «сервис поднялся, а данные не отдаёт».
3. Сценарий и критерии успеха. До старта согласуем, что считаем провалом: целевое время восстановления, допустимую потерю данных, зоны ответственности. Тогда спорить о результате постфактум не придётся.
4. Проверка резервных копий. Смотрим не наличие копий, а их разворачиваемость: восстановление на изолированный контур, сверка целостности, откат на предыдущий срез. Копия, которая не разворачивается, резервом не является.
5. Прогон сценария с замерами. Ведём хронометраж каждого шага и журнал действий: кто, что и когда делал. Замеры показывают, где реально теряются минуты, а не где, по ощущениям команды, «всё долго».
6. Разбор результатов и расхождений. Сравниваем план с фактом: какие шаги не совпали, какие допущения не подтвердились, где пришлось изобретать обходные пути. Каждое расхождение становится задачей с владельцем.
7. Обновление плана и передача. Перевыпускаем регламент, чек-листы и схему зависимостей, назначаем ответственных и дату следующих учений. План живёт в документации, а не в голове одного инженера.

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

Что заказчик получает на руки после учений

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

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

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

Кейс: как учения вскрыли нерабочий сценарий переключения

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

Прогон вскрыл расхождение между документом и реальным поведением системы. Возврат в работу занял 3 часа 40 минут вместо заявленных 30: полтора часа ушли на ручные согласования, ещё сорок минут — на ожидание отстающей реплики, состояние которой перед переключением никто не проверял. Шаг «перевести трафик» в регламенте стоял после запуска приложений, поэтому часть записей ушла в уже отключённый контур.

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

Метрики до и после:

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

Чем учебная тревога отличается от настоящего переключения

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

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

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

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

Технические сомнения перед первыми учениями

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

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

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

Можно ли начать с части систем?

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

Сколько людей нужно со стороны заказчика?

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

Обсудим задачу: с чего начнём и что подготовим

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

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

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

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