SLA и мониторинг каналов связи: как связать метрики, пороги и отчетность

Мы в Telegram

Подпишитесь на Telegram-канал wiSLA и оставайтесь в курсе последних новостей!

Подписаться

Список основных метрик:

• Доступность;

• Задержка;

• Потери пакетов;

• Джиттер; 

• Загрузка канала.

Доступность по SLA — это доля времени без отказов в согласованные часы обслуживания. Плановые работы, согласованные исключения и периоды снижения качества (без полного отказа) не уменьшают процент доступности — они отражаются отдельно, чтобы отчёт был честным и понятным обеим сторонам.

SLA считается выполненным, когда доступность не ниже порога из контракта — например, 99.9%. Отчеты формируются автоматически за нужный период и могут служить основой для расчета компенсаций при нарушениях.

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

Пример матрицы порогов

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

Как построить отчетность

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

Прежде всего, отчет должен отвечать на вопрос: какое качество получил заказчик? В данном случае подойдет информация, на сколько процентов была оказана услуга, а также, сколько времени был доступен арендованный канал связи.

Оперативный дашборд

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

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

На дашборде удобно отображать:

• текущее состояние каналов;

• доступность и деградацию;

• потери, задержку и джиттер;

• загрузку по направлениям;

• состояние основного и резервного маршрутов;

• активные инциденты;

• зависимые бизнес-сервисы.

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

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

Отчет для ИТ-руководителя

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

В первую очередь в отчет следует включать список каналов, которые не соответствуют требованиям SLA. Для каждого такого канала важно указать, какой показатель был нарушен, насколько продолжалось отклонение, в какой период оно произошло и затронуло ли оно пользователей или бизнес-сервисы. Это позволяет руководителю быстро оценить, какие направления требуют внимания и насколько ситуация влияет на выполнение обязательств перед заказчиками.

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

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

Отчет для провайдера

Для эффективной работы с оператором связи важно опираться не на субъективные оценки пользователей или единичные сообщения о проблемах, а на проверяемые и документально подтвержденные факты. Чем точнее зафиксированы параметры события, тем проще определить зону ответственности, подтвердить нарушение условий SLA и добиться содержательного ответа от провайдера.

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

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

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

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

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

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

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

Визуализация географии и топологии

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

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

Заключение

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

Практическая модель включает пять уровней:

• паспорт услуги;

• измеряемые метрики;

• предупредительные и критические пороги;

• автоматизированное реагирование;

• отчетность для эксплуатации, руководителей и провайдера.

wiSLA поддерживает такую модель за счет мониторинга основных и резервных каналов, измерения сетевых KPI/KQI, контроля вышележащих сервисов, анализа пользовательского трафика, формирования протоколов и интеграции с корпоративными системами.

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