Кейс: мониторинг сети бухгалтерской фирмы на 40 рабочих мест — от «интернет опять тормозит» до предсказуемой инфраструктуры за неделю

Исходная точка: как выглядит сеть бухгалтерской фирмы до мониторинга

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

Итак, клиент: бухгалтерская компания, 40 рабочих мест на двух этажах офисного здания. Сердце инфраструктуры — терминальный сервер, на котором крутятся 1С и сдача отчётности; рядом файловый сервер и маленький гипервизор. Сеть: роутер, четыре коммутатора разных лет и производителей (два управляемых, два — «как получилось»), шесть точек Wi-Fi, два ИБП, три сетевых МФУ.

Жалобы, с которыми пришли, звучали знакомо любому аутсорсеру:

• «1С отваливается» — терминальные сессии периодически замирают или рвутся;
• «интернет тормозит после обеда» — стабильно, как по расписанию;
• «принтер на втором этаже живёт своей жизнью» — то печатает, то нет.

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

Почему именно для бухгалтерии простой сети — это деньги с точной ценой

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

Есть и техническая специфика, которая делает бухгалтерию требовательнее среднего офиса:

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

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

Неделя внедрения по дням

День 1: аудит и восстановление доступа к железу

Инвентаризация того, что известно; сброс и восстановление доступа к коммутатору с утерянным паролем (через консольный порт, с сохранением конфигурации); заведение всех кредов в наш менеджер паролей. Побочный результат первого дня — впервые за годы у клиента появился полный список сетевого железа с адресами.

День 2: сервер мониторинга и SNMP на ядре

На имеющемся гипервизоре — небольшая ВМ (2 vCPU, 4 ГБ, SSD), в ней LibreNMS в Docker: подъём стека занимает вечер, подробную инструкцию я публиковал отдельно. Включаем SNMP на роутере и управляемых коммутаторах: read-only community, доступ только с адреса сервера мониторинга.

День 3: автообнаружение — сеть нашлась сама

Запускаем автообнаружение и получаем главный сюрприз проекта: 58 устройств вместо ожидаемых 40. Среди находок:

• неучтённый пятипортовый свитч под столом в отделе зарплаты — в него было воткнуто три рабочих места, и именно за ним позже нашлась часть проблем с «тормозит»;
• чья-то личная точка Wi-Fi, принесённая из дома и воткнутая в розетку сети — открытая, с паролем «12345678», мост в корпоративную сеть для всего района;
• старый NAS, про который забыли, — с публичной шарой и бэкапами двухлетней давности;
• несколько «серых» устройств без имён, опознанных по MAC-адресам.

Личную точку выключили в тот же день. Это, кстати, типовой результат: автообнаружение на «неизвестной» сети всегда находит на 20–40% больше, чем числится в головах.

Дни 4–5: серверы, ИБП, принтеры, структура

Добавляем терминальный и файловый серверы, гипервизор, оба ИБП (SNMP-карты были, но никогда не настраивались), МФУ. Раскладываем всё по группам — «ядро сети», «серверы», «ИБП», «печать», «Wi-Fi», по этажам-локациям. Отключаем лишние модули опроса, чтобы не собирать мусор.

Дни 6–7: алерты, дашборд, передача

Включаем наш стартовый набор правил с задержками против ложных срабатываний, транспорт в Telegram-канал дежурной смены, собираем дашборд и показываем клиенту, что теперь видно. С этого момента площадка стоит на мониторинге у нашей смены.

Что вскрыли первые графики: диагностика по данным вместо гаданий

Дальше началось самое интересное. Две недели система просто копила графики — и почти каждая жалоба из списка «до» получила точный диагноз.

«Тормозит после обеда» = аплинк этажа на 100 Мбит/с

График загрузки аплинка второго этажа показал характерную «полку»: после обеда трафик упирался в ровный потолок 100 Мбит/с — при том что порты гигабитные. Причина: старый патч-корд с перебитой парой, из-за которого порт согласовался на 100/full. Замена куска кабеля стоимостью триста рублей закрыла жалобу, которую до этого «лечили» перезагрузкой роутера полгода. Без графика эту полку не видел никто: спидтест с первого этажа показывал честные сотни мегабит.

ИБП главного узла: 4 минуты вместо 20

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

Ошибки CRC на порту МФУ

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

Терминальный сервер: факты вместо ощущений

Графики CPU терминального сервера показали регулярные пики до 100%, совпадающие по времени с жалобами на «1С зависла». Это уже не сетевой вопрос, но теперь у 1С-подрядчика клиента были точные данные: когда, как долго, с какой периодичностью. Разговор «у вас тормозит — у нас всё нормально» превратился в разговор по графику.

Настроенные алерты под специфику бухгалтерии

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

• порог реакции на недоступность роутера и терминального сервера ужимается с 5 минут до 2 — в отчётную неделю каждая минута простоя дороже;
• critical-алерты идут в чат смены с максимальным приоритетом, дежурный обязан отреагировать немедленно;
• плановые работы на площадке в эти дни запрещены вовсе.

В остальное время работают обычные пороги. Плюс два правила, заточенных под этого клиента:

• ИБП — переход на батарею всегда critical, заряд ниже 50% и температура — warning; после истории с четырьмя минутами клиент относится к этим сообщениям очень серьёзно;
• утилизация интернет-канала выше 85% дольше 15 минут — warning: банк-клиенты и терминальные сессии первыми чувствуют забитый канал.

Права и прозрачность: что видит клиент

Мониторинг — это ещё и инструмент отношений с клиентом, если правильно раздать доступы.

• Директор получил read-only дашборд со «светофором»: зелёные плитки — всё работает. Панель выведена на телевизор в его кабинете, раз в месяц мы присылаем отчёт о доступности. Директор перестал узнавать о проблемах из криков в коридоре — и это заметно изменило тон наших разговоров.
• Офис-менеджер получил простую страницу «жив ли интернет и принтеры». Эффект неожиданно сильный: половина звонков «у нас всё упало» раньше приходилась на случаи, когда не работал один принтер. Теперь офис-менеджер сам видит, что именно лежит, и звонит уже с конкретикой.
• Главбуху доступ не нужен — и это тоже осознанное решение: лишняя панель лишнему человеку только добавляет тревоги.
• Инженеры ITfresh — полный доступ через VPN; снаружи веб-интерфейс мониторинга не опубликован вообще.

Итоги в цифрах через три месяца

Через три месяца после внедрения сверили метрики с журналом заявок. Вот честная таблица:

Затраты стороны исполнителя: примерно 16 часов инженерного времени на внедрение (та самая неделя, по паре часов в день с двумя выездами) и 2–3 часа в месяц на сопровождение по регламенту — проверки, ревизии правил, обновления. Лицензионных платежей ноль: LibreNMS — открытый софт. Для клиента это вошло в абонентскую плату аутсорсинга без отдельной строки «за мониторинг».

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

Как адаптировать кейс под себя: юрфирма, клиника, склад

Схема внедрения универсальна, меняются акценты:

• Юридическая фирма. Главное — конфиденциальность: жёсткая сегментация, гостевой Wi-Fi полностью изолирован, и обязательное правило-алерт на появление новых устройств в сети — та самая «принесённая из дома точка» здесь не курьёз, а инцидент безопасности.
• Клиника. Приоритет — бесперебойность: медицинское оборудование в мониторинг не трогаем (это отдельная регуляторная территория), но ИБП, сеть регистратуры и сервер МИС — critical с минимальными задержками; расписание «усиленного режима» привязывается к приёмным часам.
• Склад. Центр тяжести — Wi-Fi-покрытие для терминалов сбора данных: мониторим точки доступа, количество клиентов на каждой и аплинки; падение одной точки в дальнем углу склада — это бригада, которая стоит и не сканирует.

Чек-лист самопроверки — десять вопросов, на которые стоит ответить честно:

1. Есть ли у вас актуальный список всех устройств в сети?
2. Узнаёте ли вы о падении сети раньше сотрудников?
3. Знаете ли вы, сколько минут реально продержат ваши ИБП?
4. Видите ли вы загрузку интернет-канала за прошлую неделю?
5. Есть ли доступ ко всем коммутаторам (пароли не утеряны)?
6. Известно ли, кто и когда менял конфигурацию сетевого железа?
7. Есть ли график свободного места на дисках серверов?
8. Заметите ли вы чужое устройство, воткнутое в вашу сеть?
9. Можете ли вы показать директору доступность сервисов за месяц?
10. Если админ уволится завтра — останется ли знание сети в компании?

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