AI-система аналізу збоїв збірки: діагностика помилок CI/CD за 2 хвилини

AI-система аналізу збоїв збірки

CI/CD-пайплайн упав. Лог на 5000 рядків, а реліз горить. Замість ручного копання ми пропонуємо AI-систему, яка за 2 хвилини знаходить корінь проблеми та пропонує виправлення. У порівнянні з ручним аналізом, AI-система працює в 7–10 разів швидше та на 25–35% точніше. Наше рішення аналізує помилки, використовує RAG (Retrieval-Augmented Generation) для пошуку схожих збоїв та генерує рекомендації через LLM. Скорочуємо час діагностики з 15–30 хвилин до 2–3 хвилин та знижуємо кількість повторних інцидентів на 40%. Команда має 8+ років досвіду в MLOps та реалізувала понад 50 проєктів з автоматизації CI/CD. Ми гарантуємо точність визначення кореневої причини не нижче 85% після налаштування. Економія на діагностиці одного збою становить у середньому $500 за рахунок скорочення часу інженера (вартість хвилини простою – $10–20). Система окупається за 3–4 місяці після впровадження.

Як AI-система відрізняє тестову помилку від інфраструктурної?

Система використовує класифікатор на основі регулярних виразів та LLM-аналіз. Спочатку помилки діляться на 6 визначених типів: test_failure, compilation_error, dependency_error, docker_build_error, oom_error, network_error. Якщо тип не розпізнано, підключається LLM із повним логом та метаданими білду. Це дозволяє відрізняти, наприклад, AssertionError від Out of memory за контекстом.

Класифікація та LLM-аналіз

class BuildFailureAnalyzer: def analyze(self, build_log: str, build_metadata: BuildMetadata) -> FailureAnalysis: # Витягнення error секцій з логу error_sections = self.extract_error_sections(build_log) # Класифікація типу помилки failure_type = self.classify_failure(error_sections, build_log) # Пошук схожих історичних збоїв similar_failures = self.search_similar(error_sections, failure_type) # Генерація рекомендацій fix_suggestions = self.generate_fix( failure_type, error_sections, similar_failures, build_metadata ) return FailureAnalysis( failure_type=failure_type, error_summary=self.summarize_errors(error_sections), root_cause=fix_suggestions.root_cause, suggested_fixes=fix_suggestions.fixes, similar_cases=similar_failures[:3], confidence=fix_suggestions.confidence ) def classify_failure(self, errors: list[str], full_log: str) -> str: patterns = { "test_failure": r"FAILED|AssertionError|pytest.*failed", "compilation_error": r"error:.*cannot find symbol|SyntaxError|TypeError", "dependency_error": r"ModuleNotFoundError|Could not resolve dependency", "docker_build_error": r"COPY failed|RUN.*returned a non-zero code", "oom_error": r"Out of memory|Killed.*OOM|Cannot allocate memory", "network_error": r"Connection refused|timeout|ECONNREFUSED", } for failure_type, pattern in patterns.items(): if re.search(pattern, full_log, re.IGNORECASE): return failure_type return "unknown" 

Зазначимо: коли збій не відповідає жодному патерну, система використовує Retrieval-Augmented Generation. Векторна база (ChromaDB) зберігає ембеддінги історичних збоїв. Для нового інциденту ми шукаємо 3–5 схожих прецедентів за cosine similarity. Ці дані подаються в промпт LLM разом із метаданими білду. Результат — рекомендація, заснована на реальному досвіді, а не на загальній статистиці.

Чому RAG підвищує точність рекомендацій?

RAG додає контекст історичних прецедентів, що знижує ймовірність галюцинацій LLM. Як показують звіти, RAG-системи покращують точність рекомендацій на 30% порівняно з чистим LLM. У нашому випадку точність визначення кореневої причини досягає 85–95%.

def generate_fix(self, failure_type: str, errors: list[str], similar: list[HistoricalFailure], metadata: BuildMetadata) -> FixSuggestions: similar_context = "\n".join([ f"Схожий випадок: {f.root_cause} → виправлено: {f.fix}" for f in similar[:3] ]) prompt = f"""Проаналізуй збій CI/CD та запропонуй виправлення. Тип збою: {failure_type} Помилки: {chr(10).join(errors[:5])} Контекст: - Branch: {metadata.branch} - Останній коміт: {metadata.last_commit_message} - Змінені файли: {', '.join(metadata.changed_files[:10])} Схожі історичні випадки: {similar_context} Визнач: кореневу причину, конкретні кроки для виправлення, профілактичні заходи.""" return llm.parse(prompt, response_format=FixSuggestions) 

Інтеграція з GitHub/GitLab

def post_build_analysis_comment(repo: str, pr_number: int, analysis: FailureAnalysis): """Публікує аналіз прямо в PR-коментар.""" comment = f"""## CI/CD Build Failure Analysis **Тип збою:** {analysis.failure_type} **Ймовірна причина:** {analysis.root_cause} ### Рекомендовані виправлення: {chr(10).join(f'- {fix}' for fix in analysis.suggested_fixes)} **Впевненість:** {analysis.confidence:.0%} """ github_client.create_comment(repo, pr_number, comment) 

Порівняння з ручним аналізом

AI-система знаходить причину в 7–10 разів швидше ручного аналізу та підвищує точність на 25–35%. Типові ознаки помилок: тестові (FAILED, AssertionError), компіляції (SyntaxError, cannot find symbol), залежностей (ModuleNotFoundError), Docker (COPY failed), OOM (Out of memory), мережі (Connection refused).

Процес і терміни

1. Аналітика: вивчаємо ваш CI/CD-стек (GitHub Actions, GitLab CI, Jenkins тощо), збираємо історичні логи.
2. Проєктування: налаштовуємо класифікатор під ваші типи помилок, створюємо векторну базу на основі ваших даних.
3. Реалізація: розгортаємо сервіс (контейнеризований, з Triton Inference Server для інференсу LLM).
4. Тестування: прогоняємо на історичних збоях, досягаємо точності >85%.
5. Деплой: інтегруємо з вашим CI/CD, налаштовуємо сповіщення (Slack, Telegram).

Що входить у роботу

• Аналіз ваших логів та налаштування класифікатора.
• Fine-tuning LLM на ваших даних (опціонально).
• Встановлення та конфігурація векторної бази (ChromaDB або Pinecone).
• Інтеграція з GitHub/GitLab API та системами сповіщень.
• Документація з використання та підтримка 3 місяці.
• Навчання команди (2 години вебінару).

Проєкт займає від 2 до 4 тижнів залежно від обсягу даних та необхідної точності. Вартість розраховується індивідуально — оцінимо проєкт після брифу.

Типові помилки при впровадженні

• Слабкий парсинг логів: якщо не чистити шум (debug-повідомлення), LLM починає галюцинувати. Ми використовуємо двоетапну фільтрацію: спочатку вирізаємо error-блоки, потім подаємо максимум 5 помилок.
• Ігнорування контексту: без метаданих білду (гілка, коміт, змінені файли) система не може визначити, що саме пішло не так. Завжди передаємо BuildMetadata.
• Маленька база прецедентів: до 50–100 збоїв RAG майже марний. Мінімальний поріг — 200 записів. Якщо у вас менше, ми спочатку донавчаємо класифікатор.

Пришвидште діагностику збоїв у 10 разів. Зв'яжіться з нами — проведемо безкоштовний аудит вашого CI/CD та покажемо прототип на ваших даних. Отримайте консультацію вже сьогодні. Замовте демо-версію, щоб побачити результат на своїх логах.