Команды сетевого мониторинга теперь могут подключаться к Интернету вещей, программной сети и облачным сервисам, чтобы обеспечить максимальное время безотказной работы и оптимальную производительность сети. Однако адаптация к этим технологиям будет означать определение новых методов интеграции унаследованной архитектуры, реинжиниринг рабочего процесса мониторинга и оценку инструментария для улучшения комплексного и многоуровневого управления сетью. Это руководство было разработано, чтобы помочь группам мониторинга сети пересмотреть свои методы работы, чтобы иметь более эффективную, основанную на данных, действенную и гибкую практику NMS.

Сетевой мониторинг: передовой опыт

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

Следовательно, по мере того, как сети становятся более плотными и сложными, потребность в адаптивном и основанном на эвристике подходе к их мониторингу становится все более острой. Вот как вы можете перенастроить свои методы NMS для лучшего понимания сети и, в конечном итоге, более эффективного управления сетью:

1. Определение проблемы: определение средней производительности сети.

Первым шагом к пониманию того, работает ли сеть на заданном уровне, является количественный тест для сравнения производительности существующей сети с идеальной производительностью сети. Задача состоит в том, чтобы определить - какой должна быть идеальная производительность сети?

Сетевые администраторы могут наблюдать за производительностью сети от нескольких недель до нескольких месяцев на разных уровнях деловой активности. По окончании периода наблюдения администратор сети получит средний тест производительности сети. Это можно использовать для установления порога производительности в сети.

Установка порога - только часть решения. Другая часть направлена ​​на получение предупреждений, как только порог был превышен.

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

2. Определение права собственности на проблему для ускорения решения.

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

Это важный шаг в управлении средним временем восстановления работоспособности. Часто предприятия с большими ИТ-командами в конечном итоге получают предупреждения в нужное время, но решение не отправляется в течение длительного времени. Это может быть вызвано несколькими причинами - ошибочными приоритетами, неуместным распределением технических специалистов и т. Д. Многие из этих проблем можно решить еще до того, как они возникнут, просто путем создания иерархии владения в сети. Эта иерархия решает, кто будет получать уведомления, когда на основе входящего предупреждения, указывающего на нарушение порога.

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

3. Генерация отчетов с учетом уровней.

Коммуникация в сложной сети часто определяется моделью взаимодействия открытых систем. Это позволяет командам сосредоточиться на функциональной совместимости системы, а не на базовой технологии. Такая же приоритезация должна произойти с точки зрения создания отчетов.

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

Следовательно, система сетевого мониторинга, которая понимает разнообразную природу узлов и элементов в сети и маркирует каждое предупреждение с правильным источником, может помочь группе NSM эффективно запускать протоколы устранения неполадок. Проблемы, которые находятся на грани обнаружения как проблемы, могут быть обнаружены на ранней стадии процесса.

4. Решение проблемы зависимости доступности данных NMS от времени работы сети.

Как правило, группы сетевого мониторинга предпочитают иметь НМС внутри сети для эффективного сбора данных и более быстрой отчетности. Однако это создает нездоровую зависимость между NMS и сетью. Если сеть столкнется с ошибкой и отключится, у группы не будет доступа к данным, встроенным в NMS, какой бы сложной она ни была. Высокая доступность (HA) может решить эту проблему, гарантируя, что NMS будет работать, даже если сеть по какой-либо причине выйдет из строя. Хотя высокая доступность может показаться второстепенной мерой, она может избавить вас от круговой проблемы простоя сети.

5. Доступность данных на временной шкале.

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

6. Иметь единое представление.

По мере роста компаний их методы сетевого мониторинга должны масштабироваться вместе с ними. Малый бизнес с выделенной сетью и командой на месте не столкнется с кризисом, поскольку базовый инструмент может создавать отчеты по всей сети. По мере роста бизнеса они добавляют новые узлы в сеть в виде новых офисов в различных местах и ​​облачной инфраструктуры. Ваша система мониторинга сети должна быть спроектирована таким образом, чтобы вы могли иметь централизованное представление всей сети, доступное в доступной форме на одной платформе. Это даст вам четкое представление о крупномасштабных сетевых тенденциях, а также о том, как каждый узел в сети взаимодействует с другими узлами в сети.

В заключение

Некоторым группам мониторинга сети может казаться, что, хотя эти передовые методы разработаны для повышения эффективности мониторинга сети, они могут быть «слишком большими, чтобы требовать» с точки зрения ресурсов, выделяемых NMS. Эту проблему легко решить с помощью инструмента, который был разработан на основе этих передовых методов.

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