Reliability — способность системы выполнять нужные функции в заданных условиях в течение времени. Recovery описывает восстановление после сбоя, а failover — переключение на резервный компонент или площадку. Эти свойства связаны, но проверяются по-разному. Успешный переход на резерв не доказывает сохранность данных, а наличие резервной копии не доказывает возможность восстановить сервис.
QA помогает превратить обещание «система переживает сбои» в наблюдаемые сценарии. Для каждого сценария нужны границы воздействия, ожидаемая деградация, правила остановки эксперимента и способ подтвердить бизнес-результат после восстановления. Начинают с контролируемого тестового окружения и согласованной модели отказа.
Надёжность глазами пользователя
Проверять только процесс или доступность порта недостаточно. Сервис может отвечать на health check и одновременно терять подтверждённые заказы. Выберите полезную операцию: создать заказ, прочитать баланс, получить документ. Определите, что считается успехом, ошибкой и превышением допустимого времени.
Наблюдайте и за периодом после сбоя. Очередь может накопиться, повторные запросы — перегрузить зависимость, а интерфейс — оставить пользователя в состоянии бесконечного ожидания. Возвращение процесса в рабочее состояние ещё не означает возвращение нормальной работы продукта.
RTO и RPO
RTO — целевое время восстановления допустимого уровня сервиса после нарушения. RPO — допустимая потеря данных, выраженная временным интервалом до сбоя. Например, цель восстановиться за десять минут отличается от цели потерять не больше одной минуты записей. Это два независимых обязательства.
Перед тестом согласуйте начало и конец измерения RTO: обнаружение, объявление инцидента или фактический отказ дают разные интервалы. Для RPO сравнивают восстановленные данные с известной последовательностью операций. Частота резервного копирования сама по себе не подтверждает достигнутую точку восстановления.
Какие отказы моделировать
Выбирайте сбои, соответствующие архитектуре: остановка экземпляра приложения, недоступность зависимости, задержка сети, отказ очереди, нехватка диска. Полный отказ площадки и краткий timeout одного запроса — разные эксперименты с разным масштабом.
Зафиксируйте, какие компоненты продолжают работать. Если одновременно отключить базу, сеть и мониторинг, результат будет трудно объяснить. Сначала полезно проверить один отказ и ожидаемую реакцию, затем переходить к обоснованным сочетаниям. Сложность эксперимента должна помогать ответить на конкретный вопрос.
Инварианты данных
Определите свойства, которые нельзя нарушать: заказ создаётся не более одного раза, остаток не становится отрицательным, подтверждённая операция доступна после восстановления. Для денег отдельно проверяют согласованность проводок, а не только показанный пользователю баланс.
Подготовьте журнал тестовых операций с уникальными идентификаторами и временем подтверждения. Сопоставляйте его с конечным состоянием через разрешённый способ проверки. Повторная отправка с тем же ключом идемпотентности и новый запрос с другим ключом должны давать различимые результаты согласно контракту.
Переключение и обратный переход
Во время failover проверяйте маршрутизацию, поведение существующих соединений, обнаружение нового лидера и ограничение записи. Риск split-brain возникает, когда несколько узлов одновременно считают себя вправе менять один набор данных. Его последствия выявляют по инвариантам и журналам, а не по зелёному статусу панели.
Обратное переключение тоже требует проверки. Вернувшийся узел должен синхронизироваться до принятия нужной роли. Автоматический возврат может вызвать второй перерыв, если резерв ещё обрабатывает накопленную очередь или старый узел содержит отставшие данные.
Практический сценарий заказов
На отдельном стенде работает два экземпляра приложения и тестовая база. Владелец инфраструктуры согласовал остановку одного экземпляра. Цели этого примера: ограниченный перерыв обслуживания и отсутствие повторных заказов; численные пределы команда задаёт заранее по требованиям.
- 1.Создайте контрольный заказ и убедитесь, что он доступен через пользовательский API. Начните журнал следующих операций и зафиксируйте базовую задержку.
- 2.Во время отправки нового заказа остановите согласованный экземпляр. Ожидается предусмотренный повтор или понятное сообщение об неопределённом результате без бесконечного ожидания.
- 3.Повторите запрос с исходным ключом идемпотентности. Ожидается один бизнес-заказ и согласованный ответ, если такой контракт заявлен.
- 4.Восстановите экземпляр, дождитесь готовности и проверьте оба заказа, очередь и ошибки за весь интервал. Ожидается отсутствие потери подтверждённых записей и возвращение задержки к допустимому уровню.
Этот сценарий проверяет отказ экземпляра приложения. Он не доказывает восстановление базы из резервной копии или отказоустойчивость целого региона.
Как проверять резервную копию
Восстановите копию в изолированное окружение с безопасными интеграциями. Проверьте структуру, миграции, чтение данных, права и возможность выполнить бизнес-операцию. Нельзя считать успешный запуск команды восстановления окончательным подтверждением работоспособности.
Для проверки RPO создайте маркированные записи до выбранной точки и после неё, затем сопоставьте восстановленное состояние с журналом. Отдельно учитывайте вложения, поисковые индексы и внешнее хранилище: восстановленная база может ссылаться на отсутствующие объекты.
Наблюдаемость и остановка
Запишите таймлайн отказа, обнаружения, переключения и восстановления. Смотрите ошибки пользователя, задержки, глубину очередей, отставание репликации и ресурсы. Сопоставляйте время между системами; несогласованные часы искажают выводы о последовательности событий.
До эксперимента определите условия остановки: нарушение инварианта, выход воздействия за границы стенда, потеря наблюдаемости или превышение допустимого времени. Назначьте ответственного за прекращение воздействия и восстановление. Без этого эксперимент может закончиться накоплением неисправленных последствий вместо полезного результата.
Частые ошибки и выводы
Ошибки — путать failover с восстановлением, проверять только доступность, не замечать дублей после retry и забывать обратное переключение. Опасно также объявлять RPO равным нулю по одному успешному прогону без достаточных доказательств и условий хранения данных.
Отчёт должен содержать модель отказа, границы проверки, измеренные интервалы, проверенные инварианты и остаточные ограничения. Надёжность подтверждается повторяемыми результатами и работоспособной процедурой восстановления, которую команда действительно смогла выполнить.