MTTR Optimization

«MTTR за квартал снизился на двадцать процентов». Я регулярно вижу такую строку в отчётах и каждый раз задаю два вопроса: какое именно R имеется в виду и сколько было инцидентов. Чаще всего оказывается, что инцидентов набрался десяток, а всю разницу сделал один долгий, попавший в прошлый квартал. Снижение настоящее. Вывода из него никакого.

Этот лист про то, что стоит за аббревиатурой. Время инцидента складывается из отрезков: пока не заметили, пока не взяли в работу, пока не погасили влияние, пока не устранили причину. У каждого отрезка свой рычаг, и работать имеет смысл с отрезком, а не с суммой. Вторая половина листа про обращение с самими числами: что с ними можно делать и чего нельзя.

Границы с соседями. DORA Metrics считают время восстановления только после неудачной выкатки; здесь любой инцидент. Incident Response описывает, что делают люди во время инцидента, а этот лист — что в это время измеряется и что из измеренного следует. Без Severity Classification времена разных инцидентов вообще нельзя класть в одну выборку.

Что должен уметь

Главный навык на уровне L4 — поставить в хронологии инцидента четыре отметки и не спутать гашение с устранением. По моим наблюдениям, половина споров о том, «сколько длился инцидент», происходит от этой путаницы: один считает до момента, когда пользователям стало нормально, другой — до закрытия тикета через два дня.

Фиксирует в инциденте отметки времени: началось, обнаружили, взяли в работу, погасили влияние, устранили причину. Отдельно пишет, откуда узнали: из алерта или от пользователя.
В инциденте сначала гасит влияние, причину ищет после; не тратит время гашения на расследование.

Раскладывает длительность инцидента на отрезки, называет самый длинный и предлагает рычаг именно для него.
Смотрит на распределение, а не на среднее: медиана, хвост и число инцидентов в выборке указаны рядом с любым числом.
Сверяет начало инцидента с метриками, а не с моментом, когда его кто-то заметил.

Записывает определения: какое R в MTTR, от чего считается начало, что считается концом. Между периодами определения не меняются.
Смотрит на время вместе с частотой: быстрое восстановление при частых отказах пользователям не помогает.
Отказывается сравнивать периоды, когда инцидентов мало, и заменяет сравнение разбором каждого инцидента.
Выбирает вложение по отрезку: в алерты, в дежурство, в откат или в runbook, смотря где теряется время.

L6+

Не даёт времени восстановления стать показателем работы команды: число, за которое спрашивают, начинают подправлять определением конца инцидента.
Связывает время гашения с архитектурой: откат одной командой, флаги, изоляция отказа дают больше, чем любая тренировка дежурных.
Показывает руководству распределение и долю инцидентов, найденных не мониторингом, вместо одного среднего.

Материалы

Статьи и доклады

Štěpán Davidovič — Incident Metrics in SRE (Google). Обязательно прочитать до того, как строить отчёт на средних. Автор моделирует инциденты методом Монте-Карло и показывает, что MTTR и его родственники плохо годятся для решений и для анализа трендов.
John Allspaw — Moving Past Shallow Incident Data (Adaptive Capacity Labs, 2018). Лучшее из известных мне возражений против самой идеи: два инцидента одной длины могут не иметь между собой ничего общего. Читать как противовес этому листу.
DORA — A history of DORA’s software delivery metrics. Короткая история того, как время восстановления в модели DORA в 2023 году переименовали и сузили до отказов после выкатки. Советую показать тем, кто до сих пор называет общий MTTR метрикой DORA. Причина там названа прямо: прежнее определение не отличало отказ от изменения и отказ от внешней причины.
Atlassian — MTBF, MTTR, MTTA, MTTF. Справочная страница с определениями. Рекомендую ради одной оговорки: у буквы R в MTTR четыре расшифровки, и команде стоит договориться, какая её.
Мой разбор — Почему не достаточно MTTR и что такое MTBF? (Telegram, ноябрь 2025). Короткий пост про пару «как быстро поднимаемся» и «как часто падаем». Писал его потому, что, по моим наблюдениям, время восстановления чаще всего показывают без частоты, и картина выходит лучше настоящей.
Cloudflare — Post mortem on the Cloudflare Control Plane and Analytics Outage (2023). Хронология с точными отметками; на ней удобно показать, почему у одного инцидента несколько длительностей.

Инструменты

Платформа управления инцидентами — incident.io, FireHydrant, Rootly. Отметки времени ставятся сами, из алерта и из чата. По моим наблюдениям, автоматические отметки честнее ручных с одной оговоркой: началом инцидента у них служит момент алерта, а не момент отказа.
Таблица инцидентов — markdown или электронная таблица с пятью столбцами времени. Если команда видит несколько инцидентов в месяц, этого хватает, и отдельная платформа будет избыточной.
Гистограмма длительностей — по отрезкам и по классам критичности. Имеет смысл, когда инцидентов набралось хотя бы несколько десятков; на меньшей выборке она рисует шум.

Best practices

У Cloudflare 2 ноября 2023 года обесточилась основная площадка. Инцидент начался в 11:43 UTC. К 17:57 большая часть панели управления работала с резервной площадки. Полностью сервисы восстановили 4 ноября в 04:25. Сколько длился инцидент? Шесть часов с четвертью, если считать до гашения. Больше сорока часов, если считать до конца. Оба ответа верны и отличаются в шесть с лишним раз. Ровно об этом оговорка у Atlassian: буква R означает то repair, то recovery, то respond, то resolve, и пока команда не выбрала одно, её среднее складывает разные вещи.

Среднее подводит и по другой причине. Štěpán Davidovič из Google смоделировал поток инцидентов методом Монте-Карло и пришёл к выводу, который вынесен в аннотацию отчёта: такие статистики плохо годятся для принятия решений и анализа трендов. Объяснение на пальцах простое. Инцидентов у одной команды мало, а разброс длительностей велик, поэтому один долгий инцидент двигает среднее сильнее, чем любое улучшение процесса. Строку из начала листа, про двадцать процентов, почти всегда пишет этот один инцидент.

Отрезки вместо одного числа. Полезнее всего разложить время и посмотреть, где оно теряется. Долго не замечали — вопрос к алертам, и за ним в SLI-based Alerting. Заметили, но долго не брали в работу — вопрос к дежурству и к шуму, это On-Call Rotation и Alert Fatigue Management. Взяли, но долго гасили — вопрос к откату, флагам и runbook. Погасили, а причина жива месяц — это уже Problem Tracking. Рычаги разные, владельцы разные, и общий лозунг «снизить MTTR» не подсказывает ни одного.

Сначала гасим, потом ищем причину. Правило старое и нарушается каждый раз, когда инженеру интересно. Расследование в разгар инцидента растягивает именно тот отрезок, который видят пользователи. Я считаю время гашения единственным из четырёх, которое стоит защищать любой ценой: остальные три можно разбирать спокойно, это нельзя.

Время без частоты врёт. Сервис может восстанавливаться за пять минут, и пользователи всё равно будут жаловаться, если падает он несколько раз в неделю. Быстрый возврат при частых отказах означает, что команда хорошо научилась чинить одно и то же. Поэтому рядом со временем я всегда держу число инцидентов за тот же период, и смотрю на пару, а не на каждое по отдельности.

Начало инцидента — когда сломалось, а не когда заметили. Если отсчёт идёт от алерта, время обнаружения по определению равно нулю, и самый дорогой отрезок исчезает из отчёта. Начало стоит восстанавливать по метрикам уже после инцидента. Заодно появляется число, которое я считаю полезнее любого среднего: доля инцидентов, о которых узнали от пользователей, а не от мониторинга.

И возражение, с которым я не до конца согласен, но которое стоит держать в голове. John Allspaw называет такие данные поверхностными: два инцидента по 54 минуты могут отличаться всем, от степени неожиданности до риска каждого действия. Он прав в том, что числа не заменяют разбора. Мне кажется, что отрезки всё же полезны как указатель, какой разбор читать первым.

У всей этой арифметики есть пределы. Она не работает, когда инцидентов мало: при десятке в год любые тренды случайны, и честнее разобрать каждый инцидент, чем считать по ним статистику. Она ломается, когда время восстановления попадает в цели команды: инциденты начинают закрывать раньше, а открывать позже. И она бесполезна для сравнения команд, потому что у сервисов разная критичность и разный поток изменений.

Связанные листья

Incident Response — роли и порядок действий в инциденте; хронология, которую там ведут, и есть сырьё для этого листа.
Severity Classification — без классов критичности в одну выборку попадают минутная деградация и суточный отказ.
SLI-based Alerting — главный рычаг времени обнаружения.
On-Call Rotation — от устройства дежурства зависит время до взятия в работу.
Runbooks и Progressive Delivery — два рычага времени гашения: готовая процедура и быстрый откат.
DORA Metrics — время восстановления после неудачной выкатки как одна из метрик поставки; определение там уже этого листа.
Problem Tracking — что происходит с причиной после того, как влияние погашено.
Blameless Postmortem — разбор, который числа не заменяют.

Открытые вопросы

Какой выборки достаточно, я не знаю. Отчёт Google показывает, что на малом числе инцидентов сравнение периодов ненадёжно, но готового порога «от стольких-то инцидентов можно» я оттуда не вынес. Своё «несколько десятков» я считаю догадкой.

Рядом лежит момент начала. Восстановить его по метрикам удаётся, когда отказ резкий. Медленная деградация начала не имеет: задержка росла неделю, и любая отметка будет произвольной. Как считать время обнаружения для таких инцидентов, мне неясно.

И вопрос к названию практики. Чем заменить одно число в отчёте для руководства, я хорошего ответа не видел. Распределение честнее, но читают его хуже. Если у вас есть форма, которую понимают без пояснений, расскажите через PR.