Qu’est-ce que l’ingénierie de fiabilité des sites (SRE) ? 

Les ingénieurs en fiabilité des sites créent de la valeur client en garantissant la fiabilité des cycles de développement logiciel et de réponse aux incidents, ce qui vient enrichir ces approches de plusieurs avantages :

• l’observabilité de la santé des services. Les équipes SRE sont impliquées dans de nombreux domaines différents des systèmes d’une entreprise, ce qui leur donne une vue d’ensemble de la façon dont ces systèmes sont connectés et fonctionnent ensemble. Les ingénieurs en fiabilité des sites savent comment suivre les métriques, les logs et les traces de nombreux services disparates pour produire une image holistique de la santé du système, et ainsi obtenir le contexte dont ils ont besoin en cas d’incident ;
• des liens plus forts entre les développeurs et les opérations. Les ingénieurs en fiabilité des sites renforcent les relations entre les développeurs et l’ITOps en introduisant l’automatisation et en améliorant la communication, ce qui profite aux deux équipes. La SRE peut révéler et corriger des faiblesses du pipeline de publication et instaurer une responsabilité vis-à-vis de l’astreinte et de la réponse aux incidents ;
• la modernisation du NOC. Les centres d’opérations réseau (NOC) s’appuient traditionnellement sur un travail humain répétitif pour trier les incidents et les alertes puis les acheminer vers la bonne personne. La SRE modernise ces processus grâce à l’automatisation et au machine learning, qui permettent d’orienter automatiquement les alertes vers la personne responsable de la résolution du problème ;
• l’organisation des structures de support et des workflows d’alerte. Les ingénieurs en fiabilité des sites apportent une connaissance approfondie en matière de création de processus de support efficaces et d’optimisation des alertes. Ils peuvent déterminer le meilleur planning d’astreinte et les règles d’alerte idéales, identifier la meilleure façon d’acheminer les alertes à travers les systèmes et assumer eux-mêmes certaines des responsabilités de garde ;
• la mise en évidence des problèmes en production. Grâce à une visibilité approfondie sur les environnements de production, les ingénieurs en fiabilité des sites sont responsables de l’observabilité de la santé du système et des services, ce qui leur permet d’identifier les défaillances susceptibles d’avoir un impact sur les clients. Lorsque ces problèmes se manifestent, les équipes peuvent mettre en œuvre des corrections dès les premières étapes de la feuille de route du produit ;
• le pilotage des équipes d’ingénierie. Entre autres choses, les ingénieurs en fiabilité des sites aident à améliorer, enrichir et appliquer les bonnes pratiques, et à soutenir la résilience interdépartementale à l’échelle de l’entreprise.

Toutes les pratiques SRE visent à améliorer la fiabilité des systèmes et elles peuvent être regroupées en cinq grandes catégories :

• la disponibilité. L’équipe SRE est chargée de maintenir la disponibilité des systèmes et des services une fois qu’ils sont en production, en commençant par définir des objectifs de niveau de service (SLO), des accords de niveau de service (SLA) et des indicateurs de niveau de service (SLI) pour le service sous-jacent. Les SLI décrivent les métriques, comme la disponibilité ou la latence des requêtes, que les entreprises utilisent pour mesurer le niveau de service fourni aux clients. Les SLO définissent les moyens de mesurer les performances du site ou du service (une disponibilité de 99,99%, par exemple) en fonction de ces SLI. Les deux sont ensuite utilisés pour créer le SLA, qui explique la fiabilité attendue du service et la réaction de l’équipe si cet objectif n’est pas atteint ;
• la performance. Une fois la disponibilité stabilisée, les équipes SRE peuvent se concentrer sur l’amélioration des performances du service. La latence, la vitesse de chargement des pages et d’autres mesures de performances n’ont pas nécessairement d’impact sur la disponibilité globale, mais elles peuvent se dégrader progressivement et dissuader les clients d’utiliser le service si cela se produit trop fréquemment. Les équipes SRE assistent les équipes de développement et participent au support des applications, corrigent les bugs et identifient de manière proactive les problèmes de performances dans l’ensemble du système, en traitant progressivement les défauts de performances et les correctifs de moindre envergure à mesure que la fiabilité globale du service s’améliore ;
• la supervision. Les équipes SRE doivent déterminer les éléments à superviser puis mettre en œuvre les solutions de supervision appropriées, selon la façon dont les différents services mesurent le temps de disponibilité et les performances. En bout de ligne, elles doivent mettre en œuvre une solution offrant une vue holistique de la santé du système aux équipes d’ingénierie ou IT, ce qui est l’un des plus grands défis de la SRE ;
• la réponse aux incidents. Les équipes SRE sont essentielles pour la réponse aux incidents, et plus précisément la mobilisation d’un incident (à ne pas confondre avec la gestion des incidents, qui est le système d’enregistrement et de suivi d’audit). Les membres de l’équipe SRE doivent être disponibles pour traiter, expliquer et examiner tout incident survenant dans le système. Cela peut inclure l’audit des workflows de production, des processus, des critères d’alerte et d’autres facteurs liés à un déploiement. En règle générale, les équipes SRE utilisent un playbook d’astreinte qui guide leur intervention face à un événement. Elles conduisent également des post-mortem sans blâme pour comprendre ce qui a causé un problème particulier, l’empêcher de se reproduire et documenter toute amélioration à apporter ;
• la préparation. En résumé, les équipes SRE aident les équipes de développement et IT à mieux se préparer, comprendre la santé de leurs services et réagir rapidement et efficacement aux incidents. L’intégration d’ingénieurs en fiabilité des sites dans le développement et l’IT permet aux développeurs d’en savoir plus sur l’environnement de production et aide les équipes ITOps à s’impliquer plus tôt dans le cycle de vie du développement. Cet effort consiste pour une grande part à préparer le déploiement, en travaillant avec les ingénieurs pour assurer l’observabilité du nouveau service. Le résultat est une approche plus proactive et rapide aux problèmes de fiabilité.

Les pratiques SRE requièrent une visibilité et une transparence sur l’ensemble des services et applications d’un système distribué. Mais dans de tels environnements, mesurer les performances et la disponibilité des différents services n’a rien de simple. Pour rendre le processus plus fonctionnel, l’équipe SRE de Google a mis au point les quatre signaux d’or, l’un des nombreux frameworks de supervision des systèmes distribués qui établissent des critères de santé d’un système. 

• Latence : c’est le temps nécessaire au traitement d’une requête. Les équipes définissent la valeur de référence des « bons » taux de latence et comparent la latence des requêtes réussies aux requêtes inabouties afin de suivre la santé du système. En suivant la latence sur l’ensemble du système, les équipes SRE peuvent déterminer quels services ne fonctionnent pas de façon optimale et détecter les incidents plus tôt.
• Trafic : il mesure la contrainte subie par le système du fait des utilisateurs ou des transactions qui s’exécutent via le service à un moment donné. La supervision des interactions et du trafic des utilisateurs réels dans l’application ou le service permet aux équipes SRE de voir comment les clients perçoivent ce produit, tout en observant l’impact de l’évolution de la demande sur le système.
• Erreurs : il s’agit du taux d’échec des requêtes. Les équipes SRE doivent superviser le taux d’erreurs survenant dans l’ensemble du système, créer un budget d’erreurs et identifier les plus critiques. Elles peuvent ainsi envisager l’état de santé d’un service du point de vue du client et réagir rapidement pour corriger les erreurs fréquentes.
• Saturation : cette mesure désigne la capacité globale du système et les ressources dont il dispose, et offre aux équipes SRE une visibilité sur la capacité d’un service donné. La plupart des systèmes commencent à se dégrader avant d’atteindre 100 % d’utilisation. Les équipes SRE doivent donc établir un pourcentage d’utilisation « sain » de référence (autrement dit, un pourcentage qui garantit les performances et la disponibilité du service pour les clients.)

Pour le DevOps, le rôle de la SRE consiste à s’assurer que les applications et les services développés par les équipes DevOps sont disponibles pour les utilisateurs finaux lorsqu’ils en ont besoin. Bien que SRE et DevOps soient souvent abordés ensemble, ce sont deux disciplines distinctes. 

Le DevOps est considéré à la fois comme une pratique et comme un ensemble de principes. Le DevOps est une approche de la livraison IT qui conjugue des personnes, des pratiques et des outils pour abattre les silos qui isolent les équipes de développement et d’exploitation. Comme son nom l’indique, il comble le fossé entre le développement logiciel, qui crée le code de l’application, et les opérations IT, qui mettent ces applications en production, à la disposition des utilisateurs finaux, et préservent leur fiabilité. 

Le principe DevOps, ou culture DevOps, est né du mouvement agile, qui a établi des directives pour favoriser de meilleures pratiques de développement logiciel en mettant l’accent sur la livraison progressive, la collaboration au sein des équipes, et la planification et l’apprentissage continus. En réunissant le développement logiciel et les opérations IT, le DevOps étend les principes d’agilité à l’ensemble du cycle de vie du développement logiciel (SDLC) et optimise l’ensemble du workflow dans un objectif d’amélioration continue. Les équipes DevOps hautement performantes n’observent pas seulement une accélération des itérations et du déploiement du code, mais aussi une réduction globale du délai de mise sur le marché des nouvelles idées, une baisse du nombre de bugs et infrastructure plus stable.

La SRE est une fonction clé des principes DevOps et une adjointe du DevOps en tant que pratique, mais ses responsabilités sont plus étroites. Si le DevOps impose aux développeurs d’assumer la responsabilité et l’exploitation de leur produit dans la pratique, à la fois en écrivant du code et en résolvant les problèmes connexes, la nécessité de développer constamment de nouvelles fonctionnalités rend souvent cette approche difficile à concrétiser. C’est là que les ingénieurs en fiabilité des sites peuvent intervenir et mettre à profit leurs connaissances couvrant à la fois le développement de logiciels et les opérations IT pour superviser la gestion du code, notamment le déploiement, la configuration et la supervision. À un niveau supérieur, la SRE resserre les liens entre le développement et les opérations en assurant le déploiement rapide des nouveaux logiciels et fonctionnalités ainsi que la stabilité de l’infrastructure IT.

L’une des principales préoccupations de la SRE est de réduire les efforts humains redondants grâce à l’automatisation. Les ingénieurs en fiabilité des sites s’appuient sur des tâches d’exploitation automatisées telles que l’analyse des logs, le réglage des performances et bien plus. L’automatisation est également essentielle pour réduire le délai moyen de résolution (MTTR), atténuer l’impact des temps d’arrêt et des défaillances, et apporter un supplément de contexte aux activités de réponse aux incidents telles que la supervision, les alertes et les correctifs.

L’automatisation est essentielle dans les environnements de développement modernes, où la vitesse, la cohérence, l’efficacité et l’adaptabilité sont essentielles. Surtout, elle réduit le nombre de tâches banales et répétitives, ce qui permet aux membres de l’équipe SRE de se concentrer sur la création de nouveaux outils, la supervision des modifications de l’infrastructure et l’exécution d’autres tâches visant à améliorer la fiabilité.

Une SRE efficace repose sur une compréhension globale des systèmes et de la manière dont ils fonctionnent ensemble. Les ingénieurs en fiabilité des sites doivent aborder le système dans son ensemble, en accordant autant de poids à ses interconnexions qu’à ses différents composants. Dans cette optique, les équipes peuvent s’appuyer sur les sept principes du « Manuel de fiabilité des sites » pour implémenter efficacement la SRE :

• les opérations sont un problème logiciel. Ce principe fondamental de la SRE dicte qu’une approche d’ingénierie logicielle est la solution à un problème logiciel ;
• axez la gestion sur un objectif de niveau de service. L’objectif de la SRE n’est pas de maintenir une disponibilité à 100 % et la défaillance est inévitable. La SRE travaille avec l’équipe produit pour définir un objectif de disponibilité et gère le service selon cette cible ;
• travaillez de manière à minimiser l’effort. L’approche par défaut ne peut jamais se satisfaire de tâches répétitives et fastidieuses, toute opération pouvant être automatisée devrait l’être ;
• automatisez le travail de cette année. Déterminez les tâches ou les opérations à automatiser et créez une stratégie de mise en œuvre ;
• agissez rapidement en réduisant le coût de l’échec. Identifiez et corrigez les problèmes au plus tôt dans le cycle de vie afin de réduire ou de minimiser l’impact sur le client ;
• partagez la responsabilité avec les développeurs. Supprimez les silos et amenuisez les frontières pour que les équipes de développement et SRE partagent la visibilité et la responsabilité des produits ;
• utilisez le même outillage, quelle que soit la fonction ou l’intitulé du poste. Une équipe SRE ne peut pas prendre en charge efficacement plusieurs équipes de développement si chacune utilise ses propres outils. La normalisation des outils est la clé d’une pratique SRE réussie.

Les ingénieurs en fiabilité des sites assument tout un éventail de responsabilités. Voici les rôles SRE les plus courants :

• création de logiciels visant à aider les équipes d’opérations et de support. Les ingénieurs en fiabilité des sites utilisent leurs compétences en développement pour créer et implémenter des logiciels qui aident le personnel informatique et de support à mieux travailler. Cela peut consister à créer un nouvel outil, à corriger des faiblesses de la livraison de logiciels, à ajuster des outils de supervision existants ou à modifier du code en production, entre autres choses ;
• résolution des problèmes d’escalade de l’assistance. Au début, les ingénieurs en fiabilité des sites consacrent du temps à résoudre les cas d’escalade du support, qui diminuent à mesure que la fiabilité du système s’améliore. En raison de la diversité de leurs compétences et de leur expérience, les ingénieurs en fiabilité des sites disposent de l’expertise nécessaire pour orienter les problèmes vers les personnes et les équipes les mieux indiquées ;
• optimisation des rotations et des processus d’astreinte. Les ingénieurs en fiabilité des sites sont généralement tenus d’être disponibles lors d’un incident, ils ont donc beaucoup à dire sur l’optimisation du processus d’astreinte pour l’amélioration de la fiabilité du système. Les équipes SRE peuvent ajouter de l’automatisation et du contexte aux alertes pour améliorer la réponse collaborative aux incidents, mais aussi mettre à jour les runbooks et la documentation pour préparer les équipes d’astreinte aux incidents à venir ;
• documentation des connaissances. Les équipes SRE sont impliquées dans tous les aspects ou presque du cycle de vie du développement logiciel, ce qui leur donne de riches connaissances sur l’historique des services et des processus. Les ingénieurs en fiabilité des sites peuvent ensuite actualiser régulièrement leurs apprentissages et gérer des runbooks où les équipes d’ingénierie trouveront les informations dont elles ont besoin au moment voulu, un atout qui améliore la gestion et renforce la confiance entre les équipes ;
• réalisation d’examens post-incident. Les équipes SRE sont chargées de veiller à ce que les développeurs logiciels et les professionnels de l’ITOps conduisent des examens sans blâme, documentent leurs conclusions et mettent en pratique ce qu’ils apprennent. Les ingénieurs en fiabilité des sites sont également responsables de tous les éléments d’action post-incident qui impliquent la construction ou l’optimisation d’une partie du SDLC ou du cycle de vie de l’incident.

La SRE s’aligne fidèlement sur le mouvement DevOps et dépend d’une interaction étroite entre les équipes de développement et des opérations : il faut donc une culture de confiance, de collaboration et d’amélioration continue pour qu’une équipe s’épanouisse.

De plus, les ingénieurs en fiabilité des sites ont besoin d’une palette de compétences en développement et en opérations, et doivent connaître les outils et les pratiques traditionnels de l’ingénierie logicielle. Il leur faut encore comprendre les systèmes de manière holistique et être ouverts à de nouvelles façons de les faire évoluer vers la fiabilité.

Enfin, la SRE nécessite un engagement important. Ce n’est pas un outil ou une béquille dans un système défectueux. Elle nécessite un certain changement culturel, l’introduction de nouveaux processus et de nouvelles façons de penser les opérations. Comme bien d’autres initiatives, la SRE peut commencer avec un seul ambassadeur, mais une pratique SRE mature nécessitera éventuellement l’adhésion du sommet de la hiérarchie.

Augmenter et maintenir la disponibilité est une lutte de chaque instant dans toutes les entreprises. Mais celles qui disposent de processus SRE efficaces ont une longueur d’avance sur leurs concurrentes, parce qu’elles bénéficient d’une plus grande résilience des systèmes et, par conséquent, d’un pourcentage plus élevé de versions réussies. Lorsqu’un incident se produit, elles affichent un temps moyen de réception et de réparation (MTTA/MTTR) plus court. En réduisant le temps nécessaire à la résolution des problèmes en production, toutes les équipes (développeurs, SRE et opérations) peuvent se concentrer sur la création de valeur commerciale dans leurs disciplines particulières. La fiabilité devient ainsi un atout du développement logiciel plutôt qu’un obstacle.