SLO и error budget: как договориться о надежности без бесконечных алертов

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

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

Для этого и нужны SLO и error budget. SLO помогает договориться о целевом уровне надежности, а error budget показывает, сколько ошибок команда может позволить себе за период без нарушения этой договоренности. Это не модные слова из SRE, а удобный язык для разговора между разработкой, QA, DevOps, SRE, продуктом, поддержкой и руководством. Хороший SLO переводит абстрактное «сервис должен работать стабильно» в измеримое условие. Хороший бюджет ошибок переводит абстрактное «нельзя ломать прод» в конкретное правило принятия решений.

Эта статья объясняет простым языком, что такое SLO, SLI, SLA и error budget, как выбрать метрики надежности, как настроить алерты без шума, как договориться с продуктом и бизнесом, как использовать бюджет ошибок при релизах и как не превратить SLO в еще одну таблицу, которую никто не открывает. Материал полезен QA-инженерам, разработчикам, DevOps, SRE, тимлидам, продакт-менеджерам и всем, кто отвечает за качество сервиса в реальной эксплуатации.

Почему надежность нельзя обсуждать словами «просто сделайте стабильно»

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

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

SLO помогает снять часть этого конфликта. Команда не спорит о чувствах, а договаривается о пользовательском результате. Например, не «сервер должен быть жив», а «99,9% запросов на создание заказа должны завершаться успешно за 30 дней». Не «поиск должен быть быстрым», а «95% поисковых запросов должны получать ответ быстрее 800 миллисекунд». Не «интеграция не должна падать», а «99,5% webhook-событий должны быть доставлены и обработаны в течение пяти минут».

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

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

Что такое SLI, SLO, SLA и error budget

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

SLI отвечает на вопрос: «Что мы измеряем?» SLO отвечает на вопрос: «Какой уровень считаем приемлемым?» SLA отвечает на вопрос: «Что обещаем внешнему клиенту и что будет, если не выполним?» Error budget отвечает на вопрос: «Сколько риска у нас осталось?»

Самая частая ошибка при внедрении SLO состоит в том, что команда начинает с цифры. Например, кто-то говорит: «Давайте сделаем 99,99%, звучит надежно». Но четыре девятки могут быть избыточными, дорогими и вредными для скорости разработки. Чем выше целевая надежность, тем меньше пространства для экспериментов, миграций, релизов и внутренних ошибок. Иногда продукту достаточно 99,5%, если пользователь легко повторяет действие и не теряет деньги. Иногда даже 99,95% мало, если речь идет о платежах, авторизации, медицинских данных, критичных B2B-интеграциях или инфраструктуре для других команд.

Начинать лучше не с красивой цифры, а с пользовательского сценария. Какие действия важны? Что пользователь теряет при сбое? Как быстро он замечает проблему? Есть ли обходной путь? Сколько денег, доверия или времени стоит ошибка? Ответы на эти вопросы дают основу для SLO.

Зачем нужен error budget и почему он лучше бесконечного запрета на ошибки

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

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

Пример: сервис обрабатывает 10 000 000 запросов к критичному API за 30 дней. SLO равен 99,9% успешных ответов. Значит, error budget составляет 10 000 неуспешных запросов за месяц. Если за первые пять дней уже накопилось 7 000 ошибок, формально месяц еще не провален, но темп расхода бюджета опасный.

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

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

Как выбрать пользовательские сценарии для SLO

Не нужно писать SLO на каждую ручку API, каждую страницу и каждую фоновую задачу. Это быстро приведет к усталости и бюрократии. Начинать стоит с сценариев, которые напрямую влияют на деньги, удержание, доверие или работу клиентов. Хороший SLO почти всегда начинается с вопроса: «Какой пользовательский путь нельзя незаметно сломать?»

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

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

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

Как выбрать SLI: что именно измерять

SLI должен быть измеримым, понятным и связанным с пользовательским результатом. Если метрику сложно объяснить продукту и поддержке, она, скорее всего, не подходит для общего SLO. Хороший показатель можно описать одной фразой: «доля успешных оплат», «доля быстрых ответов поиска», «доля доставленных уведомлений», «доля успешных загрузок файла».

Для API чаще всего используют три группы SLI: доступность, задержка и корректность. Доступность отвечает на вопрос, смог ли клиент получить успешный ответ. Задержка отвечает на вопрос, получил ли клиент ответ достаточно быстро. Корректность отвечает на вопрос, был ли ответ логически правильным. Последний пункт сложнее всего измерять, но именно он часто важнее сухого uptime.

Например, API может отвечать кодом 200, но отдавать пустой список из-за ошибки фильтра. Формально сервер жив. По мониторингу 5xx все хорошо. Но пользовательский сценарий сломан. Поэтому в зрелых системах SLI не ограничивается статус-кодами. В него добавляют бизнес-сигналы: количество созданных заказов, успешные платежи, доставленные уведомления, завершенные регистрации, обработанные заявки, корректные статусы.

Практический ориентир: если пользователь может сказать «у меня не получилось сделать действие», это действие может стать кандидатом на SLI. Если метрика понятна только инженерам и не связана с пользовательским результатом, оставьте ее для диагностики.

Нужно аккуратно решать, какие ошибки считать плохими событиями. Не каждый 4xx код является проблемой сервиса. Если клиент API отправил неверный токен, неправильный формат даты или запрос без обязательного поля, это может быть нормальная пользовательская ошибка. Но если после релиза резко выросло число 400 из-за несовместимого изменения контракта, это уже проблема продукта и API. Поэтому полезно разделять ошибки клиента, ошибки сервера, ошибки внешних зависимостей и ошибки бизнес-логики.

Для задержки не стоит смотреть только на среднее значение. Среднее легко скрывает боль пользователей. Если 90% запросов отвечают за 100 миллисекунд, а 10% за 10 секунд, среднее может выглядеть терпимо, но каждый десятый пользователь страдает. Лучше использовать процентили: p95, p99, долю запросов быстрее порога. Для SLO часто удобнее формулировка «95% запросов быстрее 800 мс», чем «средняя задержка ниже 300 мс».

Как выбрать цель SLO без магических девяток

Цель SLO должна быть достаточно строгой, чтобы защищать пользователей, и достаточно реалистичной, чтобы команда могла жить и развивать продукт. Если цель слишком мягкая, она ничего не меняет. Если слишком жесткая, команда будет постоянно нарушать SLO, а метрика потеряет управленческий смысл.

Начните с исторических данных. Посмотрите, какой уровень надежности сервис уже показывает за последние один, три и шесть месяцев. Если сейчас важный API держится на уровне 99,6%, не стоит сразу ставить 99,99%. Сначала нужно понять основные причины ошибок, убрать очевидные проблемы, улучшить наблюдаемость и только потом повышать цель. Иначе SLO превратится в вечное напоминание о провале.

Затем оцените ожидания пользователей. Внутренняя админка, которой пользуются пять сотрудников, может иметь один уровень. Публичный платежный сценарий имеет другой. API для крупных B2B-клиентов имеет третий. Мобильное приложение с нестабильной сетью требует отдельных поправок, потому что часть ошибок может происходить не на стороне сервиса.

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

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

Как считать error budget на практике

Самая простая формула выглядит так: бюджет ошибок равен 100% минус SLO. Если SLO равен 99,9%, бюджет равен 0,1%. Но на практике важно считать не только общий бюджет, а и скорость его расхода. Команда может быть внутри лимита сегодня, но двигаться к нарушению слишком быстро.

SLO: 99,9% успешных запросов за 30 дней
Error budget: 0,1% неуспешных запросов
Всего важных запросов за период: 5 000 000
Допустимые плохие события: 5 000

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

Есть два популярных способа смотреть на бюджет. Первый - календарный: месяц начался, бюджет полный, затем постепенно тратится. Второй - скользящее окно: каждый момент времени считается период за последние 7, 14 или 30 дней. Скользящее окно лучше показывает текущую реальность, потому что не обнуляет проблемы искусственно в первый день месяца. Но оно сложнее для объяснения бизнесу. На старте можно использовать календарный период, если команда только учится работать с SLO.

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

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

Как настроить алерты без бесконечного шума

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

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

Плохой алерт звучит так: «CPU выше 80% пять минут». Иногда это важно, но часто непонятно, что именно сломалось для пользователя. Хороший алерт звучит так: «API создания заказа тратит бюджет ошибок в 12 раз быстрее нормы, доля 5xx выросла до 3%, затронуто 420 запросов за 15 минут». Второй сигнал сразу объясняет влияние, масштаб и приоритет.

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

Типичная ошибка: команда добавляет SLO, но оставляет старые шумные алерты без пересмотра. В итоге сигналов становится не меньше, а больше. Внедрение SLO должно сопровождаться чисткой правил оповещения.

Как договориться между продуктом, QA, разработкой и SRE

SLO работает только тогда, когда это общая договоренность, а не инженерная таблица в углу. Если цель надежности выбрала только SRE-команда, продукт может воспринимать ее как тормоз. Если цель выбрал только бизнес, инженеры могут получить невыполнимое обязательство. Если QA видит только финальную цифру, но не понимает критичные сценарии, тестирование будет распылено. Поэтому SLO нужно обсуждать вместе.

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

Важно договориться не только о цифре, но и о реакции. Что происходит, если бюджет ошибок потрачен на 50% за первую неделю? Кто принимает решение о релизах? Какие изменения считаются рискованными? Что делаем после нарушения SLO? Как быстро пишем postmortem? Какие задачи получают приоритет? Без этих правил SLO остается графиком, а не управленческим инструментом.

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

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

Роль QA в SLO и бюджете ошибок

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

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

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

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

• QA помогает определить, какие ошибки считать плохими событиями для SLO.

• QA проверяет, что критичные пользовательские пути покрыты автотестами, ручными проверками и мониторингом.

• QA участвует в разборе инцидентов и помогает превращать причины в проверяемые сценарии.

• QA следит, чтобы релизные проверки соответствовали текущему уровню риска и остатка бюджета ошибок.

• QA помогает продукту понять, какие деградации пользователь еще терпит, а какие сразу ломают доверие.

SLO для API: что важно проверять отдельно

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

Для публичного API важно разделять несколько классов надежности. Первый класс - доступность endpoint. Второй - стабильность схемы ответа. Третий - корректность обработки повторных запросов. Четвертый - предсказуемость лимитов. Пятый - доставка асинхронных событий. Один общий SLO на весь API может скрыть проблему: общий процент успеха нормальный, но критичная ручка создания заказа деградирует.

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

Еще один важный момент - коды ошибок. Не стоит считать все 4xx плохими событиями, если клиент действительно отправляет неверные данные. Но нужно следить за резкими изменениями. Если после релиза число 422 выросло в пять раз, возможно, команда изменила валидацию, документация устарела или контракт стал несовместимым. В таком случае формально сервер не падает, но интеграции ломаются.

Пример SLO для API: 99,9% валидных запросов на создание заказа завершаются успешным ответом или корректной бизнес-ошибкой за 30 дней, p95 задержки не превышает 700 мс, а повторный запрос с тем же ключом идемпотентности не создает дубль.

Как связать SLO с релизами

Бюджет ошибок становится полезным, когда влияет на релизный процесс. Если команда смотрит на него только в отчетах, поведение не меняется. Правило должно быть простым: чем хуже состояние бюджета, тем осторожнее изменения. Это не обязательно полный запрет релизов. Иногда достаточно снизить размер изменений, усилить canary, добавить feature flag, расширить мониторинг или перенести миграцию.

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

Важно не использовать SLO как дубинку против команды. Если каждый расход бюджета превращается в поиск виноватого, люди начнут спорить с метриками, скрывать проблемы или занижать критичность. Лучше использовать бюджет как систему раннего предупреждения. Он показывает, что текущий темп ошибок опасен, а значит, нужно изменить приоритеты.

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

Как разбирать инциденты через SLO

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

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

Хороший postmortem не должен ограничиваться фразой «исправили баг». Если баг дошел до продакшена и сжег бюджет, значит, была слабость в системе. Возможно, не было теста на краевой случай. Возможно, не было canary. Возможно, алерт смотрел на CPU, а не на успешность пользовательского действия. Возможно, логирование не позволяло быстро найти клиентов с ошибкой. Возможно, документация для партнера была двусмысленной.

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

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

Типовые ошибки при внедрении SLO

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

Вторая ошибка - SLO на технические метрики вместо пользовательского опыта. Доступность сервера важна, но пользовательскому пути может быть плохо даже при живом сервере. Если регистрация не завершилась из-за ошибки бизнес-логики, uptime не спасает.

Третья ошибка - цель взята из воздуха. Цифры 99,9% и 99,99% выглядят серьезно, но без исторических данных и понимания стоимости они могут быть случайными. SLO должен быть результатом разговора, а не украшением презентации.

Четвертая ошибка - алерты настроены на нарушение SLO, а не на быстрый расход бюджета. Если команда узнает о проблеме только после нарушения месячной цели, поздно реагировать. Нужны ранние сигналы по burn rate.

Пятая ошибка - нет правил поведения при расходе бюджета. Метрика есть, дашборд есть, а релизы продолжаются как раньше. Тогда SLO ничего не меняет. Нужно заранее договориться, что происходит при разных уровнях риска.

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

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

Пошаговый план внедрения SLO и error budget

Внедрение SLO лучше делать постепенно. Не нужно ждать идеальной платформы мониторинга и полного SRE-процесса. Начать можно с одного сервиса и одного важного сценария. Главное - довести цикл до конца: выбрать сценарий, измерить метрику, поставить цель, настроить бюджет, привязать алерты, договориться о реакции и регулярно пересматривать.

1. Выберите один критичный пользовательский сценарий, например оплату, авторизацию, создание заказа или ключевой API endpoint.

2. Опишите, что для пользователя считается успешным и неуспешным результатом.

3. Выберите SLI, который можно измерить по логам, метрикам, событиям или аналитике.

4. Посмотрите исторические данные за несколько периодов и оцените текущий уровень надежности.

5. Согласуйте реалистичный SLO с продуктом, QA, разработкой и эксплуатацией.

6. Посчитайте error budget и решите, как отслеживать скорость его расхода.

7. Настройте дашборд, где видны SLI, SLO, остаток бюджета, burn rate и диагностические метрики.

8. Пересмотрите алерты: оставьте срочные только там, где требуется немедленное действие.

9. Опишите правила реакции при разных уровнях расхода бюджета.

10. Через месяц проведите ретроспективу и поправьте SLO, если он оказался слишком мягким, слишком жестким или плохо измеримым.

Этот процесс выглядит простым, но именно простота делает его рабочим. Команде не нужна сложная терминология, если она не помогает принимать решения. Нужны понятные сценарии, честные данные, ясные правила и регулярное обсуждение.

Пример полной договоренности по SLO

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

Сценарий: оформление новой платной подписки.

SLI: доля технически успешных платежных операций среди валидных попыток оплаты.

SLO: 99,9% валидных попыток оплаты завершаются успешной оплатой или корректным бизнес-статусом за 30 дней.

Error budget: 0,1% технически неуспешных операций за период.

Срочный алерт: burn rate выше 10 за 15 минут или больше 2% месячного бюджета потрачено за час.

Рабочий алерт: больше 10% бюджета потрачено за сутки.

Правило релизов: при расходе больше 80% бюджета рискованные изменения в платежном контуре требуют отдельного согласования.

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

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

Как объяснить SLO бизнесу простыми словами

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

Можно сказать так: «Мы выбираем самые важные пользовательские действия и заранее договариваемся, какой уровень ошибок допустим. Если ошибок мало, команда продолжает развивать продукт обычным темпом. Если ошибок становится слишком много, мы временно уменьшаем риск и исправляем причины. Так мы не требуем невозможного нуля ошибок, но и не игнорируем надежность».

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

Важно не обещать через SLO больше, чем команда может выполнить. Если бизнесу нужен SLA для клиентов, внутренний SLO должен быть строже внешнего SLA. Иначе команда узнает о риске слишком поздно. Например, если клиентам обещают 99,5%, внутренний SLO может быть 99,9%, чтобы оставался запас на обнаружение и исправление проблем.

Как понять, что SLO работает

SLO работает, если он влияет на решения. Команда смотрит на бюджет ошибок перед рискованными релизами. Алерты стали реже, но точнее. Инциденты разбираются через пользовательское влияние. Продукт понимает, почему иногда надежность получает приоритет. QA использует критичные сценарии для планирования проверок. Разработка видит, какие технические долги реально бьют по пользователям.

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

Хороший признак зрелости - спокойный разговор о надежности. Команда не доказывает каждый раз, что «все плохо» или «все нормально». Она показывает бюджет ошибок, burn rate, влияние на пользователей и план действий. Это снижает эмоциональность и помогает быстрее принимать решения.

Чеклист для команды

• Для каждого SLO выбран конкретный пользовательский или партнерский сценарий.

• SLI измеряет результат действия, а не только состояние инфраструктуры.

• Цель SLO основана на исторических данных, критичности сценария и ожиданиях пользователей.

• Error budget посчитан и понятен продукту, QA, разработке и эксплуатации.

• Алерты настроены по скорости расхода бюджета, а не только по техническим всплескам.

• Срочные алерты требуют немедленного действия и действительно связаны с пользовательским ущербом.

• Есть правила, как менять релизный процесс при высоком расходе бюджета.

• После инцидентов команда считает потраченный бюджет и обновляет проверки.

• SLO пересматриваются регулярно, потому что продукт, нагрузка и пользователи меняются.

• Метрики понятны не только инженерам, но и людям, которые отвечают за продукт и клиентов.

Итог

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

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

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

А лучшие вакансии для devops специалистов ищите на hirehi.ru