LLM для анализа постмортемов: как Zalando автоматизировал разбор инцидентов и выжил

Представь, что после 48 часов без сна, борьбы с очередным P0-инцидентом, ты наконец-то вернул сервис к жизни. Теперь самое "веселое" – написать постмортем. Собрать логи из 15 систем, сопоставить таймлайны, найти root cause, сформулировать action items. На это уходит 8-12 часов. А через неделю история повторяется, только с другим сервисом.

Этот цикл знаком каждому SRE. И он бесит. Потому что 90% работы в постмортеме – рутина: парсинг логов, структурирование событий, поиск паттернов. То, что идеально умеют делать современные LLM, если их правильно настроить.

В 2025 году Zalando показали, как можно сократить время на разбор инцидентов с 12 часов до 45 минут. Их система на базе GPT-4o-mini и Claude 3.5 Sonnet автоматически анализирует сырые данные и генерирует готовый постмортем. Давайте разберем, как это работает на практике, и как повторить у себя.

Почему ручной разбор инцидентов – это тупик

Ты думаешь, что пишешь уникальный анализ каждого инцидента. На самом деле ты делаешь одно и то же:

• Копируешь логи из Kibana/CloudWatch
• Выстраиваешь временную шкалу вручную
• Ищешь корреляции между метриками
• Переписываешь однотипные формулировки для action items

Проблема не в том, что это скучно. Проблема в том, что человеческий мозг плохо справляется с обработкой тысяч строк логов одновременно. Мы пропускаем паттерны. Упускаем корреляции. Зацикливаемся на очевидных гипотезах.

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

Архитектура Zalando: как они заставили LLM понимать инциденты

Система Zalando выглядит деceptively простой. Но под капотом – несколько критических решений, которые делают ее рабочей, а не просто демо.

1Сбор данных: не просто логи, а контекст

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

Zalando создали конвейер, который перед отправкой в LLM:

1. Нормализует временные метки из всех систем (UTC, одна таймзона)
2. Группирует логи по сервисам и инстансам
3. Добавляет метаданные о версиях, регионах, владельцах
4. Выделяет ошибки и warnings с помощью регулярных выражений

# Пример нормализации логов (упрощенно)
def prepare_logs_for_llm(raw_logs, service_metadata):
    """Подготовка логов с добавлением контекста"""
    normalized = []
    for log in raw_logs:
        # Добавляем контекст сервиса
        enriched_log = {
            "timestamp": convert_to_iso(log["ts"]),
            "service": service_metadata["name"],
            "version": service_metadata["version"],
            "region": log.get("region", "unknown"),
            "level": classify_log_level(log["message"]),
            "message": log["message"],
            # Критично: добавляем тип события
            "event_type": extract_event_type(log["message"])
        }
        normalized.append(enriched_log)
    return normalized

Этот шаг увеличивает точность анализа LLM на 40-60%. Потому что модель начинает понимать не просто текст, а структуру инцидента.

2Мультимодельный подход: GPT-4o-mini + Claude 3.5 Sonnet

Здесь Zalando сделали неочевидный ход. Они используют две разные модели для разных задач:

GPT-4o-mini обрабатывает первоначальный поток данных – сортирует логи, строит временную шкалу, выделяет ключевые события. Claude 3.5 Sonnet получает уже структурированные данные и занимается именно анализом причин.

3Prompt engineering: как говорить с LLM на языке SRE

Самый критичный компонент. Промпты Zalando – это не просто "проанализируй логи". Это структурированные инструкции с четкими ролями и форматами вывода.

Вот как выглядит их основной промпт для анализа (упрощенно):

POSTMORTEM_ANALYSIS_PROMPT = """
Ты – старший SRE инженер с 10-летним опытом.
Анализируешь инцидент по следующим данным:

{structured_timeline}

Инструкции:
1. Определи root cause (первопричину) инцидента
2. Если данных недостаточно – перечисли какие именно данные нужны
3. Оцени уверенность в анализе от 1 до 10
4. Предложи 3-5 action items для предотвращения

Формат ответа:
ROOT_CAUSE: [причина, 1-2 предложения]
CONFIDENCE: [число от 1 до 10]
MISSING_DATA: [список или "нет"]
ACTION_ITEMS:
- [item 1]
- [item 2]
TIMELINE_SUMMARY: [хронология, 5-7 пунктов]
"""

Ключевой момент – формат вывода. LLM склонна к многословию, а нам нужна структурированная информация для автоматической обработки. Этот промпт заставляет модель думать как инженер, а не как поэт.

Пошаговая реализация: собираем систему с нуля

Теперь давай соберем минимальную рабочую версию. Не нужно копировать Zalando один в один – начни с того, что даст результат через неделю, а не через полгода.

Шаг 1: Интеграция с источниками данных

Начни с 2-3 самых критичных систем. Например:

• CloudWatch Logs (если на AWS)
• Elasticsearch/Kibana для логов приложений
• Datadog или New Relic для метрик

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

# Минимальный сборщик логов
import boto3
from datetime import datetime, timedelta

class IncidentDataCollector:
    def __init__(self):
        self.cloudwatch = boto3.client('logs')
        self.es_client = Elasticsearch([{'host': 'localhost', 'port': 9200}])
    
    def collect_for_incident(self, incident_id, time_range):
        """Сбор данных по конкретному инциденту"""
        logs = self._get_cloudwatch_logs(time_range)
        metrics = self._get_application_metrics(time_range)
        alerts = self._get_pagerduty_alerts(incident_id)
        
        return {
            'incident_id': incident_id,
            'logs': logs,
            'metrics': metrics,
            'alerts': alerts,
            'collected_at': datetime.utcnow().isoformat()
        }

Шаг 2: Нормализация и обогащение

Здесь многие ошибаются, пытаясь создать универсальный парсер для всех логов. Не надо.

Создай отдельные обработчики для каждого типа логов:

class LogNormalizer:
    """Базовый класс для нормализации логов"""
    
    def normalize(self, raw_log):
        # Определяем тип лога по паттерну
        log_type = self._detect_log_type(raw_log)
        
        # Вызываем соответствующий обработчик
        if log_type == 'nginx':
            return self._normalize_nginx_log(raw_log)
        elif log_type == 'application_json':
            return self._normalize_app_json_log(raw_log)
        elif log_type == 'postgres':
            return self._normalize_postgres_log(raw_log)
        else:
            # Fallback: минимальная нормализация
            return self._normalize_generic_log(raw_log)

Шаг 3: Настройка LLM пайплайна

Используй OpenAI API для GPT-4o-mini и Anthropic для Claude. Настрой простой роутинг:

class LLMAnalyzer:
    def __init__(self, openai_key, anthropic_key):
        self.openai_client = OpenAI(api_key=openai_key)
        self.anthropic_client = anthropic.Anthropic(api_key=anthropic_key)
    
    def analyze_incident(self, normalized_data):
        """Двухэтапный анализ"""
        # Этап 1: Быстрая обработка GPT-4o-mini
        timeline = self._create_timeline_gpt(normalized_data)
        
        # Этап 2: Глубокий анализ Claude 3.5 Sonnet
        analysis = self._deep_analyze_claude(timeline)
        
        return {
            'timeline': timeline,
            'root_cause_analysis': analysis
        }
    
    def _create_timeline_gpt(self, data):
        """GPT-4o-mini строит временную шкалу"""
        response = self.openai_client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{
                "role": "system",
                "content": POSTMORTEM_TIMELINE_PROMPT
            }, {
                "role": "user",
                "content": json.dumps(data, indent=2)
            }]
        )
        return response.choices[0].message.content

Шаг 4: Валидация и human-in-the-loop

Самая опасная часть – слепо доверять выводам LLM. Zalando внедрили простую, но эффективную систему валидации:

1. LLM генерирует черновик постмортема
2. Система оценивает уверенность (confidence score)
3. Если confidence < 7 – постмортем помечается как "требует ручной проверки"
4. SRE инженер проверяет и корректирует анализ
5. Коррекции добавляются в тренировочные данные для улучшения модели

Этот цикл критически важен. Без него ты получишь красивый, но иногда совершенно неверный анализ.

Где система Zalando спотыкается (и как это исправить)

После 6 месяцев эксплуатации команда Zalando выявила три основные проблемы:

Эти проблемы не фатальны. Они решаются дополнительными слоями проверки и более тонкой настройкой промптов.

Что получишь на выходе: метрики, которые имеет смысл отслеживать

Внедряя такую систему, смотри не на красивые демо, а на конкретные метрики:

• MTTA (Mean Time To Analysis): время от окончания инцидента до готового постмортема. У Zalando упало с 12 часов до 45 минут
• Accuracy rate: процент постмортемов, не требующих существенной правки. Цель – 70-80%
• Action items completion: сколько рекомендаций от LLM действительно внедряются
• Time saved per incident: часы, которые инженеры тратят на рутинный анализ

В первые месяцы accuracy rate будет низким – 50-60%. Это нормально. Каждая правка инженера – это тренировочные данные для улучшения системы.

Стоит ли строить свою систему или использовать готовую?

На рынке уже появились коммерческие решения: Incident.io с AI-анализом, FireHydrant, Rootly. Они дешевле собственной разработки в первый год.

Но у своей системы есть преимущества:

1. Полная интеграция с твоим стеком технологий
2. Возможность тонкой настройки под специфичные паттерны инцидентов
3. Контроль над данными (критично для финансовых, медицинских компаний)
4. Стоимость владения на 3+ году ниже коммерческих решений

Если у тебя 50+ инцидентов в месяц и команда из 5+ SRE – своя система окупится за 9-12 месяцев. Если меньше – начинай с коммерческого решения, но обязательно с API для экспорта данных.

Что будет дальше: куда движется автоматизация постмортемов

То, что делает Zalando сегодня – только начало. Вот что появится в ближайшие 12-18 месяцев:

• Прогнозирование инцидентов: LLM будут анализировать метрики и предсказывать сбои за часы до их возникновения
• Автоматические remediation планы: не просто анализ, но и готовые скрипты для устранения
• Кросс-сервисный анализ: системы будут понимать зависимости между сервисами и находить каскадные сбои
• Интеграция с observability: прямой анализ трассировок и профилировщиков без ручного экспорта

Но самая интересная возможность – коллективный разум. Представь систему, которая обучается на постмортемах тысяч компаний, выявляет глобальные паттерны сбоев (например, уязвимости в конкретных версиях PostgreSQL или проблемы с определенными регионами AWS), и предупреждает тебя до того, как это коснется твоей инфраструктуры.

Мы движемся к миру, где инциденты будут не катастрофами, а возможностями для обучения систем. Где каждая минута простоя делает инфраструктуру умнее и устойчивее.

А пока – начни с простого. Выбери один тип инцидентов (например, проблемы с базой данных), собери логи за последние 3 случая, и попробуй прогнать их через GPT-4o-mini с промптом из этой статьи. Первые результаты удивят тебя больше, чем кажется.