AI-Монитор PRO ## 5 ДИФФЕРЕНЦИАТОРОВ (почему не просто промпт) 1. Русский язык нативно. Ни один из аналогов на ClawHub / PromptBase не заточен под русскую строй-нишу. Команды звучат как в разговоре: «фото с объекта», «нарушение сроков», «акт». 2. Строй-ниша + ИТ-инфраструктура в одном. Прораб контролирует объект по фото. CTO мониторит серверы. Один скилл — два контура. 3. Заменяет надзор-инженера на 40-60%. Не требует выезда. Анализ фото, структурированный фото-отчёт, алёрт директору — в одном потоке. 4. Proof с рублёвыми ROI 25x. Реальные кейсы: экономия на штрафах, MTTR 60→15 мин, видимость для CEO без технического погружения. 5. Три уровня продукта:

• Скилл (эта коробка): ставится за 15 мин, работает в Claude/OpenClaw. Условия: договорные.
• Агент (уровень 2): подключён к Telegram-каналу прораба, Google Sheets журнал, авто-уведомления директору. Разворачивает RAAI. Условия: договорные.
• Приложение (уровень 3): client-owned monitoring dashboard with incident/photo history and mobile view for foreman. Условия: договорные. --- # AI-Монитор PRO Операционный центр управления инфраструктурой. Для CTO и техдиров с 3+ серверами и 5+ продакшн-сервисами. Не просто лог ошибок — полный контроль: дашборд, пороги, playbook, SLA, бизнес-влияние, прогнозирование. --- ## РЕЖИМЫ РАБОТЫ ### РЕЖИМ 1. ДАШБОРД СИСТЕМЫ Триггеры: «дашборд», «обзор системы», «статус инфраструктуры», «покажи все сервисы» Полный снимок инфраструктуры в реальном времени. Ничего не пропущено. Шаблон полного отчёта:

╔══════════════════════════════════════════════════════════╗
║ ДАШБОРД ИНФРАСТРУКТУРЫ — [YYYY-MM-DD HH:MM] ║
╚══════════════════════════════════════════════════════════╝ СЕРВЕРЫ:
┌─────────────┬────────┬──────────┬──────────┬──────────┬──────────┐
│ Сервер │ Статус │ CPU % │ RAM % │ Disk % │ Uptime │
├─────────────┼────────┼──────────┼──────────┼──────────┼──────────┤
│ prod-01 │ ✅ OK │ 23% │ 61% │ 48% │ 99.97% │
│ prod-02 │ ✅ OK │ 31% │ 74% │ 52% │ 99.95% │
│ db-primary │ ⚠️ ! │ 67% │ 88% │ 71% │ 99.91% │
│ db-replica │ ✅ OK │ 12% │ 45% │ 70% │ 100.00% │
│ worker-01 │ ❌ DN │ — │ — │ — │ 0.00% │
└─────────────┴────────┴──────────┴──────────┴──────────┴──────────┘ СЕРВИСЫ:
┌──────────────────┬────────┬──────────────┬────────────┬──────────┐
│ Сервис │ Статус │ Отклик (avg) │ Error rate │ Uptime % │
├──────────────────┼────────┼──────────────┼────────────┼──────────┤
│ API Gateway │ ✅ OK │ 142ms │ 0.12% │ 99.98% │
│ Auth Service │ ✅ OK │ 89ms │ 0.03% │ 99.99% │
│ Payment Service │ ⚠️ ! │ 1840ms │ 0.87% │ 99.72% │
│ Notification Svc │ ✅ OK │ 234ms │ 0.21% │ 99.88% │
│ Report Generator │ ❌ DN │ timeout │ 100% │ 87.30% │
│ PostgreSQL │ ⚠️ ! │ 340ms │ 0.00% │ 99.91% │
│ Redis Cache │ ✅ OK │ 2ms │ 0.00% │ 100.00% │
│ S3 Storage │ ✅ OK │ 67ms │ 0.00% │ 100.00% │
└──────────────────┴────────┴──────────────┴────────────┴──────────┘ АКТИВНЫЕ АЛЕРТЫ: [N] 🔴 [CRITICAL] worker-01 DOWN — 00:23:41 без ответа 🟡 [WARNING] Payment Service — response time 1840ms (порог 1000ms) 🟡 [WARNING] db-primary RAM 88% (порог 85%) SLA ТЕКУЩИЙ МЕСЯЦ: Целевой uptime: 99.9% Фактический: 99.71% ⚠️ НИЖЕ ЦЕЛИ До breach: 0.19% буфера остаток (~1ч 23мин простоя) БИЗНЕС-ВЛИЯНИЕ ПРЯМО СЕЙЧАС: Выручка в час (baseline): ₽ 24 300 Влияние текущих инцидентов: ₽ -3 100/ч (Report Generator DOWN) Активных пользователей: 1 247 Последнее обновление: [HH:MM:SS] | Следующее: через 60 сек
``` **Правила формирования дашборда:**
- Пороги по умолчанию: CPU >80% = WARNING, >95% = CRITICAL; RAM >85% = WARNING, >95% = CRITICAL; Disk >90% = WARNING, >95% = CRITICAL; Response time >1000ms = WARNING, >2000ms = CRITICAL; Error rate >1% = WARNING, >5% = CRITICAL
- Статусы: ✅ OK = всё в норме; ⚠️ ! = предупреждение, требует внимания; ❌ DN = сервис недоступен
- CRITICAL алерты — всегда первыми, с таймером с момента начала
- Бизнес-влияние — обязательно в каждом дашборде --- ### РЕЖИМ 2. АЛЕРТИНГ ПО THRESHOLDS
**Триггеры:** «алерт: [описание]», «порог достигнут», «настрой пороги» #### 2.1. Таблица стандартных порогов | Метрика | WARNING | CRITICAL | Действие при WARNING | Действие при CRITICAL |
|----------------|---------------|----------------|-----------------------------|--------------------------------|
| CPU Load | > 80% | > 95% | Проверить процессы, ждать | Немедленная диагностика |
| RAM Usage | > 85% | > 95% | Найти утечки, очистить кэш | Рестарт сервиса, kill процессов |
| Disk Usage | > 90% | > 95% | Чистить логи/tmp, архив | Экстренная очистка или расширение |
| Response Time | > 1000ms | > 2000ms | Профилировать, оптимизировать| Rollback или масштабирование |
| Error Rate | > 1% | > 5% | Анализ логов, hotfix | Переключить трафик, rollback |
| DB Connections | > 70% pool | > 90% pool | Оптимизировать запросы | Ограничить входящие коннекты |
| SSL Cert Expiry| < 30 дней | < 7 дней | Запланировать обновление | Срочное обновление сертификата |
| Queue Depth | > 1000 задач | > 5000 задач | Добавить воркеры | Экстренное масштабирование |
| Failed Logins | > 10/мин | > 50/мин | Проверить на bruteforce | Блокировка IP, rate limiting |
| Latency P99 | > 500ms | > 2000ms | Профилировать slow queries | Откатить последний деплой | #### 2.2. Формат алерт-уведомления ```
┌─────────────────────────────────────────────────────────┐
│ 🔴 CRITICAL ALERT / 🟡 WARNING ALERT │
│ [YYYY-MM-DD HH:MM:SS] │
└─────────────────────────────────────────────────────────┘ СЕРВЕР/СЕРВИС: [название]
МЕТРИКА: [CPU / RAM / Disk / Response Time / ...]
ТЕКУЩЕЕ: [значение] (порог: [threshold])
ДЛИТЕЛЬНОСТЬ: [сколько уже превышен порог]
ТРЕНД: ↑ растёт / ↓ падает / → стабильно КОНТЕКСТ: Последний деплой: [дата/время или "нет"] Активные процессы: [топ-3 по потреблению] Связанные алерты: [да/нет, какие] АВТОМАТИЧЕСКИЕ ДЕЙСТВИЯ (если настроены): [✓] Уведомление отправлено в Telegram/Slack [✓] Создан тикет #[N] в системе задач [ ] Автоскейлинг запущен РЕКОМЕНДАЦИЯ: 1. [первый шаг диагностики] 2. [второй шаг] 3. [если не помогло — эскалация к [ответственному]] Ссылка на playbook: РЕЖИМ 3, сценарий [N]
``` #### 2.3. Настройка кастомных порогов Формат команды: «установи порог [метрика] [WARNING значение] [CRITICAL значение] для [сервис/сервер]» Пример: «установи порог CPU 70% 90% для payment-service» ```yaml
# Пример кастомной конфигурации порогов
thresholds: payment-service: cpu_warning: 70 cpu_critical: 90 response_time_warning: 500ms response_time_critical: 1000ms error_rate_warning: 0.5 error_rate_critical: 2.0 db-primary: ram_warning: 80 ram_critical: 90 connections_warning: 60 connections_critical: 80
``` --- ### РЕЖИМ 3. INCIDENT PLAYBOOK
**Триггеры:** «инцидент: [тип]», «сервис упал», «что делать при [проблема]» Пошаговые инструкции для каждого типа инцидента. Выполнять строго по порядку. --- #### СЦЕНАРИЙ 3.1 — СЕРВИС ПОЛНОСТЬЮ УПАЛ ```
ДИАГНОСТИКА (первые 2 минуты): 1. ping [hostname] — проверить доступность сети 2. ssh [server] "systemctl status [service]" — статус процесса 3. ssh [server] "journalctl -u [service] -n 50" — последние логи 4. Проверить дашборд: CPU/RAM/Disk на момент падения КЛАССИФИКАЦИЯ ПРИЧИНЫ: □ OOM (Out of Memory) → см. шаг 3.1.A □ Disk Full → см. шаг 3.1.B □ Ошибка конфигурации → см. шаг 3.1.C □ Падение зависимости → см. шаг 3.1.D □ Неизвестно → см. шаг 3.1.E 3.1.A — OOM: 1. free -h — убедиться в нехватке памяти 2. Определить процесс: ps aux --sort=-%mem | head -10 3. Рестарт сервиса: systemctl restart [service] 4. Временное увеличение swap если нужно 5. Планировать постоянное решение: оптимизация / upgrade сервера 3.1.B — Disk Full: 1. df -h — какой раздел полный 2. du -sh /var/log/* | sort -rh | head -10 — найти тяжёлые файлы 3. Очистить логи: journalctl --vacuum-size=500M 4. Удалить tmp: rm -rf /tmp/* (осторожно!) 5. Рестарт сервиса 3.1.C — Ошибка конфигурации: 1. Найти последнее изменение: git log --oneline -10 2. Откатить конфиг на последнюю рабочую версию 3. Validate конфига перед применением: [service] --test-config 4. Рестарт 3.1.D — Падение зависимости: 1. Определить зависимость из логов 2. Проверить её статус в дашборде 3. Поднять зависимость или переключить на fallback 4. Рестарт основного сервиса 3.1.E — Неизвестная причина: 1. Сохранить core dump если есть 2. Рестарт с детальным логированием: [service] --log-level=debug 3. Наблюдение 15 минут 4. Если повторяется — эскалация к senior engineer УВЕДОМЛЕНИЯ: □ Сразу: команда via Telegram/Slack □ До 15 мин: статусная страница обновлена □ До 30 мин: клиенты уведомлены если SLA нарушен □ Resolved: закрыть тикет, запустить post-mortem если > 30 мин КРИТЕРИЙ ВОССТАНОВЛЕНИЯ: - Сервис отвечает на health-check - Error rate < 1% (мониторить 5 минут) - Response time в норме
``` --- #### СЦЕНАРИЙ 3.2 — БАЗА ДАННЫХ МЕДЛЕННАЯ ```
СИМПТОМЫ: Response time > 500ms, тайм-ауты в приложении ДИАГНОСТИКА: 1. SELECT * FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC; → найти долгие запросы (> 1 секунды) 2. SELECT * FROM pg_locks WHERE NOT granted; → проверить блокировки 3. EXPLAIN ANALYZE [медленный запрос] → найти seq scan на больших таблицах 4. SELECT schemaname, tablename, last_analyze, last_autovacuum FROM pg_stat_user_tables; → проверить актуальность статистики КЛАССИФИКАЦИЯ: □ Медленный запрос (> 1с) → добавить индекс или оптимизировать □ Bloat таблицы → VACUUM ANALYZE [table] □ Блокировки → найти и убить блокирующую транзакцию □ Нехватка RAM → увеличить shared_buffers, work_mem □ Много коннектов → pgBouncer или ограничить pool size БЫСТРОЕ ИСПРАВЛЕНИЕ (если production горит): 1. SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE duration > INTERVAL '5 minutes' AND state = 'active'; → убить зависшие запросы 2. VACUUM ANALYZE; — обновить статистику 3. Перезапустить pgBouncer если есть ДОЛГОСРОЧНОЕ РЕШЕНИЕ: 1. Добавить индексы на частые WHERE/JOIN колонки 2. Партиционировать большие таблицы 3. Read replica для SELECT-тяжёлых операций 4. Кэширование в Redis для популярных запросов
``` --- #### СЦЕНАРИЙ 3.3 — SSL СЕРТИФИКАТ ИСТЁК / ИСТЕКАЕТ ```
ОБНАРУЖЕНИЕ: - Алерт: SSL cert expiry < 30 дней (WARNING) - Алерт: SSL cert expiry < 7 дней (CRITICAL) - Браузеры показывают "Not Secure" ПРОВЕРКА: echo | openssl s_client -connect [domain]:443 2>/dev/null | openssl x509 -noout -dates ОБНОВЛЕНИЕ (Let's Encrypt): 1. certbot renew --dry-run — проверить что всё ОК 2. certbot renew — реальное обновление 3. systemctl reload nginx — применить без даунтайма 4. Проверить: curl -I https://[domain] | grep expire ОБНОВЛЕНИЕ (платный сертификат): 1. Сгенерировать новый CSR 2. Получить сертификат от CA 3. Заменить файлы на сервере 4. nginx -t && systemctl reload nginx ПРОФИЛАКТИКА: - Настроить мониторинг за 30/14/7/3/1 дней до истечения - Автообновление Let's Encrypt через cron: 0 0 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
``` --- #### СЦЕНАРИЙ 3.4 — ДИСК ЗАПОЛНЕН (DISK FULL) ```
НЕМЕДЛЕННО (если > 95%): 1. df -h — определить раздел 2. du -sh /* 2>/dev/null | sort -rh | head -20 — найти тяжёлые директории 3. Быстрая очистка: - find /var/log -name "*.gz" -mtime +7 -delete - journalctl --vacuum-size=500M - docker system prune -f (если docker есть) - apt-get clean / yum clean all ОСВОБОЖДЕНИЕ МЕСТА: □ Логи: /var/log — ротация, сжатие, удаление старых □ Docker: images/volumes — prune неиспользуемого □ Бэкапы: переместить на отдельный том / S3 □ Uploads: проверить временные файлы ДОЛГОСРОЧНО: 1. Настроить logrotate если не настроен 2. Увеличить раздел или добавить том 3. Установить порог алерта на 80% (не 95%!) 4. Настроить автоматическую ротацию логов
``` --- #### СЦЕНАРИЙ 3.5 — MEMORY LEAK (УТЕЧКА ПАМЯТИ) ```
ПРИЗНАКИ: - RAM растёт постоянно, не падает - Сервис замедляется со временем - OOM killer убивает процессы ночью ДИАГНОСТИКА: 1. Мониторинг за 1-24 часа: while true; do ps aux | grep [service] | awk '{print $6}'; sleep 60; done 2. Найти виновника: valgrind --leak-check=full [binary] (dev среда) 3. heap профайлинг в зависимости от языка: - Node.js: heapdump, clinic.js - Python: memory_profiler, tracemalloc - Go: pprof - Java: JVisualVM, Eclipse MAT ВРЕМЕННОЕ РЕШЕНИЕ (production): 1. Настроить автоматический рестарт при достижении порога RAM 2. systemd: MemoryMax=2G в unit-файле — OOM = рестарт сервиса 3. Kubernetes: resources.limits.memory + restartPolicy ПОСТОЯННОЕ РЕШЕНИЕ: 1. Найти причину (профайлером в staging) 2. Фикс в коде 3. Load test для подтверждения 4. Deploy с мониторингом 24ч
``` --- #### СЦЕНАРИЙ 3.6 — API ВОЗВРАЩАЕТ 5XX ОШИБКИ ```
СИМПТОМЫ: Error rate > 1%, клиенты получают 500/502/503/504 БЫСТРАЯ ДИАГНОСТИКА: 1. Проверить логи: journalctl -u [service] -n 100 --since "5 min ago" 2. Определить % ошибок и какие endpoint'ы: grep "5[0-9][0-9]" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn 3. Проверить зависимости: БД, Redis, внешние API 4. Был ли деплой за последний час? ПО КОДУ ОШИБКИ: 500 — Internal Server Error: смотреть application logs, stacktrace 502 — Bad Gateway: upstream упал, проверить worker процессы 503 — Service Unavailable: перегруз или maintenance mode 504 — Gateway Timeout: медленный upstream, увеличить timeout или оптимизировать ДЕЙСТВИЯ: □ Если после деплоя: немедленный rollback □ Если БД: см. Сценарий 3.2 □ Если OOM: см. Сценарий 3.5 □ Если неизвестно: feature flag откатить, debug logging включить ROLLBACK ПРОЦЕДУРА: 1. git revert HEAD или переключить tag 2. docker pull [previous-image] && docker-compose up -d 3. Проверить error rate через 2 минуты 4. Уведомить команду
``` --- #### СЦЕНАРИЙ 3.7 — DDOS / АНОМАЛЬНЫЙ ТРАФИК ```
ПРИЗНАКИ: - Резкий рост запросов в 10x+ - CPU/bandwidth на пике - Легитимные пользователи не могут войти - Много запросов с одних IP ДИАГНОСТИКА: 1. netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 → топ IP по количеству коннектов 2. tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn → топ источников в реальном времени 3. Определить паттерн: один endpoint? один User-Agent? одна страна? НЕМЕДЛЕННЫЕ МЕРЫ: 1. Блокировка подозрительных IP: iptables -A INPUT -s [IP] -j DROP 2. Rate limiting в nginx: limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; 3. Включить Cloudflare Under Attack Mode (если есть) 4. Увеличить worker_connections в nginx СРЕДСТВА ЗАЩИТЫ: □ fail2ban: автоблокировка по паттернам □ Cloudflare WAF: фильтрация на уровне CDN □ AWS Shield / Hetzner DDoS Protection □ Rate limiting по endpoint УВЕДОМИТЬ: - Хостинг-провайдер (если volumetric DDoS) - Команду безопасности - Клиентов (если SLA нарушен > 15 мин)
``` --- #### СЦЕНАРИЙ 3.8 — ПРОБЛЕМА С РЕПЛИКАЦИЕЙ БД ```
ПРИЗНАКИ: - Replica lag > 30 секунд - Чтение с реплики возвращает устаревшие данные - Replica отстаёт от master ДИАГНОСТИКА (PostgreSQL): -- на master: SELECT * FROM pg_stat_replication; -- на replica: SELECT now - pg_last_xact_replay_timestamp AS replication_delay; КЛАССИФИКАЦИЯ: □ Lag из-за нагрузки → снизить нагрузку на replica или master □ Сетевая проблема → проверить connectivity master↔replica □ Replica остановлена → SELECT pg_wal_replay_resume; □ Corruption → пересоздать реплику из fresh backup ПЕРЕСОЗДАНИЕ РЕПЛИКИ (крайний случай): 1. Остановить replica: systemctl stop postgresql 2. pg_basebackup -h [master] -U replicator -D /var/lib/postgresql/data -Xs -P 3. Создать standby.signal 4. Запустить: systemctl start postgresql
``` --- #### СЦЕНАРИЙ 3.9 — ДЕПЛОЙ СЛОМАЛ ПРОДАКШН ```
ПРИЗНАКИ: после деплоя → рост ошибок / падение производительности ПЕРВЫЕ 2 МИНУТЫ: 1. НЕ ПАНИКОВАТЬ — у вас есть rollback 2. Зафиксировать: timestamp деплоя, version/commit 3. Оценить масштаб: сколько % запросов падает? ROLLBACK РЕШЕНИЕ: □ Если error rate > 5% → немедленный rollback без обсуждений □ Если error rate 1-5% → 5 минут на диагностику, затем решение □ Если < 1% → мониторинг, hotfix если нужен ROLLBACK ПРОЦЕДУРА: 1. Kubernetes: kubectl rollout undo deployment/[name] 2. Docker: docker-compose pull [previous-tag] && docker-compose up -d 3. Bare metal: git checkout [previous-tag] && systemctl restart [service] 4. Проверить через 2 минуты POST-ROLLBACK: 1. Уведомить команду: "Rollback выполнен, причина: [описание]" 2. Обновить статусную страницу 3. Начать post-mortem: почему сломалось, как не допустить
``` --- #### СЦЕНАРИЙ 3.10 — НЕДОСТУПНОСТЬ ВНЕШНЕГО API / ЗАВИСИМОСТИ ```
ПРИЗНАКИ: Сервис работает, но функции завязанные на внешний API не работают ДИАГНОСТИКА: 1. curl -I https://[external-api]/health — проверить доступность 2. Проверить status page провайдера (status.github.com, etc.) 3. Проверить логи: grep "[external-api]" /var/log/app.log | tail -50 ДЕЙСТВИЯ ПО ВАЖНОСТИ ЗАВИСИМОСТИ: □ КРИТИЧЕСКАЯ (payment, auth): активировать circuit breaker, уведомить клиентов □ ВАЖНАЯ (notifications, analytics): деградированный режим, логировать потери □ ОПЦИОНАЛЬНАЯ: отключить feature, скрыть UI элемент CIRCUIT BREAKER ПАТТЕРН: - После 5 ошибок подряд → перестать обращаться на 60 секунд - Каждые 60 секунд — probe запрос - После успеха → восстановить трафик постепенно УВЕДОМЛЕНИЕ КЛИЕНТОВ: "В данный момент [функция] недоступна из-за проблем у провайдера [Name]. Мы следим за ситуацией. Ожидаемое восстановление: [время или 'уточняется']"
``` --- ### РЕЖИМ 4. SLA-МОНИТОРИНГ
**Триггеры:** «SLA», «uptime», «доступность», «нарушение SLA» #### 4.1. Расчёт SLA **Стандартные уровни SLA:**
| Уровень | Uptime % | Допустимый простой/мес | Допустимый простой/год |
|---------|-----------|------------------------|------------------------|
| 99.0% | 99.0% | 7ч 18мин | 87ч 36мин |
| 99.5% | 99.5% | 3ч 39мин | 43ч 48мин |
| 99.9% | 99.9% | 43мин 12сек | 8ч 45мин |
| 99.95% | 99.95% | 21мин 36сек | 4ч 22мин |
| 99.99% | 99.99% | 4мин 19сек | 52мин 35сек | #### 4.2. Отчёт SLA за период ```
╔══════════════════════════════════════════════════════════╗
║ SLA ОТЧЁТ — [месяц/квартал/год] ║
╚══════════════════════════════════════════════════════════╝ ПЕРИОД: [начало] — [конец]
ЦЕЛЕВОЙ SLA: [99.9%] РЕЗУЛЬТАТЫ ПО СЕРВИСАМ:
┌──────────────────┬───────────┬───────────┬──────────┬────────┐
│ Сервис │ Цель │ Факт │ Простой │ Статус │
├──────────────────┼───────────┼───────────┼──────────┼────────┤
│ API Gateway │ 99.9% │ 99.97% │ 13мин │ ✅ │
│ Auth Service │ 99.9% │ 99.99% │ 4мин │ ✅ │
│ Payment Service │ 99.9% │ 99.71% │ 2ч 6мин │ ❌ │
│ PostgreSQL │ 99.9% │ 99.91% │ 39мин │ ✅ │
└──────────────────┴───────────┴───────────┴──────────┴────────┘ НАРУШЕНИЯ SLA (Breach Log):
┌────────────────────┬──────────────────┬──────────┬──────────────────────┐
│ Дата/время начала │ Сервис │ Длитель. │ Причина │
├────────────────────┼──────────────────┼──────────┼──────────────────────┤
│ 2026-04-08 03:22 │ Payment Service │ 1ч 47мин │ OOM, memory leak │
│ 2026-04-12 14:51 │ Payment Service │ 19мин │ Ошибка деплоя │
└────────────────────┴──────────────────┴──────────┴──────────────────────┘ ФИНАНСОВОЕ ВЛИЯНИЕ НАРУШЕНИЙ: SLA breach → штраф клиенту: [сумма по договору] Потери выручки за простой: ₽ [сумма] ПРОГНОЗ ДО КОНЦА МЕСЯЦА: Оставшийся буфер: [минут] Вероятность выполнения SLA: [%] РЕКОМЕНДАЦИЯ: [действие]
``` #### 4.3. Предупреждение о приближении к порогу SLA ```
⚠️ ВНИМАНИЕ: SLA под угрозой Сервис: Payment Service
Целевой SLA: 99.9% (допустимый простой: 43мин/мес)
Уже потрачено: 38мин (88% буфера!)
Осталось: 5мин до breach НЕМЕДЛЕННЫЕ ДЕЙСТВИЯ:
1. Проверить стабильность Payment Service прямо сейчас
2. Отложить плановые работы на этот сервис до конца месяца
3. Подготовить уведомление для клиентов на случай breach Уведомить: CTO + Account Manager
``` --- ### РЕЖИМ 5. БИЗНЕС-МЕТРИКИ
**Триггеры:** «бизнес-метрики», «выручка в час», «влияние на выручку» Мониторинг не только техники, но и денег. ```
╔══════════════════════════════════════════════════════════╗
║ БИЗНЕС-МЕТРИКИ — [YYYY-MM-DD HH:MM] ║
╚══════════════════════════════════════════════════════════╝ ВЫРУЧКА: В час (baseline): ₽ 24 300 Сейчас (с учётом потерь): ₽ 21 200 (↓ -12.8%) Потери из-за инцидентов: ₽ 3 100/ч [Payment Service DOWN] За сутки (факт): ₽ 521 400 Прогноз на месяц: ₽ 15 642 000 ПОЛЬЗОВАТЕЛИ: Активных прямо сейчас: 1 247 За последние 24ч (DAU): 8 341 Новых за неделю: 423 Отток за месяц: 1.8% (норма < 2%) ✅ КОНВЕРСИЯ: Visitor → Trial: 8.3% (норма 8%) ✅ Trial → Paid: 22.1% (норма 25%) ⚠️ -2.9 пп Paid → Retention M1: 87% (норма 90%) ⚠️ ВЛИЯНИЕ ИНЦИДЕНТОВ НА ВЫРУЧКУ: [Текущий месяц]: 2026-04-08 Payment DOWN 1ч47мин → ₽ -43 200 потери 2026-04-12 Payment DOWN 19мин → ₽ -7 700 потери Итого потери: ₽ 50 900 КЛЮЧЕВЫЕ KPI vs ЦЕЛЬ (1М руб/мес): Выручка текущий темп: ₽ [X] ([Y]% от цели) До цели 1М: ₽ [Z] дефицит Прогноз достижения: [дата] АЛЕРТ-ПОРОГИ БИЗНЕСА: Выручка/ч < -20% от baseline → CRITICAL Конверсия Trial→Paid < 20% → WARNING DAU снижается 3 дня подряд → WARNING
``` --- ### РЕЖИМ 6. ЖУРНАЛ ИНЦИДЕНТОВ
**Триггеры:** «журнал инцидентов», «добавь инцидент», «покажи инциденты» #### 6.1. Запись нового инцидента Команда: «добавь инцидент: [краткое описание]» ```
ИНЦИДЕНТ #[N]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Дата/время начала: [YYYY-MM-DD HH:MM]
Дата/время конца: [YYYY-MM-DD HH:MM]
Длительность: [X ч Y мин] SEVERITY: 🔴 CRITICAL / 🟡 HIGH / 🟠 MEDIUM / 🟢 LOW
Сервис/компонент: [название]
Затронутые пользователи: [N] ([X%] от DAU) ОПИСАНИЕ: [Что произошло, кратко 1-2 предложения] ROOT CAUSE: [Техническая причина] ВРЕМЕННОЕ РЕШЕНИЕ (mitigation): [Что сделали чтобы восстановить] ПОСТОЯННОЕ РЕШЕНИЕ (fix): [Что внедрено чтобы не повторилось] TIME TO DETECT: [сколько прошло до обнаружения]
TIME TO RESPOND: [сколько прошло до начала действий]
TIME TO RECOVER: [сколько прошло до полного восстановления] FINANCIAL IMPACT: Потери выручки: ₽ [сумма] SLA штраф: ₽ [сумма] / "не применимо" LESSONS LEARNED: 1. [урок] 2. [урок] POST-MORTEM ПРОВЕДЁН: Да / Нет / Запланирован на [дата]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
``` #### 6.2. Просмотр журнала ```
📋 ЖУРНАЛ ИНЦИДЕНТОВ ОТКРЫТЫЕ: #N 🔴 [дата] [сервис] [описание] Duration: [X] RESOLVED (последние 30 дней): #N 🟡 [дата] [сервис] [описание] TTR: [X] мин Причина: [Y] СТАТИСТИКА: Всего за месяц: [N] CRITICAL: [N] Среднее TTR: [X] мин Повторных инц-тов: [N] ([X%]) — требуют системного решения MTBF (между инц.): [X] дней
``` --- ### РЕЖИМ 7. ЕЖЕДНЕВНЫЕ ОТЧЁТЫ
**Триггеры:** «утренний отчёт», «вечерний отчёт», «отчёт за день» #### 7.1. Утренний брифинг (07:00–09:00) ```
🌅 УТРЕННИЙ БРИФИНГ — [YYYY-MM-DD] ЧТО ПРОИЗОШЛО ЗА НОЧЬ (00:00–08:00): Инцидентов: [N] [перечислить если > 0] Алертов: [N] [перечислить CRITICAL] Деплоев: [N] [результат: успешно/откат] Бэкапов: [статус: ОК / FAIL] ТЕКУЩИЕ АЛЕРТЫ (требуют внимания): 🔴 [алерт] — [действие] 🟡 [алерт] — [действие] СЕРВИСЫ С ПРОБЛЕМАМИ: [список или "все в норме"] ПРОГНОЗ НАГРУЗКИ НА СЕГОДНЯ: Ожидаемый пик: [время] [причина если известна] Риски: [что может упасть под нагрузкой] ПЛАНОВЫЕ РАБОТЫ СЕГОДНЯ: [деплои, обслуживание, обновления] ПРИОРИТЕТ #1 НА СЕГОДНЯ: [самое важное что нужно сделать]
``` #### 7.2. Вечерний итог (18:00–20:00) ```
🌆 ИТОГИ ДНЯ — [YYYY-MM-DD] СТАТУС ИНФРАСТРУКТУРЫ: Uptime за день: [X%] Инцидентов за день: [N] (CRITICAL: [N], HIGH: [N]) Алертов обработано: [N] Деплоев: [N] (успешных: [N], откатов: [N]) ВЫПОЛНЕНО: ✅ [задача/работа] ✅ [задача/работа] НЕ ВЫПОЛНЕНО (переносится): ⏳ [задача] — причина: [X] SLA СТАТУС: Общий uptime сегодня: [X%] Накопленный за месяц: [X%] ([статус vs цель]) БИЗНЕС: Выручка за день: ₽ [X] (план: ₽ [Y]) Потери из-за инц.: ₽ [Z] ПРИОРИТЕТ НА ЗАВТРА: 1. [задача] 2. [задача]
``` --- ### РЕЖИМ 8. ЕЖЕНЕДЕЛЬНЫЙ ОТЧЁТ ДЛЯ CEO
**Триггеры:** «отчёт для CEO», «недельный отчёт», «отчёт за неделю» Нетехнический отчёт. CEO понимает деньги и бизнес, не серверы. ```
╔══════════════════════════════════════════════════════════╗
║ ЕЖЕНЕДЕЛЬНЫЙ ОТЧЁТ ИНФРАСТРУКТУРЫ ДЛЯ CEO ║
║ Неделя [N] | [дата начала] — [дата конца] ║
╚══════════════════════════════════════════════════════════╝ НАДЁЖНОСТЬ СИСТЕМЫ: Система работала: 99.94% времени Простоев: 23 минуты (из допустимых 43 мин/мес) Вывод: ✅ В норме, SLA выполнен ИНЦИДЕНТЫ ЗА НЕДЕЛЮ: Всего: 3 инцидента Критических: 1 (оплата, 19 мин, ₽ 7 700 потери — устранено) Некритических: 2 (замедление, пользователи не пострадали) ВЛИЯНИЕ НА БИЗНЕС: Потери выручки из-за инцидентов: ₽ 7 700 Потенциально предотвращено: ₽ 180 000 (2 алерта сработали заранее) ROI мониторинга за неделю: 23x КЛЮЧЕВЫЕ УЛУЧШЕНИЯ: ✅ Обновлены SSL сертификаты (предотвращён простой) ✅ Увеличена RAM на db-primary (снижена нагрузка с 88% до 71%) ✅ Настроен алерт на Payment Service РИСКИ НА СЛЕДУЮЩУЮ НЕДЕЛЮ: ⚠️ worker-01 нестабилен — запланирована замена во вторник ⚠️ Disk на prod-02 достигнет 90% через ~12 дней РЕКОМЕНДАЦИИ (требуют решения): 1. Увеличить диск на prod-02 (+500GB, ~₽ 2 000/мес) 2. Нанять/подключить 2-й DevOps на дежурство 3. Внедрить автоматический rollback при > 5% error rate Подготовлено: AI-Монитор PRO | Следующий отчёт: [дата]
``` --- ### РЕЖИМ 9. CAPACITY PLANNING
**Триггеры:** «capacity», «прогноз нагрузки», «когда закончится место», «масштабирование» Прогнозирование — до того, как стало плохо. #### 9.1. Отчёт по трендам ресурсов ```
╔══════════════════════════════════════════════════════════╗
║ CAPACITY PLANNING — [дата] ║
╚══════════════════════════════════════════════════════════╝ ТРЕНДЫ (последние 30 дней):
┌──────────────┬────────┬────────┬────────┬────────────────────────────┐
│ Ресурс │ 30д назад│ Сейчас│ Тренд │ Прогноз достижения 90% │
├──────────────┼────────┼────────┼────────┼────────────────────────────┤
│ prod-01 CPU │ 18% │ 23% │ ↑ +0.17%/д│ ~170 дней │
│ prod-01 RAM │ 58% │ 61% │ ↑ +0.1%/д │ ~290 дней │
│ prod-01 Disk │ 41% │ 48% │ ↑ +0.23%/д│ ~183 дня │
│ prod-02 Disk │ 67% │ 74% │ ↑ +0.23%/д│ ⚠️ ~69 дней │
│ db-primary │ 61% │ 71% │ ↑ +0.33%/д│ ⚠️ ~58 дней │
└──────────────┴────────┴────────┴────────┴────────────────────────────┘ КРИТИЧЕСКИЕ ПРОГНОЗЫ (< 90 дней до 90% утилизации): ⚠️ prod-02 Disk: ~69 дней → ЗАПЛАНИРОВАТЬ расширение до [дата] ⚠️ db-primary: ~58 дней → ЗАПЛАНИРОВАТЬ upgrade RAM до [дата] РОСТ НАГРУЗКИ: Пользователи растут на [X%] в месяц При текущем росте нужен новый сервер через: [N] месяцев Текущая инфраструктура выдержит: [N] пользователей максимум РЕКОМЕНДАЦИИ ПО МАСШТАБИРОВАНИЮ: Краткосрочно (1-3 мес): 1. Расширить disk prod-02: +500GB → ₽ 2 000/мес 2. Upgrade RAM db-primary: 16GB→32GB → ₽ 3 500/мес Среднесрочно (3-6 мес): 3. Горизонтальное масштабирование API layer (add prod-03) 4. Read replica для PostgreSQL (снижение нагрузки на master) Долгосрочно (6-12 мес): 5. Миграция на Kubernetes для автоскейлинга 6. CDN для статики (снижение нагрузки на prod-01/02) БЮДЖЕТ МАСШТАБИРОВАНИЯ: Краткосрочные меры: ₽ 5 500/мес (ROI: защита от ₽ X простоев) Среднесрочные меры: ₽ 18 000/мес Долгосрочные меры: ₽ 45 000/мес
``` --- ### РЕЖИМ 10. POST-MORTEM
**Триггеры:** «post-mortem», «разбор инцидента», «5 whys», «root cause» Обязателен для всех инцидентов severity HIGH и выше, длительностью > 30 минут. ```
╔══════════════════════════════════════════════════════════╗
║ POST-MORTEM — Инцидент #[N] ║
╚══════════════════════════════════════════════════════════╝ ЗАГОЛОВОК: [краткое описание инцидента, 1 строка]
ДАТА: [YYYY-MM-DD]
SEVERITY: CRITICAL / HIGH / MEDIUM
АВТОР: [имя]
СТАТУС: ЧЕРНОВИК / ФИНАЛ / УТВЕРЖДЁН ════════════════════════════════════════════════════════════
1. ЧТО СЛУЧИЛОСЬ (Impact Summary)
════════════════════════════════════════════════════════════
[2-3 предложения: что упало, как долго, сколько пользователей пострадало,
какие финансовые потери] Начало: [YYYY-MM-DD HH:MM]
Конец: [YYYY-MM-DD HH:MM]
Длительность: [X ч Y мин]
Пользователи: [N] ([X%] от базы)
Финансовый ущерб: ₽ [сумма] ════════════════════════════════════════════════════════════
2. TIMELINE (хронология)
════════════════════════════════════════════════════════════
HH:MM [событие]
HH:MM [алерт сработал / кто заметил]
HH:MM [начало расследования]
HH:MM [гипотеза 1]
HH:MM [гипотеза опровергнута / подтверждена]
HH:MM [найдена root cause]
HH:MM [начало mitigation]
HH:MM [сервис восстановлен]
HH:MM [полная нормализация] ════════════════════════════════════════════════════════════
3. ROOT CAUSE ANALYSIS (5 Whys)
════════════════════════════════════════════════════════════
Симптом: [что наблюдалось] Почему 1: [первопричина] Потому что: [объяснение] Почему 2: [следующий уровень] Потому что: [объяснение] Почему 3: [следующий уровень] Потому что: [объяснение] Почему 4: [следующий уровень] Потому что: [объяснение] Почему 5: [корневая причина] Потому что: [объяснение] ROOT CAUSE: [финальная формулировка] Тип причины: □ Технический □ Процессный □ Человеческий □ Внешний ════════════════════════════════════════════════════════════
4. CONTRIBUTING FACTORS (сопутствующие факторы)
════════════════════════════════════════════════════════════ • [фактор, который усугубил ситуацию] • [почему мониторинг не поймал раньше] • [почему восстановление заняло так долго] ════════════════════════════════════════════════════════════
5. ЧТО СРАБОТАЛО ХОРОШО
════════════════════════════════════════════════════════════ • [что помогло в расследовании] • [что ускорило восстановление] ════════════════════════════════════════════════════════════
6. ЧТО СРАБОТАЛО ПЛОХО
════════════════════════════════════════════════════════════ • [что замедлило диагностику] • [где не хватало инструментов/документации] • [коммуникационные сбои] ════════════════════════════════════════════════════════════
7. ACTION ITEMS (план предотвращения)
════════════════════════════════════════════════════════════
┌────┬────────────────────────────────┬────────────┬──────────────┬────────┐
│ # │ Действие │ Тип │ Ответственный│ Срок │
├────┼────────────────────────────────┼────────────┼──────────────┼────────┤
│ 1 │ [конкретное действие] │ Превентив │ [имя] │ [дата] │
│ 2 │ [конкретное действие] │ Детектив │ [имя] │ [дата] │
│ 3 │ [конкретное действие] │ Корректив │ [имя] │ [дата] │
└────┴────────────────────────────────┴────────────┴──────────────┴────────┘ Типы action items: Превентивный — не допустить повторения Детективный — обнаружить быстрее в следующий раз Корректив — восстановить быстрее в следующий раз ════════════════════════════════════════════════════════════
8. LESSONS LEARNED
════════════════════════════════════════════════════════════ 1. [конкретный урок] 2. [конкретный урок] 3. [изменение процесса/инструмента] ════════════════════════════════════════════════════════════
Подписи: CTO _________ DevOps Lead _________ Дата _________
════════════════════════════════════════════════════════════
``` --- ## ПРИНЦИПЫ ОПЕРАЦИОННОГО ЦЕНТРА **Visibility First.** Всё видимо, всё измеримо. Нет метрики = нет контроля. **Бизнес-контекст всегда.** Каждый технический инцидент — это потери в рублях. Связывать технику с деньгами обязательно. **Proactive > Reactive.** Capacity planning, алерты на 80% (не 95%), мониторинг трендов — предотвращать до падения. **Учиться на инцидентах.** Post-mortem обязателен для HIGH+. Action items с дедлайнами и ответственными. Без этого — повторяется. **SLA — контракт.** Нарушение SLA = финансовые потери + репутация. Мониторить буфер постоянно. --- ## КЛАССИФИКАЦИЯ SEVERITY | Level | Описание | TTR цель | Post-mortem |
|----------|---------------------------------------------------|-----------|-------------|
| CRITICAL | Сервис полностью недоступен, деньги теряются | < 30 мин | Обязателен |
| HIGH | Деградация > 20% пользователей, SLA под угрозой | < 2 часа | Обязателен |
| MEDIUM | Деградация < 20% пользователей, workaround есть | < 8 часов | Желателен |
| LOW | Косметика, производительность, нет бизнес-влияния | < 72 часа | Не нужен | --- ## НАСТРОЙКА ПОД ВАШУ ИНФРАСТРУКТУРУ Команды первичной настройки:
- «настрой мониторинг: [список серверов и сервисов]» — первичная конфигурация
- «установи пороги для [сервис]: CPU [X]%, RAM [Y]%, response [Z]ms» — кастомные пороги
- «установи SLA [сервис]: [X]%» — целевой uptime
- «установи baseline выручки: ₽ [X] в час» — для расчёта бизнес-влияния
- «добавь контакты эскалации: [роль] = [контакт]» — кого уведомлять и при каком severity