Grâce au DevOps, un nouveau métier est apparu au début des années 2000 : le SRE, ou Site Reliability Engineer. Relativement peu d'entreprises l'implémentent aujourd'hui, mais il est toujours intéressant de connaître ce métier, ne serait-ce que pour mettre un nom sur l'implémentation concrète du DevOps dans une entreprise.
Un peu d'histoire
Le SRE est apparu en 2003 chez Google, lorsque Ben Treynor fut embauché pour diriger une équipe de 7 développeurs, faisant tourner un environnement de production. Le but de cette équipe était de garantir que les sites de Google fonctionneraient de manière efficace et stable.
Quand on s'appelle Google, et que l'on gère des systèmes à plusieurs péta-octets, répartis sur plusieurs continents, il est nécessaire de penser à de nouveaux paradigmes d'exploitation, basés sur l'automatisation. Il est humainement impossible de gérer plusieurs dizaines de serveurs.
Depuis, le rôle de SRE s'est largement déployé en dehors des murs de chez Google, notamment dans des entreprises comme Apple, Facebook, Microsoft, etc.
Il n'y a pas que chez Google que les SRE existent. Une entreprise française, Clever Cloud, hébergeur de cloud computing, n'a qu'une équipe de 5 développeurs s'occupant de la production de dizaines de milliers d'applications et garantissant le maintien en condition opérationnelle d'applications de plusieurs centaines de clients. Pour ce faire, l'équipe a poussé l'automatisation des déploiements au maximum, développant notamment des robots afin de détecter rapidement des pannes, problèmes ou incompatibilités logicielles, et proposant de la remédiation automatique, sans intervention humaine.
Je vais détailler les tenants et aboutissants du rôle de SRE dans la suite de ce chapitre. Mais avant, il est nécessaire de définir quelques mots clés, afin de comprendre la suite du cours.
Service Level Indicator
Cela peut être le temps de traitement d'une application, le nombre d'erreurs générées lors d'une ingestion de données, ou même le nombre de déploiements requis pour corriger un bug. Chaque équipe peut définir ses propres indicateurs, qu'elle suivra au quotidien. Ces indicateurs sont propres à chaque métier et ont une forte valeur pour l'équipe qui les a mis en place. Ces indicateurs servent de référence lors de la définition du SLO.
Service Level Objective
Ce SLO est partagé afin d'éviter tout problème entre les deux parties. Il doit suivre les préceptes S.M.A.R.T. (spécifique, mesurable, acceptable, réaliste, temporellement défini). Des exemples de SLO peuvent être le temps de réponse d'une requête, le temps de disponibilité d'un service ou le nombre d'appels acceptés en moins de 5 minutes. Le SLI sert de base pour le SLA.
Service Level Agreement
Ce dernier indicateur est donc extrêmement important, dans le sens où des clients peuvent partir du service s'il n'est pas respecté scrupuleusement. C'est aussi l'indicateur le plus suivi par le SRE lors de la mise en place d'une telle équipe.
Le rôle du SRE
Le SRE a deux rôles :
il passe 50 % de son temps à faire des tâches "ops", comme de l'astreinte, corriger des problèmes en production ou faire des interventions manuelles ;
il passe les autres 50 % de son temps à automatiser tout ou partie de ses tâches, et à développer de nouvelles fonctionnalités.
C'est là la grande force du SRE à mon sens, car du temps lui est alloué et dédié à automatiser des tâches répétitives. De fait, le SRE aide à créer des applications scalables et "self-healed".
Les piliers du SRE
Le métier du SRE repose sur 5 piliers issus des piliers CALMS que nous avons vus au chapitre 2 :
réduire les silos organisationnels (Share) ;
accepter les pannes comme normales (Culture) ;
implémenter des changements graduels (Lean) ;
s’appuyer sur des outils et de l’automatisation (Automatisation) ;
tout mesurer (Mesure).
Le SRE implémente alors ces piliers comme suit.
Réduire les silos organisationnels :
le SRE partage la possession des applications avec les développeurs, pour créer des responsabilités partagées ;
le SRE utilise les mêmes outils que les développeurs, et vice versa.
Accepter les pannes comme normales :
le SRE accepte le risque ;
le SRE quantifie les pannes et la disponibilité d’une manière normée, en utilisant le SLI et le SLO ;
le SRE mandate des post-mortem irréprochables.
Implémenter des changements graduels :
le SRE encourage les développeurs et les Product Owners à avancer rapidement en réduisant les coûts de panne.
S’appuyer sur des outils et de l’automatisation :
le SRE dispose d'une charte pour automatiser les tâches subalternes (appelées "labeurs"), à l'extérieur.
Mesurer tout :
le SRE définit des moyens normatifs pour mesurer les valeurs ;
le SRE croit fondamentalement que le fonctionnement des systèmes est un problème logiciel.
Les quatre signaux dorés
Le SRE définit quatre signaux principaux à observer constamment. Ces quatre signaux sont appelés les quatre signaux dorés : latence, trafic, erreurs et saturation.
Ces quatre signaux sont extrêmement importants, car ils sont essentiels pour garantir une haute disponibilité des applications. Je vais détailler dans la suite ces quatre signaux, et vous donner des outils capables de surveiller ces métriques.
Latence
La latence est le temps qu'il faut pour envoyer une demande et recevoir une réponse. La latence est généralement mesurée du côté du serveur, mais elle peut aussi être mesurée du côté du client pour tenir compte des différences de vitesse du réseau. L'équipe d'exploitation a le plus de maîtrise sur la latence côté serveur, mais la latence côté client sera plus pertinente pour les clients finaux.
Le seuil cible que vous choisissez peut varier en fonction du type d'application. Un système automatisé, comme une API ou un serveur, peut nécessiter des temps de réponse beaucoup plus rapides qu'un humain sur un téléphone mobile. Vous devez également suivre séparément la latence des requêtes réussies et des requêtes échouées, car les requêtes échouées échouent souvent rapidement, sans traitement supplémentaire.
Trafic
Le trafic est une mesure du nombre de demandes qui circulent sur le réseau. Il peut s'agir de requêtes HTTP vers votre serveur web ou votre API, ou de messages envoyés à une file d'attente de traitement. Les périodes de pointe de trafic peuvent exercer une pression supplémentaire sur votre infrastructure et la pousser jusqu'à ses limites, ce qui peut avoir des effets en aval.
C'est un signal clé, parce qu'il vous aide à différencier les problèmes de capacité des configurations système inappropriées, qui peuvent causer des problèmes, même en période de faible trafic. Pour les systèmes distribués, il peut également vous aider à planifier la capacité à l'avance, pour répondre à la demande à venir.
Erreurs
Les erreurs peuvent vous renseigner sur les erreurs de configuration de votre infrastructure, les bugs dans votre code ou les dépendances non résolues. Par exemple, un pic du taux d'erreur pourrait indiquer la défaillance d'une base de données, ou une panne de réseau.
Suite à un déploiement de code, il peut indiquer des bugs dans le code qui ont survécu aux tests, ou qui n'ont fait surface que dans votre environnement de production. Le message d'erreur vous donnera plus d'informations sur le problème exact. Les erreurs peuvent également affecter les autres métriques, en réduisant artificiellement la latence, ou les tentatives répétées qui finissent par saturer d'autres systèmes distribués.
Saturation
La saturation définit la charge sur votre réseau et les ressources de votre serveur. Chaque ressource a une limite au-delà de laquelle les performances se dégradent ou deviennent indisponibles. Ceci s'applique aux ressources telles que l'utilisation du CPU, l'utilisation de la mémoire, la capacité du disque et les opérations par seconde. Il faut comprendre la conception et l'expérience de votre système distribué, pour savoir quelles parties de votre service pourraient devenir saturées en premier. Souvent, ces mesures sont des indicateurs avancés, de sorte que vous pouvez ajuster la capacité avant que la performance ne se dégrade.
Atteindre la limite de saturation peut affecter votre service de différentes manières. Par exemple, lorsque le CPU est plein, cela peut entraîner des réponses retardées, l'espace de stockage plein peut entraîner une défaillance des écritures sur le disque, et la saturation du réseau peut entraîner la chute de paquets.
Le mot de la fin
Et voilà ! C'est bientôt la fin de ce cours. J'espère que vous y voyez maintenant plus clair sur ce qu'est le métier de SRE. Je vous donne rendez-vous dans le quiz de ce cours, pour tester vos connaissances quant à la démarche DevOps et sa mise en place en entreprise. Ça a été un plaisir de vous partager ma passion du DevOps !
