Fiabilité et opérations

Un système parfaitement sécurisé qui tombe en panne échoue quand même tout le monde qui en dépend. Ce sujet passe de qui protège vos ressources cloud à comment elles restent en marche : les schémas de redondance qui survivent à une panne matérielle, l'automatisation qui ajuste la capacité à la demande, le plan pour quand une panne dépasse ce que la redondance seule peut absorber, et la façon dont les équipes découvrent réellement qu'un problème s'est produit.

Ce que couvre ce sujet

• la haute disponibilité et la tolérance aux pannes, et pourquoi une brève récupération automatique et une absence totale d'interruption sont 2 garanties différentes, à des prix différents
• la redondance actif-actif et actif-passive, et comment répartir le calcul et les bases de données sur plusieurs zones de disponibilité supprime un point unique de défaillance
• la scalabilité et l'élasticité, et pourquoi la capacité d'un système à grandir n'est pas la même chose que grandir et rétrécir automatiquement selon la demande en temps réel
• les réglages d'un groupe Auto Scaling : capacité minimale, souhaitée et maximale, et les politiques de mise à l'échelle par suivi de cible, par palier et planifiée
• le Recovery Time Objective et le Recovery Point Objective, et les 4 stratégies de reprise après sinistre, de la sauvegarde et restauration jusqu'au multi-site actif-actif, qui échangent du coût contre de la vitesse de récupération
• la supervision par métriques, journaux et alarmes, et la différence entre un SLI, un SLO et un SLA

Pourquoi c'est important

Chaque schéma de ce sujet répond à une version de la même question : que se passe-t-il quand quelque chose tombe en panne malgré tout. Le matériel tombe en panne à 2h du matin, peu importe la qualité du code, donc la redondance multi-AZ et la distinction entre haute disponibilité et tolérance aux pannes décident si cette panne reste invisible ou simplement supportable. La demande ne reste jamais stable, donc la scalabilité et l'élasticité décident si une équipe paie sa pire journée toute l'année ou seulement quand elle survient réellement. La redondance à l'intérieur d'une région finit par rencontrer une panne plus grande que ce pour quoi elle a été conçue, exactement ce que le Recovery Time Objective, le Recovery Point Objective et une stratégie de reprise après sinistre testée existent pour borner.

Rien de tout cela ne vaut quoi que ce soit sans un moyen de découvrir qu'une panne s'est produite et de dire, avec des chiffres, à quel point un système a réellement été fiable. C'est ce que la supervision et les SLA viennent clore dans ce sujet : des métriques et des alarmes qui repèrent un problème en quelques minutes plutôt que par une plainte client, et une lecture lucide de ce qu'un SLA de fournisseur compense et de ce qu'il ne couvre jamais. Ensemble, ce sujet vous donne le vocabulaire qu'attendent un entretien pour un poste cloud et le parcours de certification vers lequel ce cours mène : pas seulement comment construire un système résilient, mais comment prouver, chiffres à l'appui, qu'il l'est resté.