Git in Sky выложила публичный нормативный кандидат Agent-Ops 0.4.0: открытую методологию совместной работы инженеров и ИИ-агентов в эксплуатации ИТ-инфраструктуры. К проекту присоединились maintainers из двух других компаний. Документ описывает процесс из восьми шагов, три плоскости контроля и принцип unknown ≠ OK, а также фиксирует требования к идентификаторам объектов, правилам работы с контекстом агента, лимитам на попытки исполнения и экономике применения ИИ.
Ключевая граница методологии умещается в одну фразу: рекомендация агента не даёт права на изменение инфраструктуры. Цель, ограничения и критерии успеха задаёт человек, он же утверждает конкретный план, а применяет его отдельный детерминированный исполнитель, который выполняет только допущенные действия. Всё, что выходит за рамки утверждённого плана, не исполняется.
Степень готовности авторы оговаривают прямо: 0.4.0 - кандидат методологии, часть нормативных схем и механизмов ещё предстоит построить, а ограниченное самовосстановление описано как будущая возможность.
Что такое Agent-Ops 0.4.0 и какую проблему он решает
Предмет методологии - эксплуатация ИТ-инфраструктуры с участием ИИ-агентов: диагностика инцидентов, разбор деградаций, изменения конфигураций, рутинные операции. Отдельные модели и агентные фреймворки такие задачи уже умеют. Проблема в другом: как только агенту дают доступ к продовым системам, цена ошибки растёт вместе с объёмом прав.
Классический ответ «поставим галочку подтверждения» разбивается о реальность: если одобрять каждое действие, инженер превращается в ручной шлюз и через неделю жмёт кнопку не читая план. Риск-ориентированная маршрутизация проверок и усталость от ревью разобраны отдельно в материале о проектировании системы подтверждений для AI-агента.
Agent-Ops отвечает на вопрос: как дать агенту диагностику и аналитику, но не отдавать ему право рулить продом. Ответ строится на трёх ролях и на явном разделении того, кто предлагает, кто решает и кто исполняет. Схема напоминает порядок в клинике: врач ставит диагноз и подписывает назначение, процедуру выполняют по протоколу, а подпись нельзя заменить устным «ну вроде надо».
Ключевая граница: почему рекомендация агента - не разрешение
Рекомендация агента не даёт права менять инфраструктуру. Это зафиксировано как последовательность из трёх независимых звеньев: гипотеза, утверждение, исполнение.
Пример. Агент видит рост времени ответа сервиса и предлагает перезапустить процесс. По логике Agent-Ops перезапуск не произойдёт, пока человек не утвердит план: на каком хосте, в каком временном окне, с какими критериями успеха и каким откатом. Утверждённый план получает детерминированный исполнитель. Он делает ровно один перезапуск, пишет результат в лог и не может выполнить команду, которой нет в плане.
Граница работает в обе стороны. Агент не получает полномочий по факту генерации текста, а человек не перекладывает ответственность на модель: подпись под планом остаётся человеческой.
Восемь шагов процесса: от намерения до извлечения уроков
Процесс разбит на восемь шагов, и каждый оставляет артефакт, на который опирается следующий:
- Намерение: что и зачем меняем.
- Доказательства: какие факты подтверждают проблему.
- Диагностика: в чём корневая причина.
- План: какие действия её устранят.
- Утверждение: человек согласует план.
- Контролируемое изменение: исполнитель применяет только допущенные действия.
- Проверка: достигнуты ли критерии успеха.
- Извлечение уроков: что записать в базу знаний.
Линейным этот список только выглядит. На любом шаге возможен возврат за дополнительными данными: если доказательств не хватает, диагностика не начинается.
Намерение и доказательства: постановка цели и сбор фактов
Намерение - это цель с ограничениями и критериями успеха. Формулировка «снизить latency API до 200 мс на 95-м перцентиле, не поднимая число инстансов больше шести» годится. Формулировка «сделать быстрее» не годится: по ней нельзя ни построить план, ни проверить результат.
Доказательства - проверенные факты, а не предположения. Сюда идут метрики текущего latency, частота ошибок, графики за конкретный интервал, релевантные строки логов, версии конфигураций. Без доказательств диагностика превращается в угадывание, поэтому сбор фактов стоит в процессе раньше выводов о причинах.
Диагностика и план: анализ и проектирование изменений
Диагностика отвечает на вопрос о корневой причине. План превращает ответ в конкретные шаги. Требование к плану простое: он должен быть детерминированным и проверяемым, то есть описывать команды, порядок и точки отката так, чтобы исполнитель не домысливал детали.
Пример. Метрики показывают рост потребления памяти процессом до упора и последующий OOM-kill. Диагностика указывает на утечку в конкретной версии сервиса, план состоит из шагов: зафиксировать текущую версию, выкатить сборку с исправлением на одном узле, выдержать окно наблюдения 30 минут, сравнить потребление памяти с базовым профилем, при отклонении откатиться на предыдущую сборку.
Утверждение и контролируемое изменение: человек решает, программа исполняет
Утверждение - явное согласие человека с планом. Не «понятно, делайте», а зафиксированное одобрение конкретного набора действий с окном, критериями и откатом.
Дальше в работу входит детерминированный исполнитель. Он применяет только допущенные действия и не может отклониться от утверждённого плана: нет шага в плане, нет команды в исполнении. Каждый шаг логируется, чтобы после изменения можно было восстановить, что именно произошло и на каком основании.
Проверка и извлечение уроков: обратная связь и улучшение
Проверка отвечает на вопрос, достигнуты ли критерии успеха из намерения. Извлечение уроков превращает результат в знание: что сработало, что дало побочный эффект, какие сигналы стоит отслеживать в следующий раз.
Пример. После обновления latency упала до целевых 200 мс, но выросла нагрузка на базу данных: изменился профиль запросов. Это не провал, а факт для базы знаний. В следующий раз в план добавят проверку нагрузки на БД, а в доказательства - дашборд по запросам к базе.
Три плоскости и роль Guardian: данные, управление, независимая проверка
Методология вводит три плоскости: данные, управление и политики, независимая проверка. Разделение нужно, чтобы один и тот же участник не собирал факты, не утверждал правила и не проверял сам себя.
Плоскость данных: что считается достоверной информацией
Сюда попадают метрики, логи, конфигурации, топология сервисов, история инцидентов. Требование к плоскости данных - проверяемость источника и актуальность среза. Данные без метки времени и источника считаются ненадёжными, а не «примерно верными».
С этой плоскостью напрямую связан принцип unknown ≠ OK: если факт не проверен, он остаётся неизвестным, а неизвестное нельзя молча трактовать как безопасное.
Плоскость управления и политик: правила игры
Плоскость управления задаёт рамки: кто имеет право утверждать изменения, какие действия допустимы на каком контуре, какие лимиты действуют. Часть политик автоматизируется. Пример: правило «изменения в production запрещены в пятницу после 18:00 и в дни релизов биллинга» проверяется машиной, и попытка утвердить такой план в запрещённом окне отклоняется.
По структуре это похоже на control plane в системах управления агентами, где глобальные гейты и локальные ограничения разделены по уровням. Подробнее такая архитектура разобрана в материале о двухэтажной архитектуре управления AI-агентами.
Независимая проверка и роль Guardian
Guardian - роль независимого проверяющего. Он следит за соблюдением политик и корректностью данных, но не участвует в операционных решениях: не выбирает, что менять, и не утверждает планы. Его задача - подтвердить соответствие правилам или остановить процесс.
Пример. План обновления сервиса нарушает политику изоляции: изменение затрагивает узел, зарезервированный под финансовую отчётность. Guardian блокирует исполнение до тех пор, пока план не переработают. Это не бюрократия ради процесса: независимая проверка ловит случаи, когда команда под давлением инцидента обходит собственные правила.
Принцип unknown ≠ OK: почему неизвестное - не значит безопасное
Принцип формулируется коротко: гипотеза остаётся гипотезой, а непроверенный факт - неизвестным. Из него следует запрет на удобную подмену: отсутствие сигнала об ошибке не равно отсутствию ошибки.
Пример. В логах сервиса нет записей об ошибках за сутки. Вывод «всё в порядке» здесь неверен: возможно, логгер настроен на другой уровень, сборщик логов отвалился или трафик вообще не доходит. Пока это не проверено, состояние системы неизвестно, и менять её на основе такого «спокойствия» нельзя.
Практическая польза принципа видна в диагностике. Инженер вынужден явно помечать пробелы: нет данных по памяти за ночь, неясно, применялась ли миграция, неизвестно, кто менял конфиг. Каждое такое «неизвестно» превращается в задачу на сбор данных, и только после её закрытия процесс идёт дальше. Это замедляет работу на старте и экономит часы разбора в постмортеме.
Что нового в версии 0.4.0: идентификаторы, контекст, лимиты и экономика
Четыре блока требований в 0.4.0 касаются механизмов, которые обычно остаются на усмотрение команды и потому разъезжаются между сервисами.
| Механизм | Что фиксирует версия 0.4.0 | Зачем это нужно |
|---|---|---|
| Идентификаторы объектов | Уникальные ID для сервисов, хостов, изменений и инцидентов | Связывает логи, метрики и действия агента в одну историю |
| Контекст агента | Правила отбора и ограничения объёма данных, которые получает модель | Снижает шум в решениях и стоимость запросов |
| Ограничения попыток исполнения | Максимум попыток на одно действие | Обрывает циклы и неконтролируемый расход ресурсов |
| Стоимость на один принятый успешный результат | Затраты на токены, время инженеров и инфраструктуру в расчёте на принятый результат | Позволяет сравнивать подходы и отсекать невыгодные |
Идентификаторы объектов и прослеживаемость
Каждый объект получает уникальный идентификатор: сервис, хост, изменение, инцидент. Это позволяет связать данные из разных источников и восстановить историю. Пример: ID инцидента соединяет графики метрик, строки логов, версию конфигурации и список действий, которые предлагал агент. Без общего идентификатора такая связка собирается вручную и восстанавливается по памяти участников.
Правила обращения с контекстом агента
Контекст агента ограничивают по объёму и релевантности. Избыточный контекст снижает качество решений и увеличивает стоимость обращения к модели: в шуме теряются значимые строки, а счёт за токены растёт.
Пример правила: агенту передают последние 100 строк логов по конкретному сервису и окно метрик за час, а не весь файл за месяц. Отбор идёт по идентификаторам объектов и временному окну инцидента.
Ограничения попыток исполнения
Для каждого действия задаётся предел попыток. Механизм закрывает классическую проблему агентных циклов, когда модель бесконечно повторяет одну и ту же операцию, надеясь на другой результат.
Пример: если изменение не применилось с трёх попыток, процесс останавливается, исполнитель фиксирует состояние и передаёт задачу человеку. Дальше либо пересматривают план, либо возвращаются к диагностике за новыми доказательствами.
Экономика ИИ: стоимость на один принятый успешный результат
Метрика считает полные затраты на один результат, который человек принял как успешный: токены, время инженеров на ревью, вычислительные ресурсы, простои. Сравнение по этой цифре честнее, чем по числу сгенерированных предложений.
Пример. Агент выдаёт десять рекомендаций, человек принимает одну. Стоимость на принятый успешный результат в десять раз выше, чем кажется по прайсу за токены, потому что девять отброшенных вариантов тоже кто-то читал. Такой расчёт быстро показывает, на каких задачах агент полезен, а где создаёт работу вместо того, чтобы её сокращать.
Степень готовности и ограничения методологии
Agent-Ops 0.4.0 - нормативный кандидат, а не финальная спецификация. Авторы прямо пишут, что часть нормативных схем и механизмов ещё предстоит построить, а ограниченное самовосстановление описано как будущая возможность, а не как текущая функция.
Практические следствия для тех, кто решит пробовать:
- Не все политики автоматизированы: часть проверок на раннем этапе придётся выполнять вручную, и Guardian в такой схеме опирается на людей.
- Схемы придётся адаптировать под свою инфраструктуру: инвентаризация объектов, идентификаторы и точки утверждения зависят от того, как устроены ваши сервисы и кто отвечает за контуры.
- Дисциплина стоит времени: сбор доказательств и фиксация неизвестных замедляют первые изменения. Выигрыш проявляется на разборах инцидентов и в повторяемых операциях.
Практическая применимость: кому и как использовать Agent-Ops
Методология рассчитана на команды, которые эксплуатируют инфраструктуру и уже пробуют агентов в диагностике: DevOps и SRE, дежурные смены, платформенные команды, коллективы с высокими требованиями к надёжности и аудиту.
Разумный порядок старта выглядит так:
- Инвентаризация: составить список объектов (сервисы, хосты, контуры) и выдать им идентификаторы.
- Роли: определить, кто утверждает планы, кто исполняет, кто выступает Guardian.
- Пилот на одном сервисе: выбрать задачу с низким риском, например разбор деградации на тестовом контуре.
- Исполнитель: настроить детерминированный механизм, который умеет только утверждённые действия и пишет логи.
- Метрика: фиксировать стоимость на один принятый успешный результат с первого дня.
Отдельных инструментов методология не требует: она ложится поверх существующего стека мониторинга и деплоя. Ограничение тоже честное: там, где нужна предельная скорость реакции, дополнительный шаг утверждения добавляет задержку. Как ранжировать проверки по риску и не превратить подтверждения в формальность, разобрано в материале о безопасном запуске AI-агентов без риска для продакшена.
Сопротивление инженеров при этом ожидаемо: часть специалистов воспринимает передачу операций агенту как потерю контроля над системой. Причины такого сопротивления и границы полезного делегирования разобраны в статье о том, почему часть разработчиков не хочет отдавать код ИИ-агентам.
Чем Agent-Ops отличается от других подходов к AIOps
Классический AIOps строится вокруг автоматизации: система собирает телеметрию, находит аномалии и может сама выполнить корректирующее действие. Логика понятная, но она оставляет мало следов о том, почему выбрано именно это действие и кто отвечает за результат.
Agent-Ops смещает акцент с максимальной автоматизации на контролируемость. Три отличия:
- Роли разделены: агент предлагает, человек утверждает, детерминированный исполнитель применяет.
- Неизвестное фиксируется явно: unknown ≠ OK не даёт закрыть вопрос молчанием.
- Экономика считается на принятый результат, а не на количество сгенерированных рекомендаций.
Цена такой схемы - скорость и накладные расходы на утверждение и проверку данных. Для платежей, регуляторной отчётности и критичных контуров это оправданно; для рутинной очистки временных файлов на тестовом стенде дополнительный шаг можно и не вводить. Выбор зависит от того, чем вы готовы заплатить за предсказуемость.
Начать стоит с малого: один сервис, один тип задач, явные идентификаторы и подпись человека под первым планом. Дальше границы расширяются по мере того, как накапливаются доказательства, что схема работает.