Базу восстановили, приложение запустилось, проверка доступности прошла. Можно заканчивать аварию? Допустим, это система сервисного центра. В ней снова видны заявки, но часть уже выданного оборудования числится в ремонте, а отправленные клиентам документы исчезли. Продолжать работу без сверки опасно: сотрудник не знает, каким записям доверять.
Disaster Recovery должен доводить компанию до возможности выполнять согласованные операции с понятными данными. Время запуска базы — лишь часть этого пути. Остальное легко выпадает из отчёта, если восстановление оценивает только команда инфраструктуры.
Два предела, которые нельзя назначить за бизнес
RTO — целевой предел времени от нарушения работы до восстановления согласованного сервиса. В него попадают обнаружение, решение о восстановлении, подготовка среды, возврат данных и необходимые проверки. Начать отсчёт с момента, когда инженер наконец запустил скрипт, удобно для красивого результата, но бесполезно для руководителя, чей процесс уже стоял.
RPO — допустимый разрыв во времени между событием и точкой данных, к которой нужно уметь восстановиться. Он описывает, насколько свежие изменения компания готова потерять или восстанавливать отдельно. Копирование по расписанию ещё не доказывает соблюдение этой цели: последняя копия может оказаться недоступной, повреждённой или содержать уже испорченные записи.
Эти величины нужны для конкретного процесса. Архив завершённых ремонтов и выдача оборудования клиентам могут иметь разные требования. Слова «вся система критична» мешают определить очередность восстановления и превращают любую второстепенную зависимость в обязательное условие запуска.
Различие целей и выбор стратегии разобраны в руководстве Google Cloud по планированию DR. Из него не следует универсальный норматив: допустимые сроки всё равно определяет компания.
Потерянный сервер и испорченные данные требуют разных действий
Если вышел из строя узел, пригодится исправная реплика. Если приложение ошибочно изменило записи, реплика может успеть повторить ошибку. Включить второй сервер в таком случае означает быстро вернуться к тем же неверным данным.
Для восстановления после логического повреждения требуется известная исправная точка, подходящие резервные копии и, где это поддерживается, журналы изменений для восстановления на нужный момент. Самую свежую точку нельзя автоматически считать лучшей: сначала надо выяснить, когда началась порча.
При этом вместе с ошибочными изменениями могли появиться полезные. Возврат всей базы в прошлое уберёт и их. В сервисном центре придётся выяснить, какие ремонты завершили, что уже выдали и какие документы отправили после выбранной точки. Способ сверки с другими системами и первичными документами — часть плана, а не просьба к поддержке «потом разобраться».
Из чего на самом деле состоит восстановимый комплект
Одного архива базы может не хватить. Нужны файлы, совместимая версия приложения, конфигурация, сведения о ключах шифрования и способ получить разрешённый доступ. Если копия сохранилась, а ключ потерян вместе с основной средой, наличие архива не возвращает рабочие данные.
Защиту копий стоит отделять от обычных полномочий приложения. Ошибка или компрометация рабочей учётной записи не должна автоматически давать возможность удалить все точки восстановления. Используют разделение доступа, защищённое хранение и подходящую политику удержания; конкретные механизмы зависят от платформы.
Полезна проверка в изолированной среде. Но там необходимо запретить случайные реальные отправки: восстановленный обработчик не должен заново разослать документы, запустить выплаты или передать старые задания партнёрам. Технически успешный запуск копии способен создать новую аварию, если не отделить испытание от внешних действий.
Какую часть работы возвращаем первой
Можно открыть историю ремонтов для чтения раньше, чем разрешить новые изменения. Можно возобновить приём обращений, но отдельно показать, что подтверждение выдачи ещё недоступно. Такой ограниченный режим нужно назвать и согласовать заранее: сотрудник не должен принять временный экран за полностью восстановленный сервис.
После загрузки данных проверяют связи между записями, доступы, документы и несколько типичных операций. Одной суммы строк недостаточно. Число заявок может совпасть, пока у части потеряна связь с клиентом или прикреплённым актом.
Очереди тоже требуют внимания. Сообщение могло сохраниться после подтверждённой внешней операции, а локальная отметка о выполнении — потеряться. Перед массовым запуском обработчиков нужно определить, как распознать дубликаты и какие действия сначала сверять с получателем.
Процедура, которую можно выполнить без её автора
У плана должны быть ответственный за запуск, заместитель и понятный способ принять решение, когда обычные средства связи недоступны. Инструкции и разрешённый аварийный доступ не должны существовать только внутри восстанавливаемой системы. При этом срочность не отменяет контроль полномочий и фиксацию выполненных действий.
На учении полезно дать процедуру сотруднику, который её не писал. Так обнаружатся незаписанные шаги: где взять нужную версию, какой сертификат заменить и кого попросить проверить результат. Записать найденное важнее, чем объявить испытание успешным благодаря личному вмешательству автора.
В рекомендациях Azure по DR-плану технические процедуры рассматриваются вместе с ответственностью, последовательностью и коммуникацией. Для небольшого продукта это может быть короткая инструкция, а не отдельный бюрократический проект.
Что должно остаться после учения
Нужен результат с отметками времени: когда работа нарушилась, когда приняли решение, когда данные стали доступны и когда ответственный за процесс подтвердил нужные операции. Отдельно фиксируют выбранную точку восстановления, обнаруженные расхождения и работу, которую пришлось сделать вручную.
Если команда уложилась в срок только потому, что заранее подготовила скрытые от плана ресурсы, это ограничение результата. Если восстановление удалось, но система осталась без резервирования, нужно восстановить и защиту. Иначе следующую неисправность придётся встречать уже без запаса.
Для приёмки достаточно начать с одного важного процесса и пройти его до конца. Сотрудник должен не просто увидеть знакомый интерфейс, а безопасно завершить работу и объяснить судьбу операций, попавших в разрыв. Выбор между копиями, резервной средой и несколькими активными площадками имеет смысл после такой проверки; варианты сопоставляет AWS Well-Architected.