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

Портрет клиента и его боли

Меня зовут Евгений Семёнов, я технический директор ITfresh — IT-аутсорсинг для юрлиц до 50 рабочих мест в Москве, собственные серверы в дата-центре МТС. Это финальная статья серии про NetXMS, и она устроена иначе, чем предыдущие: вместо теории — один сквозной кейс с настоящими узлами, порогами и статистикой за квартал. Клиент обезличен, цифры — нет. Если вы пропустили внедрение с нуля и статью про скрипты и интеграции — техника оттуда используется здесь на каждом шагу.

Итак, клиент: бухгалтерская компания, ведёт учёт нескольких десятков юрлиц. Внутри:

• 30 сотрудников в двух офисах, связанных VPN-туннелем;
• три сервера: терминальный (RDS, на нём же работают все базы 1С в режиме тонкого клиента), сервер 1С + MS SQL, файловый сервер с бэкапами;
• зоопарк периферии: сетевые МФУ, сканеры, ИБП;
• история обслуживания: приходящий админ раз в неделю, которого заменили нашим аутсорсингом.

Жалобы на момент приёмки — классическая тройка: «1С тормозит», «принтер не печатает», «утром не смогли зайти на терминалку». Всё — постфактум, всё — по звонку, каждый третий звонок — в панике.

Ключевая особенность именно бухгалтерского бизнеса — сезонность цены простоя. В обычный вторник час лежащей 1С — неприятность. Двадцатого числа месяца (зарплата, НДС) и в последнюю неделю квартала тот же час — сорванные сроки сдачи по десяткам клиентов фирмы, то есть прямые деньги и репутация. Мониторинг здесь нужен не «для порядка», а как страховка от простоя в конкретные даты. Это определило всю конфигурацию.

Что решили мониторить, а что осознанно нет

Карта мониторинга получилась из 25 узлов:

• 3 сервера — с полноценными агентами NetXMS;
• 2 интернет-шлюза (по одному на офис) и 3 коммутатора — по SNMP;
• 2 ИБП — по SNMP через сетевые карты управления;
• 6 сетевых МФУ и принтеров — по SNMP;
• сервер мониторинга следит и за собой (отдельный шаблон);
• 8 «реперных» рабочих станций — только ping-доступность.

Про рабочие станции — осознанное решение, о которое спотыкаются многие внедрения. Ставить агенты на все 30 машин можно, но незачем: отказ одной рабочей станции — это неудобство одного человека, которое он сам и сообщит. Наш принцип отбора: мониторим то, чей отказ заставляет звонить телефон — серверы, сеть, печать, интернет. Реперные станции по ping нужны только как индикатор «жив ли сегмент сети в дальнем углу офиса».

Бюджет решения: 0 ₽ на лицензии. Одна виртуальная машина под сервер NetXMS на уже существующем гипервизере клиента (2 vCPU, 4 ГБ RAM, 60 ГБ SSD) — то есть железо тоже не покупалось. Единственная статья затрат — инженерные часы, их итог посчитаю в конце.

Конфигурация по слоям

Слой 1: терминальный сервер

Самый «звонкий» узел — на нём работают все 30 человек. Собираем: загрузку CPU и памяти, число активных RDP-сессий (внезапный ноль в рабочее время — маркер проблемы доступа), состояние служб RDS, свободное место на томе профилей (порог 15%, профили пухнут незаметно) и срок действия RDP-сертификата — тем самым PowerShell-параметром из прошлой статьи, порог 21 день. Отдельный верхний порог на число сессий: если их вдвое больше сотрудников — кто-то плодит зависшие дубли, пора чистить.

Слой 2: сервер 1С + MS SQL

Сердце бизнеса. Процессы кластера (ragent, rphost — существование и число), службы SQL Server, TCP-порт менеджера кластера 1541, место на томах данных, журналов транзакций и tempdb — по журналам порог жёстче всех (25%): они умеют съесть диск за ночь. Плюс контроль длительности ночного обслуживания баз: если реиндексация, обычно заканчивающаяся к шести утра, ещё идёт в восемь — терминальный сервер встретит бухгалтеров тормозами. Ловим это простой проверкой факта завершения по свежести лог-файла задачи обслуживания.

Слой 3: файловый сервер и бэкапы

Свежесть бэкапов — File.Time.Modify по каталогам с архивами, порог 26 часов; контроль размера свежего архива (падение больше чем на 70% от вчерашнего — алерт); свободное место на томе бэкапов; состояние теневых копий — бухгалтеры удивительно часто просят «вернуть вчерашний файл». Ротация проверяется отдельно: каталог, где бэкапы только прибавляются и не удаляются, — это бомба с таймером на пару месяцев.

Слой 4: сеть и периферия

ИБП по SNMP: заряд батареи, признак работы от батареи (немедленная критика — в офисе пропало питание), и — важное — оценка оставшегося времени работы. Принтеры по SNMP: доступность и уровень тонера. Да, тонер в мониторинге — это не блажь: «принтер не печатает» в бухгалтерии в отчётный день — реальный инцидент, а картридж, заказанный за неделю по алерту «осталось 10%», — предотвращённый. Коммутаторы — доступность и ошибки на портах аплинков.

Слой 5: каналы связи

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

Слой 6: сервер мониторинга следит за собой

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

Пороги под сезонность бухгалтерии

Самая нестандартная часть кейса. У фирмы два режима жизни, и пороги в них должны отличаться:

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

Уведомления и регламент реагирования

Потока уведомлений два, и они принципиально разные:

• Дежурному инженеру ITfresh — всё: предупреждения, критика, восстановления. Технический язык, имена узлов, значения метрик.
• В Telegram-группу с клиентом — только «красные» события и только человеческим языком: не «DCI 4132 threshold violation», а «Заканчивается место под базами 1С на сервере, уже занимаемся». Уведомление о проблеме, отправленное клиенту раньше, чем он её заметил, — самый дешёвый способ купить доверие; спам техническими алертами — самый быстрый способ его потерять.

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

Раз в месяц клиент получает короткий отчёт на одну страницу: сколько инцидентов поймано, что предотвращено, какие узлы вызывают опасения, что рекомендуем заложить в бюджет (например, замену батарей ИБП — см. ниже). Это переводит мониторинг из невидимой технической услуги в понятную управленческую: директор фирмы видит, за что платит аутсорсеру, ещё до того, как что-то сломалось. Побочный эффект, которого мы не ожидали: отчёт стал аргументом самой фирмы в разговорах с её клиентами — «у нас инфраструктура под круглосуточным мониторингом» звучит убедительно, когда за словами есть цифры.

Статистика за первый квартал эксплуатации

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

• Два переполнения диска предсказаны за три дня. Журналы транзакций SQL после подключения двух новых клиентских баз начали расти быстрее обычного; график тренда показал «через 72 часа — ноль». Место расширили в плановое окно. Без мониторинга это была бы встающая посреди дня 1С — с вероятностью, по закону жанра, двадцатого числа.
• Служба печати перезапущена автоматически 7 раз. Тот самый рецепт самолечения из прошлой статьи: порог на зависшую очередь → рестарт спулера. Семь инцидентов «принтер не печатает» рассосались за минуту каждый, пользователи не заметили ни одного. До внедрения каждый такой был звонком и получасом ожидания.
• Деградация ИБП выявлена по времени работы от батареи. При двух коротких отключениях питания расчётное время автономии просело с 18 до 6 минут — батареи умирали. Заменили планово, за неделю до того, как очередное моргание света уронило бы серверы жёстко.
• Один инцидент прозевали — и это важная часть статистики. Завис сетевой сканер: SMB-шара, куда он складывает сканы, перестала принимать файлы, а по ping и SNMP устройство отвечало исправно. Узнали по звонку — как в старые времена. Вывод сделали: добавили проверку записи тестового файла в шару сканов. Мониторинг — итеративная штука: каждый пропущенный инцидент должен превращаться в новую проверку.

И честная метрика напоследок: жалобы «1С тормозит» не исчезли — было четыре за квартал. Изменилось другое: на каждую теперь есть график. В двух случаях виноват был тяжёлый отчёт, запущенный самим пользователем (видно по всплеску CPU его сессии), в одном — ночное обслуживание, заехавшее на утро, в одном — реальная нехватка памяти, после которой её расширили. Разговор «у вас всё тормозит» — «покажите когда, вот график» экономит часы разбирательств и переводит отношения из жалоб в инженерию.

Что из кейса переносится на юрфирму, клинику, торговую компанию

Ядро конфигурации — серверы, сеть, бэкапы, сертификаты, ИБП — идентично процентов на 80 для любой компании до 50 рабочих мест. Отраслевые отличия ложатся сверху:

Практический вывод для тех, кто захочет повторить: берите слои из этого кейса как чек-лист, замените «1С + SQL» на свою критичную систему — и вы получите 80% готовой карты мониторинга. Оставшиеся 20% — это как раз то знание о вашем бизнесе, которое в статье не напишешь.

Выводы и трезвые ограничения

Итоговая арифметика кейса:

• лицензии — 0 ₽; железо — 0 ₽ (ВМ на существующем гипервизоре);
• внедрение — 12 инженерных часов суммарно: установка сервера и агентов, шаблоны из нашего «золотого набора», две недели тюнинга порогов по паре часов;
• сопровождение — 2–4 часа в месяц по регламенту эксплуатации;
• результат за квартал — три класса инцидентов предотвращены до жалоб, семь самопочинок, один честно пропущенный инцидент, закрытый новой проверкой.

Теперь ограничения, о которых обязан сказать техдиректор, а не продавец. Мониторинг инфраструктуры отвечает на вопрос «что сломалось или скоро сломается». Он не отвечает на вопрос «почему 1С медленно проводит документы»: глубокая диагностика производительности 1С — замеры APDEX, расследование блокировок и ожиданий СУБД, анализ запросов конфигурации — это отдельная экспертиза с другими инструментами. NetXMS даст вам график, который покажет, когда было плохо; почему — предмет отдельной работы. Обещания «поставим мониторинг и 1С полетит» — маркер того, что вам продают не то.

На этом серия про NetXMS закончена: обзор, внедрение, интеграции, эксплуатация и кейс — полный цикл. Если после прочтения хочется такой же мониторинг, но чужими руками — приходите на аудит инфраструктуры: посмотрим, что у вас болит, и скажем честно, где хватит бесплатного NetXMS, а где нужно что-то ещё.