SLO as Code — нельзя верить людям

Значимый прорыв формирует отрасль ИИ: hAh0L 1 минуту назад SLO as Code — нельзя верить людям Простой 20 мин 6 Блог компании Купер DevOps * Ретроспектива Как мы внедряли SLO в Купере: от ручных формул до SLO as CodeВсем привет, меня зовут Вячеслав, я Team Lead SRE в Купер. Рассказ в этой статье пойдет о том, как мы внедряли SLO, чего достигли и какие лайфхаки нашли по дороге. Купер — сервис доставки из магазинов и ресторанов.

Сейчас у нас 12 production-кластеров Kubernetes с 350+ продуктовыми сервисами. подов, которые обрабатывают свыше 10 тыс. И все — ради 200–300 тыс.

Технические детали

заказов в день, хотя в «высокий сезон» дневной объем заказов может доходить и до 500 тыс. Осень 2022 выдалась достаточно сложной для сервиса: тот самый «высокий сезон», «черные пятницы», «зеленые дни». Инцидентов было довольно много и они только прирастали.

Разумеется, в компании существовали практика мониторинга и культура инцидент-менеджмента. Однако при такой сложности инфраструктуры оперативных дашбордов с метриками было явно недостаточно: они помогали дежурить и отвечать на текущие вызовы, но мало способствовали принятию стратегических решений. С чего все началосьВ перерывах между тушением пожаров мы, команда SRE (Site Reliability Engineering), считали метрики, строили новые дашборды, искали новые инструменты и подходы (именно так в нашей платформе появился Slok/Sloth).

Часть SLI (Service Level Indicator — индикатор уровня сервиса) мы могли описать сами. Например, базовую доступность сервиса — долю успешных запросов — считали по метрикам Istio (сервис-меш метрик сетевого взаимодействия). Но дальше без владельцев сервисов двигаться было невозможно: только они могли сказать, какая задержка допустима, по каким API-методам ее считать и какие ошибки действительно влияют на пользователя.

Отраслевые последствия

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

Это был карт-бланш, которым мы и воспользовались. Когда первые индикаторы были написаны и задеплоены, встал вопрос: как на них смотреть. У Sloth есть встроенный дашборд, который показывает индикаторы последовательно — каждый отдельно, с целью, текущим бюджетом ошибок (Error budget).

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.