Модуль 12. Инструменты архитектора
Архитектор — как художник. Разница в том, что вместо красок — метрики, вместо холста — диаграммы, а вместо ластика — ADR с планом отката.
Вы прошли 11 модулей и создали десятки артефактов: ADR, C4-диаграммы, SLO-отчёты, Runbook, постмортемы, Chaos-эксперименты, ROI-таблицы. Этот модуль — обобщение: что положить в «сумку архитектора», когда доставать и когда прятать обратно.
Связь с экосистемой курсов: если ты прошёл «Git Hosting: Serverless MVP», у тебя уже есть ADR-SV1–SV8 и Cost-отчёт. Если ты идёшь в «Git Hosting: от 10k до 100k RPS», тебе понадобятся ADR-GG1–GG8 и TCO-сравнение. Инструменты те же — меняется только инфраструктура и масштаб.
Пять инструментов — не список, а цикл решения: набросок → цифры → финальная схема → ADR с планом отката → реализация → ревизия. В ревизию возвращаются после постмортема или когда изменились цифры, — и тогда цикл начинается заново с карандаша. Дальше — каждый инструмент отдельно.
📐 1. Карандаш — быстрый набросок
Что: Эксплораторная схема, чтобы подумать, а не показать.
Когда достать: На этапе brainstorm. Вы исследуете альтернативы, спорите с командой, набрасываете 2–3 варианта на белой доске или в Excalidraw. Карандаш — одноразовый: набросал, обсудили, выбросил. В ADR попадает финальный вариант, не каждый набросок.
Инструменты:
- Excalidraw — iPad + Apple Pencil, экспорт в PNG/SVG. Рисуешь от руки — это видно, и это правильно для черновика.
- Белая доска / Miro — для команды.
- Mermaid (быстрый draft) — если удобнее писать, чем рисовать.
Антипаттерн: Набросок → «давайте сохраним в Confluence как архитектуру». Нет. Набросок — это процесс мышления, не артефакт. Финальная схема — в Mermaid, в Git, в ADR.
Из курса: в Модуле 1 вы выбирали CP/AP для двух сценариев — это типичный «карандаш»: набросали топологии, сравнили, выбрали, зафиксировали в ADR. В Serverless MVP (sv1) то же самое: Serverless vs VPS vs K8s — набросали, посчитали, выбрали.
Примеры применения в архетипах:
| Архетип | Что набрасываем | Почему карандашом |
|---|---|---|
| Финтех | Топология CP/AP для переводов | 3 варианта репликации до выбора |
| Git-хостинг | Трёхслойная архитектура (Web App, Git Gateway, Storage) | Спор о месте NFS vs Object Storage |
| Мессенджер | Схема доставки (Send → Queue → Push) | 2 варианта: Kafka vs Redis Streams |
| Лента | AP-архитектура с кэшем | Выбор между CDN и Redis на Edge |
🖼️ 2. Холст — финальная картина
Что: Диаграмма, которая живёт в Git, проходит ревью и показывается комитету.
Когда достать: Когда архитектура определена и нужна постоянная документация: ADR, README проекта, защита (Модуль 11).
Типы диаграмм и когда какие:
| Тип | Что показывает | Когда | Курс |
|---|---|---|---|
| C4 Level 2 (Container) | Сервисы, протоколы, потоки | Архитектура системы для ADR и защиты | m11 (Capstone) |
| Sequence | Порядок вызовов во времени | Saga, Outbox, Circuit Breaker — динамика | m2, m3, m4, m5 |
| State Diagram | Статусы и переходы | Стейт-машина Saga, состояния CB | m4, m5 |
| ER / Схема БД | Таблицы, индексы, партиции | Схема outbox_events, saga_instances, idempotency_keys | m2, m3, m4 |
| Network Topology | VPC, подсети, Security Groups | Terraform, Multi-AZ | m8 |
| Deployment | Поды, узлы, зоны | Инфраструктура как код | m8 |
| Эволюция БД | Линейка масштабирования | PgBouncer → CQRS | m9 |
Инструменты:
- Mermaid — для Markdown, ADR, Git. Версионируется, рендерится в GitHub/Notion. Основной инструмент курса.
- Draw.io (diagrams.net) — для сложных топологий (Yandex Cloud, AWS), где нужны иконки и брендированные формы. В курсе: пайплайн
.drawio → SVG. - PlantUML — если команда уже использует; строгая нотация UML.
Правило курса: Mermaid для всего, что живёт в Markdown. Draw.io — для топологий облака и презентаций.
Примеры применения в архетипах:
| Архетип | Ключевая диаграмма | Тип |
|---|---|---|
| Финтех | C4 Level 2: API → Saga → БД → Уведомления | C4 |
| Git-хостинг | C4 Level 2: git-gateway → Storage Nodes → Kafka → Citus | C4 |
| Мессенджер | C4 Level 2: Send Service → Queue → Push Service | C4 |
| Лента | C4 Level 2: API → Кэш → БД → CDN | C4 |
🎨 3. Палитра — метрики
Что: Числа, которыми окрашивается каждое решение. ADR без цифр — это мнение, не аргумент.
Когда достать: Всегда. Каждое архитектурное решение сопровождается Target SLO — целевыми метриками.
Базовая палитра:
| Метрика | Что значит | Пример из курса |
|---|---|---|
| p99 latency | Хвост распределения — то, что чувствует пользователь | «p99 записи ≤ 500 мс при синхронной репликации» (m1) |
| RTO | Сколько система может быть недоступна | «RTO < 1 мин при отказе зоны» (m8, m10) |
| RPO | Сколько данных допустимо потерять | «RPO = 0 → синхронная репликация» (m1, m8) |
| Error Budget | Допустимый «запас ошибок» = 100% − SLO | «43 мин даунтайма/мес при SLO 99.9%» (m6) |
| Cost / мес | Стоимость инфраструктуры | «120 000 ₽ → 150 000 ₽, ROI +70 000 ₽» (m10) |
| Cost of Downtime | Сколько стоит час простоя | «50 000 ₽/час — база для ROI-расчёта» (m10) |
| RU/с | Request Units YDB Serverless | «10 RU/с бесплатно, превышение — оплата» (sv3) |
Где описывать:
- В ADR — Target SLO в секции «Решение».
- В Grafana Dashboard — фактические значения (SLI), которые сравниваются с SLO.
- В ROI-таблице (Markdown) — связь технических метрик с деньгами.
Из курса: в Модуле 1 вы узнали, что «надёжно» и «быстро» — пустые слова без чисел. В Модуле 11 вы защищаете архитектуру, где каждое решение подкреплено p99, RTO и ₽/мес.
Примеры метрик в архетипах:
| Архетип | Ключевые метрики | Почему |
|---|---|---|
| Финтех | p99 latency ≤ 500 мс, RTO < 1 мин, RPO = 0 | Двойное списание недопустимо |
| Git-хостинг | IOPS на диске, p99 clone < 100 мс, RTO < 5 мин | git clone крупного репо = чтение packfile |
| Мессенджер | Delivery latency p99 < 2 с, % недоставленных < 0.1% | Недоставка = жалоба пользователя |
| Лента | p99 ≤ 200 мс, eventual consistency ≤ 5 с | 100k RPS на чтение |
🧽 4. Ластик — план отката
Что: ADR с секцией «План миграции/отката». Ластик — это не удаление, а осознанная смена решения с описанием, как и когда.
Когда достать: Когда решение может оказаться неверным (т.е. всегда). Архитектура без плана отката — это ставка без стоп-лосса.
Шаблон плана отката в ADR:
План миграции/отката
- Триггер: при каких метриках откатываемся (например, «p99 > 1 сек в течение 1 часа»).
- Оценка: 80 часов (разбито на этапы с канареечным деплоем).
- Шаги: dual-write → backfill → cut-over (или наоборот для отката).
- Время отката: 1 час на переключение трафика + CDC для синхронизации данных.
Из курса: каждый ADR (m2–m10) содержит план отката. В Модуле 11 на защите первый вопрос техлида: «Если оркестратор Saga стал узким местом — что за 24 часа?» Ответ — из секции «План отката» в ADR-4.
Примеры планов отката в архетипах:
| Архетип | План отката | Триггер |
|---|---|---|
| Финтех | Saga Orchestration → Temporal.io | 10k RPS, SPOF оркестратора |
| Git-хостинг | NFS → новый storage (dual-write → cut-over) | IOPS > 10000, latency clone > 500 мс |
| Мессенджер | Redis Streams → Kafka | > 50k msg/s, потеря сообщений |
| Лента | Redis → новая БД (dual-write → backfill → cut-over) | p99 > 500 мс, cache miss > 50% |
🖋️ 5. Рамка — шаблоны
Что: Стандартизированные форматы документов. Рамка не ограничивает творчество — она освобождает от раздумий «как оформить».
Шаблоны, которые архитектор использует регулярно:
| Документ | Когда | Шаблон |
|---|---|---|
| ADR | Каждое архитектурное решение | m1 (шаблон в blockquote) |
| Runbook (Chaos) | Перед Game Day | m10 (Задача 1) |
| Postmortem | После инцидента или эксперимента | m10 (Задача 4) |
| ROI-таблица | Для обоснования стоимости | m10 (Задача 3) |
| SLO-отчёт | Для связи метрик с бизнесом | m11 (Задача 3) |
| Cost-отчёт | Для Serverless / free-tier лимитов | sv8 |
Где хранить:
- Git — ADR, Mermaid-диаграммы, шаблоны. Версионируются, ревьюются, видны всем.
- Grafana — дашборды (живые метрики).
- Notion / Confluence — Runbook, постмортемы (командное пространство).
Правило: если документа нет в Git — его не существует. ADR в голове или в Slack-переписке — это не ADR.
Примеры шаблонов в архетипах:
| Архетип | Ключевой шаблон | Почему |
|---|---|---|
| Финтех | ADR для выбора БД (PostgreSQL vs YDB) | Двойное списание недопустимо; защита перед комитетом |
| Git-хостинг | ADR для выбора storage (POSIX vs S3) | Git требует hardlinks, flock, rename |
| Мессенджер | ADR для выбора очереди (Kafka vs Redis Streams) | Гарантия доставки; масштабирование |
| Лента | ADR для выбора кэша (Redis vs CDN) | p99 ≤ 200 мс; eventual consistency |
⚠️ Когда НЕ нужно доставать инструменты
| Антипаттерн | Почему плохо | Что делать |
|---|---|---|
| ADR на каждое решение | Паралич документации; ADR на «какой логгер использовать» — шум | ADR — только для решений с trade-offs (выбор БД, брокера, архитектурного паттерна). Мелочь — через PR-описание. |
| C4 Level 4 (Code) | Уровень класса/метода — это код, не архитектура. Устаревает мгновенно | Останавливайтесь на Level 2 (Container). Level 3 (Component) — только для сложных сервисов. |
| Диаграмма без ADR | «Видите картинку? Вот наша архитектура» — без контекста и trade-offs | Диаграмма — иллюстрация к ADR, не замена. |
| ADR без плана отката | «Мы выбрали Kafka» — а если не подойдёт? | Каждый ADR с trade-offs имеет секцию «План миграции/отката». |
| Метрики без SLO | «p99 = 250 мс» — это хорошо или плохо? | Метрика (SLI) без цели (SLO) — бессмысленное число. |
📊 Сводная таблица trade-offs курса (модули 1–10)
| Модуль | Решение | Плюс | Минус |
|---|---|---|---|
| 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, $/мес, % риска) и защитить каждое решение перед комитетом — без единого «потому что так принято».
📦 Что в сумке архитектора (cheat sheet)
Сумка архитектора:
├── 📐 Карандаш — Excalidraw / whiteboard (быстрый набросок, одноразовый)
├── 🖼️ Холст — Mermaid в Markdown (C4 Level 2, Sequence, State — постоянная документация)
├── 🎨 Палитра — SLO, RTO, ROI, $/мес (цифры для каждого решения)
├── 🧽 Ластик — ADR с планом отката (осознанная смена решения)
└── 🖋️ Рамка — шаблоны ADR, Runbook, Postmortem (стандартизация)
Где хранить:
├── Git (ADR, Mermaid, шаблоны) — основной холст
├── Grafana (живые метрики) — палитра в реальном времени
└── Notion/Confluence (Runbook, постмортемы) — командное пространство
💻 Практика
- ADR по шаблону. Возьмите одно решение своего проекта с trade-offs (БД, брокер, кэш, топология). Заполните ADR: контекст, 2–3 варианта, решение, Target SLO цифрами и план миграции/отката с триггером. Критерий: каждое «за» подкреплено метрикой, а не прилагательным.
- Холст. Нарисуйте C4 Level 2 своего сервиса в Mermaid в Git: контейнеры, протоколы, потоки; отдельно — sequence для одного критичного сценария (оформление заказа / доставка события). Критерий: диаграмма рендерится в GitHub и совпадает с ADR из п. 1.
- Палитра. Составьте таблицу из трёх SLI с целями и error budget на месяц; добавьте ROI-расчёт: cost of downtime × допустимый простой против стоимости решения. Критерий: числа воспроизводимы (формулы рядом).
- Ревизия. Проведите «атаку» на свой ADR: три вопроса техлида — «где узкое место?», «сколько это стоит в месяц?», «что за 24 часа, если не взлетит?». Обновите ADR так, чтобы ответы были в нём, а не в вашей голове.
🧩 Quiz
✅ Итоги модуля
Студент должен:
- Различать пять инструментов и их место в цикле решения
- Знать, что набросок — процесс, а артефакт — схема в Git
- Привязывать каждое решение к SLO/RTO/ROI цифрами
- Писать ADR с планом отката и триггером
- Выбирать тип диаграммы под задачу (C4, sequence, state)
- Отличать решение с trade-offs от мелочи, не требующей ADR
- Ответить на все вопросы Quiz
🎓 Финальный мостик: куда идти дальше
Архитектор отличается от разработчика не набором паттернов, а тем, что каждое решение нарисовано, обосновано цифрами и имеет план отката. Инструменты — это средство, не цель. Лучшая архитектура — та, которую можно объяснить на салфетке и защитить в ADR с метриками.
Ты прошёл курс «Архитектура распределённых систем» v2. Теперь у тебя есть:
- Карта мира: паттерны как ответы на боли роста проекта
- Инструменты: ADR, C4, SLO, ROI, Chaos, Cost
- Стек: только Go, Yandex Cloud, Terraform
Куда идти дальше:
- «Git Hosting: Serverless MVP» — практика на упрощённом стеке (YDB, Cloud Functions, Message Queue, ~50₽/мес)
- «PostgreSQL + ClickHouse» — данные: MVCC и индексы, репликация и бэкапы, MergeTree, CDC-пайплайн, эксплуатация
- «Архитектурный полигон» — практика инцидентов: восемь сценариев «сломай → найди → почини → защити» на живом стенде
- «Git Hosting на Go: от 10k до 100k RPS» — highload-практика на полном стеке (PostgreSQL, Kafka, Citus, Storage Nodes)
- «Мультипоточность в Go» — конкурентность до деталей: планировщик, пулы, лимиты, защиты
- «Брокеры сообщений» — глубина по Kafka, RabbitMQ и Redis Streams
- Capstone Defense — если хочешь защитить свой проект перед комитетом
Паттерны те же — инфраструктура разная. Ты теперь знаешь, когда какой стек выбирать, и можешь обосновать это цифрами. Это и есть уровень Architect.
Следующий шаг — практика. Выбери проект, примени паттерны, напиши ADR с метриками и защити перед комитетом. Инструменты в сумке — достань их и используй.