От «Авангарда» до стаи: как мы перестали писать ИИ-агентов за инженеров и научили их делать это самим

Команда поддержки облачного провайдера — это не кол-центр с операторами по скрипту. Это пара сотен сервисов: Kubernetes, GPU-инфраструктура для инференса моделей, PostgreSQL, Kafka и десятки других технологий. Когда у клиента деградирует производительность или отваливается API, инженер поддержки работает диагностом: смотрит логи, строит гипотезы, запускает утилиты.

Привет, я Максим Михайлов из Cloud.ru. Мы в команде ИИ-автоматизации решили помочь инженерам и построить внутреннюю платформу клиентской поддержки. Я рассказывал про это в предыдущей статье. Мы запустили автоматическую классификацию обращений, суммаризацию переписки и полноценных агентов, которые решали часть задач клиентов. Все работало и приносило пользу.

Но в какой-то момент прогресс остановился. Почти все низко висящие фрукты мы собрали, а каждый следующий сценарий требовал недель работы. Я думал, что проблема в моделях или промптах. Но причина оказалась глубже: мы пытались автоматизировать работу людей там, где менять нужно было сам подход к автоматизации.

Наш первый подход казался логичным. Команда ИИ-автоматизации приходила к продуктовым командам, наблюдала за работой инженеров и пыталась превратить их действия в сценарии для ботов.

Правда, довольно быстро этот конвейер сломался. Чтобы автоматизировать диагностику одного сервиса, специалисту из нашей команды приходилось погружаться в него на уровне профильного инженера: разбираться в архитектуре, изучать внутренние API, понимать связи между компонентами. На одно только погружение уходили недели. А сервисов у нас больше двухсот.

Бутылочное горлышко оказалось не в LLM. Главным ограничением стали знания сотен инженеров, которые невозможно быстро передать маленькой команде разработки. Мы поняли простую вещь: задача ИИ-команды не в том, чтобы написать тысячу агентов. Наша задача — создать условия, в которых эту тысячу агентов смогут написать сами инженеры, используя свою доменную экспертность.

Мы перестали задавать вопрос «Что вам автоматизировать?», вместо этого спросили команды «Что мешает вам автоматизировать это самостоятельно?». Ответы были предсказуемыми: нет удобного доступа к моделям, не хватает готовых инструментов, приходится собирать инфраструктуру вручную, негде обсудить идею.

Так появился проект «ИИ Авангард». Мы убрали технические барьеры:

Все это объединили в одном инструменте с понятными инструкциями. Теперь специалист мог сосредоточиться на задаче, а не на настройке доступов.

Почти сразу полетели сценарии, которые наша команда вряд ли бы придумала сама. Один инженер создал агента, который автоматически проходит диагностический runbook. Другой подключил внутренние API и научил модель разбирать алерты мониторинга. Третий избавился от ручного grep по логам.

Агентов создавали люди, которые каждый день работают с конкретным сервисом и знают его типичные проблемы. Им не нужно было две недели выяснять контекст — они точно знали, какую боль хотят убрать.

Но одних инструментов недостаточно. Любая внутренняя инициатива затухает без обратной связи. Поэтому параллельно мы собрали систему нематериальной мотивации: лидерборды, внутреннюю валюту («монеты») и ачивки за создание сценариев и помощь коллегам. Самые интересные решения показывали всей компании, создали общий чат и корпоративное пространство. Практики стали заметными, инженеры увидели, что можно переиспользовать у себя, и понимали, к кому прийти за советом.

Документацию никто не читает, лекции забываются через неделю, видеокурсы смотрят на скорости 2x. Назначить пару ИИ-чемпионов тоже плохой вариант — тогда именно они останутся единственной группой, которая занимается агентами. Нам же нужно было, чтобы уже через два дня десятки инженеров использовали собственных роботов в ежедневной работе.

Поэтому мы выбрали самый прикладной формат — собрать коллег в одном месте, дать им готовые инструменты и предложить решить понятные рабочие задачи. Так появилась идея ИИ-хакатона.

76 человек: инженеры L2, менеджеры бэк-офиса, специалисты МКИ (менеджеры клиентских инцидентов). Примерно треть участников — менеджеры, многие из них до этого вообще не использовали ИИ в рабочих задачах.

Хакатон на такую толпу нельзя проводить спустя рукава. До мероприятия техническая команда подготовила всю инфраструктуру, сетевые связности и доступы к внутренним системам. Сформировали команду модераторов — по одному-два человека на будущую группу. Они заранее связались с участниками, помогли настроить рабочее окружение и сняли базовые блокеры. Во время самого хакатона модераторы оставались рядом, но кейсы за участников не решали.

Всех разделили на восемь команд неслучайным образом. Костяк каждой группы составили инженеры из разных продуктовых направлений — так мы получили широкий набор компетенций и познакомили коллег, которые редко пересекаются. Равномерно распределили экспертов, менеджеров процессов и менеджеров клиентских инцидентов. Инженеры глубоко копали в техдиагностику, а менеджеры удерживали фокус на клиентском пути и повторяемости сценария.

Каждый участник получил индивидуальное задание: с помощью ИИ найти конкретный тикет, вытащить оттуда HAR-файл или лог, проанализировать тулом и извлечь кодовое слово. Капитаны собирали из слов финальную фразу вроде «Великолепный мастер поддержки уминает эчпочмак — преданная железка поднимает ноды». Смысл был не в самой фразе, а в базовом рабочем сценарии: сформулировать запрос, найти данные во внутренних системах, обработать инструментом и проверить результат. Справились все.

Команды получили задачи, похожие на настоящие обращения клиентов. Нужно было не только починить проблему здесь и сейчас, но и подготовить CFR (Client Feature Request) — предложение, которое позволит решать такие случаи автоматически в будущем. Фактически участникам нужно было ответить на три вопроса: как подтвердить первопричину, как помочь клиенту прямо сейчас и что изменить в продукте, чтобы ситуация не повторилась. Пока команды работали, технический траблшутинг шел параллельно с обсуждением клиентского пути и будущих изменений в продукте.

Мы посмотрели восемь демо. Голосование проводилось честно — за свою команду голосовать было нельзя. Победила команда, которая разобрала кейс со сбоем авторизации в Docker Registry при загрузке образов. У участников были только разрозненные вводные. С помощью ИИ-инструментов они нашли исходное обращение, подняли связанные тикеты в ITSM-системе и сопоставили их с документацией. Причина нашлась быстро: сбой синхронизации между платформой и Harbor, из-за которого некорректно обновлялась роль пользователя.

Для конкретного клиента ребята подготовили обходной путь (переподключить workspace), но главное — предложили изменения в процессе. Первое: проверять наличие учетной записи в Harbor сразу при добавлении пользователя в рабочее пространство. Второе: если Docker Registry возвращает ошибку, автоматически валидировать права. По оценке команды, такая проверка сократит первичную диагностику с часов до 15 минут, а часть подобных обращений вообще не дойдет до поддержки.

Отдельным вызовом в организации хакатона для нас была безопасность. Желание разобрать лог или проверить гипотезу в удобном внешнем сервисе вполне естественно для инженера. Но для облачного провайдера утечка данных недопустима. Просто запретить внешние сервисы бесполезно — важно дать альтернативу. Для хакатона мы развернули локальную модель из Evolution AI Agents внутри нашего контура. Участники могли работать с реальными тикетами и техническими данными, ничего не передавая вовне.

Когда говорят AI Native, часто представляют компанию, где каждому выдали чат с LLM, а агенты вот-вот заменят всех людей. Доступ к чат-боту сам по себе еще не означает внедрения. Настоящее внедрение начинается, когда ИИ берет на себя сбор контекста, проверку гипотез и типовые проверки, освобождая человека для принятия решений. Речь не о замене эксперта, а об освобождении его от рутины.

Этот сдвиг зафиксирован и в индустрии. Новая версия фреймворка ITIL v5 переносит фокус на управление цифровыми продуктами и прямо позиционируется как AI Native. В материалах по AI Governance предлагают использовать модель 6C (создание информации, отбор, разъяснение, анализ, коммуникация, координация) и определять уровень риска для каждого сценария. ИИ может собрать данные и предложить шаг, но границы доступа и ответственность остаются за человеком.

Многие процессы в ИТ-поддержке строились в мире, где инженер вручную искал логи и нужный абзац в документации. Сами принципы контроля никуда не исчезают, но распределение работы меняется. Хакатон стал способом проверить этот подход на практике. Результат убедил нас: такой формат стоит повторять. Он подтвердил главную мысль — самые полезные сценарии создают те, кто ежедневно сталкивается с проблемами клиентов. Остается лишь дать им правильные инструменты и безопасную среду.