Il est impossible de construire un système logiciel infaillible. Un système peut traverser tout son cycle de vie sans tomber en panne, mais personne ne peut garantir qu'il ne tombera jamais en panne. Écrire un code parfait ne résout pas le problème, car même un logiciel irréprochable dépend d'un ordinateur physique, de l'alimentation électrique, d'un stockage fonctionnel et d'autres composants. Si la machine perd son alimentation, le logiciel tombera en panne quelle que soit sa qualité. Pour cette raison, les ingénieurs doivent concevoir en prévision des pannes, en décidant à l'avance comment un système doit se comporter lorsque certaines de ses parties ne fonctionnent pas correctement.
Cet article examine les stratégies qui aident les développeurs à gérer les pannes de leurs systèmes. Il commence par le raisonnement qui sous-tend la mentalité « supposer que tout peut tomber en panne », qui prépare les équipes à anticiper les défaillances plutôt que de les traiter comme des exceptions rares. Il oppose ensuite l'évitement des pannes à leur tolérance, deux approches qui répondent à des objectifs différents dans la conception des systèmes.
La discussion aborde ensuite des techniques concrètes. Les développeurs doivent déterminer la portée d'une panne afin de savoir quelles parties du système sont touchées et lesquelles restent opérationnelles. Ils ont aussi besoin de moyens pour réduire l'impact d'une panne, afin qu'un problème dans un composant ne se propage pas à l'ensemble de la plateforme.
Enfin, l'article explique comment gérer les pannes pendant que le système continue de fonctionner correctement, et comment mesurer la reprise après panne. Suivre la rapidité et l'exhaustivité du rétablissement d'un système fournit aux équipes un retour concret sur l'efficacité réelle de leurs stratégies de gestion des pannes.
Source: ByteByteGo · Résumé par HeadlinesBriefing