Хочу поделиться тем, как мы собрали единый дашборд метрик, которые быстро оценивают как эффективно работает ИТ команда. Что он позволяет нам делать:
Подсвечивать слабые, проблемные места в процессах и работать с ними на ретроспективах
Объективно оценивать текущее состояние команды, а не полагаться на ощущения
Ставить достижимые цели и принимать стратегические решения на основании данных
Справедливо поощрять команду
Немного контекста: наша команда из 15 человек занимается продуктовой разработкой и выполняет роль второй линии поддержки. Поэтому мы собрали единые метрики и по разработке и поддержке в один дашборд. Когда наша команда станет больше, то мы планируем разделить метрики на каждую команду, у которых может быть своя специфика: где-то будут другие метрики и приоритеты, соответственно будут распределяться их веса.
В этой статье я покажу, как выстроить систему метрик здоровья — от выбора показателей до автоматизации сбора данных.
Структура метрик: 4 основные группы
Метрики здоровья мы разделили на четыре группы:
Доступность (вес 50%)
Скорость (вес 20%)
Качество (вес 20%)
Здоровья процесса (вес 10%)
Доступность сервисов
Самая весомая группа, потому что недоступный сервис = потерянные деньги и негативное влияние на репутацию. Если вы работаете в крупных финтех или продуктовых компаниях, то объяснять, как измерять доступность вам не нужно. Для тех, кто еще новичок в этом деле, чтобы не споткнуться на этой группе метрик (т.к. измерение доступности - это полноценный проект, который включает сбор требований, описание механики измерения SLA/SLO, реализация и визуализация этих метрик), мы предлагаем начать с трех базовых метрик, на сбор которых не потребуется много ресурсов.
API Uptime
Что измеряем: процент времени доступности API
SLA: 99,9%
Как считаем: Берем из логов данные о состоянии сервера(ов), сохраняем время UP/DOWN и рассчитываем по нему время недоступности.
Uptime = (Время работы / Общее время) × 100%
Время работы = Общее время - Время недоступности
Пример: в ноябре (720 часов) было 1,07 часа недоступности: Uptime = ((720ч - 1,07ч) / 720ч) × 100% = 99,85%
Цветовые индикаторы:
🟢 Зеленый: выше 99,9% попадает в цель
🟡 Желтый: 98-99,9% попадает в цель
🔴 Красный: менее 98% попадает в цель
Источник данных: логи
Вес в группе: 0,5
Latency (p95)
Что измеряем: процент времени, в течение которого p95 времени ответа API не превышает 500ms
SLA: 99,5%
Как считаем: каждую минуту фиксируем значение p95 времени ответа. Если в данную минуту p95 > 500ms — минута считается недоступной.
Доступность = (Минуты в норме / Всего минут) × 100%
Пример: 20 минут из 100 p95 превышал 500ms → доступность по метрике 80%
Цветовые индикаторы:
🟢 Зеленый: выше 99,5% попадает в цель
🟡 Желтый: 98-99,5% попадает в цель
🔴 Красный: менее 98% попадает в цель
Источник данных: Prometheus
Вес в группе: 0,4
Ошибки 5хх
Что измеряем: процент времени, в течение которого доля ошибок 5хх не превышает 5% от общего числа запросов
SLA: 99,5%
Как считаем: каждую минуту фиксируем долю ошибок 5хх. Если в данную минуту доля > 5% — минута считается недоступной.
Доступность = (Минуты в норме / Всего минут) × 100%
Пример: 20 минут из 100 доля ошибок превышала 5% → доступность по метрике 80%
Цветовые индикаторы:
🟢 Зеленый: выше 99,5% попадает в цель
🟡 Желтый: 98-99,5% попадает в цель
🔴 Красный: менее 98% попадает в цель
Источник данных: Prometheus
Вес в группе: 0,1
Скорость разработки и поддержки
Эта группа показывает, насколько быстро и предсказуемо команда доставляет ценность бизнесу.
Lead Time: время от идеи до продакшена
Что измеряем: время от статуса "Будем делать" до "Мониторинг результатов на проде"
Целевые значения мы разбили по размеру задач:
S-задачи: 5 дней, 75%+ выполняются в срок
M-задачи: 10 дней, 75%+ выполняются в срок
Цветовые индикаторы:
🟢 Зеленый: выше 75% попадает в цель
🟡 Желтый: 50-75% попадает в цель
🔴 Красный: менее 50% попадает в цель
Источник данных: система тренинга задач (например, Yandex Tracker)
Вес в группе: 0,6
Время реакции на обращения
Что измеряем: Lead Time реакции на инциденты от первой линии (от "Открыт" до "В работе")
SLA: 30 минут
Целевые значения:
🟢 Зеленый: 80%+ выполняется в срок
🟡 Желтый: 70-80% выполняется в срок
🔴 Красный: менее 70% выполняется в срок
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,1
Время устранения критичных инцидентов
Что измеряем: время полного устранения критичных инцидентов (P0, P1)
SLA: 2 часа от "Открыт" до "Закрыт"
Целевые значения:
Инцидентов всего | Нарушений SLA | Зона | Значение метрики |
0 | 0 | 🟢 | 100 % |
1-2 | 0 | 🟢 | 100 % |
3-5 | 0 | 🟡 | 70 % |
больше 5 | 0 | 🟡 | 70 % |
любое | 1 | 🟡 | 70 % |
любое | 2 | 🔴 | 50 % |
менее 5 | 3 и более | 🔴 | 20 % |
более 5 | 3 и более | 🔴 | 0% |
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,1
CSAT/Скорость
Что измеряем: оценка инициатором удовлетворенности скоростью поставки (шкала 1-3)
Целевые значения:
🟢 Зеленый: от 2 и выше
🟡 Желтый: 1,8-2
🔴 Красный: ниже 1,8
Субъективная метрика, но она показывает, насколько команда оправдывает ожидания стейкхолдеров.
Источник данных: мы настроили запрос оценки при закрытии задач в трекере. Через триггер мы отправляем событие, которое обрабатывается и отправляется через Телеграмм-бот бизнес-пользователям. Мы сохраняем ответы в свою БД и визуализируем их на дашборах в DataLens. Команда видит только итоговые оценки, а руководитель имеет доступ к детальным оценкам и комментариям, чтобы при необходимости разобрать ситуации с командой.
Вес в группе: 0,2
Качество работы
Доля успешных релизов
Что измеряем: доля релизов, которые были выпущены без сбоев и критичных ошибок
Как измеряем: Если в процессе релиза возник сбой из-за которого пришлось откатывать релиз или делать срочные исправления из-за ошибки с высокой критичностью, то релиз считается неуспешным. В метриках учитываем долю успешных релизов.
Целевые значения:
🟢 более 95%
🟡 85-95%
🔴 ниже 85%
Источник данных: Github
Вес в группе: 0,3
CSAT/Качество
Что измеряем: оценка инициатором удовлетворенности качеством выполнения задачи (шкала 1-3)
Целевые значения:
🟢 Зеленый: от 2 и выше
🟡 Желтый: 1,8-2
🔴 Красный: ниже 1,8
Как измеряем: запрашиваем вместе с оценкой CSAT/Скорость.
Вес в группе: 0,3
Число переоткрытых обращений
Что измеряем: процент переоткрытых обращений за месяц (возврат из "Закрыт" обратно в "Работу")
Целевые значения:
🟢 Зеленый: 0-3%
🟡 Желтый: 3-10%
🔴 Красный: более 10%
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,3
CSAT/Поддержка
Что измеряем: оценка инициатора, сотрудника 1-й линии, удовлетворенности ответом и решением обращения (шкала 1-3)
Целевые значения:
🟢 Зеленый: от 2 и выше
🟡 Желтый: 1,8-2
🔴 Красный: ниже 1,8
Как измеряем: аналогично CSAT/Скорость.
Вес в группе: 0,2
Здоровье процесса
В эту группу могут входить метрики производительности команды, а также метрики, которые отражают соблюдение договоренностей, существующих в команде. У нас эти договоренности касаются распределения ресурсов по проектам, а также уровня декомпозиции задач. Для каждой команды эти договоренности индивидуальны. Для кого-то это соблюдение уровня техдолга в беклоге, для кого-то гигиена списания трудозатрат. Например, в прошлой моей команде у нас действовало соглашение «Не катить г**о на прод», оно прямо так и было зафиксировано в нашем командном соглашении, это означало, что количество «костылей» должно стремиться к нулю. Отличная метрика здоровья! Если таких договоренностей у вас еще нет, то рекомендую провести с командой встречу для заполнения Team Canvas. Это хороший инструмент для сплочения команды, выявления мотивации и фиксации договоренностей, которые возможно стоит всего один раз проговорить и записать на доске, чтобы они начали соблюдаться.
Итак, лирическое отступление закончено. Какие метрики ходят в эту группу:
Динамика пропускной способности
Что измеряем: среднее отклонение и вариативность
Целевые значения:
Среднее отклонение
🟢 Зеленый: положительное
🔴 Красный: отрицательное
Вариативность менее 30%
🟢 Зеленый: менее 30%
🟡 Желтый: более 30%
🔴 Красный: более 50%
Как считаем:
Плановая пропускная способность — среднее количество StoryPoint за последние 5 спринтов
Загрузка = Фактическая пропускная способность / Плановая пропускная способность × 100%
Отклонение = Загрузка - 100%
Вариативность = ABS(Отклонение)
Perfomance Rate для среднего отклонения решили считать бинарно. 100% - если положительно, 0% если отрицательно.
Считаем значения каждый спринт, в дашборд включается средние значения за месяц.
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,4
Доля L-задач
Что измеряем: процент больших задач в общем потоке. Большая доля L-задач - это высокий уровень неопределенности и риска срыва сроков. Декомпозиция задач требует времени и ресурсов на то, чтобы спланировать какими частями можно реализовать задачу, чтобы она начала приносить ценность раньше, оценить плюсы и минусы реализации частями. Зачастую мы попадаемся в ловушку, что проще сделать «все разом», а в итоге сроки затягиваются, функционал к задаче прирастает, границы размываются. При этом действительно есть задачи, которые лучше не дробить, а сделать целиком. Поэтому мы договорились, что такие задачи могут быть, но их не должно быть более 10% от общего объема задач (мы измеряем общий объем в Story Points)
Целевое значение:
🟢 Зеленый: менее 10%
🟡 Желтый: более 10%
🔴 Красный: более 20%
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,2
Распределение ресурсов по проектам
Что измеряем: попадание в целевое значение проекта (Проект А - 40%, Проект Б - 20%, Проект В - 20%, Техдолг - 20%) - данные показатели учитываются в бюджетировании и в расчете юнит-эконмики, поэтому важно придерживаться такого фактического распределения.
Целевые значения:
🟢 среднее отклонение 0-2%, максимальное 0-5%
🟡 среднее 2-5%, максимальное 5-7%
🔴 среднее более 5%, максимальное более 7%
Источник данных: система трекинга задач (например, Yandex Tracker)
Вес в группе: 0,4
Итоговый индекс здоровья
Все группы метрик сводятся в один показатель с учетом весов:
Index = Доступность сервисов × 0,5 + Скорость разработки и поддержки × 0,2 + Качество работы × 0,2 + Здоровье процесса × 0,1
Каждая группа считается как сумма метрик, умноженных на их вес внутри группы.
Общие правила расчета:
Все значения округляем до двух знаков после запятой
Если Performance Rate < 0, то Performance Rate = 0
Performance rate = (1 - (Текущее значение - Цель)/Цель) * 100 % для метрик, где чем меньше тем лучше.
Performance rate = Текущее значение / Цель * 100 % для метрик где чем больше тем лучше.
Покажу пример расчета
Доступность сервисов
Метрика | Цель (%) | Текущее значение (%) | Зона | Performance rate (%) | Вес в группе | Итоговый вес |
API Uptime | 99,9 | 99,8 | 🟢 | 99,90 | 0,5 | 0,25 |
Latency (p95) | 99,5 | 99,4 | 🟡 | 99,90 | 0,4 | 0,2 |
Ошибки 5хх | 99,5 | 99,2 | 🟡 | 99,70 | 0,1 | 0,05 |
Скорость разработки
Метрика | Цель | Текущее значение | Зона | Performance rate (%) | Вес в группе | Итоговый вес |
Lead Time - S | Выше 75% выполняется в срок менее 5 дней | |||||
75 | 73 | 🟡 | 97,33 | 0,15 | 0,03 | |
5 | 6 | 🟡 | 80,00 | 0,15 | 0,03 | |
Lead Time - M | Выше 75% выполняется в срок менее 10 дней | |||||
75 | 80 | 🟢 | 106,67 | 0,15 | 0,03 | |
10 | 9 | 🟢 | 110,00 | 0,15 | 0,03 | |
CSAT/ Скорость соответствие ожиданиям | выше 2 | |||||
2 | 2,1 | 🟢 | 105,00 | 0,2 | 0,04 | |
Время полного устранения критичных инцидентов | SLA 2 часа | - | ||||
Количество обращений P0, P1 | 3 | |||||
Соблюдение SLA | 2 | 🟡 | 70 | 0,1 | 0,02 | |
Время реакции на обращения от 1-й линии поддержки | SLA 30 минут | |||||
100 | 80 | 🟢 | 80 | 0,1 | 0,02 |
Качество работы
Метрика | Цель | Текущее значение | Зона | Performance rate (%) | Вес в группе | Итоговый вес |
CSAT/ Качество соответствие ожиданиям | Выше 2 | |||||
2 | 1,6 | 🔴 | 80,00 | 0,3 | 0,06 | |
Процент переоткрытых обращений от HELPDESK | менее 3% | |||||
3 | 2 | 🟢 | 133,33 | 0,2 | 0,04 | |
Доля успешных релизов | более 95% | |||||
95 | 85 | 🟡 | 89,47 | 0,3 | 0,06 | |
CSAT/ Оценка качества ответа | выше 2 | |||||
2 | 1,8 | 🟡 | 90,00 | 0,2 | 0,04 |
Здоровье процесса
Метрика | Цель | Текущее значение | Зона | Performance rate (%) | Вес в группе | Итоговый вес |
Доля задач L | Менее 10% | |||||
10 | 9 | 🟢 | 110,00 | 0,2 | 0,02 | |
Пропускная способность | Среднее отклонение от плана положительное и вариативность менее 30% | |||||
0 | 5 | 🟢 | 100,00 | 0,2 | 0,02 | |
30 | 20 | 🟢 | 133,33 | 0,2 | 0,02 | |
Отклонение по проектам | менее 2% среднее и менее 5% максимальное | |||||
максимальное | 5 | 6 | 🟡 | 80,00 | 0,2 | 0,02 |
среднее | 2 | 2 | 🟢 | 100,00 | 0,2 | 0,02 |
Index = 98,53 🟢
Цветовые индикаторы Индекса здоровья:
🟢 Зеленый: выше 98%
🟡 Желтый: 95-98%
🔴 Красный: менее 95%
Какие выводы можно сделать из этого примера:
Сильные стороны
Надёжность — явный козырь команды: API Uptime 99.8%, Latency и ошибки 5xx буквально у цели. Lead Time для задач M перевыполнен, CSAT по скорости 2.1 при цели 2.0. Переоткрытые обращения тоже хорошо — 2% при допустимых 3%.
Проблемные зоны
Главная тревога — CSAT PM (качество) = 1.6 при цели 2.0. Заказчики недовольны именно качеством. При этом скоростная CSAT в норме — то есть команда работает быстро, но что-то не так с результатом.
Это, скорее всего, связано со второй проблемой: доля успешных релизов 85% при цели 95%. Каждый шестой релиз проходит неудачно — это прямой источник разочарования у заказчиков.
Общий вывод
Итоговый Индекс 98.5% в зеленой зоне, но команде стоит поработать над качеством. И разобраться в чем проблема: плохой уровень спецификации? работы с ожиданием заказчиков? качеством кода? Почему при низкой оценке качества и успешности релизов такой высокий уровень доступности? Точно ли верно выбраны SLA доступности? Точно ли верно оценивается критичность инцидентов?
Периодичность контроля
Большинство метрик считаются в реальном времени и обратиться к ним можно в любой момент. Контроль метрик происходит ежемесячно, а отчет перед руководством - один раз в полугодие. Этот отчет влияет на расчет премий команды.
Практические советы по внедрению
1. Начните с малого
Не пытайтесь внедрить все метрики сразу. Начните с 3-5 самых критичных для вашей команды.
2. Настройте автоматический сбор
Ручной сбор данных быстро надоест и метрики забросят. Автоматизируйте с первого дня.
3. Объясните команде "зачем"
Метрики не для контроля, а для улучшения процесса. Команда должна это понимать.
4. Пересматривайте целевые значения
То, что было нормой полгода назад, может стать слишком легким или слишком жестким сейчас.
5. Не наказывайте за красные зоны
Красный индикатор — это сигнал для разбора и улучшения процесса, а не повод ругать команду.
6. Используйте метрики для диалога с бизнесом
Когда продакт просит "сделать быстрее", покажите пропускную способность команды и Leadtime — это основа для конструктивного диалога.
Частые ошибки
❌ Слишком много метрик — информационный шум, никто не анализирует
✅ 5-7 ключевых метрик — фокус на главном
❌ Метрики как инструмент давления — команда начинает "оптимизировать" метрики, а не процесс
✅ Метрики как информация для решений — открытое обсуждение и совместный поиск решений
❌ Игнорирование контекста — низкая пропускная способность может быть из-за сложности задач, а не лени команды
✅ Анализ с учетом контекста — отпуска, новички, технические сложности
❌ Статичные целевые значения — то, что было реалистично год назад, может быть неактуально
✅ Регулярный пересмотр — раз в квартал смотрим, адекватны ли наши цели
Заключение
Метрики здоровья — это не волшебная таблетка, которая решит все проблемы. Это инструмент, который помогает увидеть реальную картину и принимать осознанные решения.
Правильно выстроенная система метрик дает:
Предсказуемость — можно планировать на несколько кварталов вперед
Раннее обнаружение проблем — видишь тренды до того, как начался пожар
Объективность — решения на основе данных, а не эмоций
Язык для диалога — можно конструктивно говорить с бизнесом о возможностях
Начните с простого: выберите 3-5 метрик, настройте автосбор, дайте команде квартал на адаптацию. Результаты не заставят себя ждать.
За какими метриками здоровья вы следите в своей команде? Поделитесь опытом в комментариях.
