План восстановления ИТ-сервиса описывает требуемые сроки, состояние данных, зависимости и действия участников. Проверка показывает, при каких условиях эти требования выполняются и что необходимо доработать.
В статье рассматриваются показатели RTO и RPO, пример восстановления и форма протокола испытания. Пример и рабочая форма предназначены для обсуждения конкретного сервиса, а не задают универсальные требования.
Цели RTO и RPO
RTO — Recovery Time Objective — целевой срок восстановления, используемый при планировании. В определении NIST речь идёт о времени нахождения компонентов системы в фазе восстановления до негативного влияния на деятельность организации. Для конкретного сервиса нужно явно установить начало отсчёта и состояние, которое считается восстановлением. [1]
RPO — Recovery Point Objective — требуемая точка во времени, до которой необходимо восстановить данные после сбоя. В рабочих требованиях её часто выражают допустимым интервалом потери последних изменений: например, не более 15 минут данных. [2]
Важное различие: RTO и RPO задают цели, а испытание показывает фактическое время восстановления и фактический разрыв в восстановленных данных. Не следует объявлять требование выполненным только потому, что оно записано в документе.
Критерии восстановления сервиса
Запущенный сервер, доступная страница авторизации и завершённая загрузка базы могут быть промежуточными результатами. Для проверки предлагаем заранее определить минимальный рабочий сценарий пользователя.
Например: сотрудник входит под своей ролью, открывает нужную запись, создаёт тестовую операцию и получает подтверждение её передачи в связанную систему. Восстановление считается завершённым, когда этот согласованный сценарий выполнен с нужной производительностью и ограничениями доступа.
Необязательно сразу возвращать абсолютно все функции. Можно определить допустимый ограниченный режим. Но его состав, срок использования и способ последующей обработки отложенных действий должны быть понятны владельцу сервиса.
Резервирование, резервные копии и план восстановления
Резервный экземпляр может помочь при отказе основного компонента. Копия данных может дать возможность вернуться к сохранённому состоянию. План восстановления связывает данные, конфигурацию, инфраструктуру и действия людей в последовательность возврата сервиса.
В руководстве AWS по аварийному восстановлению выбор стратегии связывается с целями, стоимостью и сложностью. Там же отдельно отмечено: репликация сама по себе не защищает от повреждения или уничтожения данных без возможности вернуться к прежней точке. Это принцип архитектурного выбора, а не рекомендация обязательно использовать облако или конкретный продукт. [3]
Поэтому в собственной проверке предлагаем отдельно ответить: от каких сценариев защищает резервирование, какое состояние сохраняют копии и как именно из него возвращается рабочий процесс.
Учебный пример восстановления
Все значения ниже условные. Это не норматив, не рекомендуемый уровень для любой системы и не результат проекта AI Code.
Для выбранного сервиса согласованы RTO 45 минут и RPO 15 минут. В этом примере отсчёт времени начинается с фактического прекращения доступности сервиса.
| Событие | Время |
|---|---|
| Последняя согласованная точка данных, доступная для восстановления | 09:55 |
| Сервис перестал работать | 10:00 |
| Инцидент обнаружен | 10:04 |
| Начато восстановление | 10:08 |
| Запущено приложение | 10:18 |
| Восстановлена интеграция с зависимой системой | 10:40 |
| Пройден согласованный пользовательский сценарий | 10:48 |
Фактическое восстановление заняло 48 минут от начала сбоя: цель RTO превышена на 3 минуты. Запуск приложения в 10:18 не означает, что сервис восстановился за 18 минут, потому что согласованный процесс ещё не работал.
Разрыв в данных составил 5 минут — от 09:55 до 10:00. При условии подтверждённой согласованности восстановленного состояния цель RPO выполнена.
Этот результат полезнее общей отметки «восстановление успешно». Он показывает конкретный разрыв: зависимая интеграция и заключительная проверка должны быть учтены в плане и, возможно, улучшены.
Зависимости сервиса
Для выбранного сценария предлагаем составить короткую карту необходимых компонентов: идентификация и доступ, разрешение имён и связь, конфигурация приложения, данные, интеграции и средства наблюдения.
Для каждого компонента задайте вопросы: откуда он восстанавливается, кто может выполнить действие, какие другие компоненты нужны раньше и доступны ли инструкции при отказе основной среды? Отдельно проверьте доступ к ключам и секретам через предусмотренный защищённый механизм — не переносите их в открытый протокол испытания.
Восстанавливаемая точка данных должна относиться к согласованному состоянию процесса. Дата файла резервной копии сама по себе не доказывает, что связанные системы смогут продолжить работу без потерь или повторов операций.
Что включить в протокол испытания
Ниже — предлагаемая рабочая форма. Её состав можно уточнять под выбранный сервис и сценарий.
| Поле | Что зафиксировать |
|---|---|
| Сервис и владелец | Что восстанавливаем и кто принимает результат |
| Сценарий | Какой отказ или потеря данных моделируется |
| Границы испытания | Какие зависимости включены, а какие не проверяются |
| Цели | RTO, RPO и условия их применения |
| Начало отсчёта | Конкретное событие и время |
| Точка данных | Последнее проверенное согласованное состояние |
| Ход восстановления | Ключевые действия и временные отметки |
| Пользовательская проверка | Какой сквозной сценарий выполнен |
| Фактический результат | Время восстановления, разрыв данных, ограничения |
| Отклонения | Где цель не достигнута и почему |
| Следующие действия | Исправления, владельцы и повторная проверка |
Успешное испытание относится к проверенному сценарию и условиям. Не распространяйте вывод автоматически на другие объёмы данных, площадки или сочетания отказов.
Практика регулярных проверок восстановления, включая проверки после существенных изменений, отражена в разделе управления отказами AWS Well-Architected Framework. При этом конкретную периодичность и безопасный способ испытаний организация выбирает для своей среды. [4]
Что меняется, когда в сервисе появляется ИИ
Для AI- или RAG-сервиса предлагаем добавить в карту восстановления не только приложение и базу, но и исходные документы, правила доступа, конфигурацию обработки, версии используемых компонентов и зависимости от внешнего провайдера.
Производный поисковый индекс можно считать восстанавливаемым из источников только после проверки такой возможности и времени перестроения. Если оно превышает согласованный срок, архитектуре нужен другой способ восстановления или заранее определённый ограниченный режим.
Отдельно проверьте, что после восстановления сохраняются правильные права доступа. Возврат выдачи ответов без восстановления разрешений на источники нельзя принимать как полноценное восстановление защищённого сервиса.
Для критичного процесса полезно заранее определить, что происходит без модели: доступен ли обычный поиск, сохраняются ли задачи в очереди и кто принимает работу вручную. Это проектные решения конкретной системы, а не универсальный рецепт.
Результаты проверки
Протокол должен позволять установить, какой сервис восстанавливался, из какого состояния, при каком сценарии и с каким результатом.
В протоколе указываются цели, границы испытания, измерения и выявленные ограничения. При отсутствии результатов проверки можно подготовить согласованный сценарий испытания и определить необходимые условия его проведения.
По теме: Архитектура и инфраструктура · ИТ-стратегия и архитектура · Как составить план модернизации.
Обсудить инфраструктуру и восстановление сервисов.
Источники
- NIST CSRC — Recovery Time Objective. Определение термина; применять с учётом контекста конкретной системы.
- NIST CSRC — Recovery Point Objective. Определение требуемой точки восстановления данных.
- AWS Well-Architected, Reliability Pillar — Use defined recovery strategies to meet the recovery objectives. Компромиссы стратегий и ограничения репликации.
- AWS Well-Architected Framework — Failure management, редакция 27.06.2024. Практика испытаний и проверки восстановления. Ссылка на явно указанную редакцию, не утверждение, что она последняя.
Числовой пример, форма протокола и последовательность вопросов — авторские иллюстрации для этой статьи, а не выдержки из нормативного документа.