7 распространенных заблуждений о метриках DevOps
12 декабря 2022 г.Метрики имеют решающее значение для DevOps и непрерывной доставки как части процесса постоянного улучшения. Однако вы должны сбалансировать сбор и отображение данных с потоком информации. Вам нужно решить, какие данные собирать и на какой меньший набор данных вы обращаете внимание в любое время.
Если бы в вашем автомобиле была приборная панель, на которой отображались бы все показатели, собираемые системой управления двигателем, не было бы места для ветрового стекла.
Ранние автомобили имели только амперметр на приборной панели, который измерял электрический ток между аккумулятором и регулятором напряжения. Это было важно, так как сообщало вам, что система зарядки работает. Спидометра не было. Автомобили могли развивать максимальную скорость только в 35 миль в час, а подвеска препятствовала движению на такой скорости. Не было необходимости измерять скорость.
В современном автомобиле на приборной панели нет места для амперметра (хотя в случае неисправности загорится индикатор аккумулятора). Но, вы найдете спидометр почти в каждой машине. Текущий дизайн приборной панели отражает развитие автомобилей и более широкой системы, в которой они работают. Двигатели стали более мощными, системы подвески лучше, дороги в целом более гладкие, и на дорогах находится больше автомобилей. Изменилось и отношение к безопасности.
Точно так же показатели, которые вы собираете и показываете, со временем будут меняться по мере того, как вы реагируете на различия в вашей команде и организации.
При создании и развитии системы измерения следует избегать некоторых распространенных ошибок.
Игнорирование данных
Первая проблема с метриками заключается в том, что вы тратите огромные усилия на их сбор, но они не всегда используются. Это происходит даже в организациях, которые регулярно просматривают цифры.
Ваши данные нуждаются в некотором процессе, который генерирует идеи. Вы можете превратить то, что вы узнаете из информации, в теории, которые вы используете для экспериментов. После этого эксперименты должны предоставить новые данные для повторного запуска цикла.
Единственная веская причина для сбора показателей DevOps — узнать больше о своей работе и найти способы ее улучшить. Если вы собираете данные на всякий случай, велика вероятность, что они будут использованы не по назначению или вообще не будут использованы.
Предвзятость по активности
Существует 4 уровня измерения, при этом данные об активности часто являются самым ранним и простым для сбора данных. Обычно вы можете отслеживать активность практически в режиме реального времени. Результат действия обычно недоступен в качестве выходной или итоговой метрики до более поздней даты.
Показатели активности обычно являются встроенной функцией ваших существующих инструментов, поэтому они уже доступны. Проблема в том, что не всякая деятельность представляет собой прогресс. Некоторые действия могут даже снизить производительность и привести к худшим результатам.
Вы можете использовать метрики активности, чтобы предсказать будущие изменения выходов и результатов. Для этого вы должны постоянно проверять взаимосвязь между вашими показателями активности и соответствующими выходными или итоговыми показателями.
Если вы измеряете только активность, вы получаете много движений, но никакого прогресса.
Отслеживание слишком большого количества данных одновременно
Количество показателей, которые вы собираете и отображаете, может быстро увеличиваться. Вскоре вы заполнили панель инструментов диаграммами и не знаете, что важно, а что нет.
Вам нужно, чтобы отслеживаемые показатели были компактными, актуальными и актуальными. Когда диаграмма больше не нужна, ее следует удалить с панели инструментов. Вам также следует подумать, нужно ли по-прежнему собирать метрику, и удалить ее, если у вас нет веских причин для ее отслеживания.
Если у вас уже есть информационная панель, откройте ее и для каждой диаграммы спросите: «Что бы я сделал по-другому, если бы это число увеличилось или уменьшилось?». Почаще возвращайтесь к этому вопросу, удаляя все диаграммы, на которые у вас нет ответа.
Ваш набор показателей должен быть ориентирован на ключевые показатели долгосрочных результатов и результатов, а панели мониторинга должны отображать краткосрочные показатели по всем категориям ваших текущих усилий по улучшению.
Переход к инструментам
Инструменты визуализации данных, такие как Microsoft Power BI, Tableau или Google Data Studio, являются одними из самых полезных программных продуктов, которые могут быть в вашей организации. Многие бизнес-инструменты имеют табличный или текстовый интерфейс, но инструменты для работы с данными снабжены красочными анимированными диаграммами.
Легко отвлечься, создавая привлекательную информационную панель. Если вы не начнете с метрического дизайна, вы получите множество приятных информационных панелей, которые никак не повлияют на вашу повседневную работу. Вам нужны информационные панели и инструменты для создания диаграмм, которые помогут вам осмыслить информацию, но сначала разработайте показатели.
Лучше начать с низкого качества, чтобы собирать значимые метрики. Можно начать с простой электронной таблицы или даже белой доски. После того, как вы определите, какие измерения будут полезны вашей команде и организации, начните автоматизировать сбор данных и создавать удобные дисплеи.
Если вы потратите слишком много времени на создание потрясающей информационной панели, вам будет сложнее удалить диаграммы, когда они больше не нужны.
Стандартизация
Некоторые организации пытаются повторить успех высокоэффективной команды, заставляя другие команды следовать тому же процессу. Это редко бывает успешным, поскольку каждая команда работает над разными проблемами и имеет разный уровень квалификации. Точно так же, как процесс и практика должны быть привязаны к контексту, то же самое нужно делать и с показателями.
Вы должны обращаться к метрикам как к части вашей деятельности по постоянному совершенствованию. Для команды с длительным временем выполнения вы измеряете размер партии, время ожидания и время, которое работа проводит в каждом состоянии. Эти показатели не подходят для команды, основной проблемой которой является качество.
Для этого требуются данные, понимание, теория и цикл экспериментов, когда вы просматриваете имеющуюся у вас информацию о проблеме, которую хотите решить, формируете теорию о том, что может улучшить проблему, а затем проводите эксперимент, чтобы проверить свою идею.
Собранные вами показатели также сигнализируют команде, что важно в данный момент. Вы часто видите улучшения просто потому, что ваши показатели говорят о том, что вы заботитесь о каком-то аспекте доставки программного обеспечения.
Полагаться на глазные яблоки
Следует создать простую панель мониторинга для отображения показателей, которые вы отслеживаете для экспериментов. Это должно отображаться на информационном излучателе, чтобы все члены команды могли видеть данные.
Однако, если вы реагируете на данные только тогда, когда кто-то смотрит на информационную панель, вы заполните информационную панель слишком большим количеством информации и пропустите ключевые события. Долгосрочные показатели, которые вы ведете для отслеживания прогресса с течением времени, кажутся такими же важными, как и краткосрочные показатели, которые вы используете для улучшения доставки своего программного обеспечения.
Ключом к решению проблемы сохранения долгосрочных метрик без загромождения вашей информационной панели является создание процесса мониторинга и оповещения для данных. Автоматические оповещения должны сообщать вам, если показатели превышают пороговое значение, и вы можете использовать обнаружение аномалий, чтобы сообщать вам, произошло ли что-то интересное.
Показатели отслеживаются автоматически, вы можете удалить их с панели управления, чтобы освободить место.
Поощрение эффективности
Если ваша команда работает над увеличением скорости развертывания, может возникнуть соблазн поощрить их вознаграждением за ежедневные развертывания. Такой подход к мотивации приводит к плохим результатам. Команда может пропустить другую важную работу ради достижения цели — не для того, чтобы обмануть систему, а потому, что вы сделали ежедневные развертывания более важными, чем что-либо еще.
В исторической книге Альфи Кон объясняется, что попытки управлять людьми с помощью стимулов наносят долгосрочный ущерб вашей организации. Сотни исследований показали, что люди хуже работают, когда им предлагают вознаграждение.
Использование метрик для создания соревновательной атмосферы для индивидуальной работы, сравнения разных команд или для геймификации рабочего места (где вы вводите игровые элементы как форму «веселого» соревнования) — все это приводит к проблемам.
Конкуренция противоречит тому, что вам действительно нужно в вашей организации: сотрудничеству. Если вы будете исходить из того, что люди хотят делать свою работу хорошо, вы обнаружите, что вам не нужно использовать поощрения или наказания, чтобы заставить их работать лучше.
Заключение
Пять показателей DORA и платформа SPACE предоставляют готовые сбалансированные способы измерения производительности доставки программного обеспечения. (Раньше было 4 показателя DORA, но был добавлен дополнительный показатель надежность.)
Хороший набор метрик будет сочетать опережающие индикаторы для прогнозирования производительности с запаздывающими индикаторами, которые проверяют точность прогнозов. Измерения должны охватывать категории действий, результатов, результатов системы и результатов.
Что бы вы ни измеряли, вам необходимо постоянно совершенствовать свои показатели, чтобы они оставались полезными для вашей команды и организации. В идеале собираемые вами показатели относятся к конкретному эксперименту, который вы проводите для проверки теории.
Если вы правильно используете метрики, вы повышаете производительность и обучаемость, стремясь стать одним из лучших исполнителей в поставке программного обеспечения.
Также опубликовано здесь
Оригинал