Мониторинг в малом бизнесе почти всегда ломается об одну и ту же стену: слишком много сигналов и слишком мало времени. В итоге либо “мониторим всё” и тонем в алертах, либо “не мониторим ничего” и узнаём о проблемах от клиентов.
Эта статья — про мониторинг, который окупается: минимальный набор метрик и проверок, понятные пороги, и самое главное — как связать мониторинг с деньгами, репутацией и реальными решениями.
Важно: мониторинг — это не “графики”. Мониторинг — это способность узнать о проблеме раньше клиента и понять, что делать.
Что значит “окупается”
Мониторинг окупается, когда выполняются хотя бы два пункта:
- Сокращается простой (downtime) или деградация сервиса.
- Снижается количество инцидентов, которые “выплывают” через поддержку/менеджеров.
- Уменьшается время восстановления (MTTR).
- Уменьшается стоимость инцидентов (потерянные заявки, штрафы, переработки, возвраты).
- Становится проще планировать инфраструктуру (не “на глаз”, а по фактам).
Быстрая формула окупаемости (практическая)
Оценка “на салфетке”:
- Стоимость часа простоя = (средняя выручка в час) + (стоимость команды, которая тушит пожар) + (репутационные потери, хотя бы условно).
- Сколько часов простоя/деградации было за квартал?
- Если мониторинг снижает простой на X% — это и есть экономический эффект.
Пример:
- 2 инцидента в месяц по 1 часу “всё плохо”.
- Потери: 20 000 ₽/час.
- Итого: 40 000 ₽/мес.
- Даже если мониторинг снизит это на 30% — экономия 12 000 ₽/мес.
Главная ошибка: мониторить компоненты вместо сервиса
Малому бизнесу почти никогда не нужен мониторинг “CPU на всех серверах” как первая цель. Нужен мониторинг услуги:
- Клиент может оставить заявку?
- Письмо уходит и приходит?
- Оплата проходит?
- Сайт грузится?
- Сотрудники могут войти в админку?
- Бэкапы восстанавливаются?
Это называется SLO/SLI-мышление (в духе SRE): сначала мониторим то, что важно пользователю и бизнесу, потом внутренности.
Уровни мониторинга: от “бизнес-сигналов” к железу
Правильный порядок внедрения (сверху вниз):
- Бизнес-сигналы (симптомы): заявки, оплаты, критические пользовательские действия.
- Сервисные проверки: доступность сайта/API, скорость ответов, ошибки.
- Зависимости: база, очередь, кэш, SMTP, внешние API.
- Хост/инфраструктура: диск, память, CPU, сеть, контейнеры.
Если начать с пункта 4, ты получишь красивые графики и ноль пользы в момент, когда “заявки не приходят”.
Минимальный набор, который почти всегда окупается
Ниже практический “MVP мониторинга” для малого бизнеса, который реально даёт эффект.
1) Доступность публичного сайта (Uptime)
Что мониторить
- HTTP/HTTPS доступность главной страницы и ключевых страниц (например, /contacts, /checkout).
- DNS-резолвинг домена.
- TLS-сертификат (срок действия, ошибки цепочки).
Почему окупается
- Это прямой индикатор “клиенты вообще могут нас найти”.
- Часто ловит проблемы провайдера/сертификата раньше пользователей.
Порог
- 1–3 неуспешных проверки подряд (в зависимости от частоты).
Что делать при алерте
- Проверить из 2–3 разных точек (не “у тебя дома работает — значит ок”).
- Проверить статус DNS и SSL.
- Если проблема у провайдера — переключать на резерв/страницу статуса.
2) Ключевой пользовательский путь (Synthetic monitoring)
Это самый недооценённый инструмент.
Что мониторить
- “Оставить заявку” (форма → подтверждение).
- “Оплатить” (хотя бы до шага редиректа в платёжку).
- “Войти в личный кабинет”.
Почему окупается
- Сервис может быть “в аптайме”, но форма сломана, и бизнес теряет лиды молча.
Порог
- Любая ошибка — критично, потому что это деньги.
Что делать
- Авто-открывать тикет/уведомление ответственным.
- Логировать payload/ответ (без персональных данных).
3) Ошибки приложения (5xx, spike ошибок)
Что мониторить
- Количество 5xx на веб-сервере и приложении.
- Резкие всплески 4xx (например, массовые 401/403 — возможная проблема с авторизацией или атака).
- Ошибки в логах уровня ERROR/CRITICAL.
Почему окупается
- 5xx почти всегда означают “пользователь упёрся в стену”.
- Ошибки в логах часто показывают первопричину раньше, чем метрики “железа”.
Порог
- Не “0 ошибок”, а “ошибок больше, чем обычно”.
- Например: 5xx > 1% от всех запросов за 5 минут.
4) Время ответа (latency) и перцентили
Среднее значение почти бесполезно. Нужно мониторить перцентили.
Что мониторить
- p95 и p99 времени ответа по ключевым эндпоинтам.
- Отдельно: время ответа базы/кеша, если есть.
Почему окупается
- Деградации часто “размазываются”: сервис не падает, но становится медленным, клиенты уходят.
Порог
- Привязать к UX:
- p95 < 500–800 мс (примерно), в зависимости от продукта.
- Порог должен быть реалистичным, иначе алерты будут всегда.
5) Диск: свободное место и “иноды” (Linux)
Это классика, которая ломает всё внезапно.
Что мониторить
- Свободное место на разделах (особенно где логи, база, бэкапы).
- Inodes (если много мелких файлов).
- Рост логов (скорость).
Почему окупается
- Полный диск = падение базы, невозможность писать логи, ломаются очереди, деплой, бэкап.
Порог
- Warning: < 20%
- Critical: < 10%
- И отдельно алерт на “скорость заполнения” (например, диск закончится за 24 часа).
6) Бэкапы: не “сделались”, а “восстанавливаются”
Большинство “мониторинга бэкапов” — фикция: проверяют, что файл появился. Но он может быть пустым, битым или не открываться.
Что мониторить
- Успешность задания бэкапа.
- Размер бэкапа (аномально маленький/большой).
- Контрольная сумма/проверка архива.
- Периодический тест восстановления (хотя бы 1 раз в месяц): развёрнуть в отдельную папку/контейнер.
Почему окупается
- Когда происходит инцидент, уже поздно узнавать, что бэкапы “не те”.
Порог
- Любой провал — критично.
7) Почта и уведомления (SMTP/почтовый шлюз)
Для малого бизнеса “почта” часто критичнее сайта.
Что мониторить
- Возможность отправки (SMTP test).
- Очередь/задержка отправки (если используется MTA).
- Доставка писем на тестовый ящик (end-to-end).
Почему окупается
- Если не уходят письма, заявки/счета/уведомления пропадают, а бизнес видит это не сразу.
8) Внешние зависимости (платежи, CRM, API)
Что мониторить
- Доступность внешнего API.
- Код ответа/ошибки.
- Время ответа.
- Лимиты/квоты (rate limits).
Почему окупается
- “У нас всё работает” — но внешняя платежка/CRM легла, и продажи стоят.
Что НЕ нужно мониторить в начале (типовые ловушки)
- CPU “на всякий случай” без связи с симптомами.
- Все метрики Prometheus “потому что там их много”.
- Красивые дашборды без алертинга и без владельцев метрик.
- Логи “накапливать” без структуры и без поиска по инцидентам.
- Алерты “на каждое чихание” (alert fatigue убивает дисциплину).
Как настроить алерты, чтобы их не отключили через неделю
Правило 1: у каждого алерта должен быть владелец
Если непонятно “кто должен реагировать” — алерт мусорный.
- Критические алерты → владелец/дежурный.
- Некритические → в канал “наблюдения” или в тикеты.
Правило 2: алерт должен говорить, что делать
Плохой алерт: “High CPU on server-1”.
Хороший алерт: “p95 /checkout вырос до 2.5s (норма < 800ms), 5xx 3% — вероятно деградация базы. Проверь: соединения DB, медленные запросы, свободное место”.
Правило 3: предупреждение и критика
- Warning — для плановых действий (приближение к лимитам).
- Critical — когда бизнес уже теряет деньги или вот-вот потеряет.
Правило 4: не алертить по “шумным” метрикам
Например, кратковременный рост CPU — нормально. А вот:
- рост ошибок,
- рост latency,
- полный диск,
- провал бэкапа, — всегда важно.
Дашборды, которые реально нужны владельцу бизнеса
Сделай отдельный “Business dashboard” (без технарщины):
- Количество лидов/заявок за час/день.
- Конверсия (если есть).
- Успешные оплаты/ошибки оплат.
- Время ответа ключевых операций (p95).
- Аптайм публичных страниц.
- Статус бэкапов (последний успешный, тест восстановления).
Это превращает мониторинг в управленческий инструмент, а не “игрушку DevOps”.
Как выбрать пороги: метод “база + аномалии”
Вместо “CPU > 80%” лучше:
- Собрать базовую линию 1–2 недели.
- Понять, что нормально в пике.
- Настроить алерты на отклонение от нормы, а не на “красивые числа”.
Примеры:
- “5xx в 3 раза выше, чем обычно в это время суток”.
- “Время ответа /api/login выросло на 200% относительно медианы недели”.
- “Бэкап обычно 2–3 ГБ, сегодня 200 МБ”.
Инциденты: мониторинг без runbook — половина дела
Если алерт есть, но непонятно, что делать — команда будет нервничать и принимать хаотичные решения.
Минимальный runbook на 1 страницу для каждого критического алерта:
- Симптом (что случилось).
- Влияние на бизнес (что ломается).
- Первые 3 проверки (быстрые).
- Вероятные причины (2–3 типовые).
- Действия (что можно сделать безопасно).
- Эскалация (кому и когда).
С чего начать: план на 7 дней
День 1–2: определить критические пути
- Список 3–5 действий, которые приносят деньги или лиды.
- Пример: “заявка”, “оплата”, “вход”, “письмо клиенту”.
День 3: включить внешнюю проверку доступности
- Проверка сайта + TLS + DNS.
- Уведомления в один канал.
День 4–5: добавить синтетический тест “заявка/оплата”
- Автотест с контрольным ящиком/тестовой заявкой.
- Логирование результата.
День 6: бэкапы с проверкой
- Успешность + размер + проверка архива.
- Поставить задачу на тест-восстановление.
День 7: привести алерты в порядок
- Убрать шум.
- Для каждого критического алерта написать мини-runbook.
Частые вопросы
“У нас один VPS. Неужели нужен мониторинг?”
Да. Один VPS падает чаще всего “по мелочам”: диск, сертификат, зависший процесс, проблемы провайдера, бэкапы. Мониторинг нужен именно для таких сценариев.
“Мы и так смотрим глазами”
“Глазами” не видно:
- ночные проблемы,
- деградации,
- скрытые поломки форм/почты,
- провалы бэкапов.
“У нас нет SRE/DevOps”
Значит, мониторинг должен быть проще: меньше метрик, больше проверок пользовательских путей и бэкапов.
Чек-лист: мониторинг, который окупается
- Uptime сайта + DNS + SSL.
- Синтетический тест “заявка/оплата/вход”.
- Ошибки 5xx и всплески ошибок.
- p95/p99 latency ключевых операций.
- Диск + скорость заполнения.
- Бэкапы с проверкой и тест-восстановлением.
- SMTP/уведомления end-to-end.
- Статус внешних API (платежи/CRM).
- Для каждого critical-алерта есть владелец и runbook.