Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à concevoir et à exécuter des tests de récupération en cas de défaillance.
Ce principe s'applique au domaine d'apprentissage 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 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épondre à des événements qui présentent des risques majeurs pour la fiabilité, comme la panne 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 où une région entière deviendrait indisponible, vous devez basculer tout le trafic vers une autre région. En 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 reprise après sinistre. Vous devez vérifier que les données répliquées sont toujours très récentes, afin que les utilisateurs ne perdent pas de données et que leurs sessions ne soient pas interrompues. 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 des opérations doivent également être en mesure de rediriger manuellement et efficacement le trafic utilisateur hors d'une région, et ce, 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 reprise après sinistre, 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 :
- 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.
- Évaluez la résilience et la tolérance aux pannes du système dans différents scénarios d'échec.
- Testez l'efficacité des mécanismes de basculement automatique.
Déterminez les composants, services ou régions qui sont inclus 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 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 d'avoir mis en place des mesures de sécurité, comme des procédures de surveillance automatisée et de restauration manuelle.
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 si les mécanismes de basculement automatique échouent.
Pour éviter toute perturbation des tests, assurez-vous que vos rôles et règles IAM, ainsi que vos configurations de basculement, sont correctement configurés. Vérifiez que les autorisations nécessaires sont en place pour les outils et scripts de test.
Informez les parties prenantes, y compris les équipes opérationnelles, DevOps et les propriétaires d'applications, du calendrier, du champ d'application et de l'impact potentiel des tests. Fournissez aux parties prenantes une estimation du calendrier et des 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 la désactivation d'une instance Cloud SQL. 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 l'étendue de votre test. Augmentez progressivement les scénarios d'échec pour observer le comportement du système dans différentes conditions.
Effectuez des tests de charge en parallèle de scénarios de défaillance pour reproduire l'utilisation réelle en cas d'indisponibilité. 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 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 de l'état et d'autres mécanismes redirigent le trafic. Utilisez des outils Google Cloud tels que Cloud Monitoring et Cloud Logging pour capturer les métriques et les événements pendant le test.
Observez les changements de latence, de taux d'erreur et de débit pendant et après la simulation d'échec, et surveillez l'impact global sur les performances. Identifier toute dégradation ou incohérence de l'expérience utilisateur.
Assurez-vous que les journaux sont générés et que les 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 à votre RTO et votre RPO
Mesurez le temps nécessaire au système pour reprendre son fonctionnement normal après une défaillance, puis comparez ces données avec le DMIA 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 du service et vérifiez 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 du 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 niveau de gravité et d'impact.
Suggérer 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 reprise après sinistre concernés. Présentez un rapport post-mortem aux parties prenantes. Le rapport doit résumer les résultats, les enseignements tirés et les prochaines étapes. Pour en savoir plus, consultez Effectuer des post-mortem 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 en cas de modifications de l'infrastructure, de mises à jour logicielles 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 parties prenantes et des utilisateurs finaux pour améliorer le processus de test et la résilience du système.