SRE: карта трека и чем надёжность отличается от «чтобы не падало»

В понедельник продакт приносит скриншот из чата поддержки: «со вторника не проходят платежи картами одного банка, клиенты жалуются пятый день». Дежурный открывает дашборд: за неделю аптайм 99,98 %, ни одного алерта, ни одного инцидента. Формально всё в порядке.

Дальше выясняется картина. Проверка /health дёргает SELECT 1 и всегда отвечает 200. Платёжный шлюз одного банка отвечает таймаутом в 8 % случаев, клиент видит «попробуйте позже». Восемь процентов от узкой группы — меньше 0,3 % всех запросов, а порог алерта стоит на 1 % ошибок по сервису. Метрика не соврала: она отвечала не на тот вопрос. Это не история про плохой мониторинг, а про то, что цель «чтобы не падало» не выражена числом и потому её нельзя ни проверить, ни нарушить. Трек — о том, как превратить надёжность в величину, о которой можно спорить с цифрами на руках и принимать решения вроде «выкатываем сегодня или нет». Эта глава — карта: определения, арифметика, честная цена, порядок чтения остальных глав.

Пять отличий надёжности от «чтобы не падало»

Формулировка «чтобы не падало» непроверяема: она не запрещает ни одного наблюдения. Инженерное понятие отличается от неё по пяти пунктам, и каждый меняет практику.

1. Отказ не бинарен. Между «работает» и «лежит» лежит всё, что реально происходит: часть запросов падает, часть путей медленная, одна страна отрезана, один тип карт не проходит. Сервис, отвечающий за 30 секунд, сломан ровно так же, как отвечающий 500-й, — просто в дашборде он зелёный.

2. Мера берётся со стороны пользователя, а не сервера. «Процесс жив» — свойство хоста. «Запрос на оплату завершился успешно быстрее 2 секунд» — свойство пользовательского опыта. Первое мерить легко и бесполезно, второе трудно и осмысленно; переход — тема главы 02.

3. У цели есть число, и оно сознательно меньше 100 %. Сто процентов — не идеал, а утверждение «мы никогда не будем менять систему», потому что изменения и есть основной источник отказов. Отсюда бюджет ошибок: разрешённая доля неудач, которую можно осознанно тратить.

4. Надёжность — свойство системы вместе с процессом. Как выкатывают, как откатывают, кого будят, кто решает отключить фичу — часть надёжности в той же мере, что таймауты и ретраи.

5. У надёжности есть цена, и её платят конкретные люди и деньги. Каждая девятка стоит нелинейно дороже предыдущей, ночные пейджеры выжигают инженеров, второй регион удваивает счёт от облака. Разговор о надёжности без разговора о цене — не инженерный. Отсюда рабочее определение, которым пользуется весь трек:

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

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

Арифметика девяток: сколько это в минутах

Проценты обманчивы, пока не переведены в минуты. Месяц в 30 суток — это 30 × 24 × 60 = 43 200 минут, год — 525 600 минут. Допустимый простой = (100 % − SLO) × длина окна.

Расчёт для 99,9 %: 43 200 × 0,001 = 43,2 минуты. Для 99,999 %: 43 200 × 0,00001 = 0,432 минуты = 25,92 секунды. Эта таблица переводит спор «давайте сделаем понадёжнее» в спор «готовы ли мы уложить весь месячный бюджет в 26 секунд».

Считать по времени или по запросам — разные ответы. Классический аптайм — доля времени, когда сервис считался живым; современный SLI считает долю успешных событий. Пусть сервис держит 1000 запросов в секунду: за месяц это 1000 × 2 592 000 = 2,592 млрд запросов, при SLO 99,9 % разрешено 2,592 млн неудач — и если они размазаны ровным слоем по 0,1 %, сервис не «лежит» ни одной минуты, а бюджет сгорает целиком. Наоборот: сорок минут полного отказа в четыре часа ночи, когда нагрузка в двадцать раз ниже дневной, по времени съедят весь месячный бюджет, а по запросам — малую его часть. Счёт по запросам взвешивает ущерб по трафику и ближе к бизнес-смыслу, счёт по времени проще пишется в договор; практика — считать по запросам, но хранить разметку инцидентов по времени.

Верхняя полоса на картинке — не бюджет, а разложение типичного MTTR (mean time to recovery) инцидента, который чинит живой человек:

Двадцать три минуты — 53 % месячного бюджета SLO 99,9 %, весь бюджет 99,95 % и пять с лишним бюджетов 99,99 %. Отсюда следует не лозунг, а инженерное ограничение:

Любая цель выше 99,95 % означает, что человека в цепочке восстановления быть не может. Не «должен работать быстрее» — а вообще не участвует: смягчение делает автоматика.

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

Почему 100 % — неправильная цель, и это считается

Первый аргумент: последовательная цепочка. Если запрос обязан пройти через N компонентов и каждый может отказать независимо, доступность системы — произведение доступностей. Шесть звеньев по «не хуже 99,9 %» дают вовсе не 99,9 %:

0,9999 (DNS) × 0,9995 (CDN) × 0,9999 (LB) × 0,999 (API) × 0,9995 (кэш) × 0,9995 (БД)
= 0,99730  →  1 − 0,99730 = 0,00270  →  0,00270 × 43 200 = 116,5 мин/мес

Отсюда самый дешёвый рычаг в теме: вынести звено из обязательной цепочки. Если промах кэша означает поход в базу, а не ошибку, кэш перестаёт умножаться в формуле — накопленный простой падает со 116,5 до 95,0 минут в месяц. Это 21,6 минуты, которые не пришлось покупать девяткой ни на одном узле. Как строить такие деградации — глава 10.

Второй: резервирование не независимо. Два экземпляра по 99 % в параллели дают 1 − 0,01 × 0,01 = 99,99 % — но только при независимых отказах. Они не независимы: общий конфиг, общий образ, общий деплой, общий DNS, общая ошибка в миграции. Пусть 20 % отказов вызваны общей причиной, которая кладёт обе реплики сразу:

недоступность = 0,20 × 0,01            (общая причина, резерв не спасает)
              + (0,80 × 0,01)²         (независимая часть, обе реплики сразу)
              = 0,002 + 0,000064 = 0,002064  →  99,79 %

Вместо обещанных 99,99 % — 99,79 %, в двадцать раз хуже расчёта. Доля общих причин — главный параметр формулы, и уменьшают её не покупкой второй стойки, а разнесением конфигураций, поэтапной выкаткой и разными окнами обновления; какие модели отказа вообще стоит предполагать — модели отказов.

Третий: клиент вне вашего контроля. Мобильная сеть даёт порядка 99,5 % успешных соединений: 0,99730 × 0,995 = 0,99232 → 331,9 минуты в месяц с точки зрения пользователя. Вывод не «сдаться», а «выбрать точку измерения и честно сказать, что в неё входит». SLO на балансировщике и SLO в браузере — разные обещания.

Бюджет ошибок: арифметика, которая меняет решения

Бюджет ошибок — разность между 100 % и SLO в тех же единицах, что SLI. Ценность не в определении, а в том, что он превращает надёжность в расходуемый ресурс с остатком. Пока остаток есть, команда имеет право рисковать: выкатывать чаще, пробовать новую схему шардирования, мигрировать хранилище. Остаток кончился — право приостановлено.

Разберём месяц на числах: SLO 99,9 % по запросам, трафик 1000 rps, бюджет месяца = 2,592 млрд × 0,001 = 2 592 000 запросов.

Проверка строк: 1000 × 660 с = 660 000, и 660 000 / 2 592 000 = 25,5 %; второй инцидент — 1000 × 1080 × 0,6 = 648 000 → 25,0 %; фон — 2,592 млрд × 0,00016 = 414 720 → 16,0 %. Теперь решение о релизе перестаёт быть спором характеров: осталось 33,5 % бюджета и десять дней месяца, средний релиз квартала стоил 6 % — значит, до конца месяца можно позволить примерно пять релизов, а не пятнадцать. Это разговор, который можно вести с продактом.

Скорость сгорания (burn rate) отвечает на другой вопрос: просыпаться сейчас или ждать до утра. Это отношение наблюдаемой доли ошибок за окно к допустимой доле (1 − SLO). При SLO 99,9 % допустимая доля 0,1 %; если за последний час ошибок 1,44 %, burn rate = 14,4. Час занимает 1/720 месяца, значит за него сожжено 14,4 / 720 = 2 % месячного бюджета. Отсюда набор порогов из SRE Workbook, каждый проверяется в одну строчку:

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

Чего бюджет не делает. Он не заменяет суждение: инцидент, задевший десять корпоративных клиентов из тысячи, может стоить дороже, чем инцидент на 2 % розничного трафика, хотя в бюджете второй весит больше. Он бесполезен, если SLO выставлен так, что бюджет никогда не тратится, и превращается в оружие, если «заморозка фич» объявлена без предварительной договорённости: тогда команды спорят об определении SLI вместо того, чтобы чинить систему.

Цена надёжности: три статьи расходов, которые считают редко

Люди: арифметика дежурства

Круглосуточное дежурство — 168 часов в неделю, которые кто-то должен покрыть. При недельной ротации из N человек каждый дежурит 52/N недель в году:

Вывод, который обычно не хотят слышать: если в команде меньше шести человек, честного 24/7-дежурства у вас нет — есть договорённость, что кто-то посмотрит, если проснётся. Варианты: покрывать пейджером рабочие часы и вечер, а ночью полагаться на автоматическое смягчение; объединить дежурство нескольких команд по общему рунбуку; договориться с бизнесом на SLO, допускающее ночной простой. Все три честнее, чем расписание, разваливающееся на третьем месяце. Вторая часть цены — ночные пробуждения: разбуженный в 3:40 инженер теряет не полчаса, а следующий рабочий день, и два пробуждения за неделю дежурства — сигнал, что алерты настроены плохо или система требует ручного управления. Метрики с первого дня: число пейджей на одно дежурство и доля пейджей, потребовавших действия. Разбор — дежурство, взгляд руководителя — дежурства и инциденты.

Алерты: почему шум обесценивает всё

Алерт, на который не нужно совершать действие, не нейтрален — он отрицателен. Механизм наблюдаемый: если из 100 пейджей за квартал 85 не требовали вмешательства, дежурный статистически прав, откладывая проверку на пять минут — он не ленив, он оптимален при таком распределении. Но эти пять минут добавляются к MTTR каждого реального инцидента, включая пятнадцать настоящих: шумный алерт покупает вам минуты простоя на всех остальных. Отсюда правило, которое проще принять, чем оспорить: у каждого пейджерного алерта должно быть записанное действие; нет действия — это не пейджер, а дашборд или тикет.

Деньги: сколько стоит девятка

Инфраструктура одного региона — 10 000 USD в месяц. Активный второй регион добавляет примерно столько же плюс межрегиональный трафик и удвоение операционной сложности; реалистичный множитель 1,8–2,2, возьмём +9000 USD в месяц. Что покупаем? Не «девятку вообще», а устранение одного класса отказов — падения региона. Такие события редки: пусть один трёхчасовой региональный отказ в год = 180 минут в год = 15 минут в месяц в среднем. Годовой бюджет 99,9 % — 525,6 минуты; убрав региональный отказ, получаем 345,6 минуты, то есть 99,934 %. Не 99,99 %.

Ценность этих минут: при выручке 1 200 000 USD в месяц минута простоя стоит в среднем 1 200 000 / 43 200 = 27,8 USD, экономия 15 минут = 417 USD в месяц против расхода 9000 USD в месяц — не окупается в двадцать раз. Расчёт переворачивается, если простой стоит не средних денег (отказ в пиковый час дороже ночного в 5–10 раз, а SLA со штрафами делает минуту тысячедолларовой), если отток необратим (ушедший в момент оплаты покупатель не возвращается) или если мультирегион — условие лицензии. Но главное: большая часть недоступности приходит не от падения региона. По оценкам Google, порядка 70 % отказов вызваны изменениями — релизами, конфигурациями, миграциями, — значит, деньги за второй регион борются с меньшей частью проблемы, пока не наведён порядок в выкатке. Отсюда порядок вложений: сначала безопасные релизы, потом деградация и ёмкость, и только потом географическая избыточность; экономика облака — стоимость и компромиссы.

Где инженерное решение упирается в организационное

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

Инцидент как процесс, а не как паника

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

Три перехода, на которых спотыкаются чаще всего. «Подозрение → Инцидент» должен опираться на признак ущерба пользователю, а не на цвет графика, иначе объявление инцидента обесценивается. «Смягчение → Инцидент» — обязательный цикл: первая гипотеза часто неверна, и без явного возврата команда часами копает не там, стесняясь признать тупик. И «Смягчение», а не «Исправление»: первая цель — вернуть пользователям работу, а не понять причину. Откат, отключение флага, переключение трафика законны, даже если непонятно, что именно сломалось; понимание — работа постмортема, у неё другой дедлайн. Роли, каналы связи и первые тридцать минут — реакция на инцидент.

Постмортем без обвинения: механизм, а не доброта

Требование «постмортем без обвинения» часто подают как этическую норму, и в таком виде оно не выдерживает первого спора («а если человек правда ошибся?»). На самом деле это утверждение о потоке информации, и его можно вывести. Единственный источник данных о том, что происходило внутри инцидента, — участники: только они знают, какую команду набрали в консоли, почему решили, что дело в базе, какая строчка в рунбуке сбила с толку, какой дашборд смотрели первым; ничего из этого нет в логах. Если рассказ о своих действиях повышает риск получить выговор, рациональная стратегия — рассказывать меньше и осторожнее. Данные иссякают; с худшими данными разбор находит меньше причин; правки становятся поверхностными («добавили проверку в код-ревью»); настоящий дефект процесса остаётся и стреляет снова — а следующий разбор проходит в ещё более напряжённой обстановке. Это усиливающая петля обратной связи в чистом виде: выход контура увеличивает вход того же контура (петли обратной связи).

Практический признак, что петля уже работает: в постмортемах перестают появляться near miss — случаи, когда чуть не сломали, но поймали. Их не стало меньше, о них перестали рассказывать.

Что тогда является причиной вместо «инженер выполнил не ту команду»? То, что систему можно было сломать одной командой без подтверждения; что рунбук содержал устаревший пример; что тестовый и боевой контуры выглядели одинаково в консоли — все три формулировки порождают правки, реально уменьшающие вероятность повторения (постмортемы). Границу стоит назвать честно: безобвинительность не отменяет последствий за намеренное нарушение процедур или халатность — она означает, что разбор инцидента не то место, где такие вопросы решаются, потому что смешение двух функций убивает первую.

Каскадный отказ — это усиливающая петля

Та же оптика объясняет самый неприятный класс продакшн-аварий. Каскад выглядит как цепь причин, но устроен как контур: сервис B замедлился → клиенты A ждут дольше → у A растёт число занятых воркеров → клиенты по таймауту повторяют запрос → нагрузка на B выросла на долю повторов → B замедлился ещё сильнее. Свойство, которое ломает интуицию: система остаётся в отказе даже после того, как исходная причина исчезла. Всплеск закончился, релиз откатили, а сервис не поднимается, потому что теперь его топят собственные ретраи. Отсюда практика: во время каскада первым делом сбрасывают нагрузку — отключают повторы, включают ограничение частоты, дропают часть трафика, — а не «добавляют ресурсов». Механика — как ломаются системы, противоядия — деградация; почему очередь взрывается нелинейно у порога насыщения — ёмкость и нагрузочное тестирование.

Google SRE: что переносится, а что нет

«Site Reliability Engineering» (O’Reilly, 2016, https://sre.google/sre-book/table-of-contents/) и «The Site Reliability Workbook» (2018, https://sre.google/workbook/table-of-contents/) — лучший доступный источник по теме. Но написаны они организацией с собственным планировщиком кластеров, собственным мониторингом, десятками тысяч инженеров и таким масштабом, при котором редкие отказы набирают статистику. Часть практик переносится в команду из восьми человек почти без потерь, часть не переносится вообще.

Переносится почти без изменений: SLI/SLO/бюджет ошибок как язык разговора с бизнесом; постмортемы без обвинения; роль командира инцидента, отделённая от роли того, кто чинит руками; алерты на симптомы и на скорость сгорания бюджета; канареечные выкатки и флаги; toil как измеряемая величина. Не переносится: отдельная команда SRE с правом «вернуть сервис разработчикам» — для этого нужны две команды на сервис, которых у вас нет; политика «не более 50 % времени на операционную работу» — при шести инженерах она фикция; собственный стек наблюдаемости; выделенный SRE на продукт; и, что важнее всего, ожидание, что редкие классы отказов наберут статистику — при вашем трафике вы увидите их один раз и не успеете построить модель.

Минимальный работающий набор для маленькой команды (подробно — глава 15):

1. Два-три SLI на критичные пользовательские пути, измеренные на границе сервиса.
2. Одно SLO на каждый, согласованное с продактом и записанное в общедоступном месте.
3. Один пейджерный алерт на быстрое сгорание бюджета плюс тикетные на медленное.
4. Рунбук на страницу для каждого пейджера: как проверить, как смягчить, кого звать.
5. Постмортем на одну страницу для всего, что задело пользователей дольше 15 минут.
6. Ежеквартальный пересмотр SLO по фактическим данным.

Всё остальное — надстройка, которую добавляют, когда эти шесть пунктов работают полгода.

Карта трека

Пятнадцать глав собраны в пять блоков: мера (01–03) — язык, на котором о надёжности вообще можно говорить; наблюдение (04–05) — как увидеть нарушение цели и не утонуть в шуме; люди в цикле (06–08) — дежурство, инцидент, разбор; устойчивость системы (09–11) — запас, деградация и механика каскадов; изменения (12–15) — как менять систему, не проедая бюджет.

Маршруты чтения. Уже горит — 07, 05, 10, потом остальное. Строите с нуля и спешки нет — по порядку, 01 → 15. Нужен разговор с бизнесом — 01, 02, 03 и раздел про цену выше. Собираете дежурство как тимлид — 06, 07, 08 и взгляд руководителя.

Что предполагается известным. Трек опирается на соседние темы и не пересказывает их: стратегии релиза и инфраструктура как код; наблюдаемость в распределённой системе; измерение производительности; репликация; прокси и балансировка; тестирование производительности; ошибки и устойчивость в коде.

Типичные ошибки на старте

• SLO придумали инженеры и не показали никому. Первый конфликт со сроками отменяет цель: SLO без подписи владельца продукта — упражнение.
• Взяли 99,99 %, потому что «звучит серьёзно». Это 4,32 минуты в месяц, то есть запрет на ручное вмешательство. Начинайте с уровня, который держите по факту, и повышайте по данным.
• Измеряют то, что легко. /health возвращает 200 — не SLI. SLI живёт там, где живёт пользовательская задача: оформленный заказ, доставленное сообщение, отрисованная страница.
• Алерт на каждую метрику. Через квартал 90 % пейджей не требуют действия — и дежурный перестаёт реагировать на все.
• Постмортем как отчёт наверх. Документ, написанный для руководства, содержит формулировки для руководства и не содержит деталей, ради которых пишется.
• Обещание в SLA жёстче внутреннего SLO. Внутренняя цель должна быть строже внешней с запасом, иначе штрафы наступят раньше внутреннего сигнала.

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

Мини-итог

Надёжность становится инженерной дисциплиной в момент, когда у неё появляется число: SLI, который меряет пользовательский опыт; SLO, который назначает цель ниже 100 %; бюджет ошибок, который делает эту цель расходуемым ресурсом. Дальше всё — следствие арифметики. 43,2 минуты в месяц против 23 минут на один ручной инцидент объясняют, почему выше 99,95 % человека в цикле быть не может; произведение доступностей — почему выносить звенья из обязательной цепочки дешевле, чем покупать девятку; усиливающая петля — и каскадный отказ, и то, почему поиск виноватого разрушает разбор. Цена считается теми же цифрами и в половине случаев показывает, что девятку покупать не нужно.

Источники

• Betsy Beyer et al. Site Reliability Engineering, O’Reilly, 2016 — https://sre.google/sre-book/table-of-contents/; главы «Embracing Risk» и «Service Level Objectives».
• Betsy Beyer et al. The Site Reliability Workbook, O’Reilly, 2018 — https://sre.google/workbook/table-of-contents/; «Implementing SLOs» и «Alerting on SLOs» — источник таблицы порогов burn rate.
• Alex Hidalgo. Implementing Service Level Objectives, O’Reilly, 2020 — SLO вне гугловского масштаба.
• John Allspaw. Blameless PostMortems and a Just Culture, Etsy, 2012 — https://www.etsy.com/codeascraft/blameless-postmortems/.
• Sidney Dekker. The Field Guide to Understanding Human Error, 3rd ed., 2014 — почему «человеческий фактор» является началом расследования, а не выводом.
• Nathan Bronson et al. Metastable Failures in Distributed Systems, HotOS 2021 — https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf.
• Michael Nygard. Release It!, 2nd ed., Pragmatic Bookshelf, 2018 — размыкатели, переборки, таймауты.

Что дальше

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