Зона 3 — Обслуживание (черновик разведки)¶

Собрано по рамке razvedka-ramka.md. Проект → О проекте.

Общая картина зоны в одном абзаце: методология здесь есть, и она не пустая — но почти вся написана либо теми, кто продаёт платформу, либо одной компанией про себя. Единственный найденный подход, который выглядит как полноценный свод процесса, ролей, ярусов автономии и приёмочных проверок, — свод Google SRE. Всё остальное либо уже его частный случай, либо продукт с описанным вокруг него порядком работы, либо бенчмарк.

Найденные подходы¶

1. SRE AI — свод Google SRE (ярусы автономии L0–L4 и «Safety Trifecta»)¶

Кто держит: Google SRE. Блог-анонс — Stevan Malesevic (Distinguished Software Engineer) и Christopher Heiser (Distinguished SRE); белая книга — Ioannis Papapanagiotou, Stevan Malesevic, Chris Heiser, Ruslan Meshenberg.
Источник:
https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations — 28.05.2026
https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ — страница-хаб белой книги «AI in SRE: How Google is Engineering the Future of Reliable Operations» / «AI in SRE Practice: Moving Beyond Automation at Google». Дата на странице не проставлена; привязка ко времени — через блог 28.05.2026.
Артефакты: runbook / playbook (агент их правит по факту использования в инциденте и генерирует новые из инцидентов); SLI/SLO; AI Insights — система, непрерывно перечитывающая закрытые инциденты и складывающая из них контекст для будущих расследований; handoff-документ при передаче дежурства; черновик постмортема; категории риска на инцидент. Именованные подсистемы: Detectr (сигналы из неструктурированной обратной связи), InvD (динамические панели расследования), AI Operator (первый ответчик с показанной цепочкой рассуждения), IRM-Analyzer / IRMA (разбирает разнородные источники и восстанавливает траекторию действий оператора), Actus (единый control plane и шлюз безопасности для всех автономных изменений в проде).
Роли (человек / агент): агенты разведены по функциям — обнаружение аномалий, обработка алертов, расследование, оркестрация инцидента, постмортем, коммуникация. Человек — oncaller и архитектор; прямая формулировка свода: человеческая экспертиза смещается в задание жёстких рамок системы, а не в ручное вмешательство («Attempting to artificially preserve unscalable manual intervention skills is counterproductive»).
Что отдано агенту: по уровням. L0 — всё делает человек. L1 — автоматизированы мониторинг и расследование, действие одобряет человек. L2 — агент может действовать, но человек явно одобряет план. L3 — мониторинг, расследование, одобрение и исполнение автоматизированы для конкретных, хорошо описанных сценариев. L4 — система сама выстраивает и исполняет последовательность действий. Наивысшая доля автономного закрытия — на частых и узких задачах: ротация сертификатов, переконфигурация балансировщика, чистка диска.
Ограничение права менять прод (самое ценное в подходе): «Safety Trifecta» — прозрачность, оценка риска в реальном времени, прогрессивная авторизация (права расширяются по доказанной надёжности). Плюс архитектурные ограничители: No Ambient Access & Least Privilege (агент не ходит под учёткой разработчика), Agentic Circuit Breakers (жёсткий лимит частоты действий), Mandatory Dry-Run Support (любая система обязана поддерживать dry_run=true), Zero-Trust, Safe-by-Default Actuation (только через защищённые control plane). Отдельно: агент обязан объяснить, почему и как он сделал действие и какие варианты отверг.
Как меряют качество агента: «Continuous Nightly Evals» — ночной прогон против реальных инцидентов, гибридная оценка с LLM-as-a-Judge; трёхуровневая иерархия данных Bronze (эвристика) / Silver (программная генерация) / Gold (проверено экспертом).
Зрелость: пилоты, переходящие во внутреннюю промышленную практику одной компании — подтверждено перечислением работающих внутренних систем с именами и описанным процессом их эксплуатации. Не «промышленная практика» по шкале рамки: независимых внедрений вне Google нет, публичных чисел (доля автономно закрытых инцидентов, MTTR) в тексте не приведено.
Модель-агностичность: переносим в несущей конструкции — ярусы L0–L4, трифекта безопасности, обязательный dry-run, прогрессивная авторизация, ночные эвалы на реальных инцидентах не зависят ни от модели, ни от платформы. Реализация несёт вендора: Gemini (дообученный на внутренних данных), Vertex AI, ADK, MCP-серверы, BigQuery, векторные базы.
Чем подтверждено: практика + вендорский источник (Google описывает себя и продаёт платформу под этим же).

2. Azure SRE Agent — «Incident Response Plan» как артефакт и два режима автономии¶

Кто держит: Microsoft.
Источник: https://learn.microsoft.com/en-us/azure/sre-agent/incident-response-plans — ms.date 08.06.2026, обновлено 12.06.2026, автор документа craigshoemaker. Общая доступность продукта — 10.03.2026.
Артефакты: incident response plan — именованная запись из двух частей: фильтр инцидентов (severity/priority, затронутый сервис, тип, вхождение строки в заголовок) и обработчик (какой кастомный агент + какой уровень автономии). План включается и выключается одним действием, конфигурация при этом сохраняется. Плюс: кастомные агенты (специализированные субагенты), таблица всех планов со статусами.
Роли (человек / агент): человек заранее пишет правила маршрутизации и решает, какой класс инцидента какому агенту и в каком режиме отдаётся. Агент маршрутизирует и расследует. Прямая формулировка: убрать из процесса «человека-роутера в 3 часа ночи».
Что отдано агенту: Review — агент диагностирует, а меняет ресурсы только после одобрения предложенных действий. Autonomous — агент сам смягчает инцидент и меняет ресурсы в пределах выданных прав. Документация прямо предупреждает: в автономном режиме инструменты, помеченные «Ask», исполняются без одобрения, обходя защиту; и отдельно требует подтвердить диалог «Autonomous mode acknowledgment» с границами ответственности. Рекомендация самого вендора — начинать с Review и переключаться после того, как поведение агента проверено.
Зрелость: промышленная практика внутри одной компании. Подтверждено: к GA Microsoft заявила 35 000+ смягчённых инцидентов и 20 000+ сэкономленных инженерных часов в месяц на собственных сервисах Azure (заявление аккаунта @AzureSREAgent при выходе GA, https://x.com/AzureSREAgent/status/2031424884551889160). Это самоотчёт вендора об одной компании, независимой проверки нет; для «промышленной практики» по шкале рамки не хватает нескольких независимых внедрений.
Модель-агностичность: привязан к Azure в несущей конструкции — план описывается в терминах ресурсов Azure и его control plane. Переносима одна идея: связка «фильтр инцидента → специализированный агент → заранее выбранный уровень автономии», причём уровень выбирается на класс инцидента, а не на агента целиком. Это самая полезная деталь во всём подходе.
Чем подтверждено: практика (документация продукта) + реклама (числа).

3. incident.io Investigations — мульти-агентное расследование как отдельный артефакт¶

Кто держит: incident.io.
Источник: https://incident.io/blog/introducing-ai-sre — 02.07.2025, автор в посте не назван (корпоративный блог).
Артефакты: investigation как самостоятельная сущность с жизненным циклом; внутри — findings (выводы), hypotheses (гипотезы), уточняющие вопросы от субагентов; на выходе — отчёт в Slack за 1–2 минуты, при возможности pull request с исправлением и черновик постмортема.
Роли (человек / агент): агент триажит каждый алерт, ведёт параллельные поиски по PR в GitHub, сообщениям в Slack, историческим инцидентам, логам, метрикам и трейсам, строит гипотезы. Человек — судья: читает готовое расследование и решает. Заявленный принцип — эскалация только там, где нужно человеческое суждение; каждый вывод трассируем до данных.
Что отдано агенту: триаж алертов и «инциденты, ради которых не должны будить»; сборка доказательной базы и ранжирование гипотез.
Зрелость: пилоты. Подтверждено: продукт живой и описан детально, но ни один клиент не назван, числа («до 80% сокращения простоя / MTTR») даны без методики и без независимого подтверждения.
Модель-агностичность: процесс (параллельные расследования, findings/hypotheses как артефакты, трассируемость вывода до источника) переносим; реализация привязана к платформе incident.io и к Slack как рабочей поверхности.
Чем подтверждено: реклама + описание практики; кейсов нет.

4. Datadog Bits Investigation — цикл гипотез и, главное, методика оценки агента¶

Кто держит: Datadog. Инженерный разбор — Daniel Shan и Tristan Ratchford.
Источник: https://www.datadoghq.com/blog/building-bits-ai-sre/ — 12.01.2026. Продуктовая документация: https://docs.datadoghq.com/bits_ai/bits_ai_sre/
Артефакты: цепочка гипотез с разбиением на подгипотезы; расследование, завершающееся за 3–4 минуты; семь действий триажа (уведомление в Slack, заведение инцидента, тикет в Jira и т.д.); PR в GitHub.
Роли (человек / агент): агент ведёт замкнутый цикл «наблюдение → рассуждение → действие»: строит гипотезу о причине, идёт запросом в телеметрию, подтверждает или отбрасывает, углубляется, пока не исчерпает пространство поиска. Человек одобряет действия, выходящие за заданные рамки.
Что отдано агенту: расследование целиком; исправление — только внутри заранее заданных guardrails, остальное выносится человеку с полным контекстом. Заявленный порядок расширения прав: начать с одобрения на каждое действие и расширять рамки по мере того, как одни и те же действия одобряются повторно.
Как меряют качество (самое переносимое здесь): собственный бенчмарк на реальных инцидентах компании: сотрудники размечают инцидент эталонной корневой причиной, агенту скармливается архивная телеметрия того момента, LLM-судья сравнивает вывод агента с эталоном. Прогоняется регулярно, чтобы видеть регресс версий.
Зрелость: пилоты — подтверждено детальным описанием внутренней инженерии и наличием эвал-контура; независимых внедрений с числами нет, «до 95% сокращения времени до разрешения» — вендорское заявление без методики.
Модель-агностичность: методика оценки (разметка исторических инцидентов + архивная телеметрия + LLM-судья + регулярный прогон) переносится полностью и на любой стек. Сам агент привязан к телеметрии Datadog.
Чем подтверждено: практика (инженерный разбор) + реклама (числа).

5. Rootly — модель зрелости AI SRE (L0–L3) и 90-дневный переход¶

Кто держит: Rootly. Автор — Purvai Nanda.
Источник: https://rootly.com/ai-sre-guide/maturity-model — обновлено 03.08.2026.
Артефакты: «context packet» — структурированная сводка с ранжированными гипотезами, где каждая гипотеза проверяема и снабжена ссылкой на доказательство; RBAC, привязанный к сервисам, окружениям и владению командой; условия остановки агента.
Роли (человек / агент) и что отдано агенту, по уровням: L0 — человек собирает контекст руками по вкладкам. L1 — агент только читает: собирает контекст и выдаёт ранжированные гипотезы со ссылками, ничего не исполняет. L2 — агент предлагает и исполняет действия через управляемый процесс с одобрением и RBAC. L3 — «guardrailed autonomy»: агент сам закрывает узкие классы инцидентов, при условии, что есть внятный сигнал успеха, явные условия остановки и только обратимые действия.
Переход: дни 0–30 — выйти на L1 (унифицировать идентификаторы сервисов, подключить события изменений); 31–60 — L2 (RBAC и одобрения); 61–90 — пилот L3 на одном режиме отказа. Продвижение меряют не размером модели, а четырьмя вещами: время до контекста, качество доказательств, контроль исполнения, накопление знания.
Зрелость: идея, оформленная как методика. Подтверждено: внятная процедура, но ни одного названного внедрения и ни одного числа со стороны клиентов.
Модель-агностичность: переносим — ни один уровень не опирается на функцию конкретной платформы. Источник вендорский, но конструкция чистая.
Чем подтверждено: мнение / методический материал вендора.

6. ilert — Agentic Incident Management Guide (L1–L3)¶

Кто держит: ilert.
Источник: https://www.ilert.com/agentic-incident-management-guide — дата публикации на странице не проставлена; содержание отвечает состоянию 2024–2025.
Артефакты: runbook, база знаний, постмортем, логи, метрики, конфиги, данные о деплоях.
Роли: on-call инженер, AI-агент с областью действия по командам и сервисам, incident commander, команды разработки.
Что отдано агенту: L1 «co-pilot» — рекомендации, контроль целиком у человека. L2 — агент исполняет отдельные действия под человеческим управлением или заранее заданными рамками. L3 «conditional full automation» — агент закрывает рутинные инциденты от начала до конца и эскалирует только по необходимости. Процесс: алерт → анализ → диагноз → рекомендация или исполнение → разрешение → коммуникация → постмортем.
Зрелость: идея. Ни одного внедрения, ни одного числа.
Модель-агностичность: переносим; вендорский источник, но конструкция не опирается на продукт.
Чем подтверждено: мнение.

7. Cloud Security Alliance — уровни автономии агента (L0–L5) как рамка управления¶

Кто держит: Cloud Security Alliance. Автор — Jim Reavis, сооснователь и CEO CSA.
Источник: https://cloudsecurityalliance.org/blog/2026/01/28/levels-of-autonomy — 28.01.2026.
Артефакты: сама шкала как инструмент разговора о правах агента.
Уровни (дословно): L0 «No Autonomy (Human Execution)» — система даёт информацию, действия выполняет человек. L1 «Assisted (Human Decision + AI Execution)» — каждое действие требует явного одобрения. L2 «Supervised (Human Approval + Batch Execution)» — человек одобряет план целиком. L3 «Conditional (AI Decision within Boundaries)» — агент действует сам в очерченных границах. L4 «High Autonomy (Minimal Supervision)» — человек следит за исключениями. L5 «Full Autonomy (Self-Directed)» — система ставит себе цели сама.
Роли: не расписаны по инцидентному процессу — это отраслевая рамка управления, а не операционная методика.
Зрелость: идея — консорциумный документ без описанных внедрений.
Модель-агностичность: полностью переносим, вендор-нейтральный источник. Пересечение зон: та же шкала одинаково ложится на зону 1 и зону 4.
Чем подтверждено: мнение отраслевого консорциума.

8. AIOpsLab и парадигма «AgentOps» — методология не эксплуатации, а оценки¶

Кто держит: Microsoft Research совместно с UC Berkeley, UIUC и IISc. Авторы: Yinfang Chen, Manish Shetty, Gagan Somashekar, Minghua Ma, Yogesh Simmhan, Jonathan Mace, Chetan Bansal, Rujia Wang, Saravan Rajmohan.
Источник: https://arxiv.org/abs/2501.06706 — 12.01.2025. Код: https://github.com/microsoft/AIOpsLab
Артефакты: воспроизводимая среда — развёртывание микросервисов в Kubernetes, инъекция отказов, генерация нагрузки, экспорт телеметрии; Agent-Cloud Interface (ACI) — стандартизованный интерфейс между агентом и средой. Отдельно заявлено использование как «спортзала» для обучения агентов.
Роли (человек / агент): человек задаёт сценарий отказа и критерий успеха, агент проходит полный цикл. Парадигма AgentOps: агент ведёт инцидент от обнаружения через локализацию и разбор причины до смягчения и закрытия.
Что отдано агенту: обнаружение, локализация неисправности, разбор корневой причины, смягчение — по задачам, разделённым в бенчмарке.
Зрелость: промышленная практика в своей нише — открытый код, многоинституциональное авторство, используется как стандарт сравнения. Как способ эксплуатировать прод — не применяется вовсе, это лабораторный стенд.
Модель-агностичность: переносим, открытый код, сравнивает произвольных LLM-агентов.
Чем подтверждено: практика (рецензируемое исследование + репозиторий).
Зачем в зоне: это единственный найденный способ проверить агента-дежурного до того, как пускать его в прод. Прямо закрывает вопрос «чем меряют».

9. ITBench (IBM) — бенчмарк на реальных задачах SRE / CISO / FinOps¶

Кто держит: IBM Research; ведущий автор Saurabh Jha, соавторов более сорока.
Источник: https://proceedings.mlr.press/v267/jha25a.html — ICML 2025. Код: https://github.com/itbench-hub/ITBench
Артефакты: 102 сценария на трёх доменах, расширяемых сообществом; два эталонных агента на CrewAI с открытым кодом; лидерборд; набор траекторий агентов на HuggingFace.
Что отдано агенту: сценарий целиком — например, «высокая доля ошибок на сервисе checkout» в Kubernetes.
Числа (важны для оценки всей зоны): агенты на лучших моделях решают 11,4% сценариев SRE, 25,2% CISO и 25,8% FinOps (без учёта обнаружения аномалий; для него F1 = 0,35).
Зрелость: промышленная практика в нише оценки — рецензированная площадка, открытый код, воспроизводимость.
Модель-агностичность: переносим, модели подключаются как watsonx, Azure или vLLM.
Чем подтверждено: практика (рецензированное исследование).

10. Русскоязычный контур: «Agentic SRE» на tproger¶

Кто держит: Евгений Стребков (tproger), пересказ и адаптация материала Neel Shah с DevOps.com.
Источник: https://tproger.ru/articles/agentic-sre-kak-ii-agenty-menyayut-praktiku-nadyozhnosti — 2026 (точный день на странице не проставлен).
Процесс: пять сценариев внедрения — триаж алертов, инцидент-копилот в канале реагирования, автоматический черновик разбора причин, безопасное исправление низкорисковых вещей, обучение на инцидентах.
Ярусы: read-only на старте → низкорисковые действия с аудитом → approval gate на всё, что задевает пользователя → человеческий override на каждом шаге.
Формулировка автора: «Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой».
Зрелость: идея. Российских внедрений и чисел в тексте нет; рекомендованный стек назван (OpenTelemetry, Prometheus/Grafana, локальные Llama/Mistral, YandexGPT или GigaChat), но как рекомендация, а не как отчёт о применении.
Модель-агностичность: переносим.
Чем подтверждено: мнение (переводной обзор).

Что искал и не нашёл¶

Не нашёл: независимой методологии дежурства с агентом, написанной не вендором. Искал: agentic SRE methodology on-call AI agent incident response process roles, AI SRE skeptical critique does not work practitioners limits evidence 2026, engineering blog "we let an agent" on-call production numbers percent incidents resolved autonomously 2026 case study, "AI SRE" runbooks as code machine readable playbooks agent methodology practice. Вернулось: два-три десятка страниц вида «Top 10 AI SRE Tools in 2026» и «AI SRE: The Complete Guide» от компаний, которых я до этого поиска не встречал (Augment Code, Sherlocks.ai, Anyshift, HealOps, Vibranium Labs, Arvo, Ciroos, Nova AI Ops, Gheware). Это SEO-слой вокруг категории, а не практика: во всех — одна и та же схема «AIOps коррелирует, AI SRE расследует», без своих данных.

Не нашёл: практики Google SRE / PagerDuty / Incident.io в независимой «агентной редакции». У Google есть свой свод, но это Google про Google. У PagerDuty — Operational Maturity Model, существовавшая до агентов; агентная часть выпущена как продуктовые анонсы (SRE Agent, Virtual Responder в раннем доступе Q2 2026, Fully Autonomous Responder — H2 2026), то есть на момент разведки половина заявленного ещё не выпущена. Отдельная страница PagerDuty — прямое сравнение с incident.io — это уже маркетинг, не метод. Никто не переписал классическую книгу Google SRE под агентов: обновления канона нет.

Не нашёл: чисел от независимых внедрений. Проверял: Catchpoint SRE Report 2026, Microsoft Ignite 2026 Azure SRE Agent 35000 incidents, кейсы Resolve.ai / Traversal / Cleric / Neubird. Все конкретные числа, которые нашлись, — либо самоотчёт вендора о самом себе (Microsoft: 35 000+ инцидентов, 20 000+ часов в месяц), либо маркетинговое «до N%» без методики (incident.io — до 80%, Datadog — до 95%, Traversal — 82% точных причин за 5 минут, 85% улучшение MTTR). Упоминания «Coinbase, Salesforce, Zscaler используют Resolve AI» встречаются только в пересказах на сторонних сайтах — до первоисточника с описанием процесса и цифрами я не дошёл.

Не нашёл: описания того, кто отвечает, если агент сам сломал прод. Искал вокруг границ права действия. Ближайшее найденное — диалог «Autonomous mode acknowledgment» в Azure SRE Agent, где Microsoft перекладывает ответственность за область прав и проверку результата на заказчика, и общий контур ответственности в рамке CSA. Отраслевой нормы нет.

Особая осторожность: число «13,8% сценариев SRE» встречается в вторичном пересказе ITBench; в первоисточнике (ICML 2025) стоит 11,4%. Беру первоисточник.

Общая оценка зоны¶

Зрелость зоны в целом: пилоты, с одним островом внутренней промышленной практики.

Три независимых свидетельства сходятся, и все три говорят одно:

ITBench, ICML 2025: лучшие модели закрывают 11,4% реальных SRE-сценариев. Это не «почти работает».
SRE Report 2026 (Catchpoint / LogicMonitor, 418 практиков, январь 2026): медианный toil — 34% рабочего времени; примерно половина респондентов говорит, что ИИ снизил рутину, вторая половина — что ничего не изменилось или стало хуже. Показательный разрыв по ролям: 60% директоров видят снижение против 38% исполнителей. При этом больше половины планируют выпускать агентные системы в прод.
Собственная осторожность вендоров: и Microsoft, и Datadog, и Rootly рекомендуют одно и то же — начинать с режима чтения и одобрения и расширять права только по накопленной статистике одобрений.

Что в зоне действительно устоялось и годится к переносу прямо сейчас:

Ярусы автономии как обязательный элемент разговора. Четыре независимых источника (Google L0–L4, CSA L0–L5, Rootly L0–L3, ilert L1–L3, Azure Review/Autonomous) пришли к одному: право агента описывается не одним флагом, а шкалой, и шкала привязывается к классу инцидента, а не к агенту целиком.
Право читать отделено от права действовать, а внутри права действовать отдельно стоит обратимость. У Rootly это условие входа в L3 прямым текстом: только обратимые действия.
Обязательный dry-run и запрет «фоновых» прав. Google формулирует жёстче всех: инструмент, которым пользуется агент, обязан быть неспособен уронить прод в одиночку, кем бы он ни вызывался.
Регресс-эвал агента на исторических инцидентах. Есть в двух независимых реализациях (Google — ночные прогоны с LLM-судьёй и разметкой Bronze/Silver/Gold; Datadog — размеченные реальные инциденты с архивной телеметрией) и в двух открытых бенчмарках (AIOpsLab, ITBench). Это, пожалуй, самое переносимое, что зона произвела.

Чего в зоне нет: независимого свода, не написанного продавцом; обновления канона Google SRE под агентов; ответственности за автономное действие; и хоть одного числа о доле автономно закрытых инцидентов, которое подтвердил бы кто-то кроме автора.