SLI/SLO/SLA: измерение надёжности системы — Павел Лакосников, Авито

• Павел рассказывает о важности трех метрик для микросервисных приложений.  

• В компании Авито появился инцидент-менеджмент для централизованного решения проблем.  

• Возник вопрос о том, насколько эффективно справляется инцидент-менеджмент.  

• SLI Service Level Indicator - метрики, которые показывают уровень обслуживания.  

• Примеры SLI: трафик, нагрузка на сервер, время закрытия тикетов.  

• Договоренности о действиях при превышении порогов SLI.  

• Amazon определяет ошибки как 500 или 503 коды ответа.  

• Недоступный сервис - все запросы получают 500 или 503 код за пятиминутный интервал.  

• Amazon компенсирует деньги за высокий уровень качества сервиса.  

• В микросервисных приложениях много компонентов, каждый из которых влияет на общую надежность.  

• Введение нефункциональных требований NFR для описания поведения микросервисов.  

• Проверка соответствия микросервисов заявленным требованиям с помощью тулинга.  

• Установка критериев качества надежности сервиса, например, 99.95%.  

• Определение бюджета ошибок на основе скользящего окна за 30 дней.  

• Цель - достичь 0.1% ошибок в скользящем окне.  

• Пример: за месяц сервис обработал миллион запросов, что позволяет совершить тысячу ошибок.  

• Ошибки включают медленные ответы, неполные ответы и деградации.  

• Важно понимать, на что тратится бюджет и в какой момент времени.  

• Бюджет ошибок можно представить как бассейн, в который капают ошибки.  

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

• Сервис стремится выйти на плато, где работает равномерно.  

• Если бюджет превышен, команда пересматривает свои ожидания и снижает критерии.  

• Важно сохранять предсказуемость сервиса для потребителей.  

• Команды могут брать на себя обязательства по техдолгу или откладывать фичи.  

• В случае высокой стоимости ошибок можно ввести мораторий на изменения.  

• Это помогает стабилизировать систему и избежать потерь.  

• Временный мораторий практикуется в одной команде эпизодически.  

• Бюджет ошибок дает разработчикам простор для маневров и экспериментов.  

• Команды могут проводить дополнительные эксперименты без страха превышения лимита.  

• Это улучшает тайм-метрики и позволяет командам спокойно работать.  

• В больших микросервисных приложениях сложно учитывать ошибки каждого микросервиса.  

• Важно учитывать все страницы, а не только главные.  

• В Авито решили использовать воронки пользовательских сценариев для учета ошибок.  

• Пользователи ведут себя непредсказуемо, что затрудняет создание воронки.  

• Воронка меняется в зависимости от дня недели и других факторов.  

• Решили отказаться от идеи воронки и перейти к другому подходу.  

• Ввели понятие журналистской надежности, чтобы понять, заметит ли журналист сбой.  

• Посчитали точки входа пользователей на сайт и их вклад в общее количество переходов.  

• Получили итоговую надежность сайта, основанную на этих данных.  

• Более 90% первых заходов на сайт начинаются с определенных страниц.  

• Построили графики, показывающие вклад каждой страницы в надежность.  

• Метрика помогает понять, когда пользователи сталкиваются с ошибками.  

• Метрика легко рассчитывается и понятна для бизнеса.  

• Помогает понять влияние на пользователей и их поведение.  

• Недостаток: требует периодического пересчета коэффициентов.  

• Планируют пересчитать воронки, чтобы сделать их более короткими и надежными.  

• Выбирают устоявшиеся страницы и сценарии для расчета надежности.  

• Считают надежность как приложений, так и сервисов.  

• Внедряют механизм противовесов для предотвращения манипуляций с надежностью.  

• Планируют валидацию значений, выбивающихся из медианы.  

• Обсуждают, как люди могут манипулировать данными, чтобы снизить общую надежность.  

• В компании поощряется улучшение продукта и личная ответственность.  

• Метрики сервиса отслеживаются разработчиками, а процент покрытия фарами отображается на карточке сервиса.  

• Бизнес-логика и сценарии учитываются при анализе метрик.  

• Инженерная культура компании способствует росту ответственных разработчиков.  

• Техдолг не является определяющим фактором, но важен для компании.  

• Техпроекты помогают массово внедрять изменения, не связанные напрямую с бизнесом.  

• Сервисы используют публичные хосты, такие как тинькофф.ру.  

• Инфраструктурные задачи решаются точечно и редко.  

• Важно поддерживать связи между сервисами для корректной работы.  

• Ошибки 404 и 503 не считаются критичными и не закладываются в бюджет ошибок.  

• Ошибки 504 указывают на проблемы с нагрузкой и требуют антидодоса.  

• Мониторинг фокусируется на пользователях, используя различные системы мониторинга.  

• Мониторинг микросервисов и приложений различается.  

• Важно сместить уровень мониторинга ближе к пользователю.  

• Используются различные системы мониторинга для отслеживания поведения пользователей.