Фаза 12. Operations: агент на дежурстве
«Витрина» в проде и принимает деньги. Теперь её надо эксплуатировать: следить за здоровьем, ловить инциденты, реагировать, разбирать после. On-call — дежурство.
Из всех фаз курса эта — та, где человеческое ограничение самое грубое и самое очевидное: человек не может смотреть на прод круглосуточно и не деградировать в три часа ночи. On-call существует ровно потому, что живой инженер конечен — а инцидент не спрашивает, выспался ли дежурный. Статья утверждает, что агент снимает именно это ограничение целиком, и оставляет человеку узкий класс инцидентов, которых система ещё не видела.
Роль человека сегодня
SRE, дежурный инженер, DevOps: мониторинг, алерты, дежурный график, детект и диагностика инцидентов, реакция, постмортемы. Классически — пейджер ночью, ручная диагностика под стрессом и усталостью, разбор после.
Разложим по слабостям, которые компенсирует эта роль. Человек не бдит непрерывно — нужен график и ротация. Человек ночью под стрессом хуже соображает — растёт время и цена ошибки. Человек забывает контекст прошлых инцидентов — нужны runbook и постмортемы как внешняя память. Почти вся организация on-call — это борьба с конечностью и деградацией живого дежурного.
Что передаём агенту
Ops-агент держит дежурство. Он следит за метриками, логами и трейсами, детектит аномалию, диагностирует, чинит известное по runbook, эскалирует неизвестное, пишет постмортем. И здесь преимущество не количественное, а качественное: агент доступен 24/7 без усталости, без деградации в ночную смену, без потери контекста между инцидентами. Три часа ночи для него не отличаются от трёх дня.
Меняется само ограничение фазы. On-call человека — это управление конечным ресурсом внимания. У агента этого ограничения нет вовсе. Дежурство перестаёт быть про «кто не спит», и становится про «что делать с инцидентом, которого мы ещё не видели».
Архитектура агента
State-machine фазы
Агент держит роль
Инструменты: наблюдаемость (метрики, логи, трейсы); корреляция аномалий; авто-remediation по runbook; откат и масштабирование; генератор постмортемов; механизм эскалации.
Артефакт
обработанные инциденты + постмортемы + запросы на изменение обратно в бэклог.
Передача дальше: постмортемы и запросы на фикс → Maintenance и Planning (ф.13 / ф.7). Постмортем как артефакт особенно выигрывает от агента. У людей его пишут неохотно, задним числом и неполно — под грузом усталости после инцидента. Агент пишет его в момент, с полным контекстом происходившего, и сразу заводит запрос на фикс в бэклог. Инцидент не растворяется в «ну, потушили», а превращается в задачу и в пополнение runbook.
- Входы: живой прод (ф.11), метрики/логи/трейсы,
architecture + ADR(ф.5), runbook. - Инструменты: наблюдаемость (метрики, логи, трейсы); корреляция аномалий; авто-remediation по runbook; откат и масштабирование; генератор постмортемов; механизм эскалации.
- Артефакт: обработанные инциденты + постмортемы + запросы на изменение обратно в бэклог.
- Триггер: алерт или аномалия в проде.
- Передача дальше: постмортемы и запросы на фикс → Maintenance и Planning (ф.13 / ф.7).
Постмортем как артефакт особенно выигрывает от агента. У людей его пишут неохотно, задним числом и неполно — под грузом усталости после инцидента. Агент пишет его в момент, с полным контекстом происходившего, и сразу заводит запрос на фикс в бэклог. Инцидент не растворяется в «ну, потушили», а превращается в задачу и в пополнение runbook.
Где ломается
Novel-инциденты вне runbook. Агент силён на известных паттернах — то, что описано в runbook, он отработает быстрее и точнее человека. Слабее — на «такого мы ещё не видели»: инцидент без прецедента, где нужно понять новую причину, а не применить готовый рецепт. Хуже того — автономная remediation по неверно распознанному паттерну может усугубить: агент уверенно применит не то лекарство.
Blast radius автономного действия. Агент, действующий в проде сам и быстро, при ошибочной диагностике делает хуже быстрее, чем человек. Скорость реакции — и сила, и множитель урона. Нужны жёсткие границы того, что агент может сделать сам, а что — только с эскалацией.
Ответственность за прод под нагрузкой. Даунтайм, затронувший деньги и данные пользователей вживую, — вопрос ответственности. Агент реагирует; отвечает за последствия субъект.
Что остаётся человеку
Эскалация для novel-инцидентов и «большая красная кнопка». Кандидат на сжатие: чем богаче runbook и чем выше доверие к авто-remediation, тем реже нужен человек — каждый разобранный novel-инцидент пополняет runbook и в следующий раз обрабатывается автономно. Устойчивое ядро — небывалый инцидент и полномочие остановить, и оно вплетено в governance (ф.14).
остаток человека ≈ 19%
Провокация / тезис
On-call — это дежурство против единственного ограничения: человек не может смотреть на прод непрерывно и не деградирует ночью. Агент снимает ровно это ограничение — целиком, а не частично. Дежурный график, ротация, «кто не спит» — вся организация on-call была протоколом управления конечностью живого инженера, и ей больше нечем управлять. Остаётся узкий класс инцидентов без прецедента — единственное, что оправдывает живого человека в контуре эксплуатации, и то лишь пока runbook их не поглотил.
«Витрина» на этой фазе
Ночью платёжный провайдер «Витрины» начинает деградировать — растёт latency подтверждений оплаты. Ops-агент ловит аномалию по метрике, коррелирует с внешним статусом провайдера, распознаёт известный паттерн (он есть в runbook — заложен после ADR ф.5 про хрупкость платёжного контура) и переключает на резервного провайдера по авто-remediation. Пишет постмортем, заводит в бэклог задачу на ретраи с экспоненциальной задержкой. Всё это — в три часа ночи, без единого разбуженного человека.
А теперь граница. Если бы деградация была не «известным паттерном из runbook», а чем-то небывалым — например, провайдер молча проводил бы платежи дважды, а метрики latency при этом оставались бы в норме, — Ops-агент не имел бы готового рецепта, а автономное действие по ошибочной гипотезе тронуло бы реальные деньги пользователей. Вот тут — эскалация к фаундеру и красная кнопка. Известное агент забирает целиком; небывалое, затрагивающее деньги, — единственный остаток человека. Артефакт → инцидент + постмортем «Витрины», задача в бэклог для ф.13.
Как это устроено — инженерные разборы
Отдельные howto из практики, где фаза показана на работающем коде и артефакте.
- Event-tracker двумя способами: UDP fire-and-forget против HTTP+PostgreSQLТелеметрия двумя способами: UDP fire-and-forget против HTTP+PostgreSQL.
- Async MCP server с job queue: почему polling, а не блокирующий вызовОчередь задач под долгие операции — устойчивость эксплуатации.
Читать дальше
Строите AI-driven доставку у себя?
Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.
Написать на почтуДвижок перехода
Next Move Engine — система, которая доводит команду до автономного цикла доставки.
Next Move Engine →