SRE в небольшой команде: что переносится, а что нет

В январе техдиректор компании из двадцати человек прочитал книгу Google про SRE и объявил внедрение. К апрелю у команды было сорок два дашборда, двести семнадцать правил алертинга, канал #sre и вики-страница «Наша SRE-культура» на шесть тысяч знаков.

Ни одного SLO. Ни одного постмортема. Расписание дежурств — «пишите Диме, он обычно отвечает». За тот же квартал случились четыре инцидента дольше часа, и все четыре обнаружили пользователи.

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

Эта глава — последняя в треке и по жанру обратная всем остальным. Там мы разбирали механизмы по одному; здесь собираем их обратно в практику для команды, у которой нет ни отдельной роли SRE, ни второго региона, ни статистики. Три вопроса, на которые надо ответить честно: какую надёжность вы вообще можете обещать (это считается, а не выбирается), сколько она стоит (в деньгах, в людях и во внимании) и что из канона переносится, а что описывает чужую компанию.

Кто здесь «небольшая команда»

«Небольшая» — не про количество людей само по себе, а про то, сколько внимания остаётся на надёжность после всего остального. Три профиля, дальше в главе я на них ссылаюсь.

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

Потолок сверху: доступность, за которую вы не отвечаете

Первое, что стоит посчитать перед любым разговором о целях, — потолок, заданный вашими поставщиками. Возьмём типовую установку профиля B: приложение на управляемых контейнерах, управляемый PostgreSQL, объектное хранилище, балансировщик. У каждого сервиса есть SLA — уровень, ниже которого поставщик возвращает часть денег.

вычисления (региональный SLA)    0,9999
управляемая БД с резервом в др. зоне 0,9995
объектное хранилище              0,999
балансировщик                    0,9999

0,9999 × 0,9995 × 0,999 × 0,9999 = 0,9983008
1 − 0,9983008 = 0,0016992
0,0016992 × 43 200 мин = 73,4 мин/мес   (месяц = 30 сут = 43 200 мин)
0,0016992 × 525 600 мин = 893 мин/год ≈ 14 ч 53 мин

Семьдесят три минуты в месяц — и это ещё до вашего кода. Внутреннее SLO 99,9 % (43,2 минуты) формально выше того, за что отвечает хоть кто-то под вами.

Здесь нужны две честные оговорки, иначе расчёт превращается в манипуляцию.

Первая: SLA — это не прогноз, а порог возврата денег. Поставщики держат заметно больше обещанного; фактическая доступность управляемой БД в спокойном регионе обычно ближе к четырём девяткам, чем к 99,95 %. Для планирования берите свои исторические измерения, а не SLA.

Вторая: SLA — не страховка. Типовая сетка компенсации — 10 % месячного счёта при доступности ниже порога, 25–30 % при грубом нарушении. При счёте 850 USD это 85 USD. Сутки простоя при валовой выручке 60 000 USD в месяц стоят вам около 2 000 USD валовой выручки — компенсация покрывает четыре процента ущерба.

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

Потолок снизу: скорость человека

Второй потолок задаёт не техника, а физиология. В главе про дежурство мы разбирали ночную цепочку по минутам: обнаружение алертом 3, доставка звонка 1, primary не берёт трубку 5, secondary принял 2, встал и подключился 6, гипотеза и проверка 6, откат 4 — около 27 минут до устранения. Днём быстрее, ночью бывает и дольше.

Сопоставим с бюджетами (месяц 43 200 минут):

Отсюда правило, которое стоит выучить раньше любых практик:

99,9 % — верхняя граница того, что небольшая команда держит человеческими средствами. Каждая следующая девятка покупается не старанием, а автоматикой на конкретный, заранее названный класс отказа.

Автофейловер БД за 90 секунд, автоматический откат по метрике, здоровьевая маршрутизация мимо больного экземпляра — это и есть «покупка девятки»: заранее описанный сценарий, из которого человек убран. Всё остальное — «будем внимательнее» — арифметически не работает.

Пять девяток: считаем, кому они нужны

99,999 % — это 25,9 секунды в месяц и 5 минут 15 секунд в год. Что это означает операционно:

• ни одного развёртывания с окном недоступности — вообще ни одного за год;
• обнаружение отказа за секунды, а не за минуты: минутное окно алерта уже больше двух годовых бюджетов;
• автоматический обход любого отказа быстрее чем за 26 секунд, включая отказ, который вы не предвидели;
• отсутствие слоя, способного упасть целиком, — включая конфигурацию, DNS, систему деплоя и сам механизм переключения;
• доказательство, что всё вышеперечисленное работает, то есть регулярные учения с настоящим отключением (учения и chaos-эксперименты).

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

Три отрезвляющих соображения для всех остальных.

Пользователь не отличит. Он приходит к вам через мобильную сеть, домашний Wi-Fi и чужой DNS. Суммарная надёжность этого пути заметно ниже трёх девяток. Ваши 4,3 минуты вместо 43 в месяц утонут в его собственных обрывах связи — если только эти 43 минуты не случатся ровно в момент его платежа. Что подводит к следующему.

Важна не доля, а распределение. 43 минуты, размазанные по месяцу как 0,1 % ошибок, и 43 минуты одним куском в чёрную пятницу — одно и то же число и совершенно разные события. Небольшой команде почти всегда важнее ограничить длину худшего инцидента, чем поднять среднюю доступность. Это дешевле: быстрый откат стоит дня работы, второй регион — годового бюджета.

Правильный вопрос — не «сколько девяток», а «какой отказ клиент не простит». Составьте список недопустимых событий: потерянный платёж, потерянные данные, недоступность дольше часа в рабочее время, тихая выдача неправильных цифр. Очень часто оказывается, что нужен не апгрейд доступности, а идемпотентность и persistent-очередь (доставка и идемпотентность) — на порядок дешевле и решает ровно ту боль, из-за которой начался разговор.

И последнее: когда поставщик продаёт вам четыре девятки, спросите, что у него в числителе. Очень часто там доступность управляющего API, а не вашей нагрузки.

Что переносится почти без изменений

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

Одна практика переносится не полностью, и это стоит посчитать отдельно.

Канареечная выкатка при низком трафике

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

трафик по изменённому пути: 2 rps
канарейка 5 %  →  0,1 rps  →  360 запросов в час
фоновая доля ошибок: 0,1 %  →  ожидаем 0,36 ошибки за час

версия ломает 1 % запросов:    ожидаем 3,6 ошибки
   вероятность не увидеть ни одной за час = e^(−3,6) = 0,027 → ловим в 97 % случаев

версия ломает 0,3 %:           ожидаем 1,08 ошибки
   вероятность пропустить = e^(−1,08) = 0,34 → треть шансов выкатить поломку дальше

версия ломает 0,1 %:           неотличимо от фона вообще

Вывод не «канарейка бесполезна», а конкретный: при низком трафике канарейка различает только грубые поломки. Три работающих ответа.

1. Увеличить долю, а не время: 50 % от 2 rps — это 3 600 запросов в час, поломка в 0,3 % даёт ожидаемые 10,8 ошибки против 3,6 фоновых и различима. Формально это уже не канарейка, а поэтапная выкатка, и это нормально.
2. Считать на событиях, а не на времени: держать канарейку не «полчаса», а «пока не пройдёт N запросов», иначе ночная выкатка проходит проверку на пустом трафике.
3. Перенести вес на откат: если поломку всё равно поймает первый час полной выкатки, важнее не удлинять канарейку, а уметь откатиться за минуту и наблюдать за первым часом целенаправленно.

Что не переносится, и по какой причине

Здесь важен не список, а механизм: каждая из этих практик опирается на ресурс, которого у вас нет.

Отдельно про «книга прямо об этом пишет». Google в главе про дежурство говорит, что для круглосуточного покрытия нужна команда из восьми человек на одной площадке или две команды по шесть на разных (Being On-Call). Если у вас всего шесть инженеров на весь продукт, вы не «делаете SRE неправильно» — вы находитесь вне области применимости рекомендации, и признать это полезнее, чем натягивать.

Нижний узел — не формальность. Разница между инженерным решением и карго-культом в том, что у первого записана причина. Через год причина изменится, и без записи вы не узнаете, какие решения устарели.

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

Формулировка «разбирайте без поиска виноватых» звучит как этическое пожелание, и поэтому её первой отменяют, когда всё горит. Механизм при этом чисто информационный.

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

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

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

Наблюдаемые индикаторы вырождения — их видно в самих документах:

• доля постмортемов, где первопричина сформулирована как «человеческая ошибка», растёт (в здоровом процессе она близка к нулю: человек — часть системы, а не её причина);
• раздел «хронология» становится короче, из него уходят фразы вида «я не понял, что означает эта метрика»;
• появляется пассивный залог без субъекта: «была применена конфигурация»;
• текст согласовывают до встречи.

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

Практический рецепт короткий. Разбор ведёт не автор изменения. Вопрос звучит «что вы видели в этот момент», а не «почему вы это сделали». Первый разбор, где основатель говорит «это была моя правка, и вот чего я не знал», делает для процесса больше, чем любой регламент. И каждая правка выходит с владельцем и сроком, иначе документ — литература. Развёрнуто — в главе 08; взгляд со стороны руководителя — в треке лидерства.

Цена: три сметы

Разговор о надёжности без сметы — не инженерный. Смет три, и они не сводятся друг к другу.

Смета в деньгах: сколько стоит минута, которую вы не потеряли

Возьмём профиль B: три сервиса, около 50 rps, счёт за инфраструктуру 850 USD в месяц (контейнеры 360, управляемый PostgreSQL в одной зоне 220, балансировщик 25, хранилище и трафик 80, мониторинг 150, округление). Дальше — три ступени избыточности. Для каждой считаем, сколько минут простоя в год она предотвращает, и делим годовую цену на минуты.

Ступень 1. Реплика БД в соседней зоне: +220 USD/мес = 2 640 USD/год
  отказ хоста БД 2 раза в год: ручное восстановление 60 мин → автофейловер 2 мин
      экономия 2 × 58 = 116 мин/год
  плановые обновления 4 раза в год по 15 мин окна → без окна
      экономия 60 мин/год
  итого ≈ 176 мин/год  →  2 640 / 176 = 15 USD за минуту

Ступень 2. Приложение в двух зонах с запасом ёмкости: +360 USD/мес = 4 320 USD/год
  отказ зоны раз в 18 месяцев (0,67 события в год), длительность ≈ 200 мин
      0,67 × 200 ≈ 135 мин/год  →  4 320 / 135 = 32 USD за минуту

Ступень 3. Второй регион, active-passive: +1 150 USD/мес = 13 800 USD/год
  отказ региона раз в 4 года (0,25 события в год), длительность ≈ 360 мин
      0,25 × 360 = 90 мин/год  →  13 800 / 90 = 153 USD за минуту

Для сравнения: валовая выручка 60 000 USD/мес = 60 000 / 43 200 = 1,39 USD за минуту

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

Прямое сравнение с выручкой убивает третью ступень: 90 минут в год стоят вам 125 USD упущенной валовой выручки, а защита от них — 13 800 USD. Но останавливаться на этом нельзя, потому что у среднего есть три поправки.

1. Пик. Отказ распределён не равномерно по трафику: чёрная пятница, рассылка, конец месяца. Множьте потерю на пиковый коэффициент — обычно 3–5.
2. Необратимое. Отток, штраф по договору, сорванная сделка, публикация в отраслевом чате. Это не выражается минутой выручки и часто в разы больше прямых потерь.
3. Разорение. Для маленькой компании потеря данных или суточный простой — не «дорогая минута», а конец. И вот тут ключевое: от этого сценария защищает не второй регион, а бэкапы с проверенным восстановлением за 30 USD в месяц.

Отсюда порядок, обратный интуиции. Сначала — защита от невосстановимого: бэкапы, проверка восстановления на пустом стенде с замером времени, отсутствие единой точки, из которой можно уничтожить всё (один админский ключ, одна учётка, одна команда terraform destroy без защиты — см. инфраструктуру как код и управление секретами). Потом — защита от частого: автофейловер БД. Потом — от редкого: зона, регион. Люди почти всегда делают наоборот, потому что второй регион звучит как инженерное достижение, а проверка бэкапа — как скучная задача на полдня.

Смета в людях: сколько стоит дежурство

Ротация из четырёх человек с недельными сменами означает, что каждый дежурит 52 / 4 = 13 недель в год, то есть четверть календаря. При полутора ночных срабатываниях в неделю это 19–20 разбуженных ночей на человека в год.

цена одной разбуженной ночи: сам инцидент 30–60 мин
   + разрушенный сон и сниженный следующий день
   консервативно ≈ 1 потерянный рабочий день суммарно

19,5 ночи × 4 человека = 78 человеко-дней в год
при 220 рабочих днях = 0,35 FTE
при команде из 6 инженеров — 5,9 % общей мощности

расширение ротации до 6 человек: 52 / 6 = 8,7 недели в год на человека
   ночей: ~13 вместо 19,5   →   нагрузка на человека −33 %, денег стоит ноль

Три вещи, которые из этого расчёта следуют и которые обычно проговариваются не полностью.

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

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

Здесь инженерное решение упирается в организационное, и притворяться не надо. Если дежурство не оплачивается деньгами или отгулом, оно оплачивается увольнениями — просто счёт приходит через полгода и на другую статью. Инженер этот вопрос не решает; он может только предъявить расчёт тому, кто решает. Расчёт выше и есть предъявление.

Смета во внимании: алерты без действия

Третья смета невидима, потому что не попадает ни в счёт от облака, ни в табель.

12 пейджей в неделю, из них 4 требуют действия  →  8 ложных
даже ложный требует посмотреть: ~15 мин с учётом возврата к работе
8 × 15 = 2 ч/нед = 8,7 ч/мес чистого времени

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

Удалить восемь бесполезных правил — два часа работы. Это освобождает около девяти часов в месяц и, что важнее, восстанавливает доверие к пейджеру. Лучший возврат на вложенное время во всём треке. Критерий отбора один и он из главы 05: алерт остаётся, если можно назвать конкретное действие дежурного в три часа ночи и это действие нельзя выполнить автоматически.

Три сметы вместе

Сложим их в одну картину — месячный бюджет времени команды из шести инженеров: 6 × 21 рабочий день × 8 часов = 1008 человеко-часов.

Главное на этой картинке — не проценты, а направление стрелки. Явная квота на надёжность (132 часа, 13 % мощности) выглядит как изъятие у фич, но оплачивается она исчезнувшей незапланированной работой: 210 часов операционки превращаются в 120, спад после ночных пейджей с 60 до 28, разбор шумных алертов с 48 до 8, ручные релизы с 90 до 30. Освободилось 222 часа, квота съела 132, фичи получили на 90 часов больше, чем было.

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

Роль без отдельной команды: три рабочих модели

Третью модель стоит посчитать, потому что её обычно отвергают по цене без арифметики.

управляемый PostgreSQL:  220 USD/мес
свой на виртуалке:       140 USD/мес
разница:                  80 USD/мес = 960 USD/год

что уезжает вместе с разницей: обновления версий, настройка репликации,
   бэкапы и их проверка, ночное восстановление, мониторинг самой БД
консервативная оценка: 4 часа в месяц = 48 часов в год

подставьте свою полную стоимость часа инженера
   (зарплата + налоги + накладные; во многих командах это 40–60 USD)
48 × 45 = 2 160 USD/год против 960 USD/год разницы

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

Если вас двое

Профиль A — не уменьшенная копия профиля B, а другая ситуация. Круглосуточное дежурство двумя людьми физически невозможно: это не «тяжело», это отсутствие второго уровня эскалации. Притворяться, что 99,9 % держится круглосуточно, — обещание, которое нарушится в первую же ночь.

Честный ход — SLO с окном:

Цель: с 09:00 до 21:00 по будням доля успешных запросов ≥ 99,5 %.
      Вне окна — best effort, реакция утром. Это записано и согласовано.

Бюджет: окно = 12 ч × 22 будних дня = 264 ч/мес = 15 840 мин
        0,5 % от 15 840 = 79,2 мин/мес

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

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

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

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

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

Тридцать дней: план, который реально проходят

Не «внедрить SRE», а четыре недели с проверяемым результатом каждой. Порядок важен: каждая следующая неделя опирается на предыдущую.

Что считается результатом каждой недели — проверяйте буквально:

1. Неделя 1. Вы узнаёте о недоступности главного пути раньше, чем первый пользователь напишет в поддержку. Проверка: выключите сервис на две минуты и засеките.
2. Неделя 2. Продакт может назвать вашу цель по памяти и знает, что означает её нарушение. Проверка: спросите.
3. Неделя 3. Любой из ротации может выполнить рунбук, не будя автора. Проверка: пусть выполнит днём, на стенде.
4. Неделя 4. Известно фактическое время восстановления из бэкапа — числом, а не «ну, наверное, час». Проверка: секундомер.

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

Уровни зрелости и переходы между ними

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

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

Антипаттерны внедрения

• Сначала инструменты. Стек наблюдаемости поставлен, SLO нет. Инструмент отвечает на вопрос, которого никто не задал. Порядок обратный: сначала вопрос, потом чем измерять.
• SLO на всё. Тридцать целей — это ноль целей: никто не помнит их и никто не принимает по ним решений. Одна цель, которую все знают, сильнее тридцати в вики.
• Заморозка релизов как автоматика. При одном продукте это остановка бизнеса, и её отменят на второй день, заодно обесценив весь механизм. Политика с явным исключением и подписью работает; автоматика — нет.
• «SRE — это тот, кто дежурит». Роль превращается в свалку: всё непонятное отправляют «эсэрию», он выгорает за квартал. Роль — про измерение и приоритеты, дежурство — общее.
• Постмортем как отчёт наверх. Документ, написанный для руководства, содержит формулировки для руководства и не содержит фактов, ради которых пишется.
• Копирование глав про чужую инфраструктуру. Раздел про балансировку между дата-центрами не о вас, если у вас один регион; дежурство без компенсации — тоже копирование, только с потерей той части, где за него платят.
• «Учения проведём, когда стабилизируемся». Стабильность — результат учений, а не условие для них. Начинать надо с малого: отключить одну реплику на стенде в среду в четырнадцать часов.
• Метрика ради метрики. Считать MTTR по трём инцидентам в квартал бессмысленно: доверительный интервал шире самого значения. При малой статистике смотрите на распределение и на худший случай, а не на среднее.

Библиотека: что читать, в каком порядке и что пропустить

Порядок, а не список — потому что порядок и есть главное.

Инструменты, которых достаточно профилю B и которые не требуют своей команды: Prometheus + Alertmanager + Grafana либо совместимый управляемый сервис; OpenTelemetry для трейсов и метрик из кода; внешняя проверка доступности (любой сторонний сервис, главное — снаружи); OpenSLO как формат описания целей и генераторы правил вроде Sloth или Pyrra, если не хочется писать выражения бюджета руками. Соседний разбор инструментов — в devops-треке и в главе про наблюдаемость распределённых систем.

Чек-лист самопроверки

Двенадцать вопросов. Отвечать «да» можно, только если ответ проверяем сегодня, а не «в принципе есть».

1. Мы узнаём о недоступности главного пути раньше пользователей — и это проверено выключением?
2. Внешняя проверка живёт вне нашей инфраструктуры?
3. Есть цель числом на главный путь, и продакт может назвать её по памяти?
4. Мы знаем остаток бюджета ошибок за текущий месяц прямо сейчас?
5. Каждый пейджерный алерт имеет действие, которое нельзя автоматизировать?
6. К каждому пейджеру есть рунбук, по которому справится не автор?
7. Известно, кто дежурит на этой неделе, и кто второй уровень эскалации?
8. Дежурство компенсируется деньгами или отгулом?
9. Последний инцидент дольше 15 минут разобран письменно, и правки имеют владельца и срок?
10. Мы измеряли время восстановления из бэкапа секундомером в этом квартале?
11. Мы можем откатить релиз одной командой, и кто-то делал это за последний месяц?
12. Наше SLO не выше произведения SLA зависимостей — или у каждой есть обход?

Меньше шести «да» — вы на L0/L1, и правильный следующий шаг ровно один: пункт 1. Девять и больше — вы на L3, и стоит подумать про учения, а не про новые инструменты.

Мини-итог

• Потолок доступности задан сверху произведением SLA зависимостей (в типовой установке — около 99,83 %, то есть 73 минуты в месяц) и снизу скоростью человека: ночной цикл около 27 минут делает 99,9 % верхней границей того, что держится людьми. Выше — только автоматика на заранее названный класс отказа.
• Пять девяток — 25,9 секунды в месяц: ни одного окна обслуживания, обнаружение за секунды, автоматический обход непредвиденного. Это не строка в смете, а другой продукт. Признак того, что они правда нужны: цена минуты измеряется не выручкой.
• Небольшой команде почти всегда важнее ограничить длину худшего инцидента, чем поднять среднюю доступность: быстрый откат стоит дня работы, второй регион — годового бюджета.
• Переносится дешёвое и меняющее решения: SLI на пользовательский путь, одно SLO с подписью продакта, 3–5 алертов, рунбуки, роль командира инцидента, безвинный разбор, флаги и откат. Не переносится всё, что опирается на вторую команду, на статистику редких событий или на собственный стек. Частично — канарейка: при 2 rps она ловит поломку в 1 % с вероятностью 97 % за час, а поломку в 0,3 % пропускает в трети случаев, поэтому долю увеличивают, окно считают в событиях, а вес переносят на скорость отката.
• Безвинный разбор — информационный механизм: обвинение делает рассказ небезопасным, детали уходят, правки мельчают, отказы повторяются, давление растёт. Усиливающая петля с задержкой в два-три инцидента, поэтому связь не замечают.
• Три сметы. Деньги: ступени избыточности стоят 15, 32 и 153 USD за предотвращённую минуту при минуте валовой выручки в 1,39 USD — но считать надо хвост, а не среднее, и первым делать бэкап с проверкой за 30 USD. Люди: ротация из четырёх — четверть календаря на человека, 0,35 FTE в год на команду, и платят её четверо конкретных. Внимание: восемь бесполезных пейджей в неделю — девять часов в месяц плюс потерянное доверие к пейджеру.
• Расширить ротацию с четырёх до шести — минус треть нагрузки на человека за ноль денег. Упирается в рунбуки, доступы и в то, что дежурство надо оплачивать. Это то место, где инженерное решение упирается в организационное, и написать об этом честно полезнее, чем изобретать техническую замену.
• Квота на надёжность оплачивается исчезнувшей незапланированной работой, но с задержкой в квартал. Не предупредить об этой задержке — гарантированно потерять квоту на третьей неделе.
• Зрелость не накапливается, а поддерживается расходом внимания: пятнадцать минут в неделю, час в квартал, полдня на учение — в календаре, а не в намерениях.

Источники

• Betsy Beyer et al. The Site Reliability Workbook, O’Reilly, 2018 — свободно доступна; главы про SLO и внедрение практичнее исходной книги.
• Betsy Beyer et al. Site Reliability Engineering, O’Reilly, 2016 — в частности Being On-Call с требованием к размеру команды и Introduction с правилом 50 %.
• Alex Hidalgo. Implementing Service Level Objectives, O’Reilly, 2020.
• Richard I. Cook. How Complex Systems Fail, 1998 — восемнадцать тезисов.
• John Allspaw. Blameless PostMortems and a Just Culture, Etsy Code as Craft, 2012.
• Sidney Dekker. The Field Guide to Understanding ‘Human Error’, 3rd ed., CRC Press, 2014.
• Michael Nygard. Release It!, 2nd ed., Pragmatic Bookshelf, 2018; AWS Builders’ Library — статьи о таймаутах, повторах и обходе отказов.
• PagerDuty Incident Response Documentation — открытый регламент ролей и связи в инциденте.
• Nathan Bronson et al. Metastable Failures in Distributed Systems, HotOS 2021.
• Casey Rosenthal, Nora Jones. Chaos Engineering, O’Reilly, 2020; записи докладов USENIX SREcon.
• OpenSLO, Sloth, Pyrra, OpenTelemetry — форматы и инструменты, с которых начинают.

Что дальше

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

Куда идти дальше, зависит от того, во что вы упёрлись.

• Упёрлись в конвейер и инфраструктуру — DevOps: стратегии выката, инфраструктура как код, стоимость облака.
• Упёрлись в «медленно» вместо «сломано» — производительность: измерение и хвосты, нагрузочное тестирование.
• Упёрлись в отказы узлов и согласованность — распределённые системы: модели отказов, репликация.
• Упёрлись в людей: ротацию, компенсацию, выгорание — инженерное лидерство и тех-долг как разговор с бизнесом.
• Упёрлись в то, что система ведёт себя не как сумма частей — системное мышление: петли обратной связи, задержки, точки воздействия.
• Смежное по ситуации: сеть и диагностика, тестирование производительности, секреты и доступы, репликация и шардирование БД.

Общая карта треков портала и порядок их прохождения — в дорожной карте.

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