DRP на бумаге и DRP в реальности: первое учение обнажило двукратный разрыв

Прошлой весной помогали клиенту - производственное предприятие, около трёхсот рабочих мест - разработать Disaster Recovery Plan. Документ вышел аккуратный: перечень критичных систем, порядок восстановления, ответственные, контакты, RTO по каждому сервису. Документ лежал, клиент был спокоен, мы тоже.

В октябре решили это проверить.

Повод был формальный - аудитор клиента упомянул ГОСТ Р ИСО/МЭК 27001-2006, в котором требования к непрерывности бизнеса и тестированию DRP прописаны явно. Не «рекомендуется», а «должно». Дата учений согласована, окно - выходные, участники предупреждены. Заранее условились: никакого досрочного стопа, идём до конца независимо от того, как будет идти.

Сценарий

Отказ основного машинного зала. Полностью: электропитание, охлаждение, сеть - всё недоступно. Резервная площадка - серверная комната в другом здании того же предприятия, метров пятьсот от основного корпуса. Там стоят несколько серверов под горячий резерв, отдельный канал интернета, резервные копии с Data Domain по расписанию.

Команда: двое из нашей стороны, двое системных администраторов клиента. Все четверо - по DRP. Связь между собой только через мобильные телефоны: корпоративная телефония тоже в «упавшем» датацентре.

Что шло не так с первых минут

Первое - документ написан для другого человека. DRP описывал шаги правильно, но на уровне «запустить сервис X на резервном сервере». Подразумевалось, что исполнитель знает, где именно смотреть конфиги, какая версия приложения на резерве, какой пользователь запускает службу. Один из администраторов клиента эти системы знал хорошо. Второй - документ читал буквально и постоянно останавливался на шагах, которые «подразумевались».

Второе - резервные копии оказались правильными, но восстановление не было проверено. Бэкапы снимались регулярно, Data Domain работал исправно, данные на резервной площадке есть. Но конкретная процедура восстановления БД из бэкапа на резервный SQL-сервер с последующей сменой строк подключения в приложениях - на практике не делалась ни разу. Ушло значительно больше времени, чем написано в документе, пока разбирались с версиями, правами и параметрами restore.

Третье - сетевые настройки. Резервная площадка имеет другую подсеть. В плане это отражено. Но количество мест, где нужно поправить IP или DNS-запись, оказалось больше, чем перечислено в чеклисте. Нашлись принтеры, одно из приложений с жёстко прописанным адресом сервера, мониторинг, который после переезда никуда не сигналил, потому что сам оказался на основной площадке.

Итог по времени

Плановое RTO по критичным сервисам (ERP, файловый сервер, электронная почта) - условно говоря, несколько часов. Фактически на восстановление ушло примерно вдвое больше. Это не катастрофа, но и не то, что было написано в документе, который подписан и лежит у директора.

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

Что делаем по итогам

Сейчас идёт доработка DRP по четырём направлениям:

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

Несколько слов о формате учений

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

Разрыв между плановым и фактическим RTO - это не провал, это данные. Теперь клиент знает реальную цифру и понимает, где конкретно теряется время.

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