Поддержка на автопилоте: как я раздал свою рутину ботам

Всем привет! Меня зовут Магомед, я инженер поддержки в команде контента в Банки.ру. За 4 месяца я собрал на n8n несколько автоматизаций. Часть из них дежурит вместе со мной: утренний дайджест по состоянию сервисов, сторож аномалий после релизов и ИИ-агент, который знает наши сервисы, работает с Jira и умеет оценивать задачи. Другая часть работает на авторов контента: уведомляет о комментариях и просмотрах и проверяет, подходят ли к материалу прикреплённые виджеты.

В этой статье я не буду уходить в детали устройства воркфлоу: схем из n8n, промптов и разбора нод здесь не будет. Хочу показать, как конкретно я, инженер поддержки, применяю ИИ в ежедневной работе. Если захочется подробностей по какому-то из ботов, спрашивайте в комментариях, расскажу.

Из чего состоит день поддержки

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

Утро — самый долгий обход: открыть Kibana, Grafana и Jira, потом глазами пройти по 500-м, доступности, latency и логам, прикинуть, что из этого фон, а что новое. Стабильно 30–40 минут, и это до того, как возьмёшься за что-то осмысленное. После релиза уходит ещё 15–20 минут на каждую выкатку: вручную выставить одно и то же временное окно сразу в Kibana и Grafana, найти автора деплоя, сверить метрики до и после. Сейчас же это занимает максимум 5 минут.

Вопросы в течение дня: коллега спрашивает про метрику или лог, и ты каждый раз идёшь собирать ответ руками. Это 10–15 минут на вопрос, и так несколько раз в день.

Задачи, их же ещё нужно не забыть завести. Разобрался с проблемой, надо оформить тикет, а тут прилетает алерт или кто-то пишет в личку с вопросом, и задача так и остаётся ненаписанной, всплывая потом неприятным «а почему это нигде не зафиксировано?».

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

На чём это собрано

Все автоматизации сделаны как воркфлоу на n8n. За анализ и тексты отвечает Claude, модели Sonnet 4.5 и Haiku 4.5, запросы к ним идут через наш внутренний прокси на LiteLLM. Sonnet 4.5 отвечает за «умное»: рассуждения агента, груминг, разбор инцидентов и саммари для дайджеста. Haiku 4.5 — за лёгкое и частое: тексты напоминалок и короткие проверки вроде соответствия виджета теме.

Источники данных: репозитории сервисов, база знаний команды, Kibana, Grafana, Jira, Zabbix, база комментариев и статистика просмотров. Сообщения уходят в Loop.

Утро: дайджест вместо ручного обхода

День начинается с воркфлоу, который собирает утренний дайджест. Он проходит по 500-м ошибкам, доступности, latency, логам, задачам в Jira и паттернам ошибок, а по сообщениям из error и critical логов делает короткое саммари.

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

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

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

Релиз: Release Anomaly Watcher

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

Главное удобство в том, что не нужно вручную выставлять временное окно в двух системах: открываешь ссылку и сразу смотришь на нужный момент.

Сразу оговорюсь: сам детект аномалий Watcher почти не ускоряет: у нас и без него грамотно выстроены алерты, которые срабатывают как надо. Его задача другая: повысить качество внимания и ускорить разбор. Обычный алерт говорит «что-то не так», и дальше ты сам идёшь собирать контекст; Watcher приходит уже с ним: кто катил, что именно поехало и готовые ссылки на нужный момент. Минуты экономятся не на обнаружении, а на разборе.

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

День: ИИ-агент команды

Агент сделан под команду контента и состоит из двух воркфлоу, которые я называю ушами и мозгом.

Уши

Уши раз в 10 секунд проверяют, не обратились ли к агенту. Он живёт в нескольких рабочих каналах, где откликается на тег, и в личке, где тег не нужен и каждое сообщение адресовано ему. Если в сообщении вопрос для ИИ, уши передают его мозгу.

Мозг: что он знает

Мозг читает код сервисов и базу знаний команды, то есть наши скиллы и регламенты. Он знает карту примерно из 41 сервиса и 12 доменов, поэтому по имени сервиса сам понимает, куда идти за метриками и логами.

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

Работа с Jira

С Jira агент работает почти как человек в команде: читает тикеты, оставляет комментарии, правит поля, связывает задачи, находит исполнителя и спринт, а при необходимости создаёт новую задачу.

Главная ценность — скорость и снижение рутины. Вместо 20–30 минут на ручное оформление задачи агент может собрать контекст и создать полноценный тикет за несколько минут. Это экономит время и снижает риск, что важная задача потеряется после созвона, обсуждения или сообщения в чате.

Важно и качество заполнения. Агент добавляет контекст, описание проблемы, ожидаемый результат, ссылки, логи и связанные задачи. Это особенно полезно, потому что разработчики сами активно используют AI-инструменты: чем лучше оформлен тикет, тем быстрее можно начать разработку или дебаг и тем меньше времени уходит на уточнения.

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

Груминг

Отдельная способность агента: оценка задач. По описанию тикета он раскладывает работу на подзадачи, сверяется с кодом и зависимостями и выдаёт оценку в часах сразу в трёх вариантах: оптимистичном, реалистичном и пессимистичном. Оценивает он только разработку: ревью, тестирование и встречи в его часы не входят.

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

Как он общается

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

Каждое сообщение он сразу помечает реакцией: 👀, когда увидел, и 🚫, если ответить не смог. Так всегда видно, что бот жив и взялся за дело.

Характер и знания заданы отдельным блоком в системном промпте: кто он, что он инженер команды контента, к кому и как обращается и в каком тоне отвечает. Отвечает он, кстати, в подчёркнуто вежливой, почти аристократической манере — со всеми на «вы» и с лёгким старомодным изяществом. Это отдельная маленькая радость команды.

Спрашивают его о самом разном и вполне рабочем: какой сейчас трафик на таком-то сервисе, почему он отдаёт 5xx и что в логах, что это вообще за сервис и где его метрики, оцени вот эту задачу, заведи тикет на такую-то доработку. По сути это те же вопросы, с которыми раньше шли ко мне, — просто теперь часть из них он закрывает сам.

Спотыкается он чаще всего там, где нужны данные из систем, к которым у него нет доступа, или когда упирается в лимит модели — тогда и появляется 🚫: «увидел, но ответить не смог».

Для авторов: сервис уведомлений

Часть автоматизаций работает не на поддержку, а на авторов контента. По сути это небольшой внутренний low-code сервис уведомлений на n8n.

Новые комментарии

Раз в пять минут бот проверяет базу на новые комментарии и присылает автору материала сообщение в Loop.

В сообщении сразу есть всё, что нужно для ответа: тип комментария (например, «кейс»), ссылка на статью, ник читателя, время и сам текст. Ниже ИИ предлагает черновик ответа. Автору не нужно заходить на сайт и искать комментарий, и писать ответ с нуля тоже не приходится: достаточно проверить черновик, поправить под себя и опубликовать.

Просмотры и проверка виджетов

Второй бот следит за статистикой и пишет автору, когда его новость набирает 1000 просмотров. В этот момент он заодно проверяет виджет. К материалам у нас прикрепляются блоки с подбором продуктов, например вкладов, кредитов или ОСАГО. Бот отправляет в Claude тему статьи и суть закреплённого виджета и смотрит, насколько они сочетаются. Если всё в порядке, он так и пишет. Если виджет, похоже, можно подобрать удачнее, предлагает автору взглянуть на него ещё раз.

Сам бот ничего не решает и не предлагает убрать или заменить виджет, последнее слово всегда за автором. Увидев подсказку, автор либо подбирает виджет точнее, либо оставляет как есть: иногда общий по теме виджет вполне уместен.

Фоном: напоминалки

Остальное это небольшие напоминалки по процессам команды: о задачах, которые засиделись на ревью, о тикетах без метки ac_ok для тестировщиков, о тикетах без Account, то есть без привязки к разделу, для тимлида, и о логе времени для всей команды. Тексты для них сочиняет Claude, и чем дольше висит задача, тем настойчивее намёки.

Что получилось

• Утренний разбор состояния сервисов: раньше ручной обход на 30–40 минут, теперь около 5 минут на чтение готового дайджеста.

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

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

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

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

Что пока не работает

• Полный дайджест пока живёт в HTML-файле, который нужно скачивать: отдельного удобного места, куда можно просто зайти по ссылке, у него ещё нет.

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

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

• Проверка виджета — это оценка «по смыслу», а не строгое правило: бот иногда придирается к вполне уместному общетематическому закрепу. Поэтому он ничего не решает сам, а лишь мягко подсказывает автору взглянуть ещё раз.

Что дальше

Для дайджеста планируем отдельный сайт вместо файла, чтобы не скачивать HTML.

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

Ещё хочу переработать сами инструменты агента — сделать их у́же и точнее. Сейчас некоторые слишком «широкие»: один инструмент умеет много всего сразу, и агенту приходится угадывать, как именно им воспользоваться, — отсюда часть промахов. Планирую разбить такие на несколько узких и понятных, каждый со своей чёткой задачей: чем конкретнее инструмент, тем меньше у агента простора ошибиться и тем предсказуемее результат.