Что такое тестирование надёжности?

Тестирование надёжности (reliability testing) оценивает, выполняет ли система свою функцию стабильно в течение заданного периода при определённых условиях. Система не является по-настоящему надёжной только потому, что проходит функциональные тесты — она должна продолжать работать корректно с течением времени, при устойчивой нагрузке и в изменяющихся условиях.

Рассмотрим приложение онлайн-банкинга. Оно может пройти все функциональные тесты за 30-минутную сессию. Но что произойдёт, когда тысячи пользователей будут взаимодействовать с ним непрерывно в течение 72 часов? Тестирование надёжности отвечает на этот вопрос.

Ключевые метрики надёжности

Две метрики являются фундаментальными в тестировании надёжности:

MTBF (Mean Time Between Failures — среднее время между отказами) измеряет среднее время работы системы до возникновения сбоя. Например, если сервер испытал 3 отказа за 300 часов работы, MTBF составляет 100 часов. Более высокий MTBF означает большую надёжность.

MTTR (Mean Time To Repair/Recover — среднее время восстановления) измеряет среднее время, необходимое для возврата системы в рабочее состояние после сбоя. Если те 3 отказа заняли 2, 4 и 3 часа на исправление соответственно, MTTR составляет 3 часа. Более низкий MTTR означает лучшую восстанавливаемость.

Доступность (Availability) объединяет обе метрики: Доступность = MTBF / (MTBF + MTTR). На примере выше: 100 / (100 + 3) = 97.1%. Это процент времени, когда система работоспособна.

МетрикаФормулаЦельПример
MTBFОбщее время работы / Количество отказовМаксимизировать100 часов
MTTRОбщее время ремонта / Количество отказовМинимизировать3 часа
ДоступностьMTBF / (MTBF + MTTR)Максимизировать97.1%

Виды тестов надёжности

Тестирование на выносливость (endurance testing) запускает систему под ожидаемой нагрузкой на продолжительный период (24-72 часа) для выявления утечек памяти, исчерпания ресурсов и паттернов деградации.

Стресс-тестирование надёжности совмещает стресс-тестирование с измерением надёжности — как меняется частота отказов, когда система работает на 80-90% мощности длительное время?

Тестирование операционного профиля имитирует реальное распределение пользовательских операций. Если 60% пользователей просматривают каталог, 30% добавляют в корзину и 10% оформляют заказ, тест воспроизводит эти пропорции.

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

Тестирование восстановления (recovery testing) проверяет, что система может быть восстановлена в рабочее состояние после сбоя. Если тестирование надёжности фокусируется на предотвращении и измерении отказов, то тестирование восстановления — на том, что происходит после отказа.

Любая система рано или поздно даст сбой. Вопрос не в том, произойдёт ли это, а в том, насколько элегантно система справится.

Типичные сценарии отказов

Краш приложения. Процесс сервера неожиданно завершается. Может ли приложение перезапуститься автоматически? Сохраняются ли текущие транзакции или корректно откатываются?

Отключение электропитания. Сервер теряет питание. Когда питание возвращается, запускается ли система? Целы ли данные? Возобновляет ли она работу с того места, где остановилась?

Разрыв сетевого соединения. Связь между сервисами прерывается. Выполняют ли сервисы повторные попытки? Деградируют ли они корректно? Что происходит с данными в процессе передачи?

Повреждение базы данных. Сектор диска выходит из строя или операция записи прерывается. Может ли база данных восстановиться из журнала транзакций? Консистентны ли данные?

Отказ оборудования. Физический компонент (диск, память, сетевая карта) выходит из строя. Обнаруживает ли система это и реагирует ли должным образом?

graph TD F[Произошёл сбой] --> D{Обнаружен?} D -->|Автоматически| R[Запуск восстановления] D -->|Не обнаружен| M[Ручное вмешательство] R --> A{Автовосстановление?} A -->|Да| AR[Автоматический перезапуск/Failover] A -->|Нет| MR[Ручная процедура] AR --> V[Проверка целостности данных] MR --> V M --> MR V --> S{Система работает?} S -->|Да| O[Возврат в работу] S -->|Нет| E[Эскалация / План DR]

Тестирование Failover

Тестирование failover проверяет, что при отказе основного компонента трафик или обработка автоматически переключается на резервный (избыточный) компонент. Это критически важно для систем высокой доступности.

Активно-пассивный failover: резервный сервер ожидает в неактивном состоянии до отказа основного. Тест проверяет, что резервный берёт управление в рамках заданного RTO (Recovery Time Objective).

Активно-активный failover: несколько серверов разделяют нагрузку. Когда один отказывает, остальные принимают его трафик. Тест проверяет, что запросы не теряются и производительность остаётся приемлемой.

Что измерять при тестировании failover:

  • Время переключения — Как быстро резервный сервер берёт управление?
  • Потеря данных — Были ли потеряны транзакции при переключении?
  • Влияние на пользователя — Пользователи увидели ошибки или переход был прозрачным?
  • Failback — Когда основной восстанавливается, корректно ли возвращается трафик?

Тестирование Backup и Restore

Наличие бэкапов — недостаточно, их нужно тестировать. Непроверенный бэкап — это не бэкап, а надежда.

Тестирование backup и restore проверяет:

  • Бэкапы завершаются успешно в рамках окна резервного копирования
  • Данные бэкапа не повреждены (проверки целостности)
  • Восстановление работает в целевом окружении
  • Восстановление завершается в рамках RTO
  • Восстановленные данные полны и соответствуют RPO
ТерминОпределениеПример
RTO (Recovery Time Objective)Максимально допустимое время простоя4 часа
RPO (Recovery Point Objective)Максимально допустимая потеря данных (по времени)1 час

Если ваш RPO — 1 час, вы должны делать бэкап как минимум каждый час. Если ваш RTO — 4 часа, вы должны уметь восстановиться из бэкапа за 4 часа.

Тестирование аварийного восстановления (Disaster Recovery)

Тестирование Disaster Recovery (DR) выходит за рамки отказов отдельных компонентов и моделирует катастрофические сценарии: полные отказы дата-центров, региональные сбои или одновременные отказы нескольких компонентов.

DR-тесты обычно проводятся ежеквартально или ежегодно и включают:

  • Активацию плана DR с определёнными ролями и процедурами
  • Переключение операций на DR-площадку
  • Выполнение критических операций с DR-площадки
  • Измерение соответствия RTO и RPO
  • Переключение обратно на основную площадку

Типы DR-тестов (от наименее к наиболее разрушительным):

  1. Настольное упражнение (tabletop) — устный разбор плана DR без реальных действий
  2. Симуляция — моделирование сценария катастрофы без выключения систем
  3. Параллельный тест — запуск DR-площадки при работающей основной
  4. Полное прерывание — реальное выключение основной площадки и работа с DR

Упражнение: Спроектируйте сценарии тестирования надёжности

Вы — QA Lead критической системы записи на приём к врачу. Характеристики системы:

  • Веб-приложение, обслуживающее 50 000 пользователей ежедневно
  • База данных PostgreSQL с записями пациентов
  • Интеграция с внешними API проверки страховки
  • Конфигурация failover активный-пассивный с двумя серверами
  • Целевая доступность: 99.9% (максимум 8.76 часов простоя в год)
  • RTO: 30 минут, RPO: 5 минут

Спроектируйте тестовые сценарии:

Часть 1: Метрики надёжности. На основе цели доступности 99.9% рассчитайте максимально допустимый MTTR, если система испытывает одну аварию в месяц (MTBF = 720 часов). Соответствует ли это требованиям?

Часть 2: Сценарии восстановления. Напишите 5 сценариев тестирования восстановления для следующих типов отказов:

  • Краш сервера приложений
  • Исчерпание пула соединений с базой данных
  • Внешнее API страховки недоступно
  • Отказ оборудования основного сервера (тест failover)
  • Повреждённый бэкап базы данных

Для каждого сценария укажите: триггер, ожидаемое поведение, допустимое время восстановления и шаги проверки целостности данных.

Часть 3: План DR-теста. Разработайте план тестирования disaster recovery, который проверяет, что система может выполнить цели RTO и RPO. Включите тип теста, предусловия, шаги выполнения и критерии успеха.

ПодсказкаДля Части 1 используйте формулу доступности: Доступность = MTBF / (MTBF + MTTR). Решите для MTTR при Доступности = 0.999 и MTBF = 720. Затем сравните рассчитанный MTTR с RTO в 30 минут.

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

Решение

Часть 1: Метрики надёжности

Дано: Доступность = 99.9%, MTBF = 720 часов

0.999 = 720 / (720 + MTTR) 720 + MTTR = 720 / 0.999 720 + MTTR = 720.72 MTTR = 0.72 часа = 43.2 минуты

Рассчитанный MTTR (43.2 минуты) превышает RTO (30 минут). Это значит, что нужно скорректировать цель доступности или RTO, либо система нуждается в улучшенных механизмах автовосстановления для снижения MTTR ниже 30 минут.

Часть 2: Сценарии восстановления

Сценарий 1: Краш сервера приложений

  • Триггер: Завершить процесс командой kill -9
  • Ожидаемое поведение: Мониторинг процессов обнаруживает краш за 30 секунд, автоматически перезапускает приложение. Текущие запросы получают ошибку с возможностью повтора. Без потери данных.
  • Допустимое время восстановления: Менее 2 минут
  • Проверка: Убедиться, что все транзакции либо завершились, либо откатились. Проверить отсутствие «осиротевших» записей о приёмах.

Сценарий 2: Исчерпание пула соединений

  • Триггер: Смоделировать 500 одновременных соединений, превышающих лимит пула в 100
  • Ожидаемое поведение: Приложение возвращает «сервис временно недоступен» для новых запросов. Существующие соединения завершаются нормально.
  • Допустимое время восстановления: Менее 5 минут после снижения нагрузки
  • Проверка: Запросить базу данных на предмет незавершённых транзакций. Убедиться, что метрики пула вернулись в норму.

Сценарий 3: Внешнее API страховки недоступно

  • Триггер: Заблокировать сетевой доступ к endpoint API страховки
  • Ожидаемое поведение: Приложение использует паттерн circuit breaker — после 3 неудачных попыток прекращает вызовы API и показывает понятное сообщение. Приёмы можно записывать без проверки страховки (в очередь на последующую проверку).
  • Допустимое время восстановления: Circuit breaker срабатывает за 30 секунд. Полное восстановление — 1 минута после возврата API.
  • Проверка: Убедиться, что отложенные проверки обрабатываются при возврате API.

Сценарий 4: Отказ оборудования основного сервера

  • Триггер: Выключить основной сервер
  • Ожидаемое поведение: Активируется failover. Резервный сервер берёт управление в рамках RTO.
  • Допустимое время восстановления: Менее 5 минут
  • Проверка: Подтвердить, что на резервном сервере актуальные данные (в пределах RPO — 5 минут). Протестировать полные пользовательские сценарии на резервном сервере.

Сценарий 5: Повреждённый бэкап

  • Триггер: Намеренно повредить файл бэкапа и попытаться восстановить
  • Ожидаемое поведение: Процесс восстановления обнаруживает повреждение через проверку контрольной суммы. Система переходит к предыдущему известному рабочему бэкапу. Генерируется алерт.
  • Допустимое время восстановления: Обнаружение за 5 минут. Итого менее 30 минут.
  • Проверка: Сравнить количество записей и контрольные суммы между восстановленными данными и источником.

Часть 3: План DR-теста

Тип теста: Параллельный тест

Предусловия:

  • DR-площадка настроена с идентичной инфраструктурой
  • Задержка репликации базы данных менее 5 минут
  • Актуальный runbook доступен всем участникам
  • Настроены дашборды мониторинга для DR-площадки

Шаги выполнения:

  1. Объявить DR-тест всем заинтересованным сторонам
  2. Проверить синхронизацию базы данных DR-площадки
  3. Перенаправить 10% трафика на DR-площадку
  4. Мониторить производительность DR-площадки 30 минут
  5. Смоделировать отказ основной площадки — перенаправить весь трафик на DR
  6. Измерить время от перенаправления до полной работоспособности
  7. Выполнить тесты критических сценариев
  8. Работать с DR-площадки 2 часа
  9. Перенаправить трафик обратно на основную площадку
  10. Проверить консистентность данных между обеими базами

Критерии успеха:

  • Полное переключение за менее 30 минут (RTO)
  • Потеря данных менее 5 минут транзакций (RPO)
  • Все критические сценарии выполняются успешно на DR-площадке
  • Деградация производительности менее 20%
  • Возврат на основную площадку без потери данных

Тестирование надёжности в CI/CD

Современные команды интегрируют тестирование надёжности в свой pipeline доставки:

Хаос-инженерия (подход Chaos Monkey от Netflix) намеренно внедряет сбои в продакшн или пре-продакшн среды для непрерывной проверки механизмов восстановления. Инструменты Chaos Monkey, Gremlin и Litmus помогают автоматизировать внедрение сбоев.

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

Health checks и readiness probes (probes liveness/readiness в Kubernetes) обеспечивают непрерывный мониторинг надёжности и автоматическое восстановление на уровне инфраструктуры.

Ключевые выводы

  • Тестирование надёжности измеряет стабильность работы системы с помощью метрик MTBF, MTTR и доступности
  • Тестирование восстановления проверяет возврат системы в рабочее состояние после крашей, отключений питания, сбоев сети и оборудования
  • Тестирование failover гарантирует автоматическое переключение на резервные системы в допустимые сроки
  • Бэкапы необходимо регулярно тестировать — непроверенный бэкап не является бэкапом
  • Тестирование DR варьируется от настольных упражнений до полного прерывания работы
  • RTO определяет максимально допустимое время простоя; RPO — максимально допустимую потерю данных
  • Хаос-инженерия переносит тестирование надёжности в CI/CD pipeline как непрерывную практику