Disaster Recovery: восстановление бизнеса после IT-сбоя

Что такое Disaster Recovery простыми словами

Disaster Recovery, или DR, — заранее подготовленный порядок возвращения компании к работе после серьёзного сбоя в IT. По-русски это можно назвать планом восстановления после аварии. Он отвечает на обычные вопросы: что случилось, кому позвонить, где взять рабочие данные, на чём запустить программы и как понять, что сотрудники снова могут работать.

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

Представьте обычное начало рабочего дня

Менеджер открывает компьютер, чтобы посмотреть заказы, а программа не запускается. Бухгалтеру нужны документы, но общая папка недоступна. Клиенты звонят, сотрудники ждут, руководитель пытается найти человека, который знает пароль от сервера. Одновременно выясняется, что резервные копии где-то есть, но никто не помнит, когда их проверяли.

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

Для чего это нужно бизнесу

• Быстрее принимать решения. Понятно, кто руководит восстановлением и какие действия уже согласованы.
• Сначала возвращать самое важное. Приём заказов или отгрузка могут быть важнее архива старых фотографий.
• Понимать риск потери данных. Компания заранее знает, какие изменения может потерять и насколько свежая копия ей нужна.
• Снижать зависимость от одного человека. Инструкции и нужные доступы находятся у компании.
• Осмысленно выбирать расходы. Можно сравнить стоимость защиты с тем, насколько долго бизнес способен ждать восстановления.

Какие ситуации стоит предусмотреть

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

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

Резервная копия и план восстановления решают разные задачи

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

Два вопроса, которые определяют весь план

Сколько времени компания может ждать?

Это допустимая длительность остановки. Одному процессу нужен быстрый возврат, другой может подождать до следующего дня. Специалисты называют этот ориентир RTO. Мы сначала обсуждаем его человеческим языком: «Как долго сотрудники могут работать без этой системы?»

За какой период можно потерять изменения?

Это допустимый промежуток между последними сохранёнными данными и моментом сбоя. Его называют RPO. Если копия сделана вчера вечером, сегодняшние изменения могут в неё не попасть. Поэтому задаём вопрос: «Какой объём работы придётся повторить и допустимо ли это для бизнеса?»

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

Что восстанавливать первым

Вместе с сотрудниками составляем простой список зависимостей. Чтобы принять заказ, могут понадобиться программа, база, вход пользователя и связь с сервером. Возвращать только один пункт из этого списка недостаточно.

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

Что входит в понятный план

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

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

Как мы готовим восстановление

1. Разбираем работу компании. Спрашиваем, без чего останавливаются продажи, обслуживание или отгрузка.
2. Изучаем текущую инфраструктуру. Проверяем, что уже есть: копии, доступы, запасные ресурсы и инструкции.
3. Выбираем разумный вариант. Сопоставляем нужную скорость возврата, возможную потерю данных и бюджет.
4. Описываем и настраиваем. Фиксируем действия, ответственных и согласованную техническую схему.
5. Проводим тренировку. Проверяем выбранный сценарий в подготовленной среде и записываем результат.
6. Передаём документы. Компания получает план, сведения о проверке и список оставшихся ограничений.

Зачем нужна тренировка

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

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

Можно ли начать без второго офиса и дорогого сервера

Да. Начать можно с одного важного процесса, доступов компании, понятной инструкции и пробного восстановления выбранной системы. Иногда уже этого достаточно, чтобы увидеть основные пробелы и принять решение о следующем этапе.

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

Что получает руководитель

Понятный ответ на вопрос «Что мы делаем, если завтра это перестанет работать?». К нему прилагаются список приоритетов, ответственные, порядок действий и результаты проведённой проверки. По ним можно обсуждать бюджет и дальнейшие улучшения.

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

Что можно подготовить до первого разговора

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

Оценить стоимость времени при простое · Скачать чек-лист и шаблон плана

Подробнее о подходе

Основные понятия и необходимость проверок описаны в материалах AWS о Disaster Recovery ↗ и NIST о планировании восстановления ↗. Реализация подбирается под оборудование и процессы заказчика; использовать облако конкретного поставщика не обязательно.

Нужны только резервные копии?

Настройка резервного копирования и пробное восстановление — отдельная услуга. План DR дополнительно охватывает зависимости сервисов, приоритеты и порядок возобновления работы.

Обсудить план восстановления

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