Что такое тестирование восстановления? с примером

Автор: Томас Гамильтон Томас Гамильтон
Hours обновлено

⚡ Умное резюме

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

  • 🔁 Что это доказывает: OperaПосле катастрофы все продолжается, а не просто существует резервная копия файла.
  • 🧩 Где оно находится: Нефункциональный метод, выполняемый обученными тестировщиками на защищенных резервных данных.
  • 🇧🇷 Факторы, влияющие на время восстановления: Точки перезапуска, объем данных, а также навыки и инструменты группы восстановления.
  • 🔄 Форма процесса: Нормальная работа, катастрофа, сбой, восстановление, затем реконструкция до нормального состояния.
  • 💾 Варианты стратегии: Резервное копирование одного или нескольких сайтов, в режиме онлайн или офлайн, автоматическое или ручное.
  • ✅ После восстановления: Подсчитайте количество файлов относительно исходной папки, откройте несколько типов файлов и сравните каталоги с помощью системных утилит.
Читать

Что такое тестирование восстановления в программном обеспечении на примере?

Что такое тестирование восстановления?

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

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

Пример тестирования восстановления

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

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

Иллюстрация ниже наглядно демонстрирует ту же идею.

Концепция восстановительного тестирования, демонстрирующая сбой системы и последующее восстановление ее нормальной работы.

Время восстановления зависит от:

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

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

Жизненный цикл процесса восстановления

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

  1. Нормальная операция
  2. Возникновение катастрофы
  3. Срыв и провал операции
  4. Устранение последствий стихийного бедствия посредством процесса восстановления
  5. Восстановление всех процессов и информации, возвращение всей системы в нормальное рабочее состояние.

Приведенная ниже блок-схема показывает эти пять этапов в последовательности.

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

Давайте подробно обсудим эти пять шагов:

  1. Нормальная операция. Система, состоящая из аппаратного, программного и микропрограммного обеспечения, интегрированная для достижения общей цели, выполняет свою задачу без сбоев в течение установленного периода времени.
  2. Произошло стихийное бедствие. Сбои могут возникнуть из-за неисправности программного обеспечения, вызванной такими причинами, как сбой, инициированный вводом данных, сбой, вызванный аппаратным отказом, или повреждение в результате пожара, кражи или забастовки.
  3. Сбои и неудачи. Это самый болезненный этап, ведущий к убыткам в бизнесе, разрыву отношений, упущенным возможностям, потере рабочего времени и, неизбежно, к финансовым потерям и ущербу репутации. План восстановления после катастрофы сводит этот этап к минимуму.
  4. Устранение последствий стихийных бедствий. Если план резервного копирования и процессы снижения рисков уже разработаны, затраты времени и усилий на восстановление значительно сокращаются. Специально созданная команда, в которой заранее определена роль каждого члена, закрепляет ответственность и предотвращает длительный период сбоев.
  5. Реконструкция. Для восстановления всех папок вместе с конфигурационными файлами может потребоваться несколько сеансов работы. Для корректного восстановления необходима надлежащая документация и четко определенный процесс восстановления.

СТАТЬИ ПО ТЕМЕ

Стратегия восстановления

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

  1. Одна резервная копия или несколько.
  2. Несколько резервных копий в одном месте или в разных местах.
  3. Онлайн-резервное копирование или офлайн-резервное копирование
  4. Резервное копирование выполняется автоматически в соответствии с политикой или запускается вручную.
  5. Независимая команда реставраторов или команда разработчиков, выполняющая работы.

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

Как провести тестирование восстановления

Стратегия определена, следующий вопрос — как настроить сам тест. При проведении тестирования восстановления следует учитывать следующие моменты.

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

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

Процедура тестирования после реставрации

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

После восстановления папок и файлов следующие проверки подтверждают корректность их восстановления:

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

Часто задаваемые вопросы (FAQ)

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

RTO — это время, отведённое на восстановление работы сервиса; RPO — это допустимая потеря данных. Тест восстановления измеряет оба параметра: время восстановления для определения RTO и сравнение восстановленных данных с последним известным работоспособным состоянием для определения RPO.

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

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

Второй пилот GitHub Быстро разрабатывает вспомогательные функции для внедрения ошибок, скрипты восстановления и утверждения после восстановления. Тестировщик по-прежнему решает, какую именно ошибку следует инициировать и как выглядит корректное восстановленное состояние, поскольку оба варианта соответствуют бизнес-правилам.

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

Это приводит к реальным неудачам, поэтому пересекается с разрушающее испытаниеОднако цель состоит в восстановлении, а не в устранении неполадок. Запускайте его на изолированном тестовом стенде, а не на реальных производственных данных.

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

Подведем итог этой публикации следующим образом: