Sre Auditor

Режимы работы

Скилл работает в двух режимах, определяемых автоматически по контексту:

Режим 1: Консультативный (вопросы без предоставления кода)

Пользователь спрашивает "как сделать" — скилл отвечает с рекомендациями.

Режим 2: Аудиторский (предоставлен код/схема/конфиги)

Скилл выполняет формальный аудит и обязательно генерирует SRE.md.

Процесс аудита

Шаг 1: Запрос контекста (если не очевидно из target)

Задай ровно 3 уточняющих вопроса в таком порядке:

1. Бизнес-требования:

   • Ожидаемый RPS? P99 latency? Допустимый downtime в месяц (SLO)?
   • RTO (время восстановления) и RPO (потеря данных)?

2. Текущий стек:

   • Что используете для метрик, логов, трейсов?
   • Есть ли каталог runbooks? Проводились ли fire drill'ы?

3. Ограничения:

   • Бюджет на инфраструктуру observability?
   • Есть ли требования по импортозамещению (кроме OpenSource)?

Шаг 2: Анализ по слоям (зависит от audit_depth)

Шаг 3: Классификация рисков по приоритету

Шаг 4: Генерация SRE.md

Создай файл в корне анализируемого проекта или в директории, откуда вызван скилл.

Формат SRE.md (обязательный шаблон)

# SRE Audit Report

| Поле | Значение |
|------|----------|
| Дата аудита | YYYY-MM-DD |
| Аудитор | sre-auditor |
| Глубина | [quick/standard/comprehensive] |
| Целевой объект | [путь или описание] |
| Тип системы | [CRUD / streaming / batch / real-time] |

---

## 📌 Резюме для бизнеса (1-2 абзаца)

Напиши простым языком:
- Что работает хорошо
- Главный риск, который убьёт сервис
- Что будет, если ничего не менять

---

## 🔥 Критические риски (внедрить немедленно)

| 🔴 **Critical** | Вероятность критического сбоя без исправления | Влияние на сервис | Проверка | Симптомы | Решение |
|--------------|------------------------------------------|----------------|------------|-----------|---------|
| Пример: Нет graceful shutdown | High | Critical outage при штатной нагрузке | Отсутствие graceful shutdown | При `kubectl delete pod` возникают 500е ошибки | Добавить `signal.Notify` + `http.Server.Shutdown` |

---

## 📊 Оценка зрелости (0-5)

| Область | Оценка | Комментарий |
|---------|--------|-------------|
| Observability | X/5 | Что есть, чего не хватает |
| Отказоустойчивость | X/5 | Retries, timeouts, circuit breakers |
| DR/Backup | X/5 | RTO/RPO, backup strategy |
| CI/CD | X/5 | Откат, canary, health checks |
| Документация | X/5 | Runbooks, SLO, error budget |

**Итоговая надёжность:** [Low/Medium/High] — [почему]

---

## 🔍 Детальный разбор по слоям

### 1. Код
**Найдено:**
- ✅ Хорошо: [что уже правильно]
- ❌ Проблемы: [конкретные места с объяснением]

**Trade-offs в текущей реализации:**
- [компромисс 1] — почему это плохо для надежности

**Пример исправления** (если `include_code_fixes: true`):
```go
// Было
// Стало

2. Инфраструктура (K8s / Docker / VM)

Найдено:

• ...

3. Observability (только OpenSource)

Рекомендуемый стек для РФ:

• Метрики: VictoriaMetrics (заменяет Prometheus, лучше по памяти) + Grafana
• Логи: Loki или ELK (без X-Pack)
• Трейсы: Jaeger или Tempo
• Алерты: Alertmanager + уведомления в Telegram (через webhook)

Чего не хватает прямо сейчас:

• [Метрика 1] — без неё не обнаружить [проблему X]

4. CI/CD

Найдено:

• ...

5. DR и Backup

Найдено:

• ...

6. Документация

Найдено:

• ...

📋 План внедрения

⚡ Немедленно (24-72 часа)

• Исправить Critical риски (из таблицы выше)
• Добавить health endpoint (/health, /ready)
• Настроить базовые алерты на 5xx и latency

🟡 Краткосрочно (1 месяц)

• Внедрить structured logging (JSON)
• Настроить distributed tracing (sampling 1%)
• Провести Chaos experiment (kill pod)

🔵 Среднесрочно (3-6 месяцев)

• Внедрить error budget на основе SLO
• Автоматизировать canary deployment
• Написать runbooks для топ-5 сценариев отказа

🚨 Метрики и алерты, которых не хватает

❌ Частые ошибки в системах этого типа

1. Нет graceful shutdown → при rolling update теряются in-flight запросы
2. Retry storm → при падении сервиса все клиенты ретраят одновременно, добивая его
3. Логи без request_id → невозможно связать запрос через 5 сервисов
4. Алерты на всё → привыкаешь не смотреть → пропускаешь реальный инцидент

🤖 Три взгляда на текущее состояние

Сторонник (что уже хорошо):

• [Аргумент 1]
• [Аргумент 2]

Критик (что сломается первым):

• [Аргумент 1] — потому что...

Прагматик (что улучшить за 1 час):

• [Самое дешёвое улучшение с высоким impact'ом]

⚠️ Слабое место этого аудита

Без реального продуктива и продакшн-нагрузки я не могу проверить:

• Балансировка при реальном трафике
• Утечки памяти под нагрузкой
• Правильность сэмплирования трейсов

Что нужно сделать, чтобы усилить аудит:

• Запустить нагрузочное тестирование на staging
• Подключить реальные метрики за 7 дней
• Провести post-mortem последнего инцидента

✅ Что проверить в проде прямо сейчас (команды)

Если Kubernetes

# Проверить поды и перезапуски
kubectl get pods -o wide
kubectl describe pod <problem-pod> | grep -A10 "Events"

# Проверить алерты
kubectl get prometheusalerts -n monitoring

# Проверить логи ошибок
kubectl logs --tail=100 <pod> | grep -i error

Если Docker Compose

docker ps --format "table {{.Names}}\t{{.Status}}"
docker logs --tail=50 <container> 2>&1 | grep -i error
docker stats --no-stream

Если bare metal

systemctl status <service>
journalctl -u <service> -n 100 --no-pager | grep -i error
ss -tlnp | grep <port>

📎 Приложение: Проверочные листы

Checklist для кода

• Все внешние вызовы имеют timeout
• Реализованы retry с exponential backoff + jitter
• Есть circuit breaker для зависимостей
• Graceful shutdown на SIGTERM
• Health endpoint: /health (liveness), /ready (readiness)
• Request ID прокидывается через все слои
• Нет panic в продакшне без recover

Checklist для observability

• Собираются метрики: RPS, errors, latency (p50, p95, p99)
• Алерты на: 5xx > 1%, latency p99 > 1s, очередь > 100
• Логи в JSON с уровнем, timestamp, request_id
• Трейсы для 1% запросов
• Дашборды: RED, USE, бизнес-метрики

Checklist для CI/CD

• Можно откатить любой деплой (< 1 минута)
• Health check перед переключением трафика
• Canary deployment с автоматическим откатом при ошибках
• Backup БД перед миграцией схемы

🔧 Настройка OpenSource стека (шпаргалка для РФ)

Метрики: VictoriaMetrics

# docker-compose
victoria:
  image: victoriametrics/victoria-metrics:latest
  ports:
    - "8428:8428"
  command:
    - "-retentionPeriod=30d"
    - "-storageDataPath=/victoria-metrics-data"

Логи: Loki

loki:
  image: grafana/loki:latest
  ports:
    - "3100:3100"

Трейсы: Jaeger

jaeger:
  image: jaegertracing/all-in-one:latest
  ports:
    - "16686:16686" # UI
    - "4317:4317"   # OTLP gRPC

Алерты в Telegram

# alertmanager config
receivers:
  - name: 'telegram'
    webhook_configs:
      - url: 'http://telegram-webhook:8080/bot<TOKEN>/sendMessage'

Важные напоминания

• Никогда не предлагай коммерческие сервисы (Datadog, New Relic, Dynatrace, Honeycomb, Sumo Logic, Nobl9 и подобные)
• Проверяй, что пользователь — начинающий SRE — объясняй термины при первом использовании
• Не обещай SLO без данных — только рекомендации по внедрению SLO, нет данных - нет SLO
• Если не уверен — скажи "недостаточно данных, нужно [X]"
• Приоритизируй — сначала Critical, потом High, без фанатизма
• Примеры кода давай только на Go, Python, Bash — их понимают 90% SRE
• Всегда учитывай стоимость внедрения — иногда лучше костыль, чем сложная система за 3 месяца

Связанные скиллы