Шесть уровней мониторинга в виде пирамиды L6 Бизнес-метрики (закрытие смены 1С, ОФД, эквайринг) L5 — Синтетика (Selenium/Playwright сценарии) проход типового сценария бухгалтера L4 — Blackbox (HTTP, TCP, certs) внешняя проверка из 2 точек L3 — Сервисы (1С, AD, SQL, SMB, Exchange) метрики приложений L2 — ОС (CPU, RAM, диск, eventlog) Zabbix-агент / node_exporter L1 — Сеть и питание (ICMP, SNMP, ИБП) базовая связность 99,98% SLA = 1ч 45мин/год 2025: 1ч 21мин = 99,985% Производство 47 РМ офис на МКАД, 12-я смена
6 уровней мониторинга: от ICMP до бизнес-метрик закрытия смены
SLA и мониторинг · 18 мин чтения · Семёнов Е.С., руководитель ITfresh

SLA 99,98% для офиса 50 РМ: наша 6-уровневая схема мониторинга

К нам в ITfresh обратилась производственная компания на 47 рабочих мест с офисом и небольшим цехом на МКАД: за прошлый год у них было пять незапланированных простоев общей длительностью 14 часов, потери на одном из них — 380 000 рублей упущенного производства. Цель — выйти на честный SLA 99,98% и держать его. Ниже — наша рабочая 6-уровневая схема мониторинга, по которой мы прожили с этим клиентом весь 2025 год: 1 час 21 минута общего простоя, что соответствует 99,985% доступности. Без воды, со всеми конфигами Zabbix, Prometheus, blackbox-exporter и реальными метриками по 1С.

Что значит SLA 99,98% — давайте посчитаем честно

Сначала про арифметику. Когда подрядчик пишет в коммерческом предложении «гарантируем SLA 99,9%», звучит красиво. Переводим в часы:

Для МСБ на 30-50 РМ оптимальный диапазон — 99,9-99,98%. «Три девятки» (99,9%) — базовая планка, которую держит любой нормальный подрядчик за счёт грамотной серверной части. «Четыре девятки» (99,98%) требуют уже системного мониторинга и продуманной отказоустойчивости — и это наш стандарт. «Пять девяток» — это когда у вас есть штатный SRE, второй ЦОД, BGP с двумя upstream-провайдерами и зарплатный фонд на это всё. Для компании в 50 РМ такая планка экономически бессмысленна.

Что входит в SLA, а что нет

В договоре с клиентом я всегда явно прописываю периметр SLA. Иначе получается, что заказчик спрашивает про «100% доступность интернета», а ему нечего возразить, когда обрыв происходит у Ростелекома и не зависит ни от подрядчика, ни от резервирования. Наш стандарт периметра:

Уровень 1. Сеть и питание (ICMP, SNMP, UPS)

Самый низкий, базовый уровень. На нём живёт классический Zabbix. Сервер мониторинга — отдельная VM 4 vCPU, 8 GB RAM, 200 GB SSD на гипервизоре, в отдельном VLAN от продакшена. Если упадёт основная сеть — Zabbix всё равно увидит и пришлёт алерт.

Что мы пингуем

Конфиг Zabbix-агента и SNMP-шаблонов

# /etc/zabbix/zabbix_server.conf — ключевые параметры
StartPollers=20
StartPollersUnreachable=10
StartTrappers=10
StartPingers=4
HousekeepingFrequency=1
MaxHousekeeperDelete=5000
CacheSize=512M
HistoryCacheSize=128M
ValueCacheSize=256M
TrendCacheSize=64M

# /etc/snmp/snmpd.conf на коммутаторах HPE Aruba — v3
createUser monitor SHA "ОченьДлинныйАутхПароль" AES "ОченьДлинныйПривПароль"
rouser monitor priv

Для ИБП APC я завёл отдельный Template APC NMC — он отслеживает 12 метрик и шлёт алерт при переходе на батарею (input voltage = 0). За 2025 год это сработало 4 раза — два раза реальное отключение, два раза скачок в подъезде.

Уровень 2. Операционные системы (CPU, RAM, диск, eventlog)

Здесь живёт классическая поагентная система. На каждом сервере и каждом значимом ПК (компьютер директора, секретаря, главного бухгалтера) стоит Zabbix-agent2. Параллельно — node_exporter для тех серверов, по которым нам важна метрика с гранулярностью 15 секунд.

Что собирается

UserParameter=ad.dfsr.queue,powershell -Command "Get-DfsrBacklog -GroupName 'Domain System Volume' -FolderName SYSVOL -SourceComputerName DC01 -DestinationComputerName DC02 | Measure-Object | Select-Object -ExpandProperty Count"
UserParameter=ad.replication.delay,powershell -Command "(Get-ADReplicationPartnerMetadata -Target DC01,DC02 -Scope Domain).LastReplicationSuccess.AddMinutes(15) -lt (Get-Date)"
UserParameter=onec.session.count,powershell -Command "(Get-CimInstance -ClassName Win32_Process -Filter \"Name='rphost.exe'\").Count"
UserParameter=hyperv.vm.cpuready,powershell -Command "(Get-Counter -Counter '\Hyper-V Hypervisor Virtual Processor(*)\\% Hypervisor Run Time' -SampleInterval 1 -MaxSamples 1).CounterSamples | Measure-Object -Property CookedValue -Average | Select-Object -ExpandProperty Average"

Эти кастомные метрики собираются с Windows-серверов раз в минуту. По истории строим тренды через Zabbix Trend и держим за 6 месяцев.

EventLog-фильтры

Я не собираю «всё подряд» из Windows EventLog — это бесполезный шум. Собираю конкретные критические события:

# Active Directory Domain Services (DC)
EventLog: Directory Service, ID 1311 (KCC ошибка), 2087 (DNS sync), 2089 (replication backlog)

# Hyper-V hosts
EventLog: Microsoft-Windows-Hyper-V-VMMS-Admin, ID 12030 (heartbeat lost), 12130 (live migration failed)

# Файловый сервер
EventLog: Application, source MSExchangeIS — пропускаем, не Exchange
EventLog: System, ID 7000-7034 (service start/stop) — только для критических служб

# 1C Сервер
EventLog: Application, source 1C:Enterprise 8.3 — все Error и Critical

Каждый из этих фильтров — отдельный item в Zabbix с триггером. Когда на DC02 за 5 минут больше двух событий 2087 — это начинающаяся проблема с DNS-репликацией, и я получаю уведомление до того, как пользователи начнут жаловаться.

Уровень 3. Сервисы приложений (1С, AD, SQL, SMB, Exchange)

Уровень про сами приложения, а не про машины, на которых они крутятся. Здесь у нас Prometheus + Grafana параллельно с Zabbix. Zabbix хорош в дискретных алертах, Prometheus — в дашбордах и сложных метриках.

Что мониторим

Prometheus + windows_exporter

На каждом Windows-сервере живёт windows_exporter от Prometheus с включёнными модулями: cs, cpu, memory, logical_disk, net, service, process, mssql, ad. Конфиг скрейпа на Prometheus-сервере:

scrape_configs:
  - job_name: 'windows-servers'
    scrape_interval: 15s
    scrape_timeout: 10s
    static_configs:
      - targets:
          - 'dc01.corp.company.ru:9182'
          - 'dc02.corp.company.ru:9182'
          - 'fs01.corp.company.ru:9182'
          - 'sql01.corp.company.ru:9182'
          - '1c-app01.corp.company.ru:9182'
        labels:
          env: 'prod'
          tier: 'core'

  - job_name: 'sql-database'
    scrape_interval: 30s
    static_configs:
      - targets: ['sql01.corp.company.ru:9182']
    metrics_path: /probe
    params:
      module: [mssql]

Дашборды Grafana — стандартные (id 14694 для windows_exporter, id 13000 для node_exporter), но я допиливаю под клиента: добавляю панель с количеством сессий 1С, графики latency на типовые проводки.

Уровень 4. Blackbox-проверки (HTTP, TCP, сертификаты)

Это «взгляд снаружи». blackbox-exporter от Prometheus стоит у нас на двух точках: один — на нашем сервере мониторинга в дата-центре МТС, второй — на VPS у Selectel в Питере. Они независимо проверяют публичные сервисы клиента и сравнивают результаты. Если из одной точки доступно, а из другой — нет, это локальная проблема (например провайдер). Если из обеих недоступно — авария на стороне клиента.

# /etc/blackbox_exporter/blackbox.yml
modules:
  http_2xx:
    prober: http
    timeout: 10s
    http:
      method: GET
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: [200, 301, 302]
      follow_redirects: true
      preferred_ip_protocol: "ip4"

  http_post_login:
    prober: http
    http:
      method: POST
      headers:
        Content-Type: application/x-www-form-urlencoded
      body: "username=monitor&password=...&submit=login"
      fail_if_not_matches_regexp:
        - "Welcome,"

  tcp_connect:
    prober: tcp
    timeout: 5s

  ssl_expiry:
    prober: http
    timeout: 5s
    http:
      method: GET
      tls_config:
        insecure_skip_verify: false

Что мониторим из blackbox:

Уровень 5. Синтетический мониторинг (Selenium / Playwright)

Один из самых нелюбимых уровней у других подрядчиков и один из самых полезных у нас. Раз в 5 минут специальный бот заходит на критичные веб-сервисы и проходит типовой пользовательский сценарий. Если сценарий упал — алерт. У клиента из кейса мы держим три синтетических сценария:

Сценарий 1. «Бухгалтер логинится в 1С через RDP-Web»

// Playwright-сценарий /opt/synthetic/onec_login.spec.js
import { test, expect } from '@playwright/test';

test('1C login via RDP-Web', async ({ page }) => {
  await page.goto('https://1c-web.company.ru');
  await page.fill('#login', 'monitor.1c');
  await page.fill('#password', process.env.MON_PASSWORD);
  await page.click('button[type="submit"]');
  await expect(page.locator('text=Главное меню')).toBeVisible({ timeout: 30000 });

  // Проверяем, что справочник Контрагенты открывается
  await page.click('text=Справочники');
  await page.click('text=Контрагенты');
  await expect(page.locator('table.list')).toBeVisible({ timeout: 15000 });
});

Этот сценарий выполняется раз в 5 минут на отдельной VM с GUI и chromium-headed. Время выполнения, успех/неуспех и скриншот при ошибке шлются в Prometheus через pushgateway. На этом сценарии мы за 2025 год трижды поймали проблему «1С работает, но бухгалтерская версия конфы не отвечает на справочник Контрагенты» — это типичная ошибка после неудачного обновления конфы.

Сценарий 2. «Менеджер открывает заявку в Битрикс24»

Аналогичный, но для Битрикс24-on-premise. Логин, открытие сделки, проверка, что фид «Живая лента» отрисовался.

Сценарий 3. «Пробитие тестового чека на тестовой кассе»

Самое сложное. Раз в час система делает запрос к 1С API на пробитие тестового чека на 1 копейку. Чек пробивается на тестовой кассе, отправляется в ОФД, ждём подтверждение. Если ОФД ответил подтверждением — всё работает. Если нет — алерт.

Уровень 6. Бизнес-метрики (закрытие смены, статус ОФД, эквайринг)

Самый верхний уровень — это не «как работает инфраструктура», а «работает ли бизнес». Метрики здесь не технические, а бизнесовые:

Эти метрики я собираю двумя способами: либо через прямой SQL-запрос к БД 1С (Prometheus exporter с кастомными запросами), либо через webhook'и от самих систем. Для ОФД — отдельный скрипт, который раз в 5 минут дёргает API ОФД с авторизацией заказчика.

Алертинг: куда и кому

Хороший мониторинг без хорошего алертинга — это просто красивые графики. Мы используем строгую матрицу маршрутизации:

# Alertmanager route config
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    # P1 — критичные, ночь и день
    - match:
        severity: critical
      receiver: 'tg-duty-and-boss'
      group_wait: 0s
      repeat_interval: 30m

    # P2 — важные, 9:00-22:00
    - match:
        severity: high
      receiver: 'tg-duty'
      active_time_intervals:
        - working-hours

    # P3 — некритичные, только на почту
    - match:
        severity: warning
      receiver: 'email-team'
      repeat_interval: 12h

receivers:
  - name: 'tg-duty-and-boss'
    telegram_configs:
      - bot_token: 'XXXXXXXX'
        chat_id: -1001234567890
      - bot_token: 'XXXXXXXX'
        chat_id: 7296241   # Семёнов

  - name: 'tg-duty'
    telegram_configs:
      - bot_token: 'XXXXXXXX'
        chat_id: -1001234567890

Severity я выставляю руками для каждого триггера. P1 — это «бизнес стоит» (упал 1С, нет интернета, упал DC). P2 — «компонент деградирован, но работает» (один провайдер из двух, диск заполнен на 80%). P3 — «нужно посмотреть когда будет минутка».

Дежурство и эскалация

Команда ITfresh — 7 инженеров. Дежурный по неделе принимает все P1/P2 алерты на круглосуточной линии. Если инженер не реагирует в течение 5 минут на P1 — автоматический эскалейт мне в Telegram. Если я не реагирую 10 минут — эскалейт на резервного руководителя смены.

Что оказалось важнее всего за 2025 год

За год эксплуатации этой схемы у клиента из Москвы я могу честно сказать, какие уровни мониторинга реально окупились, а какие — нет:

Контр-нарратив: где SLA 99,98% — неправильная цель

Скажу непопулярное. Я считаю, что для большинства мелких офисов на 10-20 РМ гнаться за SLA 99,98% не нужно. Достаточно 99,5-99,9%. Простой математики: если месячный простой ИТ для маленькой компании стоит 50 000 ₽, а разница между 99,9% и 99,98% за год — это 7 часов в районе 14 000 ₽ потерь — стоит ли тратить лишние 100 тысяч на мониторинг и резервы? Часто нет.

SLA 99,98% оправдан там, где простой реально дорогой: производство с непрерывным циклом, торговля с большим оборотом онлайн-касс, медцентр с записью и ОМС-обменом. Если у вас бухгалтерская фирма и менеджеры вполне живут полчаса без 1С — не плати за «четыре девятки», возьми «три», и сэкономь.

FAQ: что чаще всего спрашивают клиенты

Что такое SLA 99,98% в реальных цифрах?

99,98% — это не более 1 часа 45 минут плановых и аварийных простоев в год. Для офиса 50 РМ это значит, что любая авария — упал 1С, отвалился интернет, отказал коммутатор — должна устраняться меньше чем за час. Дороже SLA — например 99,99% (52 минуты в год) — мы не предлагаем, потому что для МСБ это уже не оправдано экономически.

Зачем 6 уровней мониторинга, не достаточно одного Zabbix?

Один Zabbix покажет, что сервер 1С отвечает на ICMP, а сервис апп-сервера запущен. Но Zabbix не увидит, что 1С возвращает ошибку 500 на типовой проводке, что бухгалтер не может закрыть месяц, что чек-лист утренней проверки не пройден. Шесть уровней — это шесть точек зрения на инфраструктуру: от пинга до бизнес-метрики. Любой из них может первым поймать сбой, который не виден остальным.

Сколько стоит развернуть такую систему мониторинга?

Стартовый вариант на одном сервере с Zabbix + Prometheus + Grafana — около 80-120 тысяч рублей разовая работа за 5-7 рабочих дней инженера. Плюс мы сразу пишем пять-десять кастомных проверок под бизнес клиента — это ещё 30-50 тысяч. В абонплате после внедрения мониторинг входит в стандартный тариф ITfresh без доплаты.

Откуда мы знаем, что SLA реально 99,98% — не на бумаге?

Из самого мониторинга. Zabbix в режиме SLA-сервиса считает суммарную доступность по группе ключевых сервисов: интернет, 1С, файловый сервер, телефония. Раз в месяц мы выгружаем отчёт и шлём заказчику. За 2025 год по производственной компании из кейса было два инцидента общей длительностью 1 час 21 минуту — это 99,985%.

Какой сервис обязательно мониторить, если у нас бюджет на минимум?

Бизнес-метрику самого критичного для компании процесса. Для торговой компании — это онлайн-касса и обмен с эквайрингом. Для бухгалтерии — это закрытие смены 1С. Для производства — это ERP и MES. Если эта одна метрика зелёная — компания работает. Всё остальное — вспомогательно. Мы строим именно от бизнес-метрики и обвязываем её более низкими уровнями.

Итог

SLA 99,98% — не маркетинг, а методика. Шесть уровней мониторинга, грамотная матрица алертов, дежурная команда из 7 инженеров и честный отчёт раз в месяц. Производственная компания из кейса прожила 2025 год с двумя инцидентами на 1 час 21 минуту. Если у вас критичная инфраструктура и нужна реально измеряемая доступность — напишите, пришлю детальный план мониторинга под вашу специфику.

Похожая задача в вашей компании?

Расскажите, что у вас сейчас — пришлю план работ и оценку в течение рабочего дня.

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh