Портал №1 по управлению цифровыми
и информационными технологиями

Сервис мониторинга сервисов

mntrngКэрролл Мун (Carroll Moon, главный архитектор облачных решений Microsoft) недавно подвёл итог своей полуторагодичной деятельности по публикации в блоге компании AXELOS серии заметок, посвящённых сервису мониторинга, выпустив заключительную часть. Почему, даже имея в наличии прекрасно выстроенный мониторинг, можно регулярно получать обращения недовольных пользователей? Почему так происходит? Кэрролл отвечает на эти вопросы и предлагает присоединиться к обсуждению.

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

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

  • Service Desk нуждается в информации, чтобы оперативно донести её до обращающихся пользователей. Бывало ли такое, что вы звоните своему Интернет-провайдеру, а он ничего не знает о проблеме? Определённо, при таком отношении у вас зародятся сомнения в отраслевой компетентности поставщика. Зачастую, отсутствие оповещений о недоступности услуги хуже, чем просто её недоступность. Люди понимают, что вещи ломаются, а услуги не предоставляются по тем или иным причинам. Однако, нас раздражает некомпетентность. Отношение "а мы и не знали" – отдаёт непрофессинализмом. Обнаружить инцидент, но при этом не сообщить о нём – это позор, считает Кэрролл.
  • доводите информацию до руководства, чтобы они не были внезапно удивлены. Пусть ваш босс всегда будет в курсе значимых событий.
  • выстраивайте коммуникации так, чтобы конечные пользователи даже и не обращались бы на Service Desk. Возвращаясь к примеру с Интернет-провайдером – наверняка вы были бы довольны, если бы вас заранее предупредили о недоступности услуги. Конечно, это не значит, что вас нужно разбудить среди ночи и сообщить, что доступ в Интернет отсутствует. Совсем нет. Однако, было бы замечательно, что если проблема на стороне вашего провайдера, уведомление появлялось бы тогда, когда вы не смогли попасть на какой-либо сайт. Например, прямо в вашем браузере. Конечно, возникают технические проблемы: как безопасно интегрироваться с вашим браузером, как оповещать, если канал полностьюю лежит. Но сама идея в том, чтобы реализовать эту возможность. Допустим ваш домашний роутер мог бы распознавать отсутствие Интернета и в онлайн-режиме при попытке открыть сайт показывал бы оповещение от провайдера о недоступности услуги.

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

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

  • мы выявили инцидент при помощи мониторинга и конечный пользователь не обратился к нам с проблемой, им вызванной.
    Именно этот результат нам и нужен. Что при этом произошло: а) мониторинг успешно отработал; б) возможно, что коммуникация с пользователем была успешной; в) звонок на Service Desk от пользователя не поступил.
  • мы выявили инцидент при помощи мониторинга, но пользователь обратился на Service Desk
    И это неудача. Какие возможные причины? Мы почему-то медленно производим оповещения. Мы вовремя оповестили пользователя, но информация не была вопринята и понята должным образом. Мы учли почти всё: вовремя и эффективно прокоммуницировали, но забыли про одного из пользователей. Он и позвонил с проблемой на Service Desk.
  • мы не выявили инцидент.

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

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

Со всей серией заметок Кэрролла по сервису мониторинга можно ознакомиться в блоге AXELOS. Начало здесь.

Комментариев: 1


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM