SLO: одно уравнение, множество ответов / Кирилл Борисов (VK, VK Реклама)

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

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

Сколько надо [девяток]?

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

В сфере надежности оперируют тремя ключевыми понятиями: SLA, SLI и SLO. SLA (Service Level Agreement) представляет собой формальное соглашение между поставщиком и клиентом, определяющее параметры работы сервиса, такие как время безотказной работы или время реагирования, а также меры ответственности за нарушение этих условий. SLI (Service Level Indicator) — это количественная оценка работы сервиса, которая напрямую связана с удовлетворенностью клиента продуктом за определенный период, например, квартал или год. И, наконец, SLO (Service Level Objective) — это конкретное соглашение в рамках SLA, касающееся определенного показателя, например, доступности или времени реакции на инцидент.

Для правильного построения SLO важно понимать, какие типы компонентов существуют в современных экосистемах. Выделяют три основных типа. Во-первых, это сервис (стандартные HTTP-клиенты и серверы), где измеряются задержка и доступность. Во-вторых, это пайплайн — процессы загрузки, обработки и выгрузки данных без строгих требований к реальному времени. В-третьих, это хранилище, куда поступают и где сохраняются данные, например, видеозаписи или логи.

Помимо общеизвестных метрик доступности (Availability) и задержки (Latency), существует ряд других важных индикаторов, необходимых для полной картины. Например, пропускная способность (Throughput) измеряет количество запросов, обрабатываемых за единицу времени. Корректность (Correctness) обеспечивает долю валидных данных. Свежесть (Freshness) критична для пайплайнов, гарантируя, что данные обновляются не реже установленного интервала. Также важны Полнота (Coverage) успешной обработки и Долговечность (Durability) для хранилищ.

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

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

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

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

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

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

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

После определения бизнес-кейса необходимо проанализировать все зависимости, которые обеспечивают работу этого пути. Даже простое отображение одного числа может развернуться в сложную цепочку из множества сервисов, включая сервисы статистики, хранилища (ClickHouse), очереди сообщений (Kafka) и кэширующие слои (Redis). Наблюдение за системой на этом этапе помогает выявить наличие необходимых метрик и логов, а также проанализировать прошлые инциденты, чтобы понять, как система ведет себя в реальных условиях.

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

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