Повышение скорости разрешения проблем с облачными приложениями при помощи метрик производительности сети

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

ИТ-департаменты используют Office 365, G Suite, Salesforce и многие другие Saas-платформы вместо серверных приложений. Такие платформы легко использовать, они широкодоступны, но при этом они также подвержены отказам и снижению производительности. Такая ситуация может поставить в тупик ИТ-департаменты, которые, с одной стороны, отвечают за работоспособность приложений, с другой стороны – не имеют полной картины происходящего и возможности контролировать облачные приложения. Как сохранить контроль и быть уверенным, что SaaS-приложения работают должным образом? Здесь могут помочь метрики производительности сети.

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

• Проблема связана с сетью?
• Наблюдается ли снижение производительности на стороне приложения?
• Существует ли проблема с моим Интернет-подключением?

Для ответа на эти вопросы нам нужно уйти от инструментов мониторинга инфраструктуры и использовать инструменты мониторинга производительности сети или взаимодействия пользователя с приложением. Первым шагом должно стать измерение метрик производительности сети, таких как время прохождения сегмента (задержка на стороне сети), время отклика сервера (задержка на стороне приложения) и повторные передачи (ухудшение работы сети). Метрики NPM (метрики производительности сети) – ключевая информация, которую рассматривают при жалобах пользователей на ухудшение работы сети. Вторым шагом должно стать поиск конкретного трафика, связанного с проблемным SaaS-приложением. Учитывая, что весь трафик идет в зашифрованном виде, это, возможно, покажется чем-то из области фантастики, но благодаря возможности анализа зашифрованного трафика (Encrypted Traffic Analysis) и метаданным, извлеченным из самого сетевого трафика, легко можно идентифицировать отдельные приложения и отобразить соответствующие метрики производительности на панели приложений.

 

 

Панель мониторинга Office 365 показывает метрики использования и производительности отдельных приложений, а также отдельных клиентов в корпоративной сети

После того, как мы обеспечим мониторинг, нам нужно будет добавить возможность создания отчетности и предупреждений о снижении производительности. Для отдельных метрик можно установить абсолютные пороговые значения (среднее или максимальное значение), а также относительные пороговые значения на основе базовых параметров NPM, которые непрерывно обновляются в зависимости от реального сетевого трафика. Например, при использовании Office 365 сложность вызывает разграничение между сетевой задержкой и задержкой приложения, а также распознавание повторных передач. Далее на панели отображаются статусы отдельных предупреждений, при этом сообщения могут касаться электронной почты, Syslog или SNMP trap в зависимости от предпочтений пользователя.

 

Виджет, представляющий статус предупреждений отдельных метрик производительности сети при использовании Office 365. RTT - задержка сети,  SRT – задержка приложения, RTR (повторные передачи) – ухудшение Интернет-подключения

Давайте рассмотрим один пример – время отклика сервера. Эта метрика определяет одну причину задержки, которую наблюдает клиент, и связана она с самим приложением. Для предупреждения о снижении производительности используется среднее значение за один час, при этом порог установлен как 100% увеличение текущего значения по сравнению с прогнозом (базовым значением).  Подобный подход можно использовать и для других метрик.

Подробности SRT- предупреждения в приложении Office365, показывающее условие срабатывания, базовые и текущие значения производительности приложения

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

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

Источник ►