Мониторинг. Польза или баловство?
Системы мониторинга – это, безусловно, полезный и важный инструмент. Все осознают их необходимость. Однако, у большинства организаций внедрение таких систем сопряжено с трудностями. Нередко случается так, что инженеры тратят основное время на поддержание работоспособности самой системы мониторинга, вместо того, чтобы она помогала им в решении задач.
Поделюсь личным опытом, который, вероятно, поможет многим лучше осознать проблему, .
Мониторинг «как обычно»
Итак, руководство приходит к выводу о критической важности системы мониторинга и ставит задачу её внедрения. Инженеру, занятому своими непосредственными обязанностями, например, настройкой сетей, поручают «развернуть систему мониторинга». Как это сделать, зачастую никто не знает, поскольку это первый опыт в данной области. Допустим, у компании есть сотня удаленных филиалов, и необходимо контролировать доступность каналов связи с каждым из них. В такой ситуации начинается поиск бесплатных решений, изучение доступных вариантов и выбор одного из них.
Как правило, предпочтение отдается максимально простому решению, основанному на проверке доступности конечных точек с помощью ping. После установки и настройки, затратив значительное время, ожидается немедленный результат. Однако, система начинает выдавать ложные срабатывания. Например, в удаленном филиале есть основной и резервный каналы связи, и система мониторинга отслеживает оба из них. Инженер получает уведомление о проблемах с каналом, проверяет доступность, но обнаруживает, что все работает нормально. Система мониторинга сработала ложно. Несмотря на случаи с реальными проблемами, большинство срабатываний оказываются ложными. В результате, система мониторинга, вместо помощи, лишь рассеивает внимание и приводит к тому, что ей начинают пренебрегать.
Рассмотрим другой сценарий. Помимо удаленных точек и каналов связи, в центральном офисе также имеется важное оборудование, которое необходимо контролировать. Настраивается мониторинг доступности устройств и их параметров. Однако, при возникновении реальной аварии в центральном офисе, особенно если она затрагивает сетевое оборудование, система мониторинга оказывается бесполезной. Как она может передать информацию, если корневое оборудование инфраструктуры вышло из строя? Скорее всего, о проблеме сообщат по телефону или криком: «Все сломалось, беги чинить!». После устранения неисправности система мониторинга включится и завалит почту тысячами сообщений о случившемся. Очень своевременно, не правда ли?
Предположим, компания осознала необходимость более продвинутой системы мониторинга и выбрала решение с поддержкой SNMP. Этот протокол позволяет устройствам отправлять данные о своем состоянии, такие как загрузка процессора, использование памяти, состояние сетевых интерфейсов, в централизованный коллектор. После установки и настройки системы, не являясь специалистом в этой области, выясняется, что каждое устройство в сети постоянно сообщает о каких-либо проблемах. Например, у одного устройства постоянно высокая загрузка процессора, у другого – нехватка памяти. В целом, такое состояние может быть нормальным для конкретного устройства. Однако, система мониторинга постоянно сообщает о проблемах, требуя постоянного внимания и проверки. В результате, возникает то же самое: нежелание реагировать на постоянные ложные сообщения и стремление получать только достоверную информацию о реальных проблемах. В конечном итоге, системе мониторинга уделяется меньше внимания, чем следовало бы.
И последний сценарий. Предположим, настройка системы мониторинга увлекла, и все настроено идеально. Данные отправляются корректно, ложные срабатывания сведены к минимуму. Но авария происходит в нерабочее время. Что делать? Если настроены уведомления на внешние каналы связи, то сообщение об аварии будет получено дома. Но стоит ли ехать на работу среди ночи? Если же уведомления не настроены, то о проблеме станет известно только утром, что может привести к потере времени и несвоевременному реагированию.
Мониторинг. Успешные кейсы.
В качестве конструктивного предложения, поделюсь опытом, полученным от профессионала в области мониторинга. Он рассказал о нескольких успешных кейсах использования системы мониторинга во благо.
Первый кейс – мониторинг маршрутизатора в удаленном офисе, выполняющего роль шлюза для внутренних сетей и имеющего внешние каналы связи. Простое отслеживание внешних интерфейсов не позволяет определить выход из строя всего маршрутизатора. Мониторинг внутренних интерфейсов также не дает полной картины, поскольку их можно случайно или намеренно вывести из строя. Контроль загрузки процессора или памяти может не указывать на аварию, а отражать нормальную работу устройства. Что же делать? Решением является корреляция событий. В каждом офисе есть набор статических инфраструктурных сервисов: принт-сервер, файловый сервер, DNS-сервер, почтовый сервер. Современные системы мониторинга позволяют связывать события, то есть, для определения неисправности маршрутизатора необходимо отслеживать выход из строя всех этих сервисов за короткий промежуток времени, например, за 15 секунд. В совокупности с мониторингом каналов связи, это дает основания для привлечения инженера и подозрения на выход из строя маршрутизатора.
Второй кейс — один из самых показательных примеров, демонстрирующих ценность систем мониторинга даже с точки зрения финансовой выгоды для компании. Мне рассказывал об этом человек, работавший в банковской сфере. Как известно, банки обладают разветвленной сетью офисов обслуживания, банкоматов и прочих удаленных точек, которые подключены к центральному офису через каналы связи.
Эти каналы связи обычно приобретаются у крупного оператора, способного обеспечить покрытие необходимой территории, и закрепляются договором. В договоре прописывается SLA (соглашение об уровне сервиса), гарантирующее бесперебойную работу каналов связи в режиме 24/7. Все стороны согласны, договор подписан, связь обеспечена.
Однако, учитывая масштаб сети, у оператора связи периодически возникают проблемы, приводящие к сбоям и отключениям каналов. Здесь и проявляется эффективность системы мониторинга. В первую очередь, система в автоматическом режиме формировала заявку оператору при обнаружении обрыва связи. Эта заявка, содержащая номер договора, информацию о точке сбоя, времени и другие параметры, отправлялась дежурному инженеру, которому оставалось лишь подтвердить и отправить ее по электронной почте на адрес технической поддержки оператора связи..
Во-вторых, система мониторинга вела статистику по всем заявкам и формировала ежемесячный отчет, отражающий общее время простоя каналов связи и детали по каждому инциденту. Это позволяло компании существенно экономить средства за счет штрафов за несоблюдение SLA. Таким образом, создавалась взаимовыгодная ситуация: при отсутствии сбоев оператор связи добросовестно выполнял свои обязательства, а в противном случае банк получал компенсацию за нарушение условий договора.
Послесловие
Внедрение системы мониторинга – задача комплексная и ответственная, требующая не только специализированных знаний, но и понимания бизнес-процессов компании. Поэтому нецелесообразно поручать ее настройку инженерам, занятым другими задачами.
Для эффективной работы системы необходим выделенный специалист, занимающийся ее настройкой, оптимизацией и мониторингом. Кроме того, требуются сотрудники, оперативно реагирующие на возникающие инциденты – дежурная смена или специально обученные специалисты. При комплексном подходе система мониторинга станет незаменимым инструментом для компании, значительно упростив работу инженеров и повысив эффективность бизнеса.