Конспект доклада про автофикс проблем CI/CD с использованием ИИ со второго занятия «Вечерней школы. ИИ для инженеров: польза и риски» от Слёрма
Пятница, вечер. Ты выкатываешь деплой и со спокойной душой уходишь домой. Утром открываешь дашборд и видишь: из 68 компонентов приложения не работают 54. Именно с такого реального кейса начал второе занятие «Вечерней школы. ИИ для инженеров: польза и риски» Александр Крылов (@Darkbenladan на Хабре), и дальше объяснил, как сделать так, чтобы подобные утра случались как можно реже, причём без ночных смен инженеров.
Этим летом Слёрм запустил бесплатную «Вечернюю школу. ИИ для инженеров: польза и риски». Шесть открытых онлайн занятий о том, где искусственный интеллект реально помогает инженеру, а где создаёт новые риски. Занятия построены на живых кейсах и рабочих процессах: инженеры, архитекторы, безопасники и даже юрист разбирали, как ИИ встраивается в разбор инцидентов, автофикс прода, SOC и code review, на разных моделях и инструментах.
Первое занятие школы было про то, как ИИ-агент разбирает алерты и собирает контекст инцидента за дежурного инженера. Полный разбор того доклада можно найти в первой статье цикла: «Как научить ИИ разгребать метрики, пока дежурный допивает чай».
Второе занятие прошло 23 июля 2026 года и было посвящено соседней боли: тому, что происходит после того, как инцидент уже случился и нужно системно, на регулярной основе, чинить сам деплой.
Доклад прочитал Александр Крылов (@Darkbenladan). Александр рассказал реальный кейс из своей практики: как команда с помощью сервиса на Python и собственной базы знаний научилась автоматически чинить типовые проблемы CI/CD, что привело к (спойлер) снижению доли падающих деплоев в 2,5 раза и ускорила time-to-market в два раза, а заодно освободила часть ресурсов команды для других задач.
Спикер: Александр Крылов
в ИТ больше 12 лет
Технический директор ИТ Школы Ростелеком
глава программного комитета и основатель K8sday и observability conf
член программных комитетов конференций «Стачка», ProITFest, Merge, Performance Conf
выступал на DevOps Conf, HighLoad++, TeamLead Conf, «Стачка», Merge, ProITFest
автор курса «DevOps-инженер» в рамках проекта «Цифровые кафедры» для вузов России
соавтор и соведущий подкастов ProITStand и Brainstorm
Дальше в статье: с какой проблемы всё началось, какие метрики помогли найти самые проблемные места, из чего устроен сервис AutoFix, какие результаты он показал и что из процесса всё равно осталось на инженере.
Коротко о докладе, если ты внутри CI/CD и деплои каждый день немного пугают
команда Александра автоматизировала исправление типовых проблем CI/CD сервисом на Python с базой знаний на PostgreSQL и расширением pgvector
в первой версии сервис сопоставляет ошибку деплоя с базой типовых проблем, запускает готовое решение, которое может представлять из себя, например, скрипт (bash, ansible или SQL) и инициирует повторный деплой. При этом есть лимит на такие попытки, три штуки, что защищает от зацикливания при повторении проблем. В будущих версия сервиса появился компонент, который самостоятельно принимал решение по фиксу проблемы для тестовых контуров, основываясь не только на БД знаний, но и обученной модели
если решения нет, сервис автоматически заводит тикет в Jira и присылает уведомление в Slack по принципу ChatOps с контекстом ошибки, в которую входят: ссылка на лог pipe CI/CD, dashboard сервиса в grafana с шагом -15min и тикет в jira, где дублируется вся информация. Все срабатывания ведутся в jira и анализируются на предмет ложных или не корректных на ежеспринтовой основе
решения по рискованным изменениям, вроде смены типа данных в базе, всё равно принимает инженер, и полностью убрать человека из процесса не получилось: сам сервис требует администрирования
Проблема: яма сжигания ресурсов
Александр начал с ситуации, в которой оказалась его команда, ещё до всякой архитектуры. Внутри было около 12 инженеров, снаружи, на аутсорсе, ещё 15. По новым проектам ресурсы распределялись понятно, зато по старым системам команда регулярно уходила в траблшутинг: частые, но неэффективные точечные правки на скорую руку.
При этом важно понимать, что на команде в год могло быть до 70 проектов, в которые входили внедрения новых систем, технологий и интеграций, а сервисов на поддержке было более 20. С учётом этих вводных и на фоне оптимизации бюджета и штата это стало заметной проблемой. Держать немалую команду ради постоянного тушения одних и тех же пожаров, схожесть которых удавалось определить не сразу, стало нецелесообразно, а формально сократить людей означало ещё сильнее раздуть нагрузку на оставшихся. Нужно было найти ту самую «яму», куда утекают часы инженеров, и по возможности закрыть её без ручного труда.
По ходу доклада Александр менял оптику, то как тимлид, который распределяет ресурсы команды, то как архитектор решения, то как рядовой инженер, который руками разбирает очередной фейл. Такой приём удобен для доклада с несколькими слоями контекста: бизнес-задача, техническое решение и рутинная инженерная работа рассматриваются каждая в своём слое.
Метрики: как нашли самые проблемные места
Чтобы не листать вручную десятки пайплайнов по 30 с лишним системам и тысячам сервисов, команда собрала метрики в одном окне. Источники:
GitLab CI/CD. Процент успешных и неуспешных деплоев по каждому контуру, а также время выполнения деплоя.
Jira. Тайминг спринтов, чтобы смотреть метрики деплоев ретроспективно, в разрезе конкретных спринтов.
VictoriaMetrics (Victoria Logs, Victoria Metrics) и Grafana. Слои app и performance мониторинга: HTTP-статусы компонентов, рестарты подов, задержки в сети, состояние подключённых хранилищ, нагрузка и утилизация ресурсов сервисов и т.д.
Confluence. База знаний с описанием типовых проблем и их решений, добавленная в контур метрик последней.
После сбора всей необходимой информации и её проверки, данные быстро показали конкретную картину. На тестовых контурах фейлилось 55% всех деплоев. Среднее время деплоя составляло от 15 до 16 секунд, максимальное, после которого срабатывал алерт, 26,7 секунды. У одного из сервисов, самого нестабильного, доля фейлов на тестовых контурах доходила до 70%, и почти все причины оказались типовыми, просто ещё не задокументированными.
За критерий успеха взяли саму метрику деплоя: долю успешных релизов должна стремиться к 100%. Задача состояла в том, чтобы докапываться до первопричин проблем и решать их на корню (RСA), при этом планировать проведения ряд работ по улучшению pipeline CD, стабилизацию инфраструктуры и кодовой базы сервисов. А после работ оценивать влияния на метрику. После выявления самого проблемного сервиса, начали с него, и постепенно масштабировали решение на остальные.
Технологический стек
Архитектура строилась поверх уже существующего стека компании, без замены привычных инструментов:
CI/CD: GitLab CI
хранилище артефактов: Harbor
виртуализация: VMware
оркестрация: Kubernetes и Helm
база знаний: Confluence
задачи и тикеты: Jira
сервис для сбора, анализа и корреляции метрик: собственная разработка на Python
мониторинг: VictoriaMetrics (Victoria Logs, Victoria Metrics) плюс визуализация в Grafana
ChatOps: Slack + Jira
БД Сервиса: postgresql, pgvector
Слайд презентации: стек инструментов решения
Типовые ошибки, из-за которых горят тестовые контуры
Когда команда разобрала накопленные фейлы, оказалось, что подавляющее большинство деплоев на всех окружениях (больше 30%) падает по одним и тем же причинам, и лишь меньше 30% из этих случаев были по-настоящему уникальными. Типовые проблемы, с которых начинали:
Переменные окружения и пробы Kubernetes. Опечатки, недописанные или неверно указанные параметры liveness и readiness, из-за которых проба срабатывает раньше, чем приложение успевает запуститься внутри пода.
Лимиты памяти. Несогласованные значения между лимитами уровня приложения (например, xmx и xms в Java) и лимитами Kubernetes в переменной resources.limits.memory. Команда решила проблему просто: составила карту лимитов для каждого приложения и сверяла деплои с этой картой.
Опечатки и типовые ошибки в Helm и YAML. Классические ошибки отступов, опечаток, структуры и параметров. Helm-линтеры и YAML-линтеры ловят часть таких ошибок, но покрыть линтерами вообще всё нереально, да и пользуется ими далеко не каждая команда.
В условиях ограниченных ресурсов быстрее было пойти по пути автоматизации и собрать каталог типовых проблем, чем идти по пути бэклога с рефакторингом инфраструктурного кода и покрытия его тестами и линтерами.
Решение типовых ошибок в БД сервисов. Самый чувствительный пункт, с которым было сложнее всего. Вот, например, поле, которое было varchar, внезапно превращалось в integer из-за опечатки в миграции. Для теста такие ошибки можно фиксить автоматически, а для прода изменения в архитектуре базы данных требуют отдельного решения человека, если только это не задокументированное и ожидаемое изменение из release notes.
Настройки подов, сети и нейминга. Отдельная категория ошибок, которую команда закрыла заранее: завести новый сервис можно было только через фиксированный набор шаблонов и скриптов, которые сразу создавали репозиторий с правильным неймингом и правами в GitLab и Harbor.
Отдельно Александр отметил человеческий фактор: для тестирования нового функционала команда иногда временно отключала автофикс, и делать это могли только определённые люди по чётким правилам.
Архитектура AutoFix: RAG на собственной базе знаний
Когда в GitLab CI случается фейл деплоя, срабатывает пост-джоба, которая передаёт информацию в сервис на Python. Дальше сервис работает по классическому RAG-подходу.
RAG (retrieval-augmented generation): подход, при котором система сначала ищет релевантный контекст в собственной базе знаний, а уже потом использует его для генерации ответа или решения, вместо того чтобы полагаться только на общие знания модели.
Сервис парсит лог ошибки, обращается к векторной базе на PostgreSQL с расширением pgvector и ищет соответствие. Если решение находится, запускается соответствующее решение проблемы, возможна разная реализация (bash, ansible, helm, SQL) и инициируется повторный деплой. Лимит на такие попытки, три штуки, задан эмпирически и защищает систему от зацикливания, если одна и та же ошибка почему-то повторяется без остановки.
Если решения не находится, потому что ошибка новая или уникальная, сервис автоматически создаёт тикет в Jira с деталями (включая срез метрик за 15 минут до появления первой ошибки) и дублирует уведомление в Slack с назначением на конкретного инженера. Если однотипная ошибка повторяется от 3 до 5 раз, сервис сам добавляет её в базу знаний как новую типовую, хотя решение под неё всё равно вносит человек, и с определённого момента команда добавила дополнительный валидатор, который проверяет предложенное решение до того, как оно попадёт в базу.
Всю архитектуру и первую рабочую версию сервиса команда собрала за месяц, а полностью готовый инструмент со всеми доработками, включая чат-опс и автоматическое пополнение базы, получился примерно за квартал.
Результаты внедрения
Показатель | До AutoFix | После AutoFix |
|---|---|---|
Неуспешные деплои на тестовых контурах | 55% | около 20% |
Неуспешные деплои в проде на самом нестабильном сервисе | каждый четвёртый деплой | меньше 20%, из них от 65 до 70% чинится автоматически |
Неуспешные деплои на всех окружениях вместе | больше 30% | около 20% |
Time-to-market | базовый уровень | сократился в 2 раза |
Падающие деплои | базовый уровень | уменьшились в 2,5 раза |
Не смотря на условия оптимизации, в которых находилась команда: внешних, аутсорс-инженеров сократилось с 15 до 0, а внутренних с 12 до 8 человек, команде удалось не потерять темп решения задач бэклога и входящих обращений, а освободившиеся часы с задач траблшутинга, команда перекинула на развитие самого сервиса и другие задачи.
Что осталось за человеком
Полностью убрать инженера из процесса, по словам Александра, не получилось, и не должно было получиться. За человеком остаются:
развёртывание и настройка новых окружений для задач и сервисов (позже это тоже автоматизировали)
разбор уникальных и новых ошибок, которые ещё не стали типовыми и не имели регулярного воспроизведения
пополнение базы знаний решениями, через Jira, Confluence или напрямую через pgvector
администрирование и развитие самого сервиса AutoFix, у которого тоже случаются свои ошибки
контроль бэклога по решению типовых проблем и их невоспроизведения в будущем
Слайд презентации: зоны ответственности человека и ИИ
За автоматизацией остаются обработка уже известных типовых ошибок, запуск скриптов исправления, пополнение базы после нескольких повторений одной и той же проблемы и генерация тикетов и уведомлений. Даже при высокой доле автоматических фиксов сервис требует администрирования, а значит, кто-то из команды всегда должен его поддерживать и развивать. В более поздних версиях у сервиса появилась полноценная модель, которая имела доступ к набору *ручек, с возможностью самостоятельного фикса проблем, основанное не только на БД знаний, но и модели.
Ограничения и правила безопасности автофикса
Команда сразу заложила несколько ограничений, чтобы автоматизация не превратилась в источник новых проблем:
лимит на количество повторных деплоев (три попытки), чтобы избежать бесконечного цикла редеплоев при повторяющейся ошибке
разделение по окружениям: для теста автофикс применялся смелее, а на прод выкатывались только уже апробированные и проверенные сценарии, особенно по чувствительным изменениям вроде типов данных в базе
жизненный цикл модели около 6 месяцев: команда не обновляла модель чаще раза в два квартала, потому что более частые обновления увеличивают затраты на сопровождение сильнее, чем дают пользы
версионирование самого сервиса: новая логика сначала проходит тестовый контур на одном сервисе и только потом масштабируется на остальные
жёсткая модель безопасности и ограничения действий сервиса на принятия решения и их исполнение 
Слайд презентации: чек-лист самостоятельной работы
Итоги доклада
Автофикс проблем прода с ИИ, по кейсу Александра, начинается с данных: метрик деплоев, каталога типовых ошибок и накопленной базы решений, и только потом упирается в саму модель. RAG поверх собственной базы знаний на PostgreSQL и pgvector оказался достаточным решением для того, чтобы закрыть большую часть рутинных проблем без сложной ML-инфраструктуры.
При этом решение полностью не избавляет от участия инженера: человек продолжает разбирать новые проблемы, пополнять базу знаний и администрировать сам сервис. Зато рутинная часть, повторяющиеся ошибки, которые раньше отнимали часы у инженеров, ушла в автоматизацию, и команда за квартал получила ощутимый эффект: доля падающих деплоев сократилась в 2,5 раза, а time-to-market вырос вдвое.
Это конспект второго из шести занятий «Вечерней школы. ИИ для инженеров: польза и риски». Дальше в программе были ИИ-агенты для бизнес-задач, юридические риски использования ИИ, дообучение LLM под конкретный SOC и разговор о том, как вообще меняется инженерное мышление в эпоху LLM.
Посмотреть запись этого занятия можно на YouTube по прямой ссылке, а все шесть занятий школы собраны в плейлисте «Вечерней школы. ИИ для инженеров». Устраивайся поудобнее, чай можно уже не экономить.
А если хочется пройти всю школу целиком, с материалами и файлами для практики после каждого занятия, доступ к курсу на обучающей платформе Слёрма можно получить на сайте: https://slurm.io/ai-school.
P.S.Если хотите узнать подробнее про архитектуру решения и как оно создавалось, можно ознакомиться с докладом Александра тут
