Самый полезный результат проверки отказоустойчивости иногда выглядит совсем не эффектно: команда узнаёт, что после пропажи внешней зависимости сотрудники ещё могут работать, но новые заявки остаются без подтверждения и никто этого не замечает. Серверы продолжают отвечать. Бизнес-процесс уже нарушен.
Chaos Engineering позволяет проверять такие предположения контролируемым воздействием. Для него не обязательно начинать с отключения региона. Часто более содержательный первый эксперимент — задержать ответ одной зависимости и проследить, что станет с конкретной операцией клиента.
Сформулировать вопрос до выбора инструмента
Рассмотрим сервис записи на обучение. После регистрации он отправляет подтверждение через внешний почтовый сервис. Предположение команды: недоступность почты не помешает сохранить запись, пользователь увидит её статус, а уведомление будет доставлено позже без повторного создания регистрации.
Это уже можно проверять. Нужно заранее назвать наблюдаемый результат: сохранённые регистрации доступны, другие функции сохраняют согласованное качество, очередь уведомлений остаётся в предусмотренных пределах. Также требуется условие завершения восстановления: письма обработаны, дубликатов регистраций нет.
Фраза «отключим почту и посмотрим» не определяет ни ожидаемого поведения, ни допустимого ущерба. В Principles of Chaos Engineering эксперимент начинается с измеримого нормального состояния и проверяемой гипотезы. Выбор кнопки для создания отказа следует после этого.
Воспроизвести нужный отказ, а не удобный
Быстрый отказ соединения, долгий ответ и потеря подтверждения после успешной отправки проверяют разные свойства. В первом случае приложение быстро узнает о проблеме. Во втором может занять ресурсы ожиданием. В третьем не знает, произошло ли действие, и рискует выполнить его повторно.
Для нашего примера важно, где именно создаётся задержка. Если перекрыть не тот адрес или оставить рабочий запасной маршрут, эксперимент может вообще не затронуть проверяемую зависимость. Нужны подтверждение фактического воздействия и наблюдение за обработкой, а не только успешный статус инструмента.
Проверять одновременно все возможные отказы обычно не помогает. При нескольких изменённых условиях сложнее понять, почему система повела себя иначе. Начать разумнее с одной известной зависимости и одного режима отказа, сохранив возможность повторить проверку после исправления.
Граница эксперимента должна существовать технически
Сначала выбирают среду и ограниченный набор объектов. На стенде проще проверить сам механизм, восстановление и сбор наблюдений. Такой результат нельзя без оговорок переносить на рабочую систему: её объём, данные, права и маршруты могут отличаться.
Проверка на рабочем трафике требует отдельного решения о риске. Участники должны понимать, какие клиенты могут быть затронуты, кто вправе остановить испытание и как связаться с дежурными. Начало рекламной кампании или уже идущая авария — плохой момент для расширения неизвестного воздействия.
Ограничение должно быть проверяемым: конкретная тестовая группа, ячейка или экземпляр, подтверждённый список ресурсов, минимальные разрешения. Разрешение «воздействовать на всё с таким тегом» опасно, если состав группы меняется после подготовки. Перед запуском полезно увидеть фактические цели, а не только выражение их отбора.
Для проверки уведомлений стоит отдельно ограничить получателей и содержание тестовых сообщений. Тестовая регистрация не должна случайно занять реальное место на занятии или попасть в рабочую отчётность как новая продажа. Удаление таких следов и проверка освобождения ресурсов входят в подготовленный порядок завершения.
Кнопка остановки не возвращает прошлое
Эксперименту нужны максимальная длительность, наблюдаемые условия остановки и человек, который может прекратить его немедленно. Сигналы выбирают по работе, которую собирались защитить. Если намеренно задерживаем почту, рост её очереди ожидаем; остановку стоит связывать с недопустимыми последствиями, например нарушением самого приёма регистраций.
Автоматические ограничения тоже требуют проверки. Если воздействие лишает команду мониторинга, отсутствие сигнала нельзя считать подтверждением безопасности. Должен быть заранее определённый выход из такой ситуации, включая остановку при потере необходимой наблюдаемости.
Прекращение воздействия и восстановление — разные вещи. Остановленный эксперимент не отменяет уже отправленное сообщение, не возвращает удалённые данные и не создаёт заново удалённый экземпляр сервера. Для обратимых воздействий нужно проверить снятие ограничения, для остальных — отдельную процедуру восстановления. Документация AWS FIS описывает условия остановки, а возможность обратных действий зависит от конкретного воздействия.
После возвращения зависимости испытание ещё продолжается
Почтовый сервис снова отвечает, но накопленная очередь может начать разбираться слишком быстро. Повторы добавят нагрузку, часть уведомлений уже потеряет актуальность, а пользователь мог самостоятельно повторить регистрацию. Здесь полезны ограничения скорости, идемпотентность и проверка текущего состояния перед отложенным действием.
Поэтому нужно наблюдать не только момент отказа. Проверка заканчивается, когда сервис вернулся в согласованный режим, судьба принятой работы понятна, а временные настройки убраны. Остаток очереди и ручные исправления тоже входят в результат.
Для уведомлений стоит сопоставить принятые регистрации с намерением отправить письмо и фактическим исходом. Это не всегда будет идеально точный отчёт о доставке в почтовый ящик, но команда должна различать отсутствие попытки, неизвестный результат и подтверждение провайдера. Иначе эксперимент заканчивается ровно там, где начинается жалоба клиента.
Что считать полезным результатом
Есть как минимум три возможных исхода: поведение соответствует гипотезе, гипотеза опровергнута или данных недостаточно. Последний вариант важен. Если выбранная группа не пользовалась зависимостью во время воздействия, зелёный график ничего не подтверждает. Такой тест стоит изменить, а не записывать в достижения.
В отчёте нужны версия системы, условия нагрузки, фактические цели, подтверждение отказа и наблюдения за рабочим процессом. Формулировка «платформа отказоустойчива» шире любого отдельного испытания. Честный вывод уже: проверенный сценарий при указанных условиях прошёл или показал конкретное слабое место.
Найденная проблема должна получить владельца и повторную проверку после исправления. Именно здесь появляется отдача: компания перестаёт рассчитывать на неподтверждённое свойство. Если же у команды нет достоверных наблюдений и способа безопасно восстановиться, полезнее сначала сделать их, чем добавлять инструмент для эффектного отключения серверов.