Почему не достаточно MTTR и что такое MTBF?

Привет, %username%! Очень часто в работе с доступностью и надежностью систем фигурирует метрика Mean Time To Recovery (MTTR — среднее время восстановления после сбоя) как одна из ключевых. Если остановиться только на ней, то можно прийти к такой ситуации, когда у тебя MTTR достаточно низкий, например 5 минут, однако все равно все плохо и пользователи жалуются.

Чтобы вылезти из этой ситуации нужна еще одна метрика — Mean Time Between Failures (MTBF — среднее время, прошедшее между двумя инцидентами). Данная метрика отвечает на вопрос "как часто падает наш сервис?" Таким образом мы получаем следующую картину:

  • MTTR показывает как быстро мы восстанавливаемся;
  • MTBF показывает как часто мы падаем;

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

  • Низкий MTTR при низком MTBF будет означать, что вы быстро поднимаетесь, но падаете слишком часто — пользователи все равно страдают из-за частых сбоев;
  • Высокий MTBF при высоком MTTR означает, что падает редко, но уж если упали — болит долго, SLI пробивают все доступные SLO, накапливается техдолг и растут затраты на инциденты;

Комбинированный мониторинг метрик MTTR и MTBF помогает сразу по нескольким направлениям:

  • Корректно ставить приоритеты между профилактикой (повышать MTBF) или скоростью восстановления (снижать MTTR);
  • Оценивать реальное влияние на пользователей и бизнес, ведь как частые и короткие сбои могут быть сильно хуже, чем редкие и длинные, так и наоборот — увидеть это можно только в паре метрик;
  • Выявление системных проблем — рост MTTR при стабильном MTBF намекает на деградацию процессов эскалации или on-call, а падение MTBF при стабильном MTTR на деградацию качества релизов или инфраструктуры;
  • Формирование осмысленных SLO и Error Budgets, потому что баланс "как редко" и "как быстро" напрямую формирует допуски и ожидания;

MTTR и MTBF — вместе дают контроль: ты видишь, где "течь" — в стабильности или скорости реакции, и целенаправленно улучшаешь UX, не жертвуя надёжностью.

Делись опытом в комментариях — конкретные кейсы, грабли, метрики до/после. Как у тебя балансируется MTTR и MTBF – что первоочередное и почему? Какие практики или инструменты помогли оценить и повлиять на эти метрики – поднять MTBF или снизить MTTR?

#SRE #DevOps #Observability #incidents #ErrorBudget #Postmortem #OnCall #SiteReliabilityEngineering #Monitoring