Когда в обсуждении надежности сервиса появляется еще одна «девятка», это часто звучит как небольшое улучшение.
Кажется, что речь идет о тонкой настройке. Было 99.9%, станет 99.99%. Визуально разница почти незаметна. На слайде это выглядит как один дополнительный символ после запятой. Для человека со стороны это вообще может восприниматься как косметическое усиление цели: ну да, хотим быть чуть надежнее, чуть аккуратнее, чуть качественнее.
Но на практике это совсем не так. Разница между 99.9% и 99.99% доступности - не про «чуть лучше». Это про другой режим жизни системы и команд.
Если перевести эти цифры в простой operational смысл, то 99.9% доступности - это примерно 43 минуты простоя в месяц. А 99.99% - уже около 4 минут. И вот здесь становится понятно, что дело не в красоте метрики. При таком уровне целевой доступности у системы почти не остается права на ошибку.
То, что раньше можно было пережить как неприятный, но допустимый инцидент, теперь способно съесть существенную часть месячного error budget. То, что раньше считалось рабочим компромиссом, при 99.99% уже начинает выглядеть как архитектурная или организационная слабость.
Именно поэтому переход к 99.99% — это не призыв «давайте просто внимательнее писать код». Это смена модели работы.
Почему компании часто ошибаются в самой постановке вопроса
Одна из самых частых проблем в таких историях — формулировка цели.
Повышение SLO часто объявляют как красивый KPI. Как признак зрелости. Как маркер высокого качества. Как амбициозную цель, которая должна показать рынку, клиентам или руководству, что компания относится к надежности серьезно.
Звучит хорошо. Но за этим очень часто не следует главный разговор — разговор о цене. А цена есть всегда. Любая дополнительная «девятка» — это не абстрактная амбиция. Это набор вполне конкретных последствий:
- для архитектуры;
- для процессов;
- для подхода к релизам;
- для того, как команды тратят инженерное время;
- для того, как бизнес должен смотреть на скорость поставки;
- для того, какие компромиссы теперь становятся недопустимыми.
Если этот разговор не случился заранее, начинается очень знакомый сценарий. Сверху появляется более амбициозная цифра. Команды понимают, что для такой цифры нужно работать по-другому. Но ожидания бизнеса по скорости, объему поставки и гибкости не меняются. В итоге одна сторона считает, что инженерия «начала тормозить», а другая — что от нее требуют несовместимых вещей.
На мой взгляд, проблема тут не в сопротивлении команд. Проблема в том, что число меняют быстрее, чем управленческую модель вокруг него.
Что реально меняется, когда компания идет к 99.99%
Первое, что меняется, — отношение к изменениям в проде.
При 99.9% организация еще может себе позволить некоторый запас на ошибки. Не бесконечный, конечно, но достаточный, чтобы пережить неидеальный rollout, ошибку в конфигурации, не самый быстрый rollback или не лучшим образом настроенные алерты.
При 99.99% этот запас становится очень маленьким. Любое изменение начинает рассматриваться как риск гораздо серьезнее, чем раньше. Это влияет не только на инженеров, но и на весь delivery-контур. Релизы становятся осторожнее. Требования к проверкам возрастают. Хочется более безопасных rollout-стратегий. Нужны быстрые механизмы отката. Становится важнее качество pre-production validation. Повышаются требования к сигналам мониторинга и к скорости реакции.
Дальше проявляется вторая важная вещь: растет объем инженерной работы, которая с точки зрения бизнеса часто выглядит «невидимой». Когда компания идет к высокому уровню надежности, все больше сил уходит не на новые функции, а на снижение вероятности отказа и на уменьшение blast radius, если отказ все-таки случился.
Это работа над:
- observability;
- качеством алертов;
- автоматизацией рутинных operational-шагов;
- отказоустойчивостью;
- резервированием;
- стандартизацией инфраструктуры;
- внутренней платформой;
- пайплайнами поставки;
- incident management;
- on-call-практиками;
- ясностью ownership.
Проблема не в том, что эта работа бесполезна. Наоборот, часто это один из самых ценных видов инженерной деятельности. Проблема в том, что ее труднее «продать» в виде красивого бизнес-результата на квартальной презентации.
Фичу показать легко. Редизайн архитектурного паттерна, улучшение качества alerting или устранение ручных operational-шагов продаются сложнее. Но именно такие вещи и составляют фундамент высокой надежности.
Почему почти неизбежно замедляется TTM
Очень важный момент: когда компания реально идет к 99.99%, time-to-market почти неизбежно замедляется. Это не означает, что команды стали хуже. Не означает, что инженеры вдруг начали бюрократизировать все вокруг. И не означает, что исчезло желание двигаться быстро. Это означает другое: система начинает тратить больше энергии на снижение риска.
Чем меньше допустимый простой, тем дороже любая ошибка. А значит:
- каждое изменение требует большего уровня уверенности;
- каждый релиз требует более надежных защитных механизмов;
- каждая ручная операция начинает выглядеть как потенциальная точка отказа;
- каждая размытая зона ответственности становится опасной во время инцидента;
- каждый слабый алерт превращается в риск позднего обнаружения проблемы.
По сути, растет стоимость изменений.
На более низких уровнях надежности организация иногда может позволить себе жить на комбинации таланта, опыта и героизма отдельных людей. При очень высоких уровнях надежности это перестает масштабироваться. Нельзя строить 99.99% на том, что «наши ребята всегда разрулят». Такая модель слишком хрупкая.
На смену героизму должны приходить системы:
- автоматизация;
- стандартизация;
- платформенные решения;
- качественный incident response;
- дисциплина релизов;
- предсказуемость operational-процессов.
И все это требует времени, денег и фокуса.
Поэтому если руководство говорит: «Теперь надежность у нас стратегический приоритет», но при этом ожидает от команд прежнюю скорость, прежний объем поставки и прежнюю гибкость, почти наверняка начнутся проблемы.
Потому что стратегический приоритет — это не лозунг. Это выбор того, на что компания действительно готова тратить ресурс и какие компромиссы она готова принять.
Почему 99.99% нельзя получить призывом «писать код аккуратнее»
Есть удобное, но вредное упрощение: считать, что высокая надежность — это просто следствие хорошего инженерного качества. Логика здесь обычно такая: если писать код аккуратнее, лучше тестировать и внимательнее относиться к релизам, то доступность вырастет. В каком-то смысле это верно, но только на очень поверхностном уровне.
Проблема в том, что 99.99% не покупается личной добросовестностью отдельных людей. Такая надежность покупается системными свойствами.
Нельзя всерьез объявить надежность стратегическим приоритетом и одновременно вести себя так, как будто ничего не меняется. Как будто команды по-прежнему должны с той же скоростью закрывать весь продуктовый backlog, так же легко экспериментировать и так же быстро двигать сложные изменения в прод.
Обычно это не работает. Потому что надежность такого уровня — это не бесплатное улучшение. Это осознанная инвестиция.
Первый вопрос, который должен задать бизнес
На мой взгляд, первый и самый важный вопрос здесь очень простой:
Зачем бизнесу нужна эта дополнительная «девятка»?
Именно бизнесу, а не слайду. Не бренду. Не ощущению зрелости. Не внутреннему желанию «быть как лучшие».
Должен существовать понятный контекст.
Например:
- есть критичные клиентские сценарии, где простой прямо бьет по выручке;
- есть контрактные обязательства;
- есть серьезные репутационные потери от недоступности;
- есть сценарии, где простой влияет не просто на удобство, а на core value продукта;
- есть крупные B2B-клиенты, для которых доступность — часть условий сотрудничества.
Если такого контекста нет, то цель 99.99% будет восприниматься как прихоть сверху. И это абсолютно справедливая реакция.
Потому что тогда возникает нормальный управленческий вопрос: почему мы инвестируем в это, а не в новые функции, рост продукта, улучшение воронки, ускорение поставки или в другие вещи, которые дают более понятный бизнес-эффект?
Это не спор с качеством. Это спор о приоритетах. И если на него нет честного ответа, команда очень быстро почувствует, что от нее хотят дорогую инженерную трансформацию без внятного основания.
Второй вопрос: что конкретно меняется для команд
Если решение все-таки принято, следующий вопрос должен звучать так:
Что именно меняется для команд?
Потому что последствия всегда не абстрактные, а очень практические.
Меняется приоритизация.
Появляется больше невидимой инженерной работы.
Усиливаются ограничения на релизы.
Растет значение платформенных решений.
Повышаются требования к observability и incident response.
Усложняется стоимость каждого изменения.
Если это не проговорить заранее, организация почти гарантированно попадет в классический разрыв ожиданий. Бизнес продолжит ждать прежнюю скорость. Команды уже будут работать в других условиях. Напряжение вырастет. Инженерия начнет объяснять, почему раньше можно было иначе. Бизнес начнет задавать вопрос, почему «раньше успевали больше».
И обе стороны будут по-своему правы, потому что они исходят из разных операционных реальностей.
Поэтому здесь очень важна честность управления. Если мы выбираем более высокий SLO, нужно прямо говорить и о цене выбора, и о том, какие последствия он несет для delivery-модели.
Почему это управленческое, а не только техническое решение
Для меня переход с 99.9% на 99.99% — это не разговор про «качество вообще».
Это управленческое решение о новом балансе между:
- надежностью;
- скоростью;
- стоимостью изменений.
Именно в таком виде его полезно обсуждать. Не как универсальное благо. Не как безусловный признак зрелости. Не как очевидную цель для любой компании. А как конкретный выбор с понятной ценой и понятными последствиями.
Иногда этот выбор абсолютно оправдан. Есть продукты и контексты, где 99.99% действительно нужен. Но тогда нужно быть готовыми не только к новой цифре, но и к новой модели работы.
Нужно быть готовыми к тому, что часть инженерной энергии уйдет в platform work и risk reduction. Что velocity может стать ниже. Что вырастет роль невидимой инженерной деятельности. Что релизная дисциплина станет жестче. Что improvisation перестанет быть нормой.
И главное — нужно быть готовыми не требовать от системы старых результатов в новых условиях.
Поэтому перед тем как повышать SLO, я бы задавал не вопрос «можем ли мы поставить более красивую цифру?», а вопрос «готовы ли мы к тому, как эта цифра изменит всю систему работы?».
Потому что саму «девятку» нарисовать легко. Гораздо сложнее построить организацию, процессы и инженерную среду, которые способны честно жить на этом уровне надежности.
Больше практических наблюдений про engineering management, delivery, платформенные изменения и работу с командами — в моем Telegram-канале:
https://t.me/pavelsengineeringstuff
Подписывайтесь.