Отказоустойчивость систем: принципы, архитектура и подготовка презентации

Понятие отказоустойчивости и ключевые метрики

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

Что такое отказоустойчивость

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

Важно, что:

Отказы считаются нормой, а не исключением: ломаются диски, падают инстансы, «флапают» сети, истекают сертификаты, ошибаются люди.

Цель — не «никогда не падать», а контролируемо переживать сбои и укладываться в согласованные показатели (например, доступность, время восстановления, допустимая потеря данных).

Отказоустойчивость обычно включает три слоя:

Предотвращение части проблем (например, лимиты, валидации, изоляция, постепенные выкладки).

Переживание отказов (redundancy, автоматический failover, деградация функциональности).

Восстановление и обучение (инцидент-менеджмент, постмортемы, улучшения).

Чем отказоустойчивость отличается от масштабирования и катастрофоустойчивости

Эти понятия часто смешивают, но у них разные цели.

| Понятие | Главная цель | Типичные механизмы | Что измеряют чаще всего | |---|---|---|---| | Отказоустойчивость | Продолжать работать при локальных отказах и быстро восстанавливаться | репликация, резервирование, failover, health-check, graceful degradation | доступность, MTTR, SLO | | Масштабирование | Обслуживать рост нагрузки и данных | горизонтальное масштабирование, шардирование, кеширование, очереди | throughput, latency, utilisation | | Катастрофоустойчивость | Пережить катастрофические события (регион, дата-центр, массовая потеря) | DR-сайт, multi-region, резервные копии, процедуры восстановления | RTO, RPO, готовность DR |

Практическая связь такая:

Масштабирование может повышать отказоустойчивость (например, больше реплик), но само по себе не гарантирует корректный failover.

Катастрофоустойчивость — это частный случай требований, где «авария» крупнее: затронуты целые зоны/регионы, и акцент смещается на план восстановления и потерю данных.

Когда нужна отказоустойчивая система

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

Типовые триггеры:

Деньги: прямые потери выручки (e-commerce), штрафы, возвраты, потеря лидов.

Риски: безопасность, соответствие требованиям (финансы, медицина), репутационные потери.

Операции: 24/7, международные пользователи, невозможность «падать ночью».

Архитектура: много зависимостей и интеграций; один сбой каскадируется.

Данные: важна целостность и минимальная потеря данных.

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

Ключевые метрики отказоустойчивости

Метрики нужны для двух вещей:

превращать ожидания бизнеса в измеримые цели;

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

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

Доступность

Доступность (availability) описывает долю времени, когда сервис способен выполнять свою функцию для пользователя.

Часто используют простую формулу:

Где:

— доступность (доля от 0 до 1, часто переводят в проценты);

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

— время недоступности (полной или частичной — в зависимости от того, как вы определяете «даунтайм»).

В реальности важно заранее договориться, что считается недоступностью: HTTP 500, рост p95 задержки, недоступность части функций, ошибки оплаты, и т.д. Это связывает доступность с SLI/SLO (ниже).

Также встречается разговор про «девятки».

| Доступность | Допустимый простой в год (приблизительно) | |---:|---:| | 99% | ~3,65 дня | | 99,9% | ~8,76 часа | | 99,99% | ~52,6 минуты | | 99,999% | ~5,26 минуты |

Эта таблица полезна для презентации: она переводит абстрактные проценты в понятный бизнесу язык.

Надёжность, частота отказов и «как часто ломается»

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

Практические показатели, которые часто используют на уровне эксплуатации:

MTTF (Mean Time To Failure) — среднее время до отказа (чаще для неремонтируемых или «одноразово падающих» объектов).

MTBF (Mean Time Between Failures) — среднее время между отказами (для ремонтируемых систем).

Что важно для отказоустойчивости:

если отказы редки, но восстановление долгое, вы проиграете по доступности;

если отказы частые, даже быстрые восстановления создадут постоянную «дрожь» сервиса.

Поэтому MTBF/MTTF почти всегда нужно рассматривать вместе с MTTR.

Восстановление: MTTR, RTO, RPO

MTTR (Mean Time To Recovery/Repair) — среднее время восстановления после инцидента до нормального уровня сервиса.

Вокруг восстановления есть ещё две метрики, которые особенно важны для катастрофоустойчивости, но часто фигурируют и в отказоустойчивых требованиях:

RTO (Recovery Time Objective) — целевое время, за которое сервис должен быть восстановлен после серьёзного сбоя.

RPO (Recovery Point Objective) — допустимая потеря данных по времени: насколько «в прошлое» можно откатиться при восстановлении.

Интуитивно:

RTO отвечает на вопрос «как быстро мы должны подняться»;

RPO отвечает на вопрос «сколько данных мы можем потерять».

Даже если у вас высокая доступность, плохой RPO может быть неприемлем: сервис может «работать», но терять транзакции.

SLI, SLO, SLA и бюджет ошибок

Для презентации (и для реальной работы) полезно отделять измерения от целей и обязательств.

SLI (Service Level Indicator) — измеряемый индикатор качества сервиса: доля успешных запросов, p95 latency, доля успешных платежей.

SLO (Service Level Objective) — целевое значение SLI за период: например, 99,9% успешных запросов за 30 дней.

SLA (Service Level Agreement) — договорное обязательство перед клиентом (часто с компенсациями), обычно базируется на SLO, но может быть более консервативным.

Практика SLO подробно описана в книге Google SRE: Google SRE Book: Service Level Objectives.

Из SLO следует полезное понятие бюджет ошибок (error budget): если SLO допускает немного «плохих» событий, то этот «лимит» можно тратить на изменения и релизы, сохраняя баланс между скоростью развития и устойчивостью.

Наблюдаемость и «время обнаружения»

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

Часто выделяют:

время до обнаружения (иногда называют MTTD);

время до реакции (эскалация, взятие в работу);

время до восстановления (MTTR).

В презентации это помогает показать, что отказоустойчивость — это не только резервирование, но и мониторинг, алёртинг, дежурства, runbook и тренировки.

!Таймлайн инцидента: где теряется время и какие метрики за это отвечают

Как метрики превращаются в требования к архитектуре

Метрики — это язык требований, а архитектура — способ эти требования выполнить.

Примеры связей:

высокая доступность и низкий MTTR обычно требуют:

- избыточности (несколько экземпляров); - автоматического failover; - быстрой диагностики (health-check + наблюдаемость); - снижения «радиуса поражения» (изоляция компонентов).

строгий RPO требует:

- синхронной или почти синхронной репликации; - внимательного проектирования согласованности данных.

строгий RTO требует:

- заранее готовой резервной инфраструктуры; - автоматизации процедур восстановления и регулярных тренировок.

В следующих статьях курса эти связи будут разложены по архитектурным паттернам (active-passive, active-active, multi-AZ, multi-region) и по практикам эксплуатации.

Ресурсные затраты и компромиссы

Отказоустойчивость почти всегда увеличивает стоимость владения. Основные статьи затрат:

Инфраструктура: дополнительные реплики, зоны/регионы, сетевые компоненты.

Сложность разработки: идемпотентность, ретраи, консистентность данных, распределённые транзакции (или отказ от них).

Эксплуатация: мониторинг, алёртинг, on-call, инциденты, постмортемы.

Тестирование: стенды, фолт-инъекции, game days.

Ключевой компромисс для презентации: чем больше требований (выше доступность, ниже RTO/RPO), тем дороже не только инфраструктура, но и изменения, релизы и сопровождение.

Примеры типовых заказчиков и «уровни» архитектуры (в разрезе метрик)

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

Внутренний сервис или MVP

- один регион/зона, бэкапы, ручное восстановление - фокус: базовая наблюдаемость

B2B/B2C сервис с денежными операциями

- несколько экземпляров, балансировка, разнесение по зонам доступности, автоматический failover - фокус: SLO на успешность ключевых операций, низкий MTTR

Критичный сервис 24/7 с высокой ценой простоя

- multi-AZ и/или multi-region, репликация данных, строгие runbook, регулярные тренировки - фокус: RTO/RPO + готовность к отказам зависимостей

!Эволюция архитектуры в зависимости от требований к доступности и восстановлению

Методики тестирования отказоустойчивости (обзор)

Проверять отказоустойчивость «по документам» нельзя: важна практика.

На уровне методик обычно используют:

тестирование восстановления (проверка процедур, runbook, резервных копий);

регулярные учения game days (имитация инцидентов);

контролируемые эксперименты с отказами и деградациями (fault injection, chaos engineering).

Полезная отправная точка для подхода к экспериментам: Principles of Chaos Engineering.

Также как общий ориентир по проектированию надёжности в облаке можно использовать: AWS Well-Architected Framework: Reliability Pillar.

Итоги

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

Её нельзя обсуждать без метрик: доступность, MTTR, RTO/RPO, SLI/SLO/SLA.

Метрики нужны, чтобы осмысленно выбирать архитектуру и не переплачивать за «лишние девятки».

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

Отличия: отказоустойчивость, масштабирование, катастрофоустойчивость

В предыдущей статье мы договорились о терминах и метриках: доступность, MTTR, RTO, RPO, SLI/SLO/SLA. Теперь разберём частую путаницу в презентациях: отказоустойчивость, масштабирование и катастрофоустойчивость часто обсуждают одними и теми же словами (реплики, регионы, балансировщики), но решают разные задачи и измеряются разными метриками.

Базовые определения

Отказоустойчивость

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

Простыми словами: сломалось что-то одно — система в целом продолжает работать (возможно, с деградацией), а восстановление происходит быстро и предсказуемо.

Масштабирование

Масштабирование — способность системы сохранять приемлемую производительность и стоимость при росте нагрузки (пользователи, запросы, данные).

Состоит из двух базовых подходов:

Вертикальное: сделать один узел мощнее (больше CPU/RAM/диск).

Горизонтальное: добавить больше узлов (инстансов/подов/шардов) и распределить нагрузку.

Простыми словами: стало больше пользователей — система не “задохнулась”.

Катастрофоустойчивость

Катастрофоустойчивость (disaster recovery, DR) — способность восстановить сервис после крупного инцидента, затрагивающего значительную часть инфраструктуры: зону доступности, дата-центр, регион, облачную платформу, критичную зависимость.

Простыми словами: “сгорел регион” — мы всё равно поднимемся, по заранее продуманному плану.

Чем эти понятия отличаются на практике

Ключевое отличие — масштаб события и цель.

Масштабирование отвечает на вопрос: “выдержим ли рост нагрузки без деградации?”

Отказоустойчивость: “продолжим ли работать при поломке части компонентов?”

Катастрофоустойчивость: “восстановимся ли после событий уровня зоны/региона/массовой потери?”

!Сводная картинка для слайда: цели, триггеры, метрики и механизмы для трёх тем

Сравнение в таблице: цель, метрики, механизмы

| Тема | На какой вопрос отвечает | Типичный “размер” проблемы | Главные метрики (из предыдущей статьи) | Типовые механизмы | Типовая ошибка в презентации | |---|---|---|---|---|---| | Масштабирование | “Сколько нагрузки выдержим?” | рост трафика/данных | latency (например p95), throughput, utilisation | горизонтальное масштабирование, кеши, очереди, шардирование | считать, что “больше реплик” автоматически даёт высокую доступность | | Отказоустойчивость | “Что будет, если компонент упадёт?” | отказ узла/процесса/сети/БД-реплики | availability, MTTR, SLO, error budget | redundancy, health-check, failover, graceful degradation | путать с DR и обещать “регион не нужен, у нас есть две реплики” | | Катастрофоустойчивость (DR) | “Что делаем, если потеряем площадку?” | зона/регион/массовая потеря | RTO, RPO, готовность процедур | multi-region, резервные копии, репликация, DR-процедуры и тренировки | ограничиться “у нас бэкапы есть”, не проверяя восстановление |

Три наглядных сценария (для устного объяснения)

Сценарий: резкий пик нагрузки

Симптом: растёт задержка, появляются таймауты, но инфраструктура “жива”.

Это прежде всего масштабирование.

Отказоустойчивость может пострадать вторично: перегрузка часто вызывает каскадные отказы.

Вывод для презентации: если решать пик нагрузки только “фейловером”, вы лечите не ту причину.

Сценарий: упал один сервер приложения

Симптом: часть запросов падает, но система может продолжать работу.

Это отказоустойчивость.

Масштабирование тут не главное: даже если узлов много, без правильных health-check и корректного перераспределения трафика пользователи всё равно увидят ошибки.

Вывод: “у нас 10 инстансов” не равно “у нас есть автоматический failover”.

Сценарий: недоступна зона/регион

Симптом: недоступны внешние сервисы региона, базы, сети, балансировщики.

Это катастрофоустойчивость.

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

Вывод: multi-AZ решает много задач отказоустойчивости, но DR обычно требует отдельного плана и метрик RTO/RPO.

Как они связаны и почему легко перепутать

Связь есть, но это не синонимы.

Масштабирование может улучшить отказоустойчивость: больше экземпляров — меньше шанс полной остановки при отказе одного.

Отказоустойчивость может помочь масштабированию: например, очереди и backpressure одновременно уменьшают перегрузки и предотвращают каскады.

Катастрофоустойчивость почти всегда использует те же строительные блоки, что и отказоустойчивость (репликация, переключение), но добавляет:

- отдельные “границы отказа” (другой регион/провайдер); - требования к потере данных (RPO); - требования к времени подъёма (RTO); - процедуры, роли и регулярные учения.

Мини-чеклист: как быстро определить, о чём вы говорите

Для подготовки презентации удобно начинать с вопросов, а не с технологий.

Если главный страх: “при росте пользователей система будет медленной” — это масштабирование.

Если главный страх: “упадёт часть компонентов, и сервис остановится” — это отказоустойчивость.

Если главный страх: “потеряем регион или критичную площадку” — это катастрофоустойчивость.

И привязка к метрикам:

Масштабирование: целевые задержки и пропускная способность для пиков.

Отказоустойчивость: доступность, MTTR и SLO на ключевые операции.

Катастрофоустойчивость: RTO и RPO, подтверждённые восстановлением.

Что упоминать на слайдах про механизмы (без ухода в “зоопарк технологий”)

Механизмы масштабирования

горизонтальное масштабирование stateless-компонентов;

кеширование;

очереди и асинхронная обработка;

разбиение данных (партиционирование, шардирование) при необходимости.

Механизмы отказоустойчивости

резервирование (несколько экземпляров, несколько узлов);

автоматическое переключение (failover) на здоровые компоненты;

health-check и корректное исключение “больных” узлов из балансировки;

ограничение “радиуса поражения”: таймауты, ретраи с лимитами, circuit breaker, bulkhead;

graceful degradation: заранее продуманные режимы упрощения функциональности.

Механизмы катастрофоустойчивости

второй регион (или отдельная площадка) и выбор модели: active-passive или active-active;

репликация данных (и чёткое объяснение, как она влияет на RPO);

резервные копии и проверка восстановления;

runbook и регулярные тренировки восстановления.

В качестве общих ориентиров по практикам можно ссылаться на:

AWS Well-Architected Framework: Reliability Pillar

Google SRE Book: Service Level Objectives

Итоги

Масштабирование, отказоустойчивость и катастрофоустойчивость используют похожие “строительные блоки”, но отвечают на разные вопросы и требуют разных метрик.

Чтобы не перепутать, начинайте с формулировки проблемы и метрик: задержки и пропускная способность против доступности и MTTR против RTO/RPO.

В следующих материалах курса логично углубиться в архитектурные паттерны отказоустойчивости (failover, redundancy, зоны доступности) и в практики проверки (fault injection, game days, chaos engineering).

Когда нужна отказоустойчивость: критерии и уровни требований

В прошлых статьях курса мы:

определили, что такое отказоустойчивость и какими метриками её измеряют (доступность, MTTR, SLI/SLO/SLA, RTO/RPO);

отделили отказоустойчивость от масштабирования и катастрофоустойчивости (DR).

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

Что значит “нужна отказоустойчивость”

На практике это означает, что бизнес и команда готовы:

зафиксировать измеримые цели (например, SLO по успешности ключевой операции и целевой MTTR);

инвестировать в архитектуру и процессы, которые позволяют переживать отказы предсказуемо;

принять рост сложности и стоимости владения.

Важно: отказоустойчивость — это не бинарный выбор “делаем/не делаем”, а спектр решений. Правильный вопрос: какой уровень устойчивости нужен для конкретных пользовательских сценариев.

Критерии: когда отказоустойчивость окупается

Ниже — критерии, которые удобно использовать в презентации. Они помогают перевести разговор из “давайте 99,99%” в “какие риски и деньги за этим стоят”.

Стоимость простоя и деградации

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

Типовые источники ущерба:

недополученная выручка (e-commerce, билеты, доставка);

прямые потери денег из-за сбоев транзакций (платежи, ставки, финтех);

штрафы по контрактам (B2B, интеграции, SLA);

рост затрат на поддержку (всплеск обращений, ручная обработка);

репутационный ущерб и отток пользователей.

Практический приём для требований: считать не только полный даунтайм, но и частичную деградацию (например, “поиск работает, но оформление заказа нестабильно”).

Наличие “критичных пользовательских путей”

Если у продукта есть 1–3 сценария, которые обязаны быть доступны (например, вход, платеж, создание заказа), отказоустойчивость проектируют вокруг них.

Здесь полезна связка из прошлой статьи:

SLI/ SLO — для качества ключевых операций;

MTTR — для скорости возвращения сервиса в норму.

Требования регуляторов и безопасности

Отказоустойчивость часто становится обязательной из-за внешних требований:

финансовый сектор, персональные данные, медицина;

внутренние требования по непрерывности бизнеса;

повышенные требования к целостности данных.

Почти всегда это приводит к обсуждению:

журналирования и аудита;

контроля изменений;

RPO (допустимая потеря данных), даже если формально речь не про DR.

Режим работы 24/7 и распределённая аудитория

Если пользователи в разных часовых поясах или сервис работает круглосуточно, “починим ночью” перестаёт быть стратегией.

В таких системах особенно важно снижать:

время обнаружения (MTTD) и эскалации;

время восстановления (MTTR);

долю ручных операций при фейловере.

Сложность системы и риск каскадных отказов

Чем больше зависимостей (внутренних микросервисов, внешних API, брокеров, БД, кешей), тем чаще локальный сбой превращается в каскад.

Признаки, что отказоустойчивость нужна как системная практика:

один сбой регулярно “роняет” несколько сервисов;

нет чётких границ отказа (fault domains) и ограничения “радиуса поражения”;

повторные инциденты похожи друг на друга (не устраняются причины).

“Человек как источник отказа” и частые изменения

Если вы часто релизитесь, то существенная доля инцидентов — это изменения (конфиги, миграции, выкладки).

В таких командах отказоустойчивость оправдана, когда есть:

регулярные релизы и высокая цена отката;

сложные миграции данных;

несколько команд, меняющих общую платформу.

Смещение акцента: устойчивость к ошибкам изменений (постепенные выкладки, быстрый rollback, feature flags) иногда даёт больше эффекта, чем “ещё одна реплика”.

Как сформулировать требования: от вопросов к метрикам

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

Ниже — минимальный набор вопросов, который переводится в метрики из первой статьи:

Какие пользовательские действия критичны?

Что считаем “недоступностью” для этих действий? (ошибка, таймаут, p95 задержка выше порога, недоступность части функций)

Какой SLO нужен для критичных действий?

Как быстро нужно восстанавливаться? (целевой MTTR)

Сколько данных можно потерять? (RPO)

Как быстро обязаны подняться после крупного сбоя? (RTO)

!Как требования превращаются в метрики, а метрики — в архитектурный уровень

Полезные ориентиры по подходу к SLO и балансу изменений:

Google SRE Book: Service Level Objectives

Уровни требований: практическая шкала (tiers)

Ниже — удобная шкала “уровней”, которую можно прямо перенести на слайды. Она намеренно не привязана к конкретному облаку или стеку.

Важно: уровни можно задавать для системы в целом или для отдельных критичных операций.

Tier 0: базовая надёжность (без отказоустойчивости как свойства)

Когда подходит: MVP, внутренние инструменты, прототипы, низкая стоимость простоя.

Типовые требования:

SLO не формализован или низкий;

восстановление в рабочее время;

RPO — “есть бэкапы”, без регулярной проверки.

Типовые механизмы:

мониторинг базовых метрик;

резервные копии;

ручные процедуры восстановления.

Цена выбора: низкая инфраструктурная стоимость, но высокий риск долгих простоев и непредсказуемого восстановления.

Tier 1: отказоустойчивость stateless-слоя (приложение переживает падение экземпляра)

Когда подходит: первые публичные версии, сервисы без жёстких требований к данным, когда основной риск — падение приложений.

Типовые требования:

SLO на ключевой API/страницы;

целевой MTTR на уровне минут-десятков минут при отказе одного узла.

Типовые механизмы:

несколько экземпляров приложения за балансировщиком;

health-check и автоматическое исключение “больных” узлов;

отсутствие состояния на узле (stateless), чтобы перезапуск был безопасен.

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

Tier 2: отказоустойчивость внутри одной “границы отказа” (одна зона/одна площадка)

Когда подходит: B2B/B2C системы, где простой ощутим, но потеря целой зоны/дата-центра считается редкой и принимаемой.

Типовые требования:

более высокий SLO на критичные операции;

предсказуемый MTTR при отказах отдельных компонентов;

снижение числа ручных действий при инциденте.

Типовые механизмы:

резервирование критичных компонентов (балансировщики, очереди, кеши);

реплика БД для чтения и/или фейловер в пределах площадки (если поддерживается);

контроль зависимостей: таймауты, ограниченные ретраи, circuit breaker.

Риск, который остаётся: “потеря площадки/зоны” всё ещё выводит сервис из строя.

Tier 3: multi-AZ (переживаем потерю зоны доступности)

Когда подходит: сервисы 24/7 с высокой ценой простоя; продукты, где отказ зоны — не катастрофа, а расчётный сценарий.

Типовые требования:

SLO на критичные операции с учётом отказа зоны;

MTTR сокращается за счёт автоматического переключения;

RPO малый или близкий к нулю для транзакционных данных (зависит от репликации).

Типовые механизмы:

разнесение приложений и зависимостей по зонам;

автоматическое переключение трафика между зонами;

репликация данных между зонами.

Компромисс: возрастает стоимость (дублирование ресурсов) и сложность данных (согласованность, задержки, стратегии записи).

Tier 4: DR (переживаем потерю региона по RTO/RPO)

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

Типовые требования:

RTO: “за сколько поднимемся в другом регионе”;

RPO: “сколько данных можем потерять”;

регулярные учения восстановления.

Типовые механизмы:

второй регион (warm standby или hot standby);

репликация данных между регионами и/или проверенные бэкапы;

runbook и автоматизация процедур.

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

Tier 5: active-active (высокая непрерывность даже при региональных проблемах)

Когда подходит: очень высокая цена простоя, глобальные сервисы, жёсткие требования к непрерывности.

Типовые требования:

минимальный RTO (часто близкий к “почти мгновенно”);

SLO должен учитывать сложные частичные деградации;

строгие требования к операционной готовности.

Типовые механизмы:

обслуживание трафика из нескольких регионов одновременно;

глобальная балансировка;

сложные стратегии согласованности данных (часто с компромиссами по консистентности или функциональности).

Цена выбора: максимальная сложность (данные, эксплуатация, тестирование), а также значительные постоянные инфраструктурные затраты.

Таблица для слайда: уровни, риски, механизмы, затраты

| Уровень | Какие отказы переживаем | Типовые метрики в фокусе | Примеры механизмов | Типовые затраты | |---|---|---|---|---| | Tier 0 | почти никакие (восстановление вручную) | минимальные SLI, время реакции команды | бэкапы, базовый мониторинг | низкие, но высокий риск долгого простоя | | Tier 1 | падение инстанса приложения | SLO ключевых API, MTTR | несколько инстансов, health-check, stateless | умеренные, растёт сложность деплоя | | Tier 2 | отказ отдельных компонентов в одной площадке | SLO, MTTR, частота инцидентов | резервирование, фейловер внутри площадки, circuit breaker | выше: больше компонентов и поддержки | | Tier 3 | потеря зоны (AZ) | SLO с учётом AZ-failure, MTTR, иногда RPO | multi-AZ, репликация между зонами, авто-переключение | заметные: дублирование и сложность данных | | Tier 4 | потеря региона (по плану DR) | RTO, RPO, готовность процедур | второй регион, репликация/бэкапы, runbook, тренировки | высокие: инфраструктура + регулярные учения | | Tier 5 | региональные проблемы без остановки сервиса | SLO глобального сервиса, минимальный RTO | active-active, глобальная балансировка, сложная модель данных | максимальные: сложность и стоимость |

Как выбрать уровень: практический алгоритм

Этот алгоритм можно использовать как “скелет” для устной части выступления.

Определите критичные пользовательские пути.

Зафиксируйте для них SLI и SLO (что меряем и какую цель хотим).

Определите целевой MTTR для типовых отказов (узел, процесс, зависимость).

Если есть требования к данным, зафиксируйте RPO.

Определите, нужен ли сценарий потери зоны (Tier 3) и/или региона (Tier 4–5), то есть требуются ли RTO/RPO на “крупные” события.

Постройте архитектурную схему под метрики, а не наоборот.

Запланируйте в бюджете не только инфраструктуру, но и эксплуатацию и тестирование (дежурства, алёртинг, тренировки).

!Дерево выбора уровня отказоустойчивости по требованиям

Ресурсные затраты: что именно дорожает

В первой статье мы уже перечисляли статьи затрат. Здесь — как их “привязать” к уровням.

Дорожает не только железо:

инфраструктура (дублирование, межзоновые/межрегиональные ресурсы);

разработка (идемпотентность, корректные ретраи, конкуренция за данные, миграции);

эксплуатация (on-call, алёртинг, runbook, постмортемы);

тестирование (стенды, фолт-инъекции, game days).

Хорошая формулировка для презентации: каждая дополнительная “девятка” доступности обычно стоит непропорционально дороже, потому что требует закрывать всё более редкие и сложные сценарии.

Как общий ориентир по системному подходу к надёжности можно ссылаться на:

AWS Well-Architected Framework: Reliability Pillar

Примеры “типов заказчиков” и характерные уровни

Важно: вместо конкретных компаний в выступлении часто достаточно показать классы заказчиков и их типичный выбор уровней.

Интернет-магазин среднего размера

критичный путь: каталог → корзина → оплата;

типичный уровень: Tier 2–3;

акцент: SLO на оплату и создание заказа, быстрый MTTR.

Архитектурный силуэт:

несколько экземпляров приложения;

БД с репликацией и автоматическим переключением в пределах зоны/нескольких зон;

кеш и очередь как “амортизатор” пиков и сбоев зависимостей.

Финтех/платежи

критичный путь: авторизация → списание/зачисление → чек/квитанция;

типичный уровень: Tier 3–4;

акцент: строгие требования к данным (RPO) и контролируемые изменения.

Архитектурный силуэт:

multi-AZ для основных компонентов;

DR-план с регулярной проверкой восстановления;

повышенные требования к наблюдаемости и аудиту.

B2B SaaS для корпоративных клиентов

критичный путь: доступ к API и интеграциям;

типичный уровень: Tier 1–3 (зависит от SLA и штрафов);

акцент: SLO на API, изоляция отказов, предсказуемый MTTR.

Архитектурный силуэт:

отказоустойчивый stateless-слой;

чёткие лимиты, таймауты, деградация при проблемах зависимостей;

договорённости по SLA и прозрачный статус.

Что обязательно упомянуть в презентации, чтобы избежать типовых ошибок

Частые ошибки при обсуждении “нужна ли отказоустойчивость”:

подмена требований технологиями: “сделаем Kubernetes — будет отказоустойчиво”;

отсутствие определения недоступности: доступность “в процентах” без SLI;

игнорирование данных: “приложение поднялось” не значит “данные корректны”;

ставка на ручной фейловер при строгом MTTR;

отсутствие тренировок: DR и фейловер “на бумаге”.

Итоги

Отказоустойчивость нужна там, где стоимость простоя, риски или режим 24/7 делают сбои дорогими.

Требования стоит формулировать через критичные пользовательские пути и метрики SLI/SLO, MTTR, а при необходимости — RTO/RPO.

Удобно мыслить уровнями (Tier 0–5): от базовой надёжности до multi-AZ и DR/active-active.

Чем выше уровень, тем дороже не только инфраструктура, но и разработка, эксплуатация и тестирование.

Далее в курсе логично переходить от выбора уровня к тому, за счёт каких архитектурных механизмов обеспечивается отказоустойчивость (резервирование, failover, изоляция отказов, деградация) и как это проверять на практике.

Архитектурные механизмы отказоустойчивости и типовые паттерны

В предыдущих статьях курса мы определили, что такое отказоустойчивость и какими метриками её измеряют (SLI/SLO, доступность, MTTR), а также отделили её от масштабирования и катастрофоустойчивости (DR). Теперь разберём ключевой практический слой: за счёт каких архитектурных механизмов система продолжает работать при сбоях и какие паттерны чаще всего используют в реальных системах.

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

правильных границ отказа (fault domains);

резервирования (redundancy);

автоматического обнаружения проблем и переключения (health-check + failover);

ограничения каскадных отказов (timeouts, retries, circuit breaker, bulkhead);

корректной работы с данными (репликация, кворумы, идемпотентность);

заранее спроектированной деградации (graceful degradation).

Базовые принципы: что именно ломается

Архитектурные решения становятся понятнее, если классифицировать отказы. Типовые категории:

Отказ экземпляра: процесс/контейнер/VM завершился или завис.

Отказ узла: физический сервер или хост недоступен.

Сетевая деградация: задержки, потери пакетов, частичные разрывы.

Отказ зависимости: база данных, кеш, брокер сообщений, внешний API.

Ошибки изменений: баги релиза, миграции, конфиги, истёкшие сертификаты.

Для презентации полезная формулировка: мы проектируем систему так, будто отказы — нормальное состояние мира, а не исключение.

Границы отказа: fault domain как основа архитектуры

Fault domain (граница отказа) — часть системы, которая может “упасть” целиком из-за общего фактора: один хост, одна стойка, одна сеть, одна зона доступности (AZ), один регион.

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

!Почему важно разносить реплики по независимым доменам отказа

Практические выводы:

Резервирование имеет смысл только при независимости резервов.

Чем выше уровень домена (AZ, регион), тем дороже независимость.

Резервирование: N+1, N+M и устранение единых точек отказа

Резервирование (redundancy) — наличие дополнительных экземпляров компонентов, чтобы система продолжала работать при отказе части из них.

N+1 и N+M

N+1: вам нужно N экземпляров для нормальной работы и 1 запасной на отказ.

N+M: запас больше, чем один, чтобы переживать несколько одновременных отказов.

Важно отличать:

резервирование мощности (чтобы был запас по ресурсам при падении узла);

резервирование доступности (чтобы не было единой точки отказа: один балансировщик, один лидер, один диск).

Единая точка отказа

Единая точка отказа (SPOF, single point of failure) — компонент, отказ которого делает сервис недоступным.

Типовые SPOF в проектах:

одна база данных без реплики и фейловера;

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

один балансировщик без отказоустойчивой конфигурации;

один секрет-хранилище/PKI без плана продления сертификатов.

Stateless и stateful: почему слой приложения “лечится” проще

Отказоустойчивость почти всегда начинают со stateless-слоя.

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

Stateful-компонент хранит состояние: база данных, брокер, кеш с важными данными, файловое хранилище.

Практическая связка:

stateless-слой легко масштабировать и переключать (автоматический перезапуск, балансировка);

stateful-слой требует продуманной модели данных, репликации и процедур восстановления.

Если нужен тезис для слайда: многие системы “выглядят отказоустойчивыми”, пока не падает их состояние.

Обнаружение отказов и переключение: health-check и failover

Health-check

Health-check — проверка, что экземпляр компонента способен корректно обслуживать запросы.

Ключевые варианты:

Liveness: “процесс жив?”

Readiness: “готов обслуживать трафик?”

Функциональная проверка: “может выполнить ключевую операцию?”

Типовая ошибка: считать, что “порт открыт” равен “сервис работает”. Для отказоустойчивости readiness обычно важнее.

Failover

Failover — переключение нагрузки на здоровую копию компонента.

Два режима:

Автоматический failover: система сама исключает больной экземпляр и переводит трафик.

Ручной failover: переключение человеком по инструкции.

Связь с метриками из первой статьи:

строгий MTTR почти всегда требует автоматического failover;

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

Балансировка трафика и маршрутизация

Балансировщик и маршрутизация решают две задачи одновременно:

распределение нагрузки;

изоляция отказов (не отправлять запросы в “больные” зоны/инстансы).

Типовые механизмы:

Round-robin/least connections распределение по здоровым экземплярам;

zone-aware routing: предпочтение локальной зоне, но с возможностью уйти в другую;

draining: “мягкое” выключение инстанса, чтобы не рвать активные соединения.

Для выступления удобно подчёркивать: балансировщик — это не только про производительность, но и про быстрый failover без участия человека.

Паттерны топологии: active-passive и active-active

Active-passive

Active-passive — есть активный контур, который обслуживает трафик, и пассивный контур, который простаивает или частично готов.

Сильные стороны:

проще для данных и консистентности;

проще эксплуатационно.

Слабые стороны:

переключение может занимать время;

часть ресурсов простаивает.

Active-active

Active-active — несколько контуров одновременно обслуживают трафик.

Сильные стороны:

выше непрерывность сервиса;

лучше используется инфраструктура.

Слабые стороны:

сложнее данные (конфликты записи, согласованность);

больше рисков “сложных” частичных отказов.

!Два базовых паттерна топологии и их смысл

Устойчивость к сбоям зависимостей: timeouts, retries, circuit breaker, bulkhead

Большая часть каскадных аварий происходит не из-за “падения” компонента, а из-за того, что зависимость стала медленной, а система продолжает в неё упираться.

Таймауты

Таймаут — максимальное время ожидания ответа от зависимости.

Зачем нужен:

освобождает ресурсы (пулы потоков, соединения);

снижает риск “накопления хвоста” запросов.

Практическое правило: таймауты должны быть явно настроены, а не оставлены “по умолчанию”.

Повторные попытки (retries)

Retry — повтор запроса при ошибке.

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

Чтобы ретраи помогали, обычно добавляют:

лимит числа попыток;

экспоненциальную задержку (backoff);

джиттер (случайное “размазывание” повторов во времени);

ретраи только на безопасные ошибки и операции.

Идемпотентность

Идемпотентная операция — повтор выполнения даёт тот же результат, что и одно выполнение.

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

Circuit breaker

Circuit breaker — механизм, который временно “отрубает” вызовы к проблемной зависимости, чтобы:

не перегружать её дальше;

быстро возвращать контролируемую ошибку;

дать системе шанс восстановиться.

Понятное описание паттерна: Circuit Breaker.

Bulkhead

Bulkhead (переборка) — изоляция ресурсов по группам, чтобы проблема в одном направлении не “съела” все ресурсы.

Примеры:

отдельные пулы потоков на разные зависимости;

лимиты на число одновременных запросов в один внешний API.

!Как механизмы устойчивости предотвращают каскадный отказ

Очереди и асинхронность: “амортизатор” отказов и пиков

Очередь сообщений и асинхронная обработка помогают, когда:

зависимость временно недоступна;

нагрузка приходит “всплесками”.

Ключевые архитектурные эффекты:

сглаживание пиков и защита downstream-сервисов;

возможность повторной обработки;

отделение приёма запроса от выполнения тяжёлой работы.

Но появляется новая ответственность:

контроль “роста очереди” и времени ожидания;

обработка дублей (снова идемпотентность);

стратегия dead-letter queue для “ядовитых” сообщений.

Деградация функциональности: graceful degradation

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

Примеры:

отключить персональные рекомендации, но оставить поиск и покупку;

показывать кэшированную выдачу, если источник данных деградирует;

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

Где это особенно эффективно:

B2C продукты с большим числом некритичных функций;

системы, где ключевой путь узкий и хорошо определён (как в статье про требования).

Отказоустойчивость данных: репликация, кворумы, split-brain

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

Репликация

Репликация — хранение копий данных на нескольких узлах.

Основные режимы:

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

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

Связь с метриками:

требования к RPO напрямую диктуют, приемлема ли асинхронная репликация.

Кворум

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

Эта идея часто встречается в распределённых хранилищах и системах консенсуса. Для презентации достаточно тезиса:

кворум снижает риск “разъезда” данных при сетевых проблемах, но увеличивает требования к количеству доступных узлов.

Split-brain

Split-brain — ситуация, когда из-за сетевого разделения две части системы считают себя “главными” и одновременно принимают записи.

Это один из самых опасных сценариев для данных: сервис может выглядеть “живым”, но данные начнут конфликтовать.

Типовые меры защиты:

лидер-выбор (leader election) с надёжным механизмом согласования;

запрет записи без кворума;

явная стратегия разрешения конфликтов (если система это допускает).

Механизмы, связанные с изменениями: чтобы релизы не были основной причиной падений

Большая доля инцидентов связана с изменениями, поэтому архитектура должна поддерживать безопасные выкладки.

Ключевые паттерны:

Rolling update: постепенная замена экземпляров.

Blue-green: два идентичных окружения, переключение трафика между ними.

Canary: выкладка на малую долю трафика с измерением SLI.

Feature flags: включение функциональности “переключателем” без повторной выкладки.

Эти паттерны напрямую помогают MTTR:

если можно быстро отключить фичу или вернуть старую версию, восстановление ускоряется.

Сопоставление механизмов с уровнями требований

Свяжем это с “tier”-шкалой из прошлой статьи.

| Уровень требований | Что обязательно в архитектуре | Частая ошибка | |---|---|---| | Tier 1 | несколько инстансов stateless-слоя, readiness/health-check, балансировка | “у нас два инстанса, значит всё ок”, но без корректного исключения больных узлов | | Tier 2 | устранение SPOF внутри площадки, timeouts/retries/circuit breaker, резервирование БД/очередей | игнорирование каскадных отказов и перегрузок | | Tier 3 | разнесение по AZ, автоматическое переключение между AZ, репликация данных между AZ | думать, что multi-AZ автоматически решает вопросы данных и RPO | | Tier 4 | второй регион, DR-процедуры, проверенное восстановление, понятный RTO/RPO | “бэкапы есть” без регулярных тестов восстановления | | Tier 5 | active-active, глобальная маршрутизация, сложная модель согласованности данных, строгая операционная готовность | недооценка сложности частичных деградаций и стоимости эксплуатации |

Ресурсные затраты: что именно дорожает при добавлении механизмов

Архитектурные механизмы почти всегда увеличивают стоимость владения. Удобно группировать затраты так:

Инфраструктура: дополнительные реплики, несколько AZ/регионов, межзоновой и межрегиональный трафик.

Разработка: идемпотентность, корректные ретраи, миграции без простоя, обработка конфликтов данных.

Эксплуатация: мониторинг, алёртинг, on-call, runbook, обучение и постмортемы.

Тестирование: регулярные проверки фейловера, game days, инъекции отказов.

Хорошая “презентационная” формулировка: отказоустойчивость оплачивается не только железом, но и постоянной сложностью системы.

Мини-шпаргалка для презентации: что говорить про отказоустойчивую архитектуру

Если нужно уместить тему в несколько слайдов, можно идти таким порядком:

Определить границы отказа (fault domains) и убрать SPOF.

Обеспечить резервирование и автоматический failover на уровне stateless-слоя.

Защититься от деградации зависимостей (timeouts, retries с ограничениями, circuit breaker, bulkhead).

Продумать данные: репликация, стратегия записи, защита от split-brain.

Добавить graceful degradation для некритичных функций.

Сделать изменения безопасными (canary/blue-green/feature flags), чтобы MTTR был управляемым.

Полезные источники

AWS Well-Architected Framework: Reliability Pillar

Google SRE Book: Service Level Objectives

Circuit Breaker

Итоги

Отказоустойчивость строится вокруг границ отказа, резервирования и автоматического failover.

Основной практический риск в распределённых системах — каскадные отказы из-за деградации зависимостей, поэтому timeouts/retries/circuit breaker/bulkhead критичны.

Самая сложная часть устойчивости обычно связана с данными: репликацией, кворумами и защитой от split-brain.

Чем выше требования (tier), тем сильнее растут не только инфраструктурные затраты, но и сложность разработки, эксплуатации и тестирования.

Ресурсные затраты и компромиссы при внедрении

В предыдущих статьях курса мы:

определили, что такое отказоустойчивость и как её измерять (SLI/SLO, доступность, MTTR, RTO/RPO);

отделили отказоустойчивость от масштабирования и катастрофоустойчивости (DR);

разобрали архитектурные механизмы (redundancy, failover, timeouts/retries/circuit breaker, multi-AZ, active-active).

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

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

Что именно дорожает: карта затрат

Если в презентации показать только “+2 региона”, аудитория обычно думает, что речь про железо. На практике рост затрат происходит по нескольким направлениям.

Инфраструктура

дополнительные экземпляры сервисов и БД

дублирование по зонам доступности (AZ)

резервные кластеры для DR (warm/hot standby)

глобальные балансировщики и маршрутизация

межзоновый и межрегиональный трафик

Отдельный источник расходов, который часто забывают: стоимость сети и хранения (репликация данных, egress-трафик, резервные копии, журналы).

Разработка и архитектурная сложность

идемпотентность операций (особенно для ретраев)

контроль согласованности данных при репликации

миграции без простоя и совместимость версий

проектирование деградации функциональности (graceful degradation)

устранение SPOF в зависимостях и интеграциях

Чем выше уровень (tier) отказоустойчивости, тем чаще “простая фича” превращается в набор изменений в нескольких компонентах.

Эксплуатация

мониторинг, алёртинг и поддержка SLO

дежурства (on-call), инцидент-менеджмент, постмортемы

runbook и регулярная актуализация процедур

управление секретами, сертификатами, доступами

Важно: отказоустойчивость без операционной готовности часто даёт иллюзию надёжности. Например, failover есть, но никто не знает, как он реально происходит и кто принимает решение.

Тестирование и подтверждение готовности

отдельные стенды (иногда близкие к production)

регулярные тесты восстановления из бэкапов

проверки переключения (failover drills)

game days и контролируемые эксперименты с отказами

Для “взрослых” требований это не опция, а часть стоимости владения.

!Схема, показывающая, что стоимость отказоустойчивости складывается из нескольких типов затрат

Почему “каждая следующая девятка” дороже

Инженерно это выглядит так: базовые отказы (падение одного инстанса) закрываются относительно дешёво, а редкие и сложные сценарии (сетевые разделения, split-brain, потеря зоны, ошибки изменений, отказ провайдера) требуют непропорционально больших инвестиций.

Практическая формулировка для выступления:

первые улучшения дают быстрый эффект (убрать SPOF, добавить реплики, настроить health-check)

дальше начинает дорожать сложность данных и операционная дисциплина

Компромиссы: что вы получаете и что теряете

Повышение отказоустойчивости почти всегда означает обмен одного риска на другой.

Доступность против простоты

больше резервов и автоматизации снижает простой

но увеличивает число компонентов, конфигураций и сценариев, которые могут “сложиться” в инцидент

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

Автоматический failover против предсказуемости

автоматический failover улучшает MTTR

но требует очень качественных health-check, правильных порогов и защиты от “флапа” (частого переключения туда-сюда)

Ручной failover дешевле в реализации, но дороже в простое и зависит от человеческого фактора.

Консистентность данных против непрерывности

Когда вы переходите от одной копии данных к нескольким, появляется выбор:

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

высокая доступность с активной записью в нескольких местах усложняет разрешение конфликтов и повышает риск некорректных данных

Это не абстракция: для платёжных и учётных систем ошибки данных часто дороже простоя.

!Треугольник, который помогает объяснить неизбежные компромиссы

Затраты по типовым механизмам: что добавляет каждый шаг

Ниже — практичная “шпаргалка”: какие ресурсы чаще всего требуются при внедрении конкретных механизмов.

Резервирование stateless-слоя (несколько экземпляров приложения)

рост инфраструктуры умеренный

рост сложности разработки низкий (если сервис stateless)

выигрыш по MTTR высокий, если есть корректные readiness/health-check

Скрытый компромисс: требуется запас мощности (N+1), иначе при падении узла оставшиеся экземпляры могут уйти в перегрузку.

Multi-AZ

инфраструктура дорожает заметно из-за дублирования

растёт стоимость сети (межзоновый трафик)

возрастает сложность данных и конфигураций

Типичный компромисс: придётся выбирать, какие данные реплицировать синхронно, а какие асинхронно, чтобы не “убить” задержки.

DR во втором регионе

инфраструктура дорожает сильно (особенно если standby не холодный)

появляется постоянная работа по поддержанию готовности DR

обязательны регулярные тесты восстановления

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

Active-active

дорогая инфраструктура и дорогая сеть

самая высокая сложность данных (конфликты записи, согласование)

сложнее эксплуатация: больше классов инцидентов и “серых” деградаций

Компромисс: часто приходится упрощать бизнес-операции или принимать ограничения по консистентности.

Скрытые статьи расходов, которые часто не попадают в бюджет

Ошибки изменений как главный источник инцидентов

Частая ситуация: команда вкладывается в multi-AZ, но основные падения происходят из-за релизов и миграций.

Тогда реальные инвестиции в отказоустойчивость выглядят так:

canary или blue-green выкладки

feature flags для быстрого отключения функциональности

автоматизированный rollback

контроль изменений через SLO и error budget

Подход с error budget хорошо описан в книге Google SRE: Site Reliability Engineering: Service Level Objectives.

Наблюдаемость и “стоимость тишины”

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

метрики, логи, трассировка

алёрты, которые не шумят и действительно отражают пользовательский SLI

обучение дежурных и поддержка runbook

Компромисс: чем больше сигналов, тем выше риск алёрт-усталости, поэтому наблюдаемость нужно проектировать, а не “наваливать метрики”.

Тестирование отказов

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

тестирование восстановления из бэкапов

регулярные учения (game days)

fault injection и chaos engineering в контролируемом виде

Как ориентир по принципам подхода: Principles of Chaos Engineering.

Как оценивать выгоду без сложной математики

Для презентации обычно достаточно связать затраты с понятным бизнесу риском.

Определите критичные пользовательские пути.

Зафиксируйте, что считается недоступностью (SLI).

Согласуйте цель (SLO) и допустимое время восстановления (MTTR).

Сформулируйте последствия простоя и деградации.

Сопоставьте последствия с уровнем (tier) и набором механизмов.

Полезно обсуждать не только “стоимость простоя”, но и “стоимость ошибки данных” и “стоимость ручных операций”.

Практическая таблица для слайда: механизм → выгода → цена

| Механизм | Что улучшает | Что обычно дорожает | Типичный компромисс | |---|---|---|---| | Несколько инстансов + балансировка | доступность при падении узла, MTTR | инфраструктура, деплой-процессы | нужен запас мощности N+1 | | Health-check и auto-healing | MTTR, снижение ручной работы | настройка порогов, наблюдаемость | риск флапа и ложных срабатываний | | Timeouts/retries/circuit breaker | защита от каскадов | разработка, тестирование | риск “быстрого отказа” для части пользователей | | Multi-AZ | устойчивость к отказу AZ | дублирование, сеть, данные | усложнение репликации и согласованности | | DR во втором регионе | RTO/RPO при потере региона | инфраструктура, процедуры, учения | постоянная стоимость готовности | | Active-active | максимальная непрерывность | всё: infra, данные, эксплуатация | конфликты данных, сложные инциденты |

Если нужен общий ориентир по “правильным вопросам” к архитектуре, можно ссылаться на: AWS Well-Architected Framework: Reliability Pillar.

Стратегия внедрения: как повышать отказоустойчивость без переплаты

Типовой порядок работ, который хорошо выглядит и на практике, и на слайдах.

Сформулировать SLO на критичные пользовательские пути.

Убрать очевидные SPOF и обеспечить stateless-слой.

Добавить защиту от каскадных отказов (timeouts, ограниченные retries, circuit breaker).

Поднять наблюдаемость и сократить время обнаружения.

Автоматизировать реакции и восстановление (auto-healing, runbook).

После этого принимать решение о multi-AZ и DR, исходя из требований.

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

Что сказать в презентации, чтобы разговор был конструктивным

говорить про уровни требований (tiers) и метрики, а не про технологии

показывать структуру затрат, а не только инфраструктуру

явно назвать компромиссы по данным и операционной сложности

предлагать поэтапный план, где каждый этап даёт измеримый эффект в SLO/MTTR

Итоги

Ресурсные затраты на отказоустойчивость состоят из инфраструктуры, разработки, эксплуатации и тестирования.

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

Автоматизация и резервирование улучшают MTTR и доступность, но увеличивают сложность системы и классы возможных инцидентов.

Оптимальная стратегия обычно поэтапная: от SLO и устранения SPOF к защите от каскадов, затем к multi-AZ и DR по реальным требованиям.

Примеры заказчиков: типовые архитектуры по отрасли и масштабу

В предыдущих статьях курса мы:

договорились о метриках (SLI/SLO, доступность, MTTR, RTO/RPO);

отделили отказоустойчивость от масштабирования и катастрофоустойчивости (DR);

разобрали основные механизмы (резервирование, failover, timeouts/retries, circuit breaker, multi-AZ, active-active);

обсудили стоимость и компромиссы.

Эта статья помогает подготовить презентацию: показывает типовые классы заказчиков и архитектурные силуэты, которые чаще всего встречаются в реальности. Идея простая: требования (SLO, MTTR, RTO/RPO) почти всегда определяются отраслью и ценой ошибки, а архитектура является следствием этих требований.

Как читать примеры в статье

Чтобы примеры были переносимы на вашу систему, используем два измерения.

Отрасль и риск: деньги, регуляторика, репутация, безопасность, цена потери данных.

Масштаб: трафик, география, число интеграций, частота изменений.

Для привязки к предыдущей статье про уровни требований будем использовать условные уровни:

Tier 0–1: базовая надёжность и устойчивость stateless-слоя.

Tier 2–3: устойчивость внутри площадки и multi-AZ (переживаем отказ зоны доступности).

Tier 4–5: DR и active-active на уровне регионов.

!Матрица, которая связывает тип заказчика, масштаб и целевой уровень отказоустойчивости

Базовый набор архитектурных блоков (единый словарь)

Далее примеры будут собираться из повторяющихся блоков.

Stateless-слой: сервисы, которые не хранят важное состояние на конкретном экземпляре (любой экземпляр можно заменить без потери данных).

Stateful-слой: компоненты, хранящие состояние (база данных, брокер сообщений, хранилище файлов).

Multi-AZ: разнесение по зонам доступности внутри региона, чтобы переживать потерю одной зоны.

DR (disaster recovery): восстановление в другом регионе по заранее заданным RTO/RPO.

Active-passive: один контур обслуживает трафик, второй в ожидании (или частично прогрет).

Active-active: несколько контуров одновременно обслуживают трафик.

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

Circuit breaker: механизм, который временно прекращает вызовы к проблемной зависимости, чтобы избежать каскадного отказа.

Типовые заказчики и их архитектурные силуэты

Ниже приведены отраслевые примеры. Это не единственно возможные варианты, но они хорошо подходят для слайдов: показывают, что обычно считается критичным и почему выбирают именно такой tier.

Внутренние системы и MVP

Тип заказчика: внутренние порталы, админки, ранний продукт.

Что критично:

скорость разработки важнее “девяток”;

допустим простой, но важно не потерять данные полностью.

Типичный уровень: Tier 0–1.

Силуэт архитектуры:

1 среда (один регион/зона), несколько инстансов приложения за балансировщиком;

одна база данных, бэкапы, ручное восстановление;

базовый мониторинг и алёрты на доступность.

Риски и типовые ошибки:

делать “почти production” без регулярной проверки восстановления из бэкапов;

держать состояние на экземпляре приложения (нарушать stateless), из-за чего простое масштабирование и перезапуски становятся опасными.

B2B SaaS с SLA для корпоративных клиентов

Тип заказчика: CRM/ERP/аналитика, платформенные API, интеграции.

Что критично:

предсказуемая доступность API и основных функций;

контроль деградаций зависимостей (часто много внешних интеграций);

договорные обязательства по SLA.

Типичный уровень: Tier 1–3.

Силуэт архитектуры:

Несколько экземпляров stateless-сервисов, health-check и автоматическое исключение “больных” узлов.

База данных с репликой и понятной процедурой переключения (в идеале автоматической).

Изоляция интеграций: таймауты, ограниченные ретраи, circuit breaker.

Очереди для фоновых задач (экспорт, синхронизации, отчёты).

Почему так:

SLA часто требует управляемого MTTR и понятного процесса инцидентов;

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

E-commerce и сервисы оформления заказа

Тип заказчика: интернет-магазины, доставка, маркетплейсы.

Что критично:

критичный путь “каталог → корзина → оформление → оплата”;

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

Типичный уровень: Tier 2–3, иногда Tier 4 для крупных игроков.

Силуэт архитектуры:

multi-AZ для stateless-сервисов и ключевых зависимостей;

отдельные компоненты для критичных операций (заказ, платёж) с повышенным вниманием к данным;

очередь как “амортизатор”: принять заказ и обработать части процесса асинхронно (уведомления, рекомендации, некоторые проверки);

кэширование и graceful degradation для некритичных функций.

Точки внимания для презентации:

отказоустойчивость здесь часто начинается с определения SLO именно для создания заказа и платежа, а не “для сайта в целом”;

ретраи на платёжных операциях требуют идемпотентности (повтор не должен создавать второй заказ или второе списание).

Финтех, платежи, учётные системы

Тип заказчика: платёжные шлюзы, банки, бухгалтерский учёт, биллинг.

Что критично:

целостность данных и минимальная потеря данных (жёсткий RPO);

прослеживаемость операций (аудит), строгие требования к изменениям;

простои дороги, но “тихая порча данных” ещё дороже.

Типичный уровень: Tier 3–4, иногда Tier 5 для очень высокой непрерывности.

Силуэт архитектуры:

Multi-AZ как базовая линия.

Отдельный контур DR во втором регионе (active-passive) с измеримыми RTO/RPO.

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

Минимизация каскадов: агрессивные таймауты, лимиты, circuit breaker, очереди.

Компромисс:

active-active по двум регионам резко усложняет данные (конфликты записи), поэтому часто выбирают active-passive с хорошей автоматизацией переключения и регулярными тренировками.

Медиа, стриминг, контент-платформы

Тип заказчика: видео/аудио стриминг, новостные порталы, CDN-подобные системы.

Что критично:

непрерывность выдачи контента и низкие задержки;

данные часто допускают более “мягкую” согласованность (например, лайки или просмотры могут догонять), но недоступность проигрывает бизнесу.

Типичный уровень: Tier 3–5 (зависит от глобальности аудитории).

Силуэт архитектуры:

active-active для чтения (выдача контента) в нескольких регионах;

запись часто централизуют или делают “пакетной”, чтобы не ловить конфликты;

агрессивная деградация: при проблемах показывать кэш, упрощать персонализацию;

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

Почему так:

аудитория глобальная, а “переключиться за час” часто неприемлемо;

многие системы могут позволить себе упрощения по данным ради непрерывности.

Промышленность, IoT, телеметрия

Тип заказчика: сбор телеметрии, мониторинг оборудования, “умные” устройства.

Что критично:

непрерывный приём событий и устойчивость к “шумным” сетям;

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

Типичный уровень: Tier 2–4.

Силуэт архитектуры:

ingestion-слой, рассчитанный на пики (часто через брокер сообщений);

буферизация и локальные очереди, чтобы переживать разрывы связи;

разделение потоков: критичные события обрабатываются отдельно от “массовой” метрики;

DR часто строится вокруг восстановления потока и хранения, а не вокруг “веб-части”.

Точки внимания:

в презентации важно разделить “доступность API” и “непрерывность приёма событий”: это разные SLI.

Госуслуги и системы с пиковыми нагрузками по расписанию

Тип заказчика: порталы подачи заявлений, записи, отчётность.

Что критично:

устойчивость в пиковые периоды и предсказуемая работа ключевых операций;

часто есть формальные требования к процессам и восстановлению.

Типичный уровень: Tier 2–4.

Силуэт архитектуры:

разделение фронт-слоя и бэкенд-обработки через очереди;

режимы деградации: “приняли заявление, обработаем позже” вместо “сервис недоступен”;

подготовленный DR-план (особенно если система критична и публична).

Типовая ошибка:

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

Масштаб как фактор архитектуры: один и тот же бизнес, разные решения

Отрасль задаёт риск, а масштаб задаёт, насколько дорого и сложно будет выполнять требования.

Малый масштаб: 1–2 команды, редкие релизы

чаще всего достаточно Tier 1–2;

основной выигрыш дают: устранение SPOF, health-check, наблюдаемость, быстрый rollback;

DR чаще строят на бэкапах и проверенных процедурах, без постоянного второго региона.

Средний масштаб: несколько команд, много интеграций

часто переходят к Tier 2–3;

появляется необходимость изоляции отказов между доменами (лимиты, circuit breaker, отдельные очереди);

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

Большой масштаб: высокая цена простоя, глобальная аудитория

Tier 3–5 становится нормой;

появляется глобальная маршрутизация и частичные деградации как “обычный режим аварии”;

тестирование отказов и изменения (canary, feature flags) становятся частью ежедневной инженерной практики.

Быстрые “рецепты” для слайдов: что показать на одной диаграмме

Для презентации обычно полезно иметь 1–2 схемы, которые узнаваемы для аудитории.

Рецепт: Tier 2–3 для большинства B2C/B2B продуктов

!Типовая схема multi-AZ для сервисов с критичным пользовательским путём

Рецепт: Tier 4 (DR) для систем с высокой ценой простоя и данных

основной регион (active), второй регион (standby);

репликация данных и/или регулярные бэкапы;

переключение по runbook или автоматизировано;

регулярные учения, иначе DR “не существует”.

Таблица-шпаргалка: отрасль → что критично → типовой tier → характерные механизмы

| Отрасль/тип системы | Что обычно критично | Типовой tier | Характерные механизмы | |---|---|---|---| | MVP/внутренние системы | скорость разработки, базовое восстановление | Tier 0–1 | бэкапы, базовый мониторинг, несколько инстансов приложения | | B2B SaaS | доступность API, SLA, интеграции | Tier 1–3 | multi-инстанс, реплика БД, timeouts/retries, circuit breaker, очереди | | E-commerce | заказ и оплата, быстрое восстановление | Tier 2–3 | multi-AZ, идемпотентность, очереди, graceful degradation | | Финтех/биллинг | целостность данных, строгий RPO, аудит | Tier 3–4 | multi-AZ, DR, строгий контроль изменений, журналирование | | Медиа/контент | непрерывная выдача, низкая задержка | Tier 3–5 | active-active для чтения, кэширование, деградация, глобальная маршрутизация | | IoT/телеметрия | непрерывный приём событий | Tier 2–4 | брокер сообщений, буферизация, разделение критичных потоков, DR для хранения |

Как использовать эти примеры в вашей презентации

Практичный шаблон “как рассказывать”:

Назвать тип заказчика и критичный пользовательский путь.

Назвать метрики, которые важнее всего (SLO и MTTR, а при необходимости RTO/RPO).

Показать 1 схему с fault domains (например, две AZ) и 3–5 ключевых механизмов.

Сразу назвать главный компромисс (обычно данные или стоимость эксплуатации).

Сказать, как вы будете подтверждать отказоустойчивость (фейловер-дриллы, тесты восстановления, game days), не углубляясь в инструменты.

Если нужна универсальная структура вопросов для надёжности (подходит как чеклист для подготовки слайдов), полезный источник: AWS Well-Architected Framework: Reliability Pillar.

Итоги

Типовая архитектура почти всегда определяется сочетанием отраслевого риска и масштаба, а не модой на инструменты.

Для презентации удобны “силуэты”: Tier и 5–7 ключевых блоков (multi-инстанс, failover, multi-AZ, очереди, защита от каскадов, деградация, DR).

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

Тестирование отказоустойчивости: методики, инструменты, сценарии

Отказоустойчивость нельзя подтвердить диаграммой или набором технологий. В прошлых статьях курса мы зафиксировали метрики (SLI/SLO, MTTR, RTO/RPO), определили уровни требований (tiers) и разобрали механизмы (резервирование, failover, защита от каскадов, multi-AZ, DR). Эта статья закрывает практический вопрос: как доказать, что система действительно переживает отказы, и как подготовить материалы для выступления и презентации.

Ключевая мысль: тестирование отказоустойчивости должно проверять наблюдаемое качество сервиса (SLI) при сбоях и управляемость восстановления (MTTR/RTO/RPO), а не факт “переключение вроде произошло”.

Что именно мы проверяем

Тестирование отказоустойчивости отвечает на три вопроса:

Сервис продолжает выполнять критичный пользовательский путь при отказах? (проверяется по SLI)

Время восстановления укладывается в требования? (MTTR, а для крупных событий RTO)

Данные не теряются и не портятся сверх допустимого? (RPO и проверки целостности)

Важно заранее определить:

критичные пользовательские пути (например, “создание заказа”, “платёж”, “вход”);

что считается недоступностью для этих путей (ошибка, таймаут, p95 задержка выше порога, некорректный результат);

границы отказа (fault domains), которые вы обещаете переживать (инстанс, узел, AZ, регион).

Методики тестирования отказоустойчивости

Ниже методики, которые чаще всего применяют вместе. Они отличаются степенью реализма, риском и тем, что именно подтверждают.

Failover drills

Failover drill — повторяемая проверка переключения на резервные компоненты.

Что проверяет:

корректность health-check и автоматики переключения;

фактический MTTR при типовом отказе;

отсутствие скрытых зависимостей и единых точек отказа.

Типовые примеры:

выключить одну реплику приложения и убедиться, что балансировщик перестал отправлять на неё трафик;

инициировать failover базы данных и проверить успешность критичных операций.

Тестирование восстановления (backup/restore)

Это проверка, что бэкапы реально восстанавливаются и дают ожидаемый RPO.

Что проверяет:

что бэкап существует, пригоден и соответствует ожиданиям по свежести;

что процедура восстановления выполняется за приемлемое время (часть RTO);

что после восстановления данные консистентны и сервис способен работать.

Практический ориентир по подходу и проверкам восстановления в облаке: AWS Well-Architected Framework Reliability Pillar.

Game day

Game day — учение, в котором команда проигрывает инцидент по сценарию (часто с реальным внесением изменений в систему) и отрабатывает обнаружение, коммуникации, восстановление и постанализ.

Что проверяет:

операционную готовность: алёрты, on-call, runbook;

человеческие и процессные задержки в MTTR (время до обнаружения, до реакции, до решения);

готовность принимать решения о деградации (graceful degradation) и переключениях.

Fault injection и chaos engineering

Fault injection — внесение отказов или деградаций в контролируемом виде.

Chaos engineering — дисциплина, где вы формулируете гипотезу о “стабильном состоянии” системы и проверяете её экспериментами, постепенно расширяя blast radius.

Полезная точка входа в принципы: Principles of Chaos Engineering.

Типовые эффекты, которые инъецируют:

убийство процесса или контейнера;

потеря узла;

задержки сети и потери пакетов;

ограничения CPU/памяти;

деградация зависимостей (ошибки, таймауты).

Нагрузочные тесты с отказами

Отдельно стоит выделить режим load + failure: когда система под нагрузкой, а вы добавляете отказ.

Что проверяет:

что запас мощности (N+1) реален, и при падении узла оставшиеся не уходят в перегрузку;

что ретраи и таймауты не приводят к каскадному отказу;

что при деградации зависимостей система “ломается контролируемо”.

Как безопасно планировать эксперименты

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

!Жизненный цикл эксперимента: от цели и гардрейлов до верификации и постанализа

Практический шаблон планирования:

Определите цель: какая способность подтверждается (например, “переживаем падение узла приложения без нарушения SLO оплаты”).

Зафиксируйте стабильное состояние: какие SLI должны быть “нормальными” перед началом.

Опишите сценарий: что ломаем, на сколько минут, в каком окружении.

Определите гардрейлы: пороги ошибок/задержек, при которых эксперимент немедленно прекращается.

Ограничьте blast radius: начните с небольшой доли трафика, одного сервиса, одного AZ (если это допустимо).

Подготовьте план отката: кто и как возвращает систему в норму.

Проведите верификацию: SLI, метрики данных, очередь/бэклог, бизнес-индикаторы.

Задокументируйте выводы: что сломалось в архитектуре или процессе, какие изменения нужны.

Библиотека сценариев: что стоит тестировать

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

Сценарии уровня Tier 1–2

Падение одного экземпляра приложения.

Падение узла (node) в кластере.

Флап readiness: сервис жив, но не готов обслуживать запросы.

Деградация внешней зависимости: рост задержек, частичные ошибки.

Каскадный риск: ретраи создают дополнительную нагрузку на зависимость.

Проверяемые ожидания:

балансировщик и оркестратор исключают “больной” экземпляр;

система не уходит в перегрузку после потери части мощности;

таймауты и circuit breaker ограничивают радиус поражения;

деградация некритичных функций сохраняет критичный путь.

Сценарии уровня Tier 3 (multi-AZ)

Потеря зоны доступности (AZ) для stateless-слоя.

Потеря AZ для stateful-зависимости (в рамках поддерживаемой топологии).

Сетевое разделение между AZ (частичная деградация хуже полного падения).

Проверяемые ожидания:

трафик уходит в оставшуюся AZ автоматически и быстро;

база и очереди корректно переключаются или сохраняют доступность в рамках модели;

нет split-brain поведения на уровне данных (если применимо к вашему стеку).

Сценарии уровня Tier 4–5 (DR и межрегиональные схемы)

Принудительное переключение на DR-регион по runbook.

Восстановление из бэкапов в DR и проверка RPO.

Деградации глобальной маршрутизации и “серые” частичные отказы.

Проверяемые ожидания:

фактический RTO достигается в реальной процедуре, а не на диаграмме;

фактический RPO подтверждается (по меткам времени или журналам операций);

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

Сценарии для данных и интеграций

Эти сценарии часто определяют реальную надёжность, даже если приложение легко перезапускается.

Дубликаты сообщений в очереди и повторная доставка.

“Ядовитое” сообщение, которое постоянно ломает обработчик (нужен dead-letter queue).

Потеря соединения с базой в момент транзакции.

Истечение сертификата или недоступность секрет-хранилища.

Проверяемые ожидания:

идемпотентность ключевых операций;

отсутствие “двойных списаний” и дублей заказов;

корректные ретраи, которые не усиливают аварию;

наблюдаемость позволяет быстро локализовать проблему.

Что и как измерять во время тестов

Важно измерять не “внутренние” технические метрики сами по себе, а влияние на сервис.

SLI и пользовательские проверки

Типовой набор:

доля успешных запросов по критичным операциям;

p95 или p99 задержки критичных операций;

доля успешных бизнес-событий (созданных заказов, успешных оплат);

корректность результата (например, заказ создан ровно один раз).

Метрики устойчивости к каскадам

рост очередей и время ожидания в очереди;

насыщение пулов соединений и потоков;

частота ретраев и доля запросов, прерванных circuit breaker.

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

время обнаружения и эскалации (если вы это фиксируете);

время до восстановления SLI до нормы;

время до полной стабилизации (когда ушли бэклоги, восстановились фоновые процессы).

Инструменты: чем обычно проводят тесты

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

Инструменты для chaos и fault injection

Chaos Mesh для Kubernetes.

LitmusChaos для Kubernetes.

Netflix Chaos Monkey для случайного завершения экземпляров (исторически для AWS).

Инструменты для проверки распределённых систем и консистентности

Jepsen для проверки корректности распределённых систем при сетевых сбоях и разделениях.

Нагрузочное тестирование

k6 для генерации нагрузки и сценариев тестирования.

Apache JMeter для нагрузочных сценариев.

Наблюдаемость как обязательная часть

Без наблюдаемости тест превращается в “мы что-то выключили и ничего не поняли”. На практике используют связки метрик, логов и трассировки, но выбор конкретного стека вторичен по отношению к тому, что вы измеряете.

Типовой план внедрения тестирования отказоустойчивости

Чтобы не пытаться сделать всё сразу, удобно идти ступенчато.

Сформировать SLO для критичных пользовательских путей и договориться о SLI.

Настроить минимально достаточную наблюдаемость под эти SLI.

Ввести регулярные failover drills для самых частых отказов (инстанс, узел, ключевая зависимость).

Ввести регулярные backup/restore тесты и фиксировать фактические RTO/RPO.

Проводить game days для отработки процессов и снижения “человеческой” части MTTR.

Добавлять fault injection, начиная со staging, затем production с ограниченным охватом.

Включать load + failure сценарии перед важными релизами и сезонными пиками.

Типовые ошибки при тестировании отказоустойчивости

Тестировать “переключение”, не проверяя SLI критичной операции.

Не ограничивать blast radius и проводить эксперименты без гардрейлов.

Делать тесты только на пустом стенде без реалистичной нагрузки.

Не проверять целостность данных и идемпотентность при ретраях.

Не фиксировать результаты в виде метрик и задач улучшений, из-за чего тесты не меняют систему.

Как упаковать результаты для презентации

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

Требования: критичные пользовательские пути и их SLO, плюс целевой MTTR/RTO/RPO.

Матрица тестов: какие сценарии вы регулярно проверяете и где (staging, production, game day).

Факты: измеренный MTTR/RTO/RPO и найденные проблемы с планом исправления.

Удобная форма для “матрицы тестов”:

| Сценарий | Уровень (tier) | Что подтверждаем | Где выполняем | Какой артефакт остаётся | |---|---|---|---|---| | Падение инстанса приложения | Tier 1 | SLI не падает, MTTR в минутном диапазоне | staging, затем production с малым охватом | отчёт, графики SLI, список улучшений | | Деградация внешнего API | Tier 2 | circuit breaker и таймауты ограничивают каскад | staging | запись эксперимента, настройки порогов | | Потеря AZ | Tier 3 | авто-переключение трафика и работоспособность критичного пути | по возможности production в окно | runbook, измеренный MTTR | | Restore из бэкапа | Tier 0–4 | RPO и жизнеспособность данных | staging/DR-стенд | протокол восстановления, фактическое время | | DR failover | Tier 4 | достижение RTO и корректность данных | учения | runbook, результаты учений |

Итоги

Тестирование отказоустойчивости должно подтверждать SLI/SLO, MTTR и при необходимости RTO/RPO.

Самые практичные методики: failover drills, backup/restore, game days, fault injection, нагрузочные тесты с отказами.

Без наблюдаемости и проверок данных отказоустойчивость остаётся “на диаграмме”.

Для презентации важно показывать не инструменты, а связку: требования → сценарии → измеренные результаты → план улучшений.