⚙️ Управление инфраструктурной командой 24/7

    P0 — CRITICAL (Catastrophic)
  Определение: Полная недоступность продукта или потеря данных
  Примеры:   Сайт/приложение полностью недоступны
              Потеря production данных
              Утечка персональных данных пользователей
  SLA:       Отклик: немедленно (разбудить если надо)
              Начало работ: в течение 15 минут
              Эскалация: вышестоящие руководители уведомляются автоматически
  Команда:   тим лид + все доступные инженеры

P1 — HIGH (Major)
  Определение: Критическая функциональность недоступна для значительной части пользователей
  Примеры:   Платежи не проходят
              Авторизация не работает для 30%+ пользователей
              Потеря данных в неосновном сервисе
  SLA:       Отклик: 15 минут (24/7)
              Начало работ: в течение 30 минут
              Эскалация: Engineering Manager
  Команда:   On-call Engineer + тим лид при необходимости

P2 — MEDIUM (Degradation)
  Определение: Деградация производительности или частичная недоступность
  Примеры:   Высокая latency (>5x от нормы)
              Отдельные функции не работают
              Ошибки для <10% пользователей
  SLA:       Отклик: 30 минут (рабочие часы), 1 час (нерабочие)
              Решение: в течение 4 часов
  Команда:   On-call Engineer

P3 — LOW (Minor)
  Определение: Незначительные проблемы без влияния на пользователей
  Примеры:   Ошибки в логах которые не влияют на поведение
              Неработающие дашборды мониторинга
              Деградация в staging окружении
  SLA:       Отклик: следующий рабочий день
              Решение: в течение 1 недели
  Команда:   Текущий дежурный по расписанию
    

Lifecycle инцидента

                  ALERT (автоматический или ручной)
                                    │
                                    ▼
              DETECTION — Инцидент замечен
              Кто: дежурная смена / On-call
              Действие: создать тикет, назначить severity
                                    │
                                    ▼
              TRIAGE — Первичная оценка (5-15 мин)
              Кто: прикладной инженер
              Действие: подтвердить инцидент, назначить команду
                               │
                       ┌───────┴───┐
                       │           │
                       ▼           ▼
                 ESCALATE         MITIGATE
                (если нужно)     (устранить симптом быстро)
                Позвонить L3     Rollback, feature flag off,
                Позвонить DBA    scale up, failover
                     │                │
                     └───────┬────────┘
                             │
                             ▼
              RESOLVE — Проблема устранена
              Действие: закрыть инцидент, уведомить
                                    │
                                    ▼
              POST-MORTEM — Разбор (в течение 48-72 часов)
              Действие: написать документ, определить action items
    

Post-mortem без виноватых

# Post-Mortem: Payment Service Degradation
Date: 2024-06-15
Severity: P1
Duration: 1 hour 13 minutes
Impact: ~8,000 users affected, ~450 failed transactions
Authors: Maria Kozlova, Ivan Petrov
Reviewed by: Fedor Sidorov

## Summary
Деградация платёжного сервиса вызванная отсутствующим индексом на таблице
payments, привела к накоплению slow queries и истощению connection pool к PostgreSQL.

## Timeline (UTC)
| Time  | Event                                                          |
|-------|----------------------------------------------------------------|
| 18:30 | Деплой v2.1.3 с новым запросом по полю created_at              |
| 18:32 | Алерт: p99 latency > 2s (порог алерта)                         |
| 18:33 | NOC создаёт инцидент INC-2847, назначает P1                    |
| 18:35 | On-call Maria Kozlova получает PagerDuty                       |
| 18:40 | Maria подтверждает корреляцию с деплоем                        |
| 18:45 | Решение НЕ делать rollback (деплой содержал критический bugfix)|
| 19:15 | Ivan Petrov находит slow query                                 |
| 19:30 | Индекс добавлен online (CREATE INDEX CONCURRENTLY)             |
| 19:45 | Метрики вернулись в норму, инцидент закрыт                     |

## Root Cause
Новый SQL запрос `SELECT * FROM payments WHERE created_at > $1`
не имел индекса по полю created_at. При таблице 50M строк запрос
занимал 3-8 секунд, что привело к накоплению соединений в pool.

## Contributing Factors
1. Отсутствие обязательного EXPLAIN ANALYZE в процессе code review для SQL
2. Staging БД содержит только 10,000 строк (vs 50M в prod)
   → проблема не воспроизводилась на staging
3. Алерт на connection pool не был настроен (обнаружили только по latency)

## What Went Well ✓
- Быстрое обнаружение (2 минуты после начала проблемы)
- Правильное решение не делать rollback (bugfix был критичным)
- CREATE INDEX CONCURRENTLY не заблокировал таблицу

## What Went Poorly ✗
- 45 минут от инцидента до root cause (долго искали причину)
- Отсутствие runbook для DB performance incidents
- Staging не отражает production масштаб данных

## Action Items
| Action                                                    | Owner    |  Due Date  | Priority |
|-----------------------------------------------------------|----------|------------|----------|
| Добавить EXPLAIN ANALYZE в PR checklist для SQL изменений | Maria K. | 2024-06-22 | P1       |
| Настроить алерт на DB connection pool utilization > 80%   | Ivan P.  | 2024-06-20 | P1       |
| Написать runbook: PostgreSQL performance degradation      | Maria K. | 2024-06-28 | P2       |
| Заполнить staging БД репрезентативным объёмом данных      | Platform | 2024-07-05 | P2       |
| Добавить synthetic query benchmark в CI                   | Platform | 2024-07-12 | P3       |

## Lessons Learned
Проблемы с производительностью запросов часто невидимы на staging
из-за разницы в объёме данных. Нужны либо performance tests с
production-scale данными (анонимизированными), либо обязательный
код-ревью SQL с анализом query plan.
    

4. Инструменты мониторинга и алертинга

Три столпа observability: METRICS (Prometheus+Grafana), LOGS (ELK/Loki), TRACES (Jaeger/Tempo). Четыре золотых сигнала: 1. LATENCY — время выполнения запроса Метрики: p50, p95, p99, p999 Важно различать: успешные запросы vs ошибки (ошибки могут быть быстрыми) 2. TRAFFIC — нагрузка на систему Метрики: requests/sec, transactions/sec, active users Нужен для понимания масштаба проблемы и capacity planning 3. ERRORS — доля ошибочных запросов Метрики: error rate (%), абсолютное количество ошибок Различать: явные ошибки (5xx) и неявные (200 с неправильным ответом) 4. SATURATION — насколько система заполнена Метрики: CPU %, memory %, disk I/O, DB connection pool % Saturation предсказывает будущие проблемы — самый важный для prevention

 
┌─────────────────────────────────────────────────────────┐
│                    Observability                        │
│                                                         │
│  METRICS              LOGS               TRACES         │
│  (что происходит)     (почему)           (где именно)   │
│                                                         │
│  Prometheus           Elasticsearch      Jaeger         │
│  VictoriaMetrics      Loki               Tempo          │
│  Grafana              Grafana Logs       Zipkin         │
│  InfluxDB             Splunk             AWS X-Ray      │
│                       Datadog            Honeycomb      │
└─────────────────────────────────────────────────────────┘
     

Правила хорошего алерта

Алерт должен требовать человеческого действия.
Если на алерт нет действия — его нужно убрать или понизить до info.

ПЛОХОЙ алерт:
  "CPU > 70% на prod-web-01"
  → Почему 70%? Это нормально для этого сервиса?
  → Что должен сделать дежурный?
  → Скорее всего — посмотреть и закрыть → alert fatigue

ХОРОШИЙ алерт:
  "Payment service p99 > 2s (текущее: 4.3s), error rate 2.1%"
  → Ясная проблема с измеримым влиянием
  → Есть ссылка на runbook с конкретными шагами
  → Дежурный знает что делать

Правила для алертов:
  ✓ Каждый алерт — это страница в ночи. Заслуживает ли он этого?
  ✓ Каждый алерт должен иметь runbook
  ✓ Алерты должны быть actionable (есть что сделать)
  ✓ Нет алертов без SLO нарушения — измеряем влияние на пользователя
  ✗ Нет алертов на «что-то не нравится»
  ✗ Нет дублирующих алертов об одном и том же

AlertManager: маршрутизация алертов

# alertmanager.yml
route:
  group_by: ['alertname', 'service']
  group_wait: 30s          # Ждём 30с перед отправкой группы (агрегация)
  group_interval: 5m       # Обновления существующей группы
  repeat_interval: 4h      # Повтор нерешённого алерта
  receiver: default

  routes:
    # P0/P1 — немедленно в PagerDuty + slack/telegram / аналоги
    - match:
        severity: P0
      receiver: pagerduty-critical
      repeat_interval: 15m    # Напоминать каждые 15 мин пока не решено

    - match:
        severity: P1
      receiver: pagerduty-high
      repeat_interval: 30m

    # P2 — только Slack, в рабочие часы
    - match:
        severity: P2
      receiver: slack-ops
      active_time_intervals:
        - business_hours

    # P2 вне рабочего времени — PagerDuty с меньшим приоритетом
    - match:
        severity: P2
      receiver: pagerduty-low

receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - service_key: ''
        severity: critical
        # Эскалация через 10 минут если нет acknowledgement
        escalation_policy: immediate-escalation

  - name: slack-ops
    slack_configs:
      - channel: '#alerts-ops'
        title: '{{ .GroupLabels.alertname }}'
        text: |
          {{ range .Alerts }}
          *Alert:* {{ .Annotations.summary }}
          *Severity:* {{ .Labels.severity }}
          *Runbook:* {{ .Annotations.runbook }}
          {{ end }}
        send_resolved: true

time_intervals:
  - name: business_hours
    time_intervals:
      - weekdays: ['monday:friday']
        times:
          - start_time: '09:00'
            end_time: '18:00'
         

5. On-call ротация и burnout

Принципы: равное распределение, парное дежурство (primary+secondary), освобождение после тяжёлой ночи. Ключевые метрики: MTTA, MTTR, alerts per shift, sleep disruptions. Борьба с alert fatigue — аудит алертов раз в квартал.

MTTA (Mean Time To Acknowledge):
  Сколько времени проходит от алерта до подтверждения
  Норма: < 10 минут для P1
  Если > 10 мин регулярно → человек перегружен или не спит

MTTR (Mean Time To Resolve):
  Сколько времени от инцидента до решения
  Норма: P1 < 4 часа, P2 < 24 часа

Alerts per on-call shift:
  Сколько алертов приходит за дежурство
  Норма: < 5 actionable алертов за смену
  Если > 10 → alert fatigue, надо разбираться

Repeat incidents:
  Инциденты повторяющиеся по одной и той же причине
  Каждый повтор → action item не выполнен → нужно исправить

Sleep disruptions per week:
  Сколько раз инженер был поднят ночью
  Норма: < 2 ночи подряд
  > 2 ночей подряд → немедленная замена + расследование причины
         

Борьба с alert fatigue

Alert fatigue — состояние когда инженер игнорирует алерты
из-за их большого количества или низкого сигнал/шум отношения.
Это ОПАСНО — пропускаются реальные проблемы.

Признаки alert fatigue:
  □ Алерты закрываются без анализа
  □ MTTA растёт
  □ Инженеры жалуются на «слишком много шума»
  □ Реальный инцидент обнаруживается позже алерта

Решение:
  1. Аудит алертов раз в квартал
     Для каждого алерта: «Что мы сделали последний раз когда он сработал?»
     Если ответ «ничего» — удалить или понизить severity

  2. Error budget алертов
     Цель: 0 ложных срабатываний P1/P2 в неделю
     Каждое ложное срабатывание — это incident review

  3. Алерты на симптомы, не причины
     Не: «CPU > 80%»
     Да: «Payment latency > 2s» (которое МОЖЕТ быть вызвано CPU)
         

6. Взаимодействие Dev, DevOps и Ops

Runbook — мост между Ops и разработкой. Примеры пошаговых инструкций. Принцип You build it, you run it (разработчики участвуют в on-call). Модели организации: Centralized Platform Team vs Embedded DevOps.

                Dev Team         Platform/DevOps       Ops/NOC
                    │                   │                  │
Разработка:  ███████████          ████████              ░░░░░░
Пайплайны:   ███░░░░░░░░          ████████              ░░░░░░
Деплой:      ████░░░░░░░          ████████              ████░░
Мониторинг:  ████░░░░░░░          ████████              ████░░
Инциденты:   ░░░████░░░░          ███░░░░░░             ██████

███ = основная ответственность
████ = участвует
░░░░ = не участвует
         

Пример ранбука

      
         
# Runbook: Payment Service High Latency

**Применять при:** Алерт PaymentHighLatency (p99 > 2s)
**Severity:** P1 если > 5s, P2 если 2-5s
**Время выполнения:** ~15-30 минут
**Написан:** Ivan Petrov, 2024-06-10
**Последнее обновление:** 2024-06-16 (после инцидента INC-2847)

---

## Шаг 1: Подтвердить проблему (2 мин)

Открыть дашборд: https://grafana/d/payment-service

Проверить:
- [ ] p99 latency действительно высокая (не аномалия в метриках)
- [ ] Какой процент запросов затронут (top-right: "Request Success Rate")
- [ ] Когда началось (сравнить с графиком деплоев)

Если всё нормально → false alarm, закрыть алерт с комментарием.

## Шаг 2: Проверить корреляцию с деплоями (3 мин)

```bash
# Последние деплои payment service
kubectl rollout history deployment/payment-service -n production
```

Если деплой был < 30 мин назад → рассмотреть rollback (перейти к Шагу 6).

## Шаг 3: Проверить базу данных (5 мин)

Grafana → Dashboard "PostgreSQL Overview"

Смотрим:
- [ ] Active connections (норма: < 80 из 150 max)
- [ ] Query duration (норма: p99 < 100ms)
- [ ] Lock waits (должно быть 0 или единицы)

Если connections > 120:
```bash
# Посмотреть активные запросы
psql -h $DB_HOST -U $DB_USER -d $DB_NAME << 'SQL'
SELECT pid, state, query_start,
       EXTRACT(EPOCH FROM (now() - query_start)) as duration_sec,
       LEFT(query, 100) as query_preview
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration_sec DESC
LIMIT 20;
SQL
```

Если есть запросы > 5 секунд → это причина. Записать в инцидент и эскалировать к L3/DBA.

## Шаг 4: Проверить downstream зависимости (3 мин)

Payment service зависит от:
- Stripe API: https://status.stripe.com
- Internal Auth service: Grafana → Dashboard "Auth Service"
- Redis cache: Grafana → Dashboard "Redis"

Если внешний сервис деградирует → это причина. Включить circuit breaker:
```bash
kubectl set env deployment/payment-service \
  STRIPE_CIRCUIT_BREAKER=enabled -n production
```

## Шаг 5: Быстрое исправление — масштабирование (если нет DB проблемы)

```bash
# Увеличить количество подов (если CPU bottleneck)
kubectl scale deployment payment-service --replicas=8 -n production
# Норма: 3 пода, максимум безопасный: 12

# Подождать 2-3 минуты и проверить метрики
```

## Шаг 6: Rollback (если причина — недавний деплой)

```bash
# ТОЛЬКО после согласования с Release Manager или Engineering Manager
kubectl rollout undo deployment/payment-service -n production
kubectl rollout status deployment/payment-service -n production
```

## Шаг 7: Эскалация

Если через 15 минут нет улучшения → звонить On-call L3:
- Имя: {current_oncall_l3} (смотреть в PagerDuty)
- Передать: время начала, что проверили, что попробовали, текущие метрики

## Шаг 8: После решения

- [ ] Убедиться что метрики вернулись в норму (p99 < 300ms)
- [ ] Записать в инцидент: что было сделано и что помогло
- [ ] Если делали rollback → создать задачу разработчикам в Jira
- [ ] Если масштабировались → вернуть к норме через 2 часа
         

You Build It, You Run It

Принцип: разработчики несут ответственность за работу своего кода в production. Это:
- Мотивирует писать надёжный код
- Ускоряет решение инцидентов (разработчик знает свой код)
- Снижает нагрузку на отдельную Ops команду

Реализация:
  Dev Team получает on-call ротацию для своих сервисов
  Платформа обеспечивает инструменты (мониторинг, деплой, runbooks)
  Ops (L1/L2) остаются как первая линия — фильтр и эскалация

Постепенный переход (если команда не готова):
  Месяц 1-2: Dev team в shadow режиме при инцидентах своих сервисов
  Месяц 3-4: Dev team primary on-call, Ops secondary
  Месяц 5+:  Dev team полностью несёт on-call своих сервисов
                  

7. Процессы и ритмы команды

Еженедельный ритм: Weekly sync, Architecture Review, Post-mortem review, On-call review. Quarterly Business Review (SLO, инциденты, здоровье команды). Change Management: freeze периоды, Change Advisory Board для высокорисковых изменений, maintenance window.

Еженедельный ритм

```
Понедельник:
  10:00 — Weekly team sync (30 мин)
    • Прошедшая неделя: инциденты, метрики, что сделано
    • Текущая неделя: приоритеты, блокеры, on-call передача
    • Риски: что может сломаться на этой неделе

  После встречи: обновление on-call расписания в PagerDuty

Среда:
  14:00 — Architecture / Tech Review (по необходимости, 60 мин)
    • RFC (Request for Comment) по значимым изменениям
    • Ревью крупных PR перед мержем
    • Обсуждение технического долга

Пятница:
  15:00 — Post-mortem review (если были P1/P2 за неделю)
  16:00 — On-call review: алерты за неделю, action items

8. Документация и knowledge base

Структура: Runbooks, Architecture (ADR), On-Call Guide, Post-Mortems. ADR (Architecture Decision Record) фиксирует почему выбрано решение. Обязательный минимум для сервиса: README, диаграмма, runbook, алерты, дашборд, on-call ротация.

Инфраструктурная база знаний
│
├── 📂 Runbooks
│   ├── Application Runbooks
│   │   ├── payment-high-latency.md
│   │   ├── auth-service-down.md
│   │   └── ...
│   ├── Database Runbooks
│   │   ├── postgres-connection-pool-exhausted.md
│   │   ├── redis-memory-high.md
│   │   └── ...
│   └── Infrastructure Runbooks
│       ├── kubernetes-node-not-ready.md
│       ├── disk-space-full.md
│       └── ...
│
├── 📂 Architecture
│   ├── System Overview (C4 диаграммы)
│   ├── Network Topology
│   ├── Data Flow Diagrams
│   └── Technology Decisions (ADR)
│
├── 📂 On-Call Guide
│   ├── Getting Started (новому дежурному)
│   ├── Escalation Matrix
│   ├── Contacts & Phones
│   └── Emergency Procedures
│
├── 📂 Processes
│   ├── Incident Management Process
│   ├── Change Management Process
│   ├── Deployment Process
│   └── On-Call Rotation Policy
│
└── 📂 Post-Mortems
    ├── 2024/
    │   ├── 2024-06-15-payment-degradation.md
    │   └── ...
    └── Retrospective Summaries

9. SLO/SLA/SLI — договор с бизнесом

SLI (метрика) → SLO (цель) → SLA (юридическое соглашение). Error Budget = допустимый downtime. Оставшийся бюджет определяет, можно ли рисковать новыми деплоями.

Сервис не уходит в эксплуатацию без:


□ README: как запустить локально, переменные окружения
□ Architecture diagram: зависимости сервиса (что вызывает, что вызывает его)
□ Runbook: минимум 3 самых вероятных проблемы
□ Alerts: настроены с ссылкой на runbook
□ Dashboard: есть Grafana дашборд с golden signals
□ On-call rotation: сервис добавлен в ротацию разработчиков

10. Инструменты управления командой

ChatOps примеры

/deploy payment-service v2.1.4 production
/rollback payment-service production
/oncall who
/incident create P1 "Payment service not responding"

тасктрекер для инфраструктурной команды

Проекты:
  INFRA — инфраструктурные задачи и улучшения
  OPS — операционные задачи (не инциденты)
  INC — инциденты (часто автоматически создаются)

Типы задач в INFRA:
  Epic: "Migrate to Kubernetes 1.29" (несколько недель)
  Story: "Update node pools to Ubuntu 22.04" (дни)
  Task: "Test upgrade on staging cluster" (часы)
  Bug: "k8s node randomly evicting pods"

Кастомные поля для инфраструктурных задач:
  Affected Services: [payment, auth, api-gateway]
  Environments: [staging, production]
  Risk Level: [low, medium, high, critical]
  Runbook Required: [yes/no]

Связь с инцидентами:
  Каждый P1/P2 инцидент автоматически создаёт INC задачу
  Из INC задачи линкуются action items в INFRA
  Прогресс по action items виден в ретроспективе

Sprint structure для инфраструктурной команды:
  Не классический 2-недельный спринт — мешает непредсказуемость инцидентов
  
  Рекомендуется: Kanban с WIP limits + planning раз в неделю
  WIP limit: не более 2 задач в In Progress на человека
  
  Резервирование capacity:
  30% времени → инциденты, on-call, оперативные задачи
  50% времени → плановые задачи из backlog
  20% времени → технический долг, обучение


Status Page: коммуникация с пользователями


Statuspage.io / Cachet пример обновлений:

Во время инцидента:
───────────────────
14:32 UTC | Investigating
We are aware of an issue affecting payment processing.
Payments may be slow or fail. We are investigating.
Impact: Partial outage — Payment Service
───────────────────
14:55 UTC | Identified
We have identified the root cause: database query performance.
Our team is working on a fix.
───────────────────
15:15 UTC | Monitoring
A fix has been applied. We are monitoring for full recovery.
Error rates returning to normal.
───────────────────
15:32 UTC | Resolved
This incident has been resolved.
Duration: 1 hour
Affected: ~15,000 users

A full post-mortem will be published within 72 hours.

11. Культура

Токсичные паттерны: «кто сломал» культура, alert storms, отсутствие отдыха.

Toil reduction — автоматизация рутины, цель SRE <50% toil. Принципы blameless, near-miss, безопасная эскалация.

One-on-one встречи раз в 1-2 недели.

Как измерить toil
Тикеты с тегом toil — считай еженедельно
Время на on-call: сколько алертов требовали ручного действия
Runbook с шагами «скопируй-запусти» — кандидат на автоматизацию

Near-miss — почти-инцидент: не сломалось, но могло. Ценнее реального инцидента, потому что бесплатный сигнал.
Как внедрить

Еженедельный 15-минутный «near-miss review» на стендапе
Анонимная форма для репортинга (люди боятся выглядеть некомпетентно)
KPI: количество near-miss репортов = хорошо, ноль репортов = культура страха
Каждый near-miss → issue в трекере с тегом near-miss, даже если action item «мониторить»

Правила безопасной эскалации
Для инженеров:

Эскалируй по времени, а не по уверенности: «Я разбираюсь уже N минут без прогресса» → эскалируй
    Runbook для эскалации:
    1. Попытка самостоятельного решения: 15 мин (SEV2) / 5 мин (SEV1)
    2. Ping on-call buddy
    3. Если нет ответа за 5 мин → следующий уровень
    4. Параллельно пишешь в инцидент-канал (не ждёшь решения)
Формула: «Я вижу X, я попробовал Y, нужна помощь» — никаких извинений
On-call handoff: передавай контекст письменно, не устно

Для тимлидов:

Публично благодари за раннюю эскалацию
Никогда не говори «зачем ты меня разбудил» — следующий раз не позвонят
SLA на эскалацию: если не отвечаешь за N минут → следующий уровень автоматически

12. Метрики эффективности команды

DORA метрики: Deployment Frequency, Lead Time for Changes, MTTR, Change Failure Rate. Примеры операционных отчётов: алерты за смену, false positive rate, toil часы. Team Health Check (Spotify-модель).

Четыре метрики которые коррелируют с высокоэффективными командами:


1. Deployment Frequency (как часто деплоим)
   Elite:   Несколько раз в день
   High:    Раз в день — раз в неделю
   Medium:  Раз в неделю — раз в месяц
   Low:     Раз в месяц и реже

2. Lead Time for Changes (от коммита до production)
   Elite:   < 1 час
   High:    1 день — 1 неделя
   Medium:  1 неделя — 1 месяц
   Low:     > 1 месяца

3. Mean Time to Restore (MTTR — время восстановления)
   Elite:   < 1 час
   High:    < 1 день
   Medium:  1 день — 1 неделя
   Low:     > 1 недели

4. Change Failure Rate (процент деплоев приводящих к инциденту)
   Elite:   0–15%
   High:    16–30%
   Medium:  16–30% (но дольше восстанавливаются)
   Low:     > 30%

13. Контроль работы людей в многоуровневой поддержке

Инструменты контроля

• Helpdesk: Jira SM, Zendesk — время ответа, эскалации, SLA.
• QA системы: Evaluate, Playvox — оценка тикетов по чек-листу.
• Дашборды real-time: Grafana + очереди, виджеты Jira.
• Запись сессий: Teleport, Apache Guacamole для аудита команд.

Техники управления по линиям

Раз в квартал команда анонимно оценивает 11 параметров по 3 цветам

Параметр                  Оценка    Тренд
────────────────────────────────────────────
Delivery pace             🟡 OK     → Стабильно
Quality                   🟢 GREAT  ↑ Улучшается
Teamwork                  🟢 GREAT  → Стабильно
Fun                       🟡 OK     ↓ Ухудшается (!)
Learning                  🟡 OK     → Стабильно
Mission                   🟢 GREAT  → Стабильно
Pawns or Players          🟡 OK     → Стабильно
Speed                     🔴 POOR   ↓ Ухудшается (!)
Easy to release           🟡 OK     ↑ Улучшается
Suitable process          🟡 OK     → Стабильно
Support                   🟡 OK     → Стабильно

Красные флаги:
Speed ↓ → Обсудить: что замедляет? Процессы? Долг? Нагрузка?
Fun ↓   → Обсудить: выгорание? Монотонность? Нет новых задач?

14. Использование AI-агентов для автоматизации и усиления команды

Для 1-й линии

• Автофильтрация тикетов, приоритизация
• Ответы на типовые вопросы (RAG из базы знаний)
• Сбор диагностики, проверка SLA, pre-QA
• Инструменты: Zendesk Answer Bot, Ultimate.ai, Moveworks

Для 2-й линии

• Анализ логов, рекомендация диагностических команд, генерация SQL, сравнение конфигураций.

Для SRE/DevOps (3-я линия)

• Корреляция алертов, подавление шума (AIOps: BigPanda, Moogsoft)
• Рекомендации по откату, поиск по постмортемам (GPT + RAG)
• Автосоздание задач по Toil, суммаризация логов, чат-интерфейс runbooks

Для управления

• Генерация weekly report, обнаружение выгорания, рекомендации по обучению.

Метрики эффективности AI

Итоговая схема: как всё работает вместе