Модуль 10. Chaos Engineering и Cost Awareness: доказательство надёжности и ROI

Цель модуля: Научить студента доказывать отказоустойчивость системы эмпирическим путём через контролируемые эксперименты (Chaos Engineering). Связать технические метрики (RTO, Error Budget) с бизнес-метриками (Cost Awareness — стоимость простоя и ROI избыточной инфраструктуры).

Стадия роста проекта: Зрелость. Проект пережил интеграции, Outbox, Saga, Resilience, Observability, Security, IaC и масштабирование БД. Система работает 24/7, метрики прозрачны, инфраструктура в Terraform. Но идеальные метрики — это ещё не доказательство надёжности. Как убедиться, что Circuit Breaker сработает, Saga откатится, а failover БД произойдёт за секунды, а не минуты? Гипотеза отказоустойчивости без эксперимента — вера, а не инженерия.

Перед началом: Модули 1–9 (особенно Resilience — CB/Saga, IaC — Multi-AZ, Эволюция БД — failover) Инструменты: Chaos Mesh, Toxiproxy, k6, Grafana, Alertmanager Трудоёмкость: ~6 ч (теория 1.5 ч · практика 4 ч · постмортем + ROI 0.5 ч)

🔥 Инцидент: «стабильно» — недостаточно

Инфраструктура в Terraform (Модуль 8), PgBouncer держит коннекты, read-реплики разгружают мастер (Модуль 9). В Grafana — идеальная картина: p99 = 180 мс, Error Rate 0.03%, HPA держит. Но в понедельник — сообщение от CTO: «Метрики в норме, но мне не нравится слово "стабильно". Подготовь Game Day на среду: убей 50% воркеров, добавь 5 секунд задержки к БД, проверь failover мастера. И дай ROI: сколько платим за отказоустойчивость и сколько теряем, если она не сработает».

Идеальные метрики — это и есть проблема. Если всё всегда «зелёное», как доказать, что Circuit Breaker (Модуль 5) вообще нужен? Что Saga (Модуль 4) не зависнет при потере воркера? Что failover БД сработает за секунды, а не минуты? Гипотеза отказоустойчивости без эксперимента — это вера, а не инженерия.

Ты проверяешь Error Budget (Модуль 6): сожжено 35% — значит, можно запускать. Три эксперимента:

Pod Kill 50% — HPA поднимает новые поды за 50 сек. Saga не зависает, платежи не теряются.
Network Latency 5 сек — CB переходит в Open, ретраи с Backoff+Jitter, БД не ложится.
DB Failover — RTO 47 секунд. Система выдерживает.

И главное — ROI: текущая инфраструктура 120 000 ₽/мес. Час простоя — 50 000 ₽. Улучшение (снижение RTO с 3 мин до 45 сек) экономит 2 ч простоя/мес = 100 000 ₽ при росте cost на 30 000 ₽. Чистая выгода — 70 000 ₽/мес.

Отказоустойчивость без экспериментов — гипотеза. Chaos Engineering превращает «мы думаем, система выдержит» в «мы доказали: RTO 47 сек, ROI +70 000 ₽/мес».

Связь с Serverless MVP: если ты прошёл курс «Git Hosting: Serverless MVP», ты уже настраивал cost-алерты на free-tier лимиты YDB (RU/с) и Cloud Functions (invocations). Здесь тот же принцип Cost Awareness масштабируется на полный стек: не только «не выйти за free-tier», но и «окупается ли избыточная отказоустойчивость». Паттерн тот же — инфраструктура разная.

📖 Теория: Раскрытые термины

Глоссарий модуля:

Chaos Engineering — дисциплина: проверка устойчивости системы контролируемыми экспериментами (внедрение сбоев по гипотезе), а не случайными поломками.
Steady State — нормальное состояние системы по метрикам (baseline), от которого отталкивается эксперимент.
Blast Radius — радиус поражения: какую часть системы затронет эксперимент (начинают с 1 пода / 10% трафика).
Abort Conditions — метрики, при которых эксперимент немедленно прекращается (например, Error Rate > 5%).
Game Day — плановое учение: команда намеренно «ломает» часть системы и наблюдает реакцию.
ROI (Return on Investment) — окупаемость: выгода от инвестиций в отказоустойчивость минус стоимость избыточной инфраструктуры.
Cost of Downtime — стоимость часа простоя системы; база для ROI-расчёта.
Chaos Mesh — инструмент Chaos Engineering для K8s: убивает поды, добавляет latency, packet loss, CPU pressure.
Toxiproxy — прокси между сервисом и зависимостью (БД, Kafka), симулирующий сетевые сбои (latency, timeout, drop).

10.1. Хаос-инжиниринг: методология

Это не «случайно ломать продакшен». Это дисциплина с четырьмя принципами:

Steady State (устойчивое состояние). Базовые метрики в норме (Error Rate < 0.1%, p99 < 200 мс). Эксперимент отталкивается от baseline и проверяет, что система возвращается к нему.
Гипотеза. Каждый эксперимент начинается с утверждения: «При отказе 50% воркеров HPA поднимет новые, и Saga не зависнет». После эксперимента гипотеза подтверждается или опровергается.
Blast Radius (радиус поражения). Начинаем с минимального воздействия: 1 под, 10% трафика, одна зона. Расширяем только когда эксперимент на малом радиусе прошёл.
Abort Conditions (условия отмены). При каких метриках (Error Rate > 5%, p99 > 2 сек) эксперимент немедленно прекращается автоматически. Это защищает от «эксперимент вышел из-под контроля».

Безопасность: доступ к Chaos Mesh строго ограничен (RBAC). Эксперименты запускаются через CI/CD с апрувом, используются namespace/label selectors, чтобы случайно не затронуть critical-сервисы.

10.2. Инструменты и их риски

Инструмент	Среда	Что делает	Риск
Chaos Mesh	K8s	Убивает поды, забивает CPU, рвёт сеть	Если упадёт во время эксперимента — сам станет SPOF; изолировать
Toxiproxy	Сеть	Latency, Packet Loss между сервисом и зависимостью	Ставить строго между конкретным сервисом и зависимостью (Go → PostgreSQL)
k6	Нагрузка	Генерирует трафик для проверки пропускной способности	Не путать с хаосом: k6 — throughput, хаос — устойчивость к сбоям

Для Serverless: нет подов. Хаос внедряется через Toxiproxy или эмуляцию HTTP-ошибок (503) в коде.

10.3. Отказ целой зоны (AZ Failure) и DB Failover

Отключение зоны в ALB проверяет только балансировку трафика. Для полноценной проверки нужно симулировать отказ мастера БД и убедиться, что Managed PostgreSQL переключился на реплику, а приложение переподключилось без 500-х ошибок. Связь с Модулем 9 (Эволюция БД): read-your-writes при failover, PgBouncer reconnect.

10.4. Cost Awareness: финансовая осознанность

Архитектор отвечает за деньги. Избыточная отказоустойчивость стоит дорого.

Error Budget как тормоз. Если использовано > 80% Error Budget (из Модуля 6), Chaos-эксперименты приостанавливаются — система уже нестабильна, ломать её дальше рискованно.

ROI отказоустойчивости. Инвестиции в Multi-AZ и HPA должны окупаться через снижение стоимости простоя (Cost of Downtime). Формула:

ROI = (экономия на простое + инцидентах) − (рост cloud-счёта)

Если улучшение снижает простой на 2 ч/мес при стоимости простоя 50 000 ₽/ч (−100 000 ₽) при росте cost на 30 000 ₽ — чистая выгода 70 000 ₽/мес. Это и есть аргумент для CFO.

10.5. Этот паттерн в архетипах

Chaos и Cost проявляются по-разному в четырёх архетипах проектов:

Архетип	Ключевой эксперимент	Cost-метрика	Почему критично
Финтех	DB Failover (RTO < 1 мин), Pod Kill Saga-воркеров	Стоимость простоя платежей (₽/час)	Двойное списание при откате недопустимо
Git-хостинг	Storage Node Kill (failover на реплику репо), Network Latency на clone	IOPS NVMe, стоимость CDN	`git clone` крупного репо — долгая операция, обрыв = повтор
Мессенджер	WebSocket-коннекты при Pod Kill, Delivery-очередь	Стоимость доставки push (per message)	Недоставленное сообщение = жалоба пользователя
Лента	Cache Stampede при отказе Redis, CQRS projection lag	Стоимость ClickHouse-запросов	Лавина на БД при протухшем кэше

Общий принцип: Chaos проверяет конкретный паттерн из предыдущих модулей (Saga, CB, failover), Cost обосновывает, окупается ли этот паттерн. Различается только критичный сбой и стоимость простоя.

10.6. Компромиссы (Trade-offs)

Решение	Плюс	Минус	Когда выбирать
Chaos в Production	реалистичные условия (настоящая нагрузка, данные)	риск для клиентов; цена ошибки — инцидент	зрелая система с мониторингом и Abort Conditions
Chaos в Staging	безопасно; нет риска для клиентов	нагрузка и данные отличаются от prod	ранняя стадия; нет полноценного staging-monitoring
Game Day (плановый)	команда учится; метрики зафиксированы	простой команды (~1 рабочий день)	раз в квартал; после релиза крупной фичи
Chaos непрерывный (автоматический)	ловит регрессии сразу	сложнее контролировать Blast Radius	зрелая DevOps-практика
Избыточная отказоустойчивость (3 AZ + HPA)	RTO < 1 мин; спокойный сон	+30–50% к cloud-счёту	cost of downtime > cost of redundancy
Минимальная отказоустойчивость (1 AZ)	дёшево	простой при отказе зоны (часы)	staging; система с низкой бизнес-ценностью

Вывод: Chaos Engineering — это не «ломать прод ради фана», а количественное доказательство устойчивости: таблица ROI (cost of improvement vs cost of downtime) оправдывает каждое решение. См. ADR-10 из Задачи 3.

🛠 Практические задания

Сценарий: Проведение Game Day для системы P2P-переводов на Go (K8s).

Примерный план работы:

Runbook: гипотеза, Steady State, Blast Radius, Abort Conditions.
Эксперименты: Pod Kill 50% → HPA; Network Latency 5 с → CB Open + Backoff; DB Failover → RTO.
ROI таблица: current vs improved (RTO, p99, cost/мес, стоимость простоя).
Постмортем: что ожидали vs что произошло, какие паттерны сработали/не сработали.

Задача 1: Проектирование Chaos-эксперимента (Runbook)

Студент пишет план:

Гипотеза: «При отказе 50% Go-воркеров HPA поднимет новые, а Saga (Модуль 4) не зависнет».
Steady State: Метрики до сбоя (Error Rate < 0.1%, p99 < 200 мс).
Blast Radius: Только поды с label app=go-worker, не весь кластер.
Abort Conditions: Error Rate > 1% на протяжении 1 минуты → автоматическая остановка.

✅ Готово, когда:

Гипотеза сформулирована (что именно проверяется, какой паттерн из Модулей 4–5)
Steady State: метрики до сбоя зафиксированы
Blast Radius: ограничение на конкретные поды/сервисы (label selectors)
Abort Conditions: пороги для автоматической остановки эксперимента
Указан инструмент (Chaos Mesh для K8s, Toxiproxy для сети)

Задача 2: Внедрение сбоев (проверка паттернов)

Эксперимент A (Pod Kill): через Chaos Mesh убить 50% подов Go-воркеров. Проверить HPA и корректность возобновления Saga (Модуль 4).

Эксперимент B (Network Latency): добавить 5 секунд задержки между Go-сервисом и PostgreSQL через Toxiproxy. Убедиться, что Circuit Breaker (Модуль 5) переходит в Open, а ретраи используют Exponential Backoff + Jitter, не допуская лавины запросов к БД.

Эксперимент C (DB Failover): симулировать отказ мастера БД. Измерить RTO переключения на реплику (связь с Модулем 9: read-your-writes, PgBouncer reconnect).

Go-код для Toxiproxy (настройка proxy на клиенте):

go
// Клиент Go подключается к Toxiproxy, а не напрямую к PG
// DSN указывает на toxiproxy:port, который форвардит на postgres
pool, err := pgxpool.New(ctx, "postgres://app:pass@toxiproxy:15432/mydb")
// Toxiproxy API добавляет latency:
// POST /proxies/postgres/toxics { "name": "latency", "type": "latency", "attributes": {"latency": 5000} }

✅ Готово, когда:

Pod Kill 50%: HPA поднимает новые поды, Saga не зависает (статусы в saga_instances корректны)
Network Latency 5 с: CB → Open, ретраи с Exponential Backoff + Jitter (нет лавины на БД)
DB Failover: измерен RTO переключения на реплику (< 1 мин)
Abort Conditions сработали бы при Error Rate > 1%

Задача 3: Анализ Cost Awareness (ROI)

Студенту нужно рассчитать окупаемость архитектурного улучшения (например, снижение риска OOM-кила воркеров на 50% за счёт тюнинга GOGC и увеличения подов). Пример таблицы для ADR-10:

Параметр	Текущая архитектура	Улучшенная архитектура	Разница
OOM-килы воркеров (в день)	~40	~20	−50%
RTO при отказе мастера БД	~3 мин	~45 сек	−75%
p99 latency `/transfer`	850 мс	480 мс	−43%
Cost / месяц (инфраструктура)	120 000 ₽	150 000 ₽	+25%
Стоимость простоя / час	50 000 ₽	50 000 ₽	—

ROI считается так: экономия на простое и инцидентах минус рост cloud-счёта. Если улучшение снижает простой на 2 ч/мес при стоимости простоя 50 000 ₽/ч (−100 000 ₽) при росте cost на 30 000 ₽ — чистая выгода 70 000 ₽/мес.

✅ Готово, когда:

Таблица: Current vs Improved (RTO, p99, cost/мес, стоимость простоя)
Количественный расчёт ROI (экономия на простое − рост cloud-счёта)
Вывод: окупается ли избыточная отказоустойчивость
ADR-10 «Избыточная отказоустойчивость: окупается ли?» написан

Задача 4: Постмортем (отчёт)

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

✅ Готово, когда:

Ожидаемое поведение vs фактическое
Метрики до/во время/после (с графиками или ссылками на Grafana)
Какие паттерны сработали (CB, Saga, HPA) и какие — не сработали
Action items: что изменить в архитектуре (связь с конкретным модулем)

⚠️ Антипаттерн для разбора

Студенту дается сценарий «хаос-инжиниринга» для анализа:

В пятницу вечером системный администратор вручную выполнил:
kubectl delete pod -l app=go-worker --all
в production-кластере.

Метрики никто не смотрел. Abort conditions не заданы.
Через 10 минут упала БД из-за резкого наплыва ретраев
от воркеров без Exponential Backoff.

Вопросы студенту:

Какие принципы Chaos Engineering нарушены? (Blast Radius, Steady State, автоматизация, безопасность, Abort Conditions)
Почему отсутствие Exponential Backoff + Jitter при ретраях уронило БД? (синхронная лавина запросов, см. Модуль 5)
Что произойдёт, если во время эксперимента сам Toxiproxy упадёт? (он станет SPOF; нужно изолировать)

📐 Задание по визуализации (Mermaid)

Студенту необходимо нарисовать схему проведения Chaos-эксперимента с условиями отмены и ветвлением.

Обязательные элементы:

Steady State (baseline метрики)
Внедрение сбоя (Pod Kill / Latency / Failover)
Наблюдение (метрики, паттерны)
Abort Conditions (ветвление: OK → продолжить, FAIL → остановить)
Postmortem (выводы)

Шаблон для ориентира:

Chaos Game Day: гипотеза, внедрение сбоя, abort

🧩 Проверь себя

1. ROI отказоустойчивости считается как…

2. Сожжено > 80% Error Budget. Что делать с хаос-экспериментами?

3. Cost of Downtime связан с Error Budget так:

4. Чем Chaos Engineering отличается от нагрузочного тестирования (k6)?

5. Что такое Blast Radius?

6. Game Day — это...

7. Как Chaos проявляется в Git-хостинге?

🤖 Инструкция для LLM (Coding Plan Assistant) — Режим Модуля 10

Привет! Я начинаю Модуль 10 курса «Архитектура распределённых систем».

Дай короткий ответ (2–3 предложения): чем Chaos Engineering отличается от нагрузочного тестирования (k6), и почему важно ограничивать Blast Radius и использовать RBAC для Chaos Mesh?

Объясни связь между Error Budget (из Модуля 6) и Cost Awareness. Как архитектору понять, что инвестиции в отказоустойчивость (Multi-AZ) окупаются? Используй таблицу ROI.

Покажи мне Антипаттерн (ручной kubectl delete в пятницу вечером без Backoff) и попроси меня объяснить, какие принципы нарушены и как это могло уронить БД.

Дай описание задания: спроектировать 2 Chaos-эксперимента (Pod Kill и Network Latency), описать гипотезы, Steady State, Blast Radius и Abort conditions. Укажи, какие паттерны (Saga, Circuit Breaker, Exponential Backoff) должны сработать.

НЕ ПИШИ за меня план экспериментов. Дождись моего ответа с архитектурным планом. После этого дай фидбек по чек-листу ментора и укажи на слепые зоны (например, «нет защиты от случайного убийства critical-сервисов», «не учтены ретраи», «нет отчёта», «нет ROI»).

📝 Чек-лист ментора

🔗 Мостик к Модулю 11 (Защита проекта — Capstone Defense)

В конце ревью скажи студенту:

«Поздравляю! Ты спроектировал систему, которая не теряет платежи, масштабируется в облаке и доказала свою устойчивость в Game Day. Ты не просто построил отказоустойчивую архитектуру — ты доказал её цифрами и экспериментами, а также обосновал стоимость каждого решения через ROI. Теперь время собрать всё вместе. В Модуле 11 ты подготовишь финальные ADR (Architecture Decision Records), построишь C4-диаграмму Capstone-проекта и защитишь её перед "архитектурным комитетом" (LLM), ответив на жёсткие вопросы по Trade-offs, стоимости и компромиссам. Каждое решение из Модулей 1–10 должно быть подкреплено цифрами и планом отката.»

Если ты прошёл курс «Git Hosting: Serverless MVP», ты уже видел этот паттерн на упрощённом стеке: cost-алерты на free-tier лимиты YDB и Cloud Functions (Модуль sv8), защита через ADR и ROI (Модуль sv10). Паттерн тот же — инфраструктура разная. Здесь мы разбираем его на полном стеке, с глубиной и trade-offs.

Провести Game Day не на словах, а на стенде, где отказ воспроизводится командой и проверяется машинно, можно в «Архитектурном полигоне»: инциденты БД, реплики, пайплайна, кэша и внешней зависимости.

← Модуль 9: Эволюция БД — от PgBouncer до CQRS Модуль 11: Рефлексия и защита проекта (Capstone Defense) →