Шесть уровней мониторинга в виде пирамиды 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-уровневая схема мониторинга

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, которые приходят на нашу круглосуточную линию. Если вдруг инженер не отреагирует на P1-алерт в течение 5 минут, то происходит автоматический эскалейт прямо мне в 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 на одном сервере, — это разовая работа, которая занимает примерно 5-7 рабочих дней одного инженера и стоит около 80-120 тысяч рублей. Кроме того, мы сразу же разрабатываем и настраиваем пять-десять кастомных проверок, которые идеально подходят под специфику бизнеса клиента — это ещё где-то 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

Похожие статьи

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.