Stratégies SRE : normalisez le processus de conception des SLOs

Si vous demandez à trois Site Reliability Engineers la définition de SRE, vous obtiendrez probablement au moins cinq réponses différentes ! Une mise en œuvre de DevOps, un rôle, un ensemble de pratiques, un changement culturel, un titre accrocheur… Si ces définitions varient et ne correspondent pas forcément à celles que l’on peut trouver dans des ouvrages de référence sur le sujet, il existe néanmoins un point fondamental sur lequel SRE se différencie des autres méthodes de travail : les « Service Level Objectives » (SLO) ou Objectifs de Niveau de Service. 

Conçus intentionnellement pour être simples à comprendre, les SLO sont, en revanche, souvent difficiles à définir dans la pratique. Même si les spécificités d'un SLO varient selon les industries et les secteurs verticaux, nous avons toutefois constaté que les équipes ayant réussi à les mettre en place pour leur workloads partagent certaines pratiques et stratégies.

Première étape, la collaboration entre les équipes « produit », développement et SRE est essentielle, de sorte qu’elles partagent le même niveau de compréhension du workload, tout particulièrement en termes de points stratégiques du parcours client ou CUJ pour Critical User Journey. La plupart du temps, cette étape conduit les équipes à formaliser par écrit les CUJ sous forme de flux détaillé ou de diagramme séquencé. La maturité de la relation existante entre ces trois équipes (développement, produit et SRE) intervient directement dans le niveau d’effort à fournir pour faire aboutir cette première étape. En effet, partager une vision commune des attentes des utilisateurs sur un workload constitue un prérequis pour définir des SLOs efficaces.

Bien que la modélisation d’un parcours utilisateur et sa décomposition en SLOs relève d’un véritable savoir-faire et qu’il n’existe pas deux applications identiques, vous pouvez toutefois ancrer cette première étape et les échanges qui l’accompagnent autour de quelques points clefs. 

La question principale que nous vous recommandons de garder à l'esprit tout au long du processus est la suivante : « Qu'est-ce qui intéresse mes utilisateurs ? ». En formulant votre processus de réflexion de cette manière, vous éviterez les problèmes de mise en œuvre et les stratégies qui s’éloignent des attentes des utilisateurs. D'autres points doivent également être pris en compte :

• Le parcours comprend-il des moments clefs au cours desquels l’utilisateur peut décider de ne pas poursuivre son action ?

• Quelle(s) partie(s) du parcours sont mesurables et quelle(s) partie(s) ne le sont pas ? (Typiquement, certaines parties peuvent dépendre d’un tiers)

• Quelles parties d’un parcours client sont communes à de nombreux clients et donc susceptibles d'être factorisées en tant que CUJ à part entière (exemple : login) ?

• Quelles parties du parcours peuvent être mesurées globalement et quelles autres parties doivent être séparées en raison de différences de criticité, de variabilité de la demande ou d'autres facteurs ?

• Quelles étapes du parcours sont strictement dépendantes les unes des autres ?

Armé des réponses à ces questions, d'un diagramme de requête détaillé (une représentation des étapes suivie par l’utilisateur en interagissant avec l’application) et du code de votre application, vous pouvez commencer à rédiger vos SLOs. Avant de vous jeter sur vos consoles de monitoring, nous vous conseillons de documenter vos SLOs en renseignant clairement les détails techniques qui vous ont conduit à choisir ces SLOs. Nous vous proposons un modèle pour vous aider à mettre en place ce processus de documentation. Si vous disposez d'un compte Google, vous pouvez en faire une copie en cliquant sur ce lien. Outre le modèle vierge à compléter, vous trouverez également des exemples déjà renseignés qui peuvent vous servir de référence lors de la création de vos propres spécifications. 

Que vous exploitiez ce modèle ou non, nous vous recommandons d'utiliser les éléments suivants pour documenter vos SLO :

• Soyez pointilleux sur les spécifications techniques - elles auront de l'importance lors de la mise en œuvre.

• Conservez une section décrivant les clarifications, mises en garde et/ou compromis réalisés au moment de la conception.

• Choisissez le bon endroit où effectuer des mesures - assurez-vous que c'est faisable.

• Méfiez-vous des statistiques non agréables (comme les moyennes, médianes et percentiles qui dépendent de leur sous-ensemble de données et ne peuvent pas être combinés en statistiques globales) pour vos SLO de latence.

• Veillez à ce que les périodes de conformité soient cohérentes pour l'ensemble des SLOs de vos workloads :

• Nous recommandons les valeurs suivantes :

• 28 jours glissants pour les besoins opérationnels (comme les alertes sur le budget)

• Trimestre calendaire fixe pour la priorisation (actions à entreprendre pour améliorer le service) et l’analyse rétrospective (lookback, analyse des causes et conséquences des violations des SLOs).

• Changelog (journal des modifications apportées à un SLO) : incluez-en un, même si votre outil de documentation dispose d'un historique des versions, afin de pouvoir suivre plus aisément les changements majeurs.

• Partagez votre documentation SLO dans un endroit accessible par toute votre équipe et les différentes parties prenantes dans l'entreprise (directions métiers notamment).

• Une fois votre PRD SLO finalisé (le document de conception des SLO), traitez votre implémentation comme du code et stockez-la dans votre système de contrôle des versions.

• N'oubliez pas le principe de développement DRY (Don't repeat yourself) ! Pour rappel, ce principe vise à réduire les répétitions et duplications pour éviter les incohérences et permettre une maintenance plus aisée).

Nous espérons que ces recommandations ainsi que le modèle proposé vous seront utiles et vous permettront d’être plus efficaces sur la conception de vos SLOs. Si vous avez besoin d'un outil pour mettre en œuvre vos SLOs, pensez à Google Cloud SLO Monitoring, solution qui permet de créer des SLOs pour n'importe quelle métrique disponible dans Google Cloud Monitoring. Elle détecte aussi automatiquement les erreurs de budget, favorisant ainsi la mise en place d’alertes vous informant dès que les dépenses mensuelles dépassent un certain seuil.  Si vous ne vous sentez pas encore à l’aise avec ce processus de conception des SLOs ou si votre équipe a besoin d’aide sur un des points ci-dessus, n’hésitez pas à solliciter notre Team « reliability engineering professional services ». Elle peut vous accompagner dans votre démarche. Pour plus d'informations, consultez les pages cloud.google.com/sre ou contactez l'équipe chargée de votre compte Google Cloud.