Надёжность строится в диалоге с бизнесом

Привет, %username%! В прошлой статье — «SLO как чертёж архитектуры» — я закончил тезисом, который тут же хочется развить: SLO выбирается не инженерами в одиночку, а вместе с бизнесом, потому что число в нём привязано к деньгам. А «вместе с бизнесом» в реальности чаще всего выглядит так: SRE придумал SLO, нарисовал дашборд, показал на демо, продакт покивал — и все разошлись. Чертёж готов. Надёжность… не выросла.

Так бывает, потому что чертёж сам по себе не работает. SLO/SLI/error budget — это не отчётный артефакт, а язык переговоров. Технический инструмент превращается в управленческий ровно в тот момент, когда у инженеров и у бизнеса одна и та же картинка целевой надёжности и одна и та же валюта компромиссов. Пока этого нет — у тебя есть красивый график, который никто не использует для принятия решений.

В этой статье я разворачиваю три практических следствия из этого тезиса, и все три — продолжение того же кейса с маркетплейсом (поиск каталога, 50M товаров, 30k RPS на пике), который я гонял в «чертеже»:

1. Диалог с бизнесом — это не презентация SLO, а формат принятия решений. SRE не «продаёт» таргет продакту, а вместе с ним выбирает уровень надёжности, политику бюджета ошибок и порядок разрешения спора «фичи против надёжности».
2. System Design-собес проверяет именно этот навык. Большинство «вопросов по SLO» — не про арифметику девяток, а про умение собрать разговор с бизнесом, удержать рамку трейд-оффов и перевести «бизнес хочет 100%» в инженерную работу.
3. Метрики SRE-команды меняются, когда продуктов больше одного. Ни «MTTR по компании», ни «SLO по сервису» как метрика команды не работают, когда команда обслуживает 5–10 продуктов. Нужен сводный язык.

Если первая статья была про то, какой чертёж рисовать, то эта — про то, как сделать так, чтобы по чертежу действительно построили, а не повесили его в рамке на стену.

Что ты унесёшь из статьи#

Статья длинная (~40 000 знаков). Сразу — что заберёт каждая роль:

• SRE / SRE-lead. Как перестать «отдавать SLO» и начать вести по нему диалог: три признака, что разговор не состоялся; error budget policy как продуктовый, а не инженерный артефакт; и — отдельным блоком — какие метрики брать на команду, когда продуктов много, чтобы они не врали.
• Продакт / аналитик. Что именно бизнес должен уметь произнести сам (а не получать от SRE как откровение): где у нас критичные пользовательские пути, сколько стоит девятка в деньгах, кто и когда жмёт на стоп.
• Кандидат / интервьюер на System Design. Пять типовых собес-кейсов «про SLO», которые на самом деле проверяют переговорный навык, и разбор, что в них считается сильным ответом, а что — провалом.

Общий блок для всех: почему надёжность нельзя «сделать», её можно только постоянно переторговывать — и как выглядит этот процесс в зрелой команде.

TL;DR (если читать дальше уже некогда)#

Четыре тезиса, к которым приходит статья:

1. SLO без error budget policy — это украшение дашборда. Контракт из SLO делает записанное правило: что происходит, когда бюджет сгорел, и кто принимает по этому поводу решение. Само число ничего не гарантирует. Без правила — это график, мимо которого все ходят.
2. Надёжность — это не состояние, а переговорный процесс. Её не «достигают» один раз. Каждый квартал бизнес и SRE заново выбирают уровень, потому что меняются нагрузка, деньги и приоритеты. SLO, который не пересматривают, врёт уже через полгода.
3. На собесе по SLO проверяют не формулы, а умение поменять поведение бизнеса. Сильный ответ всегда начинается со сценария и денег, а не с топологии и девяток. «100% доступности» — не повод сказать «нельзя», а повод показать цену.
4. Метрики SRE-команды при мультипродукте раскладываются на три слоя (надёжность продуктов / инженерное усилие / качество диалога) — один агрегат тут не справляется. Среднее по больнице — MTTR, composite SLO, число инцидентов — прячет ровно то, ради чего метрику заводили.

Дальше — как до этого дойти. Если интересует только управленческая кульминация — переходи сразу к разделу Метрики SRE-команды для мультипродукта .

Чертёж без переговоров — это просто дашборд#

Начнём с диагноза. В прошлой статье SLO получился как инженерный объект: числитель, знаменатель, окно, бюджет ошибок. Всё аккуратно. Но у этого объекта есть два режима существования, и разница между ними — это и есть вся статья.

SLO как артефакт против SLO как контракта#

SLO-артефакт — это число на дашборде. Его придумали, согласовали галочкой, поставили мониторинг, иногда даже сделали красивый burn-rate-график. Он существует. Он измеряется. И он ни на что не влияет, потому что ни одно решение в компании не принимается, глядя на него.

SLO-контракт — это то же число, но вокруг него выстроен процесс. Когда бюджет ошибок тает быстрее плана — кто-то останавливает рискованные деплои. Когда бюджет сгорел — спринт переключается на надёжность, и это не подвиг отдельного SRE, а записанное правило. Когда продакт хочет выкатить фичу к Чёрной пятнице — он сам спрашивает «сколько у нас осталось бюджета», потому что знает, что это его валюта тоже.

Разница видна по тому, как объект ведёт себя в жизни команды:

	SLO-артефакт	SLO-контракт
Где живёт	На дашборде	В процессе принятия решений
Кто смотрит	Дежурный SRE	Продакт и SRE вместе
Что происходит при сгорании	Ничего («ну красный»)	Срабатывает записанное правило
Кто «владелец» числа	Инженеры	Продуктовый владелец + SRE
Роль в споре «фича vs надёжность»	Никакой	Валюта, в которой спор решается
Пересмотр	Когда вспомнят	Раз в квартал, ритуалом

Разница между ними — не в качестве дашборда. Она в том, встроен ли SLO в принятие решений. И встроить его туда нельзя в одностороннем порядке: SRE не может «назначить» бизнесу, что теперь решения принимаются по бюджету ошибок. Это можно только договорить.

Три признака, что разговор не состоялся#

Проверить, в каком режиме у тебя SLO, можно по трём симптомам. Если узнаёшь хотя бы один — диалога не было, был монолог SRE.

1. SLO «спущен сверху». Инженеры посчитали девятки, выбрали таргет «по аналогии с большими» и поставили продакта перед фактом. Продакт не участвовал в выборе числа — значит, он не считает его своим и не будет на него опираться в спорах. Для него это «инженерная штука», а не общий контракт.
2. Нет error budget policy. SLO есть, бюджет считается, дашборд горит то зелёным, то красным. Но что конкретно делать, когда бюджет на исходе — нигде не записано. В итоге красный дашборд не меняет ничего: «ну красный, ну ладно, катим дальше».
3. На пересечении бюджета никто не останавливает фичи. Самый жёсткий признак. Бюджет сгорел в ноль, а релизы продолжают выкатываться, потому что «дедлайн важнее». Это значит, что SLO проигрывает любому продуктовому приоритету — то есть фактически его нет.

Все три признака — про одно: SLO не имеет оперативных последствий. А инструмент без последствий — это декорация.

Кейс Mercari: переименовать мало, нужен ритуал#

Хороший пример того, как легко перепутать артефакт с контрактом, — переход к User Journey SLO. Команды (в том числе Mercari, описавшие это в посте «Keeping User Journey SLOs Up-to-Date with E2E Testing» в декабре 2024 года) приходят к тому, что SLO «на сервис» прячет пользовательскую боль, и переезжают на SLO, привязанные к пользовательскому пути. Идея правильная — она ровно из «чертежа»: SLI вешаются на шаги критичного пути, а не на сервис целиком.

Но вот ловушка: само по себе переименование «SLO сервиса X» → «SLO пользовательского пути Y» ничего не меняет, если за ним не стоит сопровождающий ритуал с продактом. Если User Journey SLO живёт там же, где жил старый — на дашборде, который смотрит только дежурный SRE, — это просто более точный артефакт. Та же декорация, только лучше нарисованная.

Работает переход тогда, когда вместе с новым SLO появляется регулярная встреча, на которой продакт смотрит на бюджет своего пути и принимает по нему решения. Не SRE показывает — продакт смотрит и решает. Переименование — это 10% работы. Остальные 90% — встроить новый объект в процесс продукта.

Почему без продуктового владельца это не лечится#

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

SRE владеет технической доступностью — это его зона: инфраструктура, репликация, failover, capacity. Но «работает ли поиск для пользователя так, что он покупает» — это вопрос, на который SRE физически не может ответить в одиночку, потому что «так, что он покупает» — это продуктовое определение, а не техническое. Кто решает, что пустая выдача по валидному запросу — это провал, а не «технически 200 OK»? Продакт. Кто решает, что цена на карточке старше минуты — это инцидент? Продакт.

Поэтому у продуктовой надёжности должен быть продуктовый владелец. Не «SRE отвечает за надёжность» — это и есть корень всех проблем из предыдущего раздела. А «SRE отвечает за инструментарий и техническую доступность, продакт — за то, что считается надёжностью с точки зрения пользователя, и они держат общий SLO». Диалог не состоится, пока с продуктовой стороны нет того, кто за этот SLO отвечает головой.

Что мы на самом деле обсуждаем с бизнесом#

Допустим, продуктовый владелец есть и готов разговаривать. О чём конкретно идёт разговор? Не «покажи мне дашборд» — это не разговор. Настоящий диалог о надёжности крутится вокруг четырёх вещей.

1. Таргет как бюджет на компромисс#

Главное, что должен понять бизнес: высокая надёжность — это не бесплатно и не всегда хорошо. Это позиция на шкале трейд-оффов.

• Высокий SLO = низкая скорость фич (бюджет ошибок мал, каждый релиз — ставка), дорогая инфраструктура (резервирование, регионы), медленные релизы (канарейка, постепенный rollout).
• Низкий SLO = быстрые фичи, дешёвая инфраструктура, но больше видимых пользователю сбоев.

Из «чертежа» помним конкретные множители для нашего маркетплейса: переход с 99.9% на 99.99% — это 4–6× → 15–25× baseline по инфраструктуре и 2–3× → 8–10× по людям. Это не «инженеры хотят красивую цифру». Это бизнес-решение, потому что платит за него бизнес, и отказывается от скорости фич — тоже бизнес.

Ключевая фраза, которую SRE должен уметь произнести в этом разговоре, звучит примерно так:

«Если снизим SLO поиска с 99.99% до 99.9% — освободим вот этот регион и вот эту часть дежурной нагрузки, сможем катить фичи в полтора раза быстрее. Заплатим за это вот таким ростом видимых сбоев на пике. Берём?»

Это и есть перевод надёжности в валюту, понятную обеим сторонам. Не «давайте сделаем понадёжнее», а «вот цена, вот что освобождается, решаем вместе».

2. Error budget policy: правила пишутся до пожара, а не во время#

Error budget policy — это заранее зафиксированные правила игры. Не «что мы будем делать, когда бюджет сгорит» (это решается в панике и проигрывается дедлайну), а «что происходит автоматически, когда бюджет сгорел» — написанное и согласованное обеими сторонами заранее.

Минимальная политика отвечает на четыре вопроса:

• Кто и при каком условии останавливает релизы? Например: при burn-rate выше 14.4× за час — автоматический freeze рискованных деплоев до конца окна.
• Кто разрешает продолжить? Не «инженер решил» и не «продакт продавил», а названная роль с названным условием.
• Что переходит в roadmap при сгоревшем бюджете? Reliability-задачи получают приоритет над фичами — и это записано, а не выпрашивается каждый раз заново.
• Когда и как пересматривается сам SLO? Раз в квартал — короткий ритуал «изменилось ли что-то в бизнесе или системе, что меняет нужное число».

На практике это умещается на одну страницу — по образцу error budget policy из главы «Implementing SLOs» в Google SRE Workbook. Для поиска нашего маркетплейса политика могла бы выглядеть так:

Error budget policy — поиск каталога (SLO 99.9%, окно 30 дней)

• Жёлтая зона (потрачено 50% бюджета): уведомление в канал продукта, ретроспектива на ближайшем синке, новых рискованных экспериментов не начинаем.
• Красная зона (потрачено 90%): freeze рискованных деплоев — катим только хотфиксы и security-патчи. Reliability-задачи поднимаются над фичами в текущем спринте.
• Бюджет исчерпан (100%): полный freeze фич до конца окна. Эскалация продуктовому владельцу, обязательный разбор причин.
• Кто снимает freeze: продуктовый владелец по согласованию с SRE-lead, не раньше чем burn-rate вернулся к норме.
• Пересмотр SLO: первый понедельник квартала, участвуют продакт и SRE-lead.
• Подписали: имя продуктового владельца, имя SRE-lead, дата.

Эта страница важнее любого дашборда. Дашборд показывает, что бюджет горит. Страница говорит, что с этим делать и кто за это отвечает.

Важнейшее уточнение, которое часто упускают: error budget policy — это продуктовый артефакт, а не инженерный. Его подписывает не тимлид SRE «для себя», а продуктовый владелец — потому что это он соглашается, что при сгоревшем бюджете его фичи подождут. Подпись здесь не метафора: должно быть понятно, кто конкретно сказал «да» этим правилам. Если не можешь назвать имя — политики нет.

3. Перевод девяток в деньги#

Бизнесу нужны не проценты, а валюта. «99.9% против 99.95%» для продакта — пустой звук, пока ты не показал, что стоит за этой разницей в деньгах. Поэтому в зрелом диалоге всегда есть связка SLI → ₽.

Берём наш маркетплейс. Из «чертежа»: GMV порядка 1 млрд ₽ в день, поиск кормит 40–70% покупок, каждые +100 ms латентности на ключевом read path стоят примерно −0.5…1.5% конверсии. Отсюда — простой мост:

$$ \text{Стоимость простоя} = \text{GMV в час} \times \text{доля задетого трафика} \times \text{длительность} $$

Дальше бюджет ошибок перестаёт быть процентом и становится деньгами. Сгоревший за инцидент бюджет — это не «−2% за час на графике», а «вот столько недополученной выручки, если такой инцидент повторится на пике». Burn-rate из множителя (14.4×, 36× — подробно про него в статье «Скорость сгорания бюджета ошибок» ) превращается в скорость утечки денег: при таком-то burn-rate на пике Чёрной пятницы мы теряем столько-то рублей в минуту.

Посчитаем на пальцах для одного и того же 15-минутного инцидента в поиске — полная недоступность пути. GMV 1 млрд ₽ в день размазан неравномерно: обычным днём через поиск проходит порядка 400 млн ₽ выручки (предположим, 40% покупок стартуют с поиска), на пике распродажи дневной GMV умножается в ×3–5, и доля стартующих с поиска покупок растёт.

	Обычный вторник	Пик распродажи
Выручка через поиск за день	~400 млн ₽	~1,5 млрд ₽
Выручка через поиск в час (грубо)	~17 млн ₽	~120 млн ₽
Полный простой поиска 15 минут	~4,2 млн ₽	~30 млн ₽
Тот же burn-rate в долях бюджета	один и тот же ~50×	один и тот же ~50×

Цифры грубые и зависят от профиля трафика — но порядок и так говорит главное: один и тот же инцидент с одним и тем же burn-rate стоит на пике в разы дороже. Поэтому «потеряли 15 минут» — бессмысленная фраза без контекста «когда». А burn-rate как безразмерный множитель тут особенно удобен: 50× одинаково тревожен и во вторник, и в Чёрную пятницу, просто в деньгах разворачивается по-разному.

Это разговор, который продакт понимает мгновенно. Не «у нас burn-rate 14.4», а «при текущем burn-rate мы за час пикового трафика теряем выручку, равную недельной зарплате команды — продолжаем катить?». Конвертация в деньги и переводит SLO из инженерной плоскости в управленческую.

4. «Где у нас критичные пользовательские пути»#

И последнее, самое неочевидное. Список критичных пользовательских путей (CUJ — critical user journey) бизнес должен уметь произнести сам. Это не то, что SRE приносит продакту как откровение — «смотри, я тут проанализировал, у вас критичен поиск». Если CUJ известны только инженерам, значит, бизнес не владеет собственной надёжностью.

Хорошая проверка зрелости диалога: спроси продакта «назови три сценария, простой которых на 30 минут стоит нам больше всего». Если он отвечает не задумываясь — диалог здоровый. Если лезет к SRE «а какие у нас там пути» — надёжность пока живёт в инженерной резервации.

Для нашего маркетплейса CUJ — это путь «пришёл с намерением купить → нашёл → выбрал → положил в корзину → оплатил». И продакт должен понимать, что поиск (вход в этот путь) и оплата (выход) — разного класса критичности, и что на них вешаются разные SLO. Это понимание — не бонус, это условие, без которого все предыдущие три пункта повисают в воздухе.

Диалог — это цикл, а не презентация#

Сложим четыре пункта вместе. Диалог о надёжности — это не разовое «защитили SLO на демо», а повторяющийся цикл:

Каждый виток — это квартал. На входе бизнес приносит «что и сколько стоит», на выходе получает «вот сколько надёжности мы дали и какой ценой». Если хоть одно звено разорвано — цикл рассыпается, и SLO откатывается в режим артефакта. Именно эту целостность и проверяют на собесе — к нему и переходим.

Кейсы с System Design-собеса#

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

Кейс 1. «Зачем тебе SLO 99.9, а не 99.99?»#

Что проверяют: умеет ли кандидат держать рамку «бюджет → архитектура → деньги».

Провальный ответ: начать с топологии. «Ну, 99.99 — это active-active в трёх регионах, а 99.9 — один регион с failover между AZ». Технически верно, но это ответ на вопрос «чем отличаются архитектуры», а не «зачем тебе эта надёжность».

Сильный ответ всегда начинается со сценария бизнеса:

«Зависит от того, какой это путь. Если это поиск каталога — главный драйвер конверсии — то считаем: на 99.9% бюджет даунтайма на пике ~14 минут в месяц, на 99.99% — полторы минуты. Разница в архитектуре — лишних 15–25× против 4–6× baseline. Вопрос к бизнесу: эти 12 минут в месяц на пике стоят нам больше или меньше, чем утроение инфраструктуры? Если GMV такой, что минута пикового даунтайма — сотни тысяч, берём 99.99. Если нет — 99.9 с запасом».

Ключевое: кандидат не выбирает девятку сам. Он показывает, что выбор девятки — это разговор с бизнесом, и приносит в этот разговор обе цифры — цену надёжности и цену её отсутствия.

Кейс 2. «У вас 99.95 по чекауту, но 30% оплат не проходит — что не так?»#

Что проверяют: понимает ли кандидат разрыв между технической доступностью и продуктовой надёжностью.

Это мой любимый кейс, потому что он ловит самую частую ошибку. Дашборд зелёный — 99.95% по эндпоинту оплаты. А бизнес кричит, что треть оплат не доходит. Противоречие? Нет. SLI повешен не туда.

Что произошло: SLI считает «доля ответов 2xx от ручки /pay». Ручка честно отвечает 200 OK — она приняла запрос. А дальше платёж уходит в провайдера, провайдер таймаутит, ретрай не настроен, и для пользователя оплата «не прошла» — но для SLI всё прекрасно, ручка-то ответила.

Сильный ответ:

«SLI измеряет здоровье ручки, а не сценарий. Его надо переповесить на пользовательский результат: „доля начатых оплат, завершившихся подтверждённым списанием за < N секунд“. Тогда таймауты провайдера, потерянные колбэки и зависшие платежи попадут в знаменатель, и 99.95% превратятся в честные 70%. Дашборд начнёт показывать ту же боль, что чувствует бизнес».

Это ровно разведение «продуктовая надёжность против технической доступности». Кандидат, который видит этот разрыв, понимает, что SLI вешается на сценарий, а не на success rate ручки. Кандидат, который не видит, будет до утра чинить инфраструктуру, которая и так зелёная.

Кейс 3. «Бизнес требует 100% доступности. Что отвечаешь?»#

Что проверяют: переговорный навык в чистом виде.

Провальный ответ: «100% невозможно». Технически правда, но это ответ инженера, который закрывает разговор, а не ведёт его. Бизнес услышит «не хочу» и пойдёт давить.

Сильный ответ — не «нельзя», а цена:

«Окей, давай посчитаем, что такое 100%. Каждая девятка после 99.9 удорожает систему примерно в разы. 99.99 — это уже 15–25× baseline и заморозка скорости релизов. 99.999 — это multi-cloud, независимые DNS, частично независимые кодовые базы, подходы из telecom. А 100% — это бесконечность: ноль допустимых сбоев означает ноль деплоев, ноль экспериментов, ноль изменений. Мы перестанем выпускать фичи вообще. Точно нужны эти девятки — или нам нужно, чтобы конкретный сценарий, скажем оплата, не падал заметно для пользователя? Это разные задачи, и вторая решается сильно дешевле».

Кандидат переводит абсолютное требование в трейд-офф и возвращает бизнесу выбор. Часто за «хотим 100%» стоит «не хотим терять оплаты в пик» — а это не про 100%, это про правильный SLO на правильный путь плюс graceful degradation.

Кейс 4. «Кто принимает решение о фризе релизов при сгорании бюджета?»#

Что проверяют: есть ли у кандидата error budget policy в голове и понимает ли он, что это продуктовый артефакт.

Провальный ответ: «SRE решает» или «тимлид решает». Это инженерный ответ, и он выдаёт, что у кандидата SLO живёт в инженерной резервации.

Сильный ответ:

«Решает не человек в моменте, а записанная заранее error budget policy. В ней зафиксировано: при таком-то burn-rate за такое-то окно — автоматический freeze рискованных деплоев. И подписана эта политика продуктовым владельцем, потому что это он соглашается, что его фичи подождут. Если решение каждый раз принимается заново и под давлением — значит, политики нет, и побеждает тот, кто громче».

Здесь проверяют понимание, что фриз — это не власть SRE над продуктом, а заранее согласованное обеими сторонами правило. Кандидат, который это понимает, не будет воевать с продактом — он сошлётся на то, что они вместе подписали.

Кейс 5. «Покажи, как сожжённый бюджет влияет на дорожную карту»#

Что проверяют: встроен ли SRE в плановый цикл или живёт в параллельной вселенной с продуктом.

Провальный ответ: «при сгорании бюджета мы делаем post-mortem». Post-mortem — это хорошо, но это про прошлое. Вопрос — про будущее, про roadmap.

Сильный ответ:

«Сгоревший бюджет — это вход в планирование, а не только разбор инцидента. Механически: при систематическом сгорании reliability-задачи поднимаются в приоритете над фичами на следующий цикл — это записано в policy. На квартальном reliability review мы смотрим burn-rate за квартал по каждому пути и решаем, куда идёт инженерное усилие. Если поиск стабильно жжёт бюджет — значит, в следующем квартале часть roadmap уходит на его укрепление, и продакт это принимает, потому что видит связь „сгорание → потерянная выручка“».

Это проверка на то, что SRE и продукт планируют из одного документа, а не из двух. Если бюджет ошибок никак не дотягивается до roadmap — SRE и продукт живут в разных вселенных, и SLO снова декорация.

Главный паттерн всех пяти кейсов#

Сведём пять кейсов в одну таблицу — что на самом деле проверяет каждый:

Вопрос на собесе	Что реально проверяют	Маркер слабого ответа
Зачем 99.9, а не 99.99?	Рамка «бюджет → архитектура → деньги»	Начал с топологии, а не со сценария
99.95, но 30% оплат не проходит?	Разрыв «доступность vs надёжность»	Полез чинить зелёную инфраструктуру
Бизнес хочет 100%?	Переговорный навык	Сказал «невозможно» и закрыл тему
Кто решает фриз?	Error budget policy как продуктовый артефакт	«SRE решает» / «тимлид решает»
Бюджет → roadmap?	Встроен ли SRE в плановый цикл	«Делаем post-mortem» (про прошлое)

На собесе не проверяют знание формул сгорания бюджета — это гуглится за минуту. Проверяют, можешь ли ты вести разговор о надёжности так, чтобы бизнес поменял своё поведение. Все пять сильных ответов имеют одну форму: начать со сценария и денег, перевести требование в трейд-офф, вернуть выбор бизнесу, сослаться на заранее согласованное правило. Это и есть навык, который «чертёж» описывал как «SLO — интерфейс между System Design и бизнесом», только теперь — со стороны человека, который этим интерфейсом пользуется вживую.

Метрики SRE-команды для мультипродукта#

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

Когда продуктов становится 5–10, эта простая картина ломается. Команда обслуживает зоопарк сервисов с разными CUJ, разной критичностью, разной зрелостью. И тут возникает вопрос, на который у большинства команд нет хорошего ответа: как одной цифрой отчитаться перед менеджментом за надёжность, которую ты дал восьми разным продуктам? Соблазн — взять среднее. На нём всё и ломается.

Что не работает как метрика команды#

Три популярных агрегата, каждый из которых врёт по-своему:

• MTTR в среднем по всем инцидентам. Растворяет редкие тяжёлые случаи в массе мелких. Команда, которая быстро закрывает сто пустяковых алертов и месяц не может починить один критичный, покажет прекрасный средний MTTR. Хуже того, метрика поощряет «закрыть быстро, не разбираясь» — лишь бы цифра была хорошей.
• Composite SLO по всем продуктам. «Средняя надёжность по компании 99.94%» — это средняя температура по больнице. Она теряет CUJ: упавший в ноль критичный путь одного продукта тонет в здоровье семи остальных. Наивная агрегация SLO в мультипродукте математически врёт — этот эффект хорошо разобран в посте Алекса Идальго «Implicit SLOs and their dangers» : композит почти всегда оптимистичнее, чем худший из путей, а пользователю больно именно от худшего.
• Количество инцидентов в абсолюте. Стимулирует молчать о мелких. Если команду меряют числом инцидентов, она перестаёт их заводить — и ты теряешь сигнал. Это классический закон Гудхарта: метрика, ставшая целью, перестаёт быть метрикой.

Общая болезнь всех трёх — они сжимают разнородное в одно число, и в этом сжатии теряется ровно то, ради чего метрику заводили.

Что осмысленно мерить: три слоя#

Вместо одного агрегата — раскладка по трём слоям, параллельная трём ролям из «чертежа»: бизнес / инженерия / управление. Каждый слой отвечает на свой вопрос и не пытается заменить остальные.

Слой 1. Надёжность продуктов суммарно (бизнес-слой)#

Не «средний SLO», а покрытие и распределение:

• Доля продуктов, у которых SLO существует, написан в терминах CUJ и формально подписан продактом. Это метрика зрелости, а не надёжности. «6 из 8 продуктов имеют подписанный SLO» говорит больше, чем любой композит.
• Доля продуктов с действующей error budget policy. Не «есть SLO», а «есть записанное правило, что делать при сгорании». Обычно эта доля сильно меньше первой — и разрыв между ними и есть фронт работ.
• Burn-rate бюджетов по всем продуктам как тепловая карта, а не среднее. Восемь строк, в каждой — сгорание за квартал. Красные клетки видно сразу, и ни одна не тонет в зелёных соседях.
• Сумма money loss за квартал — если связка SLI → ₽ настроена. Это единственная цифра из этого слоя, которую менеджмент понимает без перевода.

Слой 2. Инженерное усилие команды (продуктивность)#

Сколько стоит надёжность в человекочасах и насколько это устойчиво:

• Toil как % времени команды. Гугловский потолок — 50% (правило из главы «Eliminating Toil» в Google SRE Book); всё, что выше, означает, что команда тонет в ручной рутине и не строит автоматизацию. Toil — отличная инженерная метрика зрелости именно потому, что растёт незаметно и душит команду медленно.
• Доля задач, переходящих от SRE обратно в продуктовую команду. Антипаттерн — «SRE как owner навсегда»: команда взяла продукт на поддержку и больше его не отпускает. Здоровая динамика — знания и ответственность постепенно возвращаются в продуктовую команду, а SRE остаётся на инструментарии и сложных случаях.
• Время от инцидента до закрытого action item — не до восстановления. Восстановили за 20 минут, а исправили причину через полгода — это плохо, и средний MTTR это скрывает, а эта метрика показывает.
• Доля постмортемов с реализованными action items. Постмортем, после которого ничего не сделали, — это терапия, а не инженерия. Эта доля показывает, учится ли команда на самом деле.

Слой 3. Качество диалога (управленческий слой)#

Самый неочевидный и самый важный слой — он меряет ровно то, о чём вся статья: встроена ли надёжность в продукт или живёт в инженерной резервации.

• Регулярность product reliability review. Проводится ли квартальный разбор бюджета с каждым продактом — или только с теми, кто сам пришёл. Цель — со всеми и по расписанию.
• Доля продуктов, где бизнес сам приходит за обсуждением бюджета. Это лакмус. Если продакт сам спрашивает «сколько у нас бюджета осталось» — диалог здоров. Если SRE его догоняет — нет. Эта доля растёт медленно и означает культурный сдвиг, а не процессный.
• NPS/CSAT-аналог от команд разработки на сервис SRE. Команда SRE — это тоже сервис, у него есть внутренние пользователи (продуктовые команды), и их удовлетворённость измерима. Низкий внутренний CSAT при хороших технических метриках — сигнал, что SRE воспринимают как тормоз, а не как партнёра.

Соберём три слоя в одну таблицу — её удобно держать перед глазами при отчёте:

Слой	Вопрос	Пример метрики	Какой агрегат заменяет
1. Надёжность продуктов	Какую надёжность мы дали бизнесу	Доля продуктов с подписанным CUJ-SLO; money loss за квартал; burn-rate тепловой картой	Composite SLO
2. Инженерное усилие	Какой ценой и насколько устойчиво	Toil %; время до закрытого action item; доля постмортемов с реализованными AI	Средний MTTR
3. Качество диалога	Встроена ли надёжность в продукт	Регулярность reliability review; доля «бизнес пришёл сам»; внутренний CSAT на SRE	Число инцидентов

Ни одна метрика из правой колонки («какой агрегат заменяет») не исчезает полностью — MTTR и счётчик инцидентов остаются полезными для внутренней диагностики. Но как метрика команды перед менеджментом они проигрывают трёхслойной раскладке, потому что усредняют то, что усреднять нельзя.

Как это звучит в отчёте менеджменту#

Финальная проверка всей раскладки — как команда отчитывается наверх. Сравни два варианта.

Плохо (агрегат): «У нас средний MTTR 22 минуты и composite SLO 99.94%». Менеджмент кивает, ничего не понимает, ни одно решение не меняется.

Хорошо (три слоя): «За квартал укрепили подписанный SLO с error budget policy у 6 из 8 продуктов (было 4), суммарное сгорание бюджета упало на 35%, бизнес-потери от инцидентов сократились на N рублей. Toil держим на 40%. Два продукта вернули в зону ответственности продуктовых команд. Осталось два продукта без политики — это фронт на следующий квартал».

Второй отчёт показывает движение, цену и план. Это и есть язык, на котором SRE-команда разговаривает с менеджментом, когда продуктов больше одного, — не «средняя температура», а «вот что мы дали бизнесу и как конвертировали инженерное усилие в продуктовый результат».

Что сделать завтра утром#

Чек-лист «куда вернуться», когда дочитал. Пять вопросов — если на какой-то нет ответа, там и фронт работ.

1. Какой product reliability review встроен в наш квартальный план? Если ответ «никакой» или «по запросу» — начни с того, чтобы поставить в календарь регулярную встречу по бюджету с каждым продуктовым владельцем.
2. Кто из бизнеса формально подписал error budget policy — и подписал ли вообще? Если не можешь назвать имя — у тебя SLO-артефакт, а не контракт. Это задача номер один.
3. На какой панели я вижу „health по сценарию“, а не „health по сервису“? Если только по сервису — твои SLI повешены на ручки, а не на пути, и ты не видишь того, что чувствует пользователь.
4. Сколько раз за последний квартал бизнес сам поднял разговор о трейд-оффе „фича против надёжности“? Если ноль — диалог пока односторонний, и слой 3 у тебя в красной зоне.
5. Какой из метрик трёх слоёв у нас нет — и почему? Чаще всего отсутствует слой 3 (качество диалога), потому что его сложнее всего мерить. Но именно он отличает зрелую практику от набора дашбордов.

Заключение#

В «чертеже» я доказывал, что архитектура без SLO — это эстетика, а не инженерия. Эта статья добавляет вторую половину: SLO без диалога — это дашборд, а не управление.

Чертёж надёжности сам по себе мёртв. Его надо защищать, торговать им и переписывать вместе с бизнесом каждый квартал. Технический инструмент — SLI, SLO, error budget — становится управленческим ровно в тот момент, когда у инженеров и бизнеса появляется одна картинка целевой надёжности и одна валюта компромиссов. До этого момента у тебя есть только красивые графики и предчувствия.

Три вещи, ради которых стоило городить всю статью:

• Диалог — это формат принятия решений, а не презентация. Его сердце — записанная error budget policy, подписанная продуктовым владельцем.
• На собесе по SLO проверяют переговорный навык, а не арифметику. Сильный ответ начинается со сценария и денег и возвращает бизнесу выбор.
• Метрики команды при мультипродукте — это три слоя, а не один агрегат. Среднее по больнице прячет именно ту боль, ради которой метрику заводили.

Надёжность не «достигается». Она каждый квартал заново строится в диалоге — и проигрывается ровно там, где этот диалог замолчал.

Спасибо, что дочитал до конца. Это продолжение цикла, начатого статьёй «SLO как чертёж архитектуры» . Если у тебя есть свой опыт диалога с бизнесом о надёжности — особенно истории, как error budget policy реально остановила релиз или как менялись метрики команды с ростом числа продуктов, — буду рад услышать.

---

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.