Привет! Меня зовут Павел Лакосников. Я тимлид команды SLA в Авито, которая работает с надёжностью сайта и приложения.

Авито рос и развивался, и продолжает развиваться сейчас. У нас вырос сайт, нагрузка, увеличилось количество объявлений до 150 млн! По мере развития продукта начали появляться процессы инцидент-менеджмента. Сначала мы внедрили их для быстрой и качественной починки инцидентов, оценки влияния на бизнес и понимания скорости их роста. Но со временем одного процесса стало не хватать: он по природе своей- реактивный, и слабо способствует предотвращению нового. Он не отображал реальной ситуации и не помогал понять, хватает ли его усилий. Мы стали замерять, насколько инцидент-менеджмент качественный, какие общие тренды он имеет,  хватает ли его. Решили вложится не только в реактивную, но и в проактивную починку. 

Для этого мы определили собственные критерии надёжности сервиса, отвязанные от абсолютных чисел нагрузки и числа инцидентов.

Что входит в понятие надёжности сервиса: SLO, SLI и SLA 

Каждая компания по-разному определяет критерии надёжности своих сервисов. Их описывают внутренние соглашения: SLO, SLI и SLA.

SLO (Service Level Objective) — декларируемый уровень надёжности сервиса. Это желаемая цель, тот уровень качества, который хочет видеть наш клиент.

К примеру, мы хотим обеспечить: 

• время ответа не больше 100 мс на 95 %%;

• количество ответов с кодом 500 не больше 0,2% от общего числа ответов сервера;

• время обработки критического тикета не больше 20 минут. 

Эти три метрики и будут нашим SLO. 

SLI (Service Level Indicator) — фактическое состояние метрик. Это то, как работает сервис в реальности. 

Мы измеряем метрики и узнаём, что наши SLI: 

• время ответа — 730 мс; 

• 0,01% ответов с кодом 500;

• 22 минуты на обработку критического тикета. 

SLA (Service Level Agreement) — договорённости или контракты о том, что делать, если SLI отличаются от SLO в худшую сторону. То есть, если сервис работает не так, как мы обещали. 

В контракте SLA можно прописать штрафные санкции. Это может быть возврат денег, дополнительные услуги, особый приоритет в будущем. 

Когда разработчики говорят о надёжности сервиса, чаще всего они вспоминают AWS от Amazon. Как люди думаю - он обеспечивает 99,99% доступности и надёжности.

Надёжность можно определять по-разному. Сервер AWS считается недоступным только в случае, если за пять минут не дает никаких ответов на запросы, кроме 500 или 503. Эти коды ответов обозначают две ошибки: Internal Server Error и Service Unavailable. Все остальные ответы сервера не учитываются при расчёте надёжности. 

То есть, представьте, что у вас в Amazon успешен только один запрос в 5 минут. Тогда, по их мнению, это 100%-я доступность! Можно сказать иначе: у вас могут быть до 21 минуты полной деградации, и неограниченное число частичных деградаций. И, что Амазон не нарушит свои условия о 99,95% доступности. Или в крайнем случае - 8640 успешных запросов (по 1му раз в 5 минут) и неограниченное число неуспешных. 

А в документации AWS прописаны условия, по которым пользователь может вернуть 100% оплаты, ТОЛЬКО если сервис доступен меньше, чем 95% времени. Это 36 часов в месяц!

В классическом понимании SLA — это юридический документ с обязательствами. Ещё это удобный термин, который применим и внутри компании. Мы в Авито стремимся давать гарантии на внутренние компоненты. Они работают как договоренности между командами разработки.

Как определяем SLO в Авито

SLO каждого микросервиса Авито определяют нефункциональные требования (non-functional requirements, NFR). Это описание того, как должен работать микросервис, как быстро отвечать, какие ответы сервиса считаются ошибками в контексте надёжности системы. Все NFR хранятся в одном репозитории с микросервисом, в файле nfr.toml.

Пример простого описания NFR в файле:

[default.handlers]
error_codes = [503, 504]
[[handlers]]
name = "/wordCounter_GET"
type = "REST"
latency = "100ms"
error_codes = [500, 400]

Кроме вышеперечисленного, можно описать:

• MaxRPM,

• Размер очереди,

• Скорость прохождения или обработки события,

• Freshness данных.

Все эти и другие аспекты мы описываем в nfr.toml как нефункциональные требования к системе.

Эти NFR - и есть требования к системе, SLO. Мы следим какой процент операций в сервисе удовлетворял NFR.

По метрикам из NFR мы визуализируем, какие проблемы есть в каждой операции микросервиса.

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

Что такое бюджет ошибок

Бюджет ошибок — это число ошибок, которое можно допустить за определённый период: недельный, месячный, квартальный и другие. К примеру, мы задекларировали SLO (ожидаемую надёжность) микросервиса на уровне 99,9%. За последние 30 дней он получил один миллион запросов. Значит, 1000 ошибок — это бюджет на месяц. 

Бюджет ошибок можно представить в виде пустого бассейна. Каждая ошибка — это капелька, которая его заполняет. Если за 30 дней у нас уже случилось 300 ошибок, то в запасе есть ещё 70% бюджета.

Зачем считать бюджет ошибок

1. Микросервис становится более предсказуемым. Его работа регламентирована в NFR и пользователи понимают, чего от него ожидать. Например, вы указываете, что микросервис ответит за 300 мс в 99,9% случаев. Если к нему подключатся другие микросервисы, то они будут ожидать ответ за это время. Тогда их разработчики смогут писать бизнес-логику с опорой на эти значения. 

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

Как считать бюджет ошибок

Когда мы считаем NFR-надежность, мы независимо считаем нарушение каждого аспекта NFR (у нас отдельно существует как метрика нарушений NFR в целом, так и метрики нарушения КАЖДОГО аспекта - времени ответа, ошибки etc).

В примере NFR выше, мы учитываем ошибки 400, 500, 503, 504, и Latency 100 мс. В нашем случае в бюджет ошибок входят только ситуации, когда микросервис нарушает нефункциональные требования: отдаёт ответ с одним из этих кодов или отвечает слишком медленно.

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

Вы можете поэкспериментировать и найти свой оптимальный период для оценки. Возможно он окажется короче.

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

Что делать, если вы истратили бюджет ошибок

1. Пересмотрите NFR. Возможно, они неправильно описаны, слишком жёсткие или требуют обновления. Например, в описание могли случайно добавить лишние коды ошибок.
   Кроме того, требования часто формируются до ввода сервиса в прод и не учитывают нюансов его реализации. Допустим, сервис физически не может отвечать быстрее, чем за 500 мс, а мы заложили в NFR Latency = 100 мс. Это рабочий момент, который нужно просто уточнить и исправить. 

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

3. Запланируйте больше времени на работу с техническим долгом в следующем спринте.

Четыре подхода к подсчёту надёжности Авито

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

Мы проверили множество способов для того, чтобы научиться считать надёжность нашего приложения Авито в целом. Мы считаем надёжность каждого «кирпичика» — NFR каждого сервиса, общую надёжность по всем методам, надёжность по точкам входа. А сейчас внедряем надёжность по пользовательским сценариям, о ней расскажу в следующий раз.

Предыдущая статья: Пишем хорошие компоненты, которые захочется переиспользовать, а плохие — не пишем