Молдавская компания с собственным сервером или несколькими критичными приложениями в облаке обычно узнаёт о проблеме одним из двух способов: либо сотрудник звонит и говорит, что не может работать, либо никто ничего не замечает до тех пор, пока не приходит крупный счёт за ремонт или не теряется целый рабочий день. Разница между этими двумя сценариями называется проактивным ИТ-мониторингом — системами, которые постоянно проверяют состояние серверов, сети и приложений и сигнализируют о проблеме до того, как она становится авральной ситуацией. В этом гиде разбираем, что на деле должен делать серьёзный мониторинг, чем он отличается от обычной техподдержки по подписке, и что спросить у поставщика до подписания договора.
Реактивный мониторинг против проактивного
Классическая техподдержка реактивна: сотрудник замечает проблему, открывает заявку, поставщик реагирует. Это работает для точечных вопросов ("как установить программу X"), но по определению слишком поздно для проблем, которые накапливаются постепенно — диск, который медленно заполняется, задание резервного копирования, которое молча проваливается три ночи подряд, сертификат, срок действия которого известен заранее.
Проактивный мониторинг меняет порядок действий: автоматическая система проверяет критичные параметры с коротким интервалом (как правило, раз в несколько минут) и отправляет оповещение сразу, как только значение превышает установленный порог — независимо от того, заметил ли уже что-то сотрудник. Практическая разница не в технологии, а в моменте: с реактивным подходом о проблеме узнаёшь, когда она уже мешает работе; с проактивным — заранее, пока её можно устранить спокойно, не в критичный момент.
Что на самом деле проверяет система мониторинга
"ИТ-мониторинг" иногда используется как расплывчатая метка для любой услуги обслуживания. Конкретно, полезный мониторинг непрерывно следит за:
- Ресурсами сервера — свободное место на диске, загрузка процессора и память, чтобы заметить аномальный рост заранее, до того как он заблокирует приложение.
- Состоянием сети и интернет-соединения — потери связи, необычная задержка, VPN, который перестал отвечать для удалённой команды.
- Результатом заданий резервного копирования — не просто то, что backup "выполнился", а что он завершился успешно и в обычный промежуток времени; резкое отклонение обычно первый признак неполадки.
- Сроком действия SSL-сертификатов и доменов — сайт, который внезапно становится небезопасным или недоступным для клиентов, обычно полностью предотвратимо заранее отправленным оповещением.
- Нетипичными попытками входа — повторные неудачные попытки авторизации, доступ из мест или в часы, не соответствующие обычной активности компании.
- Доступностью критичных приложений — сайт компании, интернет-магазин, учётная или бухгалтерская система, проверяемые снаружи, а не только внутри корпоративной сети.
- Сроком действия лицензий и подписок — программа, которая внезапно блокируется, потому что годовую лицензию не продлили вовремя.
Небольшой компании с несколькими ноутбуками и одним облачным приложением обычно достаточно первых двух-трёх пунктов. Компании с собственным сервером, интернет-магазином или активно используемой учётной системой нужна полная картина — отсутствие хотя бы одной проверки способно обесценить пользу от остальных.
Как на практике работают оповещения
Хорошее оповещение состоит из трёх частей: чёткого порога (например, свободное место ниже 10%), человека или команды, которая его реально получает, и заранее установленного времени реакции. Без всех трёх мониторинг превращается в шум.
Самая частая техническая ошибка — не отсутствие оповещений, а их избыток: слишком чувствительные пороги генерируют постоянные уведомления о нормальных колебаниях, и команда, которая их получает, естественным образом учится их игнорировать. Когда наконец возникает реальная проблема, она теряется в том же потоке, что и все остальные. Грамотно настроенный мониторинг различает уровни критичности — критическая проблема (сервер не отвечает) немедленно доходит до конкретного человека по каналу, который невозможно пропустить, тогда как незначительное наблюдение (диск медленно заполняется) может подождать до ежедневного отчёта.
Стоит также уточнить, кто реально отвечает за реакцию вне рабочих часов. Одни договоры о мониторинге покрывают только интервал 9-18, другие обещают непрерывное покрытие — эта разница существенна для компании с интернет-магазином или деятельностью, которая не останавливается вечером.
Мониторинг не заменяет резервное копирование, и наоборот
Мониторинг сообщает, что задание backup завершилось с ошибкой вчера ночью. Он не говорит, можно ли реально восстановить файлы из этой копии, и не проверяет, соответствует ли backup базовому правилу отдельной копии, не связанной напрямую с основной сетью. Эти две функции дополняют друг друга, а не заменяют — что на деле означает правильная стратегия резервного копирования, включая тестовое восстановление, разобрано в гиде о резервном копировании данных для компаний. Компания, у которой есть только одна из двух функций, всё равно остаётся уязвимой: мониторинг без протестированного backup означает, что о проблеме узнаёшь быстро, но не можешь её исправить; backup без мониторинга означает, что вовремя не узнаёшь о том, что сам backup перестал работать.
Что должен включать договор о мониторинге
- Время реакции по уровню критичности — сколько минут или часов проходит до первого человеческого ответа на критическую проблему, в отличие от незначительной.
- Чётко прописанное время покрытия — рабочие часы или 24/7, явно указанное, а не подразумеваемое.
- Периодический отчёт — список, как минимум ежемесячный, обнаруженных и устранённых инцидентов, которые не успели повлиять на работу; без такого отчёта у вас нет реального доказательства, что мониторинг что-то делает.
- Процесс эскалации — что происходит, если первый контактный человек не отвечает в обещанный срок.
- Разграничение "оповещаем" и "оповещаем и устраняем" — некоторые договоры только уведомляют, оставляя фактическое устранение отдельной, дополнительно оплачиваемой услугой; это стоит уточнить явно до подписания, а не обнаружить при первом инциденте.
Признаки того, что ваша инфраструктура не мониторится по-настоящему
- О проблеме вы узнаёте от недовольного сотрудника, а не от поставщика услуг.
- Никто не может показать вам реальную историю оповещений или отчёт за прошлые месяцы.
- Сервер работал без свободного места на диске неделями, прежде чем реально упало приложение.
- SSL-сертификат или домен истёк без какого-либо предварительного предупреждения.
- Нет никакой разницы в цене, договоре или отчётности между "поддержкой по запросу" и "проактивным мониторингом" — признак того, что название, вероятно, есть, а реального мониторинга нет.
Как проверить, что поставщик реально мониторит, а не только обещает
- Попросите доступ к живому дашборду, а не только обещание отчёта, присылаемого время от времени по почте.
- Попросите конкретный пример оповещения за последний месяц и того, что было сделано в ответ — у поставщика, который реально мониторит, такой пример всегда есть под рукой.
- Прямо спросите, что происходит вне рабочих часов — кто отвечает, сколько это занимает, что считается критичным инцидентом.
- Уточните, какой процент инфраструктуры реально покрыт — все серверы, но также и ноутбуки команды? И облачные приложения, а не только установленные локально?
- Проверьте, включает ли мониторинг аспект безопасности (несанкционированный доступ, аномальные попытки входа) или ограничивается исключительно доступностью и производительностью.
Частые вопросы
ИТ-мониторинг отличается от обычной техподдержки? Да. Техподдержка реагирует на проблему, уже замеченную сотрудником. Проактивный мониторинг обнаруживает проблему до того, как её кто-либо заметил, постоянно проверяя критичные параметры инфраструктуры.
Нужен ли мониторинг, если все приложения компании в облаке? Да, даже без собственного сервера. Доступность приложений, срок действия доменов и сертификатов, а также нетипичные попытки входа важны в той же мере и в полностью облачной инфраструктуре.
Как быстро должен реагировать поставщик на критическое оповещение? Зависит от установленного SLA, но для проблемы, блокирующей работу компании, разумный стандарт — реакция человека в течение минут, а не часов, явно прописанная в договоре.
Мониторинг устраняет необходимость в backup? Нет. Мониторинг проверяет, завершилось ли задание резервного копирования успешно, но не тестирует, можно ли реально восстановить данные. Эти две функции нужно рассматривать раздельно, включая периодические тестовые восстановления.
Как понять, плачу ли я уже за мониторинг, но фактически его не получаю? Попросите конкретный отчёт с оповещениями за последние месяцы. Если поставщик не может его предоставить, скорее всего, метка "мониторинг" не соответствует реально работающей услуге, а остаётся общим обещанием в договоре.
Проверьте до инцидента, а не после
Разница между компанией, которая предотвращает проблему, и той, что узнаёт о ней от раздражённого клиента или сотрудника, обычно не в размере бюджета, а в том, превращается ли обещанный в договоре мониторинг в реальные оповещения, отчёты и быструю реакцию. Наши услуги по ИТ-администрированию включают проактивный мониторинг серверов, сети и критичных приложений, а для инфраструктуры в облаке покрытие дополняется нашими облачными услугами и инфраструктурой.
Запросите бесплатную оценку вашей текущей инфраструктуры и узнайте, что проактивный мониторинг обнаружил бы за последние месяцы.