MTTx — это не панацея: как измерять качество инцидент-менеджмента

Метрики времени — MTTR, MTTA и другие — давно стали стандартом для оценки инцидент-менеджмента. Но что, если они не отражают реального качества процессов?

Проблема MTTx: скорость ≠ качество

Низкий MTTR может скрывать хаос: команда быстро «закрывает» инцидент, но игнорирует коренные причины. Например:

• Кейс: команда сократила MTTR на 30%, но 40% инцидентов стали повторяться из-за поверхностного анализа.
• Почему? MTTR не учитывает, как решалась проблема: были ли частые обновления, кто руководил процессом, как распределялась нагрузка.

Какие метрики стоит добавить?

1. Время мобилизации
   • Что измеряет: Сколько проходит от первого алерта до активных действий.
   • Пример: В одной из команд ночное время мобилизации было 45 минут (против 5 днём). Решение: внедрили автоматическую эскалацию на второго дежурного через 10 минут без ответа.
2. Время назначения ответственного
   • Что измеряет: Как быстро появляется лидер инцидента.
   • Пример: FinTech-стартап сократил задержку с 20 до 3 минут, добавив бота, который назначает лидера на основе ротации.
3. Частота обновлений
   • Что измеряет: Сколько сообщений публикуется за время инцидента.
   • Пример: Команда DevOps внедрила шаблоны для обновлений (например, «Статус: анализ логов, ETA 15 мин»). Частота выросла в 2x, снизив количество параллельных вопросов от стейкхолдеров.
4. Инциденты вне рабочего времени
   • Что измеряет: Сколько алертов приходит ночью или в выходные.
   • Пример: SaaS-компания обнаружила, что 60% инцидентов срабатывают после 22:00. После настройки фильтров для ложных срабатываний их доля упала до 15%.

Как внедрить это на практике?

• Шаг 1: начните с дашборда. Соберите данные по новым метрикам в одном месте. Например, Grafana + кастомные скрипты для отслеживания времени мобилизации.
• Шаг 2: автоматизируйте рутину. Используйте ботов для:
  • назначения лидера (например, Opsgenie + Jira);
  • напоминаний об обновлениях («Прошло 30 минут — пора сообщить прогресс»).
• Шаг 3: анализируйте паттерны. Если 70% инцидентов начинаются после деплоя — усильте тестирование. Если ночные алерты преобладают — пересмотрите пороги срабатывания.

Итог: метрики должны работать на команду

MTTx полезны, но они лишь часть картины. Добавьте метрики качества, чтобы:

• Снизить нагрузку на команду,
• Улучшить коммуникацию,
• Предотвращать инциденты, а не тушить их.

Главное: перестаньте измерять только скорость. Начните измерять то, что делает ваши процессы устойчивыми и человекоориентированными.