Тестирование катастрофоустойчивости
Несмотря на текущий уровень развития ИТ-систем, отказы и недоступность продолжают быть одной из ключевых проблем при необходимости договариваться о SLA между контрагентами. Каждый случай неверной договоренности может привести к цепочке отказов сервисов — как это, например, произошло с сервисами, использующими Cloudflare 25 декабря 2025 года. Cloudflare по коммерческим контрактам гарантирует SLA 100%, поэтому клиенты ему доверяют и зачастую не закладывают в архитектуру сценарии его отказа. В результате сбой одного провайдера способен затронуть значительную часть Интернета.
Как правило, при составлении SLA невозможно учесть все возможные причины. Поэтому многие руководствуются накопленным опытом отказов и восстановления. Более того, выявить точку отказа, которая проявляется лишь в 1% случаев, но при этом увеличивает RTO в шесть раз, мало кто стремится, поскольку это может быть неоднозначно интерпретировано клиентом. Верной схемой могло бы стать квантилирование: каждому проценту вероятности отказа присваиваются свои уровни SLA по RTO и RPO. Однако на практике это трудоемкая операция, требующая выявления всех скрытых потенциальных причин отказа.
Скрытые причины даунтайма
По моему опыту, самой частой причиной инцидентов является внесение изменений в систему. Это легко объясняется транзитивным состоянием системы, когда она должна перейти в новое качество. Изменения могут касаться архитектуры, инфраструктурных единиц, вычислительных мощностей или новой версии приложения. Даже после тщательного тестирования на тестовых данных и инфраструктурных элементах стабильность системы полностью проверяется только в момент установки в контур под реальный трафик пользователей.
Тем не менее поломка системы может произойти и без вашего участия — при изменениях, внесенных контрагентами на сопряженных сервисах, или при отказах оборудования.
Типовые ловушки при восстановлении
Одними из самых уязвимых мест для компаний с точки зрения соблюдения SLA являются:
- отказы базовых систем;
- попадание в кольцевую зависимость сервисов;
- КБ-инциденты;
- выход из строя мониторинга;
- выход из строя значимого сервиса контрагента, превышающий SLA.
Разберем каждую из этих причин по порядку.
Под отказом базовой системы я имею в виду фундаментальные механизмы, такие как DNS, сеть и вычислительные ресурсы. Например, при отказе DNS мониторинг не всегда корректно информирует о проблеме. Допустим, есть DNS зона, к которой обращаются несколько критичных систем инфраструктуры. В какой-то момент становится недоступен авторитативный сервер верхнего уровня DNS-зоны. С точки зрения серверов проблема не видна, так как сеть работает, DNS-серверы доступны, однако на некоторых узлах наблюдаются сильные задержки. Приложения мониторятся, и система уведомлений сообщает, что скорость запроса к соседнему серверу резко упала, запросы зависают, число воркеров веб-серверов переполняется, а в асинхронных процессах растет потребляемая память.
При этом сервис уже находится в даунтайме, а пользователи жалуются на проблемы. По метрикам видно, что серверы не могут достучаться друг до друга, логов ошибок практически нет, при этом сами серверы работают. Особенно интересна ситуация, когда сервис «жалуется» на долгое время ответа сервиса контрагента, а проблема с DNS локальна. Драйверы HTTP-запросов часто не могут явно отличить задержку DNS от задержки сервиса, что приводит к смешению событий в логах и усложняет поиск корневой причины, увеличивая время восстановления.
С кольцевой зависимостью похожая ситуация: чтобы восстановить один сервис, нужно поднять другой, а для второго — первый. Например, упала база данных, а виртуальный IP по какой-то причине не переключился на резервный сервер. При попытке перевести IP вручную через интерфейс не удается, так как IPAM недоступен, потому что БД лежит. Другой пример: отказала стойка серверов, где находились серверы непосредственно проекта, а также VPN/PAM/LDAP. В итоге доступ к серверам ограничен, и восстановление систем становится более трудоемким — через IPMI/VNC или предварительное поднятие VPN-серверов, а затем переход к восстановлению самого продукта. Это увеличивает время даунтайма и может привести к превышению SLA.
Про КБ-инциденты можно рассуждать долго. Киберугрозы представляют отдельный класс последствий с точки зрения RPO и RTO. Например, эффективный «киллер-запрос» может обрушить систему, не оставляя логов, что затрудняет определение причины.
Выход из строя мониторинга, системы логирования и трассировки напрямую не ломает систему, но в момент инцидента заставляет SRE-инженеров действовать вслепую, увеличивая время восстановления.
Любой контрагент также может столкнуться со скрытой проблемой, что продлевает восстановление и цепочно влияет на сопряженные сервисы.
Почему меры для снижения RTO иногда его увеличивают
Иногда один инцидент провоцирует другой. Например, после восстановления сети кластеры ElasticSearch и ClickHouse синхронизируют данные, используя всю пропускную способность сети, тормозя остальные сервисы. Особую проблему представляют зависшие приложения, которые, по хелсчекам, кажутся живыми. В таких случаях, даже после устранения первоначальной проблемы, проект может оставаться недоступным. Это может быть связано, например, с исчерпанием допустимого размера исходящих соединений.
Бывают ситуации, когда меры для снижения RTO приводят к его увеличению. Скажем, активные healthcheck-запросы, призванные выбрасывать тормозящие и упавшие серверы, во время пикового трафика сами перегружают сервис. В свою очередь, сделав свое дело на одном сервере, они его выключают из списка серверов обрабатывающих запросы, и в итоге большая часть запросов уходит на остальные, вызывая эффект домино, что в итоге приводит к исчерпанию ресурсов оставшихся машин и выводу их из работы.
В крупных системах всегда присутствуют скрытые зависимости, отказ которых может стать проблемой для приложений и неожиданностью для администраторов. Не всегда возможно найти их все и проанализировать. Комбинаций потенциальных событий множество, а их влияние на RTO и RPO существенно различается. Правильный разбор инцидента после аварии повышают шанс того, что редкочастотные события больше не повторятся, поскольку меры по предотвращению его повторяемости являются важной целью любого разбора. Однако даже после инцидента могут приниматься неверные решения из-за неправильной интерпретации данных, что приводит к ошибочному пониманию корневой причины аварии.
Один сценарий теста — не реальная авария
Существует также тестирование катастрофоустойчивости, и некоторые компании его проводят. Кто-то периодически тестирует отдельные критичные компоненты, другие имитируют отказ целого датацентра. Казалось бы, таким образом можно выявить значительное число проблем. Однако и здесь есть важные нюансы. Один и тот же дата-центр можно погасить разными способами: например, отключив сеть внутри самого ЦОДа или ограничив внешний трафик к нему. С точки зрения поведения приложений это будут разные сценарии. Полное отключение сети внутри дата-центра выглядит более щадящим вариантом, тогда как изоляция ЦОДа от внешнего мира может привести к split-brain в тех системах, которые не используют кворум и продолжают работать с локальными сервисами, наполняя свои базы данных новыми записями.
В этом случае восстановление превращается в долгий и трудоемкий процесс, поскольку появляются два независимых источника истины, которые затем необходимо каким-то образом свести воедино. Понятно, что такое тестирование требует значительных ресурсов, поэтому обычно ограничиваются одним сценарием.
Однако реальный отказ дата-центра может пойти по третьему сценарию: отключение электропитания, падение стоек, а затем частичное восстановление, при котором запускается лишь часть оборудования. В итоге мы получаем ситуацию, когда на бумаге архитектура выглядит полностью резервированной, в отчетах на катастрофоустойчивость протестированной, а после реального инцидента система не работает. В этом случае последовательный выход из строя двух-трех серверов внутри дата-центра способен вызвать более серьезные проблемы, чем полное отключение всего ЦОДа.
С одной стороны, это может натолкнуть на мысль, что заявленные RTO и RPO в SLA не работают и являются маркетинговыми цифрами. С другой стороны, существует реальная ответственность по договорам, которую компании обязаны исполнять.
Нельзя сказать, что цифры в SLA — это оценка на глаз. Практический опыт позволяет формировать актуальные значения RTO и RPO, если продукт зрелый и архитектура не претерпевает значительных изменений. В итоге цифры отражают наиболее частотные и вероятные инциденты, но не покрывают редкие и фундаментальные отказы. Разбор всех возможных сценариев возможен с участием большой команды экспертов, но приведет к необоснованно низкому RPO и высоким затратам на анализ и исправление потенциальных проблем.
Как итог — RPO, RTO и SLA отражают осознание компанией проблемных мест и допустимого бюджета даунтайма. При этом существует класс ошибок, за которые дешевле заплатить штраф, чем повышать стоимость сервиса за счет подготовки под малореалистичные катастрофы.
Опубликовано 25.02.2026
