Мониторинг и доступность
Мониторинг и доступность систем и сервисов
Доступность IT-сервисов и мониторинг производительности, как правило, направлен на анализ числа запросов в Service Desk. Второй способ - проведение анкетирования: дайте оценку качеству сервиса, какие проблемы с ним возникли и так далее. На практике это малоэффективные методы управления качеством сервисов.
Хоть в теории инцидентом признается любое уменьшение качества сервиса, на практике пользователь реагирует далеко не на все проблемы, а лишь на те, которые воспринимаются им как недопустимые для завершения бизнес процессов. Прежде чем пользователь обращается в техническую поддержку, он, как правило, пытается обойти инцидент своими силами. Если это удается, то о проблеме и ее причинах опять-таки ничего не известно.
Включают в себя:
- RUM- RealUserMonitoring;
- слежение за IT-инфраструктурой;
- реакция бизнес-приложений (контроль времени, как правило, GUI-роботами).
Основа мониторинга IT-инфраструктуры базируется на утверждении, что ее работоспособность связана с доступностью сервисов. На деле это так, но для полномерной работы понадобится грамотная корректировка пороговых значений в системе мониторинга. Эта задача представляется наиболее сложной в применении системы мониторинга. В случае, когда настройки не производились, можно отследить доступность к элементам IT-инфраструктуры исключительно по ping – это, безусловно, не является равенством при использовании сервиса. К примеру, элементы ip-телефонии «прослушиваются» по ping, а использовать связь не представляется возможным – звуки прерывисты, изображение тормозит.
Сегодня для мониторинга, как правило, применяются GUI-роботы. Они создают имитацию поведения пользователя в рабочем интерфейсе. Инструмент можно считать эффективным, но имеются некоторые противопоказания:
- GUI-роботы – тяжело масштабируемые решения;
- GUI-роботы глобально примитизируют поведение пользователя.
К примеру, имитировать сложную операцию GUI-робот, как правило, не способен.
Этого недостатка нет у RUM – пассивный мониторинг операций пользователей. Зачастую для этих действий применяется анализатор сетевого трафика. Дорогостоящий, но, пожалуй, самый эффективный метод.
Приём и обработка обращений возложены на техподдержку, а проактивный мониторинг ведут системные администраторы. Сисадмин предупреждает неполадки, техподдержка обрабатывает случившиеся инциденты. Ее действия направлены на скорейшее восстановление снизившегося качества сервиса.
Во время работы системный администратор может использовать или не использовать мониторинг. С помощью системы допустимо следить как за здоровьем ИТ-инфраструктуры, так и за производительностью бизнес-приложений. Кроме этого, отслеживаются и другие показатели при добавлении соответствующих модулей.
Контроль пожеланий пользователя
Пользователь описывает в Service Desk только те проблемы, которые в значительной степени ухудшают его функционал и являются неразрешимыми. Перенаправлять жалобы на службу поддержки не представляется возможным – их будет огромное количество, следовательно, инциденты должна воспринимать система мониторинга.
Ее работа будет заключаться в следующем:
- отслеживание жалоб, как очередной метрики;
- оценка новой метрики по N-балльной шкале;
- во время превышения допустимых чисел перенаправлять их техподдержке, создав запись в ServiceDesk.
Исследуя систему отчетов возможно создание ретроспективного анализа, на предмет выявления сервисов, которые вызывают наибольшие недовольства.
Пересылка жалоб
Как правило, пользователи не готовы постоянно связываться с техподдержкой. Для этого минимизируются графики пересылки жалоб. Они отправляются нажатием одной кнопки или нажатием их комбинаций.
Красной кнопкой выступает программный агент EPM-Аgent Plus. Ее устанавливают на ПК пользователя или на терминальный сервер. ЕPM-Agent Plus обладает следующими функциями:
- при нажатии определяется бизнес-приложение;
- создается скриншот экрана;
- прикрепляется значение переменных среды.
Все данные направляются в агрегатор информации.
EMPработает в двух направлениях - перенаправляет жалобы и регистрирует неполадки. Доступно два смежных режима. Первый, для открытия диалогового окна, в котором происходит регистрация проблемы. Практически все действия происходят автоматически, но вид проблемы необходимо указывать в диалоговом окне. Второй режим диалоговое окно не открывает, именно он и отправляет жалобы.
Сбор жалоб
Сообщение «помоги мне» – это SOAР-пакет. Все сообщения такого рода переходят в Агрегатор информации, который представляет собой систему мониторинга ProLАN SLA-ON. Кроме своей системы мониторинга, в Агрегаторе имеется:
- экспертная система;
- консолидированная БД;
- средство распределения отчетов.
Приняв жалобу, агрегатор прописывает её в консолидированную БД. Кроме полнофункционального ProLАN SLA-ON можно применять QuTestеr Plus. QuTestеr Plus – это пакет, который оснащен системой мониторинга и «тревожной» кнопкой. Так как пакет бесплатный, функционал - ограниченный.
Черновая информация и экспертные значения контролируются в режиме online. Экспертные оценки отображаются на моделируемой карте или на схеме бизнес-процессов. Основываясь на черновых данных, формируются тактические и оперативные отчеты. Отчеты, имеющие статус оперативных, позволяют распознать, насколько удовлетворен пользователь качеством IT-сервиса в разных аналитиках, к примеру, по офисам продаж. Отчеты со статусом «тактические» помогают распознавать изменения удовлетворённости пользователей в длительные интервалы времени.
Совокупность снимков инцидентов
Мало одной оценки количества жалоб, которые будут поступать на какой-либо сервис от того или иного пользователя. Недостаточно того, чтобы сотрудник, занимающийся поддержанием качества IT-сервиса, мог оперативно получить информацию об уменьшении качества и откорректировать процесс. Необходимо, чтобы оценка метрики, падающая до пункта «требует внимания», автоматически формировалась в агрегированный снимок и регистрировалась в Service Desk. К снимку будут приложены все жалобы, которые относятся к нему. Служба поддержки, получив снимок, будет прорабатывать его как инцидент.
Мониторинг качества IT-сервиса и мониторинг здоровья IT-инфраструктуры, в совокупности с производительностью бизнес-приложений, заметно упрощает решение задач по диагностированию причин снижения качества.
Допускается регистрация проблем в техподдержке не от персонала, а от автоматизированной системы управления действиями. Подразумевается, что система мониторинга, производя отслеживание здоровья IT-инфраструктуры, во время обнаружения ошибки подготавливает и отправляет запрос в техподдержку.
Область применения
Нельзя надеяться на то, что пользователь будет регулярно посылать жалобы. Требование к пользователю присылать уведомления о проблемах должно быть обосновано и иметь ограниченный срок действия, оптимально один – три месяца. Допустимо прибегать к этому методу в следующих ситуациях:
- проводится аудит качества IT-сервисов – запланированное техническое обслуживание.
- окончание интеграций новых сервисов, при этом систематизация запросов даст возможность локализации недоработок в бизнес-приложениях и устранит пробелы в IT-Инфраструктуре.
- во время кадровых перестановок CIO или ИТ–департаменте.
Первоочередные цели:
- локализовать проблемы, что позволит максимально эффективно применять наиболее точные инструменты диагностики, к примеру, анализаторы сетевых протоколов.
- диагностировать «узкие места» и скрытые неполадки;
- определить пороговые значения тех метрик, которые будут соответствовать продуктивной работе сотрудников. Измерение значений приведет к контролю производительности и доступности IT-сервисов с применением системы мониторинга IT-Инфраструктур. При этом сам пользователь в процедуре задействован не будет.
Поддерживаемые платфомы