Джин Ким - Руководство по DevOps

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

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

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

Эд Бланкеншип, старший менеджер по продукции Microsoft Visual Studio Team Services, пишет: «Часто команды по разработке элемента функциональности определяют свои цели с помощью воронки приобретения клиентов. Их цель — сделать так, чтобы клиенты пользовались их функциональностью каждый день. Разные группы пользователей иногда неформально называют “зеваками”, “активными пользователями”, “вовлеченными пользователями” и “глубоко вовлеченными пользователями”. Для каждой такой стадии есть своя телеметрия».

Наша цель — сделать каждый бизнес-показатель действенным. Эти важнейшие индикаторы должны сообщать нам, как изменить продукт, и быть гибкими для экспериментирования и A/B-тестирования. Когда метрика не ведет к непосредственным действиям, скорее всего, это просто пустые индикаторы, предоставляющие мало полезной информации. Такие данные стоит хранить, но вот выставлять на обозрение не нужно и уж тем более не стоит бить из-за них тревогу.

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

Рис. 28. Активность пользователей в связи с новой функциональностью после развертываний, измеренная в количестве форумных сообщений (источник: Майк Бриттен, “Tracking Every Release”, взято с сайта CodeasCraft.com, 8 декабря 2010 г., https://codeascraft.com/2010/12/08/track-every-release/)

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

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

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