Авито раскрыл, как считает надёжность и чем его бюджет ошибок отличается от Google

Одна из крупнейших российских интернет-платформ публично объяснила, как превращает «надёжность» из лозунга в цифры. Иван Тарасов, TUL Architecture Governance в техплатформе Авито, на Хабре разобрал всю цепочку: от SLI, SLO и SLA до нефункциональных требований (NFR) для REST/RPC-сервисов, шин данных и кастомных операций. Отдельный акцент в материале на том, что бюджет ошибок в Авито отличается от канонического описания в книге Google SRE. По словам автора, это намеренное решение.

Важная оговорка: в нашем распоряжении только анонс статьи. Конкретные пороги, формулы и аргументы Авито раскрыты в полной версии, поэтому ниже разбираем структуру подхода и контекст, а не пересказываем детали, которых мы не видели.

Что входит в систему

Тарасов руководит командами, одна из которых, SLA, создаёт условия для повышения технической надёжности и развивает инструменты NFR и сценарии стабильности. Из анонса следует такой набор элементов:

• SLI, SLO и SLA как базовая иерархия: что измеряем, какую цель ставим, что обещаем.
• Stability Rate и Uptime как две разные метрики, разницу между которыми автор разбирает отдельно.
• NFR для REST/RPC-сервисов, то есть требования к синхронному взаимодействию.
• NFR для шин данных, где надёжность измеряется иначе, чем у запроса с ответом.
• NFR для кастомных операций, которые не укладываются в стандартные шаблоны.
• Бюджет ошибок, намеренно отличающийся от версии Google SRE.

Перечень показывает главное: Авито не ограничивается одним числом «девяток» на сервис. Разные типы интерфейсов получают разные способы измерения.

Почему канон Google не взяли как есть

В книге Google SRE бюджет ошибок равен единице минус SLO. При цели 99,9% за 30 дней это около 43 минут допустимой недоступности. Пока бюджет не исчерпан, команда выкатывает релизы свободно. Когда он закончился, приоритет смещается на стабилизацию. Механизм простой и снимает вечный спор между разработкой и эксплуатацией.

На практике у такой модели есть слабые места. Она предполагает, что SLO осмысленно задан и что одинаково измерим для всех сервисов. В компании с сотнями сервисов, очередями, шинами и нестандартными операциями это условие часто не выполняется. Авито заявляет, что учёл это и сознательно изменил модель. Какие именно параметры изменены, из анонса не видно, и гадать здесь не стоит.

Stability Rate против Uptime

Uptime традиционно показывает долю времени, когда сервис считался доступным. Метрика удобна для отчётности, но груба: сервис может отвечать, и при этом отдавать ошибки части пользователей. Название Stability Rate указывает на оценку по результатам операций, а не по календарю. Точное определение Авито приводит в статье, но сам факт разделения двух метрик говорит о зрелом подходе. Минуты простоя и доля неуспешных операций описывают разные вещи, и бюджет ошибок зависит от того, какую из них взять за основу.

Как применить у себя

Даже без деталей реализации из публикации можно вынести несколько рабочих выводов:

• Разделяйте типы интерфейсов. Для синхронных вызовов, шин данных и фоновых операций нужны разные SLI. Единый шаблон даст красивый дашборд и плохую картину.
• Не путайте доступность и успешность. Если команда отчитывается только Uptime, часть деградаций останется невидимой.
• Фиксируйте отклонения от канона письменно. Если вы меняете модель бюджета ошибок, зафиксируйте причины и ограничения, иначе через год никто не вспомнит, зачем это сделано.
• Привязывайте NFR к архитектурному процессу. В Авито этим занимаются в рамках Architecture Governance. Требования, которые проверяются на этапе проектирования, дешевле, чем исправления после инцидента.

Оригинальная статья на Хабре стоит прочтения тем, кто строит SRE-практики в большой распределённой системе: пример заметен именно тем, что компания открыто объясняет, где и почему она ушла от общепринятой схемы.