Годовой тест DR-плана: двое из трёх клиентов не уложились в RTO

Раз в год мы проводим плановый DR-тест у клиентов, которые находятся на управляемом сопровождении с прописанными SLA. В этот раз прогнали троих. Результат честный: двое не уложились в RTO, зафиксированный в договоре. Не катастрофически - не в два раза, не в три - но за порогом. Тем не менее это нарушение контракта, пусть и плановое, и это повод разобраться, а не списать на «ну почти же».

Сам по себе факт провала DR-теста - это нормально. Именно для этого тест и делается: чтобы найти разрывы в мирное время, а не в 3 ночи во время реального инцидента. Проблема не в том, что провалились, а в том, почему.

Что конкретно пошло не так

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

У второго клиента - Hyper-V-инфраструктура, про которую мы писали раньше. Там с репликацией всё нормально, но при тесте реального failover выяснилось, что шаг с обновлением DNS-записей не был автоматизирован и не был нормально задокументирован. Инженер сделал это по памяти, но «по памяти» в runbook не считается.

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

Что изменили в runbook

Прошлись по всем трём и починили очевидные дыры:

• Явные ссылки на файлы и серверы. Не «восстановить из бэкапа», а «взять последний файл из /backup/client/daily/, проверить дату в имени, размер должен быть в районе X ГБ». Конкретика снижает время на поиск и ошибки под стрессом.
• DNS и сетевые шаги - отдельный раздел. Раньше это было вперемешку с остальным. Теперь выделено: какие записи менять, в каком DNS (внутренний, внешний), TTL, как проверить что изменение применилось.
• Проверка результата на каждом шаге. Не просто «запустить VM», а «убедиться что VM ответила по SSH, curl вернул HTTP 200 на /health». Без проверки промежуточных шагов нет уверенности, что идёшь в правильном направлении.

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

Добавили секцию по нулевым дням

Уходящий год наглядно показал: Heartbleed в апреле, Shellshock в сентябре, POODLE в октябре. Три серьёзные уязвимости меньше чем за год, каждая с экстренным реагированием. И при этом в DR-планах ни у одного клиента не было секции «реагирование на критическую уязвимость нулевого дня». Была секция «восстановление после сбоя», была «потеря ЦОД», было «ransomware» у одного. Уязвимость с немедленным патчингом - не было.

Добавили. Структура примерно такая:

Триггер. CVSSv2 >= 9.0 или явный признак активной эксплуатации в публичных источниках (CERT, вендор, Shodan-массовые сканы).

Ответственный. Конкретное имя и контакт - не «дежурный инженер». Если ответственного нет на месте - кто подхватывает. Эскалация через N минут без подтверждения.

Первые 30 минут. Оценка затронутых компонентов по заранее составленному реестру сервисов и версий ПО. Это отдельный документ, который надо поддерживать актуальным - и это сейчас слабое место у всех троих клиентов, признаем честно.

Патчинг или митигация. Для типовых сценариев прописаны команды - yum/apt для пакетных обновлений, отключение модуля/протокола как временная мера. Не «обновить bash», а конкретная команда с проверкой.

Коммуникация. Кто уведомляет клиента, в какой момент, по какому каналу. У нас это сообщение в служебный telegram-чат плюс звонок при критическом. Это тоже нужно прописать, потому что в панике люди начинают слать всё всем.

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

Где сейчас

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

Один вывод, который следует держать в голове: DR-план, который не тестировался и не правился год - это не DR-план, это его призрак.