Когда пайплайн чинит себя сам

Большая часть падений CI/CD повторяется. Одна и та же опечатка в Helm, рассогласованные лимиты памяти, проба Kubernetes, которая срабатывает раньше старта приложения. Инженер тратит на такие инциденты часы, хотя решение уже известно и лежит в чьей-то голове или в вики. Идея автофикса простая: описать типовые проблемы один раз, привязать к каждой готовый сценарий восстановления и позволить сервису применять эти сценарии самостоятельно, оставив человеку только новые случаи.

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

Сначала метрики, потом архитектура

Прежде чем что-то автоматизировать, нужно понять, куда именно утекают часы. Полезно свести в одно окно четыре источника данных:

GitLab CI/CD — доля успешных и неуспешных деплоев по каждому контуру плюс время выполнения деплоя.
Трекер задач — тайминг спринтов, чтобы смотреть метрики деплоев ретроспективно, в разрезе конкретных периодов.
Мониторинг приложений и инфраструктуры (VictoriaMetrics, Grafana) — HTTP-статусы компонентов, рестарты подов, сетевые задержки, состояние хранилищ, утилизация ресурсов.
База знаний — описание типовых проблем и решений; её подключают к контуру метрик последней, когда уже понятно, что документировать.

Такой срез быстро показывает картину. Типичный результат: на тестовых контурах падает больше половины всех деплоев, среднее время деплоя — секунды, а у самого нестабильного сервиса доля фейлов доходит до 70 %. Почти все причины оказываются типовыми, просто ещё не записанными. Дальше логично взять один самый проблемный сервис, довести его до приемлемой доли успешных релизов и масштабировать подход на остальные.

Каталог типовых причин падений

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

Переменные окружения и пробы Kubernetes

Опечатки и недописанные параметры, а также liveness и readiness, настроенные так, что проба срабатывает раньше, чем приложение поднимается внутри пода. Лечится корректировкой манифеста и разумными задержками старта.

Рассогласование лимитов памяти

Значения на уровне приложения (-Xmx, -Xms в Java) расходятся с resources.limits.memory в Kubernetes. Помогает карта лимитов для каждого приложения: деплой сверяется с ней до применения.

Опечатки в Helm и YAML

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

Изменения схемы в базе

Поле было varchar, после опечатки в миграции стало integer. На тесте такое можно откатывать автоматически, на проде изменения схемы остаются за человеком — кроме заранее задокументированных изменений из release notes.

Нейминг, сеть и шаблоны сервисов

Категория, которую закрывают превентивно: новый сервис заводится только через фиксированный набор шаблонов и скриптов, которые сразу создают репозиторий с правильным неймингом и правами в GitLab и реестре образов.

Архитектура автофикса на RAG

Когда в GitLab CI падает деплой, срабатывает пост-джоба и передаёт данные в сервис на Python. Дальше работает классический RAG: сначала поиск релевантного контекста в собственной базе, потом действие на его основе.

Сервис парсит лог ошибки и формирует из него запрос.
Обращается к векторной базе на PostgreSQL с расширением pgvector и ищет ближайшее совпадение среди описаний типовых проблем.
Если совпадение найдено, запускается привязанный сценарий восстановления — это может быть скрипт на bash, плейбук Ansible, операция с Helm или SQL — и инициируется повторный деплой.
Число повторных попыток ограничено (например, тремя). Лимит подбирается эмпирически и защищает от бесконечного цикла редеплоев, если ошибка повторяется без остановки.

Если совпадения нет, ошибка считается новой. Сервис создаёт тикет в трекере с деталями инцидента, включая срез метрик за 15 минут до появления первой ошибки, и дублирует уведомление в Slack по принципу ChatOps: ссылка на лог пайплайна, дашборд в Grafana со сдвигом назад и тот же тикет. Все срабатывания складываются в трекер и раз в спринт разбираются на предмет ложных и некорректных.

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

Где ставить ограничители

Автоматика, которая перезапускает и правит прод, требует жёстких рамок с самого начала:

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

Что остаётся человеку

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

С чего начать у себя

Хорошее стартовое упражнение занимает пару часов:

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

Главный вывод по стеку: связки PostgreSQL и pgvector достаточно, чтобы закрыть основную массу рутинных проблем без тяжёлой ML-инфраструктуры. Ценность даёт не модель, а собранный каталог типовых ошибок и метрики деплоев под ним.