Avito dévoile comment il mesure la fiabilité et en quoi son budget d'erreurs diffère de celui de Google

L'une des plus grandes plateformes internet russes explique publiquement comment elle transforme la « fiabilité » d'un slogan en chiffres. Ivan Tarasov, TUL Architecture Governance au sein de la plateforme technique d'Avito, a détaillé sur Habr toute la chaîne : des SLI, SLO et SLA jusqu'aux exigences non fonctionnelles (NFR) pour les services REST/RPC, les bus de données et les opérations personnalisées. L'article insiste notamment sur le fait que le budget d'erreurs chez Avito diffère de la description canonique du livre Google SRE. Selon l'auteur, il s'agit d'une décision délibérée.

Précision importante : nous ne disposons que de l'annonce de l'article. Les seuils, les formules et les arguments d'Avito figurent dans la version complète. Nous analysons donc ci-dessous la structure de l'approche et son contexte, sans résumer des détails que nous n'avons pas vus.

Ce que comprend le système

Tarasov dirige plusieurs équipes. L'une d'elles, SLA, crée les conditions pour améliorer la fiabilité technique et développe les outils NFR ainsi que les scénarios de stabilité. L'annonce permet d'identifier l'ensemble d'éléments suivant :

• SLI, SLO et SLA comme hiérarchie de base : ce que l'on mesure, quel objectif on fixe, ce que l'on promet.
• Stability Rate et Uptime comme deux métriques distinctes, dont l'auteur analyse séparément la différence.
• Des NFR pour les services REST/RPC, c'est-à-dire des exigences pour les interactions synchrones.
• Des NFR pour les bus de données, où la fiabilité se mesure autrement que pour une requête avec réponse.
• Des NFR pour les opérations personnalisées, qui ne rentrent pas dans les modèles standard.
• Un budget d'erreurs volontairement différent de la version de Google SRE.

Cette liste montre l'essentiel : Avito ne se contente pas d'un seul nombre de « neuf » par service. Chaque type d'interface a sa propre méthode de mesure.

Pourquoi le canon Google n'a pas été repris tel quel

Dans le livre Google SRE, le budget d'erreurs est égal à un moins le SLO. Pour un objectif de 99,9% sur 30 jours, cela représente environ 43 minutes d'indisponibilité tolérée. Tant que le budget n'est pas épuisé, l'équipe déploie ses versions librement. Une fois qu'il est consommé, la priorité passe à la stabilisation. Le mécanisme est simple et met fin à l'éternelle querelle entre développement et exploitation.

En pratique, ce modèle présente des points faibles. Il suppose que le SLO est défini de façon pertinente et qu'il est mesurable de la même manière pour tous les services. Dans une entreprise avec des centaines de services, des files d'attente, des bus et des opérations non standard, cette condition n'est souvent pas remplie. Avito affirme en avoir tenu compte et avoir modifié le modèle en connaissance de cause. L'annonce ne permet pas de savoir quels paramètres exacts ont été changés, et il vaut mieux ne pas spéculer.

Stability Rate contre Uptime

L'Uptime indique traditionnellement la part du temps pendant laquelle le service était considéré comme disponible. La métrique est pratique pour le reporting, mais grossière : un service peut répondre tout en renvoyant des erreurs à une partie des utilisateurs. Le nom Stability Rate suggère une évaluation fondée sur le résultat des opérations, et non sur le calendrier. Avito donne la définition exacte dans son article, mais la séparation de ces deux métriques témoigne en soi d'une approche mature. Les minutes d'arrêt et la part d'opérations échouées décrivent deux réalités différentes, et le budget d'erreurs dépend de celle que l'on choisit comme base.

Comment l'appliquer chez soi

Même sans les détails de mise en œuvre, la publication permet de tirer plusieurs conclusions concrètes :

• Distinguez les types d'interfaces. Les appels synchrones, les bus de données et les opérations en arrière-plan exigent des SLI différents. Un modèle unique donnera un beau tableau de bord et une mauvaise image de la réalité.
• Ne confondez pas disponibilité et taux de succès. Si l'équipe ne rend compte qu'avec l'Uptime, une partie des dégradations restera invisible.
• Documentez par écrit les écarts par rapport au canon. Si vous modifiez le modèle de budget d'erreurs, consignez les raisons et les limites, faute de quoi personne ne se souviendra dans un an pourquoi ce choix a été fait.
• Rattachez les NFR au processus d'architecture. Chez Avito, cela relève de l'Architecture Governance. Des exigences vérifiées dès la conception coûtent moins cher que des correctifs après un incident.

L'article original sur Habr mérite la lecture de ceux qui construisent des pratiques SRE dans un grand système distribué : l'exemple est remarquable précisément parce que l'entreprise explique ouvertement où et pourquoi elle s'est éloignée du schéma habituel.