Всем привет, с вами снова Максим Михайлов. В третьей статье из моего цикла я рассказывал, почему агентные сценарии не стоит централизованно писать силами одних разработчиков. ИИ действительно приносит пользу инженерам и другим специалистам, когда у них есть безопасная среда, доступные инструменты и возможность самостоятельно решать рабочие задачи. Именно такой подход мы развиваем у нас.
А сегодня расскажу о том, как сделать работу с ИИ привычной практикой для всей команды.
Мы перебрали несколько вариантов, как запустить эту практику: обучение, документацию, отдельные консультации, постепенное подключение команд. В итоге выбрали самый прикладной формат — собрать коллег в одном месте, дать им готовые и проверенные инструменты, а затем предложить решить с их помощью понятные рабочие задачи.
Так появилась идея ИИ-хакатона на стратегической сессии команды заботы о клиентах.
С чего мы начали: 76 человек — инженеры L2, менеджеры бэк-офиса, специалисты из команд ИИ и МКИ (менеджеры клиентских инцидентов). Примерно треть участников — это менеджеры, причем многие из них до этого вообще не использовали ИИ в рабочих задачах.
Подготовка — ключ к успешному мероприятию
Хакатон на 76 человек нельзя проводить спустя рукава.
До мероприятия техническая команда подготовила инструменты, MCP-серверы, доступы к внутренним системам и нужные сетевые связности.
Также сформировали команду модераторов — по одному или два человека на каждую будущую команду. До старта они связались со своими участниками, помогли настроить рабочее окружение и убедились, что вся техника готова.
Во время хакатона модераторы оставались рядом, чтобы снять технические и методологические блокеры, но они не решали кейсы за участников. Команды сами разбирали проблему, проверяли гипотезы и искали решение, которое поможет не только текущему, но и будущим клиентам.
Уже в день хакатона всех участников разделили на восемь команд — не случайным образом.
Во-первых, костяк команды — инженеры из разных продуктовых направлений. Так мы собрали максимально широкий набор компетенций. В одной команде могли быть специалисты, которые редко пересекаются в обычных рабочих задачах, но вместе способны посмотреть на проблему с нескольких сторон. Заодно это хороший способ познакомить коллег между собой: совместный траблшутинг сближает лучше многих тимбилдингов.
Во-вторых, мы равномерно распределили между командами инженеров-экспертов, менеджеров процессов и менеджеров клиентских инцидентов. Это помогло сохранить баланс: инженеры глубоко погружались в техническую диагностику, а менеджеры удерживали фокус на клиентском пути, повторяемости сценария и на том, как превратить найденное решение в улучшение процесса.
Внутри каждой команды коллеги сами номинировали и выбирали капитана. Его роль — держать команду в фокусе: помочь распределить задачи, синхронизировать результаты, вовремя выбрать направление расследования и собрать все находки в понятную историю для финального демо.
Нейроволки: зачем хакатону своя вселенная
Рабочие задачи, таймер и презентация результатов задают структуру хакатона, но сами по себе не создают нужного вайба. А нам это было важно. Мы хотели добавить неформальные элементы, которые помогут участникам переключиться с привычного рабочего режима на соревновательный, быстрее включиться в командную работу и почувствовать азарт.
Поэтому для хакатона придумали тематику стилизации — нейроволки. Вся раздатка, слайды и задания были оформлены в едином волчьем стиле: команды становились стаями, расследование — охотой, а готовое решение — добычей, которую нужно принести вожаку.
Например, участники получали такие вводные:
🐾 СЛОВО ВОЖАКУ
«Стая, ваша задача — не просто найти ответ, а пройти путь так, чтобы следующая стая могла пойти по вашим следам. Выследите зверя. Загоните проблему. Принесите вожаку трофей — работающий прототип и CFR, которые спасут других охотников от 50 часов ожидания.
Ваша стая готова? Тогда на охоту!»Время на охоту: 50 минут.
Презентация добычи: 30 минут.
Голосование стаи: 10 минут.🎯 Удачи, волки!
Мы даже напечатали на 3D-принтере монеты-баллы с волчьей символикой. Они стали частью игровой механики и физическим напоминанием о том, что за решения и вклад в работу команды можно получить не только благодарность в общем чате, но и что-то физическое.
На каждом столе появились мемные таблички, а на слайдах — игровые элементы дизайна. Стилистика не снижала важность инженерной работы: логи всё так же нужно было собирать и анализировать, а первопричину проблемы — подтверждать проверкой гипотез. Но атмосфера помогла командам быстрее включиться, свободнее обсуждать идеи и не бояться предлагать нестандартные решения.
Конечно, у охоты должен быть финал. Поэтому мы заранее подготовили награды для чемпионов: кубки, грамоты и ценные призы.
А теперь подробнее к тому, как это было.
Часть первая: разогрев и поиски эчпочмака
Начали с разминки.
Каждый участник получил индивидуальное задание: с помощью ИИ-инструментов найти конкретный клиентский тикет, обнаружить в нем HAR-файл или лог, проанализировать его через тул и извлечь кодовое слово.
Затем капитаны собирали из найденных слов финальную фразу. Например, одна из команд получила такое сообщение: «Великолепный мастер поддержки уминает эчпочмак — преданная железка поднимает ноды».
Смысл упражнения был не в самой фразе, хотя эчпочмак, безусловно, помогал поддерживать боевой настрой. Участники прошли базовый рабочий сценарий: сформулировали запрос, нашли данные во внутренних системах, обработали их инструментом и проверили общий результат.
Все участники справились с заданиями разминки. Теперь можно было переходить к настоящим кейсам.
Часть вторая: эффективность на реальных задачах
Во второй части команды получили сложные задачи, похожие на реальные обращения клиентов.
Нужно было не только решить проблему с помощью доступных ИИ-инструментов или предложить недостающие. Команды также должны были подготовить CFR (Client Feature request) — предложение, которое позволит автоматически решать такие случаи в будущем или не допускать их вовсе.
Фокус был не на том, чтобы показать самое эффективное решение задачи. Фактически нужно было ответить на три вопроса:
Как быстро найти и подтвердить первопричину проблемы?
Как помочь конкретному клиенту прямо сейчас?
Что изменить в продукте, диагностике или процессе, чтобы похожая проблема не повторилась?
Пока команды работали, было особенно интересно наблюдать, насколько по-разному они подходят к расследованию. Кто-то формулировал и проверял гипотезы, кто-то писал код и собирал недостающие инструменты, кто-то искал закономерности в логах и связанных тикетах. А кто-то брал маркер, физическую доску и рисовал пайплайны, связи между системами и несколько вариантов решения.
Работа буквально кипела: техническая диагностика шла параллельно с обсуждением клиентского пути и будущих изменений в продукте. Но время на расследование закончилось — и команды перешли к финальной части хакатона: презентациям своих решений.
Часть третья: что получилось
В результате мы посмотрели восемь демо. Команды показали, как ИИ помогает собирать контекст из разрозненных источников, искать связанные обращения, анализировать логи, формировать и проверять гипотезы.
После выступлений участники голосовали за лучшие решения. И конечно, голосовать за собственную команду было нельзя.
В итоге победила команда, которая разбирала кейс, когда при загрузке образов в Docker Registry пользователь получал ошибку авторизации.
На старте у команды были только разрозненные вводные. Но с помощью ИИ-инструментов участники нашли исходное обращение, собрали технический контекст по клиенту, подняли связанные тикеты в ITSM-системе и сопоставили их с внутренней документацией. Работали не на слепых гипотезах, а на фактах.
Команда обнаружила причину: между платформой и Harbor возник сбой синхронизации. Из-за него у пользователя некорректно создавалась или обновлялась роль в Harbor, а Docker Registry отвечал ошибкой авторизации.
Для конкретного клиента подготовили рабочий обходной путь: выйти из workspace, подключиться к нему повторно и пересоздать Jupyter-серверы.
Но главная ценность этого решения была не в обходе. Команда предложила доработать процесс так, чтобы проблема либо больше вообще не возникала, либо диагностировалась автоматически.
Первое: когда пользователя добавляют в рабочее пространство платформы, сразу проверять, создана ли для него учетная запись с нужными правами в Harbor.
Второе: если Docker Registry возвращает ошибку авторизации, автоматически проверять, есть ли у пользователя такая учетная запись и корректно ли назначены права доступа.
По оценке команды, автоматическая проверка позволит получать первичную диагностику такого кейса примерно за 15 минут. Если встроить ее в продуктовый сценарий, часть подобных обращений вообще не дойдет до поддержки. В остальных случаях команда сможет тратить на каждое обращение в среднем на четыре-шесть часов меньше, чем сейчас.
Что показал хакатон
Во-первых, ИИ не отменяет инженерное мышление. Он помогает быстрее собрать данные из разных источников, увидеть возможные связи и наметить гипотезы, но решение по-прежнему требует экспертизы, проверки фактов и ответственности человека.
Во-вторых, самые полезные сценарии создают люди, которые каждый день сталкиваются с конкретными проблемами клиентов. Они знают систему, неочевидные зависимости и типовые симптомы лучше любой централизованной команды автоматизации.
В-третьих, вход в работу с ИИ оказался доступнее, чем может показаться. Около трети участников были менеджерами, многие впервые использовали ИИ в рабочих задачах. Они не просто посмотрели, как инженеры делают демо, а сами прошли путь от поиска информации в тикете до подготовки решения и предложений по улучшению процесса.
Хакатон подтвердил главную мысль: ИИ в инженерной поддержке — это уже повседневный помощник, который позволяет быстрее решать проблемы клиентов. И, что важнее, находить способы, чтобы эти проблемы не возникали снова.
Никакого Shadow AI
Отдельным вызовом для нас, организаторов, было не допустить Shadow AI — ситуации, когда сотрудники начинают решать рабочие задачи в непроверенных внешних ИИ-сервисах.
Это понятная человеческая реакция: появляется удобный инструмент, хочется быстро проверить гипотезу, разобрать лог или получить подсказку по задаче. Но для нас, как для крупного облачного провайдера, безопасность данных — ключевой принцип, через который мы оцениваем любые новые инструменты и рабочие сценарии. В запросах к ИИ могут оказаться клиентские данные, техническая информация и другие сведения, которые не должны покидать защищенный контур.
При этом желание быстро проверить гипотезу, разобрать лог или получить подсказку по задаче вполне естественно для инженера. Поэтому недостаточно просто запретить внешние сервисы — важно дать сотрудникам безопасную альтернативу, которая действительно помогает работать.
Для хакатона мы развернули локальную модель и необходимые инструменты внутри защищенного контура на Evolution AI Agents. Участники могли работать с внутренними системами, тикетами и техническими данными в контролируемой среде без передачи информации во внешние ИИ-сервисы.
Зачем вообще это все и при чем тут AI Native
Когда говорят «AI Native», часто представляют компанию, где каждому сотруднику выдали чат с LLM, а агенты вот-вот заменят всех людей. Но доступ к чат-боту сам по себе еще не означает, что ИИ внедрен в работу.
Настоящее внедрение начинается, когда ИИ берет на себя часть повседневной рутины: помогает собирать контекст, проверять гипотезы, запускать типовые проверки и предотвращать проблемы до того, как они превращаются в обращения клиентов. Речь не о замене человека, а о том, чтобы освободить его от повторяющихся задач и оставить за ним экспертность, принятие решений и ответственность.
Для нас AI Native — это подход, при котором сервисы и процессы проектируются с учетом возможностей ИИ. Мы начинаем задавать другие вопросы:
Где ИИ может быстро собрать контекст из разрешенных источников?
Какие гипотезы он способен проверить до подключения инженера?
Какие рутинные действия можно автоматизировать?
Как предотвратить проблему еще до того, как она превратится в клиентский тикет?
Похожий сдвиг зафиксирован и в ITIL (Version 5). Новая версия фреймворка переносит фокус с классического управления ИТ-услугами на управление цифровыми продуктами и сервисами и прямо позиционируется как AI Native.
В материалах ITIL по AI Governance предлагают сначала определить, какую роль ИИ играет в конкретном сценарии. Для этого используют модель 6C, которая включает: создание информации, ее отбор и подготовку, разъяснение, анализ и выводы, коммуникацию и координацию действий. Затем для сценария определяют уровень риска, допустимую автономность ИИ, контроль со стороны человека и способ проверить результат.
То есть ИИ может собрать данные из разрешенных источников, объяснить, что происходит, предложить следующий шаг или запустить проверку. Но за каждым действием должны оставаться понятные границы доступа, ответственность и возможность проверить решение.
Многие процессы в ИТ-поддержке строились в мире, где инженер вручную искал логи, историю обращений и нужный абзац в документации. Сами принципы — контроль, ответственность, управление рисками — никуда не исчезают. Но распределение работы между человеком, ИИ и автоматизацией меняется.
Хакатон стал способом проверить этот подход на практике и начать смотреть на ежедневные задачи и построение процессов под другим углом. Результат нас убедил: формат стоит повторять.
Поучаствовали бы в таком хакатоне?
