Les services n’ont pas besoin d’être fiables [Video]

Victor : Vous êtes très bien connu dans la communauté de l’observabilité et de la communauté SRE. J’ai suivi votre travail pendant un certain temps pendant mon séjour à Confluent, je suis donc très heureux de parler avec vous. Peux-tu nous parler un peu de toi s’il te plait ? Comme tu fais quoi ? Et que faites-vous ces jours-ci?

Liz : Sûr. J’ai donc travaillé comme ingénieur en fiabilité de site pendant environ 15 ans, et j’ai pris ce pivot intéressant il y a environ cinq ans. Je suis passé d’ingénieur en fiabilité de site au sein d’équipes individuelles comme Google Flights ou Google Cloud Load Balancer à un plaidoyer pour la communauté SRE au sens large. Il s’avère qu’il y a plus de personnes en dehors de Google qui pratiquent la SRE qu’il n’y en a à l’intérieur de Google qui pratiquent la SRE.

Je voulais aider tous les membres de la communauté à partager les meilleures pratiques et à avoir des systèmes plus gérables. Ce voyage il y a deux ans et demi m’a donc amené à travailler chez Honeycomb, où j’aide les gens à réfléchir à la manière de faciliter le débogage de leurs systèmes.

Victor : C’est génial. Et avant d’entrer dans cet aspect, je veux explorer un peu votre passé. Est-il juste de dire que vous avez inventé la déclaration selon laquelle la « classe SRE implémente DevOps ?

Liz : Oui, c’est définitivement quelque chose que Seth Vargo et moi avons proposé. Et puis c’est devenu un chapitre de Le classeur de fiabilité du site.

Victor : Alors parlons un peu de ça. Dites-nous votre définition de DevOps et en quoi c’est différent de SRE.

Liz : Oui, je pense qu’il y a ce modèle intéressant qui s’est produit au début des années 2000. Différents besoins organisationnels ont surgi pour résoudre la question de savoir comment nous devons expédier des logiciels plus rapidement et de manière plus fiable. Que se passe-t-il si le logiciel que nous écrivons est critique ? Et l’un de ces mouvements était DevOps, qui était un mouvement culturel qui visait vraiment à permettre aux ingénieurs logiciels d’exécuter leur propre logiciel pour pratiquer une sorte de livraison continue, une sorte d’opérations agiles.

Et l’autre phénomène que nous avons vu était SRE, qui s’est produit chez Google, où Ben Treynor Sloss, le fondateur de SRE, a déclaré que nous devions adopter une approche différente pour faire fonctionner les systèmes de Google. C’était un ensemble de problèmes similaire et presque une solution similaire à ces problèmes. Pour commencer, les solutions ont été encodées dans les structures organisationnelles particulières de Google.

Et au fil du temps, ce qui s’est passé, c’est que ces deux communautés étaient au départ un peu à la gorge l’une de l’autre pour savoir qui est arrivé en premier, dont l’approche est la bonne approche. Mais en tant que l’une des personnes de Google qui a eu beaucoup d’interactions avec la communauté extérieure, j’ai regardé cela et je me suis dit : « Attendez une seconde. Les principes DevOps – chacun d’entre eux – sont mis en œuvre dans l’ingénierie de la fiabilité des sites. Et nous pourrions appeler cela quelque chose de différent, mais c’est comme une mise en œuvre concrète et avisée des principes DevOps. »

DevOps vous donne une grande liberté de pensée sur la façon dont vous faites les choses. Il y a quelques bonnes pratiques de la communauté. Mais je pense que ce que je vois de plus en plus, c’est que les communautés d’ingénierie DevOps et de fiabilité de site se transforment en une communauté qui commence à être connue dans le domaine sous le nom d’ingénierie de plate-forme.

Au lieu d’avoir des spécialistes des opérations, vous construisez une infrastructure pour les équipes produit de votre entreprise, en déterminant quelle est la bonne plate-forme, comment y contribuer, comment rendre les développeurs productifs. Cela englobe donc plus que de simples opérations de production. Cela englobe des choses comme la livraison continue et englobe des choses comme la construction d’infrastructures et les composites, des choses comme les mesures de fiabilité – une sorte de domaine plus large qui, je pense, a un peu plus d’influence.

Victor : C’est donc un très bon point. Et généralement, lorsque vous parlez de cette fiabilité, pour de nombreuses personnes qui ne le font pas au quotidien, cela peut sembler quelque chose d’intangible ou de très difficile à mesurer. De quoi s’agit-il exactement et comment mesureriez-vous la fiabilité ? Parce que les gens veulent que leurs systèmes soient fiables et fonctionnent 24h/24 et 7j/7. Mais si ça marche, ça marche. Si ce n’est pas le cas, ce n’est pas le cas. Qu’y a-t-il entre les deux et comment mesurez-vous cela comme une chose floue entre les deux ? Quelle serait la bonne métrique à regarder ?

Liz : Oui. Lorsque je présente aux gens l’idée d’un objectif de niveau de service d’un budget d’erreur, cela leur épate un peu. Mais la façon dont je l’ancre concrètement est de souligner que la fiabilité de votre service n’a pas d’importance. Cela n’a pas de sens de dépenser des milliards de dollars pour lancer des satellites dans l’espace pour rendre votre produit plus fiable ou obtenir cette nanoseconde ou femtoseconde supplémentaire de disponibilité. Si finalement, à la fin de la journée, les gens y accèdent à partir de leurs téléphones, les téléphones sont à court de batterie et les téléphones à court de signal cellulaire.

Votre téléphone portable, au mieux, sera fiable à environ 99,95%. Alors pourquoi voudriez-vous rendre votre service six-9s, sept-9s, huit-9s fiable ? Cela n’a tout simplement pas de sens. C’est un mauvais investissement d’argent, et c’est aussi un mauvais investissement de votre énergie. Toute l’énergie que vous investissez en surinvestissant dans la fiabilité aurait pu être consacrée à l’innovation.

Alors c’est un peu à vous. Déterminez les exigences minimales du client en matière de fiabilité. Sont-ils d’accord avec l’actualisation de temps en temps si cela ne fonctionne pas correctement ? Et après cela, vous pouvez investir tout le reste dans des fonctionnalités. Cela aide donc en quelque sorte à quantifier ce compromis.

Victor : Est-ce lié à l’accord de niveau de service avec nos clients indiquant que c’est le niveau de service que nous fournissons et pourquoi vous nous payez de l’argent ? Nous parlons principalement des équipes SaaS, mais cela s’applique également aux équipes qui exécutent des logiciels internes. Il n’est peut-être pas disponible en dehors d’Internet, mais de nombreuses entreprises exploitent des plates-formes internes. Le système doit juste être fiable.

Liz : Oui, c’est une très bonne question. Les objectifs de niveau de service ne nécessitent pas nécessairement que vous ayez un accord de niveau de service. Et souvent, votre SLO et SLA seront différents même s’il y a un client externe avec un SLA.

Il faut penser au SLA. C’est un contrat de vente, et c’est un contrat légal. Quel est le montant minimum de fiabilité, sinon nous devons vous payer de l’argent ? Ou vous rembourser. Mais quand nous pensons au bonheur des clients, nous devrions viser à rendre les clients heureux et ravis, pas seulement, vous savez, ne pas nous poursuivre.

Je pense donc que ce concept de réflexion sur ce que nous définissons comme une bonne expérience utilisateur se traduit indépendamment du fait que vous servez des clients internes ou externes. Déterminez ce dont vos clients ont besoin.

Un chef de produit est un chercheur en expérience utilisateur. Ces personnes peuvent être très utiles pour essayer de comprendre les besoins de vos utilisateurs, qu’ils soient internes ou externes.

Victor : Oui, et la chose importante pour moi, comme vous l’avez mentionné, nous voulons que nos utilisateurs soient ravis, mais nous ne voulons pas que nos utilisateurs nous poursuivent. C’est donc une chose très importante pour la façon dont les ingénieurs de l’organisation commerciale, par exemple, voient les choses. Les ingénieurs veulent construire les systèmes que l’utilisateur aura plaisir à utiliser.

Liz : Vous voulez que vos ingénieurs sachent si quelque chose risque de violer le SLO bien avant d’en arriver au point d’implication des SLA. C’est en quelque sorte la raison pour laquelle vous devez être un peu plus agressif avec vos SLO.

Victor : Oui. Pouvez-vous nous donner de bons exemples de structuration des objectifs de niveau de service pour les équipes ? Peut-être que certains des pointeurs vers des lectures intéressantes où ils peuvent en apprendre un peu plus à ce sujet ?

Liz : Je recommande donc fortement des choses comme Google Ingénierie de la fiabilité du site livre. Et il y a en fait une publication récente de mon ami Alex Hidalgo intitulée Mise en œuvre des objectifs de niveau de service, et les deux sont publiés par O’Reilly.

Mais je pense que lorsqu’il s’agit de le comprendre concrètement, parlons à travers un exemple concret. Ainsi, chez Honeycomb, nous sommes une entreprise qui comprend vos systèmes de production. Nous devons ajuster la télémétrie de vos systèmes de production pour encapsuler les transactions transitant par vos microservices et votre application.

Ainsi, l’un de nos objectifs de niveau de service est que si vous nous envoyez un événement, 99,99% du temps, nous allons l’ingérer avec succès et le rendre disponible pour requête. Cela signifie que moins d’un événement sur 10 000 peut être supprimé. Cela ne veut pas dire que nous visons la perfection. Mais cela signifie également qu’il s’agit d’un seuil plus strict qu’un événement sur 100 ou un sur 1 000 qui peut être supprimé. C’est trouver un équilibre qui nous permet d’innover et de faire évoluer la production, tout en préservant votre confiance dans la fidélité des données que nous vous transmettons.

C’est donc un peu l’exemple d’un SLO, qui dit, vous savez, c’est notre objectif – 99,9 % – et la façon dont nous le mesurons. Et la période sur laquelle nous le mesurons, par exemple, nous disons que nous visons quatre nuits sur une fenêtre de 30 jours.

Et grosso modo, si nous avions une panne complète, nous ne pourrions le faire que pendant 4,3 minutes avant de dépasser notre SLO et de dire : « OK, nous devons réinitialiser. Nous devons revoir la fiabilité. » Pour revenir à votre point sur le temps d’arrêt complet vers le haut ou vers le bas. Ce n’est ni haut ni bas. La réponse est parfois c’est un peu de haut en bas.

Fondamentalement, à un état stable, nous pourrions nous attendre à servir peut-être un sur dix au cinquième. Une requête sur 100 000 peut expirer ou être abandonnée, et c’est juste un bruit naturel dans le système. Ou nous pourrions accidentellement servir comme un pour cent d’erreurs pendant un petit moment. Et si nous servons un pour cent d’erreurs, nous pouvons tolérer cela pendant un peu plus de 4,3 minutes. Nous pouvons tolérer cela pendant, je pense, 400 minutes. Cela nous laisse suffisamment de temps pour répondre et corriger l’anomalie.

On arrête de penser aux choses en noir et blanc, en haut ou en bas. Nous pensons aux choses et aux changements et aimons, à quel point est-ce vraiment grave ? Eh bien, cela dépend de la distance à laquelle nous sommes.

Victor : Oui, et je pense que vous avez mentionné un très bon point à propos de ces chiffres. Ces mesures – les seuils nous permettent d’avoir la capacité interne de faire les changements que nous voulons. Donc, ce n’est pas du genre : « Nous étions déjà en panne ce mois-ci pendant deux minutes. Par exemple, pouvons-nous nous permettre d’être en panne une minute de plus pour déployer rapidement une fonctionnalité très importante ? » C’est quelque chose dont vous parliez.

Corrigez-moi si je me trompe, quand nous parlons du budget d’erreur. Vous pouvez vous permettre d’échouer, et cela devrait être un peu comme dans l’état d’esprit qu’il est acceptable d’échouer parce que les ordinateurs sont notoirement peu fiables – les gens encore plus notoirement peu fiables. Des erreurs vont donc arriver. Nous pouvons donc contourner ce problème, mais il devrait y avoir un certain seuil.

Et au point de ce seuil et de cette innovation, que pensez-vous de « bouger vite, casser les choses » – cet état d’esprit qui a été mis en avant sur Facebook à l’époque ? Mais il y a probablement un juste milieu quelque part, n’est-ce pas, que vous ne pouvez pas avancer lentement parce que pendant cette période et l’innovation de cette année, vous mourrez en tant qu’entreprise ?

Liz : Oui, c’est là que je pense que nous avons reformulé les valeurs d’Honeycomb récemment. L’une des choses qui est restée est cette idée que rapide et proche de la droite est mieux que parfait, et vous devez toujours être proche de la droite.

Vous n’avez pas nécessairement besoin de mettre le vernis parfait sur tout, car vous devez innover. Je pense donc que ce qui résume une grande partie de notre réflexion à ce sujet, c’est qu’il y a certaines choses que vous devez absolument faire correctement.

Par exemple, la vie privée est une chose où vous perdez définitivement la confiance des gens si vous vous trompez…