После серьезного сбоя хочется восстановить самый заметный сервис первым: 1С, файловый сервер, почту, телефонию или рабочие места руководителей. Иногда это правильно, но часто такой подход тратит время впустую. Приложение может подняться, но не сможет работать без сети, доступа, имени сервера, базы, хранилища, лицензий или актуальных данных.
Правильный порядок восстановления строится не по громкости жалоб, а по зависимостям и влиянию на бизнес. Сначала возвращают основу, затем доступ и данные, затем приложения, затем пользовательские сценарии и контроль качества.
Сначала остановить расширение ущерба
Восстановление нельзя начинать, пока не понятно, продолжается ли авария. Если причина сбоя активна, восстановленные системы могут снова выйти из строя или получить поврежденные данные. Поэтому первый этап - стабилизация: понять границы инцидента, отделить неисправные узлы, сохранить факты, назначить владельца координации и запретить хаотичные параллельные действия.
На этом этапе не нужно искать идеальное объяснение. Достаточно понять, какие системы затронуты, какие данные под риском, какие действия могут ухудшить ситуацию и кто принимает решения о восстановлении, ожидании или отключении части сервисов.
Слой 1: питание, связь и базовая инфраструктура
Если не работают питание, сеть, интернет-канал, коммутация, маршрутизация, хранилище или виртуализация, прикладные сервисы восстанавливать рано. Даже успешный запуск приложения будет нестабильным, если базовый слой деградирует.
Проверяют доступность площадки, состояние сетевого ядра, гипервизоров, хранилищ, резервных каналов, систем времени и DNS там, где они нужны для остальных сервисов. Цель не в том, чтобы восстановить все идеально, а в том, чтобы создать минимально надежную основу для следующих шагов.
Слой 2: идентификация и доступ
Многие сервисы зависят от учетных записей, групп, политик, сертификатов, VPN, каталогов пользователей или облачной идентификации. Если слой доступа работает частично, пользователи увидят хаотичные ошибки: приложение открывается у одних, не открывается у других, права выглядят случайными, сервисы не могут подключиться друг к другу.
Перед запуском бизнес-приложений нужно убедиться, что пользователи и сервисные учетные записи могут проходить аутентификацию, базовые группы применяются корректно, критичные сертификаты или токены действительны, а удаленный доступ не открывает лишние риски.
Слой 3: данные и восстановимость
Данные восстанавливают с учетом RPO: какую потерю изменений бизнес считает допустимой. Для разных сервисов допустимая точка восстановления может отличаться. Файловая папка, база продаж, бухгалтерская база и архив видеонаблюдения имеют разную критичность и разные последствия потери.
На этом этапе важно не только вернуть файлы или базу, но и проверить целостность, дату копии, полноту набора данных и связь с приложениями. Если есть несколько копий, выбирают не самую новую автоматически, а ту, которая не содержит известного повреждения и подходит под бизнес-решение.
Слой 4: приложения и интеграции
Когда инфраструктура, доступ и данные готовы, можно поднимать приложения. Но приложение редко работает одно: у него есть база, файловые хранилища, почтовые уведомления, обмены, печать, внешние API, лицензирование, фоновые задачи и расписания.
Поэтому проверка приложения должна включать не только вход в интерфейс. Нужны типовые операции: открыть документ, создать запись, провести обмен, сформировать отчет, отправить уведомление, выполнить фоновую задачу, убедиться, что права соответствуют ожиданиям.
Слой 5: рабочие места и пользовательская приемка
Рабочие места восстанавливают после того, как понятно, к чему они должны подключаться. Иначе инженеры будут чинить клиентские симптомы, хотя причина все еще на сервере или в сети. Приоритет получают роли, которые нужны для запуска критичных процессов: бухгалтерия, продажи, склад, руководство, диспетчерская или другое ключевое подразделение.
Пользовательская приемка должна быть конкретной. Не "вроде работает", а список действий: открыть нужную систему, найти свежие данные, выполнить типовую операцию, распечатать или отправить результат, подтвердить доступность из нужного офиса или удаленного подключения.
Как принимать решения при нехватке времени
Иногда нельзя восстановить все сразу. Тогда нужен простой критерий: какой минимальный набор сервисов позволяет бизнесу продолжить критичную работу, какие данные можно временно обрабатывать вручную, какие сервисы можно отложить без существенного ущерба, а какие решения требуют руководителя.
Решение о временном режиме должно быть явным. Если компания работает на восстановленной копии с потерей части данных, все участники должны понимать, какие операции разрешены, какие запрещены и как потом будет выполняться сверка.
Минимальная таблица очередности
| Этап | Что проверяется | Когда переходить дальше |
|---|---|---|
| Стабилизация | Границы сбоя, активная причина, владелец инцидента | Понятно, что восстановление не ухудшит состояние |
| Инфраструктура | Питание, сеть, хранилище, виртуализация, DNS | Есть надежная основа для сервисов |
| Доступ | Учетные записи, права, сертификаты, удаленный доступ | Пользователи и сервисы могут авторизоваться |
| Данные | Точка восстановления, целостность, полнота | Данные пригодны для приложения и бизнеса |
| Приложения | Запуск, интеграции, фоновые задачи | Типовые операции проходят без критичных ошибок |
| Пользователи | Рабочие сценарии, офисы, удаленный доступ | Владельцы процессов приняли результат |
Что подготовить заранее
Порядок восстановления нельзя качественно придумать в момент аварии. Его готовят заранее как часть резервного копирования и восстановления: список сервисов, зависимости, RTO/RPO, ответственные, способы связи, проверки после восстановления и условия перехода на временный режим.
После каждого серьезного сбоя этот порядок нужно обновлять. Если выяснилось, что один сервис зависит от незадокументированного сервера, что backup был неполным или что никто не мог принять результат ночью, это не отдельные неприятности. Это факты, которые должны попасть в регламент восстановления до следующей аварии.