Google Cloud Well-Architected Framework: fiabilité

Last reviewed 2025-02-14 UTC

Le pilier de fiabilité du Google Cloud framework Well-Architected fournit des principes et des recommandations pour vous aider à concevoir, déployer et gérer des charges de travail fiables dans Google Cloud.

Ce document est destiné aux architectes cloud, aux développeurs, aux ingénieurs de plate-forme, aux administrateurs et aux ingénieurs en fiabilité des sites.

La fiabilité est la capacité d'un système à exécuter de manière cohérente ses fonctions prévues dans les conditions définies et à assurer un service ininterrompu. Les bonnes pratiques en matière de fiabilité incluent la redondance, la conception tolérante aux pannes, la surveillance et les processus de récupération automatisés.

La résilience est la capacité du système à résister et à se rétablir après des défaillances ou des perturbations inattendues, tout en maintenant ses performances. Des fonctionnalitésGoogle Cloud , telles que les déploiements multirégionaux, les sauvegardes automatiques et les solutions de reprise après sinistre, peuvent vous aider à améliorer la résilience de votre système.

La fiabilité est importante pour votre stratégie cloud pour de nombreuses raisons, y compris les suivantes:

  • Temps d'arrêt minimal: les temps d'arrêt peuvent entraîner une perte de revenus, une baisse de la productivité et une atteinte à la réputation. Les architectures résilientes peuvent aider à s'assurer que les systèmes peuvent continuer à fonctionner en cas de défaillance ou à les récupérer efficacement.
  • Amélioration de l'expérience utilisateur: les utilisateurs s'attendent à des interactions fluides avec la technologie. Les systèmes résilients peuvent contribuer à maintenir des performances et une disponibilité cohérentes, et ils fournissent un service fiable même en cas de forte demande ou de problèmes inattendus.
  • Intégrité des données: les défaillances peuvent entraîner la perte ou la corruption de données. Les systèmes résilients implémentent des mécanismes tels que les sauvegardes, la redondance et la réplication pour protéger les données et s'assurer qu'elles restent précises et accessibles.
  • Continuité de l'activité: votre entreprise s'appuie sur la technologie pour ses opérations critiques. Les architectures résilientes peuvent contribuer à assurer la continuité après une défaillance catastrophique, ce qui permet aux fonctions métier de continuer sans interruption importante et favorise une reprise rapide.
  • Conformité: de nombreux secteurs sont soumis à des exigences réglementaires en matière de disponibilité des systèmes et de protection des données. Les architectures résilientes peuvent vous aider à répondre à ces normes en veillant à ce que les systèmes restent opérationnels et sécurisés.
  • Réduction des coûts à long terme: les architectures résilientes nécessitent un investissement initial, mais la résilience peut contribuer à réduire les coûts au fil du temps en évitant les temps d'arrêt coûteux, les corrections réactives et une utilisation plus efficace des ressources.

Esprit d'entreprise

Pour que vos systèmes soient fiables, vous avez besoin d'un plan et d'une stratégie établie. Cette stratégie doit inclure une formation et l'autorité de donner la priorité à la fiabilité par rapport aux autres initiatives.

Indiquez clairement que l'ensemble de l'organisation est responsable de la fiabilité, y compris le développement, la gestion des produits, les opérations, l'ingénierie de la plate-forme et l'ingénierie en fiabilité des sites (SRE). Même les groupes axés sur l'entreprise, comme le marketing et les ventes, peuvent avoir une incidence sur la fiabilité.

Chaque équipe doit comprendre les cibles de fiabilité et les risques de ses applications. Les équipes doivent être tenues responsables de ces exigences. Les conflits entre la fiabilité et le développement régulier des fonctionnalités produit doivent être hiérarchisés et être remontés en conséquence.

Planifiez et gérez la fiabilité de manière globale, pour toutes vos fonctions et équipes. Envisagez de configurer un centre d'excellence cloud (CCoE) qui inclut un pilier de fiabilité. Pour en savoir plus, consultez Optimiser le parcours cloud de votre organisation avec un centre d'excellence cloud.

Domaines d'action pour la fiabilité

Les activités que vous effectuez pour concevoir, déployer et gérer un système fiable peuvent être classées dans les domaines suivants. Chacun des principes et des recommandations de fiabilité de ce pilier est pertinent pour l'un de ces domaines d'intérêt.

  • Établir le champ d'application: pour comprendre votre système, effectuez une analyse détaillée de son architecture. Vous devez comprendre les composants, leur fonctionnement et leur interaction, la façon dont les données et les actions circulent dans le système, et ce qui peut mal se passer. Identifiez les défaillances, goulots d'étranglement et risques potentiels, ce qui vous aidera à prendre des mesures pour atténuer ces problèmes.
  • Observation: pour éviter les défaillances du système, implémentez une observation et une surveillance complètes et continues. Grâce à cette observation, vous pouvez comprendre les tendances et identifier les problèmes potentiels de manière proactive.
  • Réponse: pour réduire l'impact des défaillances, réagissez de manière appropriée et récupérez efficacement. Les réponses automatisées peuvent également contribuer à réduire l'impact des défaillances. Même avec une planification et des contrôles, des défaillances peuvent se produire.
  • Apprentissage: pour éviter que les échecs ne se reproduisent, tirez des enseignements de chaque expérience et prenez les mesures appropriées.

Principes de base

Les recommandations du pilier de fiabilité du framework Well-Architected sont mappées sur les principes fondamentaux suivants:

Contributeurs

Auteurs :

Autres contributeurs :

Définir la fiabilité en fonction des objectifs d'expérience utilisateur

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected vous aide à évaluer l'expérience de vos utilisateurs, puis à mettre en correspondance les résultats avec les objectifs et les métriques de fiabilité.

Ce principe s'applique à la zone de mise au point de la fiabilité en termes de champ d'application.

Présentation des principes

Les outils d'observabilité fournissent de grandes quantités de données, mais toutes ne sont pas directement liées aux impacts sur les utilisateurs. Par exemple, vous pouvez observer une utilisation élevée du processeur, des opérations de serveur lentes ou même des tâches plantées. Toutefois, si ces problèmes n'affectent pas l'expérience utilisateur, ils ne constituent pas une panne.

Pour mesurer l'expérience utilisateur, vous devez faire la distinction entre le comportement interne du système et les problèmes visibles par l'utilisateur. Concentrez-vous sur des métriques telles que le taux de réussite des requêtes des utilisateurs. Ne vous appuyez pas uniquement sur des métriques centrées sur le serveur, comme l'utilisation du processeur, qui peuvent conduire à des conclusions trompeuses sur la fiabilité de votre service. La fiabilité réelle signifie que les utilisateurs peuvent utiliser votre application ou votre service de manière cohérente et efficace.

Recommandations

Pour vous aider à mesurer efficacement l'expérience utilisateur, tenez compte des recommandations des sections suivantes.

Mesurer l'expérience utilisateur

Pour bien comprendre la fiabilité de votre service, priorisez les métriques qui reflètent l'expérience réelle de vos utilisateurs. Par exemple, mesurez le taux de réussite des requêtes des utilisateurs, la latence de l'application et les taux d'erreur.

Idéalement, collectez ces données directement depuis l'appareil ou le navigateur de l'utilisateur. Si cette collecte de données directe n'est pas possible, déplacez progressivement votre point de mesure plus loin de l'utilisateur dans le système. Par exemple, vous pouvez utiliser l'équilibreur de charge ou le service d'interface comme point de mesure. Cette approche vous aide à identifier et à résoudre les problèmes avant qu'ils n'aient un impact significatif sur vos utilisateurs.

Analyser les parcours utilisateur

Pour comprendre comment les utilisateurs interagissent avec votre système, vous pouvez utiliser des outils de traçage tels que Cloud Trace. En suivant le parcours d'un utilisateur dans votre application, vous pouvez identifier les goulots d'étranglement et les problèmes de latence susceptibles de nuire à son expérience. Cloud Trace capture des données de performances détaillées pour chaque saut de votre architecture de service. Ces données vous aident à identifier et à résoudre plus efficacement les problèmes de performances, ce qui peut améliorer l'expérience utilisateur.

Définir des objectifs réalistes de fiabilité

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected vous aide à définir des objectifs de fiabilité techniquement réalisables pour vos charges de travail dans Google Cloud.

Ce principe s'applique à la zone de mise au point de la fiabilité en termes de champ d'application.

Présentation des principes

Concevez vos systèmes de manière à ce qu'ils soient suffisamment fiables pour satisfaire les utilisateurs. Cela peut sembler contre-intuitif, mais un objectif de fiabilité de 100% n'est souvent pas la stratégie la plus efficace. Un niveau de fiabilité plus élevé peut entraîner des coûts nettement plus élevés, à la fois en termes d'investissement financier et de limites potentielles sur l'innovation. Si les utilisateurs sont déjà satisfaits du niveau de service actuel, les efforts visant à améliorer leur satisfaction peuvent générer un faible retour sur investissement. Vous pouvez ainsi mieux utiliser vos ressources ailleurs.

Vous devez déterminer le niveau de fiabilité qui satisfait vos utilisateurs, et le point où le coût des améliorations incrémentielles commence à dépasser les avantages. Lorsque vous déterminez ce niveau de fiabilité suffisante, vous pouvez allouer des ressources de manière stratégique et vous concentrer sur les fonctionnalités et les améliorations qui apportent plus de valeur à vos utilisateurs.

Recommandations

Pour définir des objectifs de fiabilité réalistes, tenez compte des recommandations des sous-sections suivantes.

Accepter certains échecs et hiérarchiser les composants

Visez une haute disponibilité, par exemple une disponibilité de 99,99 %, mais ne fixez pas une cible de disponibilité de 100 %. Acceptez que certaines défaillances sont inévitables.

L'écart entre une disponibilité de 100% et une cible de 99,99% correspond à la marge de tolérance pour les défaillances. Cet écart est souvent appelé budget d'erreur. Le budget d'erreur peut vous aider à prendre des risques et à innover, ce qui est essentiel pour toute entreprise pour rester compétitive.

Priorisez la fiabilité des composants les plus critiques du système. Acceptez que les composants moins critiques puissent avoir une tolérance à la défaillance plus élevée.

Équilibrer la fiabilité et les coûts

Pour déterminer le niveau de fiabilité optimal pour votre système, effectuez des analyses approfondies des coûts et des avantages.

Tenez compte de facteurs tels que les exigences système, les conséquences des défaillances et la tolérance au risque de votre organisation pour l'application spécifique. N'oubliez pas de tenir compte de vos métriques de reprise après sinistre, telles que l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO). Déterminez le niveau de fiabilité acceptable en fonction du budget et des autres contraintes.

Recherchez des moyens d'améliorer l'efficacité et de réduire les coûts sans compromettre les fonctionnalités de fiabilité essentielles.

Créer des systèmes à haute disponibilité grâce à la redondance des ressources

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour planifier, créer et gérer la redondance des ressources, ce qui peut vous aider à éviter les défaillances.

Ce principe s'applique à la zone de mise au point de la fiabilité en termes de champ d'application.

Présentation des principes

Une fois que vous avez défini le niveau de fiabilité dont vous avez besoin, vous devez concevoir vos systèmes pour éviter tout point de défaillance unique. Chaque composant critique du système doit être répliqué sur plusieurs machines, zones et régions. Par exemple, une base de données critique ne peut pas être située dans une seule région, et un serveur de métadonnées ne peut pas être déployé dans une seule zone ou région. Dans ces exemples, si la seule zone ou région est indisponible, le système est indisponible dans son intégralité.

Recommandations

Pour créer des systèmes redondants, tenez compte des recommandations des sous-sections suivantes.

Identifier les domaines de défaillance et répliquer les services

Mappez les domaines de défaillance de votre système, des VM individuelles aux régions, et concevez des services permettant la redondance entre les domaines de défaillance.

Pour garantir une haute disponibilité, distribuez et répliquez vos services et applications dans plusieurs zones et régions. Configurez le système pour le basculement automatique afin de vous assurer que les services et les applications restent disponibles en cas de panne de zone ou de région.

Pour obtenir des exemples d'architectures multizones et multirégionales, consultez la section Concevoir une infrastructure fiable pour vos charges de travail dans Google Cloud.

Détecter et résoudre rapidement les problèmes

Suivez en permanence l'état de vos domaines de défaillance pour détecter et résoudre rapidement les problèmes.

Vous pouvez surveiller l'état actuel des Google Cloud services dans toutes les régions à l'aide du Google Cloud tableau de bord Service Health. Vous pouvez également afficher les incidents pertinents pour votre projet à l'aide de Personalized Service Health. Vous pouvez utiliser des équilibreurs de charge pour détecter l'état des ressources et acheminer automatiquement le trafic vers des backends opérationnels. Pour en savoir plus, consultez la page Présentation des vérifications d'état.

Tester les scénarios de basculement

Comme pour un exercice d'évacuation, simulez régulièrement des défaillances pour valider l'efficacité de vos stratégies de réplication et de basculement.

Pour en savoir plus, consultez les pages Simuler une défaillance de zone pour un MIG régional et Simuler une défaillance de zone dans des clusters régionaux GKE.

Exploiter l'évolutivité horizontale

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à utiliser l'évolutivité horizontale. En utilisant l'évolutivité horizontale, vous pouvez vous assurer que vos charges de travail dansGoogle Cloud peuvent évoluer efficacement et maintenir leurs performances.

Ce principe s'applique à la zone de mise au point de la fiabilité en termes de champ d'application.

Présentation des principes

Passez à une architecture horizontale. Pour faire face à la croissance du trafic ou des données, vous pouvez ajouter des ressources. Vous pouvez également supprimer des ressources lorsqu'elles ne sont pas utilisées.

Pour comprendre l'intérêt du scaling horizontal, considérez les limites du scaling vertical.

Un scénario courant de scaling vertical consiste à utiliser une base de données MySQL comme base de données principale contenant des données critiques. À mesure que l'utilisation de la base de données augmente, plus de RAM et de processeur sont nécessaires. À terme, la base de données atteint la limite de mémoire sur la machine hôte et doit être mise à niveau. Ce processus peut devoir être répété plusieurs fois. Le problème est que la croissance d'une base de données est limitée. Les tailles de VM ne sont pas illimitées. La base de données peut atteindre un point où il n'est plus possible d'ajouter d'autres ressources.

Même si les ressources sont illimitées, une grande VM peut devenir un point de défaillance unique. Tout problème lié à la VM de base de données principale peut entraîner des réponses d'erreur ou une panne à l'échelle du système affectant tous les utilisateurs. Évitez les points de défaillance uniques, comme décrit dans la section Créer des systèmes hautement disponibles grâce à la redondance des ressources.

En plus de ces limites de scaling, le scaling vertical a tendance à être plus coûteux. Le coût peut augmenter de manière exponentielle à mesure que des machines dotées de plus de puissance de calcul et de mémoire sont acquises.

En revanche, le scaling horizontal peut coûter moins cher. Le potentiel d'évolutivité horizontale est pratiquement illimité dans un système conçu pour évoluer.

Recommandations

Pour passer d'une architecture de VM unique à une architecture horizontale multi-machines, vous devez planifier soigneusement et utiliser les outils appropriés. Pour vous aider à effectuer une mise à l'échelle horizontale, tenez compte des recommandations des sous-sections suivantes.

Utiliser des services gérés

Les services gérés vous évitent de gérer manuellement le scaling horizontal. Par exemple, avec les groupes d'instances gérés (MIG) Compute Engine, vous pouvez ajouter ou supprimer des VM pour faire évoluer votre application horizontalement. Pour les applications conteneurisées, Cloud Run est une plate-forme sans serveur qui peut faire évoluer automatiquement vos conteneurs sans état en fonction du trafic entrant.

Favoriser la conception modulaire

Les composants modulaires et les interfaces claires vous aident à faire évoluer les composants individuels selon les besoins, au lieu de faire évoluer l'application entière. Pour en savoir plus, consultez la section Favoriser la conception modulaire du pilier "Optimisation des performances".

Implémenter une conception sans état

Concevez des applications sans état, c'est-à-dire sans données stockées localement. Vous pouvez ainsi ajouter ou supprimer des instances sans vous soucier de la cohérence des données.

Détecter les défaillances potentielles à l'aide de l'observabilité

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à identifier de manière proactive les zones où des erreurs et des défaillances peuvent se produire.

Ce principe s'applique à la zone de concentration de la fiabilité de l'observation.

Présentation des principes

Pour maintenir et améliorer la fiabilité de vos charges de travail dansGoogle Cloud, vous devez implémenter une observabilité efficace à l'aide de métriques, de journaux et de traces.

  • Les métriques sont des mesures numériques des activités que vous souhaitez suivre pour votre application à des intervalles de temps spécifiques. Par exemple, vous pouvez suivre des métriques techniques telles que le taux de requêtes et le taux d'erreur, qui peuvent être utilisés comme indicateurs de niveau de service (SLI). Vous devrez peut-être également suivre des métriques commerciales spécifiques à l'application, telles que les commandes passées et les paiements reçus.
  • Les journaux sont des enregistrements horodatés d'événements distincts qui se produisent dans une application ou un système. L'événement peut être un échec, une erreur ou un changement d'état. Les journaux peuvent inclure des métriques, et vous pouvez également les utiliser pour les SLI.
  • Une trace représente le parcours d'un utilisateur ou d'une transaction unique à travers un certain nombre d'applications distinctes ou les composants d'une application. Par exemple, ces composants peuvent être des microservices. Les traces vous aident à suivre les composants utilisés dans les parcours, les goulots d'étranglement et la durée des parcours.

Les métriques, les journaux et les traces vous aident à surveiller votre système en continu. La surveillance complète vous aide à déterminer où et pourquoi des erreurs se sont produites. Vous pouvez également détecter les défaillances potentielles avant qu'elles ne se produisent.

Recommandations

Pour détecter efficacement les défaillances potentielles, tenez compte des recommandations des sous-sections suivantes.

Obtenir des insights complets

Pour suivre les métriques clés telles que les temps de réponse et les taux d'erreur, utilisez Cloud Monitoring et Cloud Logging. Ces outils vous aident également à vous assurer que les métriques répondent de manière cohérente aux besoins de votre charge de travail.

Pour prendre des décisions basées sur les données, analysez les métriques de service par défaut afin de comprendre les dépendances des composants et leur impact sur les performances globales de la charge de travail.

Pour personnaliser votre stratégie de surveillance, créez et publiez vos propres métriques à l'aide du SDK Google Cloud.

Effectuer un dépannage proactif

Implémentez une gestion des erreurs robuste et activez la journalisation pour tous les composants de vos charges de travail dans Google Cloud. Activez des journaux tels que les journaux des accès Cloud Storage et les journaux de flux VPC.

Lorsque vous configurez la journalisation, tenez compte des coûts associés. Pour contrôler les coûts de journalisation, vous pouvez configurer des filtres d'exclusion sur les récepteurs de journaux afin d'exclure le stockage de certains journaux.

Optimiser l'utilisation des ressources

Surveillez la consommation du processeur, les métriques d'E/S réseau et les métriques d'E/S disque pour détecter les ressources sous-provisionnées et surprovisionnées dans des services tels que GKE, Compute Engine et Dataproc. Pour obtenir la liste complète des services compatibles, consultez la présentation de Cloud Monitoring.

Prioriser les alertes

Pour les alertes, concentrez-vous sur les métriques critiques, définissez des seuils appropriés pour réduire la fatigue liée aux alertes et assurez-vous de répondre rapidement aux problèmes importants. Cette approche ciblée vous permet de maintenir de manière proactive la fiabilité de la charge de travail. Pour en savoir plus, consultez la présentation des alertes.

Concevoir pour une dégradation élégante

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à concevoir vos charges de travail Google Cloud de manière à gérer les échecs de manière appropriée.

Ce principe s'applique à la zone de concentration de la fiabilité concernant la réponse.

Présentation des principes

La dégradation élégante est une approche de conception dans laquelle un système soumis à une charge élevée continue de fonctionner, avec des performances ou une précision éventuellement réduites. La dégradation élégante garantit la disponibilité continue du système et évite une défaillance complète, même si le fonctionnement du système n'est pas optimal. Lorsque la charge revient à un niveau gérable, le système reprend toutes ses fonctionnalités.

Par exemple, en période de forte charge, la recherche Google donne la priorité aux résultats provenant des pages Web les mieux classées, ce qui peut entraîner une certaine perte de précision. Lorsque la charge diminue, la recherche Google recalcule les résultats de recherche.

Recommandations

Pour concevoir vos systèmes de manière à assurer une dégradation élégante, tenez compte des recommandations des sous-sections suivantes.

Implémenter la limitation

Assurez-vous que vos réplicas peuvent gérer indépendamment les surcharges et limiter les requêtes entrantes lors de scénarios à fort trafic. Cette approche vous permet d'éviter les défaillances en cascade causées par les variations de trafic excédentaire entre les zones.

Utilisez des outils tels que Apigee pour contrôler le débit des requêtes API pendant les périodes de forte affluence. Vous pouvez configurer des règles de stratégie pour refléter la manière dont vous souhaitez réduire les requêtes.

Abandonner les requêtes en trop tôt

Configurez vos systèmes pour qu'ils abandonnent les requêtes excédentaires au niveau de la couche de présentation afin de protéger les composants de backend. L'abandon de certaines requêtes empêche les défaillances globales et permet au système de récupérer plus facilement.Avec cette approche, certains utilisateurs peuvent rencontrer des erreurs. Toutefois, vous pouvez réduire l'impact des pannes, contrairement à une approche telle que le déclenchement d'un disjoncteur, où tout le trafic est abandonné en cas de surcharge.

Gérer les erreurs partielles et les nouvelles tentatives

Créez vos applications pour qu'elles gèrent les erreurs partielles et les nouvelles tentatives de manière fluide. Cette conception permet de garantir que le trafic est diffusé autant que possible lors de scénarios de charge élevée.

Tester les scénarios de surcharge

Pour vérifier que les mécanismes de limitation et de suppression des requêtes fonctionnent efficacement, simulez régulièrement des conditions de surcharge dans votre système. Les tests permettent de vérifier que votre système est prêt à faire face aux pics de trafic réels.

Surveiller les pics de trafic

Utilisez des outils d'analyse et de surveillance pour prédire et répondre aux pics de trafic avant qu'ils ne se transforment en surcharges. La détection et la réponse précoces peuvent contribuer à maintenir la disponibilité des services pendant les périodes de forte demande.

Effectuer des tests de reprise après échec

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 à la zone de concentration de la fiabilité dans l'apprentissage.

Présentation des principes

Pour vous assurer que votre système peut se rétablir après un échec, vous devez exécuter régulièrement des tests qui incluent des basculements régionaux, des rollbacks de versions et la restauration des 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é de l'ensemble d'une région. 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 défaillance d'une région entière, 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 bascule. 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 pouvoir transférer le trafic vers la région de basculement à tout moment sans interruption de service. Pour réduire au maximum 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 vidange 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 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 é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 la page 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.
  • 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 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 reproduit votre configuration de production. Si vous effectuez le test en production, assurez-vous de préparer des mesures de sécurité, comme la surveillance automatisée et les procédures de rollback manuel.

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 automatique échouent.

Pour éviter les perturbations des tests, assurez-vous que vos rôles, règles 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 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 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 régionale à l'aide de règles de pare-feu ou de restrictions d'API en fonction de votre champ d'application des tests. Évoluez progressivement les scénarios d'échec pour observer le comportement du système dans différentes conditions.

Implémentez des tests de charge en plus des scénarios de défaillance pour reproduire l'utilisation réelle en cas de panne. Testez les conséquences des défaillances en cascade, comme le comportement des systèmes de 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 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 Google Cloud outils 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 interruptions 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 une défaillance.

É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 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 à hiérarchiser les corrections, classez les problèmes par gravité et impact.

suggérer 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 règles 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, tous les trimestres).

Exécutez des tests dans différents scénarios, y compris des modifications d'infrastructure, des mises à jour logicielles et une 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.

Effectuer des tests de récupération après perte de données

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 perte de données.

Ce principe s'applique à la zone de concentration de la fiabilité dans l'apprentissage.

Présentation des principes

Pour vous assurer que votre système peut récupérer les données perdues ou corrompues, vous devez exécuter des tests pour ces scénarios. La perte de données peut être causée par un bug logiciel ou une catastrophe naturelle. Après de tels événements, vous devez restaurer les données à partir de sauvegardes et rétablir tous les services à l'aide des données fraîchement restaurées.

Nous vous recommandons d'utiliser trois critères pour évaluer la réussite ou l'échec de ce type de test de récupération: l'intégrité des données, l'objectif de durée de récupération (RTO, Recovery Time Objective) et l'objectif de point de récupération (RPO, Recovery Point Objective). Pour en savoir plus sur les métriques RTO et RPO, consultez la page Principes de base d'un plan de reprise après sinistre.

L'objectif des tests de restauration des données est de vérifier régulièrement que votre organisation peut continuer à répondre aux exigences de continuité d'activité. En plus de mesurer le RTO et le RPO, un test de restauration de données doit inclure le test de l'ensemble de la pile d'applications et de tous les services d'infrastructure critiques avec les données restaurées. Cette étape est nécessaire pour vérifier que l'ensemble de l'application déployée fonctionne correctement dans l'environnement de test.

Recommandations

Lorsque vous concevez et exécutez des tests de récupération après une perte de données, tenez compte des recommandations des sous-sections suivantes.

Vérifier la cohérence des sauvegardes et tester les processus de restauration

Vous devez vérifier que vos sauvegardes contiennent des instantanés de données cohérents et utilisables que vous pouvez restaurer pour remettre immédiatement les applications en service. Pour valider l'intégrité des données, configurez des vérifications de cohérence automatiques à exécuter après chaque sauvegarde.

Pour tester les sauvegardes, restaurez-les dans un environnement hors production. Pour vous assurer que vos sauvegardes peuvent être restaurées efficacement et que les données restaurées répondent aux exigences de l'application, simulez régulièrement des scénarios de récupération de données. Documentez la procédure de restauration des données et entraînez vos équipes à l'exécuter efficacement en cas de défaillance.

Programmer des sauvegardes régulières et fréquentes

Pour minimiser la perte de données lors de la restauration et atteindre les objectifs de RPO, il est essentiel de planifier régulièrement des sauvegardes. Définissez une fréquence de sauvegarde en fonction de votre RPO. Par exemple, si votre RPO est de 15 minutes, planifiez les sauvegardes toutes les 15 minutes. Optimisez les intervalles de sauvegarde pour réduire le risque de perte de données.

Utilisez des Google Cloud outils tels que Cloud Storage, les sauvegardes automatiques Cloud SQL ou les sauvegardes Spanner pour planifier et gérer les sauvegardes. Pour les applications critiques, utilisez des solutions de sauvegarde quasi continues telles que la récupération à un moment précis (PITR) pour Cloud SQL ou les sauvegardes incrémentielles pour les grands ensembles de données.

Définir et surveiller le RPO

Définissez un RPO clair en fonction de vos besoins métier et surveillez son respect. Si les intervalles de sauvegarde dépassent le RPO défini, utilisez Cloud Monitoring pour configurer des alertes.

Surveiller l'état des sauvegardes

Utilisez le serviceGoogle Cloud Backup and DR ou des outils similaires pour suivre l'état de vos sauvegardes et vérifier qu'elles sont stockées dans des emplacements sécurisés et fiables. Assurez-vous que les sauvegardes sont répliquées dans plusieurs régions pour plus de résilience.

Planifier des scénarios au-delà de la sauvegarde

Combinez les sauvegardes à des stratégies de reprise après sinistre telles que les configurations de basculement actif-actif ou la réplication interrégionale pour améliorer le temps de récupération dans les cas extrêmes. Pour en savoir plus, consultez le guide de planification de reprise après sinistre.

Effectuer des analyses post-mortem approfondies

Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à effectuer des analyses post-mortem efficaces après des défaillances et des incidents.

Ce principe s'applique à la zone de concentration de la fiabilité dans l'apprentissage.

Présentation des principes

Un post-mortem est un compte-rendu écrit d'un incident, de son impact, des mesures prises pour l'atténuer ou le résoudre, des causes profondes et des actions de suivi pour éviter que l'incident ne se reproduise. L'objectif d'un post-mortem est d'apprendre des erreurs et non de désigner des responsables.

Le diagramme suivant illustre le workflow d'une analyse post-mortem:

Flux de travail d'une analyse post-mortem.

Le workflow d'une analyse post-mortem comprend les étapes suivantes:

  • Créer une analyse post-mortem
  • Rassembler les faits
  • Identifier et analyser les causes profondes
  • Planifier l'avenir
  • Exécuter le plan

Effectuez des analyses post-mortem après des événements majeurs et non majeurs, comme les suivants:

  • Temps d'arrêt ou dégradations visibles par l'utilisateur au-delà d'un certain seuil
  • Perte de données de quelque nature que ce soit.
  • Interventions des ingénieurs d'astreinte, telles qu'un rollback de version ou un nouveau routage du trafic.
  • Durée de résolution supérieure à un seuil défini
  • Défaillances de surveillance, qui impliquent généralement la découverte manuelle d'incidents.

Recommandations

Définissez des critères d'analyse post-mortem avant qu'un incident ne se produise afin que tout le monde sache quand une analyse post-mortem est nécessaire.

Pour effectuer des analyses post-mortem efficaces, tenez compte des recommandations des sous-sections suivantes.

Effectuer des analyses post-mortem non accusatoires

Les analyses post-mortem efficaces se concentrent sur les processus, les outils et les technologies, et ne blâment pas les individus ni les équipes. L'objectif d'une analyse post-mortem est d'améliorer votre technologie et votre avenir, et non de trouver qui est responsable. Tout le monde fait des erreurs. L'objectif doit être d'analyser les erreurs et d'en tirer des leçons.

Les exemples suivants montrent la différence entre les commentaires qui attribuent la faute et ceux qui ne l'attribuent pas:

  • Commentaires qui attribuent la faute: "Nous devons réécrire l'ensemble du système backend complexe ! Il tombe en panne chaque semaine depuis les trois derniers trimestres, et je suis sûr que nous sommes tous fatigués de réparer les choses au coup par coup. Sérieusement, si je suis appelé une fois de plus, je vais le réécrire moi-même."
  • Feedback sans blâme: "Un point d'action visant à réécrire l'ensemble du système backend pourrait empêcher ces pages de continuer à apparaître. Le manuel de maintenance de cette version est assez long et très difficile à maîtriser. Je suis sûr que nos futurs ingénieurs de garde nous en seront reconnaissants."

Rendre le rapport post-mortem lisible par toutes les audiences cibles

Pour chaque information que vous prévoyez d'inclure dans le rapport, évaluez si elle est importante et nécessaire pour aider l'audience à comprendre ce qui s'est passé. Vous pouvez déplacer les données et explications supplémentaires dans l'annexe du rapport. Les examinateurs qui ont besoin d'informations supplémentaires peuvent en demander.

Éviter les solutions complexes ou trop complexes

Avant de commencer à envisager des solutions à un problème, évaluez son importance et la probabilité qu'il se reproduise. Ajouter de la complexité au système pour résoudre des problèmes qui ne sont pas susceptibles de se reproduire peut entraîner une instabilité accrue.

Partager le post-mortem aussi largement que possible

Pour vous assurer que les problèmes ne restent pas non résolus, publiez les résultats de l'analyse post-mortem auprès d'un large public et obtenez l'aide de la direction. La valeur d'une analyse post-mortem est proportionnelle aux enseignements tirés après l'analyse. Lorsque davantage de personnes tirent des enseignements des incidents, la probabilité de défaillances similaires se répétant est réduite.