Ce principe du pilier de fiabilité du framework d'architectureGoogle Cloud 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 la zone de concentration de l'apprentissage sur la fiabilité.
Présentation des principes
Pour vous assurer que votre système peut se rétablir en cas de défaillance, vous devez effectuer régulièrement des tests qui incluent 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épondre aux événements qui présentent des risques majeurs pour la fiabilité, tels que l'indisponibilité d'une région entière. Ces tests vous aident également à vérifier que votre système se comporte comme prévu en cas de perturbation.
Dans le cas peu probable d'une panne complète d'une région, vous devez basculer l'ensemble du trafic vers une autre région. Lors du 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 de rupture de session. Le système d'équilibrage de charge doit également être en mesure de transférer le trafic vers la région de bascule à tout moment sans interruption de service. Pour réduire les temps d'arrêt après une panne régionale, les ingénieurs d'exploitation doivent également pouvoir rediriger manuellement et efficacement le trafic utilisateur vers une autre région, dans les plus brefs délais possible. Cette opération est parfois appelée vider 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 reprise après échec, tenez compte des recommandations des sous-sections suivantes.
Définir les objectifs et la portée des tests
Définissez clairement ce que vous souhaitez obtenir des tests. Par exemple, vos objectifs peuvent inclure les 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 la section Principes de base de la planification de la reprise après sinistre.
- Évaluez 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 automatiques
Déterminez les composants, services ou régions concernés par les 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 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 un 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 les procédures de rollback manuelles.
Créez un plan de sauvegarde. Créez 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 à effectuer des interventions manuelles si les mécanismes de basculement automatiques échouent.
Pour éviter toute interruption des tests, assurez-vous que vos rôles IAM, vos règles et vos configurations de basculement sont correctement configurés. Vérifiez que les autorisations nécessaires sont en place pour les outils et les scripts de test.
Informez les personnes concernées, y compris les équipes d'exploitation, DevOps et les propriétaires d'applications, du calendrier, de la portée et de l'impact potentiel des tests. Fournissez aux personnes concernées un calendrier estimé et les comportements attendus pendant le test.
Simuler des scénarios de défaillance
Planifiez et exécutez des échecs à 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 d'une instance Cloud SQL désactivée. Vous pouvez également utiliser des scripts pour simuler une panne réseau à l'échelle régionale à l'aide de règles de pare-feu ou de restrictions d'API en fonction de votre champ d'application. Évoluez progressivement les scénarios de défaillance pour observer le comportement du système dans différentes conditions.
Introduisez des tests de charge en plus des scénarios de défaillance pour reproduire l'utilisation réelle en cas d'indisponibilité. Testez les conséquences des défaillances en cascade, comme le comportement des systèmes d'interface utilisateur 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 des scénarios impliquant des erreurs de configuration. Par exemple, exécutez des tests avec des paramètres de basculement DNS ou des autorisations IAM incorrects.
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 rediriger le trafic. Utilisez des outils Google Cloud tels que Cloud Monitoring et Cloud Logging pour capturer des métriques et des événements pendant le test.
Observez les changements de 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 gestion des incidents.
Vérifier la récupération par rapport à vos RTO et 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 au RTO défini et documentez les écarts.
Assurez-vous que l'intégrité et la disponibilité des données correspondent 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 un échec.
Évaluez la restauration des services et vérifiez que tous les services sont rétablis dans un état fonctionnel avec un minimum de perturbation pour les utilisateurs.
Documenter et analyser les résultats
Documentez chaque étape de 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 lors du test. Pour hiérarchiser les corrections, catégorisez les problèmes en fonction de leur gravité et de leur impact.
Suggérez des améliorations à l'architecture du système, aux mécanismes de basculement ou aux configurations de surveillance. Sur la base des résultats des tests, mettez à jour les stratégies de basculement et les playbooks pertinents. Présentez un rapport 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 la section Mener 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 en cas de modification de l'infrastructure, de mise à jour logicielle et d'augmentation des charges de trafic.
Automatisez les tests de basculement à l'aide de pipelines CI/CD pour intégrer les tests de fiabilité à votre cycle de développement.
Lors de l'analyse post-mortem, utilisez les commentaires des personnes concernées et des utilisateurs finaux pour améliorer le processus de test et la résilience du système.