Перейти к основному содержимому

Инженерные принципы

Для чего модуль​

Сформировать инженерное мышление, где решение объясняется через ограничения, риски, стоимость изменений и проверяемый результат.

Результат после прохождения​

  1. Вы формулируете решения как гипотезы с критериями проверки.
  2. Вы принимаете архитектурные решения через trade-offs, а не через «вкус».
  3. Вы закладываете reliability и операционку в дизайн заранее.
  4. Вы управляете техническим долгом как системой приоритетов, а не как списком жалоб.

Термины и аббревиатуры​

ТерминКоротко
ADRЗапись архитектурного решения
SLIИзмеримый индикатор качества
SLOЦелевой уровень качества
Error budgetДопустимая деградация
RunbookПошаговые действия

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Для каждого урока берите один реальный кейс из проекта.
  2. Оформляйте решение письменно: контекст -> альтернативы -> выбор -> риски -> метрики.
  3. После урока обновляйте один инженерный артефакт: ADR, checklist, runbook.

Программа модуля​

Урок 1. Решение как система компромиссов​

Цель: выбирать решения по продуктовым ограничениям, а не по личным предпочтениям.

Decision context​

Перед выбором фиксируем:

  1. Цель (какой бизнес-эффект должен быть достигнут).
  2. Ограничения (срок, команда, инфраструктура, бюджет).
  3. Нефункциональные требования (надежность, latency, безопасность, масштаб).

Decision matrix​

  1. Выбираем критерии и веса.
  2. Сравниваем 2-4 альтернативы.
  3. Фиксируем, какую цену платим за выбранный путь.

Где ломается в проде​

  1. Решение принято, но не описано, почему отвергнуты альтернативы.
  2. Команда оптимизировала локальную метрику и ухудшила общий результат.
  3. Нет ownership за долгосрочные последствия решения.

Мини-задача (обязательная)​

Соберите decision matrix для одной сложной задачи из текущего проекта и защитите выбор перед «виртуальным ревью» (3 возражения + ответы).

Что спросит интервьюер: почему вы отвергли альтернативы и какую цену заплатили за выбранный путь.

Критерий готовности по уроку: вы можете объяснить решение так, чтобы спор шел по фактам и критериям, а не по авторитету.

Урок 2. Reliability by design​

Цель: проектировать отказоустойчивость до релиза.

Базовые элементы надежности​

  1. SLI/SLO/Error budget.
  2. Таймауты, retry, circuit breaker.
  3. Graceful degradation и fallback UX.

Принцип fail-safe​

При частичном отказе пользователь должен получать контролируемый результат, а система — понятный сигнал о проблеме.

Где ломается в проде​

  1. Retry без лимита вызывает retry storm.
  2. Нет fallback, поэтому единичный отказ «роняет» критичный сценарий.
  3. Команда измеряет availability, но не измеряет пользовательский impact.

Мини-задача (обязательная)​

Сделайте runbook для кейса: внешний API частично недоступен 30 минут. Включите: fallback UX, алерты, эскалацию, rollback conditions.

Что спросит интервьюер: какой минимальный UX вы сохраните при отказе внешней зависимости.

Критерий готовности по уроку: вы можете описать поведение системы в отказе и доказать, что оно управляемо.

Урок 3. Эволюция решений​

Цель: изменять архитектуру без остановки доставки фич.

Инкрементальные изменения​

  1. Strangler/branch by abstraction.
  2. Небольшие шаги с измеримым эффектом.
  3. Параллельное существование старого и нового пути с контролем рисков.

ADR и техдолг​

  1. ADR фиксирует контекст и последствия.
  2. Техдолг приоритизируется по impact/probability/cost.
  3. У долга всегда есть owner и план, иначе это «скрытый риск».

Где ломается в проде​

  1. Big-bang migration без rollback.
  2. Нет критериев «миграция успешна/неуспешна».
  3. Refactor «ради красоты» съедает delivery и не решает пользовательские проблемы.

Мини-задача (обязательная)​

Соберите roadmap эволюции проблемного модуля на 8 недель: стабилизация -> упрощение -> ускорение delivery.

Что спросит интервьюер: как вы докажете, что план эволюции не убьет velocity команды.

Критерий готовности по уроку: вы можете провести изменение архитектуры как управляемую программу, а не как рискованную операцию.

Урок 4. Командная инженерия​

Цель: встроить инженерные принципы в регулярный процесс команды.

Process as quality system​

  1. Definition of Ready/Done.
  2. PR quality gates.
  3. Ритуалы архитектурных и техдолговых ревью.

Postmortem и обучение команды​

  1. Timeline без обвинений.
  2. Root cause + corrective actions + preventive actions.
  3. Проверка, что изменения реально снизили риск повтора.

Где ломается в проде​

  1. Стандарты есть в wiki, но не встроены в CI/PR flow.
  2. После инцидента нет системных изменений.
  3. Ownership «размыт», сложные зоны остаются бесхозными.

Мини-задача (обязательная)​

Зафиксируйте quality gates для релиза: тесты, perf budgets, security checks, rollback readiness, owner sign-off.

Что спросит интервьюер: как вы обеспечиваете, что инженерные стандарты работают, а не висят в документах.

Критерий готовности по уроку: вы можете показать процесс команды как механизм стабильной инженерной поставки.

Практика​

1. Decision matrix и ADR​

Сделайте 2 decision artifacts: один для frontend architecture, один для delivery/process decision.

Ответьте:

  1. Senior q-1: масштабируемая frontend-архитектура.
  2. Senior q-20: technical leadership и decision log.
  3. Playbook q-3: trade-offs без "всегда делаем X".

Артефакт: decision matrix + mini ADR с context, options, criteria, trade-off, decision, risk, validation, owner.

Готово, если решение можно пересмотреть по явным criteria, а не по вкусу команды.

2. Reliability checklist и postmortem​

Соберите reliability checklist для рискованного изменения и протестируйте его на учебном incident.

Ответьте:

  1. Senior q-12: rollout/rollback plan.
  2. Senior q-19: postmortem после frontend-инцидента.
  3. Playbook q-7: risk management в ответе.

Артефакт: reliability checklist + postmortem template с impact, timeline, root cause, actions, owner, due date, verification.

Готово, если corrective action меняет gate, runbook, ownership или alert, а не просто формулируется как "быть внимательнее".

3. Quality gate dry-run​

Проведите dry-run одного high-risk PR.

Ответьте:

  1. Senior q-16: quality gates в CI.
  2. Playbook q-10: структурный ответ без потока мыслей.

Артефакт: quality gate dry-run note с change, risk, blocking gate, warning gate, exception rule, rollback trigger.

Готово, если понятно, что блокирует release, кто принимает исключение и какой сигнал запускает rollback.

Связь с треками и вопросами​

  1. Основные вопросы: Senior q-1, q-12, q-16, q-19, q-20.
  2. Playbook: q-3, q-7, q-10.
  3. Повтор через 24 часа: перепишите один ответ как context -> trade-off -> decision -> risk -> validation.

Критерий готовности​

Ready: вы показываете decision matrix, ADR, reliability checklist и quality gate dry-run; каждый artifact имеет owner, risk и validation.

Partial: artifact есть, но в нем нет owner, rollback trigger, exception rule или verification.

Not ready: ответ сводится к "надо договориться" или "надо написать ADR" без criteria, trade-offs и проверки результата.

Артефакты после модуля​

  1. Набор decision matrix шаблонов.
  2. 2 ADR с альтернативами и рисками.
  3. Reliability checklist + postmortem template.
  4. 5 сильных interview-ответов по engineering mindset: architecture, rollout, quality gates, postmortem, leadership.

Куда дальше​

  1. Frontend-архитектура
  2. Tooling и Delivery
  3. Инженерные принципы