Кейс: как мы построили мониторинг «здоровья 1С» на Monq CE для бухгалтерской компании на 40 рабочих мест

Исходная точка: инфраструктура и боли клиента

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы больше пятнадцати лет обслуживаем IT-инфраструктуру московских компаний до пятидесяти рабочих мест и держим собственные серверы в дата-центре МТС. Этот кейс — собирательный и обезличенный, но каждая деталь в нём взята из реальных внедрений у бухгалтерских фирм, которые мы сопровождаем. Он завершает серию про Monq: до этого были обзор Community Edition, установка, подключение Zabbix и Prometheus под зонтик и регламент эксплуатации.

Клиент — бухгалтерская компания, ведёт учёт примерно сотни организаций-заказчиков. Сорок рабочих мест, из них десять удалённых. Инфраструктура типовая для отрасли:

• Гипервизор с шестью виртуальными машинами, второй хост — резервный, слабее.
• Терминальный сервер, на котором сорок человек работают в 1С:Бухгалтерии и 1С:Зарплате через RDP.
• Отдельный сервер 1С с MS SQL: около тридцати информационных баз, самые крупные — по 40–60 ГБ.
• Файловый сервер с архивом документов и сканов.
• Система сдачи отчётности и банк-клиенты на терминалке, криптопровайдер, два десятка сертификатов электронной подписи разных организаций.
• Два интернет-канала с автоматическим переключением на маршрутизаторе.
• Zabbix, поставленный прошлым подрядчиком: 18 хостов, стандартные шаблоны, уведомления на почту, которую никто не читал.

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

Почему выбрали Monq CE, а не платный продукт или голый Zabbix

Мы рассматривали три варианта: оставить Zabbix и довести его до ума, поставить коммерческую зонтичную систему, поставить Monq Community Edition поверх Zabbix. Аргументы свелись в таблицу, которую показывали директору:

Решающими стали три вещи. Бюджет на софт — ноль, и это не обсуждалось. Десяти пользователей CE хватает: два инженера ITfresh, ИТ-ответственный клиента и директор. И требование «российское ПО»: у компании есть заказчики с госучастием, которые задают этот вопрос при проверках. Zabbix мы сознательно оставили сборщиком метрик под зонтиком — его шаблоны под Windows и SQL работали нормально, менять их было незачем.

Проектируем сервисную модель от бизнес-процессов, а не от серверов

Первое, что мы сделали, — не открыли консоль, а сели с директором и двумя ведущими бухгалтерами и спросили: без чего ваша работа останавливается? Получилось три бизнес-сервиса:

1. «Работа в 1С» — сорок человек могут войти на терминальный сервер, открыть свои базы и проводить документы с приемлемой скоростью.
2. «Сдача отчётности» — с терминалки доступен портал оператора отчётности, криптопровайдер и сертификаты действительны, интернет работает хотя бы по одному каналу.
3. «Зарплатный контур» — базы 1С:Зарплаты доступны, обмен с банк-клиентами проходит, файловый сервер с ведомостями на месте.

Для каждого сервиса мы нарисовали дерево зависимостей вниз до конкретных дисков и служб. Для «Работы в 1С» оно выглядело так: сервис ← терминальный сервер (служба удалённых рабочих столов, лицензирование, свободная память, очередь процессора) ← сервер 1С (агент сервера, рабочие процессы, кластер) ← MS SQL (служба, блокировки, время отклика, диск с базами, диск с журналами транзакций) ← гипервизор (датастор, хост) ← сеть (коммутатор, маршрутизатор).

В Business-редакции это дерево один в один переносится в РСМ, и здоровье сервиса считается автоматически. В CE дерево осталось у нас в документации, а в системе его роль сыграли два механизма: синтетическая проверка каждого сервиса «глазами пользователя» (она и есть статус плитки) и пороги по метрикам компонентов, которые предупреждают о проблеме раньше, чем синтетика покраснеет.

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

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

Сбор данных мы разделили по слоям. Zabbix остался там, где он силён, Monq взял на себя логи, синтетику и единую консоль.

Самая полезная проверка из всех — синтетический вход в 1С. Раз в десять минут сервисная учётка заходит на терминальный сервер, открывает тестовую базу через тонкий клиент и выполняет простой запрос; измеряются три времени: до рабочего стола, до открытия базы, до результата запроса. Эти три числа лучше любого счётчика процессора говорят, как сейчас работается бухгалтеру. Порог «открытие базы дольше 20 секунд три раза подряд» — жёлтый статус сервиса, «вход не удался» — красный.

Ловим «тормозит после 16:00» данными

Хроническая жалоба, ради которой во многом всё и затевалось, разобралась за первые две недели — просто потому, что данные впервые оказались в одном месте с общей осью времени. На одном экране мы положили рядом четыре ряда: число активных сеансов RDP, время отклика SQL, загрузку диска с базами и события из журнала Windows сервера SQL.

Картина оказалась такой. В 15:50 стартовало задание резервного копирования баз SQL, настроенное прошлым подрядчиком «на вечер» — когда-то вечер начинался в 18:00, потом расписание сдвинули ради ночного окна гипервизора и забыли. Бэкап тридцати баз выедал дисковую очередь на полтора часа. Одновременно в 16:00 удалённые сотрудники из второго офиса заканчивали внешние встречи и массово заходили в 1С — число сеансов вырастало с 25 до 38. Два фактора накладывались, время отклика SQL прыгало с 20 до 400 миллисекунд, и бухгалтеры получали «тормозит».

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

Алерты и автоматизация: предупреждать, а не констатировать

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

• Диск с базами SQL заполнен на 80% (красный — 90%).
• Диск с журналами транзакций растёт быстрее 5 ГБ в сутки — признак, что модель восстановления и обрезка журналов разъехались.
• Сертификат любой из двадцати электронных подписей истекает через 14 дней (красный — 3 дня). Раньше это обнаруживалось в день сдачи отчёта.
• Задание резервного копирования не отчиталось об успехе к 8:00 утра.
• Время синтетического входа в 1С превышает 20 секунд три раза подряд.
• Основной интернет-канал упал, работа идёт через резервный (сервис зелёный, но запас прочности кончился).
• Свободной памяти на терминальном сервере меньше 15% при числе сеансов ниже обычного — утечка в каком-то сеансе.

Красные пороги — классика: хост недоступен, служба 1С или SQL не запущена, вход не удался, интернет отсутствует по обоим каналам.

Автоматизацию в Community Edition мы проектировали с учётом единственного обработчика: сценарии короткие и быстрые. Всего их три. Первый — маршрутизация уведомлений: жёлтые события идут в рабочий чат инженеров ITfresh, красные — дополнительно дежурному звонком через бота и ИТ-ответственному клиента. Второй — подавление шторма: при событии «хост недоступен» на десять минут глушатся уведомления по виртуальным машинам этого хоста. Третий — сбор диагностики: при жёлтом статусе сервиса «Работа в 1С» no-code сценарий запрашивает у Zabbix текущие значения ключевых метрик терминалки и SQL и складывает их одним сообщением в чат, чтобы инженер открывал инцидент уже с данными. На этом масштабе один обработчик не узкое место: очередь из трёх сценариев отрабатывает за секунды.

Календарные пороги, появившиеся в Monq 9.2, сняли отдельную головную боль: в последние пять рабочих дней квартала пороги по нагрузке SQL и числу сеансов мы подняли, потому что закрытие периода — это штатная пиковая нагрузка, а не авария. Раньше под это заводили отдельные правила и включали-выключали руками.

Экран для директора и ежемесячный отчёт

Директор получил отдельную учётку и один дашборд: три плитки «1С», «Отчётность», «Зарплата» со статусом по синтетике, под ними — лента событий за неделю человеческим языком. Мы отдельно переписали названия порогов: вместо «Disk C: free space < 20%» — «Заканчивается место под базы, инженер предупреждён». Это заняло вечер и дало больше доверия, чем любые презентации.

Ежемесячный отчёт в CE мы собираем полуавтоматически: доступность каждого сервиса по результатам синтетики (доля зелёных проверок за месяц), список инцидентов с длительностью, список предотвращённых проблем — тех самых жёлтых событий, по которым инженер успел отработать до простоя. В Business-редакции этот отчёт формировался бы модулем отчётов по расписанию; у нас это час работы ответственного инженера в первый рабочий день месяца. Для компании такого размера разница в цене лицензии это оправдывает.

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

Результаты за первый квартал

Затраты: 0 рублей на лицензии; две недели работ внедрения (из них три дня — разговоры с бухгалтерами о том, что для них «работает»); виртуальная машина под платформу — 8 ядер, 32 ГБ памяти, 200 ГБ SSD на нашей площадке в ЦОД МТС, соединённая с офисом клиента туннелем; сопровождение — 2–3 часа в месяц по регламенту плюс реакция на события в рамках договора аутсорсинга.

Чего не получилось и что мы бы сделали иначе. Дерево зависимостей в документации, а не в системе, — это компромисс: когда в инфраструктуре что-то меняется, его надо не забыть обновить руками. Для трёх сервисов терпимо, для десяти уже нет — и это граница, за которой мы рекомендовали бы клиенту считать Business-редакцию или сокращать амбиции. И второе: синтетический вход в 1С мы сначала сделали раз в 30 минут — оказалось слишком редко, пропускали короткие деградации; десять минут — рабочий интервал.

Как повторить этот кейс у себя: шаблон для отрасли

Модель переносится на другие отрасли почти без изменений — меняются только сервисы и синтетика.

• Юридическая фирма. Сервисы: «Работа с делами» (файловое хранилище, система документооборота), «Правовые базы» (справочно-правовая система и её обновления), «Почта и календарь». Синтетика: открытие документа из хранилища, поиск в правовой базе, отправка тестового письма наружу и обратно.
• Медицинская клиника. Сервисы: «Приём пациентов» (МИС, расписание), «Касса и фискализация» (кассовое ПО, ОФД), «Лаборатория и интеграции». Здесь требование российского ПО и хранения данных в контуре — не пожелание, а необходимость, и self-hosted Monq закрывает его. Синтетика: вход в МИС, пробитие тестового чека в режиме без фискализации, доступность ОФД.
• Торговая компания. Сервисы: «Продажи» (1С:УТ, сайт, терминалы сбора данных), «Склад» (Wi-Fi, сервер обмена), «Доставка» (интеграции со службами). Синтетика: оформление тестового заказа, обмен с сайтом.

Мини-чек-лист старта из 10 шагов

1. Сесть с руководителем и ключевыми пользователями: без чего останавливается работа? Получить 3–5 сервисов, не больше.
2. Для каждого сервиса нарисовать дерево зависимостей до дисков и служб — на бумаге, до консоли.
3. Развернуть Monq CE на отдельной площадке или втором гипервизоре (см. статью про установку).
4. Оставить существующий Zabbix сборщиком, подключить его вебхуком и коннектором (см. статью про зонтик).
5. Для каждого сервиса сделать синтетическую проверку «глазами пользователя» — это и есть статус плитки.
6. Настроить 5–7 жёлтых порогов, которые предупреждают за часы и дни, и красные — по недоступности.
7. Подключить логи терминалки и SQL; положить метрики и логи на один экран времени.
8. Сделать три сценария автоматизации: маршрутизация, подавление шторма, сбор диагностики.
9. Собрать дашборд руководителя с человеческими названиями и показать его ему лично.
10. Записать регламент эксплуатации и паспорт системы (см. статью про эксплуатацию) и назначить ответственного.

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