Мы собираем метаданные (cookie, данные об IP-адресе и местоположении) для функционирования сайта, если вы не согласны, чтобы эти данные обрабатывались, то должны покинуть сайт.
#DevOps_ITSM4U

Телеметрия: события, категории, уровни факторов

Время чтения: 7 мин.
Использование телеметрии (то есть снятия статистик с элементов архитектуры предприятия) с моей точки зрения одна из ключевых задач для обеспечения функционирования компании, которая стремится к успеху. Под функционированием я понимаю весь спектр показателей здоровья компании - ее прибыль, непрерывность, доступность, безопасность, качество и другие.

Но сейчас речь не об этом. Перечитывая книгу "Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях" обратила внимание на ряд тезисов, которыми хочу поделиться.

Первый говорил о том, что в одном из докладов 2015 State of DevOps Report было открытие, показывающее что успешные организации решали проблемы в создании программного решения в 168 раз быстрее, чем в других фирмах, а медианное значение измерялось в минутах (MTTR), при этом медиана неуспешных компаний измерялась днями.

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

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

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

  • решения о подтверждении прав доступа / авторизации (и отключения)
  • сам доступ в систему / модуль / к данным
  • изменения систем и приложений
  • изменения данных (удаление, добавление, правка)
  • некорректный ввод (возможно вредоносный, угрозы)
  • ресурсы (ram, диск, проц, пропускная способность и др)
  • работоспособность и доступность
  • загрузка и завершение работ
  • сбои и ошибки
  • задержки
  • успешные и неудачные резервные копирования

Так же автор рекомендует для упрощения интерпретации использовать нефункциональные характеристики событиям, такие как качество работы, безопасность и функциональные (такие как поиск, ранжирование).

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

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

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

Так вот, факторы могут быть следующих уровней:

  • бизнес. Здесь мы измеряем бизнес показатели - кол-во поставок, количество сделок, количество счетов, количество регистраций, % оттока, удовлетворенность клиентов, длительность процесса (к примеру, срок с момента обращения клиента до выдачи ему кредита).
  • уровень приложений - на данном уровне мы измеряем параметры работы приложений, время транзакции, доступность и непрерывность систем.
  • уровень инфраструктуры - здесь мы меряем показатели работы баз данных, ОС, сети, серверов, смотрим загрузку ЦПУ, объем свободного пространства, трафик сервера.
  • уровень клиентского ПО (здесь мы смотрим на работу клиентских приложений, время выполнения операций, наличие ошибок, простои сервисов)
  • уровень развертывания (здесь показатели показывающие работу процесса развертывания, такие как время развертывания, частота, статус сборки)
Я бы дополнила данный перечень между уровнем бизнес и приложений - уровень сервисов. О чем мы говорим - а о том, что на языке бизнеса не интересно как работают приложения, бизнесу важно как работает процесс в целом. Соответственно возникает еще уровень метрик, на котором мы измеряем работоспособность сервисов обеспечивающих процесс, его доступность, непрерывность, мощность, скорость выполнения этапов и прочие метрики.

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

Еще дополню своим взглядом на категории факторов (показателей):

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

    Этими показателями характеризуют успешность и эффективность процесса.

    Если процесс связан с получением денег, то однозначно одним из целевых показателей будет доход или степень доходности. Для производств – объем производства, для услуг – объем оказанных услуг. Целевым показателем маркетинга может быть количество новых целевых клиентов, обратившихся за услугой или товаром, ROMI – коэффициент возврата инвестиций в маркетинговые проекты. Для управления персоналом может быть ключевым показатель – текучести персонала.
    1
  • Временные
    Показатели времени. Ими может быть длительность выполнения этапа или процесса (от входа процесса до выхода процесса).

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

    Один из известных показателей – эффективность производственного цикла, MCE (manufacturing cycle effectiveness) рассчитываемый как отношение времени производства к времени всего цикла производства (время производства+ время перемещения плюс время хранения + время проверки).
    2
  • Качества
    Показатели качества специфичны и индивидуальны для каждого процесса. Это может быть % брака, % ошибок, CSAT, NPS удовлетворенность клиентов, удовлетворенность пользователей, отток клиентов, % повторных клиентов.
    3
  • Финансовые
    Показатели, связанные с деньгами. С помощью них можно оценивать стоимость процессов, издержки, поступления.

    Такими показателями могут быть:
    • Себестоимость процесса
    • Потери от простоев процесса
    • Прибыль процесса
    • ЧОД по процессу
    4
  • Технологические
    Данные показатели актуальны для ИТ-сервисов и технических сервисов.

    • Доступность процесса
    • Скорость выполнения операций (с момента нажатия кнопки до момента отображения реакции системы)
    • Мощность процесса (объем транзакций, который может быть обработан)
    • Своевременность завершения процедуры/операции
    • Время выполнения обращений службой поддержки
    • Time To Market – длительность с момента подачи запроса на изменение до реализации задачи
    • % изменений, вызывавших сбои процесса от общего количества изменений
    5
  • Фрагментарные
    Еще один показатель – фрагментация процесса. Он показывает сложность и многоступенчатость процесса, определяется количеством участников, действий.

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

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

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

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

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

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

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

Здесь на помощь приходит статистический анализ. Расчет среднего и стандартных отклонений. И система оповещений настраивается на условие, что значение показателя отличается от среднего значения отклонения. Но такой способ работает только для нормального распределения. Как быть если у данных негауссово распределение? Существуют методики выявления аномалий, еще их называют как «поиск явлений и событий не подчищающихся ожидаемым правилам и моделям». Но сейчас мы не будем углубляться в эту тему.


Читайте так же в моем блоге:


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

Практические рекомендации с примерами как отвечать на негативный отзыв клиента.

Практические рекомендации с примерами: как ответить на положительный отзыв клиента.

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

Два простых инструмента для выбора интересных тем и отслеживания трендов для блога.

Подход к управлению ИТ услугами ITSM vs. ITIL, после прочтения вы раз и навсегда поймете в чем разница подхода к управлению ITSM и библиотеки ITIL.

Как применять индекс NPS для управления лояльностью клиентов