Короткий ответ: в инфраструктуре компании нужно мониторить доступность критичных сервисов, состояние серверов, дисков, сети, VPN, backup, сертификатов, журналов ошибок и пользовательских сценариев. Уведомление полезно только тогда, когда понятно, кто реагирует и какое действие ожидается.
Базовая карта мониторинга
| Зона | Что контролировать | Зачем бизнесу |
|---|---|---|
| Критичные сервисы | 1C, файлы, AD, DNS, почта, VPN, сайт, телефония | Понять простой до массовых обращений пользователей |
| Серверы | CPU, память, диски, службы, перезагрузка, ошибки | Заметить деградацию до аварии |
| Хранилища | Свободное место, рост данных, состояние массивов | Не остановить сервис из-за заполненного диска |
| Сеть | Доступность шлюзов, провайдеров, VPN, филиалов, Wi-Fi-контроллеров | Быстро отделить проблему сети от проблемы сервера |
| Backup | Успешность заданий, давность копии, ошибки, место хранения | Не узнать о неработающем backup во время восстановления |
| Сертификаты и домены | Сроки действия и ответственные за продление | Избежать внезапного отказа доступа к сервису |
| Пользовательский сценарий | Можно ли войти, открыть базу, подключиться к VPN, получить файл | Проверять не только железо, но и реальную работу |
1. Начните с критичных бизнес-сервисов
Мониторинг должен идти от бизнес-процессов, а не от списка устройств. Сначала определите, без чего компания быстро остановится: 1C, файловые ресурсы, домен, интернет, VPN, телефония, складская система, сайт, почта или сервис заявок.
Для каждого сервиса полезно знать владельца, допустимое время простоя, зависимые серверы и простой способ проверки. Иначе мониторинг покажет, что сервер включен, но не ответит, работает ли процесс.
2. Контролируйте ресурсы с порогами и трендами
Порог по диску или памяти полезен, но тренд полезнее. Если диск растет на десятки гигабайт в день, предупреждение за два процента до конца уже позднее. Для серверов смотрят не только текущую нагрузку, но и устойчивое изменение: рост очередей, постоянную нехватку памяти, частые пики CPU, увеличение времени ответа.
3. Отдельно мониторьте backup
Backup нельзя прятать в общий статус сервера. Нужны сигналы по последней успешной копии, ошибкам, длительности задания, месту на хранилище и возрасту копии. Если копия не создавалась несколько дней, это отдельный риск, даже если сервер работает нормально.
Периодический тест восстановления не заменяется мониторингом, но мониторинг помогает не пропустить ежедневные сбои.
4. Проверяйте сеть как путь до сервиса
Для пользователей проблема выглядит одинаково: не открывается база, не работает файл, нет доступа к системе. Причина может быть в сервере, DNS, маршрутизации, провайдере, VPN или Wi-Fi. Поэтому мониторинг сети должен показывать не только доступность маршрутизатора, но и состояние каналов, туннелей, филиалов и ключевых сетевых узлов.
5. Настройте уведомления так, чтобы их читали
Если уведомлений слишком много, их перестают замечать. Хорошая настройка разделяет аварии, предупреждения и информационные события. Авария требует действия сейчас. Предупреждение требует плановой задачи. Информационное событие остается в истории и не будит команду без причины.
Для каждого важного уведомления должен быть владелец реакции: кто смотрит, когда эскалирует, где фиксирует результат.
6. Свяжите мониторинг с SLA
Мониторинг без процесса превращается в табло. SLA без мониторинга опирается на жалобы пользователей. Их нужно связать: критичный сигнал создает инцидент, получает приоритет, ответственного, срок реакции и понятную коммуникацию.
В ежемесячном отчете полезны не все графики подряд, а выводы: какие аварии были, что повторяется, где нужен плановый ремонт, какие риски закрыты и какие остаются.
Минимальный набор для малого бизнеса
- доступность интернета и резервного канала, если он есть;
- доступность AD, DNS, файлового сервера и 1C;
- свободное место на критичных дисках;
- ошибки backup и возраст последней копии;
- состояние VPN для удаленных сотрудников или филиалов;
- сроки действия сертификатов для внешних сервисов;
- критичные службы и перезагрузки серверов;
- короткая проверка пользовательского сценария.
Типовые ошибки
- Мониторить железо вместо сервиса. Устройство доступно, но пользовательский сценарий не работает.
- Ставить слишком много уведомлений. Шум маскирует реальные аварии.
- Не назначить владельца реакции. Сигнал есть, но никто не обязан его обработать.
- Не мониторить backup. Ошибка копирования всплывает только при аварии.
- Не пересматривать пороги. Инфраструктура меняется, старые лимиты становятся бесполезными.
Итог: полезный мониторинг показывает не все, что можно измерить, а то, что помогает быстрее восстановить работу компании и планово снижать повторяющиеся риски.