Мониторинг сервера и сервисов офиса: как узнать о падении 1С раньше, чем позвонит бухгалтер

Есть один звонок, который я помню лет десять спустя. Половина двенадцатого, звонит главбух клиента и ледяным голосом спрашивает, почему 1С «висит уже сорок минут». Сервер упал в девять утра. Три часа никто не знал, кроме тех, кто пытался в неё зайти и материлcя молча. С тех пор я считаю мониторинг не роскошью для больших контор с айтишником в штате, а обязательной湿ой вещью для любого офиса, где есть хотя бы один сервер и бухгалтерия, которая сдаёт отчётность вовремя.

Почему в маленьком офисе про мониторинг обычно забывают

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

У меня на сопровождении сейчас порядка тридцати клиентов, и я разложил бы их на три группы. Первая — вообще без мониторинга, узнают о проблеме от пользователей. Вторая — Zabbix или что-то похожее, но настроено криво, алерты шлют на почту, которую никто не читает. Третья, самая маленькая, — три-пять точечных проверок, которые реально работают и реально спасают. Вот про третий вариант этот текст.

Дело не в деньгах. Бесплатных инструментов навалом. Дело в том, что никто не выделяет на это час-полтора. А зря — час на настройку экономит потом недели нервов и репутации перед клиентами, которым не ушли счета вовремя.

Что на самом деле роняет офисный сервер

За пятнадцать лет в аутсорсинге я видел десятки падений, и почти все они укладываются в четыре причины. Диск переполнился — раз. Кончилась оперативная память — два. Упала служба сервера 1С или SQL — три. Пропал интернет, и облачная база или клиент-банк стали недоступны — четыре. Пожары, вирусы, отключение электричества — это отдельная история, там нужен UPS и бэкапы, не мониторинг.

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

Память — вторая по частоте причина, особенно на терминальных серверах, где десять человек одновременно держат открытыми Excel с полусотней вкладок, 1С и Chrome с двадцатью табами. Классика: к обеду сервер начинает тормозить, к вечеру виснет насмерть, к утру бухгалтер уже в панике. А служба 1С сама по себе может упасть без всякой видимой причины — обновление криво встало, лицензионный сервер не достучался, антивирус решил проверить файл базы в самый неподходящий момент.

Минимальный набор: четыре метрики, которых достаточно

Я сознательно не советую мониторить всё подряд. Чем больше алертов, тем быстрее их начинают игнорировать — это называется alert fatigue, и это реальная проблема даже в крупных IT-отделах. Для офиса без штатного админа хватает четырёх показателей.

Свободное место на диске — порог 15-20% в зависимости от размера базы, для 1С лучше не 10%, а именно 15-20%, потому что резервная копия и временные файлы платформы тоже что-то весят. Оперативная память — алерт при загрузке выше 85-90% в течение пяти минут подряд, разовый скачок это норма. Доступность службы сервера 1С (agent.exe или ragent, зависит от версии) и службы SQL Server — банальная проверка «процесс жив, порт слушается». И четвёртое — доступность интернета, обычно пингом до 8.8.8.8 и до сайта самой 1С-Отчётности или клиент-банка, если работа критично зависит от облака.

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

Чем это настроить — без лишней инфраструктуры

Ставить полноценный Zabbix-сервер ради четырёх метрик — как покупать грузовик, чтобы раз в неделю съездить за хлебом. Хотя, если у клиента уже несколько площадок и десятки хостов, у нас как раз есть проект централизованного Zabbix именно под такие случаи. Но для одного офиса на 10-50 рабочих мест я обычно советую что-то из трёх вариантов попроще.

Первый — встроенные средства Windows Server: Task Scheduler плюс простой PowerShell-скрипт, который проверяет диск, память и службы раз в пять минут и при проблеме шлёт письмо через SMTP или сообщение в Telegram-бота. Пишется такой скрипт за час, работает годами без обслуживания. Второй вариант — бесплатные облачные сервисы вроде UptimeRobot или Healthchecks.io: сервер сам раз в минуту стучится «я живой», если пропал пинг дольше заданного времени — приходит алерт. Третий — уже готовые агенты вроде Zabbix Agent или PRTG в бесплатном режиме на 100 сенсоров, этого за глаза хватает на один сервер.

У себя в компании я в итоге пришёл к простой связке: PowerShell-скрипт на сервере плюс Telegram-бот. Стоит это ноль рублей в месяц, если не считать час моего времени на первичную настройку у клиента. Никакой отдельной инфраструктуры разворачивать не нужно — скрипт живёт на том же сервере, который он же и проверяет.

Куда должны прилетать алерты — и почему не на почту

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

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

И ещё: сообщение должно быть конкретным, а не «ошибка на сервере». Хороший алерт выглядит так — «Сервер OFFICE-SRV: диск D свободно 8%, порог 15%», «Служба 1С:Предприятие 8 остановлена, время 14:32». Тогда даже не самый технический человек в чате понимает масштаб проблемы и может позвонить мне с конкретикой, а не с фразой «что-то сломалось».

Реальный кейс: как это выглядит на практике

Возьму пример из своей практики — небольшая торговая компания, 18 рабочих мест, склад плюс офис продаж. Сервер на Windows Server 2019, база 1С:Управление торговлей на SQL Server Express. До настройки мониторинга падения случались раз в полтора-два месяца, обнаруживались всегда одинаково — звонок от менеджера склада, который не может провести отгрузку.

Настроили простую связку: скрипт PowerShell по расписанию каждые пять минут проверяет четыре параметра и пишет в Telegram-бота, созданного через BotFather за пять минут. За полгода эксплуатации бот трижды поймал реальные проблемы. Один раз — диск, забился журналами SQL Server, вовремя почистили. Второй — служба 1С встала после автоматического обновления Windows с перезагрузкой в три ночи, никто бы не узнал до девяти утра, а бот прислал сообщение в 03:07, я подключился удалённо и поднял службу до прихода первого сотрудника. Третий — упал интернет-канал у провайдера, но это уже не наша зона ответственности, зато директор смог сразу позвонить провайдеру, а не тратить час на выяснение, в чём вообще дело.

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

Типичные ошибки при настройке мониторинга своими силами

Первая ошибка — слишком чувствительные пороги. Если алерт на память срабатывает при 70% загрузки, а сервер стабильно так и работает весь день, через неделю все привыкают игнорировать сообщения бота. Порог нужно выставлять так, чтобы алерт означал реальную проблему, а не фоновый шум.

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

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

Частые вопросы

Нужен ли для этого выделенный IT-специалист в штате?
Нет, именно в этом смысл минимального набора. Настройка занимает час-два разово, дальше система работает сама и присылает уведомления. Обслуживать её может тот же человек, что и раньше отвечал за сервер по остаточному принципу — офис-менеджер, бухгалтер с техническим складом ума, или мы на аутсорсе.

Сколько стоит такой мониторинг в месяц?
Если делать своими силами на PowerShell и Telegram-боте — ноль рублей на софт, только разовая настройка. Готовые облачные сервисы вроде UptimeRobot бесплатны в базовом тарифе для нескольких проверок, платные планы начинаются от 500-1000 рублей в месяц и нужны, только если хостов и метрик становится много.

Чем это отличается от Zabbix, который вы ставите крупным клиентам?
Масштабом задачи. Zabbix — это платформа для десятков хостов, графиков за годы, эскалаций и интеграций с сервис-деском, её мы разворачиваем, когда у клиента реально сложная инфраструктура. Для одного сервера в офисе на 10-50 рабочих мест это как забивать гвоздь микроскопом — работать будет, но избыточно и требует постоянного внимания.

А если сервер уже в порядке, и падений давно не было?
Именно поэтому их и не видно — до момента, пока не случится. Мониторинг не чинит проблемы заранее, он экономит часы простоя, когда проблема всё же случится, а она случится, потому что диски заполняются, обновления ставятся криво, а провайдеры иногда падают вне зависимости от нашего желания.