Тест аварийного восстановления отвечает на практический вопрос: сможет ли команда восстановить необходимый бизнес-процесс в согласованных условиях? Само наличие резервной копии, документа или резервной площадки этого не подтверждает. Команда должна выполнить выбранный сценарий восстановления, проверить данные и зависимости, измерить результат и устранить выявленные недостатки.
Исходным документом здесь является текущий план восстановления. Тестирование не заменяет его разработку, оценку всех рисков для компании или планирование непрерывности бизнеса. Если неизвестны такие параметры, как система, владелец, приоритет или критерий готовности, сначала уточните эти данные. В противном случае успешный запуск сервера может легко быть ошибочно истолкован как восстановление всего процесса.
Определите вопрос, на который должно ответить тестирование
Выберите одно четкое предположение. Например: возможно ли восстановить обработку заказов, если основной объем хранения недоступен? Укажите, какая часть среды считается потерянной, и какие стандартные инструменты нельзя использовать. Не позволяйте команде полагаться на компонент, который предназначен для тестирования, без надлежащего контроля.
Используйте заранее определенные цели RPO и RTO в качестве входных данных. Запишите допустимый возраст рабочей точки восстановления и максимальное время, необходимое для восстановления операции. Уточните, какое событие запускает отсчет времени и что считается завершением. Копирование файлов, запуск виртуальной машины и подтверждение бизнес-операции измеряют различные этапы.
Определите минимальный рабочий результат совместно с владельцем процесса. Для приложения это может включать вход пользователя, доступ к необходимым данным и выполнение согласованной операции. Тестирование должно охватывать все необходимые зависимости: аутентификацию, сеть, разрешения, базы данных, интеграции и внешние сервисы. Конкретный набор зависит от системы.
Выберите тип тестирования и пределы его выводов
Сила вывода зависит от фактически выполненных действий
|
Тип |
Что проверяется |
Что еще нельзя сделать на основании |
|---|---|---|
|
Проведение сценария с участием участников |
Принятие решений, роли, последовательность и доступность инструкций |
Данные фактически были восстановлены в установленный срок |
|
Восстановление отдельного компонента |
Получение и использование выбранной резервной копии, а также запуск компонента |
Что весь связанный процесс готов к работе |
|
Восстановление связанного сервиса в тестовой среде |
Зависимости и бизнес-процессы в рамках определенного объема |
Что производственная нагрузка и все реальные ограничения были воспроизведены |
|
Переключение на резервную среду восстановления |
Согласованный путь переключения, доступ и обслуживание операций |
Что обратное переключение и сверка новых данных также были проверены |
|
Комплексное тестирование |
Координация работы команды и несколько взаимосвязанных сценариев |
Проверка на возможность возникновения любых нештатных ситуаций |
Начать с уровня, который команда готова освоить. Прохождение сценария помогает выявить неясные полномочия и недоступные контакты. Это не заменяет техническое восстановление. В более сложном сценарии необходимо различать обсужденные действия и фактически выполненные. Отчет должен отражать эти результаты.
Подготовьте безопасные условия и участников
Согласуйте действия, процедуры остановки и возврата
Назначьте руководителя тестирования, исполнителей, наблюдателя, ответственного за приемку и человека, имеющего право остановить тестирование. Укажите заместителей и подрядчиков, если это необходимо. Заранее проверьте их доступ и готовность. Согласуйте временной интервал и сообщите всем, кто может быть затронут.
Запишите условия немедленной остановки, допустимый уровень воздействия и процедуру возврата. Убедитесь, что команда может восстановить безопасное состояние, если тестирование не удастся. Не выключайте производственные системы только ради реалистичности без предварительного разрешения и подготовки. Если необходимо, сначала практикуйте опасные действия в ограниченной среде.
Определите, где взаимодействуют тестовая и производственная среды. Изолируйте ненужные внешние соединения и действия, которые могут отправлять реальные электронные письма, платежи или команды интеграции. Используйте данные в соответствии с текущей политикой доступа. Секреты и конфиденциальные данные производственной среды не должны попадать в открытый отчет о тестировании.
Проверьте доступные ресурсы и пути доступа
- Определите версии инструкций, конфигурацию системы и карту необходимых зависимостей.
- Подтвердите подходящую точку восстановления и способ ее получения.
- Проверьте ключи, каталог, программное обеспечение для восстановления и необходимые разрешения.
- Уточните возможности среды восстановления, доступное пространство, лимиты и сетевые ограничения.
- Обеспечьте доступ к инструкциям и контактам, когда основной сайт недоступен.
- Согласуйте канал связи для резервного копирования и способ связи с внешними участниками.
- Подготовьте журнал времени, доказательств, решений и отклонений.
AWS особенно подчеркивает изменения в конфигурации среды восстановления, лимитах и возможностях. Возможности, достаточные для предыдущего теста, могут оказаться недостаточными после увеличения нагрузки. Поэтому повторный тест использует текущую среду и известные различия, а не только старый успешный отчет.
Выполните сценарий и разделите факты от предположений
Перед началом, зафиксируйте начальное состояние, выбранную резервную копию, участников и ограничения. Дайте согласованный сигнал о начале. Следуйте процедуре последовательно, фиксируя начало и окончание значимых этапов. Если инструкции неполные, запишите необходимую ручную инструкцию и укажите, кто ее утвердил. Не переписывайте историю действий впоследствии.
Зафиксируйте отклонения от сценария. Например, команда может получить ключ через обычный рабочий канал, который должен был быть недоступен. Это действие может помочь завершить упражнение, но не подтверждает первоначальную гипотезу. Сохраните ограничение и проведите отдельный тест непредсказанного пути.
После технической подготовки, владелец процесса выполняет согласованный приемный контроль. Подтвердите полноту и актуальность данных, необходимые разрешения, интеграции и бизнес-операции. Если проводится тестирование нагрузки, укажите ее объем и условия. Небольшой тест не оправдывает утверждение о готовности к любой производственной нагрузке.
Оцените фактический результат по сравнению с целями
Для оценки потерь данных сравните время имитированного сбоя с последним доступным моментом, который был успешно восстановлен. Важно, чтобы был успешно использован конкретный момент, а не время последнего успешно завершенного задания. Если данные повреждены, найдите более ранний доступный состояние и запишите новую потерю.
Используйте согласованные начало и конец измерения для оценки продолжительности. Также сохраните промежуточные этапы: обнаружение, принятие решения о восстановлении, подготовка среды, извлечение данных, запуск и прием в эксплуатацию. Это показывает, где произошла задержка. Не называйте целевое время восстановления фактическим временем или исключите неудобный этап без объяснения.
Оцените результат по отношению ко всему набору критериев. Достижение целевого времени восстановления недостаточно, если проверка данных не удалась или важная функция недоступна. Если некоторые условия были смоделированы, укажите, какие выводы подтверждаются фактическим выполнением, а какие остаются предположениями.
Проверьте завершение и возврат
Для сценария переключения на резервную среду заранее решите, будете ли проверять обратное переключение. Для новых данных, созданных в резервной среде, нужна согласованная процедура переноса и сверки. Нельзя просто запустить прежний рабочий экземпляр системы, не устранив расхождения. Возврат подтверждает уполномоченный ответственный, а не только администратор инфраструктуры.
После завершения теста отключите ненужные тестовые соединения, удалите или сохраните тестовые данные в соответствии с согласованной политикой и верните временные разрешения в нормальное состояние. Убедитесь, что резервное копирование и мониторинг возобновились там, где настройки временно изменились. Также необходимо подтверждение завершения теста.
Подготовьте отчет с проверяемыми доказательствами
Скопируйте форму и заполните ее фактическими результатами. Если один сценарий тестирует несколько систем, используйте отдельные строки результатов или четко связанные приложения. Не заменяйте неизвестное значение на «успешно». Поля с неполной проверкой требуют владельца для дальнейших действий.
Отчет о тестировании восстановления после аварии
|
Поле отчета |
Что записывать |
|---|---|
|
Сценарий и границы |
[Неисправные компоненты, недоступные инструменты, работа в тестовой среде] |
|
Конфигурация и версия |
[Система, зависимости, инструкции, дата и участники] |
|
Цели и принятие |
[Согласованные показатели RPO, RTO, время начала и критерии готовности] |
|
Тип и безопасность |
[Выполняемые действия, симуляции, авторизация, остановка и возврат] |
|
Точка восстановления |
[Идентификатор и временная метка восстановленных данных] |
|
Сроки |
[Начало, ключевые этапы и подтверждение готовности к работе] |
|
Ожидаемые и фактические |
[Целевые и фактические значения, результат тестирования] |
|
Доказательства |
[Журналы, результаты тестирования и защищенные ссылки] |
|
Ограничения |
[Симуляции, различия в среде, не протестированные зависимости] |
|
Отклонения и исправления |
[Ошибка, влияние, ответственный, срок и необходимость повторного тестирования] |
|
Завершение |
[Возврат, сверка данных, удаление временного доступа и подтверждение] |
|
Принятие |
[Технический владелец, владелец процесса и решение о результате] |
Устранение ошибок и планирование следующего теста
Проанализируйте результаты вместе с участниками. Разделите проблемы, связанные с нехваткой ресурсов, от проблем, вызванных неправильными инструкциями, доступом и координацией. Назначьте ответственного, установите сроки и четкие критерии исправления для каждой значительной неисправности. Обновите процедуры, контакты и конфигурацию, а затем повторно протестируйте измененный путь. Заметка, содержащая слово «учитывается», не закрывает ошибку без доказательств.
Покажите руководству готовность к выполнению задач в рамках протестированного объема: какие операции подтверждены, где были допущены ошибки и что еще не было протестировано. Автоматизация может собирать временные данные, выполнять повторяющиеся шаги и вести журнал. Также необходимо проверить сценарии, полномочия и результаты; они сами по себе не гарантируют успех.
Критичность, изменения, предыдущие ошибки и применимые требования определяют частоту тестирования. Также необходимо планировать тестирование после значительных изменений в системе, на сайте, в данных, команде или у поставщика. Универсальное правило, согласно которому достаточно тестировать раз в год, игнорирует эти различия. Проверьте, не изменились ли зависимости между запланированными тестами.
Нужно провести или запустить тест восстановления? Обратитесь в DKs Enterprises. резервное копирование и восстановление после аварий. Предоставьте описание ситуации, согласованные критерии и предыдущие результаты, чтобы обсудить объем работ.
