6.1 Индикаторы, цели уровня сервиса и бюджеты ошибок

Обзор и мотивация

Инженерия надёжности сайта (SRE), дисциплина, впервые разработанная в Google и задокументированная в книге Site Reliability Engineering, внесла словарь, на который эта тема опирается напрямую: индикатор уровня сервиса (SLI) это напрямую измеренный сигнал здоровья сервиса, задержка запроса, доля ошибок, доступность. Цель уровня сервиса (SLO) это целевой диапазон для этого индикатора, 99,9% запросов успешны в течение 200 миллисекунд, например. А бюджет ошибок это допустимое отклонение, 0,1% запросов, которым разрешено не пройти, рассматриваемое не как дефект для устранения, а как расходуемый ресурс, который можно использовать сознательно для принятия риска: отгрузки рискованного изменения, проведения эксперимента, или просто принятия того, что совершенная надёжность не достижима и, за определённой точкой, не стоит своей стоимости.

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

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

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Никакой формальной SLO (неявное «максимально надёжно, насколько возможно»)	Никаких накладных расходов на настройку	Бесконечные, необоснованные переговоры между скоростью и стабильностью; никакого общего правила
Амбициозная, очень высокая SLO (99,99%+)	Сигнализирует серьёзность относительно надёжности	Часто ненужная стоимость; убывающая отдача за пределами того, что фактически замечают пользователи
SLO, основанная на доказательствах и обоснованная пользовательским опытом	Отражает подлинную ценность; защитима и достижима	Требует реальных данных и анализа для правильной установки
Бюджет ошибок с заранее определённым ответом на исчерпание	Устраняет специальные переговоры; объективное, быстрое принятие решений	Требует организационной поддержки и дисциплины, чтобы фактически соблюдать заранее определённое правило

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

Вопросы для обсуждения в команде

Обоснована ли наша текущая SLO доказательством того, что фактически замечают пользователи, или она была установлена амбициозно, потому что высокое число ощущалось подобающе серьёзным? Проследите происхождение вашей текущей цели, если можете, и честно оцените, отражает ли она реальное пользовательское исследование или одну лишь инженерную интуицию.
Есть ли у нас заранее определённый, согласованный ответ на исчерпание бюджета ошибок, или компромисс пересматривается каждый раз, когда это происходит? Если честный ответ второе, этот пробел стоит закрыть до того, как следующий инцидент вынудит спор под давлением.
Тратится ли наш бюджет ошибок когда-либо фактически сознательно, на изменение с просчитанным риском или эксперимент, или он только когда-либо потребляется случайно через инциденты? Бюджет, никогда не тратящийся сознательно, может указывать на чрезмерно осторожную команду, упускающую законные возможности, для которых бюджет существует.
Измеряются ли наши SLI из подлинного пользовательского опыта, или из внутреннего здоровья системы, которое может не отражать то, с чем фактически сталкиваются пользователи? Проверьте вашу текущую инструментацию против этого конкретного различия; это распространённый пробел даже в в остальном зрелых программах надёжности.
Когда мы в последний раз пересматривали нашу SLO против текущего доказательства, и изменилось ли что-то, ожидания пользователей, архитектура системы, бизнес-приоритеты, что оправдало бы её пересмотр? Если вы не можете вспомнить недавний пересмотр, это отсутствие само по себе стоит обсудить.
Во что обошлось бы нам, в инженерном усилии, поднять нашу текущую SLO на одну дополнительную «девятку» надёжности, и была бы эта стоимость оправдана какой-либо подлинной пользовательской выгодой? Эта конкретная формулировка затрат и выгод помогает обосновать напряжение амбиции против достижимости реальными числами, а не абстрактным предпочтением.

Отраслевой взгляд

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

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

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

Государство. Цели надёжности государственного сектора для критической инфраструктуры иногда несут правовой или регуляторный вес, а нереалистичная, недостигнутая цель, обнаруженная во время аудита или публичного инцидента, значительно повреждает институциональное доверие. Устанавливайте цели на основе подлинной, задокументированной потребности пользователей и миссии, и будьте публично прозрачны о сознательном компромиссе, который представляет бюджет ошибок, а не подразумевайте недостижимый стандарт совершенства.

Примеры

Корпорация. Компания облачного хранения годами нацеливалась на «максимальное время работы» без формальной SLO, что приводило к хроническому, неразрешённому напряжению между продуктовой командой (хотевшей отгружать функции быстро) и инфраструктурной командой (хотевшей максимальной осторожности), заново оспариваемому на каждой встрече по планированию релиза. Принятие формальной SLO доступности 99,95% с явным бюджетом ошибок и заранее определённой политикой, работа над функциями автоматически приостанавливается, когда бюджет исчерпан, полностью разрешило повторяющиеся переговоры: обе команды могли видеть одно и то же число и соглашаться на одно и то же правило, и компания сообщила об измеримом увеличении отгруженных функций в периоды здорового бюджета наряду с измеримым, сознательным замедлением в течение двух периодов следующего года, когда бюджет был подлинно исчерпан, именно так, как и предполагала политика.

Государство. Система общественных предупреждений национальной метеослужбы годами работала под неформальным ожиданием «всегда доступна», без задокументированной цели и значительным, неадресованным операционным стрессом на дежурную команду, пытающуюся соответствовать невысказанному, фактически невозможному стандарту. Недавно принятая формальная SLO, доступность 99,9% с ясно сообщённым публичным объяснением бюджета ошибок, дала операционной команде явное, защитимое разрешение планировать окна планового обслуживания в рамках бюджета, то, что предыдущее невысказанное ожидание «всегда доступна» делало политически трудным сделать, даже когда это было подлинно необходимо для долгосрочного здоровья системы. Публичная коммуникация, напрямую объясняющая концепцию бюджета ошибок, а не скрывающая её, была воспринята благоприятно как признак честной, зрелой операционной практики, а не ослабления обязательства к качеству сервиса.

Бизнес-кейс: мотивация, ROI и TCO

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

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

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Инициация: Цели надёжности неявны или амбициозны, без формально определённой SLO, SLI или бюджета ошибок.
Уровень 2, Развитие: У некоторых сервисов есть неформальная SLO, но SLI могут не отражать подлинный пользовательский опыт, и нет заранее определённой политики исчерпания.
Уровень 3, Стандартизация: SLO, основанные на доказательствах, с подлинными SLI пользовательского опыта и заранее определённой политикой исчерпания бюджета ошибок установлены последовательно по критическим сервисам.
Уровень 4, Управление: Бюджеты ошибок активно и сознательно тратятся на просчитанное принятие риска, а SLO пересматриваются и пересматриваются с регулярной, основанной на доказательствах каденцией.
Уровень 5, Оркестрация: SLO и бюджеты ошибок интегрированы по всей организации как общий, объективный механизм для балансирования скорости и стабильности, а организация может указать на конкретные решения, которые обеспечил этот фреймворк, которые необоснованные переговоры не разрешили бы так же эффективно.

Идеи для обсуждения

Обоснована ли наша текущая SLO доказательством или амбицией?
Есть ли у нас заранее определённый ответ на исчерпание бюджета ошибок, который мы фактически соблюдали бы под давлением?
Когда мы в последний раз сознательно тратили здоровый бюджет ошибок на просчитанный риск?
Измеряют ли наши SLI подлинный пользовательский опыт или удобные внутренние проверки здоровья?
Во что обошлось бы нам поднять нашу SLO на одну дополнительную «девятку», и была бы эта стоимость оправдана?

Основные выводы

Индикатор уровня сервиса (SLI) измеряет подлинный пользовательский опыт; цель уровня сервиса (SLO) это её основанная на доказательствах цель; бюджет ошибок это сознательно расходуемое допустимое отклонение.
100% надёжность обычно неправильная цель; обосновывайте вашу SLO тем, что фактически замечают пользователи и сколько подлинно стоит каждое дополнительное приращение.
Относитесь к бюджету ошибок как к расходуемому ресурсу с заранее определённым ответом на исчерпание, устраняя необходимость пересматривать скорость против стабильности под давлением каждый раз.
Измеряйте SLI из подлинного пользовательского опыта, а не только удобных внутренних проверок здоровья.
Пересматривайте и пересматривайте SLO периодически, на основе доказательств, поскольку устаревшая цель теряет свою полезность по мере того, как меняются система и её пользователи.

Источники и дальнейшее чтение

Site Reliability Engineering: How Google Runs Production Systems, под редакцией Бетси Бейер, Криса Джонса, Дженнифер Петофф и Найалла Ричарда Мёрфи (основополагающий текст, определяющий SLI, SLO и бюджеты ошибок).
The Site Reliability Workbook, под редакцией Бетси Бейер, Найалла Ричарда Мёрфи, Дэвида К. Ренсина, Кента Кавахары и Стивена Торна (практическое руководство по внедрению SLO и бюджетов ошибок).
Implementing Service Level Objectives, Алекс Идальго (всеобъемлющее, ориентированное на практика руководство по проектированию и операционализации SLO).
Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким (связь между практикой надёжности и производительностью поставки).

6.1 Индикаторы, цели уровня сервиса и бюджеты ошибок

Обзор и мотивация

Ключевые принципы

Рекомендации

Выбирайте SLI, отражающие подлинный пользовательский опыт

Устанавливайте цель SLO на основе того, что фактически нужно пользователям, а не произвольного круглого числа

Относитесь к бюджету ошибок как к расходуемому ресурсу с заранее определённым ответом на исчерпание

Используйте бюджет ошибок для сознательных, информированных решений о риске

Пересматривайте и пересматривайте SLO периодически, на основе доказательств, а не инерции