Руководителю нужны не все IT-метрики. Ему нужны показатели, по которым можно понять, мешает ли IT работе бизнеса, где растет риск и какие решения требуют бюджета или организационного согласования. Инженеру, наоборот, нужна подробная телеметрия: загрузка ресурсов, ошибки служб, задержки, очереди, статусы заданий и технические причины.
Проблема начинается, когда эти уровни смешивают. Отчет на двадцать графиков может выглядеть серьезно, но не отвечать на главный вопрос: стало ли обслуживание надежнее, где повторяются сбои и что нужно изменить.
Три уровня IT-метрик
Удобнее разделять показатели на три слоя: бизнес-метрики, сервисные метрики и инженерную диагностику. Они не конкурируют между собой. Каждый слой отвечает на свой вопрос.
| Уровень | Вопрос | Примеры | Кому нужен |
|---|---|---|---|
| Бизнес | Что мешало работе компании? | Простой ключевого сервиса, влияние на отделы, повторяемые риски, статус критичных изменений | Руководителю |
| Сервис | Как работает поддержка? | Инциденты по приоритетам, выполнение SLA, время реакции, просрочки, причины эскалаций | Руководителю и ответственному за IT |
| Инженерия | Почему это произошло и как проверить? | CPU, память, диски, журналы ошибок, очереди, сетевые потери, статусы backup-заданий | Инженеру |
Хороший отчет не прячет инженерные данные, но и не ставит их в центр управленческой части. Руководителю важно видеть вывод, динамику и решение. Инженерная детализация нужна как доказательная база и материал для диагностики.
Метрики, которые обычно нужны руководителю
Первая группа - доступность бизнес-сервисов. Не абстрактная доступность сервера, а состояние того, чем реально пользуются сотрудники: почта, 1С, файловый ресурс, CRM, интернет, VPN, телефония, видеонаблюдение, печать, рабочие места критичных ролей. Если сервер был включен, но пользователи не могли работать с сервисом, для бизнеса это инцидент.
Вторая группа - инциденты по влиянию. Руководителю полезно видеть не только количество заявок, а распределение по приоритетам: что останавливало работу, что затрагивало один отдел, что было обычной пользовательской просьбой. Так становится видно, не подменяется ли авария потоком мелких обращений.
Третья группа - повторяемость причин. Один сбой принтера может быть случайностью. Десять похожих обращений за месяц - уже повод менять процесс, оборудование, права, сеть или инструкцию. Повторяемость важнее сырого количества заявок.
Четвертая группа - состояние резервного копирования и восстановимости. Для руководителя недостаточно фразы "backup настроен". Нужны ответы: какие сервисы покрыты, когда была последняя успешная копия, когда проверяли восстановление, какие данные остаются вне защиты и какой риск принят осознанно.
Пятая группа - изменения инфраструктуры. В отчете должны быть видны значимые работы: что менялось, зачем, кто согласовал, как проверили результат, какие риски закрыты и какие остались. Это связывает IT с управлением изменениями, а не превращает поддержку в набор невидимых действий.
Что лучше оставить инженерам
Инженерные метрики не становятся бесполезными оттого, что они не нужны в первой части отчета. Загрузка CPU, свободная память, IOPS, latency, SMART-атрибуты, статусы служб, ошибки в логах и показатели сети нужны для диагностики. Но сами по себе они редко говорят руководителю, что делать.
Например, высокая загрузка процессора не всегда проблема: во время плановой обработки она может быть нормой. А низкая загрузка сервера не доказывает здоровье сервиса, если приложение зависло на ошибке базы или пользователи не проходят авторизацию. Поэтому инженерная телеметрия должна быть связана с сервисной картиной.
Практичный формат: в управленческой части оставить вывод и влияние, а в приложении или инженерном разделе - детали для проверки. Тогда отчет можно читать на двух скоростях: руководитель видит решения, инженер видит факты.
Вредные и vanity-метрики
Часть показателей выглядит убедительно, но плохо помогает управлять IT. Количество закрытых заявок без классификации может поощрять мелкую активность вместо устранения причин. Среднее время реакции может скрывать одну тяжелую просрочку по критичному сервису. Процент доступности без списка измеряемых сервисов превращается в декоративное число.
Еще одна опасная метрика - "все зеленое" без порогов и исключений. Если мониторинг не знает бизнес-календарь, регламентные работы и критичность сервисов, зеленый статус может означать только то, что техническая проверка ответила на ping. Это не равно готовности сервиса для пользователей.
Как собрать отчет без перегруза
Начинать лучше не с графиков, а со списка сервисов и решений, которые руководитель реально принимает. Для каждого сервиса стоит определить владельца, критичность, допустимый простой, признаки деградации и источник проверки. После этого метрики становятся не набором чисел, а способом подтвердить состояние сервиса.
- Для ключевых сервисов показывать статус, инциденты, причины и оставшиеся риски.
- Для поддержки показывать SLA, просрочки, эскалации и повторяемые обращения.
- Для backup показывать покрытие, последние успешные копии и доказательства тестов восстановления.
- Для изменений показывать цель, согласование, результат, откат и постпроверку.
- Для инженерии оставлять детализацию там, где она объясняет вывод или нужна для диагностики.
В IT-аутсорсинге такая структура отчета особенно важна: один ответственный подрядчик с командой должен показывать не объем суеты, а управляемость сервиса. Центральный смысл метрик - доказать, что поддержка видит риски, реагирует по согласованным правилам и предлагает понятные следующие действия.
Признаки хорошего набора метрик
Хороший набор метрик можно проверить простым вопросом: какое управленческое действие следует из этого показателя? Если действие непонятно, метрика может остаться в инженерной панели, но не должна занимать место в управленческом резюме.
Второй признак - проверяемость. Если в отчете написано "серьезных проблем нет", должны быть понятны границы: какие сервисы проверялись, за какой период, какие исключения были, какие события не входят в отчет. Без этого фраза превращается в обещание, которое нельзя подтвердить.
Третий признак - динамика. Разовый показатель полезен меньше, чем изменение за несколько периодов: стало ли меньше повторных обращений, закрыты ли причины инцидентов, сократилось ли число незапланированных работ, улучшается ли дисциплина backup и изменений.
Итог
Руководителю нужны метрики, которые показывают влияние IT на бизнес, качество сервиса, состояние рисков и необходимость решений. Инженеру нужны подробные технические сигналы, чтобы находить причины и подтверждать выводы. Когда эти уровни разделены, IT-отчет перестает быть набором графиков и становится инструментом управления.