SLI, SLO, SLA

Три буквы, которые управляют продакшеном

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

Индикатор уровня сервиса (SLI): измерение поведения сервиса. Примеры: задержка запросов, частота ошибок, пропускная способность, глубина очереди. SLI — это то, что можно отобразить на графике.

Цель уровня сервиса (SLO): целевое значение или диапазон для SLI. Пример: «99,9 % HTTP-запросов успешно обрабатываются за скользящий период 28 дней». SLO — это обещание, которое вы даёте себе и пользователям относительно приемлемого качества сервиса.

Соглашение об уровне сервиса (SLA): контрактное обязательство, обычно с финансовыми штрафами за нарушение. Пример: «Мы возвращаем 10 %, если месячная доступность падает ниже 99,9 %». SLA — это обещание, подкреплённое юристами.

Ключевое отличие: ваше SLA всегда должно быть мягче, чем SLO. Если вы ставите внутреннюю цель 99,9 %, а внешний контракт тоже 99,9 %, у вас нет запаса. SRE обычно устанавливают SLO на одну девятку строже SLA: цель 99,95 %, контракт 99,9 %. Этот зазор покрывает неизбежные плохие недели.

Error Budgets: The Inverse SLO

От целей надёжности к инженерным решениям

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

Если SLO обещает 99,9 % успешных запросов за 28 дней, то error budget составляет 0,1 % запросов, или примерно 40 минут полного простоя в месяц. Этот бюджет можно тратить по своему усмотрению: на плановые релизы, экспериментальные фичи, chaos engineering или на работу с ненадёжными зависимостями.

Error budgets снимают конфликт между разработкой и эксплуатацией. Без бюджета каждый инцидент превращается в спор о том, кто виноват и как предотвратить повторение. С бюджетом:

- Бюджет есть: можно быстрее выпускать фичи, идти на больший риск, проводить эксперименты. Бюджет это оплачивает.

- Бюджет исчерпан: прекращаем запуск новых фич, замораживаем рискованные изменения, сосредотачиваемся на работе по повышению надёжности, пока бюджет не восстановится.

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

Определение Toil

Что считается Toil

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

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

Примеры, которые считаются toil:

- Ручной перезапуск сервиса после падения из-за утечки памяти

- Вставка фрагментов логов в чат во время разбора инцидента

- Заполнение формы тикета для создания новой базы данных

- Ручной запуск ежеквартального отчёта по ёмкости

- Одноразовое одобрение обычных запросов на развёртывание

Правило пятидесяти процентов ограничивает toil половиной рабочего времени SRE. Если toil превышает 50 %, команда должна вернуть ответственность продуктовой команде или нанять дополнительных инженеров, но цель остаётся неизменной: свести toil к нулю, заменив его инженерными системами, которые выполняют ту же работу без участия человека.

Автоматизация не просто экономит время. Она полностью устраняет целый класс человеческих ошибок. Скрипт, который разворачивает базу данных, не пропустит шаги после долгой смены.

Обоснование аудита toil

Ваша команда отслеживает, как тратится её время. В прошлом квартале распределение было таким: 30 % — развёртывания, 25 % — реагирование на инциденты, 20 % — работа с ёмкостью, 15 % — разработка фич, 10 % — разовые запросы от продуктовых команд.

Гигиена дежурств

Инженеры, а не пейджеры

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

Здоровые дежурные ротации следуют нескольким принципам:

- Компенсируемое время: часы дежурства конвертируются в отгулы, дополнительную оплату или аналогичную компенсацию. Бесплатное дежурство приводит к выгоранию команды.

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

- Бюджет на количество пейджей: книга SRE от Google рекомендует максимум два пейджинга за двенадцатичасовую смену. При превышении команда должна вкладывать инженерное время в снижение количества алертов, а не просто терпеть их.

- Только actionable-алерты: каждый пейдж должен требовать действий человека. Если пейдж будут игнорировать, автоматизировать или он срабатывает регулярно при нормальной работе, он не должен существовать. Алерт-фатиг — это дефект надёжности.

- Follow-the-sun handoff: глобально распределённые команды передают смены по границам часовых поясов, чтобы никто не получал пейдж в 3 часа ночи, если система действительно может подождать до утра.

Blameless Postmortems

Как инциденты превращаются в улучшения

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

Blameless означает, что документ относит причины сбоев к системам и процессам, а не к отдельным людям. Если инженер выполнил неверную команду, постмортем спрашивает: почему система позволила выполнить эту команду? Почему не сработала защита? Какое изменение системы, документации или инструментов предотвратит повторение той же ошибки следующим инженером?

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

Постмортемы обычно включают:

- Summary: однопараграфное описание инцидента и его влияния

- Timeline: поминутная реконструкция с временными метками

- Анализ первопричин: технические и процессные факторы, которые привели к сбою

- Обнаружение: как команда узнала об инциденте и сколько времени это заняло

- Устранение: действия, предпринятые для восстановления сервиса

- Выводы: что сработало, а что нет

- Пункты действий: конкретные, закреплённые за владельцами и ограниченные по времени инженерные задачи

Пункты действий хранятся в трекере. Они приоритизируются как любая другая инженерная работа. Постмортемы без пунктов действий превращаются в рассказывание историй. Работа ничего не меняет.

Четыре золотых сигнала

Что должен измерять каждый сервис

Книга SRE от Google предлагает четыре сигнала, которые должна предоставлять каждая пользовательская служба: задержка, трафик, ошибки и насыщение. Вместе они описывают состояние сервиса с точки зрения пользователя. Мониторинг с меньшим количеством сигналов оставляет слепые зоны; мониторинг сотен метрик приводит к усталости от алертов.

Задержка: сколько времени занимают запросы. Отслеживайте распределения, а не средние значения. p50 (медиана) описывает типичный опыт. p99 описывает худший 1 % пользователей. Среднее значение скрывает длинные хвосты: сервис со средним значением 50 мс и p99 5 000 мс выглядит нормально по среднему, но портит опыт одному пользователю из ста.

Трафик: нагрузка на сервис. Для веб-сервиса это запросы в секунду. Для стримингового сервиса — одновременные подключения. Для пакетной задачи — обработанные элементы в минуту. Трафик коррелирует с решениями по ёмкости и выявляет аномалии нагрузки.

Ошибки: доля неудачных запросов. Считаются явные сбои (HTTP 500), неявные сбои (HTTP 200 с повреждёнными данными) и нарушения политики (ответ слишком медленный для выполнения SLO). Важно различать их: ответ 200 с некорректными данными часто вредит пользователям сильнее, чем честный 500.

Насыщение: насколько загружена система. Использование CPU, глубина очередей, давление памяти, заполненность пула соединений. Насыщение предсказывает будущую задержку: система на 95% CPU имеет очень мало запаса, прежде чем задержка для пользователей резко вырастет.

Большинство оповещений SRE основаны на этих четырёх сигналах. Оповещение по симптомам (когда пользователи заметят проблему) эффективнее оповещения по причинам (когда CPU превышает 80%). Четыре золотых сигнала описывают симптомы.

Карьерные пути SRE

Где востребованы навыки SRE

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

SRE инфраструктуры: строит платформы, на которых работают другие команды. Kubernetes, service mesh, внутреннее облако. Глубокая системная инженерия, теория распределённых систем и дизайн платформ. Очень хорошо оплачивается в крупных компаниях, потому что работа масштабируется: один SRE инфраструктуры поддерживает сотни продуктовых инженеров.

Встроенный SRE: работает в паре с продуктовой командой инженеров, повышая надёжность конкретного сервиса. Наполовину инженер, наполовину коуч. Сильные навыки коммуникации и code review важны не меньше технической глубины. Часто лучший путь для инженеров, которым нравится обучать.

Инструментарий надёжности: строит стек наблюдаемости — мониторинг, алертинг, дашборды, инструменты постмортемов, платформы управления инцидентами. Много работы с фронтендом и данными. Результаты используют все остальные команды.

Production engineering: термин Facebook/Meta для SRE, фокусирующегося на capacity, деплое и управлении трафиком. Много работы с сетями и системами.

Технические сертификаты, которые стоит получить: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional и сертификаты CNCF (Kubernetes Administrator, Kubernetes Application Developer) подтверждают навыки работы с облачно-нативными технологиями. Сертификаты Linux Foundation подтверждают глубокие знания систем. Ни один из них не заменяет портфолио, но они помогают пройти отбор у рекрутеров.

Подведение итогов

Что вы теперь знаете

Site reliability engineering зародилась в Google как ответ на проблему масштабирования и превратилась в дисциплину, которую теперь применяют по всей индустрии. Вы изучили:

- Переход от ручных операций к проектируемой надёжности

- SLI, SLO, SLA и концепцию error budget как обратную сторону SLO

- Определение toil, правило 50 % и снижение toil через инженерные подходы

- Устойчивые дежурства и практика blameless postmortems

- Четыре золотых сигнала как отправная точка для мониторинга сервисов

- Карьерные треки SRE и сертификаты, открывающие двери

Две идеи важнее всего. Надёжность — это число, согласованное заранее. И тоил — это дефект, а не описание должности. Если вы запомните эти две мысли, всё остальное в SRE вытекает естественным образом.

Рекомендуемая литература: книга Google SRE (бесплатно онлайн: sre.google/books/), SRE Workbook для практических упражнений и статьи Charity Majors об observability. Урок geometry-of углубляется в визуальную структуру, лежащую в основе практики SRE: распределения задержек, конусы бюджетов ошибок, графы зависимостей и макеты дашбордов.