Кейс: мониторинг бухгалтерской фирмы на 30 рабочих мест — что мы поставили на контроль и что это дало за год

Меня зовут Евгений Семёнов, я технический директор «АйТи Фреш» — мы больше пятнадцати лет занимаемся IT-аутсорсингом московских компаний до 50 рабочих мест и держим собственные серверы мониторинга в дата-центре МТС. Это заключительная статья нашей серии про Zabbix: в обзоре мы разбирались, зачем малому бизнесу вообще система мониторинга, в пошаговом мануале ставили Zabbix 7.0 LTS с нуля, в статье про интеграции подключали Telegram, 1С и бэкапы, а в материале про эксплуатацию — боролись с шумом алертов и настраивали регламент сопровождения. Сегодня всё это собирается в одну картину: полный разбор внедрения в бухгалтерской компании на 30 рабочих мест — с картой метрик, таблицей трудозатрат, хроникой сработавших триггеров и расчётом окупаемости.

Исходная точка: как выглядит «у нас всё работает» на самом деле

Сразу честная оговорка, без которой этот текст был бы маркетинговой сказкой: кейс — композитный. Он собран из нескольких наших реальных внедрений в компаниях похожего профиля и масштаба. Все цифры, метрики и эпизоды — настоящие, но детали разных проектов сведены в одну обобщённую историю, а всё, что могло бы указать на конкретного клиента, изменено. Так я могу рассказывать откровенно — включая то, что у нас самих получилось не с первого раза.

Итак, бухгалтерская фирма: ведёт учёт нескольких десятков юрлиц, 30 сотрудников, свой небольшой серверный шкаф в офисе. К нам они пришли не потому, что прочитали умную статью про мониторинг, — а после конкретной аварии. В марте, в разгар сдачи годовой отчётности, на сервере с MS SQL переполнился том, где жила tempdb. База 1С перестала проводить документы, терминальный сервер, через который работали все, по сути встал. Полдня тридцать бухгалтеров пили чай и звонили клиентам с извинениями, а руководитель считал штрафные риски по срокам сдачи деклараций — у бухгалтерского аутсорсинга дедлайн жёстче не придумаешь: он прописан в Налоговом кодексе.

Приехав на аудит, мы нашли картину, которую видим у новых клиентов постоянно. Последняя успешно созданная резервная копия базы датировалась сорока днями ранее — задание тихо отваливалось после какого-то обновления, и никто этого не заметил. RAID-массив файлового сервера давно работал в состоянии degraded: один диск умер несколько месяцев назад, и всё это время данные жили без избыточности. При этом на вопрос «как у вас с IT?» до аварии все искренне отвечали: «да всё работает». Фраза «у нас всё работает» без системы мониторинга означает ровно одно: «мы не знаем, что у нас сломано».

Инфраструктура клиента и карта рисков

Хозяйство типичное для бухгалтерской компании такого размера, и именно поэтому кейс легко примерить на себя:

• терминальный сервер (RDS) — до 30 одновременных сессий, в них крутятся 1С:Бухгалтерия и ЗУП, офисный пакет и браузеры;
• отдельный сервер SQL — базы 1С, та самая tempdb, регламентные задания обслуживания;
• файловый сервер — договоры, сканы первички, архивы клиентов, теневые копии;
• контроллер домена — учётки, групповые политики, DNS/DHCP;
• NAS — приёмник резервных копий;
• сеть — роутер и два коммутатора;
• инженерка — ИБП на серверный шкаф и три МФУ, на которых печатаются акты, декларации и первичка;
• внешние сервисы — СБИС для сдачи отчётности и четыре клиент-банка, без которых работа встаёт так же верно, как без 1С.

Прежде чем настраивать хоть один шаблон, мы садимся с руководителем и составляем карту рисков — переводим бизнес-боли на язык метрик. Это самый важный час всего проекта: он определяет, что попадёт под контроль в первую очередь, а что не попадёт вовсе.

Обратите внимание: в левой колонке нет ни слова про процессоры и гигабайты. Бизнес болит сроками, деньгами и данными — и каждая строка правой колонки существует только потому, что отвечает на строку левой.

Что поставили на контроль: полная карта метрик

После первичной настройки и месяца доводки на сервере мониторинга собралось порядка 450 элементов данных. Звучит внушительно, но большая часть приезжает автоматически — через низкоуровневое обнаружение дисков, сетевых интерфейсов и служб в стандартных шаблонах. Раскладка по группам получилась такой:

• терминальный сервер — 78 метрик: CPU, память, диски, число RDP-сессий, очередь печати, службы;
• SQL + кластер 1С — 96 метрик: службы, память процессов, место под базами и tempdb, длительность бэкапа;
• файловый сервер — 54 метрики: тома, SMART, RAID, теневые копии, служба VSS;
• контроллер домена — 38 метрик: службы AD, DNS, DHCP-scope, репликация времени;
• NAS — 26 метрик: место, диски, свежесть и размер файлов копий;
• роутер и два коммутатора — 88 метрик: SNMP-интерфейсы, ошибки портов, загрузка канала, CPU;
• ИБП — 24 метрики: заряд, нагрузка, напряжение на входе, температура, режим работы;
• три МФУ — 27 метрик: уровень тонера, счётчики страниц, статусы ошибок по SNMP;
• внешний контур — 18 метрик: web-сценарии до СБИС и банков, проверка офиса снаружи.

Терминальный сервер: сессии важнее процессора

Стандартный набор CPU/RAM/диски здесь вторичен. Главная метрика терминалки бухгалтерской фирмы — количество активных RDP-сессий. Мы повесили на неё триггер не только «сессий слишком много», но и обратный, на аномально низкое значение: если в рабочий день отчётного месяца к десяти утра подключились три человека вместо обычных двадцати пяти — с доступом что-то не так, даже если все графики сервера идеально зелёные. Сервер может быть здоров, а люди — не могут работать: сломался шлюз, слетела лицензия RDS, легла сеть в опенспейсе. Аномалия посещаемости ловит весь этот класс проблем одной метрикой. Вторая специфичная вещь — очередь печати: зависший спулер в день, когда печатаются сотни актов сверки, по последствиям равен упавшему серверу.

1С и SQL: прогноз вместо констатации

Службы кластера 1С, число и память процессов rphost, доступность опубликованной базы по HTTP — всё это мы подробно разобрали в статье про интеграции, здесь эти шаблоны просто применены. Ключевое добавление кейса — предиктивные триггеры на место под базами. Клиент пострадал не от того, что диск кончился, а от того, что об этом узнали в момент, когда он кончился. Штатная функция forecast() в Zabbix 7.0 строит тренд по истории метрики и отвечает на вопрос «сколько будет через N дней». Триггер на томе с базами и tempdb выглядит так:

# Прогноз свободного места на томе с базами SQL.
# Берём тренд за 2 недели и смотрим на 5 дней вперёд:
# если предсказанный остаток меньше 10 ГБ — предупреждение.
forecast(/SQL-server/vfs.fs.size[D:,free],2w,5d)<10G

# Дублирующий триггер той же идеи через timeleft():
# сколько времени осталось до нуля при текущем тренде
timeleft(/SQL-server/vfs.fs.size[D:,free],2w,0)<5d

Разница с классическим порогом «осталось меньше 10%» принципиальная: обычный триггер сообщает о проблеме, предиктивный — о будущей проблеме, пока она ещё решается спокойным письмом «запланируйте расширение тома на выходные». Отдельно контролируем длительность ночного обслуживания SQL: если бэкап, который всегда шёл сорок минут, вдруг идёт три часа — что-то изменилось, и лучше выяснить что до того, как он перестанет влезать в ночное окно.

Файловый сервер: место, тени и VSS

Помимо очевидного места на томах — две неочевидные проверки. Первая — состояние теневых копий: для бухгалтерии VSS-снимки это «машина времени», которой пользуются каждую неделю («я вчера перезаписала не тот файл»), и остановившаяся служба VSS означает, что машина времени молча перестала записывать. Вторая — SMART и статус RAID-массива через утилиту контроллера: именно эта пара проверок закрывает историю с degraded-массивом, который у клиента прожил незамеченным несколько месяцев.

Сеть и инженерка: SNMP-дешёвка с дорогим эффектом

Роутер и коммутаторы отдают по SNMP загрузку и ошибки портов — настройка на десять минут по стандартным шаблонам. ИБП рассказывает про заряд батареи, нагрузку и температуру; триггер на «работаем от батареи дольше двух минут» отправляет отдельное оповещение, потому что это сигнал к контролируемому завершению работы серверов. А самый недооценённый пункт — тонер трёх МФУ. Коллеги-айтишники традиционно посмеиваются над мониторингом принтеров, но именно предупреждение «тонер ниже 15%, закажите картридж» бухгалтерия вспоминает добрым словом чаще, чем все наши серверные подвиги вместе взятые.

Внешний контур: смотрим изнутри и снаружи одновременно

Доступность СБИС и клиент-банков мы проверяем с площадки клиента — штатными web-сценариями Zabbix, которые ходят на шлюз СБИС и страницы входа банков именно из офисной сети. Это принципиально: сервис может быть жив «вообще», но недоступен конкретно из этого офиса — из-за провайдера, маршрутизации или включённого кем-то фильтра. Одновременно наша внешняя нода в ЦОД МТС проверяет офис снаружи: отвечает ли канал, жив ли RDP-шлюз. Если офис полностью потеряет интернет, изнутри тревога уйти не сможет физически — её отправит внешняя точка наблюдения.

Реагирование под ритм бухгалтерии: календарь severity

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

Никакой экзотики для этого не нужно — хватает штатных механизмов. Maintenance-периоды, которые обычно используют для подавления тревог на время плановых работ, мы применили «наоборот»: спокойные периоды получили окна пониженной чувствительности для некритичных метрик, а на отчётные месяцы заведены отдельные Actions с условием по времени — с более короткими шагами эскалации и расширенным списком получателей. Предупреждение, которое в августе спокойно ждёт утреннего разбора, в апреле дежурный получает немедленно.

Вторая часть организации реагирования — два разных потока информации. В чат с главным бухгалтером бот пишет только статусы уровня бизнеса: «1С работает штатно» и «зафиксирована проблема, работаем, доступ восстановим к 14:30». Ни слова про rphost, гигабайты и проценты — этот шум главбуху не нужен и только подрывает доверие к каналу. Дежурному инженеру, наоборот, уходит полная техническая картина с именем узла, метрикой и ссылкой на график. Одно событие — два языка. По нашему опыту, это вообще главный секрет «приживаемости» мониторинга у нетехнического заказчика: он видит понятный ему сервис, а не поток иероглифов.

Внедрение в цифрах: 18 человеко-часов и ноль рублей лицензий

Развенчаю миф о том, что «нормальный мониторинг — это проект на месяцы». Вот фактические трудозатраты этого кейса, от первого визита до передачи в сопровождение:

Железо: виртуальная машина 2 vCPU / 4 ГБ ОЗУ на уже имеющемся гипервизоре клиента — для 450 метрик этого хватает с большим запасом, отдельный сервер покупать не пришлось. Лицензии: 0 рублей — Zabbix распространяется под AGPLv3 без ограничений по узлам и метрикам. Для сравнения: коммерческая система мониторинга на такое же количество сенсоров (а 450 элементов данных — это уже уровень «от 500 сенсоров» в тарифных сетках) обошлась бы от ста тысяч рублей в год только за право пользования, не считая продления. За эти деньги здесь куплено восемнадцать часов инженерной работы — разница в том, что работа остаётся у клиента навсегда, а лицензия — до конца оплаченного года.

Год спустя: какие триггеры реально сработали и что предотвратили

Ценность мониторинга измеряется не количеством метрик, а событиями, которые не стали авариями. Вот честная хроника года — четыре предотвращённых инцидента и один ложный, о котором тоже расскажу.

Эпизод 1, январь: forecast поймал диск SQL за шесть дней. Тот самый предиктивный триггер сообщил: при текущем темпе роста баз свободное место на томе SQL закончится через шесть дней — аккурат к пику январской отчётности. Мы спокойно согласовали работы, в выходные расширили том, в понедельник бухгалтеры пришли и ничего не заметили. Сравните с исходной точкой кейса: та же самая причина год назад стоила клиенту полудня простоя тридцати человек. Одна и та же проблема, два сценария — вся разница в шести днях форы.

Эпизод 2, апрель: SMART предупредил о смерти диска в RAID. На файловом сервере у одного из дисков массива поползли переназначенные секторы — SMART-триггер сработал до того, как контроллер выкинул диск из массива. Диск заменили по гарантии, ребилд прошёл на живом массиве без деградации и потери избыточности. Это зеркальное отражение второй находки первичного аудита: тогда массив месяцами жил degraded, и никто не знал.

Эпизод 3, июнь: бэкап замолчал — узнали через 12 часов, а не через 40 дней. Очередное обновление Windows сломало задание резервного копирования — то же самое, что когда-то произошло у клиента до нас. Разница: триггер nodata() на отчёте задания поднял тревогу через двенадцать часов тишины. Задание починили в тот же день. Сорок дней без копий против двенадцати часов — это, пожалуй, самое наглядное «до/после» всего кейса.

Эпизод 4, октябрь: тонер. Скучнейший триггер года — «тонер МФУ ниже 15%» — сработал за неделю до пика печати актов сверки. Картридж приехал заранее. Я упоминаю этот эпизод не ради технического содержания, которого тут нет, а потому что именно его бухгалтерия вспоминает добром: закончись тонер в день массовой печати — и это был бы вполне осязаемый простой процесса, никак не связанный с серверами.

Эпизод 5, честный ложный: логон-шторм. Первые две недели после запуска триггер на CPU терминального сервера исправно голосил каждое утро с 8:50 до 9:20 — когда двадцать пять человек одновременно входят в сессии и открывают 1С, процессор совершенно законно уходит в полку. Это нормальное поведение, а не проблема. Вылечили порогом с учётом времени: в окно утреннего входа порог выше и требуется большая длительность превышения. Рассказываю это специально: не бывает внедрения без периода ложных срабатываний, и честный подрядчик не скрывает этот этап, а закладывает его в план — те самые четыре часа тюнинга первого месяца из таблицы выше. Подробнее о гигиене алертов — в статье про эксплуатацию Zabbix.

Что НЕ стали мониторить и почему

Хороший план мониторинга определяется не только тем, что в него вошло, но и тем, что из него сознательно выброшено. Наши отказы в этом кейсе:

• APDEX и замеры производительности 1С. Для тридцати рабочих мест инструментальный контроль скорости проведения документов избыточен: субъективная обратная связь («сегодня 1С тормозит») приходит быстрее, чем настроишь замеры, а стоимость сопровождения этой подсистемы не окупается. На двухстах рабочих местах ответ был бы другим.
• Рабочие станции поимённо. Мы не следим за диском и памятью каждого из тридцати компьютеров — только за агрегатами: сколько машин в сети, на всех ли живо антивирусное ПО и какие версии стоят (это закрывается инвентаризацией через агентов). Персональный мониторинг тридцати ПК генерирует шум, который никто никогда не разбирает.
• Температура в серверном шкафу. В первую очередь не вошла — не было датчика, а городить проверку «по косвенным признакам» мы не стали. Через полгода датчик поставили отдельным мини-этапом, и метрика появилась. Нормальная практика: мониторинг — не разовый проект, а растущая система.

Принцип, которым мы руководствуемся: каждый пункт мониторинга должен окупать собственное обслуживание. Метрика, на которую никто не реагирует, — это не контроль, а балласт: она ест внимание дежурного, место в базе и доверие к системе. Меньше метрик с внятными сценариями реакции полезнее, чем «мониторим всё» без единого назначенного ответственного.

Как перенести этот шаблон на юрфирму и медицинский центр

Разобранный каркас не привязан к бухгалтерии намертво — при переносе на другую отрасль меняется процентов двадцать метрик, остальное остаётся стандартным ядром из этой серии статей.

Юридическая фирма

Ядро то же: терминальный или файловый сервер, домен, бэкапы, сеть, ИБП. Смещаются акценты. Центр тяжести — файловый сервер с делами и договорами: здесь жёстче контроль теневых копий и прав доступа, потому что цена утёкшего или испорченного документа выше, чем цена часа простоя. Вместо СБИС во внешнем контуре — доступность СЭД и судебных сервисов, через которые подаются документы и отслеживаются заседания: пропущенный срок подачи для юристов — то же, что для бухгалтеров дедлайн ФНС. И заметно строже требования к защите самой панели мониторинга: она видит структуру всей сети, поэтому доступ — только по VPN и с двухфакторной аутентификацией.

Медицинский центр

Здесь замен больше. Место 1С-бухгалтерии занимает МИС — медицинская информационная система, и её доступность критична по-особому: простой означает пустые слоты в расписании врачей, то есть прямые невозвратные потери выручки — приём, который не состоялся в 10:30, нельзя «допровести вечером», как бухгалтерский документ. Контроль ИБП из желательного становится обязательным — от питания зависит оборудование, а не только серверы. И добавляется контур требований 152-ФЗ к персональным медицинским данным: изолированный сегмент сети под контролем, отдельное внимание к бэкапам и доступам. Каркас при этом узнаваем: те же web-сценарии, те же forecast-триггеры на диски, тот же календарь нагрузки — только вместо отчётных месяцев у медцентра сезонные пики.

Общий вывод по переносу

Меняется предметная часть — «что именно болит у этого бизнеса», и под неё первая таблица этой статьи переписывается заново за час разговора с руководителем. Технический каркас — сервер Zabbix, агенты через GPO, SNMP-инженерка, предиктивные триггеры, два потока оповещений — переезжает между отраслями практически без изменений. Именно поэтому мы и потратили целую серию статей на стандартную часть: она у всех одна.

Выводы и ROI одним абзацем

Считаем на калькуляторе, без магии. Внедрение — 18 человеко-часов, сопровождение — около 2 часов в месяц (разбор дайджестов, актуализация порогов, проверка самой системы), итого за первый год порядка 42 часов инженерного времени. На другой чаше весов — один-единственный предотвращённый простой уровня «исходной точки»: полдня без работы для 30 сотрудников. При средней зарплате бухгалтера в Москве около 100 тысяч рублей сотрудник обходится работодателю со взносами примерно в 150 тысяч в месяц, то есть около 900 рублей в час. Полдня простоя — 30 человек × 4 часа × 900 рублей = порядка 108 тысяч рублей прямых потерь по ФОТ, ещё до штрафных рисков по срокам сдачи отчётности и репутационных издержек перед клиентами. За год мониторинг перехватил четыре таких сценария. Иными словами, система окупила бы себя первым же январским эпизодом с диском SQL — всё остальное работает в плюс.

На этом Zabbix-серия завершена. Если собрать её в одну строку: зачем → как поставить → как заставить реагировать → как эксплуатировать без шума → и этот кейс как доказательство, что всё вместе работает на реальном малом бизнесе. Если хотите такую же картину по своей инфраструктуре — мы в «АйТи Фреш» начинаем с бесплатного экспресс-аудита: посмотрим, что у вас «всё работает» на самом деле, и покажем карту рисков до того, как её покажет авария. Пишите в Telegram @ITfresh_Boss или звоните +7 903 729-62-41.