Привет! Меня зовут Егор, я DevOps/SRE-инженер с небольшим (2+ года) стажем. Когда-то давно я мечтал о 100% аптайме – казалось, вот он, священный грааль для любого инженера. Помню, как любовался графиками uptime: если сервис работал без перерыва месяц, другой… год – гордости не было предела. Я даже подумывал повесить табличку “Uptime: 365 дней” и получить за это медаль от руководства. Ведь 100% доступность означала бы ноль инцидентов, счастливых пользователей и спокойный сон, разве не так?

Реальность, конечно, быстро остудила мой пыл. ? В прошлых материалах на Хабре я уже делился, как мы внедрили SRE-подход: завели SLO/SLI и умные мониторы, перестали тушить бесконечные пожары и наладили дежурства. Команда выдохнула, жизнь начала налаживаться. Но один идеал всё ещё манил меня – добиться заветных 99.999% аптайма, чтобы система никогда не падала. В этой статье я расскажу, почему гонка за девятками оборачивается разочарованием, что такое Error Budget и как он помог мне и бизнесу найти баланс между стабильностью и развитием. Будет личная история, немного юмора и, надеюсь, полезные практические иллюстрации.

Сколько стоят девятки

Когда речь заходит о надёжности, многие мыслят процентами. Разница между 99% и 99.9% кажется небольшой – всего-то 0.9%, какая ерунда! Но давайте посмотрим на это в масштабе времени. 99% аптайма – это ~87 часов простоя в год. 99.9% (три девятки) – уже около 8 часов в год (или ~43 минуты в месяц) допускаемого даунтайма. А 99.99% – менее часа в год (чуть больше 4 минут в месяц). Получается, каждая дополнительная девятка в 10 раз сокращает допустимое время простоя. То есть стремясь от 99.9% к 99.99%, мы ужимаем допустимый даунтайм с часов до минут.

Но сокращение простоев даётся не бесплатно. Существует шуточное правило: каждая новая девятка надежности обходится в 10 раз дороже. Представьте, у вас сервис с 99% доступности – чтобы добиться 99.9%, придётся выложиться технически и финансово на порядок сильнее. Ещё +0.09% (до 99.99%) – снова ×10 затрат. На графике выше эта зависимость утрирована: для образности я показал, как стоимость резко растёт при движении от 99% к 99.999%. Первая девятка – условно 1 единица усилий, три девятки – уже 10, четыре – 100 и т.д. В реальной жизни, конечно, не всегда ровно в 10 раз, но тренд понятен: ближе к 100% – деньги (и нервы команды) улетают в космос.

Причём бизнес-выгода от этих экстра-девяток стремится к нулю. Пользователи зачастую не заметят разницы между 99.9% и 99.99%: ну был сервис недоступен 5 минут в месяц вместо 45 минут – для большинства сценариев это некритично. Зато инженерная команда для этих 5 минут экономии простоя будет месяцами внедрять отказоустойчивые кластеры, дублировать всё на свете, писать сложнейшие тесты и процедуры. Ирония в том, что 100% аптайм недостижим в принципе – всегда может одновременно отказать сразу несколько компонентов (и чем сложнее система, тем больше шансов). Даже у облачных гигантов случаются сбои, а уж внешние факторы (сетевые проблемы, человеческий фактор) никто не отменял.

Наконец, главная мысль, к которой я пришёл: идеал 100% убивает развитие. Если гнаться за абсолютной безотказностью, придётся никогда не обновлять сервис. Любое изменение – враг стабильности. Новые фичи, обновление библиотек, да даже критические патчи безопасности – всё это риск нарушить заветный аптайм. Проактивно улучшать продукт некогда, ведь команда занята тем, что мониторит и латает любую мелочь, лишь бы не упало. В итоге система стагнирует, пока конкуренты выпускают обновления. Никому такая “стабильность” не выгодна.

После осознания всего этого я перестал молиться на дополнительные девятки. Но как тогда задавать цели по надежности? Тут на выручку приходит концепция Service Level Objective (SLO) и связанный с ней Error Budget.

Error Budget: запас на ошибки

Пару слов теории. SLO (Service Level Objective) – это наша целевая надежность, выраженная, как правило, в процентах или другом понятном метриками показателе. Например, «99.9% успешных запросов в месяц» – SLO для сервиса. Важно, что SLO обычно ниже 100% (как мы выяснили, 100% – плохая цель). А Error Budget (дословно «бюджет ошибок», я буду называть его “бюджетом” для краткости) – это, по сути, обратная сторона SLO, то есть сколько неполадок мы готовы потерпеть. Если SLO 99.9% за месяц, значит 0.1% времени сервис может быть неидеален. Переводя в числа: при 99.9% аптайма бюджет ошибок ≈ 43 минуты простоя в месяц (или ~8 часов в год). Это и есть тот самый лимит, в который мы укладываем все сбои, аварии, технические окна и прочие проблемы, прежде чем нарушим обязательства перед пользователями.

Зачем нам знать этот бюджет? Он служит буфером и одновременно мерилом риска. Представьте, месяц почти прошёл, а вы израсходовали только половину бюджета на простои – то есть сервис работал лучше, чем требовалось по SLO. Отлично, можно смело выкатывать новые фичи, экспериментировать – пользователи всё равно довольны, а у вас есть запас прочности. Напротив, если случилась пара серьёзных инцидентов и бюджет почти сгорел, это звоночек: приберегите релизы, сконцентрируйтесь на стабилизации. Такой подход официально практикуется в SRE-командах: пока не потрачен бюджет ошибок, релизы идут полным ходом; когда бюджет исчерпан – включается режим Stop The Line. По сути, бюджет ошибок – это договорённость между инженерами и бизнесом о приемлемом уровне ненадёжности.

Бизнес любит метафору с бюджетом, потому что она прозрачна: процент аптайма превращается в конкретные часы и минуты простоя, на которые мы согласны. Например, легко объяснить продуктовой команде: «SLO 99.5% в квартал – это около 11 часов возможных проблем. Мы “закладываем в бюджет” эти 11 часов на случай ЧП или техработ, и обещаем не превысить эту сумму». Такая подача меняет разговор: вместо требований “сделайте максимально надёжно, чтоб ничего никогда не падало” появляется осознанное согласие на небольшой риск ради развития.

И тут важный психологический момент. Если раньше каждая мелкая авария вызывала панику (“всё пропало, клиенты бегут!”), то с введением SLO/Error Budget градус драматизма падает. Вон у нас 0.1% допустимых ошибок – небольшие сбои перестают быть концом света, они заложены в общий план. Конечно, это не значит, что можно расслабиться и ронять продакшн направо и налево. Но команда чувствует себя увереннее: мы контролируем ситуацию, у нас есть численное понимание, когда стоит бить тревогу, а когда инцидент – просто инцидент, остаёмся в рамках.

Чтобы Error Budget работал, его мало посчитать – нужно ещё договориться о шагах при превышении. Например, у нас правило: если за месяц выбрали бюджет более чем наполовину – планируем следующие спринты с упором на надежность (долги, оптимизации). Если бюджет полностью исчерпан (SLO нарушен) – стоп релизам, фокус на устранении проблем, разбор инцидентов, усиленный мониторинг и т.д., пока метрики не вернутся в норму. Вот упрощённая схема реакции:

Что делать, если бюджет ошибок исчерпан? Если “Да” – ставим релизы на паузу, улучшаем стабильность; если “Нет” – продолжаем выпуск фич и небольшие эксперименты.

Следуя такой политике, мы, с одной стороны, обеспечиваем стабильность до оговоренного уровня, с другой – не душим инновации. Бизнес видит, что команда ответственно подходит к надёжности (есть чёткие цели SLO и план действий при их невыполнении). А инженеры понимают, что пока они держат слово по SLO, руководство не будет требовать невозможного. Это и называется balance between innovation and reliability – баланс между развитием и стабильностью. Как мы в шутку говорим, “бюджет ошибок помогает примирить вечный конфликт между разработчиками, которые хотят всё поменять, и операторами, которые хотят, чтобы всё работало”. ?

Кейс: когда гонка за аптаймом мешает работе

Хочу поделиться историей из собственного опыта. Ещё будучи начинающим инженером, я попал в одну команду, где неписаным правилом был идеальный аптайм. Про SLO тогда никто не знал, SLA (договорных гарантий) у нас тоже не было, но руководство внушило: “сбой недопустим”. Мы сами себя убедили, что любое падение – это катастрофа. Вначале энтузиазм бил ключом: мы настроили агрессивный мониторинг, ловили каждый чих сервера, дежурили ночами, откладывали обновления “до лучших времён”. Казалось, ещё чуть-чуть – и мы реально выйдем на 100% аптайма!

Чем это обернулось? Релизы встали. За квартал мы почти ничего нового не выпустили – каждый боялся быть тем, кто “уронит продакшн” обновлением. Бэклог рос, сроки сдвигались, но начальство вроде довольно: система же не падает! Правда, ценой того, что мы фактически остановили развитие. Ирония в том, что при всём нашем трепетном отношении аварии всё равно случались. Однажды накопилась куча изменений, которые мы слишком долго не выкатывали – и в итоге, когда пошли в релиз, получили крупный сбой из-за конфликтов и непротестированных сценариев. Полдня простоя, хаос, злые пользователи… вот тебе и “никогда не падает”. Мы потратили весь запас нервов, но в итоге аптайм за тот месяц упал хуже некуда, а бизнес остался и без стабильности, и без новых фич.

Тот крах отрезвил всех. Мы поняли, что дальше так нельзя: нужно планово отпускать систему на перезагрузку (как минимум для обновлений), иначе она рухнет сама в самый неудобный момент. Я предложил попробовать подход SRE, о котором к тому времени начал читать. Идея “бюджета ошибок” неожиданно понравилась менеджерам: цифры их успокоили. Мы договорились установить SLO 99.5% на следующий квартал – это всё ещё высокий аптайм (максимум ~1 час простоя в месяц), но не строгие 100%. То есть допустили маленький процент риска.

Дальше – больше. Мы разгребли мониторинг, убрали лишние алерты (о чём я подробно писал в предыдущей статье про дежурства). Вместо сотен сигналов “у вас CPU 85%” или “в логах ошибка” сосредоточились на метриках, влияющих на пользователей (уровень SLI): процент успешных запросов, время ответа, и т.п. Если эти показатели в норме – система считается здоровой, не отвлекаемся. Заодно внедрили постмортемы: каждый серьёзный инцидент теперь разбирали, искали корень, а не просто тушили пожар.

Результат нас поразил. Получив чётко определённый запас на ошибки, команда... стала смелее, что ли. Появилась уверенность: “у нас 0.5% допуска на сбои, можем нормально жить”. Мы наконец разморозили релизы – раскатали накопившиеся обновления постепенно, без спешки. Где-то что-то, конечно, ломалось – но мы учитывали это в бюджете. Например, одна фича вызвала часовой простой в ночное время. Неприятно, но ничего страшного: утром всё подняли, уложились в SLO за месяц. Зато фича дала ценность клиентам уже сейчас, а не через год. Руководство видит: да, были мелкие сбои, зато продукт развивается, пользователи довольны, а общая метрика аптайма по-прежнему высокая.

Через несколько месяцев такой работы мы вышли на стабильный баланс: держали около ~99.8–99.9% аптайма (чуть выше цели), релизились регулярно каждую неделю, а иногда и чаще. Среднее время восстановления (MTTR) резко сократилось – ведь инциденты стали реже и легче, и у нас были отработанные runbook’и на случай проблем. А главное – вся команда выдохнула. Больше не было страха передDeploy-кнопкой, не нужно героически не спать ночами (дежурства редкие и почти без вызовов). Error Budget позволил нам перейти от режима “держать всё и вся в идеале” к режиму “держим в разумных рамках и развиваем”. И, как ни парадоксально, пользователи стали только довольнее: мелкие простои прошли почти незамеченными, а новые фичи – вот они, выходят постоянно.

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

SLO на практике: как говорить с бизнесом и искать баланс

Итак, технически идея понятна. Но как донести её до людей, которые далеки от SRE? Многие тимлиды и инженеры боятся разговора с бизнесом про ошибки, думают, что любые допущенные “9 часов простоя в год” вызовут шок у руководства. Мой опыт показывает: наоборот, бизнес часто готов пойти навстречу, если объяснить правильно. Вот несколько советов:

Баланс инноваций и стабильности. Error Budget помогает соблюдать равновесие: пока “чаша” надёжности в порядке, можно класть больше на чашу инноваций (выпускать фичи). Перевесило в сторону сбоев – добавляем усилий в стабильность.

• Говорите на языке влияния на пользователя и деньги. Вместо абстрактных процентов показывайте, что стоит за ними. Например: «99.9% аптайма значит не более 43 минут простоя в месяц. Если вдруг сервис лежит час – пользователи начнут жаловаться, и мы превысим бюджет». Или наоборот: «Разница между 99.5% и 99.9% – это ~5 часов простоя в год. Вопрос: готовы ли мы инвестировать $$$, чтобы выиграть эти 5 часов надежности? Может, пользователям важнее за это время получить новые функции?». Когда ставишь вопрос так, бизнес начинает сам взвешивать выгоды.

• Подчеркните, что 100% надёжности = 0% развития. Прямо скажите: «Если требовать нулевых сбоев, придётся остановить любые изменения. Система замрёт, а конкуренты обгонят». Это сильный аргумент. Продуктологи и директора не хотят потерять рынок из-за того, что команда боится релизить. Расскажите историю (можно и гипотетическую) про команду, которая ничего не выпускала, держа аптайм, а потом всё равно словила крупный отказ – и понесла двойные потери. Такие байки отрезвляют.

• Предложите конкретный SLO как компромисс. Бизнесу проще согласиться, когда есть цифра. Не надо начинать разговор с “давайте чуть ухудшим надёжность”. Вместо этого: «Давайте официально цели: 99.X% аптайма. Это высокий показатель, клиенты будут довольны. Зато у нас будет небольшой резерв времени на плановые работы и непредвиденные инциденты без ущерба обязательствам». Часто так и выясняется, что 99.9% их устроит ничуть не меньше, чем мифические 100%. Заодно вы выглядите как ответственный инженер, который предлагает договор, а не отговорки.

• Используйте аналогию с бюджетом и рисками. Термин “бюджет ошибок” сам по себе удачный – апеллирует к привычному понятию бюджета. Скажите: «У нас, как у банка, есть кредит доверия – мы можем позволить себе X минут сбоев. Давайте их разумно “потратим”: например, на обновление базы или эксперимент. Если вдруг “потратим слишком много” – прекратим выпуск фич, пока не восстановим надёжность». Бизнес ценит такой подход: у него есть контрольный показатель и обещание, что вы не выйдете за рамки. Это лучше, чем неопределённость “ну может упадёт, а может нет”.

• Внедрите SLO/Error Budget в процессы. Мало про это поговорить – закриптуйте в регламенты. Например, договоритесь, что каждый квартал пересматриваете SLO с продуктовой командой: устраивает ли текущий уровень, не изменились ли требования рынка? Закрепите политику release freeze при нарушении SLO: если за отчётный период провалились по надежности, следующий цикл посвящаете улучшениям (и донесите это до всех стейкхолдеров заранее, чтобы не было сюрпризов). Включите метрики SLO в статус-отчёты: пусть в обзорах проекта будет строчка вроде “Аптайм за квартал: 99.8% (цель 99.5%, бюджет ошибок использован на 60%)”. Когда менеджеры видят такие цифры регулярно, они привыкают мыслить в этих терминах. Со временем SLO станет частью культуры: решение о запуске нового большого релиза всегда будет сопровождаться вопросом “а не рискуем ли мы превысить бюджет ошибок?”. И это здорово.

В заключение скажу: перестать гнаться за 100% аптаймом – не значит опустить руки и “пусть всё падает”. Это значит – выбрать разумную планку надежности и стремиться к ней, не больше и не меньше. SLO и Error Budget дисциплинируют и команду, и бизнес. Первым они дают чёткие ориентиры и избавляют от перфекционизма, вторым – понимание, чего ожидать от технической стороны. В итоге все выигрывают: продукт развивается быстрее, пользователи получают новое, а сервис остаётся достаточно стабильным, чтобы не терять доверия. Я больше не пишу в резюме «100% аптайм (никогда не падает)» – вместо этого пишу про реалистичные достижения, вроде «99.9%+ uptime при 3× росте выпусков и снижении MTTR на 35%». Потому что именно такой баланс говорит: команда умеет и держать систему надёжной, и менять её под нужды бизнеса. А гоняться за абсолютом мы оставим супергероям – в реальной жизни лучше быть чуть прагматичнее. ?

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