Автотрон берёт рутину на себя. Как мы с нуля создаём дежурного робота

В этой статье раскроем основные моменты, связанные с созданием дежурного робота-инженера: какие задачи ему можно поручать, какими метриками мы оцениваем его работу и какие AI-эксперименты проводим, чтобы роботы взяли на себя ещё больше тикетов.

Зачем нужен робот-дежурный?Зачем нужен робот-дежурный?

Робота мы решили создать, чтобы автоматизировать обработку рутинных тикетов. Это сокращает затраты времени и ресурсов, ведь таких однотипных задач очень много.

Сначала важно было определить, какие именно задачи можно доверить этому роботу. Мы сравнили, с какими вопросами лучше справляется человек, а с какими — робот.

Человек умеет:

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

Плюсы робота:

• не устаёт;
• хорошо работает с рутинными и односложными операциями, где нужно действовать по определённому алгоритму;
• прозрачен с точки зрения затрат;
• может параллельно работать с несколькими тикетами без потери фокуса. Человек может терять эффективность, когда параллельно занимается несколькими задачами. Робот создаёт свои отдельные инстансы, каждый инстанс работает с конкретной задачей.

Метрики оценки нагрузки роботаМетрики оценки нагрузки робота

Также необходимо было понять, как оценивать эффективность робота.

Универсальной метрики нет — нужно анализировать всё комплексно. Для этого мы выделили три метрики: количество тикетов, чистое время решения тикета и переключение контекста.

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

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

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

Как устроен робот АвтотронКак устроен робот Автотрон

Вся разработка в Яндексе происходит полугодовыми сезонами, затем подводятся итоги, и работа продолжается с новыми вводными. Этот механизм позволяет точнее формулировать задачи и распределять ресурсы. Такой подход со стандартным кодом даёт гибкость, но доставка изменений идёт медленнее, а сил на обёртки (c ретраями и отказоустойчивостью) можно потратить много. Кроме того, нужны разработчики на фултайм.

Можно напрограммировать всё, что угодно, но хватит ли на это времени и ресурсов? Как за счёт оставшихся 20% ресурса достигнуть 80% успеха?

Мы решили пойти нестандартным путём — через лоу-код: программируем с помощью визуальных инструментов, а заказчик может на лету создавать бизнес-логику. От разработки нужна только базовая часть, высокоуровневые кубики с понятными входами и выходами, а пользователь уже сам может набросать то, что ему нужно. В этом случае мы не тратим время на коммуникации и экономим ресурсы. Конечно, что-то затейливое таким путём реализовать сложно, но для простых операций — самое то.

Так у нас появился новый виртуальный сотрудник Автотрон, который стал помогать с рутинными процессами.

Как работает Автотрон?Как работает Автотрон?

В наших процессах есть три основных кубика:

• Трекер — система с тикетами
• Реактор — кран и очередь обработки хуков
• Нирвана— исполнение графов

Как это работает? Яндекс Трекер — это система с тикетами. Когда открывается тикет, Трекер передаёт информацию в очередь, которая может накапливать задачи и выполнять определённые действия. Реактор выступает в роли крана и очереди обработки хуков, он запускает лоу-код-графы с нашего робота. Стандартный механизм — линейный: от Трекера в Реактор. При этом Реактор сразу запускает наш граф в Нирване.

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

Основные блоки роботаОсновные блоки робота

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

• реакция ничего не делала (тикет ей вообще не подходит);
• всё хорошо;
• реакция упала (нестандартное поведение, падать она не должна).

Каждый этап этого графа состоит из ряда компонентов.

Сначала мы парсим тикет: важно преобразовать строку с ключом тикета в типизированный набор параметров. На скрине они обозначены разноцветными кружками, цвет символизирует тип. Синий — это текст, красный — например, JSON.

Каждое извлечение — это поход в Трекер и обработка отдельного поля тикета.

Не всегда каждое поле можно обработать тривиально, путем regexp или запроса поля. Нужно навернуть полноценную логику. В этом нам помогает Starlark — прекрасный диалект Python. Его можно встроить в любую Go-систему и использовать с привычным синтаксисом. В базовой версии его вполне хватает, поэтому инженеру не приходится переключать контекст.

После получения параметров запускаем реакции.

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

Затем реакция уведомляет об успехах, чтобы дежурный инженер мог понять, нужно ли ему погружаться в процесс, среагировал ли робот или эта схема ещё не покрыта.

Этот подход дал свои плоды. За полтора месяца были написаны базовый скелет и одна реакция. Через два года у нас было уже 14 реакций: разработка к этому рук не приложила — всё полностью было сделано дежурной сменой.

Как выглядит работа АвтотронаКак выглядит работа Автотрона

В наших внутренних системах работа дежурного робота может отображаться по-разному: всё зависит от задачи, которую он решает.

Можно выделить три основных типа тикетов, с которыми работает Автотрон.

• Робот консультирует. Например, человек заказал доступ через файрвол, указал в тикете параметры, но доступ не работает. Робот проходит по нескольким системам и всё проверяет.

  В примере на слайде робот говорит, что само правило, которое указывает человек, валидно. Но при этом указанные IP-адреса не мэтчатся с этим правилом. Либо человек в своём тикете что-то не так указал, либо указал не тот порт, промахнулся с группой доступа. Робот просто подсказывает, а затем дежурный инженер делает работу.

• Робот выполняет тикет от и до: получает тикет, решает его и закрывает. Это работает для простых сценариев.

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

• Многоэтапный тикет. Это тикеты, которые обычно не требуют технических знаний, а создаются для административной работы.

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

  В подобных тикетах дежурному инженеру не надо ничего делать, кроме переписки, работы с тикетом и запуска пинга.

  Вот как может выглядеть первичная проверка:

Затем идёт решение в связанном тикете:

В финале — контрольная проверка робота:

Если робот ошибаетсяЕсли робот ошибается

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

Также есть анализ постфактум: когда робот ошибается, создаётся тикет в отдельной очереди и мы анализируем, почему так произошло. Если речь о логической ошибке (робот что-то сломал, но написал, что всё прошло успешно), то разработчики анализируют произошедшее, чтобы внести корректировки и предотвратить ошибки в будущем.

Но даже если робот что-то снесёт, у нас всегда есть бэкап (если из-за ошибки пострадал только кусочек, мы сможем быстро всё перехватить и исправить).

Результаты: работа Автотрона в цифрахРезультаты: работа Автотрона в цифрах

Насколько эта история успешна? Вспомним метрики оценки эффективности робота: число тикетов, чистое время на решение тикета и переключение контекста.

Рассмотрим средние цифры по результатам в трёх ракурсах.

• Дополнительные ресурсы

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

Получаем усреднённые значения за полгода: робот решает чуть меньше тикетов, чем трое дежурных. По чистому времени и по переключению контекста это очевидно меньше, потому что дежурный занимается более сложными задачами. Около «двух дежурных» достигается за счёт того, что инженер работает посменно, а робот — 24/7.

Дополнительные ресурсы (AVG, %):

• Усиление смены

  Если взять всё время дежурных и посчитать, сколько в среднем приходится на смену, то получим два человека на смене. Понятно, что есть часы наибольшей нагрузки, а есть праздники, выходные, когда нагрузки меньше.

За счёт того, что у нас работает третий дежурный (только робот), мы получаем, что в смене он добавляет 70% по количеству тикетов, около 50% по чистому времени и по переключению контекста.

Усиление смены (AVG, %):

• Снижение нагрузки на дежурного

  В этом ракурсе смотрим, как робот снижает нагрузку на дежурного инженера. Если бы эти тикеты не выполнил робот, их пришлось бы делать человеку.

Каждому дежурному пришлось бы решать на 25% больше тикетов. По чистому времени и по переключению контекста — это около 20% на человека.

Уменьшенная нагрузки на дежурного (AVG, %):

Что дальше: внедряем AIЧто дальше: внедряем AI

Результаты довольно успешные: мы автоматизировали множество рутинных операций. Теперь экспериментируем с использованием AI для автоматизации трёх направлений:

• Анализ и рекомендация по предыдущим тикетам

  Все тикеты, которые проходят через дежурную смену, анализируются, структурируются, идут в базу. Когда появляется новый тикет, с ним происходит та же операция (некоторая векторизация с последующим поиском).

  Например, у нас есть тикет на вход: мы смотрим похожие тикеты и выгружаем их в LLM-ку. Дальше уже языковая модель должна нам по промпту дать рекомендацию из серии «Я видела в базе максимально похожий тикет, рекомендую выполнить в этой операции такие-то действия».

  На слайде — пример подобной операции.

• Подключение AI для консультаций

  Здесь мы работаем с тикетами, в которых человек задаёт вопрос: ему нужно просто что-то подсказать. Такие тикеты также проходят через Автотрон, формируется отчёт. Эта штука уже использует RAG: берём AI, в робота добавляем инструкции, по которым он проводит анализ. Робот смотрит инструкции, читает тикет и делает выводы.

• Подключение AI для обработки почты

  Мы экспериментируем с AI в обработке нашей почты, используя дополнительные инструменты, чтобы нейронка могла куда-то сходить, что-то там посмотреть и обогатить контекст.

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

  Какие инструменты мы даём в помощь AI? Подгружаем инструмент обращения в Трекер, чтобы AI мог смотреть историю, искать письма по ключевым словам. Соответственно, AI анализирует всё и пишет нам: я классифицировал причины, нашёл такую-то историю, событие такое-то, требуется изменить дату переноса работ.

  Вот как может выглядеть подобный процесс:

ПрототипПрототип

Робот сделан на наших внутренних инструментах, но, возможно, кому-то будет интересно его попробовать для решения своих задач. Делимся прототипом на n8n.