Que se cache-t-il derrière un SLA ?

Sans SLA (Service Level Agreement), pas de baromètre du support applicatif, mais une porte ouverte à une augmentation du temps, des ressources et du budget de gestion de projet. Un SLA consiste en un contrat entre un prestataire de services et ses clients internes ou externes, afin d’anticiper tout déséquilibre au niveau de l’infrastructure, organisationnel et/ou financier, et ainsi de couper court à tout risque d’insatisfaction des utilisateurs.

Il assure une compréhension commune des contraintes et des attentes en termes de disponibilité, débit, latence et sécurité des services fournis aux utilisateurs ou aux clients. Cet accord, qui pourrait donner lieu à des obligations financières et légales, nécessite de déterminer au préalable les SLOs (Service Level Objectives) ou indicateurs sur lesquels les équipes d’ingénierie internes se concentreront pour respecter ces SLAs.

Garder constamment à l’esprit les clients 

Le SLO est la valeur cible interne au sein des équipes d’ingénierie ou des unités d’exploitation. Il est basé sur les mesures de SLIs (Service Level Indicators) liés aux services. Ces mesures se doivent d’être très représentatives de ce que l’utilisateur devrait expérimenter, telles que la rapidité de chargement d’une page Web. Ces SLOs sont nécessaires et même très pertinents pour faciliter la conversation entre les parties prenantes.

Définir les SLOs sous-entend de garder continuellement à l’esprit les clients, parce qu’ils révèlent l’expérience à laquelle ils s’attendent avec les applications et les services. Au sein de l’entreprise, les parties couramment impliquées dans ces SLOs sont un mélange de responsables produit, d’ingénieurs produit, d’ingénieurs en charge de la fiabilité (SRE) et de cadres supérieurs.

Suivant l’entreprise, la conception des SLOs peut provenir de la direction ou non, sachant que ces objectifs se composent de sous-ensembles de SLIs et de SLOs dont la responsabilité est répartie au sein des équipes. Il est important que les équipes et la direction comprennent ce que sont les SLOs et pourquoi ils sont définis ainsi pour l’équipe d’ingénieurs. De manière générale, chaque fois qu’un nouveau service est introduit dans l’environnement d’une entreprise, elle doit être en mesure de définir automatiquement un ensemble spécifique de SLIs et SLOs.

Monitorer les SLOs pour visualiser les expériences client

Lorsqu’il s’agit d’exploiter et de surveiller les SLOs, l’équipe en charge des SLAs doit avoir une vue d’ensemble de haut niveau et gérer les SLOs par équipe d’ingénieurs produit, qui en sont néanmoins responsables. Ce sont donc eux qui produisent leurs tableaux de bord, s’y référent périodiquement, et envoient des alertes si nécessaire. Une valeur clé des SLOs est appelée « budget d’erreur » correspondant à une marge de manœuvre, c’est-à-dire le temps maximal d’indisponibilité avant d’atteindre le SLO. Et c’est ce qui intéresse aussi les équipes d’ingénieurs, parce que cela les guide dans leurs prises de décisions sur une période donnée.

Même si plusieurs millions d’indicateurs peuvent être collectés, tous ne sont pas très révélateurs de l’expérience client. Pour avoir une vision approfondie de ce que vos clients expérimentent exactement et assurer le niveau de disponibilité et de performance attendu, il est nécessaire de prendre du recul, d’identifier quels sont les workflows réels des utilisateurs de vos applications, quels sont les services qu’ils utilisent, quelles sont leurs attentes quand ils interagissent avec vos applications, puis d’assurer le monitoring à tous ces niveaux. Ainsi, il faut examiner quels SLIs pertinents sont à associer à l’expérience utilisateur escomptée, les mettre en place en les adaptant et en considérant qu’il s’agit d’une période de temps donnée, puis d’itérer sur cette base.

Au-delà des indicateurs techniques, un outil collaboratif

Un défi pour tous ceux qui établissent des SLOs est que ceux-ci soient intégrés par l’ensemble de l’entreprise pour être utiles à tous. Par exemple, la création minutieuse de SLOs devrait permettre de remarquer une augmentation des incidents ou des pannes qui ne respectent pas les SLOs et causent une consommation du budget d’erreur.

Cela pourrait être un indicateur pour suggérer de ralentir le développement de nouvelles fonctionnalités et se concentrer davantage sur la disponibilité. Un autre défi, lorsque des équipes mettent en place des SLOs et que certains ne sont pas respectés, est de ne pas utiliser ces SLOs pour trouver des coupables. Ils demeurent un outil de collaboration qui favorise le dialogue, et qui fournit des informations pour prendre des décisions éclairées.

Mes recommandations à l’attention d’une entreprise qui migre une application vers le cloud seraient d’être orientée client, de démarrer lentement, de ne pas établir 20 SLOs d’un coup, et de les utiliser comme fil de discussion favorisant le travail collectif, sans incriminer. Les SLOs ont pour vocation d’impliquer les intervenants, de responsabiliser chacun sans attribuer de blâme. Bien que ces SLOs semblent très techniques, en fin de compte, ils sont très orientés métier. En effet, ils donnent à toutes les équipes d’ingénierie le sens du business parce qu’ils sont vraiment centrés sur le client et sur les équipes. Les SLOs sont une question de services, mais aussi de personnes.