Инцидентов стало в два раза больше. Время восстановления сократилось вдвое. Uptime сервисов держался в норме. По всем ключевым метрикам мы становились лучше. А обращения в саппорт росли, аккаунт-менеджеры передавали жалобы, и в клиентском чате всё чаще писали, что сервис нестабилен.

Эта статья о том, как метрики надёжности могут хором врать о клиентском опыте, почему установка «чините быстрее» — ловушка, которая сжигает дежурных инженеров и прячет настоящую причину проблем, и как мы развернули фокус с MTTR на MTBF, сократили количество инцидентов вдвое и вернули поток обращений клиентов к норме.

Как дашборды оказались зелёными, а клиенты — красными

Сначала два определения, чтобы дальше говорить на одном языке. MTTR (mean time to recovery) — среднее время восстановления, то есть как быстро чиним. MTBF (mean time between failures) — среднее время между отказами: как часто ломаемся.

У нас происходило вот что: частота инцидентов росла, то есть MTBF деградировал. Но команда, которая реагировала на инциденты и чинила их (SRE-команда), набирала скорость, и MTTR сократился вдвое. Перемножьте: суммарная недоступность почти не менялась, и uptime оставался в рамках целевых значений.

В этой арифметике спрятаны два обмана.

Первый: uptime видел не всё. Заметная часть инцидентов вообще не приводила к недоступности: деградация функций, ошибки в отдельных сценариях, замедления. Для метрики доступности их не существовало, хотя мы, разумеется, их видели и разбирали. А для пользователя они существовали ещё как.

Второй обман тоньше. Суммарное время недоступности — это не то, что переживает человек. Пользователь не складывает минуты простоя, он считает эпизоды. Один большой инцидент — это «у них была авария, починили». Десять мелких за тот же суммарный простой — это «у них постоянно что-то падает». Доверие разрушает не длительность, а частота: каждый эпизод — ещё один момент, когда сервис подвёл. Это хорошо ложится на пирамиду ценностей B2B-клиентов Bain («The B2B Elements of Value», Harvard Business Review, 2018): доступность сервиса, снижение рисков и снижение тревоги — самостоятельные элементы ценности для B2B-клиента. Частые сбои бьют ровно по ним, даже когда uptime формально в норме.

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

Ловушка «чините быстрее»

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

У этой логики есть невидимая цена, и платит её не тот, кто принимает решение.

Большую часть инцидентов генерировали продуктовые команды, и это нормально. Новый функционал — главный источник изменений, а большая часть отказов — их следствие. Но требования росли к тем, кто чинит, а не к командам, которые вносят изменения. Основная нагрузка пришлась на SRE-команду: каждый месяц больше инцидентов и низкое влияние на причину. К тушению по необходимости привлекались уже и остальные дежурные инженеры. SRE бежали всё быстрее вверх по эскалатору, едущему вниз, и начали выгорать. Не от сложности работы, а от её бессмысленности. Это был бег на месте: чинить быстрее то, что ломается чаще.

Здесь и зарыта разница между двумя метриками. MTTR — метрика чинящих, её улучшение целиком лежит на дежурных инженерах. MTBF — метрика вносящих изменения, ведь частоту отказов определяет то, как проектируется, тестируется и выкатывается новый функционал. Оптимизируя MTTR, организация направляет всё давление на тех, кто стоит в конце конвейера, и снимает его с тех, кто стоит в начале.

У ставки на MTTR есть и чисто статистическая проблема. Длительность инцидентов распределена с сильным перекосом: большинство решается быстро, но редкие длинные хвосты таскают среднее туда-сюда. В отчётах VOID, открытой базы с почти 10 тысячами публичных инцидентов от почти 600 компаний (отчет за 2024 год), из-за этой врождённой вариативности прямо предложено отказаться от MTTR как от метрики надёжности сложных систем. Там же показано, что длительность инцидента не коррелирует с его серьёзностью: долгий не значит страшный, короткий не значит безобидный. Штепан Давидович («Incident Metrics in SRE») проверил MTTR симуляциями Монте-Карло на реальных данных инцидентов и пришёл к выводу, который мы прочувствовали на себе: MTTR не различает «нам помогло улучшение» и «нам повезло с составом инцидентов». Случайный разброс инцидентов раскачивает среднее сильнее, чем реальные улучшения. Поэтому, даже честно ускорив восстановление, в следующем квартале вы вполне можете увидеть MTTR хуже прежнего. Мы гордились улучшением метрики, которая даже статистически не способна сказать правду о надёжности системы.

Отдельного разбора заслуживает фраза, которая часто звучала у нас в компании: fail fast в значении «быстро упал, быстро поднялся». Во многом отсюда и росло давление на MTTR. Ирония в том, что классический инженерный принцип fail fast (Джим Шор, IEEE Software, 2004) совсем о другом. Ошибка должна проявляться немедленно и заметно в месте возникновения, а не маскироваться и стрелять загадочным сбоем часы спустя. Так что настоящий fail fast помогает обеим метрикам: пойманные до прода баги — это реже ломаться, а быстро выявленная ошибка на проде — это ещё и быстрее чиниться. Трактовка «главное — быстро подняться» берёт из принципа только вторую половину. Заодно она искажает другую здоровую идею: культуру принятия сбоев (failures are inevitable, «сбои неизбежны»). Сбои действительно неизбежны, нулевой частоты не бывает, а гнаться за ней бесконечно дорого, на то и бюджет ошибок. Но «неизбежны» не значит «частота не важна, главное быстро чинить». Принимать сбои — инженерная зрелость. Прощать себе их частоту — индульгенция, цену которой платят дежурные инженеры и клиенты.

Как это было продано руководству

Переубедили не инженерные аргументы.

Сначала пришли клиентские службы, причём сами, без приглашения: инцидентов стало слишком много, с этим надо что-то делать. И это важный момент. Жалоба инженера на выгорание звучит как просьба о ресурсах, жалоба клиентских служб — как бизнес-риск. Затем коллега-руководитель принесла исследование Bain об элементах ценности B2B-клиентов, то самое, о котором выше: доступность сервиса и снижение рисков — вещи, которые формируют ценность для клиента, а частые сбои бьют именно по ним.

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

Продалось не сразу, но продалось: фокус сместился на MTBF. Скорость починки никто не откатывал, просто целью стало «ломаться реже», а не «чинить ещё быстрее».

Разворот: три механики

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

Задачи из инцидентов перестали растворяться. Всё, что порождали разборы (исправления, улучшения, недостающие проверки), мы стали считать отдельным потоком: свой учёт, свой дашборд, видно, как поток разгребается. До этого задачи из постмортемов честно записывались и тонули в бэклогах.

Классификация со сроками. Задачи из инцидентов получили классификацию, и для каждого типа задач — свой дедлайн, а не когда дойдут руки. Критичное закрывается за дни. И классификацию, и дедлайны согласовали со всеми, кого они касались: с CTO, CPO и PM. Это стало общим правилом компании, а не внутренним регламентом одной команды, и превратило выводы постмортемов из благих намерений в обязательства.

Что изменилось

Количество инцидентов сократилось вдвое. А следом схлынул и вал клиентских обращений, с которого всё началось: в саппорте, в клиентском чате, на встречах с аккаунт-менеджерами стало ощутимо тише.

SRE-команда перестала бежать на месте. Давление сместилось с «чините быстрее» на «ломаемся реже» и теперь направлено на тех, кто действительно влияет на частоту: на команды, которые вносят изменения, и менеджеров, которые планируют их работу. А сама идея, что за надёжность отвечают не только те, кто чинит, позже выросла в систему метрик «здоровья продукта» с целевыми значениями и заранее согласованными действиями. Об этом я подробно писал в статье «Сократили цикл разработки на 20% — и получили вдвое больше инцидентов».

Как понять, что вы в ловушке MTTR

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

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