Le rôle du SRE dans le développement de la résilience informatique

Si vous nous lisez depuis quelque temps, vous vous êtes sans doute aperçu·e que le monde informatique est particulièrement friand d’acronymes (anglophones, le plus souvent) : IT, SOC, DevOps, SRE, etc. Et c’est précisément celui-ci qui nous intéresse aujourd’hui. Qu’est-ce qui se cache réellement derrière ces trois lettres : Site Reliability Engineering ? Pourquoi SRE  et résilience informatique sont-ils intrinsèquement liés ?

À l’origine du SRE (Site Reliability Engineering), une volonté de confier au génie logiciel les tâches exécution.

Définition générale du SRE : DevOps ou pas DevOps ?

Nous avons déjà eu l’occasion de parler de l'ingénierie de la fiabilité des sites (SRE), notamment pour comprendre son impact et son lien essentiel avec la méthodologie DevOps. Nous voudrions avec cet article pousser un peu plus loin la réflexion sur le SRE. Mais avant de revenir sur la définition de la discipline, un petit élément de contextualisation s’impose. Le DevOps est né de la volonté de casser les silos entre les équipes de développement d’un site ou d'une application et l’équipe opérationnelle chargée de leur exécution. Pour ce faire, une refonte organisationnelle en profondeur et le recours à des technologies d’automatisation sont requis. 

Le SRE s’inscrit dans la continuité de cette culture de l’agilité, parce qu’il s'évertue lui aussi à raviver la collaboration entre le développement et l’opérationnel. Pour y parvenir, les ingénieur·e·s SRE (développeur·euse·s de formation) puisent dans les pratiques et les métriques de l’ingénierie logicielle pour les implémenter dans l’exécution de tâches opérationnelles. Concrètement, cela signifie qu’ils vont développer des logiciels évolutifs et performants pour :

• automatiser des tâches initialement effectuées par l’humain
• résoudre des problèmes et gérer l’ensemble d’une infrastructure
• assurer disponibilité et fiabilité des applications, mais aussi de tout le système d’information (SI) d’une organisation

Le S de SRE renvoie au terme anglais site qui embarque bel et bien l’ensemble d’un SI : les applications et le site internet et aussi les machines virtuelles, le réseau, etc.

Petite et grande histoire du SRE

Dans le paysage informatique contemporain, le SRE est aujourd’hui incontournable, mais comment se sont développés ce métier et les méthodologies associées ? Revenons vingt ans en arrière pour un petit rappel historique. Nous sommes en 2003 dans les bureaux californiens de Google. Ben Treynor, nouvelle recrue qui occupe le poste de VP’s Engineering, intègre une équipe d'ingénieurs logiciels. Il constate que ces derniers puisent dans leur expertise logicielle pour automatiser la résolution de problèmes autrefois dévolus à l’humain. Et lorsque Ben Treynor doit organiser sa propre équipe pour gérer la partie exploitation, il continue de s'appuyer sur le génie logiciel pour résoudre toute problématique opérationnelle. La démarche connaît un succès retentissant puisqu'elle a su répondre de manière immédiate et pérenne aux défis de fiabilité et de performance rencontrés par les acteurs de la Tech. Dans la foulée, un ouvrage de référence théorise et jette les premiers jalons du Site Reliability Engineering.

Les principes fondamentaux du SRE : au service de la résilience informatique 

Objectifs de la résilience informatique : maintenir l’activité et réduire au maximum les perturbations

Une stratégie cyber-résiliente part du principe qu’aucun système d’information n’est exempt d’une panne, d'un incident, d’un bug ou d’une cyberattaque. Il ne faut pas voir en ce postulat de la résignation, au contraire, il faut l'envisager, de manière proactive, comme une opportunité. En clair, c’est être capable d’anticiper le moindre incident avant même qu’il ne survienne et surtout, d’en comprendre les origines profondes pour que les équipes IT soient toujours prêtes à rebondir. 

Par conséquent, la résilience informatique est une approche qui va sans cesse rechercher des ressources (humaines, financières, technologiques et organisationnelles) pour garantir la performance d’un SI et en limiter les perturbations. Elle met tout en œuvre pour garantir la disponibilité d'une infrastructure, peu importe les circonstances. 

En cela, l'ingénierie de la fiabilité des sites participe activement à cette méthodologie. Dans l’acronyme SRE, le R de reliability renvoie à la notion centrale de fiabilité. Ainsi, l’ingénieur·e SRE met à profit le génie logiciel pour solutionner des problématiques et réduire les défaillances garantissant performance et fiabilité de l’ensemble d’un SI. Il ou elle innove pour automatiser des processus, fluidifier les échanges et le travail de toutes les équipes : les développeur·euse·s, les équipes opérationnelles, mais aussi la sécurité. Après tout, n’est-ce pas le propre de l'ingénierie d’innover et de chercher des solutions ? Et là, nous retrouvons le E d'Engineering ! 

Voyons à présent les fondamentaux de cette discipline. 

La gestion des erreurs : l'échec comme source d’apprentissage

Pour les ingénieur·e·s SRE, la notion d’erreur est considérée comme normale, mais est surtout perçue comme un important levier d’apprentissage. Quoi de plus logique quand on considère qu’un système n’est jamais fiable à 100%. Une équipe SRE applique les principes de l’agilité et ne cherche jamais à blâmer ni à pointer du doigt. Elle instaure à la place une véritable culture de l'analyse pour identifier les origines d’une erreur et y remédier. Le post-mortem (ou compte-rendu d’incident) illustre parfaitement cet esprit. Il s’agit d’un document où l’on établit de manière neutre un état des lieux après la survenue d’un problème et du plan d’action mis en place pour le résoudre, ni plus, ni moins.

En outre, un budget est systématiquement alloué à la notion d’erreur dans les contrats à niveau de service (les SLI et SLO). On considère que durant un certain laps de temps, l’erreur est admise sans aucune conséquence juridique ou financière.

La limitation du temps de travail opérationnel : un exemple d’application de la culture DevOps

Dans le but de soulager les équipes ops et leur offrir les meilleurs outils, les ingénieur·e·s SRE occupent 50% de  leur temps à des problématiques d’exploitation et 50% du temps restant à la conception de logiciels. En revanche, si l’ingénieur·e SRE dépasse les 50% du temps alloué à l’exploitation, cela signifie que la charge de travail entre le développement et l'équipe opérationnelle est déséquilibrée et que la performance du SI en pâtit. En charge alors à l’équipe SRE de réaffecter certaines tâches d’exploitation aux devs.

La surveillance proactive et l’observabilité : l’exemple de l'ingénierie du chaos

Surveillance et observabilité font partie intégrante des fonctions de l'ingénierie de la fiabilité des sites et par extension, de la résilience informatique. À l'aide d’outils de monitoring, les équipes SRE et DevOps surveillent et tracent l’activité d’un système dans le but d’anticiper toute perturbation. Ils peuvent configurer des alertes et s’appuyer sur des métriques  pour personnaliser cette surveillance.

Et ils peuvent même aller jusqu’à tester la résistance d’une infrastructure grâce à l'ingénierie du chaos. Petit clin d'œil à la célèbre théorie, le SRE va étudier les imprévus et les comportements aléatoires d’un système et de ses utilisateurs. En résumé, cela consiste à établir une situation dite stable et à y simuler en permanence des scénarios à degré de gravité varié. L’objectif étant de tester l’efficacité d’un plan d’action et le cas échéant, l’améliorer.

Promouvoir et déployer l’automatisation

Sans surprise, la recherche de solutions automatisées est une composante majeure du travail d’un·e ingénieur·e SRE. Le principe est simple, si le SRE s’aperçoit qu’un problème survient au moins deux fois, il va chercher à solutionner cette difficulté par l’automatisation. N’oublions pas non plus que dans une approche DevOps, il va également s’appuyer sur l’automatisation pour réduire les tâches manuelles et chronophages des développeur·euse·s et des équipes chargées de l'exploitation . De fait, ils peuvent se concentrer sur des tâches plus stratégiques. 

Résilience informatique en entreprise : pourquoi faut-il capitaliser sur le SRE ?

Agilité, réduction des silos, communication rétablie : vers une meilleure collaboration d’équipe

L’ingénieur·e SRE est un profil clé dans une entreprise. Il ou elle maîtrise plusieurs disciplines : le développement, le génie logiciel, l'opérationnel, la sécurité, etc. Il ou elle connaît ainsi les rouages de chaque métier, mais surtout le quotidien et les obstacles rencontrés par ses équipes. Presque comme   un-e coach, il ou elle va accompagner les métiers longtemps séparés par un mur d’incompréhension à reprendre le dialogue, mais aussi à travailler en étroite collaboration. Cette fine connaissance de son environnement à laquelle s'ajoute son expertise logicielle en fait le profil idéal pour créer, développer des outils adaptés. 

Rendre le SI plus fiable tout en veillant à l’accélération du cycle de développement des applications

• Tirer parti des données d’exploitation et de l’expertise logicielle
• Équilibrer les charges de travail entre Devs et Ops 
• Inclure les équipes sécurité dans les processus

Ces trois leviers engagés par le SRE vont participer à rendre le système d’information plus fiable et plus performant. Mais dans un monde où tout doit aller encore plus vite, cela participe surtout à mettre au jour beaucoup plus rapidement des applications et autres outils essentiels à la conduite d’un business.

Réduire le nombre d’incidents 

Envisager la notion de risque comme un·e ingénieur·e SRE, c'est garantir au SI d’une entreprise de voir le nombre d’incidents chuter drastiquement. Cela permet également de limiter les pannes et autres interruptions qui coûtent très cher. L’ingénieur·e SRE identifie, hiérarchise et cartographie chaque situation à risque. Il ou elle analyse l’historique des incidents passés et recueille toutes les informations nécessaires pour déjouer les risques potentiels. Chaque erreur s’envisage comme une source d’apprentissage précieuse.

Des client·e·s, des utilisateur·trice·s et des collaborateur·trice·s satisfait·e·s

Une culture SRE ne force jamais la main des collaborateur·trice·s dans l’emploi d’un nouvel outil, elle propose, solutionne, s’adapte, mais adopte surtout une approche méthodique. L’information n’est jamais cachée, mais elle est recherchée et valorisée. En cas d’erreur, les équipes partagent la responsabilité, mais ne se blâment jamais entre elles. De fait, les collaborateur·trice·s travaillent dans une atmosphère saine où la charge de travail tend à l’équilibre. Quant aux utilisateur·trice·s, ils ou elles bénéficient d’applications fonctionnelles, fluides et sans problèmes majeurs, ce qui est un véritable gage de confiance.