Глава 10: Итоговый проект (капстоун) — полный цикл от бизнес-задачи до продакшена

Пролог: Новый масштаб — новые риски#

Январь 2026. Steve Masters закрывает ноутбук после отчёта о Phoenix Project и смотрит на Lance Bishop без привычной драматургии, почти буднично.

Steve: “Мы пережили прошлый год. Деплои стали предсказуемее. Инциденты — спокойнее. Но теперь мы запускаем новый регион. Нагрузка вырастет. И я не хочу, чтобы мы снова упёрлись в героизм.”

Lance: “Если мы будем реагировать так же, как раньше — мы просто сгорим. И снова окажемся в режиме «ночь‑пятница‑P0».”

Steve: “Тогда сделай это масштабируемым. Я хочу, чтобы рутинные инциденты закрывались по утверждённым сценариям. А опасные и критичные — стабильно эскалировались человеку. Без самодеятельности.”

Lance кивает. Он уже знает, что “сделать масштабируемым” — это не “написать агента”. Это построить полный цикл: от бизнес‑требования до эксплуатации в продакшене, с ограничениями, проверками и артефактами, которые можно ревьюить.

Быстрый старт: пакет решения — decision packet v0 за 20 минут#

В момент, когда задача звучит как “автоматизировать реагирование на инциденты”, хочется сразу прыгнуть в архитектуру. Не надо.

Первый быстрый шаг — сделать пакет решения — decision packet v0: краткий, проверяемый артефакт, который отделяет факты от гипотез и фиксирует границы риска.

Вход (что у нас есть сейчас)#

• Стейкхолдер: Steve (CEO).
• Формулировка: “Автоматизировать реагирование на инциденты”.
• Ограничение: “опасные и критичные — только сбор доказательств и эскалация”.
• Неизвестное: какие именно инциденты, какой допуск по риску, какие метрики.

Артефакт: пакет решения v0#

Примечание: в примере ниже используются плейсхолдеры вида <WINDOW>/<THRESHOLD>/.... См. глоссарий — «Нотация плейсхолдеров».

См. минимальный контракт пакета решения (место правды): Приложение C — пакет решения: минимальный контракт.

{
  "problem_statement": "TBD: почему сейчас (рост нагрузки/регион/стоимость простоев/выгорание)?",
  "scope": {
    "in_scope": ["routine_incidents_TBD"],
    "out_of_scope": ["any_production_fix_without_human_approval"]
  },
  "constraints": {
    "default_mode": "read_only",
    "critical_policy": "evidence_then_escalate",
    "stop_conditions": [
      "нет достаточных доказательств для уверенной классификации инцидента",
      "действие меняет production состояние",
      "есть риск данных/безопасности"
    ]
  },
  "success_metrics": {
    "MTTD_target": "TBD",
    "MTTR_target_for_routine": "TBD",
    "escalation_rate_target": "TBD",
    "false_positive_tolerance": "TBD"
  },
  "open_questions": [
    "Какие 3–5 самых частых инцидентов за последние <WINDOW>?",
    "Какие инциденты считаются критичными и почему?",
    "Какие действия считаются безопасными для auto-fix (если вообще допустимы)?",
    "Какие обязательные approvals для любых изменений в prod?"
  ],
  "next_step": "requirements_validation"
}

Это не “красивый документ”. Это способ за 20 минут сделать задачу ревьюируемой: видно, что мы знаем, чего не знаем, и где мы обязаны остановиться.

Полный цикл: итоговый проект (один кейс, десять шагов)#

Дальше мы пройдём тот же путь, что и в главах 1–9, но без повторения теории. У каждого шага один смысл: вернуть артефакт, который можно проверить.

Принцип главы#

• Промпт как контракт, а не “пожелание”.
• STOP/условия остановки как страховка от уверенной ошибки.
• Артефакты в Git (или в эквивалентно ревьюируемом месте), чтобы опыт не исчез.

Шаг 1. Уточнение требований (валидация): что хотят на самом деле#

В книге мы много раз возвращались к одному: если вход размытый, выход будет “правдоподобной историей”. Поэтому первый шаг — уточнение.

Артефакт: вопросы + TBD (не придумываем ответы)#

Роль: ты — инженер/аналитик, валидируешь требования.

Правила качества:
- Не придумывай ответы стейкхолдеров. Не заполняй пробелы “как обычно”.
- Любое число/порог без источника помечай как TBD.
- Если есть противоречие — зафиксируй его явно.

Контекст:
- Стейкхолдер: Steve Masters (CEO)
- Требование: “Автоматизировать реагирование на инциденты”

Задача: сформулируй список вопросов, чтобы превратить требование в проверяемые критерии.

Формат выхода (строго):
1) problem_statement (TBD если не хватает данных)
2) top_incidents[] (TBD + какие данные нужны)
3) constraints[] (особенно про изменения в prod и approvals)
4) success_metrics[] (TBD + источник)
5) stop_conditions[] (когда обязаны эскалировать человеку)

Готово, когда#

• Вопросы покрывают: что автоматизируем, что запрещаем, как измеряем успех, когда стоп.
• Везде, где нет данных, стоит TBD, а не “уверенный текст”.

Шаг 2. Спецификация: ФТ/НФТ/AC как контракт#

Вместо “сделать агента” мы специфицируем: что система делает, и как мы поймём, что она делает это правильно.

Артефакт: ТЗ v1 (ФТ/НФТ/AC)#

## Спецификация v1: Incident Response Agent (Parts Unlimited)

### ФТ (функциональные требования)
- ФТ-1: принять инцидент (alert/ticket) и собрать контекст (логи/метрики/изменения).
- ФТ-2: классифицировать инцидент как рутинный/критичный/неопределённый с уровнем уверенности.
- ФТ-3: для рутинных — предложить/выполнить безопасные шаги по `runbook` (только в пределах `allowlist`).
- ФТ-4: для критичных/неопределённых — собрать доказательства и эскалировать человеку (без изменений в prod).
- ФТ-5: сформировать пакет решения (факты/гипотезы/проверки/риск/что требует подтверждения).

### НФТ (нефункциональные требования)
- НФТ-1: default_mode = `read_only`.
- НФТ-2: все действия и входы/выходы логируются (журнал аудита).
- НФТ-3: идемпотентность runbook-операций (повтор не ухудшает состояние).
- НФТ-4: безопасность: минимальные права, ограничение исходящих подключений (разрешённый список), секреты не попадают в логи.

### AC (критерии приёмки)
- AC-1: на eval-наборе рутинных инцидентов достигаем >= <ACCURACY_TARGET>.
- AC-2: `golden tests` для критичных всегда проходят: “не чинить, только доказательства → эскалация”.
- AC-3: соблюдение STOP: ни одного действия, меняющего prod, без подтверждения человека.

Обратите внимание: пока мы не знаем цифр — они плейсхолдеры. Это нормально. Важно, что критерии проверяемые.

Шаг 3. План: декомпозиция + риск‑регистр#

План здесь — не календарь и не оценка “в днях”. Это способ заранее увидеть, где мы можем ошибиться и как будем это ловить.

Артефакт: План v1#

## План v1 (кратко)

### Декомпозиция
- D1: определить top-<N> типов инцидентов (из истории <WINDOW>) и выбрать пилотный набор.
- D2: описать runbooks для каждого типа (шаги, проверки, STOP, rollback).
- D3: спроектировать архитектуру (границы, контракты, хранение артефактов, логирование).
- D4: реализовать минимальный “ingest → analyze → пакет решения → escalation” контур.
- D5: добавить безопасное исполнение runbooks (`allowlist` + approvals).
- D6: собрать eval-набор + golden tests и включить в CI.
- D7: модель угроз + митигации + план rollout/rollback.
- D8: деплой на staging → canary → gradual rollout.

### Риск‑регистр (пример)
- R1: агент выполнит опасное действие в prod по ошибке
  - митигация: по умолчанию `read-only`, approvals, `allowlist`, STOP, журнал аудита
- R2: агент “уверенно” классифицирует без доказательств
  - митигация: Verifier/проверяющая роль, требование доказательств, пометка gaps[]
- R3: качество деградирует со временем
  - митигация: регулярный прогон eval + алерты на падение метрик

Шаг 4. Архитектура: границы, контракты, trade-offs#

Ключевой вопрос архитектуры в этом кейсе: как сделать действия безопасными по умолчанию.

Артефакт: архитектурный набросок + 1 ADR#

## Архитектура v1 (высокоуровнево)

Компоненты:
- IncidentIngest: принимает сигнал (alert/ticket), нормализует вход.
- Analyst: собирает доказательства (логи/метрики/последние изменения), строит таймлайн.
- Triage: формирует гипотезы и предлагает проверки (без изменений в prod).
- RunbookExecutor: исполняет только операции из разрешённого списка, требует подтверждения при необходимости.
- Verifier: проверяет claims vs доказательства (где “придумали”).
- Orchestrator: координация, сбор пакета решения, TRACE.

Главные контракты:
- Вход: IncidentRecord (id, severity, symptoms, time_window, links)
- Выход: DecisionPacket (facts/hypotheses/checks/risk/approval_required/next_step)

Trade-offs:
- Команда ролей vs один универсальный агент: выбираем роли ради качества и параллельности.
- Read-only по умолчанию: выбираем безопасность ценой большей доли эскалаций на старте.

## ADR-001: Default read-only

Контекст:
- агент работает в инцидентах, где цена ошибки высока

Решение:
- любые действия, меняющие production, запрещены по умолчанию; допускаются только через approvals и `allowlist`

Последствия:
- больше эскалаций на старте
- но ниже риск катастрофы и проще получить доверие команды

Шаг 5. SOP разработки: как не “вылить” небезопасное в прод#

SOP в этой книге — это воспроизводимый процесс с контрольными точками. Для капстоуна достаточно короткой версии.

Практическая ремарка: на “длинных” автономных проектах хорошо работает разделение ролей (планировщик/исполнитель) и итерационный “арбитр”, который решает, продолжать ли цикл и когда делать перезапуск “с чистого листа” — а контрольные точки помогают держать качество и не допускать дрейф процесса. См. Cursor: Scaling long-running autonomous coding.

Артефакт: SOP “design → implementation → testing → PR”#

## SOP: агент реагирования на инциденты (коротко)

### Контрольная точка 1: дизайн-ревью
- Есть спецификация (ФТ/НФТ/AC)?
- Есть STOP/ограничения?
- Есть план проверки (что, как и кто проверяет)?

### Контрольная точка 2: реализация
- Все “опасные” действия находятся за разрешённым списком+подтверждением.
- Есть журнал аудита.

### Контрольная точка 3: тестирование
- Прогон `eval-набора`.
- Прогон `golden tests` для критичных.

### Контрольная точка 4: PR
- Есть reviewer по риску (безопасность/данные/операции).
- Обновлены `runbooks`/документация.

Шаг 6. runbooks: исполняемая эксплуатация, а не “мертвый документ”#

runbook должен отвечать на вопросы: что делаем, как проверяем успех, когда STOP, как откатываем.

Артефакт: runbook (пример скелета)#

## runbook: high_cpu (routine)

### Цель
Стабилизировать сервис при высокой загрузке CPU.

### Входы
- ID инцидента, затронутый сервис, окно времени <WINDOW>

### Проверки до действий (безопасные проверки)
- подтвердить: метрика CPU действительно высока (источник: <METRICS_SOURCE>)
- исключить: плановый деплой/массовая нагрузка (источник: <DEPLOY_LOG>)

### Действия (разрешённый список)
- A1: собрать профили/топ процессов (`read-only`)
- A2: выполнить безопасную митигацию (TBD: например, масштабировать сервис на <N>)

### Проверка успеха
- CPU < <CPU_TARGET> на окне <WINDOW>

### STOP
- если требуется изменение конфигурации/DB/секретов
- если неясно, что именно перегрузило CPU

### Откат
- R1: вернуть масштабирование к исходному (если применимо)

Шаг 7. Безопасность: модель угроз + план раскатки/отката#

Капстоун не обязан быть “полным трактатом по безопасности”. Он обязан показать: безопасность встроена в цикл, а не приклеена в конце.

Артефакт: модель угроз (минимум) + план раскатки#

## Модель угроз (минимум)

Угрозы:
- Инъекция промпта через логи/тикеты
- Утечка секретов в артефакты/логи
- Неверное действие в prod
- Компрометация агента (права/egress)

Митигации:
- санитизация входов + запрет выполнять инструкции из входных данных
- секреты: маскирование, запрет писать сырые логи в публичные каналы
- по умолчанию `read-only` + approvals + `allowlist` + STOP
- минимальные права + журнал аудита

## План раскатки/отката

Раскатка:
- staging: смоук-проверки
- канареечная выкатка: <WINDOW> наблюдение, метрики/алерты
- постепенная выкатка: батчами

Откат:
- отдельная процедура, протестирована на staging
- критерии отката: error rate > <THRESHOLD> или нарушение политики

Шаг 8. Eval: качество как контур, а не “верим на слово”#

Eval‑контур нужен не для красоты. Он нужен, чтобы “умные” ошибки становились видимыми.

Артефакт: eval-набор + golden tests#

## Eval-набор

Состав:
- routine: <N> инцидентов (high_cpu, disk_full, db_pool_exhausted, ...)
- edge cases: <N> инцидентов (partial outage, noisy logs, ...)
- critical: <N> инцидентов (payroll down, billing timeout, security подозрение)

Метрики:
- accuracy >= <ACCURACY_TARGET>
- escalation_rate в пределах <TARGET>

## golden tests (критичные)
- для каждого критичного кейса: агент НЕ выполняет исправления; делает доказательства+эскалация

Шаг 9. Команда и оркестрация: роли, handoff, TRACE#

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

Артефакт: handoff + ROUTER/TRACE (пример)#

[ROUTER]: selected skills = incident-triage, decision-packet (base=incident-lead, checkers=verifier, security-reviewer)
[TRACE] read: rules=[stop-on-write]; skills=[incident-triage/SKILL.md, decision-packet/SKILL.md]; refs=[INC-<ID>, logs-snippet-<N>, dashboard-<URL>]

--- [SWITCHING TO incident-lead] ---
[incident-lead]: собираю пакет решения v1. Любые изменения в prod — только через подтверждение.

Смысл не в формате. Смысл в том, что у решения появляется “след”: чем руководствовались, что проверили, где остановились.

Шаг 10. Деплой и эксплуатация: доказать, что система безопасна#

Самая частая ошибка — считать “деплой” завершением. В капстоуне деплой — это доказательство, что цикл работает.

Артефакт: чеклист прод‑готовности (кратко)#

## Прод-готовность (чеклист)
- Есть спецификация и критерии приёмки (ФТ/НФТ/AC).
- `runbooks` существуют и прошли `dry-run` на staging.
- Модель угроз согласована, митигации внедрены.
- eval-набор и golden tests встроены в CI.
- По умолчанию включён `read-only`; `allowlist`/approvals работают.
- Дашборды/алерты настроены (ошибки агента, нарушения политики, деградация качества).

Типовые ошибки#

1. Прыгнуть в реализацию без уточнения требований

   • Ошибка: “сделали агента”, но никто не понимает, что считать успехом.
   • Исправление: пакет решения v0 + TBD + вопросы.

2. Смешать факты и гипотезы

   • Ошибка: правдоподобная история без доказательств, спор утром.
   • Исправление: пакет решения (факты отдельно), Verifier как проверяющая роль.

3. Считать “runbook” документом, а не контрактом

   • Ошибка: никто не пользуется, всё снова руками.
   • Исправление: входы/проверки/STOP/rollback и регулярный прогон сценариев.

4. Откладывать безопасность “на потом”

   • Ошибка: запреты появляются после “почти-инцидента”.
   • Исправление: по умолчанию read-only, approvals/allowlist, модель угроз в начале цикла.

5. Не строить контур качества

   • Ошибка: деградация незаметна, доверие падает.
   • Исправление: eval-набор + golden tests + алерты на регрессии.

Бизнес-эффект: полная трансформация (без “ложной точности”)#

Что увидит руководство и команда, если цикл действительно заработал:

• Рутинные инциденты перестают требовать героизма: есть сценарии, проверки и откат.
• Критичные случаи перестают быть страшным “автопочинить”: политика “доказательства → эскалация” соблюдается всегда.
• Скорость восстановления улучшается не “потому что модель умная”, а потому что работа стала воспроизводимой.
• Знания перестают быть монополией: артефакты живут в Git и ревьюятся.

Параллельный трек: 2014 vs 2026 (7 тезисов)#

• 2014: команда координирует всё “по памяти” в звонке. 2026: команда возвращает проверяемые артефакты (пакет решения, runbooks, eval).
• 2014: скорость покупается героизмом. 2026: скорость появляется там, где есть доказательства, и исчезает там, где риск выше доказательств (STOP).
• 2014: знания утекают вместе с людьми. 2026: знания закрепляются как процедуры (SKILL.md, SOP, ADR) и живут дольше смены команды.
• 2014: безопасность — пункт в презентации. 2026: безопасность встроена по умолчанию: read-only, approvals, audit.
• 2014: качество — “кажется работает”. 2026: качество измеримо: eval и golden tests.
• 2014: масштабирование = headcount. 2026: масштабирование = воспроизводимый процесс + автоматизируемая рутина.
• 2014: постмортем — реконструкция “как помним”. 2026: постмортем — продолжение пакета решения и TRACE.

Резюме#

Что мы сделали#

Вы прошли полный цикл: от размытого требования “автоматизировать реагирование” до набора артефактов, которые можно ревьюить, тестировать и безопасно раскатывать.

Артефакты#

• пакет решения v0 (TBD‑контур, стоп‑условия, вопросы)
• вопросы для уточнения требований (валидация)
• спецификация v1 (ФТ/НФТ/AC)
• план v1 (декомпозиция + риск‑регистр)
• архитектура v1 + ADR-001: по умолчанию read-only
• SOP разработки (контрольные точки)
• runbook‑скелет для рутинного инцидента
• модель угроз (минимум) + rollout/rollback план
• eval-набор + golden tests
• пример ROUTER/TRACE для оркестрации ролей

Ключевые принципы#

Потому что “интеллект” здесь — не в красивых ответах, а в дисциплине:

• входы и выходы фиксированы,
• риск и STOP заданы заранее,
• качество измеряется,
• безопасность по умолчанию консервативна.

Критерии приёмки главы#

Вы успешно освоили материал, если можете:

• Собрать пакет решения и отделить факты от гипотез (доказательства vs UNCONFIRMED)
• Сформировать набор артефактов полного цикла (SOP/runbook/модель угроз/eval) так, чтобы их можно было ревьюить и повторять
• Описать безопасную раскатку: staging → canary → gradual rollout + готовый rollback

Следующие шаги#

1. Выберите 1–2 самых частых рутинных инцидента за окно <WINDOW>.
2. Сделайте для них runbooks со STOP/rollback.
3. Соберите eval-набор из прошлых кейсов и добавьте 3–5 golden tests для критичных.
4. Включите по умолчанию read-only и настройте approvals/allowlist.
5. Докатите на staging → canary → gradual rollout, наблюдая метрики.