Привет Хабр!


Года три назад я сидел на встрече с топ‑менеджментом и показывал отчёт по ИТ. Красивые слайды, графики растут вверх и вправо, SLA — зелёный, количество закрытых тикетов бьёт рекорды, релизов в месяц — вдвое больше, чем год назад. Всё выглядело отлично, я был уверен, что сейчас похвалят.

А директор по развитию посмотрел на меня и спросил: «Почему тогда мы до сих пор две недели ждём простую интеграцию с новым поставщиком? И почему бухгалтерия каждую неделю жалуется, что у них что‑то падает?»

Я замялся. Потому что вся эта красота на слайдах говорила о том, как много мы делаем, но не объясняла, почему бизнесу от этого не легче. Оказалось, что половина «закрытых тикетов» — это переоткрытые старые, релизы состояли из мелких фиксов без реальной пользы, а SLA считался по системам, которые никого особо не волновали.

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

Что делает метрику полезной, а что превращает её в показуху

Перед тем как разбирать конкретные примеры, полезно понять общий принцип: когда метрика работает на вас, а когда вы работаете на метрику.

Признаки живой метрики

1. Она влияет на решения

Хорошая метрика — это та, по которой вы что‑то меняете. Увидели, что MTTR по одному сервису растёт три месяца подряд — выделили ресурсы на рефакторинг или автоматизацию мониторинга. Заметили, что время деплоя выросло вдвое — начали искать узкие места в пайплайне.

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

2. Её понимает команда

Метрика должна быть понятна тем, кто реально делает работу. Если разработчик видит «Lead Time for Changes» и понимает, что это его время от коммита до прода, он может думать, как его улучшить. Если вы показываете «Коэффициент эффективности использования инфраструктуры» — все кивают, но никто не знает, что с этим делать.

3. Она связана с целью

Любая метрика должна отвечать на конкретный вопрос:

·         Мы быстро чиним то, что сломалось? → MTTR, частота инцидентов.

·         Мы доставляем фичи быстрее? → Lead time, частота деплоев.

·         Мы эффективно тратим бюджет? → Удельные затраты ИТ на пользователя/заказ.

Если непонятно, зачем метрика и на какой вопрос она отвечает, скорее всего, она «для красоты».

Что такое vanity metrics и почему они опасны

Vanity metrics — это метрики‑обманки. Они выглядят впечатляюще, растут красиво, но не говорят ничего про реальную пользу или проблемы.

Классический пример из продуктов: «у нас миллион пользователей зарегистрировались». Звучит круто, но если 90% из них зашли один раз и ушли, цифра ничего не значит.

В ИТ то же самое. «Мы закрыли 500 тикетов в месяц» — отлично, но если 200 из них — это одна и та же проблема, которую никак не чинят, а просто переоткрывают, то вы просто крутитесь на месте.

Опасность vanity metrics в том, что они создают иллюзию прогресса. Вы смотрите на дашборд, видите рост цифр, думаете «всё ок», а на самом деле команда выгорает, бизнес недоволен, технический долг растёт.

Какие метрики в ИТ реально помогают

Надёжность: насколько у нас всё падает и как быстро встаёт

Первая группа метрик — про то, живы ли вообще наши сервисы.

  • Среднее время восстановления после сбоя. Показывает, как быстро вы поднимаете систему, когда всё уже плохо. Если время растёт — это сигнал, что где-то нет процедур, автоматизации или знаний.

  • Частота инцидентов по сервисам. Не «вообще по компании», а по конкретным системам. Сразу видно, где болит чаще всего и куда стоит направить усилия.

  • Повторяющиеся инциденты. Если один и тот же тип аварии всплывает снова и снова, никакая красивая статистика по «закрытым тикетам» не спасёт — проблема просто маскируется.

По этим метрикам можно принимать очень приземлённые решения: куда отправить сильнейших инженеров, где нужно выделить время на устранение первопричин, какие сервисы нельзя трогать без плана.

Изменения: как мы выкатываем и насколько болезненно

Вторая группа — про то, как вы доставляете изменения в прод.

  • Частота выпусков. Не ради самой цифры «у нас сто релизов в месяц», а как признак того, что процесс поставки достаточно отлажен и мелкие изменения выкатыва��тся без страха.

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

  • Доля неудачных релизов. Сколько выпусков приходится откатывать или срочно чинить после выката. Если цифра высокая — это повод пересмотреть тестирование, согласования и сам подход к изменениям.

Эти метрики помогают ответить на простой вопрос: «мы ускоряемся или просто больше бегаем на месте».

Операционная эффективность: как мы тратим силы и деньги

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

  • Доля ручных операций. Сколько задач в ИТ по‑прежнему делается руками: заведение пользователей, настройки, типовые изменения. Чем выше доля ручного труда, тем больше риск ошибок и выгорания.

  • Удельные затраты ИТ. Не «общий бюджет ИТ», а, например, расходы на одного активного пользователя, на один заказ, на один сервер. Это помогает понять, где вы действительно переплачиваете, а где всё уже неплохо.

  • Время отклика ИТ на типовые запросы. Насколько быстро сотрудники получают доступ, оборудование, нужный сервис. Это очень понятная для бизнеса метрика, которая хорошо показывает, тормозит ли ИТ развитие компании.

Здесь важен не сам факт «мы всё измерили», а то, что по этим цифрам можно менять процессы, приоритеты и состав команды.

Метрики, которые просто красиво смотрятся

Теперь — про цифры, которые часто попадают в отчёты, но мало помогают.

Количество закрытых тикетов

Любимая метрика служб поддержки и сервис‑десков. На бумаге всё просто: чем больше закрыли, тем лучше работаем. На практике:

  • один и тот же инцидент может переоткрываться много раз;

  • сложные заявки ломаются на несколько мелких;

  • часть тикетов вообще не про работу, а про «передвиньте мне кнопку».

Без контекста сложности, повторов и причин такая метрика больше про объём, чем про качество.

Количество релизов

«Мы релизим сто раз в месяц» звучит впечатляюще, но:

  • можно выпускать десятки мелких фиксов, не меняя ничего важного для пользователя;

  • можно выкатывать сырые изменения, которые потом приходится чинить.

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

Общий процент доступности

«У нас 99,99% доступности» часто скрывает:

  • что считают среднюю температуру по всем системам, включая неважные;

  • что падения в критичных сервисах размазываются по общей статистике.

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

Количество автоматизаций, скриптов, дашбордов

Чем их больше, тем эффектнее выглядят презентации. Но:

  • автоматизация, которой никто не пользуется, не экономит ни минуты;

  • дашборды, которые никто не открывает, не помогают принимать решения.

Важно не сколько у вас «штук», а сколько из них реально снимают ручной труд и помогают работать.

Количество внедрённых систем и проектов

Цифра «мы за год внедрили десять систем» хорошо смотрится в годовом отчёте, но ничего не говорит о том:

  • пользуются ли ими сотрудники;

  • окупились ли они;

  • сколько боли они добавили в поддержку и интеграции.

Зачастую один хорошо сделанный проект даёт больше пользы, чем пять «для галочки».

Почему такие метрики всё равно любят

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

Задача ИТ‑руководителя — не запретить такие цифры совсем, а перестать воспринимать их как доказательство эффективности. Пусть остаются как фон, но ключевые решения лучше опирать на более приземлённые и честные показатели.

Минимальный набор метрик: команде одно, руководству другое

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

Для операционных команд (поддержка, эксплуатация, DevOps)

Здесь важны метрики, которые помогают прожить день, неделю, релиз.

  • Среднее время восстановления после сбоя по ключевым сервисам.

  • Частота инцидентов и повторные инциденты по типам.

  • Время поставки изменений от готового кода до продакшена.

  • Доля автоматизированных операций в типовых задачах.

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

Для руководителей ИТ и бизнеса

Здесь метрики должны быть проще и ближе к языку денег и пользы.

  • Доступность критичных сервисов в рабочее время.

  • Время реакции ИТ на типовые бизнес‑запросы (подключить, изменить, интегрировать).

  • Удельные расходы на ИТ в привязке к понятным объектам (пользователь, заказ, подразделение).

  • Время от идеи до первой реальной ценности для бизнеса по ключевым инициативам.

По этим показателям можно отвечать на вопросы: «ИТ тормозит развитие или помогает?», «мы тратим слишком много или наоборот, недоинвестируем?», «где у нас самые дорогие и самые бессмысленные сложности».

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

Как внедрять метрики и не получить бунт

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

Начинать с пользы для команды

Если первая презентация про метрики выглядит как «теперь мы будем за вами ещё пристальнее следить», ничего не взлетит. Гораздо честнее прийти и сказать:

  • давайте выберем 3–4 цифры, которые помогут именно вам меньше гореть и меньше тушить пожары;

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

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

Не привязывать всё сразу к премиям

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

Гораздо здоровее сначала прожить с набором метрик несколько месяцев «в учебном режиме»: смотреть, обсуждать, улучшать, не наказывая людей за каждое колебание. И только потом аккуратно привязывать некоторые показатели к мотивации, если это вообще нужно.

Регулярно чистить и пересматривать дашборды

Метрики имеют свойство ржаветь. Что‑то перестаёт быть актуальным, что‑то считалось «как получилось», какие‑то показатели так ни разу ни на что не повлияли.

Нормальная практика — хотя бы раз в полгода устраивать ревизию:

  • какие цифры мы за это время хоть раз использовали для решений;

  • какие только занимают место;

  • какие было бы полезно добавить в свете новых задач.

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

Как отличить живую метрику от декоративной: короткий чек‑лист

В завершение — простой фильтр, который можно применить к любому показателю на вашем дашборде:

1.       Понимаю ли я, на какой вопрос отвечает эта метрика своими словами?

2.      Могу ли я вспомнить хоть один случай, когда по этой цифре мы что‑то поменяли в процессах или приоритетах?

3.      Знает ли команда, от чего она зависит и что нужно сделать, чтобы её улучшить?

4.      Понимает ли бизнес, почему эта метрика важна, если показать её без технических подробностей?

5.       Смог бы я честно объяснить, что будем делать, если значение резко ухудшится?

Если хотя бы на два‑три пункта ответа нет — скорее всего, перед вами не инструмент, а украшение. А украшения хороши на стене, но плохи в роли компаса для ИТ.

Сводные таблицы метрик которые использую в дашбордах:

Операционные метрики (для команд поддержки, эксплуатации, Dev/DevOps)

Приоритет

Метрика

Для кого

Что показывает

Зачем нужна на практике

1

Среднее время восстановления (MTTR)

Операции

Как быстро поднимаем сервис после сбоя

Приоритизация автоматизации, дежурств, устранения причин

2

Частота инцидентов по сервисам

Операции

Какие системы ломаются чаще всего

Фокус на проблемных сервисах, обоснование инвестиций

3

Повторяющиеся инциденты

Операции

Где мы «латаем», а не лечим

Выделение времени на устранение первопричин

4

Время реакции на инциденты

Операции

Как быстро команда реагирует на проблемы

Настройка дежурств, процессов эскалации

5

Время решения инцидентов

Операции

Полный цикл «нашли → починили»

Измерение зрелости процессов поддержки

6

Время поставки изменений (от кода до прода)

Dev/DevOps

Насколько эффективен процесс выката

Поиск узких мест в пайплайне, настройка релизной политики

7

Частота выпусков

Dev/DevOps

Насколько часто мы можем безопасно выкатываться

Понимание гибкости и «пластичности» системы

8

Доля неудачных релизов

Dev/DevOps

Насколько больно проходят изменения

Баланс скорости и качества, улучшение тестирования

9

Доля автоматизированных операций

Операции

Сколько рутины делается вручную

Поиск точек для автоматизации, снижение выгорания

10

Время выполнения типовых операций

Операции

Насколько быстро проходят стандартные процедуры

Оптимизация регламентов и инструментов

11

Доля инцидентов, решённых с первого обращения

Поддержка

Качество работы первой линии поддержки

Нужна ли донастройка процессов, обучение, пересмотр ролей

12

Доля инцидентов, переведённых на 2–3 линию

Поддержка

Насколько эффективно фильтруется нагрузка

Баланс компетенций между линиями поддержки

13

Количество критичных инцидентов (P1/P0)

Операции

Частота серьёзных аварий

Оценка общей стабильности ландшафта

14

Средний возраст задач технического долга

Архитектура

Как долго висят известные проблемы

Аргумент для выделения времени на долг

15

Доля задач по долгу в общем портфеле

Архитектура

Насколько серьёзно относятся к долгу

Баланс между новым функционалом и оздоровлением систем

16

Удельное количество инцидентов на сервис

Операции

Какие сервисы приносят больше всего проблем

Решение: переписать, отключить, инвестировать

17

Доля изменений, прошедших без ручных действий

DevOps

Зрелость автоматизации выката

Степень зависимости от «героизма» отдельных людей

18

Заполненность и актуальность базы знаний

Операции

Есть ли у команды доступ к живым знаниям

Понимание, где знания мешают, а не помогают

Верхнеуровневые KPI и метрики для CIO / бизнеса

Приоритет

Метрика

Для кого

Что показывает

Зачем нужна на практике

1

Доступность ключевых сервисов в рабочее время

CIO, бизнес

Насколько стабильны критичные для бизнеса системы

Оценка надёжности ИТ с точки зрения бизнеса

2

Время реакции на типовые бизнес‑запросы

CIO, бизнес

Насколько быстро ИТ помогает бизнесу двигаться

Оценка «скорости ИТ» глазами внутренних заказчиков

3

Время от идеи до первой ценности

CIO, бизнес

Как быстро ИТ превращает запрос в пользующуюся функцию

Оценка скорости изменений, аргумент в спорах о приоритетах

4

Удельные затраты ИТ на пользователя/заказ

CIO, финансы

Сколько реально стоит ИТ на единицу бизнеса

Сравнение с рынком, поиск резервов, защита бюджета

5

Доля расходов ИТ по направлениям (поддержка/развитие)

CIO, бизнес

Куда уходит бюджет: на «тушение» или на развитие

Перекос в сторону модернизации или, наоборот, поддержки

6

Время решения инцидентов по критичным сервисам

CIO, бизнес

Насколько быстро восстанавливается важный функционал

Оценка влияния ИТ‑сбоев на бизнес

7

Количество критичных инцидентов (P1/P0)

CIO, бизнес

Как часто бизнес сталкивается с серьёзными простоями

Аргумент для инвестиций в надёжность

8

Удовлетворённость внутренних пользователей

CIO, HR, бизнес

Насколько комфортно работать с ИТ‑сервисами

Выявление болевых точек, которые не видны по технике

9

Доля задач по долгу в портфеле крупных инициатив

CIO, архитектура

Насколько стратегически вычищается старый хлам

Баланс краткосрочной выгоды и долгосрочного здоровья

10

Доля автоматизации в ключевых бизнес‑процессах

CIO, бизнес

Насколько ИТ помогает убирать ручной труд

Связь ИТ‑инвестиций с реальной эффективностью процессов

11

Доля инициатив, давших заявленный эффект

CIO, бизнес

Какой процент проектов реально дал обещанный результат

Зрелость отбора и управления портфелем инициатив

12

Доля ИТ‑расходов в выручке/марже

CIO, финансы

Место ИТ в общей экономике компании

Понимание, не «проедает» ли ИТ слишком много

Заключение

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

Главное отличие живой метрики от мёртвой — вы помните, когда в последний раз по ней что‑то меняли. Если не помните — это просто красивая строчка в отчёте.

Мой совет: откройте дашборд прямо сейчас и честно пройдитесь по каждому показателю. Спросите себя: «Если эта цифра завтра станет в два раза хуже, я пойду разбираться и что‑то менять?» Если ответ «нет» или «наверное, нет» — смело удаляйте. Освободите место для тех метрик, которые действительно помогают вам делать работу, а не просто украшают слайды.

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

Владислав Прокопович