Инженерные принципы
Для чего модуль
Сформировать инженерное мышление, где решение объясняется через ограничения, риски, стоимость изменений и проверяемый результат.
Результат после прохождения
- Вы формулируете решения как гипотезы с критериями проверки.
- Вы принимаете архитектурные решения через trade-offs, а не через «вкус».
- Вы закладываете reliability и операционку в дизайн заранее.
- Вы управляете техническим долгом как системой приоритетов, а не как списком жалоб.
Термины и аббревиатуры
| Термин | Коротко |
|---|---|
ADR | Запись архитектурного решения |
SLI | Измеримый индикатор качества |
SLO | Целевой уровень качества |
Error budget | Допустимая деградация |
Runbook | Пошаговые действия |
Фокус по грейдам
Junior: понимать базовые механики и объяснять их простыми примерами.Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.
Как работать с модулем
- Для каждого урока берите один реальный кейс из проекта.
- Оформляйте решение письменно: контекст -> альтернативы -> выбор -> риски -> метрики.
- После урока обновляйте один инженерный артефакт: ADR, checklist, runbook.
Программа модуля
Урок 1. Решение как система компромиссов
Цель: выбирать решения по продуктовым ограничениям, а не по личным предпочтениям.
Decision context
Перед выбором фиксируем:
- Цель (какой бизнес-эффект должен быть достигнут).
- Ограничения (срок, команда, инфраструктура, бюджет).
- Нефункциональные требования (надежность, latency, безопасность, масштаб).
Decision matrix
- Выбираем критерии и веса.
- Сравниваем 2-4 альтернативы.
- Фиксируем, какую цену платим за выбранный путь.
Где ломается в проде
- Решение принято, но не описано, почему отвергнуты альтернативы.
- Команда оптимизировала локальную метрику и ухудшила общий результат.
- Нет ownership за долгосрочные последствия решения.
Мини-задача (обязательная)
Соберите decision matrix для одной сложной задачи из текущего проекта и защитите выбор перед «виртуальным ревью» (3 возражения + ответы).
Что спросит интервьюер: почему вы отвергли альтернативы и какую цену заплатили за выбранный путь.
Критерий готовности по уроку: вы можете объяснить решение так, чтобы спор шел по фактам и критериям, а не по авторитету.
Урок 2. Reliability by design
Цель: проектировать отказоустойчивость до релиза.
Базовые элементы надежности
- SLI/SLO/Error budget.
- Таймауты, retry, circuit breaker.
- Graceful degradation и fallback UX.
Принцип fail-safe
При частичном отказе пользователь должен получать контролируемый результат, а система — понятный сигнал о проблеме.
Где ломается в проде
- Retry без лимита вызывает retry storm.
- Нет fallback, поэтому единичный отказ «роняет» критичный сценарий.
- Команда измеряет availability, но не измеряет пользовательский impact.
Мини-задача (обязательная)
Сделайте runbook для кейса: внешний API частично недоступен 30 минут. Включите: fallback UX, алерты, эскалацию, rollback conditions.
Что спросит интервьюер: какой минимальный UX вы сохраните при отказе внешней зависимости.
Критерий готовности по уроку: вы можете описать поведение системы в отказе и доказать, что оно управляемо.
Урок 3. Эволюция решений
Цель: изменять архитектуру без остановки доставки фич.
Инкрементальные изменения
- Strangler/branch by abstraction.
- Небольшие шаги с измеримым эффектом.
- Параллельное существование старого и нового пути с контролем рисков.
ADR и техдолг
- ADR фиксирует контекст и последствия.
- Техдолг приоритизируется по impact/probability/cost.
- У долга всегда есть owner и план, иначе это «скрытый риск».
Где ломается в проде
- Big-bang migration без rollback.
- Нет критериев «миграция успешна/неуспешна».
- Refactor «ради красоты» съедает delivery и не решает пользовательские проблемы.
Мини-задача (обязательная)
Соберите roadmap эволюции проблемного модуля на 8 недель: стабилизация -> упрощение -> ускорение delivery.
Что спросит интервьюер: как вы докажете, что план эволюции не убьет velocity команды.
Критерий готовности по уроку: вы можете провести изменение архитектуры как управляемую программу, а не как рискованную операцию.
Урок 4. Командная инженерия
Цель: встроить инженерные принципы в регулярный процесс команды.
Process as quality system
- Definition of Ready/Done.
- PR quality gates.
- Ритуалы архитектурных и техдолговых ревью.
Postmortem и обучение команды
- Timeline без обвинений.
- Root cause + corrective actions + preventive actions.
- Проверка, что изменения реально снизили риск повтора.
Где ломается в проде
- Стандарты есть в wiki, но не встроены в CI/PR flow.
- После инцидента нет системных изменений.
- Ownership «размыт», сложные зоны остаются бесхозными.
Мини-задача (обязательная)
Зафиксируйте quality gates для релиза: тесты, perf budgets, security checks, rollback readiness, owner sign-off.
Что спросит интервьюер: как вы обеспечиваете, что инженерные стандарты работают, а не висят в документах.
Критерий готовности по уроку: вы можете показать процесс команды как механизм стабильной инженерной поставки.
Практика
- Подготовьте 3 decision matrix по разным типам задач.
- Оформите 2 ADR из реального проекта.
- Сформируйте reliability checklist и проведите dry-run.
- Сделайте постмортем-шаблон и протестируйте на учебном кейсе.
- Закрепите в Senior Frontend и Playbook.
- Проведите мини-дизайн с 2 альтернативами и decision matrix в Песочнице.
Связь с треками и вопросами
- Треки: Middle трек, Senior трек.
- Вопросы: Senior Frontend, Playbook.
- Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.
Критерий готовности
Вы системно объясняете решения через ограничения, риски, метрики и процесс эксплуатации.
Артефакты после модуля
- Набор decision matrix шаблонов.
- 2 ADR с альтернативами и рисками.
- Reliability checklist + postmortem template.
- Набор из 6 сильных interview-ответов по engineering mindset.