Модуль 11. Рефлексия и защита проекта (Capstone Defense)

Цель модуля: Научить студента упаковывать технические решения в понятные артефакты (ADR, C4-схемы, отчёты) и защищать их перед «архитектурным комитетом». Студент должен уметь аргументировать Trade-offs количественными метриками, доказывать экономическую целесообразность (TCO, ROI) и описывать планы миграции/отката. Финальный модуль курса: все артефакты из Модулей 1–10 собираются в единую защиту.

Стадия роста проекта: Защита. Проект пережил все стадии роста: идею, MVP, интеграции, сложные процессы, внешние сервисы, продакшен, публичный API, рост нагрузки, зрелость. Система построена, паттерны применены, Chaos-эксперименты проведены, ROI рассчитан. Осталось одно — защитить каждое решение перед комитетом. И здесь ломается большинство: инженер знает, КАК работает система, но не умеет объяснить, ПОЧЕМУ она должна работать именно так.

Перед началом: Модули 1–10 (используются артефакты из всех модулей) Инструменты: — (сборка ADR, диаграмм и отчётов из предыдущих модулей) Трудоёмкость: ~8 ч (4 ADR 3 ч · C4-диаграмма 1 ч · SLO/отчёт 2 ч · защита 2 ч)

🔥 Инцидент: день защиты

Ты сидишь в переговорке. Напротив — «архитектурный комитет»: CTO, техлид соседнего домена и финансовый директор. На экране — C4-диаграмма, рядом — четыре ADR с цифрами, в руках — отчёт по SLO и ROI.

CTO: «Вижу Kafka, Saga, Outbox. Расскажи не про то, что есть, а про то, от чего ты отказался и почему». Техлид: «Дай план отката: если оркестратор Saga стал узким местом — что за 24 часа?» Финдиректор: «120 000 ₽/мес. Почему не 80 000? И сколько экономим за счёт "переплаты"?»

Ты начинаешь не с кода, а с бизнеса: «P2P-переводы. NFR: RTO < 5 мин, p99 < 200 мс. Если p99 вырастет до 800 мс — конверсия падает на 17%. Поэтому Multi-AZ и HPA, хотя дороже». Затем — ADR с цифрами: «Orchestration Saga: +150 ₽/мес, +100–200 мс задержки. SPOF закрыт Multi-AZ + CB. План миграции: при 10k RPS → Temporal, 80 часов». На вопрос про Serverless: «Сэкономит 30 000 ₽/мес, но Cold Start → p99 600 мс → конверсия −12% → минус 450 000 ₽ выручки. ROI отрицательный».

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

Связь с Serverless MVP: если ты прошёл курс «Git Hosting: Serverless MVP», у тебя уже есть опыт защиты на упрощённом стеке (Модуль sv8: ADR + Cost-отчёт). Здесь тот же принцип, но на полном стеке: K8s вместо Cloud Functions, PostgreSQL вместо YDB Serverless, Kafka вместо Message Queue. Паттерн тот же — инфраструктура разная.

📖 Теория: Как защищать архитектуру

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

• ADR (Architecture Decision Record) — короткий документ: контекст, альтернативы, решение, последствия с цифрами; фиксирует, почему решили именно так.
• C4 — 4 уровня архитектурных диаграмм (Context → Container → Component → Code); для защиты обычно хватает Level 2 (Container).
• NFR (Non-Functional Requirement) — нефункциональное требование: SLO, RTO, стоимость (а не «что делает система»).
• TCO (Total Cost of Ownership) — полная стоимость владения решением за период (инфраструктура + эксплуатация).
• Trade-off — осознанный обмен одной характеристики на другую (см. Модуль 1).
• ROI (Return on Investment) — окупаемость: выгода от инвестиций минус стоимость избыточной инфраструктуры.

11.1. ADR с количественными аргументами

Архитектор не говорит «мы выбрали Saga, потому что это правильно». Он говорит: «Мы выбрали Orchestration Saga. Это стоит $150/мес на инфраструктуру оркестратора и добавляет 100 мс задержки, но дает RTO < 5 минут и вероятность потери согласованности < 0.01%».

ADR содержит: Контекст, Альтернативы, Решение, Последствия (Trade-offs с цифрами: RTO, стоимость, риски).

11.2. Структура защиты (Pitch)

Защита строится по принципу сверху-вниз:

1. Бизнес-проблема и NFRs: Что строим и какие SLO/RTO обеспечиваем.
2. High-Level Архитектура: Общая схема (C4 Level 2) с протоколами и гарантиями доставки.
3. Ключевые вызовы и Trade-offs: Разбор 4 ADR с цифрами.
4. Эксплуатация и Cost Awareness: Связь технических метрик с бизнесом (p99 200 мс = конверсия X%, RTO 5 мин = потеря Y заказов). План миграции (v2).

11.3. Зрелость инженера

Студент должен признавать слабые места и иметь план отката. «Да, Outbox на поллинге дает задержку до 5 секунд. Переход на CDC (Debezium) потребует 40-60 часов, но для MVP поллинг достаточен».

11.4. Компромиссы (Trade-offs) — сводная таблица курса

Модуль	Решение	Плюс	Минус
m1	CP (синхронная репликация)	RPO = 0	latency записи
m2	DB unique index (не Redis)	атомарность	нагрузка на БД
m3	Polling Outbox (не CDC)	просто	задержка до 5 с
m4	Orchestration Saga (не Choreography)	явный стейт, аудит	SPOF оркестратора
m5	Circuit Breaker + Fallback	доступность	риск пропуска KYC
m6	Auto-instrumentation OTel	покрытие из коробки	overhead
m7	ALB JWT (Edge-валидация)	быстро	нет полного role-check
m8	K8s (не Serverless) для синхронных API	нет Cold Start	фиксированная стоимость
m9	Шардирование (крайняя мера)	write-скейлинг	cross-shard transactions
m10	Chaos в Production	реализм	риск инцидента

Критерий сдачи курса: студент может заполнить эту таблицу своими цифрами (RTO, SLO, $/мес, % риска) и защитить каждое решение перед комитетом — без единого «потому что так принято».

---

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

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

1. Финализировать 4 ADR (на основе модулей m2–m9) с количественными trade-offs (RTO, SLO, $/мес, % риска).
2. Нарисовать архитектурную диаграмму C4 Level 2 (протоколы, гарантии доставки, sync/async потоки).
3. Отчёт по SLO и стоимости: точка деградации, fallback, ROI (current vs improved).
4. Защита перед «архитектурным комитетом» (LLM): 3 жёстких вопроса — TCO, scale 10x, migration plan.

Задача 1: Финализация 4 ADRs (с количественными Trade-offs)

Студент предоставляет 4 ADR. Пример структуры (ADR-2: Saga):

Решение

Выбрана Orchestration Saga с отдельным Go-сервисом-оркестратором.

Последствия (Trade-offs)

• Плюсы: Явный стейт, простая компенсация, понятный аудит.
• Минусы: Доп. инфраструктура (~$150/мес), доп. задержка (latency ~100-200 мс).
• Риски: Оркестратор становится SPOF; решено через Multi-AZ и Circuit Breaker.
• Метрики: RTO < 5 минут, вероятность потери согласованности < 0.01% (по данным Chaos-экспериментов).
• План миграции: При росте до 10k RPS оркестратор можно заменить на Temporal.io (оценка: 80 часов).

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

• Минимум 4 ADR, каждый со структурой: Контекст, Альтернативы (мин. 2), Решение, Метрики
• Каждый ADR содержит количественные Trade-offs: RTO, SLO, $/мес, % риска
• Каждый ADR содержит план миграции / отката

Задача 2: Архитектурная диаграмма (C4 Level 2)

Создать диаграмму, на которой отражены типы протоколов (gRPC/REST/Kafka), гарантии доставки (at-least-once) и разделение синхронных/асинхронных потоков.

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

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

• Диаграмма в нотации C4 Level 2 (Container)
• Отражены типы протоколов: gRPC, REST, Kafka
• Отражены гарантии доставки (at-least-once) и разделение синхронных/асинхронных потоков

Задача 3: Отчёт по SLO и стоимости (Cost Awareness)

Связать технические метрики с бизнес-потерями. В отчёте описать: при какой нагрузке начинаются ошибки и таймауты, какой fallback срабатывает, и как это соотносится с SLO из контракта. Привести таблицу ROI (Текущая архитектура vs Улучшенная: RTO, p99 latency, стоимость простоя, cloud-счёт) и сделать вывод об окупаемости избыточной отказоустойчивости.

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

• Описана точка деградации: при какой нагрузке начинаются ошибки/таймауты
• Описан какой fallback срабатывает и как это соотносится с SLO из контракта
• Таблица ROI: Текущая vs Улучшенная (RTO, p99, стоимость простоя, cloud-счёт)
• Вывод: окупается ли избыточная отказоустойчивость (количественно)

Задача 4: Ролевая защита перед «архитектурным комитетом»

Студент защищает архитектуру, а LLM выступает в роли «Злого Архитектора» и задаёт жёсткие вопросы, на которые нужно ответить количественными аргументами:

• «Почему K8s, а не Serverless — оправдана ли разница в TCO?»
• «Как система поведёт себя при масштабировании 10x (10 000 RPS)?»
• «Не будет ли дребезга (flapping) Circuit Breaker при колебаниях latency?»
• «Каков план отката — например, при миграции с PostgreSQL на YDB?»
• «Вы упомянули CQRS — когда перейдёте на Event Sourcing и что для этого нужно?»

Подсказка по Event Sourcing: ответьте, что ES — это план v2, когда audit-требования или шардирование write-нагрузки станут критичными. Outbox (Модуль 3) уже готов стать Event Store — добавить version, убрать write-таблицы, построить projection workers. Оценка миграции: 120 часов, канареечный деплой.

Подсказка по Serverless vs K8s: если ты прошёл курс «Git Hosting: Serverless MVP», ты уже обосновывал выбор Serverless для MVP (Модуль sv8). Здесь тот же принцип: Cold Start Go приемлем для воркеров (1–2 с), но недопустим для синхронных API с p99 < 100 мс. TCO: Serverless экономит при спорадической нагрузке, K8s — при стабильной > 1k RPS.

Подсказка по PostgreSQL vs YDB: YDB Serverless — native sharding, eventual consistency, ~0₽/мес при 10 RU/с. Managed PostgreSQL — ACID, реплики, FOR UPDATE SKIP LOCKED. Для MVP Git-хостинга — YDB достаточно (sv3). Для финтеха с strong consistency — PostgreSQL.

Критерий сдачи: каждое решение обосновано метриками (RTO, SLO, $/мес, % риска) и имеет план отката.

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

• Ответы на все вопросы «Злого Архитектора» даны количественными аргументами
• TCO-вопрос: обоснована разница в стоимости между вариантами (K8s vs Serverless, PostgreSQL vs YDB)
• Scale-вопрос: описано поведение при 10x масштабировании
• Migration-вопрос: описан план отката (например, PostgreSQL → YDB)
• Ни один ответ не сводится к «потому что так принято» — всё подкреплено метриками

---

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

Студенту дается пример плохой защиты.

Защита: "Мы написали API на Go. Оно сохраняет данные в БД.

Для очередей мы используем RabbitMQ, потому что он быстрый.

Система работает нормально, тесты проходят."

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

1. Почему «RabbitMQ быстрый» — не аргумент для архитектора? (Нужно переформулировать в NFRs: «Выбран из-за at-least-once доставки и поддержки TTL/DLQ»).
2. Чего не хватает в этой защите? (Бизнес-контекста, количественных Trade-offs, SLO).

---

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

---

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

Привет! Я завершаю курс «Архитектура распределённых систем» и готовлюсь к защите Capstone-проекта.

Дай короткий ответ (2–3 предложения): почему архитектор при защите системы должен делать акцент на Trade-offs и последствиях (Cons) с количественными метриками, а не только на преимуществах (Pros)?

Покажи мне пример Антипаттерна защиты (без бизнес-контекста, «RabbitMQ быстрый») и попроси меня объяснить, почему такая защита не убедит CTO.

Выдай мне финальный чек-лист, который я должен соблюсти для успешной сдачи курса (ADR с метриками, C4-диаграмма, Отчёты, план миграции).

Скажи: «Я готов выступить в роли Архитектурного комитета. Пришли мне свои ADR и диаграммы, и я задам тебе 3 жёстких вопроса по твоим решениям, включая вопросы про TCO (K8s vs Serverless), масштабирование 10x и план миграции (PostgreSQL vs YDB)».

НЕ ПИШИ за меня ADR. Дождись моих материалов. После этого задай неудобные вопросы по сценарию.

---

📝 Финальный Чек-лист Архитектора (Критерии сдачи курса)

• Архитектура: Внедрена Clean Architecture. Стек: только Go (без альтернативных треков).

• Идемпотентность: Idempotency-Key с уникальным индексом. Защита от Replay (HMAC + Timestamp + Канонический JSON).

• Outbox: Нет Dual-Write. outbox_events в той же транзакции. Воркер использует FOR UPDATE SKIP LOCKED и пробрасывает trace_id в Kafka headers.

• Saga: Orchestration Saga. Компенсации описаны. Оркестратор использует FOR UPDATE от гонок. Реализован таймаут-джоб.

• Resilience: Circuit Breaker (с Half-Open), Bulkhead (пулы/Worker Pool), Rate Limiter (Redis). Описаны Fallback-стратегии и Exponential Backoff + Jitter.

• Observability: Сквозной trace_id (через Kafka). Метрики без высокой кардинальности. SLO и Error Budget определены. PII замаскированы в логах и трейсах.

• Безопасность: JWT на Edge. RBAC на бэкенде. Секреты в Yandex Lockbox с IAM-политикой (condition).

• Инфраструктура: Terraform (IaC) с remote state. Multi-AZ. Разделение SA. Docker-образы (multi-stage, non-root, Trivy-scan).

• Эволюция БД: PgBouncer → Read Replicas → Партиционирование → Шардирование (если нужно). Read-your-writes.

• Хаос и Стоимость: Проведены Chaos-эксперименты (Runbook). Рассчитан ROI. Технические метрики привязаны к бизнес-потерям.

• Документация: 4 ADR с количественными Trade-offs и планом миграции. Итоговая C4 Level 2 диаграмма. Отчёт по SLO.

• Связь с Serverless MVP: Студент понимает, когда Serverless дешевле (MVP, спорадическая нагрузка), а когда K8s (стабильная > 1k RPS). Может обосновать выбор.

🎓 Мостик в Реальный мир

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

• «Поздравляю! Ты прошёл путь от написания кода к проектированию распределённой системы, выдерживающей сбои на уровне инфраструктуры и сети. Ты умеешь не только реализовывать паттерны (Saga, Outbox, CB), но и доказывать их необходимость бизнесу через ROI и SLO. Твои ADR, C4-диаграмма и отчёт по стоимости — это именно те артефакты, которые показывают уровень Architect на собеседованиях. Теперь ты готов строить production-ready системы в Yandex Cloud и защищать их перед самым строгим комитетом.»

Если ты прошёл курс «Git Hosting: Serverless MVP», ты уже видел эти паттерны на упрощённом стеке: YDB Serverless вместо PostgreSQL, Message Queue вместо Kafka, Cloud Functions вместо K8s. Паттерны те же — инфраструктура разная. Теперь ты понимаешь, когда какой стек выбирать, и можешь обосновать это цифрами. Это и есть уровень Architect.

Следующий шаг — Модуль 12 (Инструменты архитектора): приложение с шаблонами, диаграммами и метриками, которые ты будешь использовать в реальной работе.

Если хочется проверить свои решения не только на бумаге — «Архитектурный полигон»: восемь инцидентов на живом стенде, у каждого — машинная проверка «починил» вместо «вроде работает».