Ai Monitor Pro

AI monitoring for construction sites and IT infrastructure: dashboards, alerts, incident playbooks, photo reports, SLA and capacity control.

Security Scan

The skill's docs claim a quick, instruction-only install for monitoring, but the package includes executable install/build/smoke-test scripts and expects integrations (Telegram, Prometheus/Grafana, server hostnames) without declaring required credentials or an install mechanism — review the scripts and integrations before running anything.

Purpose & Capability

The SKILL.md and README describe monitoring for both construction sites and IT infra, which aligns with the included config.yaml fields. However the skill advertises 'no-server / 15 min install' and 'instruction-only' while shipping install.sh/build.sh/test scripts. The presence of system-level scripts is disproportionate to the claim of being pure instruction-only and raises questions about what those scripts will do.

Instruction Scope

Runtime instructions require filling config.yaml and running install.sh/test/smoke-test.sh. SKILL.md also describes integrations (Telegram alerts, Prometheus/Grafana, Cloudflare commands in examples). The instructions do not declare what secrets or network endpoints the agent will need, nor do they limit or explain what install.sh will perform — this gives the skill broad discretion to read sensitive config, make network calls, or modify the host.

Install Mechanism

Registry lists no install spec but the package contains build.sh, install.sh and a smoke-test script and README explicitly tells the user to run install.sh and the smoke test. Scripts packaged with an 'instruction-only' listing are a higher-risk install vector because they can download/extract/execute code on the host. The provided build.sh appears to prepare ZIPs (benign pattern), but install.sh content was not shown — running it without review is risky.

Credentials

The skill requests filling config.yaml with server hostnames/IPs, escalation contacts, and business-sensitive values (hourly revenue, cost_of_1h_major_downtime_rub). It references external destinations (Telegram, Prometheus/Grafana, Cloudflare) but the registry metadata declares no required env vars or primary credential. That mismatch is concerning: the skill likely needs tokens/keys to send alerts or integrate with other systems but does not declare them, so credential usage is opaque and not proportionally documented.

Persistence & Privilege

The skill is not marked always:true and does not declare requests to modify other skills or agent-wide settings. However bundled install scripts could create services, schedule jobs, or write to system locations; SKILL.md/README do not detail these actions. Recommend reviewing install.sh for persistence actions (systemd, cron, writing to /etc, creating user accounts) before execution.

What to consider before installing

What to do before installing or running anything from this skill: - Do NOT run install.sh, build.sh, or test/smoke-test.sh as-is on a production host or as root. Treat them as untrusted code until reviewed. - Request or inspect the full contents of install.sh and test/smoke-test.sh. Look for network downloads (curl/wget), creation of systemd services, cronjobs, use of sudo, writes to /etc or /root, or hardcoded external endpoints/IPs. - Verify what credentials/integration tokens are required. The skill references Telegram, Prometheus/Grafana, Cloudflare and sending alerts, but the registry lists no required env vars — ask the author which secrets (e.g., TELEGRAM_BOT_TOKEN, PROMETHEUS_API_KEY, SSH keys) are needed and how they are stored/used. - If you must test: run inside an isolated VM or disposable container with no access to production network or secrets; monitor outbound network connections and filesystem changes. - Pay attention to privacy and legal risk: the skill claims to handle photo reports from construction sites; confirm how photos and personal data are stored/transmitted and that uploads are not sent to unknown third-party servers. - Prefer a manual / read-only trial: fill config.yaml with dummy values and exercise prompts that only generate textual playbooks/dashboards (no integrations) to validate functionality before enabling integrations or running installer scripts. - If you want a deeper review, provide the install.sh and test/smoke-test.sh contents (or allow a static analysis run) so the scripts can be audited for downloads, service installation, credential exfiltration, or other risky behavior. Why this is suspicious: the package claims 'instruction-only' and '15 min install' yet includes executable install/build scripts and integration-driven features without declaring required credentials. That gap (scripts + undisclosed integrations/credentials) increases the chance the package will perform unexpected network or system actions when installed.

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