План восстановления часто выглядит убедительно, пока не нужно принять первое решение: кто объявляет инцидент, какой сервис возвращать первым, где лежит актуальная инструкция и кто подтверждает результат для бизнеса. Настольная проверка — это управляемый разговор по сценарию. Она не меняет рабочую систему и не заменяет техническое восстановление, но быстро показывает пробелы в ролях, зависимостях и коммуникации.
Выберите один понятный сценарий
Начинать лучше не с абстрактной «катастрофы», а с события, последствия которого понятны участникам: недоступен критичный сервер, потеряна важная папка, не запускается учётная система или отсутствует доступ к внешнему сервису. Сценарий должен быть достаточно реалистичным, но не должен раскрывать внутренние адреса, учётные данные или конфигурации.
До встречи формулируют границы: какие сервисы рассматриваются, что считается восстановлением, какое время недоступности допустимо и кто участвует. Если в проверке нет владельца бизнес-процесса, техническая команда рискует восстановить не тот результат, который нужен пользователям.
Пройдите путь от сигнала до приёмки
| Этап | Вопрос для проверки |
|---|---|
| Обнаружение | Кто замечает проблему и кому сообщает? |
| Решение | Кто определяет приоритет и допускает запуск восстановления? |
| Порядок | Какие сервисы, данные и зависимости нужны раньше других? |
| Возврат | Где инструкция, копия и ответственный за техническое действие? |
| Приёмка | Кто проверяет рабочий сценарий и фиксирует результат? |
Полезно идти по сценарию с вопросами «что происходит дальше?» и «на чём это решение основано?». Если ответ звучит как «кто-нибудь знает» или «инструкция где-то есть», это не готовность, а риск, который стоит записать.
Проверяйте порядок сервисов, а не список оборудования
Бизнесу редко нужен отдельный сервер или диск. Ему нужен работающий процесс: принять заказ, оформить документ, увидеть данные, связаться с клиентом. Поэтому порядок восстановления начинается с результата для пользователя и идёт назад к приложениям, данным, сети, доступу и копиям.
В процессе легко обнаружить скрытую зависимость: сервис запустится, но не сможет обратиться к данным; данные доступны, но никто не знает, кто подтвердит их актуальность; есть резервная копия, но не определено допустимое время её восстановления. Такие находки не являются провалом встречи — ради них её и проводят.
Фиксируйте доказательства, а не только обещания
По каждому важному ответу должно быть видно, на чём он основан: актуальная карта сервисов, согласованный список ролей, подтверждение наличия копии, результат предыдущей проверки, доступная инструкция или договорённый канал связи. Если доказательства нет, действие записывают как конкретную задачу с владельцем и сроком.
- обновить последовательность запуска и владельцев;
- подтвердить контакты и запасной канал связи;
- уточнить зависимость между сервисами и данными;
- назначить техническую проверку копии или инструкции в безопасной среде;
- согласовать, какой результат бизнес считает восстановлением.
Чего настольная проверка не доказывает
Разговор не подтверждает, что копия действительно читается, что площадки хватает по мощности или что фактическое время восстановления уложится в цель. Эти вопросы требуют отдельных технических проверок в согласованной среде. Настольный формат ценен другим: он позволяет сначала найти организационные и архитектурные пробелы, не добавляя риск остановки рабочим системам.
После встречи полезно выбрать один или два наиболее значимых пробела и довести их до проверяемого результата. Большой список без владельцев быстро превращается в ещё один документ, который не помогает во время сбоя.
Как сделать проверку регулярной
Сценарии меняют вместе с инфраструктурой и бизнесом: после важного изменения, появления нового сервиса, смены ответственных или заметного инцидента. Результат каждой встречи добавляют к рабочему регламенту: что подтвердили, что оказалось неясным и когда проверят исправление. Это дополняет, а не заменяет резервное копирование и технические тесты восстановления.
Итог: настольная проверка безопасно выявляет, готова ли компания принимать решения и возвращать сервисы в правильном порядке. Её результатом должны быть доказанные ответы и короткий план устранения пробелов, а не формальная отметка о проведённой встрече.