SRE: что это и как соотносится с DevOps

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.

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

---

1. Что изучаем

• объяснять, что такое SRE и в каком смысле «class SRE implements interface DevOps» — где кончается философия DevOps и начинается конкретный набор практик;
• считать бюджет ошибок из целевого SLO и объяснять, почему цель «100 %» неверна;
• отличать toil от инженерной работы по шести признакам и оценивать его долю;
• называть, чем бюджет ошибок служит общим языком разработки и эксплуатации;
• видеть карту блока: какая практика сокращает toil, а какая тратит или защищает бюджет.

2. Зачем это нужно и где применяется

Блоки 12–14 дали инструменты: Kubernetes держит нужное число реплик, пробы решают, куда пускать трафик, метрики и логи показывают, что происходит. Но инструменты не отвечают на вопрос эксплуатации: насколько надёжным сервис должен быть и кто это решает. Без ответа команда живёт в двух крайностях. Либо «надёжность — не наша забота, катим что хотим», и сервис падает под нагрузкой. Либо «ничего не трогаем, вдруг сломается», и изменения замирают.

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

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

3. Теория (30 минут)

Откуда взялся SRE. Термин ввёл Бенджамин Трейнор Слосс в Google в 2003 году, и его определение осталось самым точным: «SRE is what happens when you ask a software engineer to design an operations team» — «SRE это то, что получается, когда инженера-программиста просят спроектировать команду эксплуатации». Ключевое слово — инженер: вместо того чтобы обслуживать систему руками, он пишет программы, которые делают это за него, и относится к эксплуатации как к задаче разработки со своими метриками и целями.

SRE и DevOps — не конкуренты и не синонимы. DevOps — это философия и культура: убрать стену между разработкой и эксплуатацией, автоматизировать, измерять, делиться. Её удобно свести к пяти опорам CALMS: Culture, Automation, Lean, Measurement, Sharing (культура, автоматизация, бережливость, измерение, обмен). Но CALMS говорит, что хорошо, и не говорит, как именно это делать. SRE даёт конкретный, «мнениевый» ответ. Google формулирует связь одной строкой: «class SRE implements interface DevOps» — SRE реализует интерфейс, который описывает DevOps. Из документации: «If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes.» То есть DevOps — интерфейс (что должно быть), SRE — одна из его реализаций (набор практик: SLO, бюджет ошибок, потолок на рутину, безобвинительные постмортемы, дежурства с правилами). Можно делать DevOps без SRE и по-другому реализовать те же принципы; SRE — проверенная в Google конкретика.

Надёжность — это функция, которую измеряют, а не ощущение. Отсюда первый неочевидный тезис: «100% is the wrong reliability target for basically everything» — сто процентов это неверная цель почти для всего (исключения — кардиостимуляторы и антиблокировочные тормоза). Причины две. Первая: разница между 99,9 % и 100 % пользователю почти не видна — на пути к нему и так есть Wi-Fi, мобильная сеть, его собственное устройство, каждое со своей надёжностью. Вторая: последние доли процента стоят непропорционально дорого и убивают скорость изменений. Поэтому цель задают ниже 100 % осознанно.

Бюджет ошибок. Как только цель установлена, появляется запас: «the error budget is one minus the availability target» — бюджет ошибок это единица минус целевая доступность. При SLO 99 % бюджет — 1 %: столько запросов (или времени) можно «потратить» на сбои, не нарушив обещание. Каждая добавленная девятка сокращает этот запас примерно в десять раз, и это видно в допустимом простое за 30-дневное окно (посчитано калькулятором урока):

SLO	Бюджет ошибок	Допустимый простой за 30 суток
99 %	1 %	7,2 часа
99,9 %	0,1 %	43,2 минуты
99,99 %	0,01 %	4,3 минуты

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

В блоке 16 бюджет уже измерялся на живом сервисе: при SLO 99 % и фактической доступности 95 % бюджет израсходован на 500 %, скорость сжигания (burn rate) равна 5, и месячный бюджет сгорает за шесть дней (урок 16.10). Burn rate — это отношение фактической доли ошибок к бюджету: при 1 бюджета хватает ровно до конца окна, при 5 он сгорает впятеро быстрее. Бюджет ошибок и есть общий язык двух ролей: пока он не исчерпан, разработка катит новое; когда исчерпан — по политике бюджета выкат новых функций останавливается, и силы идут на надёжность. Число, а не характер, решает спор.

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

SLI, SLO и SLA — три разные вещи, которые постоянно путают. SLI (Service Level Indicator) — измеренная величина, например доля успешных запросов: не-5xx / все из блока 16. SLO (Objective) — внутренняя цель по этому индикатору, например «SLI не ниже 99 % за 30 дней»; именно из SLO считается бюджет ошибок. SLA (Agreement) — внешнее обещание клиенту с последствиями за нарушение (возврат денег, штраф). Правило: SLO всегда строже SLA — цель ставят с запасом, чтобы успеть среагировать до того, как нарушится обещание с санкцией. В учебном курсе и в большинстве внутренних сервисов SLA нет вовсе, а SLI и SLO есть всегда.

Toil — рутина, которая не даёт расти. Второе центральное понятие. Определение Google дословно: «Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.» Шесть признаков:

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

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

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

Потолок на рутину. Отсюда практическое правило: «Google places a 50% cap on the aggregate "ops" work for all SREs — tickets, on-call, manual tasks, etc.» — на всю эксплуатационную работу SRE отводится не больше половины времени, остальное уходит на инженерию, которая эту работу сокращает. Без потолка инженерия «на потом» не наступает никогда, и toil съедает всё.

Карта блока. Дальше девять уроков раскладывают эти понятия на практику. SLO и политика бюджета (17.02) — как задать цель и что делать с бюджетом. Дежурства (17.03), управление инцидентами (17.04) и безобвинительные постмортемы (17.05) — как тратить бюджет с наименьшей болью и учиться на сбоях. Runbooks (17.06) — как превратить разбор в повторяемую процедуру и снять toil. Отказоустойчивость (17.07: таймауты, повторы, circuit breaker), нагрузочное тестирование (17.08) и chaos engineering (17.09) — как заранее защитить бюджет, найдя слабые места до пользователя.

3.1. Примеры и варианты реализации

SRE — это прежде всего организационная практика: сами понятия (SLO, бюджет, toil) от среды не зависят. Различается инструментарий, которым берут числа для SLI. Считать бюджет ошибок нужно из фактических метрик, а не на глаз, и способ их получить у каждой среды свой.

Среда	Как решается	Что нужно иметь
Локальный стенд (Docker / VM / kind)	Prometheus в кластере (блок 16), SLI как доля не-5xx, бюджет считается по запросам	kind + стек наблюдаемости, error-budget.py
VPS / bare-metal	node_exporter + Prometheus либо аптайм-пробер снаружи; SLI по логам балансировщика или по внешним проверкам	сервер мониторинга, доступ к логам/метрикам сервиса
Yandex Cloud	Managed Prometheus / Monitoring: метрики сервиса и балансировщика, SLI по кодам ответа ALB	включённый мониторинг, дашборд или запрос к метрикам

Локальный стенд. Стенд блока 16 (kind + course-obs-app:1 + Prometheus) уже даёт SLI: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])). Это и есть вход для бюджета ошибок; в 17.02 мы посчитаем его на живых метриках.

VPS / bare-metal. SLI берут либо изнутри (экспортёр метрик приложения), либо снаружи (внешний пробер бьёт по /health и считает долю успешных). Внешняя проверка честнее отражает опыт пользователя, но видит только то, что доступно снаружи.

Yandex Cloud. Managed-сервисы отдают коды ответа балансировщика и метрики нагрузки; SLI считается тем же PromQL, что и на стенде, только источник — облачный Prometheus. Замером в этом уроке не проверялось (обзорный урок; облако задействуется в блоках, где оно нужно) — по документации Yandex Monitoring.

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

4. Практика на занятии (30 минут)

Курс проходят самостоятельно, поэтому каждый шаг говорит, что сделать, зачем, что должно получиться и что делать при неудаче. На бумаге и калькуляторе разбираем два центральных понятия: считаем бюджет ошибок для разных целей и проводим аудит toil. Кластер не нужен — только python3 на хозяине. Опыты — в 17.01-sre-overview/.

Шаг 1 (10 минут). Во что превращается цель в допустимый простой.

• Что ввести:

cd blocks/17-reliability-sre/examples/17.01-sre-overview
for slo in 0.99 0.999 0.9999; do
  python3 error-budget.py --slo $slo --window-days 30 | sed -n '2,4p'; echo
done

• Зачем: увидеть числом, а не на слух, почему «ещё одна девятка» стоит так дорого — переход к более жёсткой цели урезает допустимый простой примерно на порядок, и это видно на трёх целях подряд.
• Ожидаемый результат: три блока вывода: бюджет 1 % (SLO 99 %) даёт допустимый простой 7,2 ч за месяц; 0,1 % (99,9 %) — 43,2 мин; 0,01 % (99,99 %) — 4,3 мин. Каждая девятка сокращает запас примерно в десять раз.
• Если не так: если скрипт не запускается («command not found» или «No such file») — проверьте, что вы в каталоге examples/17.01-sre-overview и файл исполняемый (chmod +x error-budget.py либо запускайте через python3 error-budget.py); если числа не совпадают с ожидаемыми — проверьте, что передали --window-days 30, а не значение по умолчанию.
• Ответьте: во сколько раз примерно сокращается допустимый простой при каждой следующей девятке?

Шаг 2 (5 минут). Бюджет на числах из урока 16.10.

• Что ввести:

python3 error-budget.py --slo 0.99 --sli 0.95 --window-days 30

• Зачем: повторить расчёт, который в 16.10 был сделан по живым метрикам, и убедиться, что калькулятор даёт тот же вывод — burn rate и предупреждение о перерасходе решает измеренное число, а не мнение.
• Ожидаемый результат: строки Бюджет потрачен на: 500%, Скорость сжигания: 5.00 и предупреждение «бюджет ПРЕВЫШЕН, сгорит за ~6.0 сут вместо 30».
• Если не так: если вывод показывает «в пределах бюджета» — проверьте, что --sli меньше --slo (0.95 < 0.99); перепутанные местами значения дают обратную картину.
• Ответьте: замените --sli 0.95 на --sli 0.999 — что изменилось в выводе и почему то же приложение теперь «в пределах бюджета»?

Шаг 3 (10 минут). Аудит toil.

• Что сделать: откройте toil-audit.md и заполните таблицу по шести задачам эксплуатации — возьмите из своей практики или из курса (например: перезапустить зависший под руками; вручную выкатить релиз по ssh; разобрать новый, невиданный инцидент; продлить сертификат руками; написать автоматизацию продления; ответить на однотипный тикет). По каждой задаче поставьте «да»/«нет» в шести колонках признаков и решите в последней колонке, toil это или инженерия.
• Зачем: применить шесть признаков toil (§3) не к абстрактному примеру, а к конкретным задачам, и увидеть, что решение не по ощущению «это рутина», а по совпадению признаков.
• Ожидаемый результат: заполненная таблица на шесть строк; у «разобрать новый инцидент» и «написать автоматизацию продления» в колонке «Toil?» стоит «нет» — у них есть долгая ценность; у «перезапустить под руками», «ручной выкат по ssh», «продлить сертификат руками» и «однотипный тикет» — «да».
• Если не так: если в задаче стоит «да» ровно в половине колонок и решение неочевидно — перечитайте §3: решающий признак обычно «без долгой ценности» (после задачи сервис в том же состоянии, что и был) и «растёт линейно» (задача умножается вместе с числом сервисов).
• Ответьте: какая из ваших шести задач ближе всего к toil по всем признакам сразу, и что нужно, чтобы убрать её полностью, а не просто ускорить?

Что обсудить в конце занятия. Разработчик хочет добавить в метрику метку user_id, чтобы «видеть каждого пользователя». Что вы ответите и почему?

5. Домашняя работа (1–2 часа)

Задание. Провести аудит надёжности одного сервиса — учебного (course-obs-app из блока 16) или любого знакомого — и оформить два документа.

1. Заполните toil-audit.md: не меньше шести реальных задач эксплуатации, разметка по шести признакам, оценка доли toil в процентах и три задачи с наибольшим toil с предложением, чем их заменить.
2. Заполните error-budget-worksheet.md: выберите SLO и окно, посчитайте бюджет и допустимый простой через error-budget.py, впишите фактический SLI (можно взять измеренный в 16.10 или задать свой), посчитайте burn rate и — обязательно — заполните политику бюджета: что команда делает, когда бюджет есть, и что останавливает, когда он исчерпан.

Критерии приёмки.

• toil-audit.md заполнен: не менее 6 задач, у каждой размечены все шесть признаков и вывод «toil да/нет», указана оценка доли toil в процентах;
• в аудите есть три задачи с наибольшим toil и для каждой — чем её заменить (автоматизация или устранение);
• error-budget-worksheet.md содержит SLO, бюджет ошибок и допустимый простой, полученные прогоном error-budget.py (числа сходятся с выводом команды);
• в worksheet заполнена таблица политики бюджета — оба столбца (что разрешено и что останавливается) для состояний «бюджет есть» и «бюджет исчерпан»;
• в выводе worksheet одной фразой сказано, чего сервису сейчас не хватает — надёжности или скорости изменений.

Файлы для работы: blocks/17-reliability-sre/examples/17.01-sre-overview/

6. Частые ошибки и подводные камни

• Цель «100 % надёжности». Симптом: в требованиях стоит «сервис должен работать всегда». Причина: надёжность считают абсолютной, а не мерой. Что делать: задать SLO ниже 100 % осознанно; последняя девятка стоит непропорционально дорого и не видна пользователю за его же сетью и устройством.
• SLO без политики. Симптом: цель записана, но при её нарушении ничего не происходит. Причина: SLO приняли за число, а не за договор. Что делать: к каждому SLO писать политику бюджета — что останавливается, когда бюджет исчерпан (это и делает урок 17.02).
• «SRE — это переименованная эксплуатация». Симптом: та же ручная работа под новым названием, дежурные тонут в тикетах. Причина: пропущен потолок на toil и инженерная половина времени. Что делать: держать долю эксплуатации не выше ~50 % и тратить остальное на автоматизацию.
• Считать всю эксплуатацию toil. Симптом: разбор инцидентов и проектирование записывают в «рутину на удаление». Причина: путают тактическую повторяющуюся работу с инженерной. Что делать: сверяться с шестью признаками — у инженерии есть долгая ценность, у toil её нет.
• Бюджет ошибок как наказание. Симптом: исчерпанный бюджет используют, чтобы искать виноватых. Причина: инструмент договорённости превратили в кнут. Что делать: бюджет — общий сигнал «пора вложиться в надёжность», а не повод для разбора личностей (разбор — безобвинительный, урок 17.05).
• Путаница SLI / SLO / SLA. Симптом: в разговоре смешивают меру, цель и договор с санкцией. Что делать: SLI — измеренная величина (доля успешных), SLO — внутренняя цель по ней, SLA — внешнее обещание с последствиями за нарушение; SLO всегда строже SLA.

7. Проверка усвоения

1. Как связаны SRE и DevOps? Что означает «class SRE implements interface DevOps»?
2. Почему «100 % надёжности» — неверная цель почти для любого сервиса? Приведите обе причины.
3. Что такое бюджет ошибок и как он считается из SLO? Сколько это в минутах простоя за 30 дней при SLO 99,9 %?
4. Назовите шесть признаков toil. Чем toil отличается от инженерной работы по эксплуатации?
5. Зачем нужен потолок ~50 % на эксплуатационную работу? Что происходит без него?
6. Как бюджет ошибок примиряет спор «катить быстро» против «ничего не трогать»?
7. Чем SLI отличается от SLO и от SLA?
8. burn rate равен 5 при SLO 99 %. Что это значит для месячного бюджета и что должна сделать команда?

8. Материалы

Минимум два варианта на выбор: официальная документация плюс книга/статья/видео.

• Google SRE Book, глава «Introduction» — sre.google/sre-book/introduction/. Первоисточник определения SRE, потолка 50 % и бюджета ошибок; отсюда взяты дословные цитаты урока. Читать всем как отправную точку.
• Google SRE Workbook, «How SRE Relates to DevOps» — sre.google/workbook/how-sre-relates/. Разбор связи SRE и DevOps и формулы «class SRE implements interface DevOps»; полезно тем, кто уже знает DevOps и хочет увидеть стык.
• Google SRE Book, глава «Eliminating Toil» — sre.google/sre-book/eliminating-toil/. Полное определение toil, шесть признаков и как его сокращать. Для практической части урока и домашней работы.
• Все книги серии (бесплатно онлайн) — sre.google/books/. Site Reliability Engineering, The Site Reliability Workbook и Building Secure & Reliable Systems; справочник на весь блок.

---

← Предыдущий: 16.10. SLI, SLO и бюджет ошибок на практике · Блок 17 · Следующий: 17.02. SLO на практике и политика бюджета ошибок →