План восстановления после аварии: от «ну часа три» до реального документа

Вопрос прозвучал на обычной встрече, без особого повода. Финансовый директор спросил: «Если серверная сгорит - буквально сгорит, вот прямо сегодня ночью - когда мы восстановимся?». Мы переглянулись с коллегой. Сказали что-то вроде «ну, часа три-четыре, всё же в бэкапах». Директор кивнул и ушёл. А мы остались с неприятным ощущением, что только что соврали - не намеренно, но соврали.

«Часа три-четыре» не было ни откуда взято. Это было ощущение, коллективное представление команды, основанное на том, что бэкапы пишутся, железо стоит, люди опытные. Конкретных цифр не было ни у кого.

Учебное восстановление

Год назад мы делали похожую проверку у другого клиента. Тогда нашли неполный бэкап 1С и отсутствие документации по паролям. Здесь решили повторить - теперь уже целенаправленно, с установкой замерить реальное время от «объявили аварию» до «всё работает».

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

Прошло не три часа. Прошло двенадцать с половиной.

Где потерялось время

Разбор по пунктам показал несколько мест, где каждый раз теряли по часу-полтора.

Первое - поиск дистрибутивов и лицензий. Серверное ПО нужно ставить заново. Где ключи от Windows Server? Один нашёлся на ноутбуке инженера, второй - в почте трёхлетней давности. SQL Server нашли на диске в ящике стола. Exchange - пришлось звонить вендору. Итого: больше двух часов только на сборку того, что нужно для установки.

Второе - порядок установки. Казалось бы, все знают. Но когда садишься и делаешь, выясняется: Active Directory надо поднять раньше Exchange, файловый сервер - раньше 1С, принтерный сервер - после файлового. Несколько раз переделывали. Документации с правильным порядком не было.

Третье - сетевые настройки. IP-адреса, DNS-зоны, маршруты - всё это живёт в головах. Часть удалось вытащить из конфигов на стримере, часть пришлось восстанавливать по памяти и проверять тестами. Один адрес перепутали, полчаса выясняли почему не ходит почта.

Четвёртое - восстановление почтовых ящиков. Бэкап Exchange шёл, но процедура восстановления отдельных ящиков - не та же, что восстановление сервера. Помучились.

Пятое - проверка. «Всё поднялось» и «всё работает» - разные вещи. Прогнали список: пользователи логинятся, 1С открывается, почта ходит, принтеры видны, интернет есть, VPN до офиса поднимается. На это ещё час, плюс два раза что-то переделывали.

Двенадцать с половиной часов. Вчетверо больше «ну, часа три-четыре».

Что такое настоящий DR-план

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

Структура сложилась такая:

• Инвентарь восстановления - список всего, что нужно для подъёма: дистрибутивы, лицензионные ключи, адреса, пароли. Не «где-то есть», а конкретно где и в каком виде. Копия в двух местах - у нас и у клиента в сейфе.
• Порядок восстановления - пошаговый список с зависимостями. AD первым, потом DNS, потом файловый сервер, потом Exchange, потом 1С. Каждый шаг - конкретные действия, не «поставить сервер».
• Контрольный список проверки - чеклист того, что должно работать, чтобы считать восстановление законченным. С ответственным за каждый пункт.
• Контакты - вендоры, провайдеры, телефоны для получения ключей или помощи. На бумаге, не только в почте на сервере, который сгорел.
• RTO и RPO - реальные, а не придуманные. Recovery Time Objective: двенадцать часов при хорошем раскладе, восемнадцать при плохом. Recovery Point Objective: данные за последние сутки, почта - за последние четыре часа (инкрементальный бэкап). Это не те цифры, которые хочется видеть, но это честные цифры.

Последний пункт - самый важный. В SLA-договоре с клиентом у нас теперь есть раздел про восстановление. Не абстрактный, а со ссылкой на этот документ и этими конкретными числами. Клиент подписал, зная реальное время - не «часа три».

Про аудит инфраструктуры

Ситуация с этим клиентом начиналась с аудита - мы разбирали состояние инфраструктуры и в процессе задали вопрос про восстановление. Именно тогда и выяснилось, что ответа нет. Без этого вопроса всё бы продолжалось: бэкапы пишутся, директора успокоены, реальное время восстановления неизвестно.

Аудит - это не только проверка конфигов и патчей. Это ещё вопрос «что будет, если вот этот сервер прямо сейчас перестанет работать». Ответ на него часто оказывается неожиданным.

После

Раз в полгода - плановое учебное восстановление. Не обязательно полное: можно поднять только 1С или только файловый сервер. Главное - сверять реальное время с тем, что написано в плане, и обновлять план, если что-то изменилось в инфраструктуре.

На следующей встрече финансовый директор спросил то же самое. Мы открыли документ и показали: двенадцать часов, вот чеклист, вот где лежат ключи. Ему это не понравилось - он ожидал три часа. Но по крайней мере теперь мы не врали.