Qu’est-ce que l’ingénierie de la résilience?
Aucun individu ou aucune équipe de professionnels ne reconnaît facilement que les choses peuvent mal tourner. Les pratiques modernes d’ingénierie ont toutefois dépassé cette crainte, donnant naissance à l’ingénierie de la résilience.
Article d’abord publié (en anglais) sur le site DevOps.com.
Aujourd’hui, l’ingénierie de la résilience n’est pas considérée comme un profil IT. Cependant, tout comme le terme DevOps décrivait d’abord une culture avant de devenir un rôle et que la fiabilité des sites était une extension des opérations avant de devenir une priorité, je ne serais pas surpris de voir l’ingénierie de la résilience devenir également un profil IT à l’avenir. «N’est-ce pas similaire à la SRE?», pourrait-on me demander. Le terme d’ingénierie de la résilience ne consiste pas à simplement mettre l’accent sur la réaction aux incidents et s’étend au développement des stratégies de réponse à long terme.
La résilience est la responsabilité des équipes DevOps et celles en charge des opérations cloud, car il est prévisible de voir des défaillances dans ces environnements. Lorsque les applications et les services ne fonctionnent plus, une stratégie de réponse «à la sauvette» ne fonctionnera pas.
Focus sur les frameworks
L’ingénierie de la résilience, bien qu’ancrée dans les pratiques d’ingénierie, est largement axée sur la mise en place de stratégies et d’un framework pour l’exécution de celles-ci. Le processus de mise en place de la résilience s’inscrit principalement dans un système non défini, notamment car chaque système est unique. Et la façon de réagir aux problèmes de ce système sera probablement unique, même si le plan de gestion qui signale les problèmes ne l’est pas.
Le rôle de l’ingénierie de la résilience consiste à:
Etablir des procédures, des habitudes et des arbres de décision
Lorsque les choses se dégradent, la confrontation est la seule option. Les opérations et les ingénieurs astreints doivent résoudre les problèmes de manière systématique et reproductible pour éliminer au mieux de l’équation l’émotion et la peur. Agir ainsi permet non seulement de trier et de résoudre les problèmes, mais aussi de s’assurer que l’activité associée au problème puisse fournir des indications utiles pour l’avenir. Une partie de ce travail consiste à établir des habitudes et des processus de décision pour ceux en charge de l’astreinte. Ces processus permettent de définir les priorités et de saisir les détails, car ces derniers sont cruciaux.
Se centrer sur les données
L’ingénierie de la résilience doit s’appuyer sur des données. En ce sens, cette pratique va plus loin que les pratiques traditionnelles de SRE, en se focalisant sur la résilience. Dans les environnements SRE typiques, l’accent est mis sur le présent, en faisant appel à des tableaux de bord renseignant sur l’état actuel en temps réel. Or, lorsqu’on parle de résilience, on ne parle pas du présent mais de l’impact du passé sur l’avenir. La seule façon de rendre compte de cet impact est de se baser sur des données: une part du rôle de l’ingénierie de la résilience consiste ainsi à s’assurer que les données sont disponibles. Et non isolées dans des silos de données le long de la chaîne de livraison, comme c’est le cas dans beaucoup d’entreprises. L’ingénierie de la résilience doit garantir que des données télémétriques de l’ensemble de la chaîne de livraison sont saisies, corrélées et partagées. C’est essentiel car ce qui se passe au début de la chaîne de livraison a un impact direct sur les incidents. Cette pratique peut apporter des réponses aux problèmes, inciter à faire marche arrière ou apporter des explications suffisamment claires pour prévenir la survenue de problèmes similaires à l’avenir. Sans une continuité entre chaque étape de la chaîne de livraison, il est facile de passer à côté d’événements corrélés qui peuvent conduire à des problèmes plus systémiques.
Apprendre d’incidents précédents
Pour beaucoup, le bénéfice principal de l’ingénierie de la résilience consiste à pouvoir tirer les leçons des incidents précédents et à trouver des moyens d’automatiser les résolutions futures. Apprendre des données et forger des habitudes consistantes permet de créer des runbooks et d’automatiser la résolution des problèmes connus. Souvent, les pistes d’audit de réponse aux incidents peuvent se lire comme des manuels pour traiter des problèmes particuliers. Lorsque la résolution n’est pas directement liée au code et qu’il paraît inévitable que des problèmes refassent surface à l’avenir, créer ce corpus de renseignements utiles pour y remédier évite de réveiller quelqu’un à minuit et limite l’impact sur les clients.
Le stack de la résilience
Les entreprises qui souhaitent adopter l’ingénierie de la résilience doivent disposer d’une boîte à outils adaptée. C’est assez évident mais cela vaut la peine d’être souligné. Le stack de résilience comprendra:
Un outil d’observation et/ou de suivi
Un outil de réponse aux incidents
Une documentation sur la stratégie d’astreinte
Processus et documentation post-mortem
Processus documentés comprenant les étapes de réponse recommandées
Voie vers l’automatisation
Pour ceux qui disposent d’un environnement relativement mature et automatisé, l’étape suivante est l’ingénierie du chaos, c’est-à-dire la prise en compte du chaos comme moyen d’anticiper les incidents avant qu’ils ne se produisent dans la réalité.
Augmentez vos compétences de documentation (Markdown/balisage) au maximum. L’ingénierie de la résilience nécessite beaucoup de documentation. Mais il ne faut pas que ces documents s’intègrent dans une routine. Ils doivent au contraire être vivants et mener à une automatisation ou fournir un feedback sur le processus de développement.
Quant aux outils de surveillance, de visualisation et de réponse aux incidents, il ne suffit pas de les mettre en œuvre. Il faut également savoir comment les données seront collectées, consommées et actualisées. Il en va de même pour la mise en place d’une stratégie d’astreinte, qui doit avoir un objectif précis. Il ne s’agit pas d’assigner tout le monde à l’astreinte seulement parce que c’est «la chose la plus cool à faire».
Affirmer que les entreprises désirent assurer la résilience de leur système peut sembler une évidence. Ce qui n’est pas évident, c’est la façon d’y parvenir. Lorsque les entreprises constatent des lacunes (qui souvent les embarrassent), elles comprennent que la résilience est une priorité pour les fonctions actuelles et futures. D’où l’importance d’aborder l’ingénierie de la résilience et les pratiques qui la rendent efficace.
