Метрики и зачем они нам

Сейчас метриками никого не удивишь. Метрики повсюду, в логах приложений, в управлении проектами, в управлении продуктами, в управлении людьми, в управлении чем угодно. Можно сказать, что мы даже понимаем зачем они нужны. Но к сожалению, не все и не всегда.

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

1. Сложная система — это система, поведение которой невозможно предугадать

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

Ради развлечения и пущей прозрачности введем понятие простой системы.

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

Сложная система – это система, которая состоит из множества компонентов. Для такой системы сложно описать поведение и предугадать результат, так как он может зависеть от множества факторов.

2. Современные компьютерные программы в большинство своем сложные системы

Всем, кто работает в ИТ, повезло! Мы работаем с программами и кодом и строим свои системы сами. За время существования компьютерных наук человечество придумало огромное количество разных штук, которые упрощают компьютерную систему. Я имею ввиду стандартные протоколы, высокоуровневые языки программирования, сборщики мусора, планировщики, типовые архитектуры, парадигмы программирования и много другое. Все то, что скрывает сложность отдельного элемента от нас. Это то что в ООП называется «инкапсуляция». 

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

К этому стоит добавить влияние всех остальных факторов на работу ПО, таких как железные сервера, системы виртуализации\контейнеризации, сеть, базы данных, прокси, DNS, клиентские конечные устройства и весь остальной реальный мир. Прошу заметить, что каждый из этих компонентов также является сложной системой и даже, если ваше ПО делает лишь одну операцию, возвращая ответ математического выражения 2*2 по сети, то ваше приложение, развернутое в кластер сложно и предугадать его поведение практически невозможно. Если не понимаете, о чем я, то вот вам несколько вариантов, когда пользователь, придя к вам и спросив, чему равно 2*2, получит не 4, а нечто другое:

1. Сервер упал, пользователь получил ошибку таймаута

2. У пользователя проблемы с сетью

3. Пользователь ввел запрос не в том формате, который вы ожидаете

4. Пользователь использует неподдерживаемую вами версию браузера и получит 500 ошибку

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

6. …

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

1. Мы можем предугадать вывод системы

2. Нам не нужно раскрывать всю сложность внутреннего устройства черного ящика

3. С нашей точки зрения черный ящик можно считать простой системой, хотя, на самом деле, это может быть не так

Если вы сейчас подумали о микросервисах и инкапсуляции в ООП, то, я думаю, вы уже поняли, к чему я веду.

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

Кроме того, дальнейшие рассуждения применимы не только к компьютерным программа, но и к любым другим сложным системам.

3. В основе управления сложных систем лежит цикл P-D-C-A

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

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

Что такое управление с точки зрения отцов-основателей теории менеджмента?

До прихода вышеупомянутых личностей управление системами строилось на их поддержании, стабильности и управлении сверху вниз. Отличным примером тут может служить конвейер Генри Форда. Мы строим процесс так, чтобы он был максимально стабилен, даже при участии в нем неквалифицированной рабочей силы. Рабочая сила лишь инструмент и полностью заменяема. В связи с этим можно выделить первую базовую функцию управления системой – поддержание стабильности существующей системы. И конвейер Форда справлялся с этой функцией отлично.

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

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

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

Как мы добьемся изменяемости системы, при том, что мы хотим фильтровать хорошие и плохие изменения?

Ответ: Цикл Деминга-Шухарта. Это достаточно простая концепция, которая дала рост бесчисленному количеству вариантов. Она заключается в том, что изменения системы мы разбиваем на циклы, состоящие из четырех шагов:

1. Планируем изменение (Plan)

2. Проводим его (Do)

3. Проверяем, что наше действие позитивно повлияло на показатели (Check)

4. Проводим коррекцию по результатам измерений (Act)

5. Повторяем все сначала

Вы не находите, что запахло Аджайлом? И это в первой половине прошлого века!

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

Таким образом, Деминг ввел вторую базовую функцию управления системой – внесение изменений.

4. Без метрик невозможен контроль изменений 

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

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

5. Карты Шухарта — простой способ визуализации метрик

Что это мы все про Деминга да про Деминга? Мы же упоминали двух отцов-основателей. И пришло время влететь с ноги в нашу история Уолтеру Шухарту.

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

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

6. Основные виды метрик и некоторые примеры

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

1. Основные результаты нашего процесса. Наша система для чего-то нужна, нужно понять для чего. Например,

   1. Бизнес делают для зарабатывания денег, логичной основной метрикой будет являться прибыль.

   2. Команда разработки пилит фичи, логичной основной метрикой будет количество выпущенных фич\задач\User story.

   3. Интернет магазин продает товары, логичной основной метрикой будет количество продаж и выручка с продажи.

   4. Веб сервер маршрутизирует запросы, логичной основной метрикой будет количество обработанных запросов.

2. Показатели качества основного процесса. Система отдает результат, но вопрос, насколько хорошо она это делает. Например,

   1. Для бизнеса это может быть отношение оборота к чистой прибыли.

   2. Для команды разработки количество багов, которое пролезло в продакшн и TTM.

   3. Для интернет магазина соотношения в воронке продаж и время отклика на действия пользователя.

   4. Для веб-сервера соотношение обработанных запросов к запросу упавшим по вине сервера, доступность сервера.

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

   1. Все что вносит вклад в бизнес.

   2. HR метрики, метрики Git и другие.

   3. Метрики подсистем.

   4. Метрики сервера .

7. После сбора метрик их нужно проанализировать

Итак, мы выбрали метрики и собрали данные. И что делать дальше? 

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

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

Построим временной ряд и рассчитаем линию тренда

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

Наша линия тренда может быть параллельна оси. По Шухарту, стабильный процесс – процесс, который имеет линию тренда равную линии среднего значения, все отклонения имеет около нормальный (гауссовый) характер. Проще говоря, если мы увидели прямую горизонтальную линию тренда – наш процесс стабилен, все отлично.

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

Наша линия тренда может иметь скачки. Очень хорошо, если мы можем сопоставить такие скачки с изменениями в системе. Например, добавили практику TDD, TTM вырос, количество критических багов снизилось. Забросили практику TDD, увидели обратный процесс. Накинули оперативки на сервер, получили меньшее время отклика.

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

Анализируем отклонение точек от линии тренда или от среднего значения (CL) со временем

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

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

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

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

Анализируем «частотное» представление данных

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

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

Вероятнее всего мы увидим нормальное распределение (гауссиану) или какой-нибудь другой вид симметричного распределения, болезненно похожий на нормальное. Если это так, то у нас вероятно все хорошо. По Шухарту, нормальное распределение соответствует стабильному процессу со случайными отклонениями. Если нас устраивает значение пика, мы можем проводить изменения системы, чтобы уменьшить разброс относительно целевого значения. Можем делать что-то чтобы сдвинуть пик.

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

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

Можем увидеть какое-то другое типовое распределение и тут я предлагаю читателю погрузится в изучение темы самостоятельно.

Продолжаем играть с данными

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

Строим модель и предсказываем поведение системы в будущем

Очень тонкий и спорный пункт. Как говорится, все модели ошибочны, но некоторые из них полезны. Тут мы пытаемся зафиксировать некоторые закономерности, например, «увеличение стори поинтов ведет к увеличению срока выполнения задачи», «рекламные компании в среднем увеличивают посещение сайта на 10%», «сервер чаще всего падает, когда объем использованной оперативной памяти переваливает за 97%». Надеюсь ваши выводы будут менее очевидными, и вы сможете их добавить в отчет о проделанной работе.

Кроме того, линию тренда можно продлить бесконечно в будущее, а если еще подкрепить это выводами из построенной модели, может получиться науко-подобный текст, рассказывающий, что через полгода экономическую систему мира ждет крах. Все такие утверждения стоит снабжать ремарками типа: «Если, тренд выбран правильно, то…», «Если зависимость не поменяется, то…», «Если наши рассуждения верны…».

8. Но на самом деле нет

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

Когда мера становится целью, она перестает быть хорошей мерой

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

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

Назначение любых метрик сразу на порядки увеличивает шансы «не увидеть лес за деревьями». Выставляя метрики на всеобщее обозрение, мы заявляем: «Вот это важно, а остальное нет». Даже если мы так не считаем, наверняка найдутся те, кто поймет нас именно так. Таким образом мы сведем нашу сложную систему к ряду ее проявлений. С одной стороны, простых что позволит отслеживать состояния системы, не погружаясь в ее сложность, но почти наверняка абсолютно недостаточных для понимания и отслеживания работы всей системы и ее динамики.

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

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

9. Что мы имеем в итоге?

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

10. Материалы по теме

1. Выход из кризиса. Новая парадигма управления людьми, системами и процессами, Эдвардс Деминг

2. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта. Дональд Уилер, Дэвид Чамберс

3. Инженерные метрики: что мерить, как и зачем?

4. ИТ-ландшафт как сложная система систем

5. ГОСТ Р ИСО 7870-1—2011

6. ГОСТ Р ИСО 7870-2—2011

7. Control Chart в JIRA, все ее тайны

8. Производственный процесс глазами Канбан-практика