План аварийного восстановления: что делать, когда сервер уже не включается

Резервная копия отвечает на вопрос «из чего восстанавливать». План аварийного восстановления отвечает на более широкий вопрос: кто, в каком порядке и на какой инфраструктуре вернёт бизнес к работе.

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

Начните с процессов, а не серверов

Составьте список бизнес-функций:

• продажи;
• бухгалтерия;
• обслуживание клиентов;
• телефония;
• документооборот;
• производство;
• сайт и приём заявок;
• удалённая работа;
• доступ к файлам.

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

Критичность и порядок

Разделите сервисы по приоритету. Простая модель:

Приоритет 1

Без сервиса основной процесс остановлен, обходного решения нет.

Приоритет 2

Работа существенно затруднена, но некоторое время возможен ручной режим.

Приоритет 3

Сервис важен, но может подождать до восстановления основных процессов.

Приоритет должен утверждать бизнес-владелец. ИТ не всегда знает, что в конкретный день важнее: база 1С, сайт или телефония.

RPO и RTO

Для каждого сервиса задают ориентиры:

• RPO — сколько последних данных допустимо потерять;
• RTO — за какое время нужно вернуть сервис.

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

Нельзя обещать восстановление за час, если запасное оборудование доставляется два дня.

Карта зависимостей

Зафиксируйте, что необходимо для запуска каждой системы:

• сеть;
• DNS;
• доменная аутентификация;
• база данных;
• хранилище;
• лицензия;
• сертификат;
• внешний API;
• интернет-канал;
• ключи шифрования;
• конкретный специалист или подрядчик.

Карта помогает определить реальный порядок. Приложение нельзя запустить раньше базы, а база может зависеть от хранилища и доменной службы.

Сценарии аварий

План должен учитывать несколько типов событий:

• поломка одного сервера;
• отказ дискового массива;
• недоступность офиса;
• длительное отключение электричества;
• отказ интернет-провайдера;
• ошибка администратора;
• повреждение базы;
• атака шифровальщика;
• компрометация облачного аккаунта;
• потеря ключевого сотрудника.

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

Роли

Укажите не только имена, но и роли:

• кто объявляет аварийный режим;
• кто координирует технические работы;
• кто связывается с провайдерами;
• кто принимает решение о переключении;
• кто информирует сотрудников;
• кто проверяет бизнес-функции;
• кто фиксирует события и расходы.

Должны быть заместители. План, завязанный на одного недоступного администратора, не является планом.

Контакты и доступы

В аварийном комплекте нужны:

• контакты провайдеров;
• номера договоров;
• данные оборудования;
• административные учётные записи;
• резервные коды;
• ключи шифрования;
• инструкции доступа к копиям;
• адреса резервных площадок;
• список лицензий.

Комплект хранится защищённо и доступен уполномоченным людям даже при недоступности основной сети.

Инфраструктура восстановления

Нужно заранее понимать, где запускать сервис:

• на запасном физическом сервере;
• на свободных ресурсах виртуальной платформы;
• у облачного провайдера;
• на резервной площадке;
• на временном оборудовании;
• в ограниченном аварийном режиме.

Подготовленный шаблон виртуальной машины и проверенная сеть экономят больше времени, чем инструкция «при необходимости арендовать сервер».

Пошаговые инструкции

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

1. Условия начала восстановления.
2. Нужные доступы и файлы.
3. Порядок развёртывания.
4. Настройки сети и DNS.
5. Загрузка данных.
6. Проверка целостности.
7. Тестовый вход.
8. Подключение пользователей.
9. Критерий завершения.
10. План возврата в основную среду.

Скриншоты интерфейса могут устареть. Команды, параметры и логика обычно полезнее.

Коммуникация

Во время аварии сотрудники должны знать:

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

Не обещайте точный срок до первичной диагностики. Лучше сообщать регулярные обновления, чем один оптимистичный прогноз.

Тренировки

План без проверки быстро устаревает. Варианты тренировок:

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

После тренировки фиксируют фактическое время, проблемы и изменения в инструкции.

Когда обновлять план

• после миграции;
• после замены оборудования;
• при смене подрядчика;
• после открытия офиса;
• при появлении нового критичного сервиса;
• после серьёзного инцидента;
• при изменении контактов и ролей;
• после обновления схемы резервного копирования.

Итог

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