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'intérêt apprentissage de la fiabilité.
Présentation du principe
Pour vous assurer que votre système peut se remettre de défaillances, vous devez exécuter régulièrement des tests qui incluent des basculements régionaux, des rollbacks de version et la restauration de données à partir de sauvegardes.
Ces tests vous aident à vous entraîner à répondre à des événements qui présentent des risques majeurs pour la fiabilité, comme l'indisponibilité d'une région entière. Ils vous aident également à 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 tomberait en panne, 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 être en mesure de 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 déplacer manuellement et efficacement le trafic utilisateur d'une région, dans les plus brefs délais. Cette opération est parfois appelée vidage d'une région, ce qui signifie que vous arrêtez le trafic entrant vers la région et que vous 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 des tests. Par exemple, vos objectifs peuvent inclure les éléments suivants :
- Valider 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 la 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.
- Tester l'efficacité des mécanismes de basculement automatisés.
Déterminez les composants, services ou régions qui entrent dans le champ d'application des tests. Le champ d'application peut inclure des niveaux d'application spécifiques tels que le frontend, le backend et la base de données, ou des ressources spécifiques telles que des instances Cloud SQL ou des clusters GKE. Google Cloud 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 réplique votre configuration de production. Si vous effectuez le test en production, assurez-vous de disposer de mesures de sécurité prêtes à l'emploi, telles que la surveillance automatisée et les procédures de rollback manuel.
Créez un plan de sauvegarde. Prenez des instantanés ou 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, stratégies et configurations de basculement IAM 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, du champ d'application et de l'impact potentiel des tests. Fournissez aux parties prenantes une chronologie estimée 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 de réseau à l'échelle d'une région à l'aide de règles de pare-feu ou de restrictions d'API en fonction du champ d'application de votre 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 en parallèle des scénarios de défaillance pour répliquer l'utilisation réelle pendant les pannes. Testez les impacts des défaillances en cascade, par exemple le comportement des systèmes frontend lorsque les services backend ne sont pas disponibles.
Pour valider les modifications de configuration et évaluer la résilience du système face aux erreurs humaines, testez les 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 redirigent le trafic. Utilisez Google Cloud des outils tels que Cloud Monitoring et Cloud Logging pour capturer des métriques et des événements pendant le test.
Observez les modifications de la latence, des taux d'erreur et du 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 pannes 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 à votre RTO et votre RPO
Mesurez le temps nécessaire au système pour reprendre ses opérations normales après une défaillance, puis comparez ces données avec le 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 du service et vérifiez que tous les services sont restaurés dans un état fonctionnel avec une interruption minimale pour l'utilisateur.
Documenter et analyser les résultats
Documentez chaque étape du test, chaque scénario de défaillance 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 pendant le test. Pour vous aider à hiérarchiser les correctifs, 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 stratégies et les playbooks de basculement pertinents. Présentez un rapport post-mortem aux parties prenantes. Le rapport doit résumer les résultats, les leçons tirées et les prochaines étapes. Pour en savoir plus, consultez Effectuer des analyses post-mortem approfondies.
Itérer et améliorer
Pour valider la fiabilité et la résilience continues, planifiez des tests périodiques (par exemple, trimestriels).
Exécutez des tests dans différents scénarios, y compris les modifications d'infrastructure, les mises à jour logicielles et les charges de trafic accrues.
Automatisez les tests de basculement à l'aide de pipelines CI/CD pour intégrer les tests de fiabilité à votre cycle de développement.
Pendant l'analyse 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.