От Senior к Architect: системный дизайн и архитектурное лидерство
Планируемый 12-недельный силлабус с инструктором: от требований и атрибутов качества через архитектуру данных и интеграций, безопасность и стоимость эксплуатации до технического лидерства. В конце вы защищаете архитектуру для реалистичного кейса в духе платёжной системы. Порядок и глубина могут корректироваться под группу; программа не обещает работу или должность.
Эта программа планируется и пока не стоит в расписании. Дата, группа и набор не объявлены, заявки мы не принимаем. Оставьте интерес или запросите консультацию: мы свяжемся с вами, когда программа будет запланирована.
- Длительность
- 12 недель
- Живые занятия
- 2 в неделю по 90 минут
- Структура
- Этапов: 4
12 недель
Программа по неделям
Это планируемая программа: порядок и глубина могут корректироваться под группу. Это не гарантия работы или должности.
01 · Недели 1–3
Основы: требования, стили, документирование
Цель этапа: Превратить расплывчатый бизнес-запрос в измеримые атрибуты качества, обосновать архитектурный стиль и задокументировать решение через C4 и ADR.
Неделя 1
Роль архитектора, требования и атрибуты качества
- Что решает архитектор и за что отвечает
- Функциональное требование, атрибут качества, ограничение
- Сценарии атрибутов качества и utility tree
- C4 Level 1 (System Context) и введение в ADR
Лабораторная: Группы выявляют требования к сервису платёжных уведомлений, пишут 5 сценариев атрибутов качества и рисуют C4-диаграмму контекста.
Задание: Индивидуально: репозиторий с ADR-001 и C4-диаграммой контекста для выбранного кейса.
Неделя 2
Архитектурные стили: modular monolith, microservices, event-driven
- Modular monolith: границы, правила модулей, когда его достаточно
- Microservices: границы команд, независимость деплоя, цена распределённости
- Event-driven: events и commands, eventual consistency, гарантии доставки
- Критерии выбора стиля
Лабораторная: Набросайте один кейс в трёх стилях и заполните таблицу затрат и выгод для каждого.
Задание: ADR-002: выбор стиля с отклонёнными альтернативами и условиями пересмотра.
Неделя 3
C4, ADR и архитектурная документация
- C4 Levels 2-3: диаграммы container и component
- Правила диаграмм: легенда, заголовок, направление связи
- Жизненный цикл ADR: proposed, accepted, superseded
- Fitness functions и автоматическая проверка архитектуры
Лабораторная: Перекрёстное ревью диаграмм: каждая группа читает C4 container-диаграмму другой и пишет 5 вопросов.
Задание: Индивидуально: C4 Level 2 и описание хотя бы одной fitness function (например, правило зависимостей модулей).
Контрольная точка: Для выбранного кейса: документ требований, диаграммы C4 уровней 1-2 и не менее трёх ADR (включая выбор стиля).
02 · Недели 4–6
Масштаб и архитектура данных
Цель этапа: Оценивать нагрузку и ёмкость, обосновывать partitioning и replication и определять, когда оправдан CQRS.
Неделя 4
Масштабируемость и оценка ёмкости
- Прикидочные расчёты: RPS, хранилище, пропускная способность
- Пиковая нагрузка, p95/p99 и запас ёмкости
- Горизонтальное и вертикальное масштабирование, stateless-дизайн
- Слои кэша и риски инвалидации
Лабораторная: Оцените суточную и пиковую нагрузку кейса, найдите первое узкое место и напишите план нагрузочного теста.
Задание: Индивидуально: одностраничная таблица оценки ёмкости с явными допущениями.
Неделя 5
Архитектура данных: partitioning, replication, consistency
- Выбор partition key и проблема hot partition
- Replication: sync/async, replica lag, failover
- Модели consistency и CAP/PACELC на практике
- Границы транзакций и идемпотентность
Лабораторная: Модель данных для ledger: partition key, топология реплик и сценарий failover.
Задание: ADR-003: решение по хранению данных и partitioning с последствиями и рисками.
Неделя 6
Messaging, CQRS и event sourcing: когда оправданы
- Queue и log (в стиле Kafka): отличия и критерии выбора
- Outbox pattern и идемпотентный consumer при at-least-once
- CQRS: когда стоит разделять модели чтения и записи
- Цена event sourcing: replay, эволюция схем, GDPR
Лабораторная: Спроектируйте поток outbox + идемпотентный consumer для статуса платежа и проведите встречу 'нужен ли CQRS?'.
Задание: Индивидуально: ADR с ответом 'да' или 'нет' на CQRS; отказ допустим, если обоснован.
Контрольная точка: Таблица оценки ёмкости, модель данных с решением по partitioning/replication и ADR, обосновывающий (или отклоняющий) CQRS.
03 · Недели 7–9
Интеграции, безопасность и эксплуатация
Цель этапа: Включить в архитектуру интеграции с внешними и legacy-системами, требования безопасности и compliance и стоимость облака.
Неделя 7
Архитектура интеграций: API, messaging, legacy
- Дизайн API: версионирование, обратная совместимость, contract testing
- Синхронная и асинхронная интеграция, timeout/retry/circuit breaker
- Legacy и банковские интеграции: файловый обмен, SOAP, сообщения ISO 20022, ночные batch
- Anti-corruption layer и подход strangler
Лабораторная: Спроектируйте файловую интеграцию сверки с банковской core-системой: формат, обработка ошибок, повторная отправка.
Задание: Индивидуально: карта интеграций и ADR по anti-corruption layer для одной legacy-связи.
Неделя 8
Архитектура безопасности и compliance
- Threat modeling (STRIDE) и trust boundaries
- Архитектура AuthN/AuthZ: OIDC, доверие между сервисами, управление секретами
- Классификация данных, шифрование, audit trail, retention
- Compliance-рамки: основы PCI DSS, защита персональных данных
Лабораторная: Сессия STRIDE по диаграмме потоков данных кейса; минимум 8 угроз и меры их снижения.
Задание: Индивидуально: документ с моделью угроз и ADR по границе для карточных и персональных данных.
Неделя 9
Стоимость облака и операционная готовность
- SLI/SLO/error budget и их влияние на архитектурные решения
- Observability: логи, метрики, трейсы и качество алертов
- Multi-AZ/region, RTO/RPO и уровни disaster recovery
- FinOps: модель стоимости, unit economics, цена over-engineering
Лабораторная: Сравните три варианта развёртывания (один регион, multi-AZ, multi-region) по месячной стоимости и RTO/RPO.
Задание: Индивидуально: SLO, модель стоимости и ADR по рекомендуемому варианту развёртывания.
Контрольная точка: Обновлённый архитектурный пакет с картой интеграций (контракты API/сообщений/файлов), моделью угроз, SLO и моделью стоимости.
04 · Недели 10–12
Техническое лидерство и защита архитектуры
Цель этапа: Проводить архитектурные решения через команды и стейкхолдеров с помощью RFC, roadmap и коммуникации; защитить итоговую архитектуру.
Неделя 10
Процесс RFC, roadmap и технический долг
- Процесс RFC: кто пишет, кто ревьюит, как принимается решение
- Классификация технического долга, осознанный и случайный долг
- Архитектурный roadmap: этапы, зависимости, риски
- Риски architecture review board и лёгкие альтернативы
Лабораторная: Группы пишут RFC по кейсу; другая группа выступает формальным ревьюером и даёт письменный отзыв.
Задание: Индивидуально: трёхэтапный архитектурный roadmap и реестр технического долга (минимум 6 пунктов с приоритетами).
Неделя 11
Коммуникация со стейкхолдерами и менторство
- Объяснение технического решения на языке бизнеса: риск, стоимость, сроки
- Обсуждение trade-off и решения в условиях неопределённости
- Менторство: рост senior-инженеров к архитектурному мышлению
- Конфликт и согласование: 'disagree and commit'
Лабораторная: Ролевая игра: 10-минутный доклад о решении перед CFO, риск-менеджером и тимлидом, затем обратная связь.
Задание: Индивидуально: одностраничное нетехническое резюме для руководства и план менторской сессии.
Неделя 12
Итоговый проект: защита архитектуры
- Сборка и последовательность итогового пакета
- Структура защиты: контекст, ключевые решения, trade-off, риски
- Ответы на сложные вопросы: 'что если нагрузка вырастет в 10 раз?', 'что если сменится провайдер?'
- Отзыв панели, ретроспектива и план дальнейшего развития
Лабораторная: Репетиция защиты внутри группы, затем 25-минутная защита перед панелью из инструктора и приглашённых инженеров.
Задание: Индивидуально: итоговый архитектурный пакет (репозиторий) и одностраничная самооценка после защиты.
Контрольная точка: Итоговый архитектурный пакет (требования, C4, ADR, ёмкость, данные, интеграции, безопасность, стоимость, roadmap) и защита перед панелью.