ИИ-агент AutoFix снижает количество падающих деплоев в 2,5 раза: опыт автоматизации CI/CD на базе знаний

# Когда пятничный деплой превращается в катастрофу

Представьте стандартную сцену для любого DevOps-инженера: пятница, вечер, успешный запуск релиза и возвращение домой с чувством выполненного долга. Утро понедельника открывает дашборд в панике: из 68 компонентов приложения функционируют лишь 34, а 54 уже требуют внимания. Именно с этого реального кейса началась история сервиса AutoFix, разработанная командой Александра Крылова, технического директора ИТ Школы «Ростелеком».

Проблема заключалась в «яме сжигания ресурсов». Команда из 12 внутренних инженеров и 15 аутсорс-специалистов поддерживала более 70 проектов в год. Значительную часть времени они тратили не на развитие, а на тушение пожаров в виде повторяющихся сбоев CI/CD. Оптимизация бюджета и штата усугубила ситуацию, сделав ручное тушение ошибок экономически нецелесообразным. Цель была ясна: найти корневые причины сбоев и автоматизировать их исправление без необходимости работать в ночные смены.

Как строится архитектура решения на базе знаний

Сервис AutoFix реализует концепцию RAG (Retrieval-Augmented Generation — генерация с привлечением извлеченного контекста). Вместо того чтобы полагаться исключительно на общие знания языковой модели, система сначала ищет релевантное решение в собственной базе знаний, а затем формирует ответ или запускает скрипт на его основе.

Техническая реализация: 1. Цепочка событий: При сбое деплоя в GitLab CI срабатывает пост-джоба, передающая логи в сервис AutoFix на Python. 2. Поиск решения: Сервис парсит логи и обращается к векторной базе данных PostgreSQL с использованием расширения pgvector. Здесь хранятся описания типовых проблем и их решения. 3. Действие: Если найдено решение, запускается соответствующий скрипт (bash, Ansible, SQL) и инициируется повторный деплой. Количество попыток ограничено тремя, чтобы избежать бесконечного цикла редеплоев при неизменной ошибке. 4. Эскалация: Если решение не найдено или ошибка уникальна, система автоматически создает тикет в Jira и отправляет уведомление в Slack с детальным контекстом (графики метрик за 15 минут до сбоя, ссылки на логи).

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

Что такое RAG простыми словами

RAG — это метод, при котором искусственный интеллект не отвечает на основе своих внутренних нейросетевых весов, а сначала «читает» предоставленную ему информацию. В случае AutoFix эта информация — это документированные кейсы и скрипты, которые уже доказали свою эффективность для конкретной компании. Это снижает риск галлюцинаций (неправильных ответов) ИИ, так как решения базируются на проверенных фактах из истории проектов организации.

Какие ошибки исправляются автоматически, а что остается за человеком

Анализ показал, что более 30% всех сбоев носят типовой характер. Сервис успешно справляется с рядом классических проблем:

* Конфигурация Kubernetes: Опечатки в переменных окружения, ошибки в параметрах пробуждения (liveness/readiness probes), когда проверка состояния запускается раньше, чем приложение готово отвечать. * Лимиты ресурсов: Несогласованность между лимитами памяти в конфигурации приложения (например, Java Xmx) и лимитами в манифесте Kubernetes. * Helm и YAML: Опечатки, проблемы с отступами и структурами файлов конфигурации. Хотя линтеры ловят часть таких ошибок, полная автоматизация через каталог известных проблем оказывается эффективнее при ограниченных ресурсах. * Нейминг и права: Стандартизированные скрипты обеспечивают правильное создание репозиториев и прав доступа при запуске новых сервисов.

Однако существуют границы автономии. Команда принципиально оставила за собой контроль над изменениями архитектуры базы данных. Пример: внезапное изменение типа поля из varchar в integer из-за ошибки в миграции может быть исправлен автоматически на тестовых контурах, но в продакшене требует обязательного человеческого решения. Также за человеком остаются:

* Разработка и развертывание новых окружений для уникальных задач. * Анализ и разрешение новых, ранее неизвестных типов ошибок. * Администрирование самого сервиса AutoFix. * Периодический root-cause анализ (RCA) для выявления новых закономерностей.

Результаты и ограничения внедрения

После внедрения сервиса показатели команды улучшились значительно. Доля неуспешных деплоев на тестовых контурах снизилась с 55% до около 20%. Для наиболее нестабильного сервиса количество падающих релизов в продакшене уменьшилось в 2,5 раза, а доля автоматически исправляемых сбоев составила от 65 до 70%.

Основные метрики до и после внедрения: | Показатель | До AutoFix | После AutoFix | | :--- | :--- | :--- | | Неуспешные деплои (тест) | 55% | ~20% | | Неуспешные деплои (прод, нестабильный сервис) | ~25% (1 из 4) | <20% | | Time-to-market | Базовый уровень | Ускорен в 2 раза | | Доля падающих деплоев (все окружения) | >30% | ~20% |

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

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

Заключение

Опыт Александра Крылова демонстрирует, что применение ИИ в DevOps не обязательно подразумевает создание сложных ML-моделей с нуля. Использование готовых подходов, таких как RAG, на базе структурированных данных компании позволяет быстро решить масштабную проблему рутинных сбоев. Однако разумное сочетание автоматизации и экспертного контроля инженера остается ключом к стабильной работе системы. Попробовать внедрить подобный подход можно, начав с анализа последних 20–30 деплоев на своем сервисе, выявления повторяющихся ошибок и попытки систематизировать их решение.