Сообщить об ошибкеКороткий ответ
Явного единственно верного KPI тут не существует: количество обработанных инцидентов как метрика мотивации создаёт искажённые стимулы (может поощрять частые, но несущественные инциденты или наоборот скрытие/недооценку severity, чтобы не "портить" метрику) — нужно обсуждать, какое поведение команда на самом деле хочет поощрять, и выбирать метрики, устойчивые к манипуляции, в сочетании с качественной оценкой (постмортемы, обратная связь).
Как это работает подробнее
любая метрика, напрямую влияющая на деньги сотрудника, подвергается эффекту Goodhart's law — люди начинают оптимизировать саму метрику, а не то, что она должна отражать; "количество обработанных инцидентов" можно искусственно завысить (дробить один инцидент на несколько тикетов) или, наоборот, у инженера может появиться стимул занижать severity, чтобы не создавать formal incident record, если именно их количество бьёт по премии негативно в других метриках KPI.
Компромисс: нужно явно обсудить с заинтересованными сторонами, какое поведение хотят получить (быстрое реагирование? снижение числа инцидентов в будущем? качество постмортемов?), и подобрать метрики и форму признания/мотивации, устойчивые к манипуляции именно для этой цели — единого готового рецепта премирования on-call, который работает для любой команды и культуры, не существует.
Пример / кейс
Ожидаемое поведение: команда и руководство должны явно проговорить потенциальные искажения стимулов до введения метрики и выбрать вариант, который в данной культуре организации с наименьшей вероятностью приведёт к манипуляции или сокрытию инцидентов.
Пример кода
Предложенная метрика: премия = f(количество закрытых инцидентов за месяц).
Риск: инженер А разбивает один сложный инцидент на 4 отдельных тикета → получает больше премии,
чем инженер Б, который предотвратил повторение похожего инцидента превентивным фиксом
и за месяц у него 0 новых инцидентов по этой теме.
Альтернатива для обсуждения: командная премия, привязанная к соблюдению SLO за квартал
+ качественная оценка постмортемов, без индивидуального счёта "обработанных тикетов".Что использовать на практике
- Практический подход. Более устойчивые к манипуляции подходы — оценивать качество реагирования (своевременность, соответствие runbook, качество постмортема) через peer review, а не через чистое количество; или не привязывать индивидуальные премии к инцидентам вовсе, а признавать вклад on-call через нематериальные механизмы (компенсация времени, признание в команде) и фокусировать материальную мотивацию на долгосрочных командных метриках надёжности (соблюдение SLO, снижение повторяющихся инцидентов), которые отражают системное качество, а не личную "производительность" в тушении пожаров.
Подводные камни
- Частые ошибки. Вводить метрику "количество инцидентов" без учёта, что это поощряет реактивное тушение пожаров вместо превентивной работы (устранение причин повторяющихся инцидентов, которая снижает число будущих инцидентов и, по этой метрике, парадоксально снижает премию); связывать индивидуальные (не командные) премии с метриками надёжности, что провоцирует сокрытие проблем вместо blameless-культуры постмортемов; не обсуждать с самой командой дежурных, какие стимулы метрика создаёт на практике, прежде чем внедрять.