title: "AI-агенты для DevOps: автоматизация CI/CD и управление инцидентами" slug: agents-devops-cicd-incident-response-2026-ru date: 2026-02-21 lang: ru tags: [devops, ci-cd, incident-response, llm-agents, automation, infrastructure] description: "Как AI-агенты автоматизируют CI/CD-конвейеры, диагностируют production-инциденты, генерируют runbook'и и управляют изменениями инфраструктуры с approval-gate'ами."

AI-агенты для DevOps: автоматизация CI/CD и управление инцидентами

Ключевые факты

• anthropic: 0.84.0 (последняя стабильная версия, Messages API с поддержкой tool use)
• openai: 2.24.0 (поддерживает Assistants API v2 с function calling)
• langchain: 1.2.10 (фреймворк оркестрации агентов, поддержка LCEL)
• langgraph: 1.0.10 (stateful графы мультиагентных систем, persistence layer)
• slack-sdk: 3.40.1 (WebClient для публикации сообщений, поддержка blocks и attachments)
• pdpyras: 5.4.1 (обёртка REST API v2 PagerDuty, управление инцидентами)
• PagerDuty Events API v2 endpoint: https://events.pagerduty.com/v2/enqueue (payload: routing_key, event_action, payload.summary, payload.severity, payload.source)
• Slack WebClient method: client.chat_postMessage(channel='#incidents', text='...', blocks=[...])
• GitHub Actions OIDC: Настройка permissions: id-token: write, получение JWT с помощью ${{ github.token }}, обмен через aws-actions/configure-aws-credentials@v4
• workflow_dispatch event: Ручной триггер с параметром inputs для окружения, версии и т.д.
• Incident severity P1: Критический отказ системы, требуется немедленный отклик, SLA: 15 мин подтверждения, 1 час на разрешение
• Incident severity P2: Серьёзное снижение производительности, 30 мин подтверждения, 4 часа на разрешение
• Incident severity P3: Незначительное воздействие, 4 часа подтверждения, 24 часа на разрешение
• Incident severity P4: Минимальное воздействие, подтверждение на следующий рабочий день, 7 дней на разрешение
• Log regex patterns: r'ERROR|FATAL|CRITICAL|panic|exception', r'connection refused|timeout|deadline exceeded', r'out of memory|OOM|killed', r'rate limit|quota exceeded|throttled'
• Terraform plan parsing: Извлечение resources_added, resources_modified, resources_deleted из вывода плана
• CI/CD pipeline stages: unit-tests (3 мин), integration-tests (12 мин), security-scan (8 мин), performance-tests (25 мин), e2e-tests (20 мин)
• Approval gate triggers: production-окружение, любое удаление ресурса, risk_level >= high, >5 изменённых ресурсов, >20% прироста стоимости
• Agent model selection: Claude Opus 4.6 для сложной логики (диагностика инцидентов, оценка risk инфраструктуры), Claude Sonnet для ускоренной триажа
• Tool call timeout: 300 секунд для runbook-шагов, 60 секунд для запросов логов, 600 секунд для terraform apply
• Auto-remediation confidence threshold: 0.7 (70%) минимальная уверенность для автономного действия без эскалации

Сценарии использования DevOps-агента

Обнаружение и триаж инцидентов: Агенты поглощают алерты из PagerDuty/Prometheus/DataDog, параллельно собирают логи и метрики, коррелируют с недавними deployment-ами и классифицируют severity. Они различают реальные инциденты и ложные срабатывания, анализируя исторические паттерны.

Исполнение runbook'ов: Для известных типов инцидентов (нехватка памяти, исчерпание пула соединений, истечение сертификата) агенты автономно исполняют шаги remediation: перезагружают сервисы, масштабируют deployment-ы, ротируют credentials, очищают кэши. Они проверяют успешность после каждого шага и эскалируют при неудаче.

Маршрутизация oncall и эскалация: Агенты обогащают контекст инцидента перед вызовом людей. Они прикрепляют диагностические данные, вероятную root cause, рекомендуемые действия и релевантные ссылки на runbook'ы к инцидентам PagerDuty. Это снижает mean time to diagnosis с 23 минут до менее чем 5 минут.

Оптимизация CI/CD-конвейера: Агенты анализируют изменённые файлы и решают, какие test suite'ы запустить. Для изменений только документации они пропускают дорогие e2e-тесты. Для изменений сервиса платежей они триггерят полные security-scan'ы и performance-тесты. Это снижает среднюю длительность конвейера при сохранении покрытия.

Диагностика отказа тестов: Когда конвейеры падают, агенты парсят логи тестов, категоризируют ошибки (ошибка компиляции, нестабильный тест, реальная регрессия, проблема зависимостей), предлагают исправления и определяют, нужно ли блокировать merge или позволить retry.

Генерация post-mortem: После разрешения инцидента агенты черновой вариант blameless post-mortem'ов из timeline data, метрик и выполненных действий. Они применяют анализ 5-Whys root cause и генерируют SMART action item'ы, экономя 2-3 часа инженерного времени на инцидент.

Утверждение изменений инфраструктуры: Terraform-агенты запускают plan, оценивают risk на основе deletions и cost impact, определяют необходимых одобрителей, запрашивают human approval для high-risk изменений и исполняют apply только после одобрения.

Рамка принятия решений

Rule-based автоматизация (без LLM): Используйте для детерминированных задач с чёткими триггерами: renewal сертификата когда истечение < 7 дней, auto-scaling когда CPU > 80% в течение 5 минут, log rotation при 90% использования диска. Быстро, предсказуемо, ноль стоимости API.

LLM-агент (автономное действие): Используйте когда задача требует рассуждения над неструктурированными данными: диагностика novel error pattern'ов в логах, решение какие pipeline stage'ы запустить на основе изменённых файлов, оценка risk инфраструктурного изменения, классификация incident severity из текста алерта. Агент должен работать в рамках safety границ: confidence threshold'ы, approval gate'ы, circuit breaker'ы.

Human-in-the-loop: Требуется для: production infrastructure deletion'ов, инцидентов затрагивающих >10k пользователей, изменений с rollback_complexity = impossible, любого действия когда confidence агента < 70%, первого deployment'а в новое окружение (всегда dry-run сначала).

Критерии триггера activation агента:

• Alert severity >= P2 → активируйте incident response agent
• CI/CD pipeline failure → активируйте test diagnosis agent
• Terraform plan с >3 изменениями ресурса → активируйте infrastructure risk agent
• Log error rate > 10 ошибок/мин sustained за 5 мин → активируйте log analysis agent
• PagerDuty incident создан → прикрепите agent-generated diagnostic context

Критерии эскалации:

• Agent confidence < 0.7 → эскалируйте немедленно
• 3 последовательных неудачных попытки remediation → остановитесь и эскалируйте
• Инцидент не разрешён после 30 минут работы агента → эскалируйте senior engineer
• Любое infrastructure изменение deleting production ресурсы → требуйте CTO одобрение

Таблица справки параметров

Частые ошибки

Ошибка 1: Отправка полных логов в LLM без фильтрации

Воздействие: Переполнение контекста, высокая стоимость, медленный отклик. 1 миллион строк логов примерно ~4 токена/строка = 4M токенов = $30 за анализ с Claude Opus.

❌ Антипаттерн:

# Отправляет ВСЕ логи в LLM - упадёт на больших объёмах
logs = get_logs(service="api-gateway", hours=24)
diagnosis = client.messages.create(
    model="claude-opus-4-6",
    messages=[{"role": "user", "content": f"Analyze: {logs}"}]
)

✅ Правильный подход:

# Двухэтапный: быстрая фильтрация regex, затем LLM анализ deduplicated подмножества
ERROR_PATTERNS = [
    re.compile(r'ERROR|FATAL|CRITICAL', re.IGNORECASE),
    re.compile(r'connection refused|timeout'),
]

def filter_logs(log_stream):
    errors = []
    for line in log_stream:
        if any(p.search(line) for p in ERROR_PATTERNS):
            errors.append(line)
        if len(errors) > 500:
            break
    return deduplicate_errors(errors)  # Удалить повторяющиеся паттерны

filtered = filter_logs(get_logs("api-gateway", hours=24))
diagnosis = client.messages.create(
    model="claude-opus-4-6",
    messages=[{"role": "user", "content": f"Analyze: {filtered[:50]}"}]
)

Ошибка 2: Отсутствие approval gate для production инфраструктурных изменений

Воздействие: Production outage из-за автоматического удаления ресурса. Время восстановления: часы или дни если требуются backup'ы.

❌ Антипаттерн:

# Автоматически применяет ВСЕ terraform изменения
plan_result = run_terraform_plan(workspace="production")
run_terraform_apply(workspace="production", auto_approve=True)

✅ Правильный подход:

plan = run_terraform_plan(workspace="production")
risk = assess_risk(plan)  # LLM анализирует plan вывод

if (plan.resources_deleted or
    risk.level >= "high" or
    env == "production"):
    approval = request_approval(
        change=plan.summary,
        risk=risk,
        approvers=["cto", "platform-lead"],
        timeout_minutes=60
    )
    if not approval.approved:
        return {"status": "blocked"}

run_terraform_apply(workspace="production", auto_approve=True)

Ошибка 3: Отсутствие обработки LLM hallucination'ов в параметрах tool'ов

Воздействие: Агент вызывает инструменты с неверными параметрами (неправильное имя сервиса, несуществующий конвейер), вызывая каскадирующиеся ошибки.

❌ Антипаттерн:

# Слепо исполняет tool call'ы без валидации
for tool_call in response.content:
    if tool_call.type == "tool_use":
        result = execute_tool(tool_call.name, tool_call.input)

✅ Правильный подход:

# Валидируйте параметры инструмента против известных entities
VALID_SERVICES = ["api-gateway", "auth-service", "payment-service"]
VALID_ENVIRONMENTS = ["dev", "staging", "production"]

for tool_call in response.content:
    if tool_call.type == "tool_use":
        # Валидируйте сервис существует
        if "service" in tool_call.input:
            if tool_call.input["service"] not in VALID_SERVICES:
                return error_result(
                    f"Unknown service: {tool_call.input['service']}. "
                    f"Valid: {VALID_SERVICES}"
                )

        # Валидируйте окружение
        if "environment" in tool_call.input:
            if tool_call.input["environment"] not in VALID_ENVIRONMENTS:
                return error_result(f"Invalid environment")

        result = execute_tool(tool_call.name, tool_call.input)

Ошибка 4: Отсутствие circuit breaker'а на последовательные отказы

Воздействие: Агент усугубляет ошибки, делает production хуже. Пример: агент перезагружает сервис 10 раз в цикле, каждая перезагрузка вызывает краткий outage.

❌ Антипаттерн:

# Бесконечный retry цикл без лимита отказов
while not incident_resolved:
    action = agent.decide_next_action(incident)
    execute_remediation(action)

✅ Правильный подход:

MAX_FAILURES = 3
failures = 0

while not incident_resolved and failures < MAX_FAILURES:
    action = agent.decide_next_action(incident)
    result = execute_remediation(action)

    if not result.success:
        failures += 1
        if failures >= MAX_FAILURES:
            escalate_to_human(
                incident=incident,
                reason=f"Agent failed {MAX_FAILURES} consecutive actions",
                actions_attempted=action_log
            )
            break
    else:
        failures = 0  # Резет на успех

Ошибка 5: Отсутствие обогащения контекста инцидента перед вызовом людей

Воздействие: Oncall инженер просыпается, тратит 15-20 минут собирая те же диагностические данные которые агент уже собрал.

❌ Антипаттерн:

# Немедленно вызывает человека с raw алертом
if alert.severity == "P1":
    pagerduty.create_incident(title=alert.title, severity="P1")

✅ Правильный подход:

# Агент сначала собирает контекст, затем вызывает с обогащёнными данными
if alert.severity == "P1":
    context = await gather_diagnostic_context(alert)  # Параллельные запросы логов/метрик
    diagnosis = await diagnose_incident(alert, context)

    summary = generate_incident_summary(
        alert=alert,
        diagnosis=diagnosis,
        recent_deployments=context.deployments,
        recommended_actions=diagnosis.actions
    )

    pagerduty.create_incident(
        title=f"[AI-Triaged] {alert.title}",
        severity="P1",
        body=summary,
        custom_fields={
            "probable_cause": diagnosis.cause,
            "confidence": diagnosis.confidence,
            "logs_url": context.logs_link,
            "runbook_url": diagnosis.runbook_url
        }
    )

Incident Response Agent

Архитектура: Alert ingestion → context gathering → LLM диагностика → решение (remediate vs escalate) → исполнение → верификация.

Alert ingestion (PagerDuty webhook → агент):

from dataclasses import dataclass
from enum import Enum
from datetime import datetime

class IncidentSeverity(Enum):
    P1 = "P1"  # Critical - 15 мин ACK, 1 час разрешения
    P2 = "P2"  # High - 30 мин ACK, 4 часа разрешения
    P3 = "P3"  # Medium - 4 часа ACK, 24 часа разрешения
    P4 = "P4"  # Low - следующий рабочий день

@dataclass
class Alert:
    id: str
    title: str
    service: str
    severity: IncidentSeverity
    timestamp: datetime
    metrics: dict  # {"error_rate": 0.15, "latency_p99": 2500}
    labels: dict   # {"team": "platform", "region": "us-east-1"}

Context gathering (параллельные запросы к observability stack):

async def gather_context(alert: Alert) -> dict:
    tasks = [
        get_recent_logs(alert.service, minutes=30),
        get_metrics(alert.service, minutes=60),
        get_recent_deployments(alert.service, hours=24),
        get_dependency_health(alert.service),
    ]

    results = await asyncio.gather(*tasks, return_exceptions=True)

    return {
        "logs": results[0] if not isinstance(results[0], Exception) else [],
        "metrics": results[1] if not isinstance(results[1], Exception) else {},
        "recent_deployments": results[2],
        "dependency_health": results[3],
    }

LLM диагностика (structured output с confidence):

async def diagnose_incident(alert: Alert, context: dict) -> Diagnosis:
    prompt = f"""Диагностируйте production инцидент как expert SRE.

Alert: {alert.title}
Service: {alert.service}
Severity: {alert.severity.value}
Current Metrics: {json.dumps(alert.metrics)}

Logs (last 30 min): {str(context['logs'][:4000])}
Recent Deployments: {json.dumps(context['recent_deployments'])}
Dependency Health: {json.dumps(context['dependency_health'])}

Рассмотрите:
1. Deployment корреляция (совпадение timing с началом ошибки)
2. Каскадирующийся отказ из зависимости
3. Истощение ресурса (память/диск/соединения)
4. Всплеск трафика или DDoS
5. Изменение конфигурации

JSON output:
{{
    "probable_cause": "specific description",
    "confidence": 0.0-1.0,
    "evidence": ["deployment at 14:23 correlates", "OOM in logs"],
    "recommended_actions": ["rollback v1.2.3", "scale to 10 replicas"],
    "requires_human": true/false,
    "estimated_resolution_minutes": 15
}}

Установите requires_human=true если confidence < 0.7 или действие затрагивает >10k пользователей."""

    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=2048,
        messages=[{"role": "user", "content": prompt}]
    )

    data = json.loads(response.content[0].text)
    return Diagnosis(**data)

Автоматический remediation (исполнение runbook-шагов):

async def auto_remediate(alert: Alert, diagnosis: Diagnosis) -> dict:
    actions_taken = []

    for action in diagnosis.recommended_actions:
        result = await execute_action(action, alert.service)
        actions_taken.append({
            "action": action,
            "result": result,
            "timestamp": datetime.now().isoformat()
        })

        # Проверьте разрешена ли проблема после каждого действия
        if await check_metrics_healthy(alert.service):
            return {
                "status": "remediated",
                "actions": actions_taken,
                "resolution_time_minutes": (datetime.now() - alert.timestamp).total_seconds() / 60
            }

    return {"status": "remediation_incomplete", "actions": actions_taken}

Эскалация с контекстом (создание PagerDuty инцидента):

async def escalate_to_human(alert: Alert, diagnosis: Diagnosis, context: dict):
    summary = f"""**Impact**: {alert.title}
**Probable Cause** ({diagnosis.confidence:.0%} confidence): {diagnosis.probable_cause}

**Evidence**:
{chr(10).join(f'- {e}' for e in diagnosis.evidence)}

**Recommended Actions**:
{chr(10).join(f'{i+1}. {a}' for i, a in enumerate(diagnosis.recommended_actions))}

**Recent Deployments**: {len(context['recent_deployments'])} in last 24h
Latest: {context['recent_deployments'][0] if context['recent_deployments'] else 'None'}

**Logs**: [View in Kibana](https://kibana.example.com/...)
**Metrics**: [View in Grafana](https://grafana.example.com/...)
"""

    incident = pagerduty_client.create_incident(
        title=f"[AI-Triaged] {alert.title}",
        severity=alert.severity.value,
        body=summary,
        custom_fields={
            "ai_diagnosis": diagnosis.probable_cause,
            "ai_confidence": str(diagnosis.confidence),
        }
    )

    # Also post to Slack
    slack_client.chat_postMessage(
        channel="#incidents",
        text=f"🚨 {alert.severity.value} Incident: {alert.title}",
        blocks=[
            {"type": "section", "text": {"type": "mrkdwn", "text": summary}},
            {"type": "actions", "elements": [
                {"type": "button", "text": {"type": "plain_text", "text": "View in PagerDuty"}, "url": incident.html_url}
            ]}
        ]
    )

CI/CD Pipeline Agent

Pipeline decision logic (интеллектуальный выбор stage'ов):

from dataclasses import dataclass

@dataclass
class PipelineDecision:
    should_run: bool
    pipeline_config: str  # "full", "targeted", "minimal"
    rationale: str
    estimated_duration_minutes: int
    skip_stages: list[str]

def analyze_changeset(changed_files: list[str], branch: str, commit_msg: str) -> PipelineDecision:
    # Map файлов на затронутые сервисы
    affected = set()
    for file in changed_files:
        if file.startswith("services/payment/"):
            affected.add("payment-service")
        elif file.startswith("services/auth/"):
            affected.add("auth-service")
        elif file.startswith("docs/"):
            affected.add("docs-only")

    prompt = f"""Решите какие CI/CD stage'ы запустить.

Changed files: {', '.join(changed_files[:20])}
Affected services: {', '.join(affected)}
Branch: {branch}
Commit: {commit_msg}

Доступные pipeline stage'ы:
- unit-tests: 3 мин, per-service
- integration-tests: 12 мин, требует running сервисов
- security-scan: 8 мин, SAST/dependency check
- performance-tests: 25 мин, только для payment/auth/api изменений
- e2e-tests: 20 мин, full stack

JSON output:
{{
    "should_run": true,
    "pipeline_config": "full|targeted|minimal",
    "skip_stages": ["performance-tests", "e2e-tests"],
    "estimated_duration_minutes": 23,
    "rationale": "Skip perf tests - only docs changed"
}}

Правила:
- docs-only изменения: пропустите e2e-tests, performance-tests
- payment/auth изменения: запустите ВСЕ stage'ы включая performance-tests
- infrastructure изменения: запустите full конвейер"""

    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

    data = json.loads(response.content[0].text)
    return PipelineDecision(**data)

GitHub Actions интеграция (workflow_dispatch с динамической матрицей):

# .github/workflows/ai-pipeline.yml
name: AI-Orchestrated CI/CD

on:
  push:
    branches: [main, 'release/**']
  pull_request:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        type: choice
        options: [dev, staging, production]

permissions:
  id-token: write  # For OIDC token
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    outputs:
      pipeline_config: ${{ steps.decide.outputs.config }}
      skip_stages: ${{ steps.decide.outputs.skip }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changes
        run: |
          git diff --name-only ${{ github.event.before }}..${{ github.sha }} > changed.txt
          echo "files=$(cat changed.txt | tr '\n' ',')" >> $GITHUB_OUTPUT

      - name: AI Pipeline Decision
        id: decide
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python3 .github/scripts/pipeline_decision.py \
            --files changed.txt \
            --branch ${{ github.ref_name }} \
            --output decision.json

          echo "config=$(jq -r .pipeline_config decision.json)" >> $GITHUB_OUTPUT
          echo "skip=$(jq -r '.skip_stages | join(",")' decision.json)" >> $GITHUB_OUTPUT

Диагностика отказа теста (категоризируйте и предложите fix):

def diagnose_test_failure(service: str, test_output: str) -> dict:
    prompt = f"""Диагностируйте CI/CD test отказ для {service}.

Test output:

{test_output[:8000]}

Предоставьте JSON:
{{
    "root_cause": "specific error description",
    "category": "compilation|test-logic|dependency|environment|flaky",
    "fix_suggestion": "specific code/config change",
    "is_flaky": true/false,
    "flaky_reasoning": "test passed in previous 3 runs, timeout-based",
    "priority": "block-merge|warn-only|ignore"
}}

Category определения:
- compilation: syntax error, type error, import error
- test-logic: assertion failure, wrong expected value
- dependency: missing package, version mismatch, network timeout
- environment: missing env var, wrong filesystem path
- flaky: non-deterministic, timeout-based, race condition"""

    response = client.messages.create(
        model="claude-sonnet-4-0",  # Более быстрая модель для quick triаж
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

    return json.loads(response.content[0].text)

Auto-revert решение (откатитесь на регрессии):

def should_auto_revert(test_failures: list[dict], deployment_info: dict) -> bool:
    """Решите если deployment должен быть auto-reverted на основе test отказов."""

    # Никогда не auto-revert если flaky тесты
    if all(f["is_flaky"] for f in test_failures):
        return False

    # Auto-revert если любые block-merge отказы
    if any(f["priority"] == "block-merge" for f in test_failures):
        return True

    # Auto-revert если error rate увеличился >10% post-deployment
    if deployment_info.get("error_rate_increase", 0) > 0.10:
        return True

    return False

On-Call маршрутизация

PagerDuty интеграция (Events API v2):

import httpx

PAGERDUTY_EVENTS_URL = "https://events.pagerduty.com/v2/enqueue"

def create_pagerduty_incident(alert: Alert, diagnosis: dict):
    payload = {
        "routing_key": "YOUR_INTEGRATION_KEY",
        "event_action": "trigger",
        "payload": {
            "summary": f"{alert.title} - {diagnosis['probable_cause']}",
            "severity": alert.severity.value.lower(),  # p1 → critical
            "source": alert.service,
            "custom_details": {
                "confidence": diagnosis["confidence"],
                "recommended_actions": diagnosis["recommended_actions"],
                "evidence": diagnosis["evidence"],
            }
        }
    }

    response = httpx.post(PAGERDUTY_EVENTS_URL, json=payload)
    return response.json()["dedup_key"]

Классификация severity (LLM определяет P-level):

def classify_incident_severity(alert_text: str, metrics: dict) -> IncidentSeverity:
    prompt = f"""Классифицируйте incident severity (P1/P2/P3/P4).

Alert: {alert_text}
Metrics: {json.dumps(metrics)}

Severity определения:
- P1: Complete service outage, data loss, security breach, >50% error rate
- P2: Major degradation, >10% error rate, critical feature down, <5% users affected
- P3: Minor degradation, <5% error rate, non-critical feature, workaround exists
- P4: Cosmetic issue, logging noise, no user impact

JSON: {{"severity": "P1|P2|P3|P4", "reasoning": "..."}}"""

    response = client.messages.create(
        model="claude-sonnet-4-0",
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}]
    )

    data = json.loads(response.content[0].text)
    return IncidentSeverity[data["severity"]]

Human escalation path (маршрутизируйте по severity и времени):

def determine_escalation_path(severity: IncidentSeverity, hour: int) -> list[str]:
    """Определите кого вызывать на основе severity и времени суток."""

    if severity == IncidentSeverity.P1:
        # Вызовите несколько людей немедленно для P1
        return ["oncall-primary", "oncall-secondary", "team-lead"]
    elif severity == IncidentSeverity.P2:
        # Вызовите primary, эскалируйте secondary после 15 мин
        return ["oncall-primary"]
    elif severity == IncidentSeverity.P3:
        # Вызовите только в рабочие часы
        if 9 <= hour <= 17:
            return ["oncall-primary"]
        else:
            return []  # Создайте инцидент но не вызывайте
    else:  # P4
        return []  # Создайте тикет, без вызова

Производительность и benchmark'и

Примечание: Приведённые ниже цифры являются иллюстративными оценками на основе типичных production-конфигураций, а не измерениями конкретной системы.

Agent response latency:

• Context gathering (параллельные запросы логов/метрик): 2-5 секунд
• LLM диагностика (Claude Opus, 8K токенов): 8-15 секунд
• Общее время incident triаж: 15-25 секунд (vs 15-20 минут вручную)
• Auto-remediation исполнение: 30-90 секунд (зависит от действия: перезагрузка сервиса vs масштабирование deployment)

Анализ стоимости (за инцидент):

• Context gathering (без LLM): $0
• Diagnosis prompt (~6K input, 1K output): ~$0.20 с Claude Opus
• Follow-up рассуждение (если требуется): ~$0.10
• Итого за P2 инцидент: ~$0.30 (vs $150 возможность стоимости инженера за 20 мин ручной triаж)

Пропускная способность:

• Single agent инстанс: 10-15 инцидентов в минуту (параллельное context gathering, sequential LLM calls)
• Bottleneck: LLM API rate limit'ы (Anthropic: 4000 запросов/мин на tier 4)
• Горизонтальное масштабирование: Запустите несколько agent replica'ы с shared state в Redis/Postgres

Точность (на основе типичных production agent deployment'ов):

• Incident severity классификация: Правильно классифицирует P1 vs P2 в большинстве случаев, имеет тенденцию over-escalate edge case'ы (более безопасный default)
• Root cause диагностика: Определяет вероятную root cause для common failure mode'ов (deployment регрессия, истощение ресурса, отказ зависимости)
• Auto-remediation успех: Успешно разрешает инциденты matching известным runbook pattern'ам без human вмешательства в типичных случаях

Потребление ресурса:

• Agent сервис: 512MB RAM, 0.5 CPU baseline, 2 CPU под нагрузкой
• Log хранилище для контекста: 50MB за инцидент (30 мин фильтрованных логов)
• Metric хранилище: 5MB за инцидент (1 час time-series данных)

Экономия времени (за type инцидента):

• P1 инцидент с auto-remediation: 15-20 минут сэкономлено (agent triаж + исполнение runbook vs вручную)
• P2 инцидент с diagnostic контекстом: 10-15 минут сэкономлено (agent pre-собирает весь контекст)
• Pipeline отказ диагностика: 5-10 минут сэкономлено (agent категоризирует ошибку, предлагает fix)
• Post-mortem генерация: 2-3 часа сэкономлено (agent draft'ит из timeline данных)

Reliability метрики:

• Agent uptime requirement: 99.9% (более критична чем большинство сервисов - обрабатывает все инциденты)
• Circuit breaker activation rate: Design для <1% инцидентов (agent падает и эскалирует)
• False positive rate (agent remediate'ит неправильное): Target <0.1% (опасно, реализуйте approval gate'ы)
• Escalation rate: 30-40% инцидентов эскалируются человеку (agent устанавливает requires_human=true или hit confidence threshold)