Comprendre l’ingénierie pour la résilience
Microsoft définit la résilience comme « la capacité d’un processus ou d’un service métier à répondre aux attentes des clients face aux erreurs et aux défis liés aux opérations normales ». À l’échelle de Microsoft Online Services, la résilience est essentielle pour maintenir la disponibilité de nos services en ligne. Nous mettons tout en œuvre pour renforcer la robustesse de nos services, car nous savons que :
- Le matériel échouera. Supposons que le Temps moyen entre pannes (MTBF) est de 100 000 heures pour un disque dur. Pour un seul disque dur, cela représente une panne tous les 11,5 ans, ce qui paraît très gérable. Mais si vous avez 10 000 000 disques durs, cela correspond à une panne toutes les 30 secondes environ. La résilience contre la défaillance des composants matériels courants est une caractéristique essentielle de la façon dont nous concevons et construisons nos services en ligne.
- Les humains feront des erreurs. Supposons qu’un humain, dans un réseau informatique classique, effectue 100 opérations par jour dans un système de 100 serveurs. Même avec une précision de 99 %, cela représente une erreur par jour. À l’échelle de 250 000 serveurs, cela représente 2 500 erreurs par jour.
- Le logiciel comportera des bogues. Les mises à jour logicielles doivent être déployées en continu pour maintenir les services à jour. Les services résilients doivent se protéger contre les bogues nouveaux et non découverts dans les logiciels.
Nous répondons à ces difficultés en utilisant le cloud à très grande échelle de Microsoft et en employant l’automatisation des services pour rendre nos services résistants à de multiples modes de défaillance.
Conception de service active/active
Dans la mesure du possible, nous nous assurons que nos services soient conçus et déployés avec une résilience active/active. Cela signifie qu’en cas de défaillance d’un composant essentiel du service, un composant identique est disponible pour prendre le relais sans perte de disponibilité. Les déploiements actifs/actifs remplacent les anciens modèles actifs/passifs, dans lesquels les composants passifs prenaient du temps pour prendre en charge la charge de travail en cas de défaillance des composants actifs, perturbant temporairement la disponibilité du service et l’intégrité des données. La conception des services actifs/actifs représente une amélioration significative par rapport aux autres modèles de déploiement et offre une résilience contre de nombreux types de défaillances de service.
Isolation des pannes
L’isolation des pannes renforce la résilience du service en empêchant les erreurs d’un composant de provoquer l’échec d’autres composants. L’isolation des pannes complète la conception du service actif/actif en réduisant la portée requise pour la récupération automatisée des pannes de composants. Microsoft travaille en permanence à réduire la taille des zones d’erreur dans nos services cloud afin d’éviter que les défaillances ne se propagent et n’affectent d’autres composants système.
Certaines des stratégies que nous utilisons pour l’isolation des pannes sont les suivantes :
- Contrôle détaillé des erreurs au sein des composants de service et entre ceux-ci : par exemple, les groupes de disponibilité de base de données Exchange Online limitent l’impact des défaillances au sein du service à des groupes de disponibilité spécifiques.
- Gestion à protocoles multiples de la disponibilité des services : par exemple, un incident affectant l’accès aux fichiers dans Teams peut être atténué par l’accessibilité des fichiers via SharePoint Online.
- Régionalisation et conception de systèmes granulaires : notre conception de services sépare l’infrastructure de services logique et physique en unités de plus en plus petites. Cela nous permet de répondre de manière appropriée aux incidents en fonction de leur étendue en utilisant la flexibilité de la gestion des services à petite et à grande échelle.
- Répartition et limitation des charges : nos services mélangent régulièrement le trafic et les données entre les composants du système dans le cadre du fonctionnement normal du service. Le trafic côté service non essentiel est limité au profit du trafic essentiel comme la livraison du courrier. Cela permet à nos systèmes de hiérarchiser automatiquement les services essentiels en cas de défaillance d’un composant ou d’incident de service.
Rayon d’explosion réduit
Le concept de « rayon d’explosion » d’un incident est étroitement lié à l’isolation des pannes. Lorsqu’un incident se produit, le rayon de l’explosion fait référence à l’ampleur de l’impact de l’incident sur nos services en ligne. Microsoft travaille en permanence pour réduire le rayon d’explosion des incidents potentiels. Lorsqu’une réponse post-mortem à un incident découvre un type d’incident avec un rayon d’explosion inacceptable, nous réagissons en investissant dans des mises à jour de service conçues pour réduire l’impact des incidents similaires à l’avenir.
Amélioration continue
Lorsque des incidents se produisent, notre processus de réponse aux incidents garantit que chaque incident est géré jusqu’à sa résolution. Nous utilisons des métriques standardisées pour suivre l’impact des incidents sur la disponibilité et les performances du service. Les incidents ayant un impact significatif sur les clients sont soumis à un examen post-incident. Les principales constatations et mesures d’atténuation résultant de l’examen post-incident sont publiées dans le tableau de bord d’intégrité du service pour que les clients concernés puissent les consulter.
Les analyses post-incident permettent d’identifier les améliorations de la résilience qui pourraient empêcher ou limiter la portée de problèmes similaires à l’avenir. Les leçons tirées des incidents sont partagées entre les équipes de service, afin que chaque équipe puisse mettre en œuvre des améliorations sans rencontrer directement un incident similaire.