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

Время чтения: 7 мин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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