Dans l’environnement SRE, assurer la présence de systèmes robustes est un élément extrêmement important. Dans cet article, notre expert Fabio Mora explique pourquoi la SRE est si fondamentale et comment réagir en cas d’accident.
Construire des systèmes robustes
Si une grande partie des problèmes peuvent être résolus avec de l’argent ou en comptant sur des professionnels hautement qualifiés, la solution ne s’avère pas toujours bon marché ni sécurisée pour l’entreprise (pour plus d’informations, voir le concept de « facteur d’autobus / bus factor »).
Maintenir un système stable impliquant autant d’opérations manuelles est quelque chose de vraiment complexe, puisqu’il est plus sujet aux pannes et aux incidents. Un tel système devient insoutenable à long terme et risque d’entraîner l’équipe dans des situations stressantes, voire peut-être même à la perte de ses composants. Cependant, en corrigeant les petites erreurs au fur et à mesure et en poursuivant la maintenance, sans ne rien laisser s’accumuler, vous pouvez obtenir un excellent compromis.
Stratégie Shift Left
Il est souvent plus pratique de commencer à travailler sur un produit avec un kick-off technique sur lequel réfléchir et planifier les composants du système et son architecture logicielle, puis passer des architectures aux microservices. Le tout, avec la bonne conception d’API et de protocoles, pour étudier les modèles d’utilisation et identifier les coûts des ressources nécessaires.
Cette technique est appelée stratégie de Shift Left : le support SRE commence dès la conception (non pas lorsque le trafic utilisateur est déjà arrivé) et se poursuit jusqu’à la mise en œuvre du produit. Il est essentiel d’employer des ressources et des personnes de manière consciente, qu’il s’agisse d’ordinateurs ou de temps de génie logiciel. Cette activité de conception transverse est fondamentale et continue. Elle occupe, en effet, la majeure partie du temps dans une journée SRE.
Dans la plupart des cas, lorsque l’on est face à des systèmes « mal conçus » mais déjà mis en place (par exemple si les utilisateurs peuvent déjà naviguer sur le site), la solution la plus commode est de re-concevoir les parties “pauvres” et les réécrire en partant de zéro.
La réalisation de ces tâches pour un SRE consiste en une sorte de programmation « appliquer l’informatique à l’informatique » : c-à-d intervenir avec des compétences plus fortes que celles des autres dans ce domaine. C’est d’ailleurs la valeur d’un bon SRE et ce qui le distingue des autres.
La connaissance des systèmes d’exploitation, des protocoles réseau, l’étude des pipelines de versions, le contrôle de la qualité des logiciels et savoir passer en toute confiance entre la télémétrie et les systèmes d’alarme sont particulièrement fondamentaux. Définir les objectifs de SLA/SLO (Service Level Objective), la capacité à gérer la complexité et à travailler dans l’urgence, nécessitent des connaissances transversales : il s’agit en fait d’écrire un logiciel pouvant être utilisé pour gouverner d’autres systèmes logiciels et, “last but not least”, l’améliorer par petites étapes pour le garder stable et simple.
Interaction entre le SRE et les membres de l’équipe de développement
L’interaction entre le SRE et les membres de l’équipe de développement n’est donc pas une simple réallocation des rôles, mais une manière différente de penser la gouvernance des produits. Le bilan est positif pour les deux équipes, si l’on pense à faire en sorte que les responsabilités des ops soient réduites au minimum. La façon d’y parvenir est de créer des systèmes « continus », qui permettent des changements constants et sécurisés dans les grandes architectures système, les clusters, les applications, les bases de données, les réseaux. Et ce, quelle que soit la situation dans laquelle vous vous trouvez : au bureau devant un poste de travail et quatre écrans , ou attendre à une porte d’aéroport avec une connexion cellulaire. Il est important de poursuivre cet objectif jusqu’à ce qu’un énorme système puisse devenir gérable par une petite équipe de personnes ordinaires.
Une autre façon de concevoir des systèmes stables, consiste à concevoir avec des équipes sur des plateformes standards et distribuées, plus faciles à gérer et offrant aux professionnels une mobilité entre les équipes. Pensez à une compagnie aérienne par exemple : souvent la flotte d’avions et leurs configurations sont similaires, de sorte que le personnel au sol peut être formé sur quelques types de machines très précises ; il en va de même pour les pilotes avec leurs qualifications, le personnel navigant et le personnel de maintenance. Un système standard et une gamme de produits finis à maintenir permettent de créer un standard et de pouvoir passer d’une équipe à l’autre au sein d’une même organisation.
Cette stratégie n’a peut-être pas d’effet direct sur les utilisateurs, mais elle permet de simplifier les systèmes et constitue la clé de l’amélioration. Un bon SRE est avant tout un bon Ingénieur Logiciel : il doit aimer résoudre des problèmes hétérogènes et complexes, bien savoir ce que fait un ordinateur de bas niveau et connaître son système d’exploitation, interagir avec les développeurs, avoir des compétences dans des domaines intéressants et horizontaux et, enfin, une bonne prédisposition pour créer des automatismes et supprimer les soi-disant « goulots d’étranglement ».
Le SRE est le ciment entre l’équipe technique et les systèmes de production, il facilite la compréhension de la complexité que les développeurs ne comprennent pas immédiatement, car ils sont experts dans d’autres domaines. Ce n’est cependant pas un exercice sans risque, car la nécessité d’être rapide doit se conjuguer avec celle de transmettre ses connaissances à son collègue. Quand quelque chose fonctionne et est compris individuellement, il y a une impulsion, une urgence à continuer de travailler pour faire simple : on ne peut pas s’arrêter à la première mise en œuvre, mais il faut chercher des solutions techniques toujours plus simples. En général, dans la vie de tous les jours, une équipe de développement n’a peut-être pas un besoin urgent de connaître les détails de ce qui se trouve « sous le capot » d’un cloud, mais lorsque le besoin s’en fait sentir, elle doit avoir les outils pour le faire. De plus, les personnes et les équipes changent, et dans les technologies de l’information, pour résoudre un gros problème, il ne suffit pas d’ajouter des personnes à un groupe mais il faut des processus et de longues procédures d’intégration, de mentorat et de programmation en binôme, avant qu’une personne puisse être productif.
Mais ce n’est pas seulement le SRE qui est responsable du produit, bien au contraire : c’est surtout l’équipe de développement. En fait, même les développeurs doivent être inclus dans la rotation des équipes de garde pour voir et utiliser leur produit en action. Personne n’aime être réveillé la nuit ou sortir d’une salle de cinéma pour ouvrir un ordinateur portable et se connecter au réseau pour que le système soit opérationnel. La responsabilité du produit incombe toujours à l’équipe de développement, qui connaît les détails et guide les décisions. Pour être prêt, il faut des outils de diagnostic sur les produits, il faut observer les graphiques et les alarmes, mais surtout il faut faire beaucoup de pratique et faire de la prévention avec des simulations et des pauses aléatoires sur lesquelles expérimenter et apprendre (appelé Chaos Ingénierie).
Les incidents
Lorsqu’un incident survient, si un NOC (Network Operating Core, le personnel qui supervise le réseau mondial 24h/24 et 7j/7) est présent dans l’entreprise, celui-ci est aussi impliqué dans la culture SRE. Il ne se contente pas de regarder des graphiques, il a des tâches beaucoup plus proactives. Il doit faciliter la communication, suivre la disponibilité et les événements, automatiser les procédures de rapport et d’alerte, catalyser le travail des Ops, en plus d’initier le diagnostic et guider l’équipe, peut-être avec l’aide du chatbot et de l’apprentissage automatique. De l’autre côté de l’alerte, il pourrait y avoir une petite perturbation sur un flux vidéo, ou une succursale entière de point de vente ou un réseau téléphonique bloquant des milliers d’utilisateurs.
Lorsqu’un incident survient, les objectifs sont au nombre de deux :
- Minimiser l’impact dès que possible
- Empêchez que cela se reproduise
Le flux classique de gestion des incidents implique :
- Gérer et atténuer l’événement (dépannage)
- Rechercher la cause première (tri)
- Aborder une phase de suppression d’impact (atténuation)
- Faire face à un processus post-mortem
- Vérifier la consolidation et l’évolution du système (solution à long terme)
Post-Mortem
L’outil indispensable d’un SRE est donc le Post-Mortem, ou le rapport qui est rédigé lorsqu’un incident s’est produit ou que quelque chose a mal tourné.
“Nous avons besoin d’un processus mental totalement transparent et honnête, sous peine de nullité. Il ne s’agit pas d’un procès accusatoire, mais d’une reconstruction chronologique des événements survenus, des moments critiques, des causes, des effets, des données perdues et des travaux de restauration générés – où nous avons eu de la chance et où non.”
L’objectif est de trouver l’erreur déclenchante et de trouver une solution pratique pour s’assurer que cette même famille de problèmes ne se reproduise pas – par conséquent, pour corriger les procédures. A la fin du post-mortem vous obtenez une liste de “bugs, suivis et à corriger”. C’est le moteur de l’amélioration continue : bien expliquer ce qui ne va pas doit faire partie de la culture SRE. Il est également important de redimensionner le travail de manière durable : l’idéal étant de gérer quelques incidents par poste, il faut un juste équilibre entre les heures de travail et de repos. Ce n’est pas seulement une question de respect et d’équilibre envers soi-même, mais aussi de sécurité, d’efficacité et de responsabilité envers l’équipe.Une personne fatiguée n’aura pas l’attention ni la concentration suffisante que requiert cette profession, ce qui facilite grandement les erreurs. Le même principe dirige les rythmes des pilotes, chauffeurs, médecins et autres professions où le facteur humain est hautement considéré.
En résumé : les post-mortem, les rétrospectives et la réflexion corrective à long terme sont les trois outils fondamentaux pour mettre en pratique une démarche d’amélioration. Sinon, vous ne pourrez pas apprendre de vos erreurs.
Pour en savoir plus sur notre contenu thématique SRE consultez également :
