Техническое лидерство: ADR, RFC, риски и production-инциденты

↑ 9.1 Team Lead и soft skills · ← Предыдущая · → Следующая

Обязательно~3 мин чтенияУровень: senior

Зачем это на собесе

Технический лид принимает и документирует решения и управляет рисками и инцидентами.

ADR (Architecture Decision Record)

Короткий документ о принятом решении.

# ADR-021: Хранение токенов
Статус: принято · Дата: 2026-06-02 · Авторы: ...
## Контекст
Приложение SPA с OIDC; риск XSS.
## Варианты
1. localStorage. 2. Память + refresh в HttpOnly cookie. 3. BFF.
## Решение
Вариант 2, вариант 3 рассмотреть при росте требований.
## Последствия
+ безопаснее; − сложнее refresh-логика; нужны CSRF-меры.

Хранение в репозитории (docs/adr), нумерация, статусы (proposed, accepted, superseded).

RFC

Документ для предложений с большим влиянием (архитектура, общие библиотеки, миграции): проблема, цели и не-цели, варианты, дизайн, риски, план внедрения, открытые вопросы. Круг рецензентов, срок обсуждения, ответственный за решение. Когда нужен: затрагивает несколько команд или необратим.

Управление рисками

ШагЧто
Идентификациясписок рисков в планировании
Оценкавероятность × влияние
Реакцияизбежать, снизить, передать, принять
Мониторингвладельцы, триггеры, регулярный пересмотр

Практики: feature flags, canary, автоматические откаты, спайки, пилотные внедрения.

Инциденты в продакшене

Действия:

  1. Обнаружение (алерты, Sentry, пользователи).
  2. Триаж и уровень серьёзности.
  3. Роли: incident commander, коммуникации, технические исполнители.
  4. Смягчение важнее диагностики: откат, отключение флага, деградация.
  5. Коммуникация: статус-страница, регулярные апдейты.
  6. Разрешение и проверка.
  7. Постмортем через 1–3 дня.

Blameless постмортем: хронология, причины (5 почему), что сработало, что нет, действия с владельцами и сроками. Без поиска виноватых: ищем сбои в системе.

Метрики

MTTD (обнаружение), MTTR (восстановление), частота инцидентов, change failure rate.

Вопросы с ответами