SLA 99,98% для офиса 50 РМ: 6-уровневая схема мониторинга от ITfresh
Шесть уровней мониторинга в виде пирамиды 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-уровневая схема мониторинга

К нам обратилась производственная компания — 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 год сработало четыре раза: два — реальное отключение питания, два — скачок напряжения в подъезде.

Уровень 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 — горизонт хранения шесть месяцев.

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 за пять минут больше двух событий с ID 2087 — это начинается проблема с DNS-репликацией. Алерт приходит до того, как пользователи успевают набрать номер поддержки.

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

Третий уровень — уже не про железо и ОС, а про сами приложения. Здесь параллельно с Zabbix работают Prometheus и Grafana. На практике получается так: 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)

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

Сценарий 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 });
});

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

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

Это тот же сценарий, только заточенный под Битрикс24-on-premise. Скрипт логинится, открывает сделку и проверяет, что фид «Живая лента» нормально отрисовался — без ошибок рендеринга и пустых блоков.

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

Вот тут, честно говоря, сложнее всего. Каждый час наша система сама стучится к 1С API и пробивает тестовый чек ровно на 1 копейку. Чек уходит через тестовую кассу в ОФД — и мы ждём подтверждения. Пришло подтверждение — значит, фискализация живая, всё работает. Не пришло — немедленно летит алерт. Именно так, а не через «проверить вручную утром».

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

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

Собираем эти метрики двумя способами. Первый — прямой 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% вполне хватает. Считайте сами: если час простоя стоит компании условные деньги, а разница между 99,9% и 99,98% за год — это около 7 часов, то при потерях в 50 000 ₽ в месяц недобор составит примерно 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С пингуется и сервис запущен. Но он не увидит, что 1С валит ошибку 500 на типовой проводке, что бухгалтер не может закрыть месяц, что чек-лист утренней проверки так и завис незакрытым. Именно поэтому у нас шесть уровней мониторинга — шесть разных точек зрения на инфраструктуру: от пинга до ключевой бизнес-метрики. И любой из этих уровней может поймать сбой, который остальные попросту не заметят.

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

Теперь про деньги. Базовый стек — Zabbix + Prometheus + Grafana на одном сервере — это 5–7 рабочих дней одного инженера, стоит 80–120 тысяч рублей. Плюс разработка 5–10 кастомных проверок под специфику бизнеса клиента — ещё 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

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

📄
Скачайте подробный разбор в PDF Кейсы, статистика, типовые ошибки и чек-лист самопроверки — 12 страниц
Скачать PDF

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

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

Письмо придёт в течение минутыНе нашли его во «Входящих» — загляните в папку «Спам» или «Промоакции» и нажмите «Не спам». Так все следующие выпуски будут приходить прямо в основную почту.
Реквизиты оператора персональных данных

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