Agent-Ops 0.4.0: ИИ предлагает, человек решает, программа исполняет
Меня зовут Сергей Житинский, я основатель Git in Sky. Наша команда занимается эксплуатацией и технической поддержкой ИТ-инфраструктуры. Весной мы начали развивать Agent-Ops - открытую методологию совместной работы инженеров и ИИ-агентов. Сейчас опубликован первый кандидат версии 0.4.0, а к проекту присоединились специалисты ещё из двух компаний, ставшие его maintainers.
Agent-Ops задуман не как набор инструментов конкретного вендора, а как общая модель организации работы. Она должна помочь ответить на практические вопросы: кто исследует проблему, на каких данных строится рекомендация, кто имеет право разрешить изменение, каким образом выполняется утверждённый план и кто отвечает за последствия.
Зачем нужна отдельная методология
ИИ всё чаще используют в эксплуатации: ему поручают анализировать журналы событий, сопоставлять конфигурации, искать причины деградации сервисов и готовить варианты исправлений. Сильная сторона моделей - скорость обработки больших объёмов разнородной информации. Агент способен за короткое время просмотреть данные мониторинга, документацию и результаты предыдущих проверок.
Однако убедительное объяснение ещё не доказывает, что рекомендацию безопасно применять. Агент мог работать с устаревшими сведениями, перепутать тестовую и рабочую среду, не учесть скрытую зависимость или принять правдоподобную гипотезу за установленный факт. Дополнительная угроза возникает, если вредоносная инструкция попадает в данные, которые анализирует модель.
Поэтому основной принцип Agent-Ops можно сформулировать так: ИИ предлагает, человек принимает решение, программа исполняет. Ответственность за изменение инфраструктуры нельзя передать модели формулировкой "так посоветовал искусственный интеллект". Её несут владелец сервиса, менеджер и инженер - каждый в пределах своих полномочий.
Человек при этом не должен формально нажимать кнопку подтверждения. Согласование должно относиться к конкретной цели, версии плана, набору объектов и периоду действия. Если изменились параметры сценария, используемый пакет или область воздействия, старое разрешение больше не считается действительным.
Почему нужны обычные программы
При наличии агента, который умеет писать скрипты и объяснять результаты, возникает соблазн поручить ему весь процесс. Но многие операции надёжнее выполнять детерминированными программами. К ним относятся сбор фактов, проверка форматов, сравнение значений с порогами, контроль полномочий и запуск заранее утверждённого сценария.
Для таких задач особенно важен принцип чистой функции: одинаковые входные данные должны приводить к одинаковому результату. Это упрощает тестирование, аудит и повторное выполнение операции. Модель может предложить способ проверки, но окончательная проверка должна быть воспроизводимой и независимой от случайностей генерации.
Восемь этапов от задачи до результата
В Agent-Ops процесс можно представить как последовательность из восьми шагов:
1. Формулировка цели. Указывается, какую проблему требуется решить и какой результат считается успешным.
2. Определение ограничений. Фиксируются допустимый простой, затрагиваемые среды, сроки, лимиты и запрещённые действия.
3. Сбор исходных данных. Система получает логи, метрики, версии конфигураций и другую необходимую информацию.
4. Анализ и подготовка гипотез. Агент сопоставляет сведения и предлагает возможные причины или варианты действий.
5. Проверка гипотез. Утверждения модели проверяются детерминированными процедурами, дополнительными измерениями или инженером.
6. Подготовка плана. Формируется конкретный сценарий с указанием команд, объектов, порядка операций и ожидаемого эффекта.
7. Согласование. Уполномоченный человек подтверждает именно этот план, а не абстрактную просьбу "починить сервис".
8. Исполнение и контроль результата. Программа запускает утверждённые действия, после чего проверяет фактический эффект и фиксирует итог.
Такая схема разделяет рассуждение, разрешение и исполнение. Это снижает риск того, что ошибочная рекомендация сразу превратится в изменение рабочей системы.
Неизвестное нельзя выдавать за норму
Отдельное правило методологии связано с неопределённостью. Если система не располагает достаточными данными, это должно быть явно обозначено. Нельзя автоматически считать нормальным значение, которое просто не удалось получить.
Например, отсутствие метрики не равнозначно нулевой нагрузке, а неподтверждённая версия конфигурации не должна трактоваться как актуальная. Агент обязан отделять наблюдаемый факт от предположения и указывать, какие сведения необходимы для продолжения работы.
Процесс должен отдельно отвечать как минимум на три вопроса:
- что действительно известно;
- какие выводы являются гипотезами;
- какие действия разрешены и кем именно.
Это позволяет не смешивать технический анализ с управленческим решением.
Пример: на диске осталось 8%
Рассмотрим типовую ситуацию. Мониторинг сообщает, что на диске осталось 8% свободного пространства. Агент может быстро изучить логи, определить крупные каталоги, сопоставить рост файлов с расписанием резервного копирования и предложить несколько вариантов: удалить временные данные, расширить том или перенести архивы.
Но ни один из вариантов не должен выполняться автоматически только потому, что модель сформулировала его убедительно. Сначала программа подтверждает актуальное состояние диска, проверяет сервер и среду, определяет владельца данных и оценивает возможные последствия удаления. Затем инженер выбирает допустимый сценарий, а уполномоченный сотрудник согласует его.
После выполнения необходимо проверить не только увеличение свободного места, но и отсутствие побочных эффектов: не сломались ли резервные копии, сохранилась ли работоспособность приложения, не появились ли ошибки записи. Полезность операции определяется проверенным результатом, а не количеством действий агента.
Что включает версия 0.4.0
Редакция 0.4.0 имеет статус публичного нормативного кандидата. Это проект правил, предназначенный для обсуждения, проверки на реальных сценариях и дальнейшего развития.
В текущей версии акцент сделан на разграничении ролей, обязательности человеческого решения, фиксации контекста согласования, воспроизводимости процедур и контроле результата. Важное место занимает идея минимально необходимого доступа: агент и исполняющий компонент должны иметь только те полномочия, которые нужны для конкретной операции.
Также принципиально отделяются исследовательские действия от изменяющих. Сбор информации и построение гипотез могут выполняться в безопасном режиме, тогда как любые операции, способные повлиять на доступность, данные или конфигурацию, требуют отдельного разрешения.
Как оценивать пользу ИИ
Скорость ответа сама по себе не является показателем эффективности. Если инженер после генерации час проверяет, откуда взялись выводы, исправляет ошибки в командах и восстанавливает контекст, реальная экономия может оказаться нулевой.
Оценивать внедрение Agent-Ops следует по другим критериям: сократилось ли время до подтверждённой причины, уменьшилось ли число необоснованных изменений, стало ли проще восстановить ход расследования, снизилось ли количество повторных ошибок. Важно учитывать и стоимость контроля: автоматизация полезна тогда, когда проверка результата дешевле ручного выполнения всей работы.
Не менее важна возможность остановить процесс. Если агент начинает повторять неудачные попытки, менять цель или генерировать новые отчёты без продвижения к результату, система должна завершать сценарий и передавать его инженеру.
Безопасность и аудит
Каждое значимое действие должно оставлять понятный след: кто поставил задачу, какие данные использовались, какую рекомендацию сформировал агент, кто её проверил, какое разрешение выдано и чем завершилось исполнение.
Такой журнал нужен не только для расследования инцидентов. Он помогает находить слабые места процесса, сравнивать варианты автоматизации и обучать сотрудников. При этом в журнале следует учитывать защиту чувствительных данных: секреты, токены и персональная информация не должны попадать в контекст модели без необходимости.
Agent-Ops 0.4.0 предлагает не отказываться от ИИ, а правильно определить его место в эксплуатационном контуре. Агент полезен как быстрый аналитик и помощник по подготовке решений. Человек остаётся ответственным за выбор, а обычная программа обеспечивает предсказуемое исполнение и проверку результата. Именно такое разделение позволяет использовать возможности моделей, не превращая инфраструктуру в пространство неконтролируемых экспериментов.