Глава 5: SOP “дизайн → PR” с агентом

Пролог: Parts Unlimited, 2014. Проблема Brent#

В 2014 Bill Palmer столкнулся с проблемой, которая угрожала всему Phoenix Project.

Проблема называлась “Brent”.

Brent — ведущий инженер, единственный человек, который понимал, как работают легаси‑системы Parts Unlimited:

• легаси‑конфигурации БД (Oracle 9i, кастомные схемы)
• слой интеграций с внешними системами (SAP, Salesforce, кастомные API)
• скрипты деплоя на Perl (написаны в 2005, никто не помнит, как работают)

Симптомы:

Любая задача, связанная с легаси:

• “Нужно изменить таймаут БД в продакшене” → эскалация к Brent
• “Скрипт деплоя упал на шаге интеграции” → эскалация к Brent
• “SAP API вернул 500, что делать?” → эскалация к Brent

Результат:

Brent работает очень много (в этом сюжете — порядка 60–70 часов/неделю). Bus factor = 1. Erik Reid, наставник Bill Palmer, спросил: “Что будет, если Brent заболеет? Или уволится?”

Bill ответил честно: “Мы остановимся.”

Корневая причина:

Знания Brent — в голове. Нет документации. Нет runbooks. Нет SOP. Каждый раз он делает изменение по-разному:

• Иногда пишет скрипт миграции
• Иногда делает ручной SQL update
• Иногда меняет конфиг и перезапускает сервис

Никто не знает почему он выбирает тот или иной подход. Результат воспроизводится (изменение работает), но процесс не воспроизводим.

Та же задача в 2026: как Lance решает с агентом#

Контекст: Lance Bishop в Parts Unlimited 2026 столкнулся с той же проблемой — есть senior-инженер (Richard Hendricks), который знает всё о легаси‑БД. Но Richard уходит в отпуск на 3 недели.

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

Решение Lance: создать SOP “дизайн → PR” с агентом, который может воспроизвести процесс Richard.

Ключевой инсайт:

В 2014 Brent делал изменение сам, знания оставались в голове. В 2026 Richard один раз проходит процесс с агентом, фиксируя его в SOP. Агент записывает каждый шаг, каждое решение, каждую контрольную точку.

Результат: SOP, который команда может использовать без Richard.

Быстрый старт (15-30 минут)#

Цель#

Создать SOP для типичной задачи: “Изменить таймаут подключения к БД в легаси Oracle DB”.

Что нужно#

• Агент (например, Cursor)
• Доступ к легаси‑кодовой базе (только чтение для начала)
• 1 типичная задача, которую senior-инженер делает регулярно

Термины (1 минута, чтобы не путаться)#

• Acceptance Criteria (AC) — что должно получиться (ожидаемое поведение/результат).
• Definition of Done (DoD) / критерии готовности — какие доказательства считаем достаточными, чтобы назвать работу “готовой” (проверяемые утверждения).
• План проверки — как именно мы получим эти доказательства (тесты/метрики/выборки).
• STOP — условия остановки: когда агент обязан остановиться и эскалировать.

Для людей AC иногда “дотягиваются” за счёт диалога и контекста. Для агента это не работает, поэтому DoD + план проверки + STOP — минимальный контракт.

Практика: управление контекстом (чтобы агент не тонул)#

Обычно вам не нужно вручную “тащить в чат” половину репозитория. Это создаёт шум и часто ухудшает качество результата.

• Если вы знаете точное место (файл/директория/компонент) — укажите его явно.
• Если не знаете — попросите агента сначала найти релевантные файлы (поиск/семантический поиск) и перечислить их, прежде чем что‑то менять.
• Не прикладывайте “всё подряд”: лучше 1–3 точных артефакта + явный запрос “что ещё нужно прочитать”.

Как пример реализации этих практик в инструментах (включая ориентирование на текущую ветку/дифф и связанные файлы) см. Cursor: Best practices for coding with agents.

Практика: если агент пошёл не туда — вернитесь к плану, а не «латайте» перепиской#

Если агент делает не то (не тот scope, пропущены ограничения/DoD, неверные приоритеты), часто быстрее:

• откатить изменения,
• уточнить план (входы, ограничения, критерии “готово”, план проверки),
• перезапустить выполнение по обновлённому плану.

Это снижает дрейф и риск “археологии чата”. См. «Starting over from a plan»: Cursor: Best practices for coding with agents.

Практика: TDD‑контур с агентом (как жёсткая «цель итерации»)#

Когда изменение должно быть доказуемым (и у вас есть способ тестировать), удобно использовать короткий TDD‑цикл:

• сначала написать/обновить тесты (или golden tests) под ожидаемое поведение,
• запустить и убедиться, что они падают (контроль, что проверка реальна),
• реализовать минимальный фикс до “зелёного”,
• зафиксировать результат (PR/CI‑артефакты) как доказательство.

Это особенно хорошо ложится на наши контрольные точки 2–3 (реализация → тестирование).

Мини‑гайд: как описывать роли‑воркеры (специализированные агенты)#

Когда задача длинная и неоднородная (дизайн → реализация → тесты → PR), один “универсальный” агент начинает расплываться. Практичнее работать через несколько узких ролей‑воркеров (исполнителей), где каждый делает одну вещь и возвращает результат фиксированного формата.

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

Шаблон роли‑воркера (вендор‑нейтрально):

• Когда использовать: чёткие триггеры (“ошибка тестов”, “нужна проверка безопасности”, “нужен план тестирования”).
• Одна ответственность: ровно 1 цель (“сформировать план тестирования”, “проверить риск данных”, “найти root cause падения тестов”).
• Входы: какие артефакты требуются (дифф/PR, логи CI, ссылки на метрики, список файлов).
• Выход: строгая структура (например: findings[], evidence[], proposed_fix, verification_steps, stop_reason).
• Ограничения: read‑only по умолчанию; опасные действия только через STOP + подтверждение.
• Проверка: что считается “done” (тесты зелёные, линтер без новых ошибок, воспроизведение подтверждено/опровергнуто).

Анти‑паттерн: десятки “универсальных помощников” с расплывчатыми описаниями. Если роль не отличается по входам/выходам и критериям успеха — это не роль, а шум.

Откат: базовый и расширенный#

Базовый путь отката нужен всегда: вы должны понимать, как “вернуть назад” изменение, если оно оказалось неверным. В большинстве случаев это стандартная схема revert → redeploy (откатить коммит/PR и перевыкатить).

Отдельный, подробный план отката (с оценкой времени, шагами проверки и — по возможности — тестом на стейджинге) нужен по триггерам риска, например если изменение затрагивает:

• продакшен‑данные и миграции/необратимые операции
• доступность/платежи/критичные пользовательские потоки
• безопасность и доступы
• инфраструктуру/конфиги деплоя, где ошибка = простой

SOP-промпт для агента#

Роль: ты — агент для документирования процесса разработки изменения.

Контекст:
  - Senior-инженер (Richard Hendricks) делает изменение: "увеличить DB connection timeout с 30s → 60s"
- Мне нужно зафиксировать процесс так, чтобы команда могла воспроизвести

Ограничения безопасности:
- Не выполняй опасные/изменяющие команды в production. Если шаг потенциально меняет состояние (деплой, перезапуск, миграции, удаление) — STOP и запроси подтверждение.
- В SOP не должны попадать секреты/PII и сырые логи: используй маскирование и ссылки на артефакты/коммиты.

Задача:
1) Дизайн‑ревью (контрольная точка 1): Richard, какие компоненты затронуты?
2) Для каждого компонента: файлы, параметры, зависимости
3) Риски: что может пойти не так?
4) План тестирования: как проверить что изменение работает?
5) Откат: какой **базовый путь отката** (обычно revert → redeploy) и нужен ли **отдельный план отката** по триггерам риска?

Формат SOP:

## Изменение: [название]

### Контрольная точка 1: Дизайн‑ревью

**Область изменения (что меняем):**
- Компонент X: файл Y, параметр Z
- Компонент A: файл B, параметр C

**Зависимости (что зависит от этого):**
- Сервис 1 (может упасть, если timeout меньше X)
- Интеграция 2 (может уйти в таймаут, если timeout больше Y)

**Риски:**
- Риск 1: [описание] → [вероятность] → [влияние] → [митигация]

**УСЛОВИЯ ОСТАНОВКИ:**
- Если зависимости неясны → остановись, спроси у Richard Hendricks
- Если есть активные инциденты → отложи изменение

### Контрольная точка 2: Реализация

**Файлы для изменения:**
- `config/db.yml`: `connection_timeout: 30 → 60`
- `services/legacy/db_client.go`: update default value

**Шаги проверки:**
- Сборка: `make build` (должна пройти без ошибок)
- Линтер: `make lint` (без новых предупреждений)
- Unit tests: `make test-unit` (все зелёные)

**УСЛОВИЯ ОСТАНОВКИ:**
- Если сборка упала → исправь, повтори контрольная точка 2
- Если тесты красные → разберись, исправь, повтори

### Контрольная точка 3: Тестирование

**Интеграционные тесты:**
- Тест 1: подключение к БД успешно с новым таймаутом
- Тест 2: выполнение запроса за 60s или быстрее не падает
- Тест 3: выполнение запроса дольше 60s падает с ошибкой таймаута

**Ручная проверка:**
- Деплой на стейджинг
- Запустить смоук‑тесты: [список команд]
- Проверить логи: нет ошибок

**УСЛОВИЯ ОСТАНОВКИ:**
- Если интеграционные тесты упали → разберись с первопричиной
- Если деплой на стейджинг упал → откат, разберись

### Контрольная точка 4: PR + ревью

**Чеклист PR:**
- Дизайн‑ревью пройдено (контрольная точка 1)
- Реализация проверена (контрольная точка 2)
- Тесты прошли (контрольная точка 3)
- Базовый путь отката определён (обычно revert → redeploy); отдельный план отката — если нужен по триггерам риска
- План миграции (если нужен)

**Фокус ревью:**
- Митигация рисков: достаточно ли?
- Покрытие тестами: проверены все граничные случаи?
- Откат: если требуется протестированный откат — протестирован ли?

**Критерии готовности (DoD):**
- PR одобрен 2 ревьюерами
- CI/CD зелёный
- Деплой на стейджинг успешен

РЕЖИМ ВЫПОЛНЕНИЯ:
- Агент задаёт вопросы Richard Hendricks на каждой контрольной точке
- Агент фиксирует ответы в SOP
- Агент генерирует чеклисты для команды

Шаги#

1. Скопируй промпт в чат
2. Пройди процесс со старшим инженером (Richard отвечает на вопросы агента)
3. Агент выполняет команды для проверки (сборка, линтер, тесты) в безопасной среде (локально/стейджинг) и без опасных операций
4. Агент генерирует SOP на основе ответов + результатов проверки
5. Проверка результата: следующий инженер использует SOP для похожей задачи

Как обсуждать и поддерживать SOP (чтобы он не “протух”)#

• SOP живёт в Git рядом с кодом и меняется так же, как код: через MR/PR, ревью и историю изменений.
• Таск‑трекер — для коммуникации: в карточке обсуждаем нюансы, фиксируем статус и кладём ссылки на:
  • MR/PR с изменением SOP
  • конкретную версию SOP (commit/tag), на которую опирается агент
• Владелец (owner) обязателен: за каждый SOP отвечает конкретная роль/человек (например, владелец домена/платформы). Без владельца SOP быстро превращается в “кладбище ссылок”.
• Периодический пересмотр: раз в квартал (или после крупных изменений системы) владелец проходит по SOP и обновляет “протухшие” шаги/проверки.

SOP как переносимый «пакет компетенции» (skill)#

Когда SOP перестаёт быть “одной страницей для одной задачи” и начинает жить годами, удобно хранить его не только как текст, но и как структурированный пакет:

• SKILL.md: краткое “когда применять” + основная процедура
• assets/: шаблоны чеклистов, PR‑описаний, форматов артефактов
• references/: политики, edge cases, примеры и объяснения “почему так”
• scripts/: повторяемые проверки (линтеры, валидация форматов, генерация отчётов) — только при sandbox/разрешённом списке/аудите (см. главу 7)

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

Пример результата#

Агент написал и выполнил серию команд для проверки области изменения:

# Агент выполнил поиск всех упоминаний connection_timeout
grep -r "connection_timeout" ./config ./services
# Результат: 3 файла затронуты

# Агент выполнил анализ зависимостей
go list -m -json all | jq '.Path' | grep legacy
# Результат: 5 зависимостей найдено

# Агент запустил тесты
make test-unit
# Результат: 120 тестов прошло, 0 упало

SOP (сгенерирован агентом):

## Изменение: увеличить таймаут подключения к БД (30s → 60s)

### Контрольная точка 1: Дизайн‑ревью

**Область изменения:**
- `config/db.yml`: `connection_timeout: 30 → 60`
- `services/legacy/db_client.go`: обновить константу по умолчанию
- `services/api/handlers/query.go`: обновить валидацию таймаута (отклонять запросы > 60s)

**Зависимости (проверено агентом):**
- `user-service` (использует `db_client`, не зависит от таймаута)
- `report-service` (использует `db_client`, запросы до 10s, безопасно)
- `analytics-service` (использует `db_client`, запросы ~ 45s, нужно проверить)

**Риски:**
- **Риск 1:** аналитические запросы могут уйти в таймаут (вероятность: СРЕДНЯЯ, влияние: ВЫСОКОЕ)
  - **Митигация:** проверить аналитические запросы на стейджинге; если дольше 60s → увеличить до 90s
- **Риск 2:** зависимые сервисы могут ожидать таймаут меньше 60s (вероятность: НИЗКАЯ, влияние: СРЕДНЕЕ)
  - **Митигация:** проверить интеграционные тесты, если упали → разберись

**УСЛОВИЯ ОСТАНОВКИ:**
-  Зависимости проверены агентом (5 найдено, 3 безопасно, 1 нужна проверка)
- ⚠︎ `analytics-service` требует ручной проверки → СТОП, проверь на стейджинге

### Контрольная точка 2: Реализация

**Изменённые файлы:**
```diff
# config/db.yml
-connection_timeout: 30
+connection_timeout: 60

# services/legacy/db_client.go
-const DefaultTimeout = 30 * time.Second
+const DefaultTimeout = 60 * time.Second

# services/api/handlers/query.go
-if queryTimeout > 30 {
+if queryTimeout > 60 {

Проверка результата (выполнено агентом):

• Сборка: make build (passed, 2m 15s)
• Линтер: make lint (no new warnings)
• Модульные тесты: make test-unit (120 passed, 0 failed)

Контрольная точка 3: Тестирование#

Интеграционные тесты (выполнено агентом на стейджинге):

• Тест 1: подключение к БД успешно (timeout = 60s)
• Тест 2: выполнение запроса 45s → success
• ⚠︎ Тест 3: аналитический запрос 55s → success (было на грани с 30s timeout)

Ручная проверка (нужна для аналитики):

• Деплой на стейджинг (Ansible: dry-run обязателен) → подтверждение → apply:
  • ansible-playbook -i inventories/staging playbooks/db-config.yml --check --diff
  • ansible-playbook -i inventories/staging playbooks/db-config.yml --diff
• Запустить смоук‑тест для аналитики: ./scripts/analytics-smoke.sh
• Проверить логи: ssh staging-analytics-01 "sudo journalctl -u analytics-service --since '15 min ago' | grep timeout"

Результат:

• Аналитические запросы теперь проходят (было 55s, запас 5s)
• Нет ошибок в логах

Контрольная точка 4: PR#

Чеклист PR:

• контрольная точка 1 пройден (зависимости проверены, риски для аналитики промитигированы)
• контрольная точка 2 пройден (сборка + тесты зелёные)
• контрольная точка 3 пройден (деплой на стейджинг успешен)
• План отката: откатить изменение конфига, redeploy (до 5 минут)

ГОТОВО: PR #142 смержен, выкачено в продакшен

**Время выполнения:**
- В 2014 Brent делал это вручную: 4-6 часов (дизайн в голове, реализация, ручное тестирование)
- В 2026 агент + Richard + SOP: 45 минут (15 минут дизайн с агентом, 20 минут реализация/тестирование агентом, 10 минут проверка результата)

**Суть отличия:** теперь у команды есть SOP. Следующий инженер использует его и делает похожее изменение за 30 минут без участия Richard Hendricks.

---

## Теория: почему SOP + контрольная точка критичны для агентов

### Концепция 1: контрольная точка как точка принятия решения

**Проблема в 2014:**

Brent делал изменение так:
1. Смотрит на задачу
2. Думает (5-10 минут)
3. Пишет код
4. Тестирует
5. Деплоит

Шаг 2 ("думает") — чёрный ящик. Никто не знает:
- какие альтернативы он рассматривал
- какие риски он учитывал
- почему он выбрал это решение

Результат: команда не может воспроизвести процесс.

**Решение в 2026:**

контрольная точка — это **остановка агента для явного принятия решения**.

Агент выполняет контрольная точка 1: Design Review

1. Агент анализирует scope (выполняет grep, go list, проверяет зависимости)
2. Агент генерирует список компонентов + риски
3. Контрольная точка: агент останавливается и спрашивает: “Вот что я нашёл. Подтверди scope? Риски приемлемы?”
4. Человек отвечает: “Да” или “Нет, ты пропустил компонент X”
5. Агент фиксирует решение в SOP

**Зачем это нужно:**

- **Прозрачность:** процесс принятия решения явный
- **Воспроизводимость:** следующий инженер видит "почему это решение"
- **Безопасность:** человек контролирует критичные точки

В 2014 Brent принимал решения в голове. В 2026 агент фиксирует каждое решение на контрольной точке, делая процесс воспроизводимым.

### Концепция 2: контрольная точка 1 (Design Review) — почему нельзя сразу в код

**Типичная ошибка junior-инженера:**

Задача: "Увеличить DB timeout с 30s → 60s"

Junior видит:
```yaml
# config/db.yml
connection_timeout: 30

Junior думает: “Легко! Поменяю на 60 и всё.”

Junior меняет → коммит → PR → merge → deploy → авария в продакшене.

Что пошло не так:

Junior пропустил:

• services/api/handlers/query.go имеет hardcoded check if timeout > 30 { reject }
• analytics-service делает запросы ~ 55s, которые работали “на грани” с 30s timeout
• Интеграционные тесты не проверяют запросы > 30s

Результат: изменение не полное, авария в продакшене.

Почему контрольная точка 1 предотвращает это:

контрольная точка 1: Дизайн‑ревью

Агент выполняет:
1. grep -r "connection_timeout" (находит 3 файла, не 1)
2. go list -m -json all (находит 5 зависимостей)
3. Строит граф зависимостей: кто использует `db_client`?
4. **СТОП:** Агент спрашивает: "Я нашёл 3 файла и 5 зависимостей. Все нужно изменить?"

Человек проверяет → понимает, что `query.go` тоже нужен → добавляет в область изменения

В 2014: Brent делал это в голове за 5 минут (опыт). Junior не может.

В 2026: агент выполняет те же команды, что Brent делал вручную (grep, анализ зависимостей), и фиксирует результат для ревью.

Концепция 3: контрольная точка 2 — реализация: границы ответственности и обработка ошибок#

Проблема в 2014:

Brent пишет код. Код работает. Но:

• Обработка ошибок перемешана: где-то return err, где-то panic, где-то log.Fatal
• Границы ответственности неясны: где заканчивается ответственность db_client?

Результат: следующий инженер не понимает “куда добавлять код”.

Решение в 2026: контрольная точка 2 проверяет границы ответственности

контрольная точка 2: Реализация

Агент проверяет:
1. Границы ответственности: изменения внутри одного компонента или пересекают границы?
2. Обработка ошибок: соответствует ли принятым правилам проекта?
3. Зависимости: добавились ли новые зависимости?
4. Тесты: покрыты ли изменения тестами?

**УСЛОВИЯ ОСТАНОВКИ:**
- Если изменения пересекают границы ответственности → эскалируй архитектору
- Если появились новые зависимости → проверь лицензию и безопасность
- Если нет тестов → напиши тесты или объясни, почему они не нужны

Пример:

// services/legacy/db_client.go (контрольная точка 2: boundary check)

//  GOOD: изменение внутренней реализации
func (c *Client) Connect() error {
    c.timeout = 60 * time.Second // было 30
    return c.connect()
}

//  BAD: изменение затрагивает внешний API
func (c *Client) Connect(timeout time.Duration) error {
    // Это меняет сигнатуру → breaking change → нужен план миграции
}

Агент проверяет: “Это внутренняя правка или breaking change?” → СТОП → спрашивает человека.

В 2014 Brent знал границы ответственности (опыт). В 2026 агент проверяет границы ответственности автоматически через анализ кода (используя grep, AST parsing).

Концепция 4: контрольная точка 3 — тестирование: не “тесты прошли”, а “покрытие достаточное”#

Проблема в 2014:

Brent тестирует изменение на staging:

• Запускает сервис
• Делает 2-3 ручных запроса
• Смотрит логи: “вроде работает”
• Деплоит в production

Риск: граничные случаи не проверены.

Решение в 2026: контрольная точка 3 требует явного покрытия тестами

Пример артефакта контрольной точки 3 (матрица тестов):

Контрольная точка 3: Тестирование

Матрица тестов:

Покрытие:

• Основной путь: ✓
• Граничные случаи: ✓
• Обработка ошибок: ✓
• Откат: ⚠︎ если требуется протестированный откат и он не протестирован → СТОП, сначала протестируй откат

Агент генерирует матрицу тестов на основе области изменения:

• Находит все пути выполнения (normal, edge, error)
• Генерирует тесты
• Выполняет тесты на staging
• Проверяет покрытие

В 2014 Brent тестировал “на глаз”. В 2026 агент генерирует явную матрицу тестов и выполняет все сценарии автоматически.

Концепция 5: Условия остановки на каждой контрольной точке#

Зачем нужны условия остановки:

Агент не понимает “достаточно ли информации”. Условие остановки — это явное правило остановки.

Контрольная точка 1: УСЛОВИЯ ОСТАНОВКИ:

• Если зависимости неясны → СТОП, спроси архитектора
• Если есть активные инциденты → СТОП, отложи изменение (не делай изменение во время инцидента)
• Если влияние риска высокое и план снижения риска неясен → СТОП, эскалируй

Контрольная точка 2: УСЛОВИЯ ОСТАНОВКИ:

• Если сборка упала → СТОП, почини сборку
• Если тесты красные → СТОП, разберись почему
• Если новые зависимости без подтверждения → СТОП, запроси подтверждение

Контрольная точка 3: УСЛОВИЯ ОСТАНОВКИ:

• Если интеграционные тесты упали → СТОП, найди первопричину
• Если деплой на стейджинг упал → СТОП, откати, разберись
• Если требуется протестированный откат (по триггерам риска) и он не протестирован → СТОП, сначала протестируй откат

Принцип:

Агент не должен угадывать, что делать в неясной ситуации. Условие остановки — это эскалация человеку.

В 2014 Brent принимал решение “пойдёт или не пойдёт” на основе опыта. В 2026 агент останавливается и спрашивает явно.

Практика: полный SOP для типичного изменения#

Задача (реальный пример)#

Требование бизнеса: “Клиенты жалуются что отчёты генерируются > 2 минуты. Нужно увеличить timeout.”

Технический scope: изменить timeout в report-service с 120s → 300s.

SOP-промпт для агента#

Роль: ты — агент для разработки изменения по SOP.

Контекст:
- Изменение: увеличить report generation timeout (120s → 300s)
- Сервис: report-service
- Кодовая база: Go, PostgreSQL, systemd, deb‑пакеты, Ansible

Ограничения безопасности:
- Любые действия, которые меняют состояние production (деплой, перезапуск, миграции, изменение конфигов), выполняются только по утверждённому процессу и после явного подтверждения.
- По умолчанию выполняй только анализ/поиск/сбор артефактов (read-only). Если для шага нужен доступ/команда — сначала поясни риск и запроси подтверждение.
- Не включай секреты/PII в вывод и артефакты; используй маскирование и ссылки.

Задача: пройти контрольная точка 1 → контрольная точка 2 → контрольная точка 3 → контрольная точка 4

## Контрольная точка 1: Design Review

**Шаг 1:** найди все места где timeout упоминается
- Выполни: `grep -r "report.*timeout" ./services/report ./config`
- Зафиксируй: список файлов + строки

**Шаг 2:** найди зависимости (кто использует report-service?)
- Выполни: `go list -m -json all | jq '.Path' | grep report`
- Выполни: `ansible-inventory -i inventories/production --graph | grep -i report`
- Зафиксируй: список зависимостей

**Шаг 3:** построй матрицу рисков
- Риск 1: увеличение timeout → рост потребления ресурсов (DB connections held longer)
- Риск 2: downstream services могут timeout если ждут < 300s
- Риск 3: пользователи могут подумать что сервис "завис" (UX)

**УСЛОВИЯ ОСТАНОВКИ:**
- Если зависимостей > 5 → эскалируй архитектору (нужен более широкий анализ влияния)
- Если DB connection pool size < expected concurrent reports → СТОП (риск исчерпания подключений)

## Контрольная точка 2: Implementation

**Файлы для изменения (на основе контрольная точка 1):**

1. `config/report-service.yml`:
```yaml
report:
  generation_timeout: 300s  # было 120s

2. services/report/handler.go:

const ReportTimeout = 300 * time.Second  // было 120

3. services/api/client/report_client.go (downstream):

client := &http.Client{
    Timeout: 350 * time.Second,  // было 150s, нужен запас для 300s
}

Шаги проверки результата:

• Build: make build
• Linter: make lint
• Unit tests: make test-unit
• Check DB connection pool: достаточно ли connections для longer hold time?

УСЛОВИЯ ОСТАНОВКИ:

• Если build failed → fix, re-run
• Если tests red → investigate
• Если DB pool size < (concurrent_reports * avg_duration / timeout) → СТОП, increase pool size first

Контрольная точка 3: Testing#

Test matrix:

Интеграционные тесты:

• Деплой на стейджинг
• Запустить смоук‑тесты: ./scripts/report-smoke.sh
• Мониторить подключения к БД: ssh db-staging-01 "sudo -u postgres psql -c \"SELECT count(*) FROM pg_stat_activity WHERE application_name='report-service'\""
• Проверить логи: нет ошибок

УСЛОВИЯ ОСТАНОВКИ:

• Если любой тест упал → разберись с первопричиной
• Если DB connections > pool_size * 0.8 → СТОП (риск исчерпания пула)
• Если downstream timeout меньше 300s → СТОП, сначала исправь downstream

Контрольная точка 4: PR#

Чеклист PR:

• контрольная точка 1: область изменения + зависимости + риски задокументированы
• контрольная точка 2: реализация + тесты прошли
• контрольная точка 3: интеграционные тесты + деплой на стейджинг успешен
• План отката: revert config, redeploy (до 10 минут)
• Мониторинг: добавлен алерт report_duration > 280s (предупреждение перед таймаутом)

Фокус ревью:

• DB connection pool size: достаточен?
• Downstream services: все обновлены?
• UX: пользователи знают, что report может занять до 5 минут?

КРИТЕРИИ ГОТОВНОСТИ (DoD):

• PR одобрен 2 ревьюерами
• CI/CD зелёный
• Деплой на стейджинг успешен > 24 часа (без проблем)

РЕЖИМ ВЫПОЛНЕНИЯ:

• На каждом контрольная точка агент останавливается и показывает результаты
• Человек подтверждает: “продолжай” или “исправь X”
• Агент фиксирует все решения в SOP

### Результат выполнения

Агент выполняет контрольная точка 1 (команды выполнены автономно):

```bash
# Агент выполнил grep
$ grep -r "report.*timeout" ./services/report ./config
config/report-service.yml:  generation_timeout: 120s
services/report/handler.go:const ReportTimeout = 120 * time.Second
services/api/client/report_client.go:Timeout: 150 * time.Second

# Агент выполнил анализ зависимостей
$ go list -m -json all | jq -r '.Path' | grep report
github.com/company/report-service
github.com/company/api-gateway (uses report-client)
github.com/company/dashboard-service (uses report-client)

# Агент проверил пул подключений к БД
$ ssh db-staging-01 "sudo -u postgres psql -c \"SHOW max_connections;\""
max_connections = 100

$ ssh db-staging-01 "sudo -u postgres psql -c \"SELECT count(*) FROM pg_stat_activity WHERE application_name='report-service';\""
count = 12

# Агент рассчитал: max concurrent reports = 100 / (250s avg / 300s timeout) ≈ 120
# Текущее использование: 12, запас: 108 → БЕЗОПАСНО

Результат контрольная точка 1:

## Контрольная точка 1: Дизайн‑ревью — ПРОЙДЕНО

**Область изменения:**
- `config/report-service.yml`: timeout 120s → 300s
- `services/report/handler.go`: const 120s → 300s
- `services/api/client/report_client.go`: client timeout 150s → 350s (запас)

**Зависимости:**
- api-gateway (uses report-client, timeout увеличен до 350s)
- dashboard-service (uses report-client, timeout увеличен до 350s)

**Риски:**
- Риск 1: исчерпание пула подключений к БД (вероятность: НИЗКАЯ, влияние: ВЫСОКОЕ)
  - Митигация: проверено, текущее использование 12/100, запас 88 подключений
- Риск 2: таймауты downstream-сервисов (вероятность: СРЕДНЯЯ, влияние: ВЫСОКОЕ)
  - Митигация: увеличены client timeouts (350s > 300s)
- Риск 3: UX (пользователи думают, что service завис) (вероятность: СРЕДНЯЯ, влияние: СРЕДНЕЕ)
  - Митигация: добавить индикатор прогресса в интерфейсе (отдельной задачей)

**Решение:** перейти к контрольная точка 2

Агент выполняет контрольная точка 2:

# Агент написал и применил изменения
$ git diff config/report-service.yml
-  generation_timeout: 120s
+  generation_timeout: 300s

# Агент выполнил build
$ make build
Building report-service... OK (1m 23s)

# Агент выполнил тесты
$ make test-unit
Running 87 tests... OK (0m 45s)

Результат контрольная точка 2: ПРОЙДЕНО

Агент выполняет контрольная точка 3:

# Агент сделал деплой на staging
$ ansible-playbook -i inventories/staging playbooks/report-service.yml --tags deploy --check --diff --extra-vars "report_service_version=<NEW_VERSION>"

# Пакет решения + контрольная точка подтверждения (даже для staging — чтобы паттерн не “сломался” при переносе в production):
# - dry-run показал ожидаемые изменения
# - запроси подтверждение у ответственного за окружение/релиз
# - STOP без подтверждения
#
# Apply (после подтверждения):
$ ansible-playbook -i inventories/staging playbooks/report-service.yml --tags deploy --diff --extra-vars "report_service_version=<NEW_VERSION>"
Deploy report-service: OK

# Агент выполнил smoke‑тесты
$ ./scripts/report-smoke.sh
Test 1 (small report, 10s):  PASS
Test 2 (medium report, 120s):  PASS
Test 3 (large report, 250s):  PASS
Test 4 (timeout, 310s):  PASS (timeout error as expected)

# Агент проверил DB connections во время теста
$ ssh db-staging-01 "sudo -u postgres psql -c \"SELECT max(c) FROM (SELECT count(*) AS c FROM pg_stat_activity WHERE application_name='report-service' GROUP BY datname) AS counts;\""
max = 18 (пик на тесте 3, безопасный запас)

Результат контрольная точка 3: ПРОЙДЕНО

Контрольная точка 4: PR создан (#245)

## PR #245: Увеличить таймаут генерации отчёта (120s → 300s)

### Кратко
Пользователи жаловались на медленную генерацию отчётов (> 2 min). Увеличили таймаут до 300s.

### Контрольная точка 1: Дизайн‑ревью
- Область изменения: изменены 3 файла
- Зависимости: обновлены 2 downstream-сервиса
- Риски: пул подключений к БД проверен (запас достаточен)

### Контрольная точка 2: Реализация
- Сборка: прошла
- Тесты: 87/87 прошло
- Линтер: без новых предупреждений

### Контрольная точка 3: Тестирование
- Деплой на стейджинг: успешно
- Смоук‑тесты: 4/4 прошло
- Подключения к БД: пик 18/100 (безопасно)

### План отката
Dry-run (обязателен) → подтверждение → apply:

`ansible-playbook -i inventories/production playbooks/report-service.yml --tags rollback --check --diff --extra-vars "report_service_version=<PREV_VERSION>"`

`ansible-playbook -i inventories/production playbooks/report-service.yml --tags rollback --diff --extra-vars "report_service_version=<PREV_VERSION>"`
Оценка времени: до 5 минут

### Мониторинг
Добавили алерт: `report_duration > 280s` (предупреждение перед таймаутом)

**Reviewers:** @bob @kevin @stuart

Время выполнения:

• В 2014 Brent: 4-6 часов (дизайн в голове, реализация вручную, ручное тестирование)
• В 2026 агент + SOP: 1 час (20 min контрольная точка 1, 20 min контрольная точка 2, 20 min контрольная точка 3)

Ключевое: SOP теперь зафиксирован. Следующий инженер использует его для похожего изменения за 45 минут без участия старшего инженера.

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

Ошибка 1: Пропуск контрольная точка 1 (дизайн‑ревью)#

Сценарий:

Младший инженер: “Задача простая: увеличить таймаут. Зачем тратить время на ревью дизайна? Пойду сразу в код.”

# config/report-service.yml
-  generation_timeout: 120s
+  generation_timeout: 300s

Коммит → PR → слияние → деплой → авария в продакшене.

Что пошло не так:

Младший инженер пропустил:

• services/api/client/report_client.go имеет жёстко заданный timeout 150s (меньше новых 300s)
• DB connection pool не рассчитан на более длинное удержание соединений
• Downstream services timeout < 300s

Результат: таймауты downstream-сервисов → каскадный отказ → 2 часа простоя.

Вывод:

В 2014 Brent столкнулся с похожим инцидентом: кто-то (не Brent) изменил DB timeout без ревью дизайна → авария в продакшене. После этого Brent стал делать ревью дизайна для каждого изменения, но процесс оставался в голове.

В 2026 контрольная точка 1 делает ревью дизайна обязательным и структурированным: агент помогает с grep, анализом зависимостей и первичной оценкой рисков — те же шаги, что Brent делал вручную. В типовом кейсе это может занимать десятки минут вместо часа+ (порядок величины зависит от базы и качества артефактов).

Как избежать:

SOP с контрольной точкой 1 делает design review воспроизводимым:

• Агент выполняет анализ области изменения (grep, AST parsing)
• Агент выполняет проверку зависимостей (go list, инвентарь/конфиги деплоя)
• Агент выполняет расчёт рисков (connection pool, timeout chains)
• Человек проверяет результаты → approve/reject

Условие остановки: если инженер пропускает контрольная точка 1 → CI/CD должен отклонить PR: “Design review required (checklist not filled)”.

Ошибка 2: контрольная точка 2 без проверки результата#

Сценарий:

Richard написал код, но не запустил сборку/тесты локально:

// services/report/handler.go
const ReportTimeout = 300 * time.Second

Пуш → CI/CD → сборка упала → “Ой, опечатка”.

Проблема:

Цикл обратной связи медленный:

• Локальная сборка: 1 min
• CI/CD сборка: 5-10 min (queue + setup)

Результат: 10 минут потрачено на то, что можно было поймать за 1 минуту.

Вывод:

В 2014 Parts Unlimited CI/CD занимал 30-60 минут (legacy Jenkins). Инженеры пушили код “наугад” → долгий цикл обратной связи → раздражение.

В 2026 агент выполняет сборку/тесты локально перед пушем:

# Агент выполнил перед коммитом
$ make build && make lint && make test-unit
Building... OK
Linting... OK
Testing... OK

# Только после этого пуш
$ git push

Как избежать:

контрольная точка 2 включает локальную проверку результата:

• Агент выполняет сборку локально
• Агент выполняет тесты локально
• Только если всё зелёное → пуш

Условие остановки: если сборка/тесты упали → исправь локально, перезапусти контрольная точка 2.

Ошибка 3: контрольная точка 3 без деплоя на стейджинг#

Сценарий:

Lance: “Richard, тесты прошли локально — можно в продакшен?”

Риск:

Локальная среда ≠ продакшен:

• DB version разная
• Разные лимиты ресурсов/конфигурация systemd (CPU/memory limits, ulimit, systemd unit overrides)
• Задержка сети разная

Результат: работает локально, падает в продакшене.

Вывод:

В 2014 Parts Unlimited деплоили сразу в продакшен (стейджинга не было). Результат: каждый второй деплой падал.

Bill Palmer после 10-го инцидента создал стейджинг‑среду: “Теперь все изменения идут через staging first.”

В 2026 контрольная точка 3 делает деплой на стейджинг обязательным:

контрольная точка 3: Тестирование

1. Локальные тесты
2. Деплой на стейджинг
3. Смоук‑тесты на стейджинге
4. Мониторинг стейджинга 24 часа
5. Только после 24h → одобрить деплой в продакшен

**УСЛОВИЕ ОСТАНОВКИ:** если деплой на стейджинг упал → разберись, исправь, повтори контрольная точка 3

Как избежать:

SOP требует явной проверки на стейджинге:

• Агент деплоит на стейджинг
• Агент выполняет смоук‑тесты
• Агент мониторит стейджинг 24 часа
• Только если достаточно времени без проблем → человек одобряет деплой в продакшен

Ошибка 4: Нет пути отката (и нет плана, когда он нужен)#

Сценарий:

Деплой в продакшене → сервис упал → “Как откатить??”

Паника. 30 минут поиска, как сделать rollback. Простой растёт.

Вывод:

В 2014 Parts Unlimited столкнулись с payroll инцидентом: деплой упал, rollback занял 4 часа (никто не знал как).

Patty McKee после этого ввела правило: “Каждое изменение должно иметь путь отката до деплоя.”

В 2026 контрольная точка 4 фиксирует это как часть контракта:

контрольная точка 4: PR

**Путь отката (минимум, всегда):**
- revert → redeploy (как именно — по вашему стандарту деплоя)

**План отката (подробно, если требуется по триггерам риска):**
- Команда/шаги отката
- Оценка времени
- Проверка результата (например, смоук‑тест после отката)
- По возможности: протестировать на staging (вперёд → откат → проверка)

**УСЛОВИЕ ОСТАНОВКИ:** если по триггерам риска требуется протестированный откат, а он не протестирован → СТОП, сначала протестируй откат на стейджинге

Как избежать:

SOP делает откат частью процесса:

• Базовый путь отката определён всегда (чтобы не искать “как откатить” в момент аварии)
• Для рискованных изменений: агент готовит подробный план и (по возможности) тестирует откат на staging
• Только после этого можно честно сказать “Ready for deployment”

Параллельный трек: эволюция от 2014 к 2026#

Как это было в 2014 (Bill Palmer, проблема Brent)#

Сцена из книги (Главы 7-12 “The Phoenix Project”):

Ситуация: Brent — единственный человек в Parts Unlimited, который понимает легаси‑системы. Любое критичное изменение блокируется на нём. Команда ждёт, проекты задерживаются. Bill Palmer пытается решить “проблему Brent”.

Проблема Brent (начало книги):

• Нагрузка: 70+ часов/неделю (в этом сюжете; порядок величины, а не универсальная цифра)
• Bus factor: 1 (если Brent заболеет → компания останавливается)
• Знания: в голове Brent, не документировано
• Команда блокируется: 15-20 раз/неделю команда ждёт Brent для критичных изменений
• Рутина Brent: 80% времени на “скучные изменения” (обновления конфигурации, деплои), 20% на стратегическую работу

Действия (что делал Bill вручную):

Попытка 1 (провалилась): “Brent, напиши документацию”

• Время: 2 недели — Brent пытается писать документацию
• Результат: 50 страниц текста, который никто не читает и не использует (устаревает через месяц)
• Последствие: Bus factor = 1 (ничего не изменилось)

Попытка 2 (частично успешна): делегирование + наставничество

• Время: 6 месяцев — Bill организует парное обучение Brent с младшими инженерами
• Результат: 2-3 инженера могут делать базовые изменения (Bus factor: 1 → 3)
• Но: Brent всё ещё 50+ часов/неделю, делегированы только простые задачи

Попытка 3 (долгий успех, конец книги): документация + автоматизация + процесс

• Время: 12–18 месяцев — трансформация
• Действия:
  • Brent с командой документируют процессы (runbooks, чеклисты)
  • Автоматизация рутины (скрипты для деплоев, обновления конфигурации)
  • Обучение команды через структурированный онбординг
• Результат (конец “The Phoenix Project”):
  • Нагрузка Brent: 70 часов/неделю → 40 часов/неделю (-30 часов)
  • Bus factor: 1 → 3 (команда может делать большинство изменений без Brent)
  • Рутина Brent: 80% → 50% (больше стратегической ёмкости)
  • Команда блокируется: 15-20 раз/неделю → 5 раз/неделю (-75%)

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

Стоимость:

• Время Brent: существенная доля времени на документацию и обучение (высокие альтернативные издержки)
• Время команды: месяцы парного обучения и наставничества
• Итого: дорого по времени и организационному вниманию

Последствия:

• У Brent появляется окно для стратегической работы
• Риск Bus factor снижен: команда может работать без Brent (возможен отпуск)
• Но: документация быстро устаревает — её нужно поддерживать

Почему так долго/дорого:

• Причина 1: Документация долго создаётся (недели написания → десятки страниц, которые никто не читает)
• Причина 2: Неявные знания сложно передавать (наставничество требует месяцев парной работы)
• Причина 3: Документация протухает (изменения формата → документация устаревает → нужно переписывать)

Рефлексия Bill Palmer:

“Проблема Brent — это не про Brent. Это про то, что мы держим критичные знания в головах людей. Документация помогла, но это медленно. 18 месяцев, чтобы Bus factor стал 3. Если бы мы могли быстрее фиксировать знания Brent и сделать их воспроизводимыми…”

Итог Bill (конец книги “The Phoenix Project”):

• Нагрузка Brent: 70 часов/неделю → 40 часов/неделю
• Bus factor: 1 → 3 (команда обучена)
• Бизнес: Brent работает над стратегическими инициативами → эффект становится заметным
• Время до результата: 18 месяцев

Как это стало в 2026 (Lance Bishop, knowledge capture с агентами)#

Та же проблема (Richard Hendricks = “наш Brent”):

Ситуация: Richard Hendricks — эксперт в легаси‑слое БД. Команда блокируется на нём для изменений БД. Нагрузка 65+ часов/неделю. Bus factor = 1.

Подход Lance Bishop (2026): “Парное программирование с агентом для фиксации знаний”

Неделя 1: первый SOP с агентом

Действия:

1. Richard Hendricks делает типичное изменение (обновление таймаута БД) с агентом «в роли ученика»
2. Агент задаёт вопросы в реальном времени:
   • «Почему проверяешь размер пула подключений перед изменением таймаута?»
   • «Какие риски, если не проверить метрики и алерты?»
   • «Как сделать откат, если что-то пойдёт не так?»
3. Агент генерирует SOP с контрольными точками на основе ответов Richard
4. Richard делает ревью SOP (15 минут) + уточняет граничные случаи

Время: 4 часа (Richard делает изменение + отвечает на вопросы агента)

Результат:

• SOP готов (не 50 страниц текста, а структурированная процедура с контрольными точками)
• SOP исполним: агент может выполнить те же команды
• контрольная точка явно определяет, когда остановиться и спросить Richard

Недели 2-4: масштабирование SOP

• Неделя 2: ещё 3 SOP (обновление конфигурации, деплой, откат) — по 4 часа = 12 часов суммарно
• Неделя 3: младший инженер использует SOP + агент для простого изменения → успешно (Richard делает только ревью)
• Неделя 4: ещё 2 инженера обучены работать по SOP + агент

Месяцы 2-3: рост Bus factor

• Месяц 2: команда делает большую часть типовых изменений без Richard (agents + SOP)
• Месяц 3: Bus factor: 1 → 5+ (как целевой ориентир в этом кейсе; в реальности зависит от сложности домена и дисциплины поддержки SOP)

Суммарные затраты времени:

• Время Richard: 4 часа × 5 SOP = 20 часов за 3 месяца (не 9 месяцев, как у Brent)
• Обучение команды: SOP + агент = самообслуживание (без месяцев парной работы)

Стоимость:

• Время Richard: время эксперта на создание SOP и ответы на вопросы агента
• Время команды: обучение работе по SOP
• Итого: заметно ниже, чем “документировать и учить месяцами”

Последствия:

• Нагрузка Richard Hendricks: 65 часов/неделю → ~35 часов/неделю (в этом кейсе; требует подтверждения замерами)
• Рутина Richard Hendricks: 80% → 20% (агенты берут рутину через SOP)
• Bus factor: 1 → 5+ (ориентир; сравнение с Brent — иллюстративно)
• Команда блокируется: 15 раз/неделю → 2 раза/неделю (эскалация только на граничных случаях)
• Время до результата: 3 месяца (против 18 месяцев у Bill)

Почему так быстро/дёшево:

• Агент закрывает корневую причину 1: создание SOP автоматизируется (агент фиксирует процесс во время выполнения, а не «пишем документацию потом»)
• Агент закрывает корневую причину 2: неявные знания становятся явными (агент задаёт вопросы «почему/что/как» в реальном времени)
• Агент закрывает корневую причину 3: SOP остаётся актуальным (изменился формат → обновить SOP за 30 минут; агент адаптируется)

Рефлексия инженера:

“Bill Palmer потратил 18 месяцев, чтобы Bus factor Brent стал 3. Мы достигли Bus factor 5+ за 3 месяца.

Это не потому, что мы умнее. Это потому, что агенты автоматизируют фиксацию знаний:

• Brent писал документацию 2 недели → никто не читал
• Richard делает изменение 4 часа + агент фиксирует процесс → SOP готов сразу

Агенты = усилитель подхода Bill к документированию. Не замена, а исполнение заметно быстрее (порядок величины зависит от контекста и дисциплины процесса).”

Эффект мультипликатора: агенты усиливают улучшения Phoenix Project#

Вместо “таблиц мультипликаторов” важнее наблюдаемая закономерность:

• знания перестают быть “в голове эксперта” и становятся SOP, по которым может работать команда
• уменьшается вариативность исполнения (контрольная точка и условия остановки задают рамки)
• снижается зависимость от одного человека (эскалация становится исключением)
• поддержка процессов становится проще, потому что SOP обновляются вместе с изменениями системы

Что агенты добавляют к подходу Bill (documentation approach):

1. Автоматизированная фиксация: знания фиксируются во время выполнения (а не «сначала сделаем, потом когда‑нибудь задокументируем»)
2. Структурированный процесс: SOP с контрольными точками (а не свободный текст на 50 страниц, который никто не читает)
3. Исполнимость: агент может воспроизвести SOP (а не «читай инструкцию и делай руками»)
4. Самообновление: изменения формата → обновить промпт (а не переписывать документацию с нуля)
5. Масштабируемость: один эксперт + агент → SOP для всей команды сразу (а не месяцы парной работы)

Эволюция, а не революция#

Ключевая разница:

• В 2014: Bill Palmer использовал документацию + наставничество (медленно, вручную, быстро устаревает)
• В 2026: Lance Bishop использует документацию + наставничество + агентов (быстро, автоматизировано, самообновляется)

Не замена, а усиление:

Параллели с управлением людьми:

Bill Palmer (2014) делегировал людям через наставничество:

• Парная работа Brent с младшим инженером: 6 месяцев
• Младший инженер учится через наблюдение и вопросы
• Результат: младший инженер может делать базовые изменения (но не все граничные случаи)
• Время: месяцы на человека

Lance Bishop (2026) делегирует агенту через SOP:

• Richard делает изменение + агент фиксирует процесс: 4 часа
• Агент учится через вопросы «почему/что/как» в реальном времени
• Результат: агент может выполнить SOP (+ команда использует агента для тех же изменений)
• Время: 4 часа на создание SOP, сразу доступно для команды

Ключевой навык переносится:

• Bill учил команду через парную работу (делегирование задач)
• Lance учит агента через создание SOP (делегирование процесса)
• Принципы те же: делегирование, проверка, обратная связь
• Исполнение в разы быстрее (месяцы → недели)
  • (оценка порядка величины в этом сюжете; в реальных командах зависит от доступности артефактов, качества процессов и поддержки SOP)

Сравнение Phoenix Project: решение Bill для Brent и подход с агентами#

Подход Bill Palmer (2014, “The Phoenix Project”):

Хронология:

• Месяц 0: проблема Brent выявлена (Bus factor = 1, 70 часов/неделю)
• Месяц 3: попытка «написать документацию» (провалилась: никто не читает 50 страниц текста)
• Месяц 6: старт наставничества (Brent + 2 младших инженера, парная работа)
• Месяц 12: базовое делегирование работает (Bus factor: 1 → 2, простые изменения делегированы)
• Месяц 18: успех (Bus factor: 1 → 3, Brent 40 часов/неделю)

Ключевые вехи:

• Нагрузка Brent: 70 часов/неделю → 40 часов/неделю (-30 часов)
• Bus factor: 1 → 3 (2-3 инженера обучены за месяцы парной работы)
• Рутина Brent: 80% → 50% (делегирование простых задач)

Инвестиции:

• 18 месяцев трансформации
• Время Brent: существенная доля времени на документацию и наставничество (высокие альтернативные издержки)
• Время команды: месяцы парной работы и обучения
• Итого: дорого по времени и организационному вниманию

Возврат:

• У Brent появляется окно для стратегической работы
• Риск Bus factor снижен (команда может работать без Brent, возможен отпуск)
• Продуктивность команды: +20% (меньше ожидания Brent)

Ограничения:

• Документация быстро устаревает (нужна поддержка)
• Парная работа медленная (месяцы на инженера)
• Неявные знания сложно извлекать и формализовать

Подход инженера (2026, с агентами):

Хронология:

• Неделя 0: проблема Richard Hendricks (аналогично Brent; Bus factor = 1; 65 часов/неделю)
• Неделя 1: первый SOP с агентом (изменение таймаута БД, 4 часа)
• Недели 2–4: ещё 4 SOP (конфигурация, деплой, откат) + команда обучена
• Месяц 2: Bus factor: 1 → 4 (команда использует SOP + агент)
• Месяц 3: успех (Bus factor: 5+; Richard 35 часов/неделю)

Ключевые вехи:

• Нагрузка Richard Hendricks: 65 часов/неделю → 35 часов/неделю (-30 часов, как у Brent, но быстрее)
• Bus factor: 1 → 5+ (любой инженер + SOP + агент; без месяцев парной работы)
• Рутина Richard Hendricks: 80% → 20% (агенты забирают рутину через SOP)

Инвестиции:

• 3 месяца трансформации
• Время Richard Hendricks: создание SOP и ответы на вопросы агента
• Время команды: обучение работе по SOP
• Итого: заметно ниже, чем «документировать и учить месяцами»

Возврат:

• У Richard Hendricks появляется больше окна для стратегической работы (и меньше накладных расходов на поддержку)
• Bus factor: 5+ (против 3 у Bill) → устойчивость команды выше (без “точной” кратности)
• Продуктивность команды: заметно выше за счёт меньших ожиданий и более воспроизводимого процесса (метрика зависит от контекста)

Мультипликатор агентов для инвестиций Bill:

• Время до ценности: 3 месяца против 18 месяцев = условно “в разы быстрее” (как гипотеза/оценка порядка величины)
• Инвестиции: заметно ниже за счёт меньшей доли ручной координации и переобучения
• Достигнутый Bus factor: 5+ против 3 = выше (без “точной” кратности)
• Окупаемость: считать по вашему контексту (см. шаблон в Приложении A)

Проблемы, которые решают агенты:

• Протухание документации → SOP с агентом (самообновляется; агент адаптируется к изменениям формата)
• Парная работа медленная → создание SOP (4 часа, а не месяцы)
• Неявные знания → автоматизированная фиксация (агент задаёт вопросы в реальном времени)

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

Экономия времени#

Вместо “калькулятора” важнее динамика:

• SOP создаются быстрее, потому что знание фиксируется во время выполнения, а не «потом допишем»
• обучение превращается в самообслуживание (SOP + агент), а не в месяцы парной работы
• рутинные изменения выполняются по процедуре с контрольными точками и условиями остановки, снижая нагрузку на эксперта

Улучшения качества#

Сохранность знаний:

• До: знания в голове у Richard Hendricks; теряются, если он уходит или в отпуске (Bus factor = 1)
• После: знания в SOP; воспроизводимо любым инженером с агентом (Bus factor = 5+)
• Эффект: риск потери знаний существенно снижен; отпуск/уход меньше блокируют команду (при условии поддержки SOP и проверок)

Доля успешных изменений:

• До: «примерно» (ошибки человека: пропущенные шаги, «забыл проверить X»)
• После: например, 92% (иллюстративная метрика; в реальности считать по вашим данным и определить окно измерения)
• Эффект: меньше неудачных изменений за счёт воспроизводимости и проверок

Поддержка SOP:

• До: документация быстро протухает (изменения формата → документация устаревает → нужно переписывать каждые 6 месяцев)
• После: SOP проще поддерживать вместе с системой (изменения формата → обновить шаблон/промпт и проверки; время зависит от объёма изменений)
• Эффект: меньше стоимости поддержки: меньше “переписывать документацию”, больше “обновить шаблон и проверки”

Организационный эффект#

Нагрузка Richard Hendricks (эксперт):

• До: 65 часов/неделю (80% рутина, 20% стратегическая работа, риск выгорания)
• После: 35 часов/неделю (20% рутина на ревью/подтверждение, 80% стратегическая работа, устойчивый режим)
• Эффект: появляется устойчивое окно для стратегической работы

Команда блокируется на Richard Hendricks:

• До: 15 раз/неделю (команда ждёт, пока Richard сделает изменения)
• После: например, 2 раз/неделю (иллюстративно; в реальности зависит от того, какие задачи считаем “типовыми” и как измеряем)
• Эффект: снижение времени ожидания и блокировок, меньше “стоять и ждать эксперта”

Скорость роста Bus factor:

• До: 18 месяцев до Bus factor 3 (через документацию + парное обучение, в стиле Bill Palmer)
• После: 3 месяца до Bus factor 5+ (через SOP + агентов; как ориентир/гипотеза, требующая подтверждения на ваших данных)
• Эффект: критичный риск устраняется быстрее (Richard может уйти в отпуск, команда продолжает работать)

Экономическая модель (под ваш контекст)#

Экономический эффект здесь считается не “по цифрам из книги”, а по вашей модели времени и риска.

Как считать под ваш контекст:

• База: где команда теряет время (ожидание, ручная координация, повторяемые шаги)
• Цель: что делегируется агенту, где подтверждение, где условия остановки
• Стоимость: время внедрения SOP + поддержка шаблонов/проверок
• Ценность: снижение зависимости от эксперта + меньше блокировок + меньше ошибок в изменениях

Шаблон для расчёта — в Приложении A.

Сравнение с Phoenix Project#

Bill Palmer (2014, решение проблемы Brent):

• Инвестиции: существенные вложения времени и организационной дисциплины
• Хронология: длинная трансформация
• Возврат: снижение зависимости от эксперта, рост воспроизводимости
• Bus factor: растёт через документацию + наставничество

Lance Bishop (2026 с агентами):

• Инвестиции: время на SOP, контрольная точка и проверку
• Хронология: короче за счёт делегирования повторяемых шагов
• Возврат: меньше блокировок на эксперта, больше воспроизводимости
• Bus factor: растёт быстрее через SOP + агентов

Мультипликатор агентов для проблемы Brent:

• быстрее фиксация знаний
• меньше ручной координации и зависимостей
• проще масштабировать практику на команду

Кумулятивные метрики (Главы 1 → 5)#

Важнее “накопительных цифр” — накопительный эффект:

• процессы становятся воспроизводимыми
• зависимость от экспертов снижается через SOP и контрольные точки
• рутина уходит в делегирование, освобождая время на инженерные решения

Projected после Главы 10:

• Операционная экономия: заметный эффект на рутине и устойчивости
• Запуск Phoenix Project: бизнес-эффект проявляется за счёт более предсказуемой поставки

Трансформация бизнеса началась#

После месяца с SOP + агентами:

Возможности команды:

• Bus factor: 1 → 5+ (любой инженер + SOP + агент может делать изменения)
• Richard больше не узкое место (команда блокируется 15 раз/неделю → 2 раза/неделю)
• Знания зафиксированы: 5 SOP готовы, шаблон для новых SOP определён

Организационное обучение:

• Команда понимает: SOP ≠ свободный текст (SOP = исполнимый процесс с контрольными точками)
• Команда понимает: агенты могут фиксировать неявные знания (через вопросы во время выполнения)
• Команда понимает: делегирование агентам ≠ потеря контроля (человек подтверждает, агент выполняет)

Масштабируемость разблокирована:

• До: для масштабирования нужен Richard (линейно: больше работы → нужно больше экспертов)
• После: масштабирование через SOP + агентов (сублинейно: больше работы → та же команда + больше агентов)

Следующая волна:

• Выявлено: ещё 10 процессов для SOP (деплои, настройка мониторинга, ревью конфигурации)
• Хронология: 1 месяц на SOP × 10 = 10 месяцев (или параллельно, если есть несколько экспертов)

Сравнение: агенты и альтернативы для проблемы Brent#

Альтернатива 1: нанять ещё 2 старших инженеров (снизить зависимость от Richard Hendricks)

• Стоимость: найм и онбординг (время и деньги)
• Время до продуктивности: медленный разгон
• Риски: всё ещё узкие места (bus factor 1 → 3), знания в головах

Альтернатива 2: большой проект по документации (подход Bill Palmer 2014)

• Стоимость: высокая цена времени экспертов + организационная дисциплина
• Реализация: длинный цикл
• Поддержка: документация стареет и требует постоянной поддержки
• Риски: документация протухает, процесс не исполним, всё равно нужно обучение

Альтернатива 3: SOP + агенты (выбрано)

• Стоимость: время на SOP, обучение и поддержку шаблонов
• Реализация: короче за счёт делегирования повторяемых шагов
• Поддержка: регулярное обновление SOP/шаблонов
• Риски: снижены через контрольная точка + условия остановки

Преимущество агентов:

• ниже цена координации и меньше зависимость от экспертов
• быстрее путь от неявных знаний к воспроизводимому процессу
• Самообновление: SOP адаптируется к изменениям формата (обновить промпт 30 мин и переобучение months)

Подготовка к следующей главе#

Что сделать сразу:

1. Найдите одно узкое место‑эксперта в вашей команде (кто делает критичные изменения; Bus factor = 1)
2. Выберите один рутинный процесс изменения (что эксперт делает регулярно, 4–6 часов каждый раз)
3. Эксперт делает изменение + агент фиксирует процесс (4 часа, SOP сгенерирован)
4. Обучите 1–2 инженеров работать по SOP + с агентом (по 5 часов на человека; проверьте результат)

Что подготовить к следующей главе (Глава 6 — Operations/Incidents):

• Шаблон SOP готов → в Главе 6 применим к реагированию на инциденты (runbooks)
• Команда обучена делегированию → в Главе 6 делегируем рутинные инциденты агентам
• Bus factor улучшен → в Главе 6 масштабируем покрытие дежурств (без зависимости от одного эксперта)

Резюме#

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

Создали SOP «дизайн → PR» с 4 контрольными точками:

1. Контрольная точка 1 (дизайн‑ревью): область изменений + зависимости + риски
2. Контрольная точка 2 (реализация): код + локальная проверка (сборка/тесты)
3. Контрольная точка 3 (тестирование): деплой на стейджинг + смоук‑тесты + мониторинг
4. Контрольная точка 4 (PR): ревью + откат (базовый путь; план по триггерам риска) + критерии готовности

Артефакты#

• SOP «дизайн → PR» с 4 контрольными точками (готовый к копированию)
• Промпт для агента (генерация SOP из процесса старшего инженера / Senior)
• Пример реального изменения (таймаут генерации отчёта) с полным прохождением контрольных точек
• Чеклисты для каждой контрольной точки (условия остановки + критерии готовности)

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

В 2014: Brent держал процесс изменения в голове. Bus factor = 1. Команда не могла воспроизвести.

В 2026: SOP фиксирует процесс. Агент выполняет те же шаги (grep, сборка, тесты), что Brent делал вручную. Команда использует SOP без старшего инженера.

Суть отличия:

• В 2014: знания в голове Brent
• В 2026: знания в SOP + агент выполняет команды автономно

Метрики успеха:

• До SOP (2014): время изменения 4–6 часов (Brent), Bus factor 1, воспроизводимость 0%
• После SOP (2026): время изменения 1 час (агент + SOP), Bus factor 3+, воспроизводимость 95%

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

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

Уровень 1: Понимание

• Объяснить что такое контрольная точка и зачем он нужен
• Объяснить разницу между “Brent в голове” (2014) и “SOP + агент” (2026)
• Перечислить 4 контрольные точки и их назначение

Уровень 2: Применение

• Создать SOP для типичного изменения в вашем проекте
• Определить условия остановки для каждой контрольной точки
• Написать промпт для агента для контрольная точка 1 (Design Review)

Уровень 3: Воспроизводимость

• Использовать SOP для реального изменения с агентом
• Агент прошёл все 4 контрольные точки успешно
• Изменение ревьюируемо и тестируемо; путь отката определён, а при триггерах риска — откат протестирован

Уровень 4: Масштабирование

• SOP используется командой (не только вами)
• Bus factor увеличен (изменение может делать младший инженер без старшего)
• Время изменения снижено на 50%+ (по сравнению с ручным процессом)

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

Глава 6: Эксплуатация и инциденты — научим агента быть первой линией реагирования для рутинных инцидентов (runbooks + SLI/SLO + плейбук триажа).

Связь с Главой 5: SOP помог разработать изменение, но что делать, когда изменение задеплоено и его нужно эксплуатировать? Глава 6 покажет, как создать runbooks для агента.