Ce principe du pilier "Fiabilité" du Google Cloud Well-Architected Framework fournit des recommandations pour vous aider à concevoir et à exécuter des tests de récupération en cas de défaillance.
Ce principe est pertinent pour le domaine d'apprentissage de la fiabilité.
Présentation du principe
Pour vous assurer que votre système peut récupérer après une défaillance, vous devez exécuter régulièrement des tests incluant des basculements régionaux, des rollbacks de versions et la restauration de données à partir de sauvegardes.
Ces tests vous aident à vous entraîner à réagir à des événements qui présentent des risques majeurs pour la fiabilité, tels que la panne d'une région entière. Ces tests vous permettent également de vérifier que votre système se comporte comme prévu en cas d'interruption.
Dans le cas peu probable où une région entière deviendrait indisponible, vous devez basculer tout le trafic vers une autre région. Pendant le fonctionnement normal de votre charge de travail, lorsque des données sont modifiées, elles doivent être synchronisées de la région principale vers la région de basculement. Vous devez vérifier que les données répliquées sont toujours très récentes, afin que les utilisateurs ne subissent pas de perte de données ni d'interruption de session. Le système d'équilibrage de charge doit également pouvoir transférer le trafic vers la région de basculement à tout moment, sans interruption de service. Pour minimiser les temps d'arrêt après une panne régionale, les ingénieurs d'exploitation doivent également être en mesure de rediriger manuellement et efficacement le trafic utilisateur hors d'une région, en un minimum de temps. Cette opération est parfois appelée drainage d'une région, ce qui signifie que vous arrêtez le trafic entrant vers la région et déplacez tout le trafic ailleurs.
Recommandations
Lorsque vous concevez et exécutez des tests de récupération après défaillance, tenez compte des recommandations des sous-sections suivantes.
Définir les objectifs et le champ d'application des tests
Définissez clairement ce que vous souhaitez obtenir du test. Par exemple, vos objectifs peuvent inclure les éléments suivants :
- Validez l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO). Pour en savoir plus, consultez Principes de base de la planification de reprise après sinistre.
- Évaluer la résilience et la tolérance aux pannes du système dans différents scénarios de défaillance.
- Testez l'efficacité des mécanismes de basculement automatique.
Déterminez les composants, services ou régions inclus dans le champ d'application des tests. Le champ d'application peut inclure des niveaux d'application spécifiques tels que l'interface, le backend et la base de données, ou des ressources Google Cloud spécifiques telles que des instances Cloud SQL ou des clusters GKE. Le champ d'application doit également spécifier toutes les dépendances externes, telles que les API tierces ou les interconnexions cloud.
Préparer l'environnement pour les tests
Choisissez un environnement approprié, de préférence un environnement de préproduction ou de bac à sable qui reproduit votre configuration de production. Si vous effectuez le test en production, assurez-vous de disposer de mesures de sécurité, telles que la surveillance automatisée et des procédures de rollback manuel.
Créez un plan de sauvegarde. Prenez des instantanés ou effectuez des sauvegardes des bases de données et des services critiques pour éviter toute perte de données pendant le test. Assurez-vous que votre équipe est prête à intervenir manuellement en cas d'échec des mécanismes de basculement automatisés.
Pour éviter les interruptions de test, assurez-vous que vos rôles, règles et configurations de basculement IAM (Identity and Access Management) sont correctement configurés. Vérifiez que les autorisations nécessaires sont en place pour les outils et les scripts de test.
Informez les parties prenantes, y compris les propriétaires des opérations, de DevOps et des applications, du calendrier, de la portée et de l'impact potentiel des tests. Fournissez aux parties prenantes un calendrier estimé et les comportements attendus pendant le test.
Simuler des scénarios de défaillance
Planifiez et exécutez des défaillances à l'aide d'outils tels que Chaos Monkey. Vous pouvez utiliser des scripts personnalisés pour simuler des défaillances de services critiques, comme l'arrêt d'un nœud principal dans un cluster GKE multizone ou une instance Cloud SQL désactivée. Vous pouvez également utiliser des scripts pour simuler une panne réseau à l'échelle d'une région à l'aide de règles de pare-feu ou de restrictions d'API en fonction de votre champ d'application de test. Augmentez progressivement les scénarios de défaillance pour observer le comportement du système dans différentes conditions.
Introduisez des tests de charge parallèlement aux scénarios d'échec pour reproduire l'utilisation réelle pendant les pannes. Testez les impacts des défaillances en cascade, par exemple le comportement des systèmes d'interface lorsque les services de backend ne sont pas disponibles.
Pour valider les modifications de configuration et évaluer la résilience du système face aux erreurs humaines, testez des scénarios impliquant des erreurs de configuration. Par exemple, exécutez des tests avec des paramètres de basculement DNS incorrects ou des autorisations IAM incorrectes.
Surveiller le comportement du système
Surveillez la façon dont les équilibreurs de charge, les vérifications d'état et d'autres mécanismes réacheminent le trafic. Utilisez des outils Google Cloud comme Cloud Monitoring et Cloud Logging pour capturer les métriques et les événements pendant le test.
Observez les variations de latence, de taux d'erreur et de débit pendant et après la simulation de défaillance, et surveillez l'impact global sur les performances. Identifiez toute dégradation ou incohérence dans l'expérience utilisateur.
Assurez-vous que des journaux sont générés et que des alertes sont déclenchées pour les événements clés, tels que les interruptions de service ou les basculements. Utilisez ces données pour vérifier l'efficacité de vos systèmes d'alerte et de réponse aux incidents.
Vérifier la récupération par rapport à vos objectifs de temps de récupération (RTO) et de point de récupération (RPO)
Mesurez le temps nécessaire au système pour reprendre un fonctionnement normal après une défaillance, puis comparez ces données au RTO défini et documentez les écarts.
Assurez-vous que l'intégrité et la disponibilité des données sont conformes au RPO. Pour tester la cohérence de la base de données, comparez les instantanés ou les sauvegardes de la base de données avant et après une défaillance.
Évaluez la restauration des services et confirmez que tous les services sont restaurés dans un état fonctionnel avec un minimum de perturbations pour les utilisateurs.
Documenter et analyser les résultats
Documentez chaque étape de test, chaque scénario d'échec et le comportement du système correspondant. Incluez des codes temporels, des journaux et des métriques pour des analyses détaillées.
Mettez en évidence les goulots d'étranglement, les points de défaillance uniques ou les comportements inattendus observés lors du test. Pour vous aider à prioriser les corrections, classez les problèmes par gravité et par impact.
Suggérez des améliorations à l'architecture du système, aux mécanismes de basculement ou aux configurations de surveillance. En fonction des résultats des tests, mettez à jour les règles et les playbooks de basculement pertinents. Présenter un rapport d'analyse post-mortem aux personnes concernées. Le rapport doit résumer les résultats, les enseignements tirés et les prochaines étapes. Pour en savoir plus, consultez Effectuer des post-mortems approfondis.
Itérer et améliorer
Pour valider la fiabilité et la résilience continues, planifiez des tests périodiques (par exemple, tous les trimestres).
Exécutez des tests dans différents scénarios, y compris les modifications d'infrastructure, les mises à jour logicielles et l'augmentation des charges de trafic.
Automatisez les tests de basculement en utilisant des pipelines CI/CD pour intégrer les tests de fiabilité à votre cycle de développement.
Lors du post-mortem, utilisez les commentaires des parties prenantes et des utilisateurs finaux pour améliorer le processus de test et la résilience du système.