Return to site

Tech.Rocks/Google :

Retours d'expérience
SRE (Site Reliability Engineering)

13 Juin 2019 - Avec Google Cloud

Par Aurore MALHERBES

Première partie

Culture d'entreprise par Bruno Reboul (Professional Services de Google Cloud), un retour sur mise en place SRE par différents clients de Google.

Qu’est ce qu’un SRE ?

L’équipe SRE (Site Reliability Engineer) est une équipe d‘ingénieurs qui intervient sur des produits, des plateformes qui ont besoin de stabilité. Ces ingénieurs ont de solides compétences systèmes, couplées à des compétences de développement.

Attention, il n’est pas nécessaire d’avoir un SRE dans toutes les équipes. Google compte 35000 développeurs pour autant il y a seulement 2200 SRE. Un produit comme Gmail a besoin de SREs car il est critique pour le business de l’entreprise, un outil interne peut par exemple être indisponible pendant 2 heures sans avoir un réel impact sur l’entreprise.

Comment répartir la charge entre Dev et Ops ?

Un des premiers principes du SRE est le management du toil budget. Le toil c’est l’ensemble des tâches opérationnelles qui sont répétitives et manuelles et dans leur état actuel, non scalable sans faire grossir l’équipe opérationnelle. Faire un déploiement de hot fix manuellement est par exemple considéré comme du toil.

Le management du toil budget est assez simple en théorie : il consiste à dire que l’équipe SRE ne doit pas passer plus de 50% de son temps à faire du toil. En d’autres termes l’équipe SRE doit passer à minima 50% de son temps à développer des outils, notamment d’automatisation, qui contribuent à la stabilité de la plateforme et par voie de conséquence à la réduction du futur toil.

Que se passe-t-il alors en cas de dépassement du seuil des 50% ? Si le toil dépasse 50% les demandes repartent vers l’équipe de développement, elles sont donc soient gérés par elle directement soit mises en attente. Ceci nécessitent donc d’avoir aligné l’ensemble de l’équipe technique en amont avec un fort support de la part du management.

Comment un error budget permet à votre entreprise d’innover ?

Généralement quand on parle de disponibilité on parle d’un nombre de 9 : mon application doit être disponible 99,9% (trois 9)ou 99,99%(quatre 9) du temps. Ce pourcentage est calculé en faisant le ratio de “good time” sur du “bad time”, par exemple le nombre de requêtes réussies sur le nombre total de requêtes.

L’error budget c’est le résultat de 100% auquel on soustrait votre objectif de disponibilité, donc par exemple 0,1% ou 0,01%.

Dès qu’un incident en production se passe, par exemple la mise en production d’une feature qui fait monter le taux de réponse 500 à une requête, l’error budget diminue. Lorsqu’il atteint 0, il n’y a plus de budget donc plus de releases possibles tant qu’il n’est pas redevenu positif. L’error budget c’est donc le terrain de jeu, le budget d’innovation de votre produit.

C’est pour cette raison qu’il est important de faire des Canary release : mettre en production une nouvelle release d’abord pour 10% des utilisateurs, puis 20%, etc, etc. L’objectif de disponibilité étant défini par le business avec l’implication de l’équipe technique, l’error budget est connu et accepté par tous, c’est acté qu’un passage de celui-ci dans le négatif implique un feature freeze.

Comment se fixer des objectifs ?

Lorsque l’on fixe un SLI, Service Level Indicator et un SLO, Service Level Objective, associé, il faut tout d’abord fixer un objectif atteignable, puis un objectif aspirationnel. Le premier objectif doit être atteignable pour ne pas se démotiver.

Il faut également prendre en compte que tenter de rajouter un 9, c’est 10 fois moins d’erreurs mais 10 fois plus de budget.

Comment gère-t-on des incidents avec une équipe SRE ?

Chez Google, les développeurs sont responsables du monitoring : si quelque chose tombe et qu’on ne l’avait pas vu, c’est sous leur responsabilité. Cependant si la plateforme de monitoring tombe, c’est alors la responsabilité des opérationnels.

Lors d’un incident, c’est le moment où l’on doit être le plus collaboratif et ceci notamment au moment du post mortem, où l’on demande COMMENT et non POURQUOI afin de ne pas tomber dans le blâme.

Conclusion

Ce premier talk nous a permis de poser les bases des concepts principaux du SRE et de voir qu’ils pouvaient être accessibles à toutes les tailles d’équipe technique. Il est intéressant de remarquer aussi que ces outils, notamment l’error budget peuvent être un outil de communication sur l’impact de la dette technique avec des personnes non techniques. Enfin un élément marquant, car très souvent oublié, est la (bonne) manière de mener un post-mortem afin qu’il ne produise pas un effet de blâme

Deuxième Partie

Un retour d'expérience d'Elizabeth LeBeau (Directrice of Engineering de Sqreen, ancienne Manager SRE chez Google) sur la mise en place de l'approche SRE chez Sqreen : éduquer les Software Engineers à l'approche SRE.

L’objectif d’une équipe de SRE est de construire des systèmes fiables à partir de systèmes peu fiables. Pour cela elle développe des outils, des services afin de répondre à des problèmes opérationnels.

Beth nous a donné une métaphore sur l’évolution du métier de SRE. Auparavant les immeubles américains étaient construits avec un escalier de secours autour de la structure, c’était un ajout à la structure de base. Puis au fil du temps, les systèmes de secours ont été construits intrinsèquement aux immeubles, ils ont été incorporés à la structure afin de répondre au mieux à leur devoir : être disponibles et efficaces en cas d’urgence.

Pour autant toutes les entreprises tech n’ont pas toujours une équipe de SRE, c’est par exemple le cas actuellement de Sqreen. Ainsi pour construire des systèmes stables il faut se poser les cinq questions suivantes lors de la phase de conception de ce système :

1) Your dependencies WILL break

Que ce soit un package open source, un produit que l’on paye ou autre, il faut avoir en tête que cette dépendance va un jour ne pas fonctionner ou créer des données incorrectes. Votre système doit être prêt s’en rendre compte et à le prendre en compte.

2) What would happen if I turn this service off ?

De la même manière qu’un service tiers peut arrêter de répondre, une brique de vos systèmes peut cesser de fonctionner. Vous devez soit savoir le gérer, soit à minima savoir comment votre système réagit, pour ne pas être surpris lorsque cela arrivera. Cela vous permettra alors de d’identifier plus vite la source de l’incident.

3) Your operators are not perfect

L’erreur est humaine et ce proverbe à deux conséquences. La première est qu’il faut automatiser un maximum de tâches afin de minimiser les interventions humaines. La deuxième est qu’il faut toujours faire des post-mortems, lors desquels, comme le soulignait déjà Bruno Reboul, il faut chercher comment c’est arrivé et non pourquoi afin d’éviter que cela se reproduise.

4) Isolation can be the best friend of SRE

Isoler les composants de son système permet de réduire les impacts. Il est par exemple intéressant d'avoir une redondance géographique de votre infrastructure, ainsi si une zone tombe, une autre zone géographique peut prendre le relais. Il est important de noter qu’il faut également isoler les retry, ainsi si une réaction en chaîne impacte une zone elle ne doit pas pouvoir faire tomber l’ensemble des zones géographiques.

5) It will break no matter what you do

Quoique vous fassiez il y aura des problèmes, c’est pour cela qu’il est tout d’abord important de faire des Canary releases afin que ces problèmes n’impactent qu’une fraction de la plateforme. Dans un second il est important de pouvoir annuler (rollback) n’importe quelle release à n’importe quel moment afin de revenir dans un état stable et d’investiguer sur le problème calmement.

Conclusion

Deux concepts se retrouvent presque mot pour mot dans les deux interventions: l’importance de demander comment c’est arrivé et non pourquoi, ainsi que la nécessité de faire des Canary Releases pour repérer au plus tôt les erreurs.

Enfin, Beth nous partage que l’outillage du SRE est relativement facile à mettre en place, mais que le plus gros challenge, et qui est le sien actuellement chez Sqreen, est souvent culturel.

Table ronde  Panel autour le choc de culture qu'est le SRE dans une entreprise. Avec la participation de Nicolas Helleringer (Head of SRE chez Criteo -- équipe de 140 personnes), d'Elizabeth LeBeau et Bruno Reboul. La table ronde a été préparée et menée par Dimitri Baeli (CTO chez LesFurets.com). 

Quand êtes vous devenus familiers du concept de SRE ?

Nicolas :

Quand j’ai rejoint Criteo il y a 6 ans. En 2013, Criteo a passé un cap en terme de nombres de serveurs, 3 000 à ce moment là et les opérations manuelles n’étaient plus possible. Inspirés par les connaissances qu’ils avaient de Google nous avons commencé à automatiser le plus de choses possibles. Pour moi implémenter le SRE c’est un moyen de d’opérer à grande échelle.

Beth :

La première fois que j’ai entendu parlé de SRE, c’était au téléphone par un recruteur and ça ne m’a pas vraiment tentée. Mais après une discussion très intéressante j’ai décidé de tenter et j’ai trouvé ça génial ! Bruno :

Je l’ai découvert à Google, avec le concept d’error budget qui est fantastique !

Nicolas, tu m’as dit que insuffler la culture SRE a pris trois ans, pourquoi ?

C’est une question de definition of done. Nous avions passé le cap de l’automatisation bien avant la fin des trois ans mais changer l’état d’esprit des gens prend du temps. Vous ne pouvez pas programmer l’esprit de quelqu’un ;)

Nous étions 35 dans l’équipe SRE et nous l’avons team après teams. Aujourd’hui nous sommes 140.

Avez-vous des conseils pour démarrer ce changement de culture ?

Beth :

Mon meilleur conseil est de concevoir les incidents où n’importe quoi qui arrive comme une expérience. Acceptez que votre plateforme est faillible, c’est un moyen d’apprendre.

Bruno :

Le soutien du management est VRAIMENT important pour aligner tout le monde sur l’error budget, la gestion du toil ou la manière de mener les post mortems. Une fois que tout le monde est dans le même bateau, que tout le monde comprend l’objectif, c’est plus facile d’amorcer le changement culturel.

Parlez nous de votre plus gros succès ou échec sur la partie Ops

Nicolas :

J’ai sous estimé la courbe d’apprentissage pour un ops qui souhaite devenir SRE. Lorsque vous êtes SRE vous devez maîtrisez un certain nombre d’outils de développement auxquels vous n’étiez pas exposé avant et certains peuvent être difficiles à utiliser au début.

Beth :

J’ai beaucoup appris sur la communication pendant un incident. Vous devez avoir quelqu’un en dehors de l’équipe pour gérer la communication pendant l’incident. Les stackeholders doivent être tenus au courant de l’avancement de la résolution.

Bruno :

J’ai appris quand vous faîtes un roll forward, c’est à dire que fixer un bug, une régression avec un patch, vous tuer l’innovation, car vous créez de la dette technique sur laquelle il sera plus difficile de construire plus tard. Alors que si vous rollback, vous n’impactez pas les utilisateurs et vous prenez le temps de coder un patch proprement sans créer de dette technique.

Parlez nous de votre plus gros succès ou échec sur la partie Dev

Nicolas :

Quand ça marche très bien, le SRE c’est un peu comme de la magie noire et les équipes deviennent trop confiantes. Alors les développeurs l’utilise, l’utilise énormément, un jour des développeurs on fait tourner 10 000 conteneurs pour tester leur modèle de prédiction/

Ainsi, trop de confiance est aussi un échec, vous devez établir un cadre avec des limites d’utilisation pour ne pas éprouver votre système sans que ce soit nécessaire.

Beth :

Je n’ai pas réussi à mettre en place les canary releases et l’équipe voulait toujours tester manuellement les nouvelles fonctionnalités. Les dysfonctionnements étaient alors très longs à détecter. Nous devrions accepter que la technologie peut être meilleure que nous, notamment pour identifier les problèmes le plus vite possible.

Bruno :

Notre plus gros succès côté dev a été d’acter que lors que l’on trouve une façon de supprimer une “hard dependency” (un service externe, un package open source, etc), tout le monde travaille à sa suppression qui doit alors avoir lieu à la prochaine release. En effet, comme on l’a dit précédemment, si une “hard dependency” ne fonctionne plus, ça peut être tout votre service qui ne fonctionne plus.

C’est une ligne spéciale de l’error budget.

Vous nous avez donné les avantages du SRE, quels sont les inconvénients ?

Nicolas :

Vous supprimez des rôles et vous en créer de nouveau, par conséquent vous créer de nouveau problèmes. Mais ceci n’est pas un problème qui se manifeste tant que vous n’êtes pas plus de 20 dans votre équipe technique.

Beth :

Diminuer la vélocité de l’équipe et chercher absolument à optimiser pour le 0.1% des cas.

Bruno :
Je vois deux inconvénients. Plus de fiabilité est égal à plus de coûts et le management entre une équipe de SRE et une équipe d’ops / SysAdmin plus traditionnel peut être compliqué car vous avez en quelque sorte la “shiny team” et l’équipe traditionnelle.

En tant que CTO quelle est la chose que je dois faire après ce talk ?

Beth :

Posez vous une question : où en suis-je en terme de fiabilité ? Ensuite définissez des SLOs.

Bruno :

Demandez vous si vous en avez vraiment besoin et si plus de fiabilité va réellement impacter votre business. Vous ne devez pas appliquer le SRE partout car cela implique un coût.

Nicolas :

Quelle est LA mission de votre entreprise ? Ensuite aligner tout le monde sur cet objectif.

Conclusion

Dimitri synthétise alors la table ronde en ces quelques mots. SRE est un outil chirurgical pour la haute disponibilité du cœur de votre business, porteur d’un très probable changement culturel d’associer les Dev et les Ops à la loi de la disponibilité : détecter très tôt les erreurs, étudier par des Post-Mortem comment elles arrivent, apprendre à découpler les systèmes et surtout savoir financer l’ensemble à sa juste valeur.

Alors quelle partie de votre système à besoin de haute disponibilité ? Quel est votre performance et votre budget sur le sujet ?

Cet article a été écrit par Aurore Malherbes, CTO de Padok qui accompagne des entreprises dans la migration de leurs infrastructures sur le Cloud avec Kubernetes et dans la construction de leur équipe SRE.

Rejoignez-nous sur le Slack de la communauté Tech.Rocks pour nous donner vos retours d’expérience !

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly