Les SRE apportent de l’ORDRE(R) au CHAOS

Les défis et les responsabilités de votre allié de confiance : l’ingénieur de la fiabilité des sites (SRE).

Par Keith McDuffee, ambassadeur Snyk, expert DevSecOps et fondateur de StackRef.com.

« Quelle est la différence entre un ingénieur DevOps et un ingénieur de la fiabilité des sites ? »

C’est une question que l’on me pose sans cesse — et que j’ai entendue (et parfois posée) lors d’entretiens d’embauche. Mais existe-t-il une bonne réponse ? Tout dépend de la personne à qui vous la posez. À mon avis, il y a une distinction, mais elle est si floue qu’il faut plisser les yeux pour la voir.

Pour l’instant, parlons des SRE. Quelles sont leurs responsabilités ? Que font-ils ? À quels défis sont-ils confrontés au quotidien ?

Je vais (essayer de) faire preuve d’ingéniosité en regroupant leurs responsabilités sous le terme ORDERR, et leurs défis sous CHAOS.

CHAOS

Qu’est-ce qui tient les SRE en alerte et les empêche de dormir la nuit ? Voici les principales catégories :

Défaillance d’un composant critique

Un système informatique repose sur de nombreux composants, mais il ne s’agit pas ici uniquement de matériel. Le matériel — même avec ses redondances — peut tomber en panne, tout comme les services et les applications. Les applications plantent, les services sont surchargés et le matériel finit par lâcher.

Intervention humaine

L’absence d’automatisation efficace revient à réveiller un SRE chaque nuit à 2 h du matin pour lui faire saisir 4, 8, 15, 16, 23 et 42 sur un clavier. Faire appel à un humain en chair et en os pour des tâches qu’un programme pourrait facilement accomplir, c’est s’exposer à l’exaspération, à l’épuisement et aux erreurs de frappe. Et lorsque ces systèmes automatisés tombent en panne — ce qui peut arriver et arrive —, ne pas pouvoir reproduire le processus rapidement et facilement devient un problème en soi.

Bugs dans le code applicatif

Les possibilités d’action d’un SRE sont limitées. Certains savent coder et connaissent une application sur le bout des doigts, mais ce n’est généralement pas pour cela qu’ils ont été recrutés. Un SRE peut toutefois aider à identifier les personnes concernées et à faire intervenir les bons ingénieurs. Les SRE devraient aussi avoir une certaine capacité d’anticipation grâce à leurs outils d’observabilité : sans eux, une bombe à retardement risque de les réveiller. Encore une fois.

Problèmes liés à l’open source

Parfois, vos développeurs ne sont pas entièrement responsables d’un code qui plante ou qui manque de sécurité (même si, idéalement, ils devraient le savoir). De nombreuses applications reposent sur des dépendances open source, dont certaines s’apparentent à des boîtes noires d’une complexité quasi magique, qu’aucune équipe interne de développement logiciel ne peut entièrement comprendre. Un module importé dans un projet pour activer une seule fonctionnalité peut en introduire un millier d’autres, inutiles, et entraîner des vulnérabilités encore inconnues ainsi que des problèmes de performance.

Les dépendances open source ne sont pas les seules responsables potentielles. Des composants tiers payants peuvent aussi être en cause, parfois avec des conséquences plus graves : vous dépendez alors des priorités de l’entreprise concernée, et non de celles de la communauté au sens large (log4j, ça vous dit quelque chose ?).

Incidents de sécurité

Le pire cauchemar d’un SRE. Quand cela arrive, le problème est soit difficile à résoudre rapidement, soit découvert bien plus tard qu’on ne veut l’admettre. Les attaques par déni de service (DoS) en font partie : les atténuer est une chose, mais faire face à une présence hostile active dans vos systèmes en est une autre. La situation n’est « résolue » qu’une fois la menace active maîtrisée et écartée, et que tout ce qui a pu être compromis est traité comme un déchet nucléaire.

ORDERR

J’ai essayé — vraiment essayé — de réduire tout cela à ORDER, mais impossible d’ignorer ou de séparer les deux derniers R de la liste.

Observabilité

À quoi bon tenter de gérer le CHAOS si vous ne le voyez pas ? L’observabilité consiste simplement à garder un œil sur l’ensemble : disponibilité, performances, activité.

Mais il ne suffit pas de pouvoir consulter ces informations. Il faut mettre en place des alertes exploitables et fiables pour les événements qui nécessitent une intervention. Ici, « exploitables » et « fiables » vont de pair. Si un SRE est réveillé la nuit par une fausse alerte — et que ces fausses alertes se répètent —, il risque de se fatiguer et de finir par crier au loup : une alerte considérée comme fausse peut alors signaler un vrai problème.

Des alertes pertinentes et rapides sont importantes, mais un SRE ne peut pas s’y fier uniquement. Il faut pouvoir consulter les outils de supervision et suivre en continu l’état des systèmes en cours d’exécution : c’est la première étape pour configurer ces alertes ! Certaines équipes SRE utilisent des outils tiers, d’autres développent les leurs. Tout dépend du budget et de l’existence d’une solution adaptée à votre situation.

Il existe trop d’outils dans cette catégorie pour tous les citer, mais en voici quelques-uns : Datadog, New Relic, ELK Stack (avec hébergement et assistance gratuits), SolarWinds et Splunk.

Fiabilité

C’est un sujet vaste. De nombreux facteurs peuvent empêcher les systèmes et les applications de fonctionner de manière fiable. Toute la pile technique — et même au-delà ! — est concernée : géolocalisation, centre d’hébergement, serveurs et matériel, réseau, système d’exploitation, services, code applicatif et fourniture des services. Vous êtes fatigué ? Les SRE, oui.

J’aurais pu ajouter un « A » pour la disponibilité, mais je pense que ces notions sont suffisamment proches pour se confondre. Veiller à mettre en place les éléments nécessaires à la disponibilité de vos systèmes — redondance, mécanismes automatisés et/ou manuels de basculement, sécurité et gestion des incidents de déni de service — relève de la fiabilité.

À l’exception du code applicatif, les SRE sont seuls responsables de l’entretien de tout ce qui garantit la fiabilité des systèmes d’une organisation. Pour le code applicatif, bien souvent, les SRE servent simplement de relais d’observabilité auprès des développeurs qui l’ont écrit ; ce ne sont pas eux qui réparent ce qui est cassé. Cela passe en partie par des outils d’analyse statique du code, qui signalent les problèmes dès qu’ils sont détectés, ou par les systèmes de supervision et de journalisation en place. Une fois les problèmes repérés, il revient aux SRE de s’assurer qu’ils sont transmis à la ou aux équipes compétentes et traités rapidement.

Snyk propose des outils pour vous aider dans ce domaine.

Gestion des catastrophes

Pour les SRE, le terme « catastrophe » recouvre de nombreuses situations. Il peut s’agir de la défaillance d’une infrastructure critique ou, à Dieu ne plaise, du crash d’un avion avec à son bord votre ingénieur logiciel principal. Bien sûr, cela inclut aussi tout ce qui touche à la sécurité.

Disposer d’un processus efficace pour répondre à ces catastrophes est essentiel aux missions d’un SRE. Il est donc indispensable d’avoir des procédures à jour et accessibles (abordées dans le E ci-dessous), car on ne peut pas toujours compter uniquement sur sa mémoire. Les exercices de simulation et les tests réguliers de reprise après sinistre sont difficiles à planifier, mais ils sont essentiels pour réagir rapidement et de façon plus structurée en cas de catastrophe.

Parmi les outils payants (et les versions gratuites ou limitées) de cette catégorie, citons Mattermost et PagerDuty.

Une intervention efficace passe aussi par…

Une communication efficace

Les moyens de communication sont nombreux, surtout lorsque les équipes travaillent à distance et dans différents fuseaux horaires. Il est indispensable d’établir une méthode de communication claire pour gérer les problèmes, non seulement pour savoir où, mais aussi comment et quand communiquer.

Des moyens de communication adaptés aident les SRE à garder une bonne visibilité sur les situations, mais aussi à s’assurer qu’elles sont gérées correctement et rapidement, sans que le travail soit effectué en double.

Il faut aussi communiquer avec les parties prenantes internes et externes. Si une anomalie est détectée, la communication commence au sein des équipes internes, avant d’informer les clients externes des problèmes qui affectent leur utilisation de vos services. Les SRE sont au cœur des décisions concernant le fait de communiquer avec l’extérieur, le moment choisi et la manière de le faire.

Voici quelques outils de communication courants que vous connaissez sans doute : Slack, Microsoft Teams et Atlassian StatusPage.

Rétablissement

Tout ce qui précède contribue à l’objectif ultime (en plus d’éviter tout incident) : rétablir un état stable et sécurisé. Tous les éléments mentionnés détermineront la rapidité avec laquelle cet objectif pourra être atteint.

• Observez ce qui se passe.

• Prévoyez un mécanisme de basculement et une redondance fiables.

• Veillez à suivre votre plan d’action de réponse aux catastrophes.

• Mettez en œuvre une communication efficace.

Les SRE doivent respecter un objectif de TMR (temps moyen de rétablissement) : la chance seule ne suffit pas. Une fois le rétablissement effectué, il faut reprendre une communication efficace pour rassurer les parties prenantes. Mais pour les SRE, le travail n’est pas terminé. Place à…

Rétrospective

Une fois la poussière retombée, les SRE peuvent souffler un peu, à juste titre, mais pas trop longtemps. Quelque chose de grave s’est produit. Si rien n’est fait, cela risque de se reproduire.

Nous revenons ainsi à la communication efficace. Il faut comprendre quand, quoi, où, pourquoi et comment, mais aussi ce que nous allons faire pour éviter que cela se reproduise.

Les enseignements tirés doivent être consignés avec les détails de l’incident et accompagnés d’un plan d’action concret. Les éléments précédents devront peut-être être ajustés : améliorer l’observabilité, renforcer les systèmes et la sécurité, ajouter des couches de fiabilité, voire améliorer la communication. Il faut ensuite fixer des échéances raisonnables pour que ces mesures soient mises en œuvre, et les SRE doivent suivre les responsables pour s’assurer qu’elles sont bien appliquées.

DevOps et SRE

Alors, que font les équipes DevOps si elles ne sont pas aussi des SRE ? Je ne vais pas entrer dans tous les détails, mais, pour ce qui concerne les SRE, les équipes DevOps font le lien entre les SRE et les développeurs. Elles donnent aux deux parties les moyens d’accomplir leur travail sans avoir à se renvoyer trop de problèmes. Elles fournissent tout l’ORDERR dont les SRE ont besoin pour gérer le CHAOS, tout en permettant aux non-SRE de s’impliquer autant que nécessaire.

Bonne chance…

- K