Почему SLO являются важным инструментом

Современные цифровые продукты работают на масштабах, которые десять лет назад казались недостижимыми. YouTube обрабатывает более 500 часов видео каждую минуту, Amazon — около 12 миллионов заказов в сутки, а крупные облачные платформы и рекламные системы обслуживают миллиарды запросов в реальном времени.

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

Мы поговорили с Сергеем Сидоровым, опытным инженером-программистом и техническим лидером в Meta, работающим над инфраструктурой, обеспечивающей такие продукты компании, как Ads и Instagram. Сергей создал высокопроизводительные системы для асинхронных вычислений, способные обрабатывать миллиарды запросов в секунду. В этом интервью он поделился, как сделать надежность измеримой в высоконагруженных средах, почему SLO важны и что действительно работает на таких масштабах.

ADM: Что для вас означает «надежность» в контексте высоконагруженных продуктов?

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

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

С инженерной стороны, мы переводим эти пользовательские ожидания в измеримые сигналы. Показатели уровня сервиса (SLI) определяют, что именно мы отслеживаем — например, показатели успеха или пороги задержки. Затем мы устанавливаем SLO, чтобы определить, какой уровень производительности приемлем.

Когда SLO установлены, можно говорить на языке, понятном как для инженеров, так и для бизнеса. Например, 99,95% доступности соответствует примерно 4,5 часам простоя в год. Или: 99,95% вероятность, что любой данный запрос будет успешным.
Но определить значимые SLI и SLO сложно, особенно в крупных распределенных системах. Можно столкнуться с такими проблемами, как задержка на горячих шардерах или ненадежные зависимости, вводящие в заблуждение глобальные агрегаты, скрывающие региональные сбои, и шумные арендаторы, искажающие общие метрики. А на масштабе так называемые «редкие события» происходят постоянно. Поэтому способность отделять сигнал от шума становится абсолютно критичной.

ADM: Как вы пришли к использованию SLO как основного инструмента для управления надежностью?

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

В это же время команды SRE в Google уже активно работали с SLO. Изучение их подхода показало, насколько эффективно он связывает технические индикаторы с реальными результатами для пользователей. Это привело к созданию внутренней платформы в Meta под названием SLICK, которая позволяет командам определять и отслеживать SLO единообразным образом. Помимо инструментов, процесс эволюционировал: SLO стали частью анализа инцидентов и повседневных операционных обзоров.

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

ADM: Что делает SLO действительно полезным и какие распространенные ошибки встречаются при их определении?

Сергей: Полезный SLO — это тот, который дает командам четкий, измеримый сигнал, на который можно реагировать. Самая распространенная ошибка — сосредоточение на внутренних системных статистиках, таких как загрузка CPU или глубина очереди, вместо того, что действительно важно для пользователей.
Чтобы этого избежать, выбирайте метрики, связанные с реальными пользовательскими задачами — например, «95% загрузок страниц завершаются менее чем за 300 мс» или «99,9% сообщений успешно доставляются». Эти индикаторы не только измеримы, они также легко объяснимы, отлаживаемы и улучшаемы.

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

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

ADM: Вы разработали алгоритм для быстрого обнаружения проблем на основе SLO — чем он отличается от традиционного оповещения?

Сергей: Традиционные оповещения часто зависят от статических порогов — например, «включить оповещение, если уровень ошибок превышает 5% в течение 5 минут». Проблема в том, что эти пороги либо слишком чувствительны, вызывая ложные срабатывания, либо слишком расслаблены, позволяя настоящим проблемам ускользнуть. В масштабе это создает усталость от оповещений и подрывает доверие к системе.

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

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

SLICK: Обзоры SLO в Meta - Дэвид Барток и Сергей Сидоров

ADM: Какие основные вызовы стоят перед обеспечением надежности при масштабе в миллиарды запросов в секунду?

Сергей: На таком масштабе сбои не редкость — они ожидаемы. Ключ в создании систем, которые могут их поглощать без влияния на пользователя. Это означает, что избыточность, повторные попытки и устойчивость к сбоям должны быть заложены в дизайн.

Другой важный вызов — измерение. Объем телеметрии огромен, и хранить все невозможно. Выборка помогает, но это также означает, что можно пропустить небольшие, но важные сигналы — например, всплеск задержек в одном регионе.

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

ADM: Что вы посоветуете команде, которая хочет начать использовать SLO, но еще не имеет сложной инфраструктуры?

Сергей: Начните просто и начните с пользователя. Вам не нужны сложные инструменты, чтобы получить ценность от SLO. Ключ в изменении мышления с «Работает ли система?» на «Достаточно ли хорош пользовательский опыт?». Затем выберите одно или два основных пользовательских пути, таких как загрузка страницы, отправка сообщения или завершение транзакции, и определите, что значит «хорошо» для этого процесса. Это станет вашей первой SLI.

Затем установите реалистичную цель: возможно, 99,9% запросов должны завершаться за 300 мс. Это не должно быть идеально. Цель — создать общий контракт между продуктом и инженерией о том, какой уровень надежности важен, и измерить его. Простой счетчик успешных и всех запросов — это достаточно, чтобы начать. Оттуда вы можете ввести идею бюджета ошибок и использовать его для принятия решений: можем ли мы выпустить это рискованное изменение сейчас? Должны ли мы приостановить и сначала исправить надежность?

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