Well-Architected Framework: pilier de 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 les fonctions prévues dans les conditions définies et à maintenir 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.

En termes de fiabilité, la résilience est la capacité du système à résister aux défaillances ou aux perturbations inattendues et à s'en remettre, tout en maintenant ses performances. Les fonctionnalitésGoogle Cloud , comme 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 vous aider à vous assurer que les systèmes peuvent continuer à fonctionner en cas de défaillance ou à s'en remettre efficacement.
  • Expérience utilisateur améliorée : les utilisateurs s'attendent à des interactions fluides avec la technologie. Les systèmes résilients peuvent vous aider à maintenir des performances et une disponibilité constantes. 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 une perte ou une corruption des données. Les systèmes résilients mettent en œuvre 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 exactes et accessibles.
  • Continuité de l'activité : votre entreprise s'appuie sur la technologie pour les 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 se poursuivre sans interruption majeure et favorise une reprise rapide.
  • Conformité : de nombreux secteurs sont soumis à des exigences réglementaires concernant la disponibilité des systèmes et la protection des données. Les architectures résilientes peuvent vous aider à respecter ces normes en garantissant 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 correctifs réactifs et en permettant une utilisation plus efficace des ressources.

Esprit d'organisation

Pour rendre vos systèmes fiables, vous avez besoin d'un plan et d'une stratégie établie. Cette stratégie doit inclure la formation et l'autorité nécessaire pour privilégier la fiabilité par rapport aux autres initiatives.

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

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

Planifiez et gérez la fiabilité de manière holistique, 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.

Points clés 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 d'intérêt suivants. Chacun des principes et des recommandations de fiabilité de ce pilier concerne l'un de ces domaines d'intérêt.

  • Définition du 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, le flux de données et d'actions dans le système, et ce qui pourrait mal se passer. Identifier les échecs, les goulots d'étranglement et les risques potentiels, ce qui vous aide à prendre des mesures pour atténuer ces problèmes.
  • Observation : pour éviter les défaillances du système, mettez en place une observation et une surveillance complètes et continues. Cette observation vous permet de comprendre les tendances et d'identifier les problèmes potentiels de manière proactive.
  • Réponse : pour réduire l'impact des échecs, réagissez de manière appropriée et récupérez efficacement. Les réponses automatiques peuvent également contribuer à réduire l'impact des défaillances. Même avec une planification et des contrôles, des échecs peuvent se produire.
  • Apprentissage : pour éviter que les échecs ne se reproduisent, tirez les leçons de chaque expérience et prenez les mesures appropriées.

Principes de base

Les recommandations du pilier de fiabilité du framework Well-Architected sont associées aux principes fondamentaux suivants :

Contributeurs

Auteurs :

Autres contributeurs :

définissent la fiabilité en fonction des objectifs d'expérience utilisateur ;

Ce principe du pilier de fiabilité du Google Cloud Well-Architected Framework vous aide à évaluer l'expérience de vos utilisateurs, puis à mapper les résultats sur des objectifs et des métriques de fiabilité.

Ce principe s'applique au domaine d'application de la fiabilité.

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 rencontrés par les utilisateurs. Concentrez-vous sur des métriques telles que le taux de réussite des requêtes des utilisateurs. Ne vous fiez pas uniquement aux métriques centrées sur le serveur, comme l'utilisation du processeur, qui peuvent conduire à des conclusions trompeuses sur la fiabilité de votre service. Une 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, privilégiez 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 des applications et les taux d'erreur.

Dans l'idéal, collectez ces données directement à partir de l'appareil ou du navigateur de l'utilisateur. Si cette collecte directe de données n'est pas possible, éloignez progressivement votre point de mesure de l'utilisateur dans le système. Par exemple, vous pouvez utiliser l'équilibreur de charge ou le service frontend 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 comme 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 qui pourraient nuire à l'expérience utilisateur. Cloud Trace capture des données de performances détaillées pour chaque hop de l'architecture de votre service. Ces données vous aident à identifier et à résoudre les problèmes de performances plus efficacement, ce qui peut améliorer la fiabilité et la satisfaction des utilisateurs.

Définir des cibles de fiabilité réalistes

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

Ce principe s'applique au domaine d'application de la fiabilité.

Présentation des principes

Concevez vos systèmes pour 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. Une fiabilité plus élevée peut entraîner un coût considérablement plus élevé, à la fois en termes d'investissement financier et de limitations potentielles de l'innovation. Si les utilisateurs sont déjà satisfaits du niveau de service actuel, les efforts visant à accroître encore 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émentales commence à dépasser les avantages. Lorsque vous avez déterminé 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 offrent une plus grande valeur à vos utilisateurs.

Recommandations

Pour définir des cibles 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, 99,99 % de disponibilité), mais ne définissez pas une cible de disponibilité de 100 %. Reconnaissez que certains échecs sont inévitables.

L'écart entre 100 % de disponibilité et un objectif de 99,99 % correspond à la marge d'erreur. Cet écart est souvent appelé budget d'erreur. La marge d'erreur peut vous aider à prendre des risques et à innover, ce qui est essentiel pour toute entreprise qui souhaite 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 aux pannes 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 coûts-avantages approfondies.

Tenez compte de facteurs tels que les exigences du 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, comme 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 à disponibilité élevée grâce à la redondance des ressources

Ce principe du pilier de fiabilité du Google Cloud Well-Architected Framework 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 au domaine d'application de la fiabilité.

Présentation des principes

Après avoir défini le niveau de fiabilité dont vous avez besoin, vous devez concevoir vos systèmes de manière à é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 à l'échelle mondiale.

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

Cartographiez les domaines de défaillance de votre système, des VM individuelles aux régions, et concevez la redondance dans les domaines de défaillance.

Pour garantir une haute disponibilité, distribuez et répliquez vos services et applications sur 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 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 services Google Cloud dans toutes les régions à l'aide du tableau de bord Service Health.Google Cloud 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 présentation des vérifications d'état.

Tester les scénarios de basculement

Comme pour un exercice d'incendie, 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 Simuler une défaillance de zone pour un MIG régional et Simuler une défaillance de zone dans des clusters régionaux GKE.

Profiter de l'évolutivité horizontale

Ce principe du pilier de fiabilité du Google Cloud Well-Architected Framework fournit des recommandations pour vous aider à utiliser la scalabilité 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 au domaine d'application de la fiabilité.

Présentation des principes

Repensez l'architecture de votre système pour qu'elle devienne 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 la valeur du scaling horizontal, examinez les limites du scaling vertical.

Un scénario courant pour le scaling vertical consiste à utiliser une base de données MySQL comme base de données principale avec des données critiques. À mesure que l'utilisation de la base de données augmente, davantage 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. Vous devrez peut-être répéter ce processus plusieurs fois. Le problème est que la croissance d'une base de données est strictement limitée. La taille des VM n'est pas illimitée. La base de données peut atteindre un point où il n'est plus possible d'ajouter de ressources.

Même si les ressources étaient 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 qui affecte tous les utilisateurs. Évitez les points de défaillance uniques, comme décrit dans Créer des systèmes à disponibilité élevée 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 vous acquérez des machines dotées d'une puissance de calcul et d'une mémoire plus importantes.

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

Recommandations

Pour passer d'une architecture à une seule VM à une architecture horizontale à plusieurs machines, vous devez planifier soigneusement votre migration et utiliser les bons outils. Pour vous aider à effectuer un scaling horizontal, tenez compte des recommandations des sous-sections suivantes.

Utiliser des services gérés

Les services gérés éliminent la nécessité 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 de manière horizontale. Pour les applications conteneurisées, Cloud Run est une plate-forme sans serveur qui peut adapter automatiquement vos conteneurs sans état en fonction du trafic entrant.

Promouvoir la conception modulaire

Les composants modulaires et les interfaces claires vous aident à mettre à l'échelle les composants individuels selon vos besoins, au lieu de mettre à l'échelle l'ensemble de l'application. Pour en savoir plus, consultez Promouvoir la conception modulaire dans le pilier de l'optimisation des performances.

Implémenter une conception sans état

Concevez des applications sans état, c'est-à-dire sans données stockées localement. Cela vous permet d'ajouter ou de 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 Well-Architected Framework fournit des recommandations pour vous aider à identifier de manière proactive les domaines où des erreurs et des échecs peuvent se produire.

Ce principe s'applique au domaine d'intérêt Observation de la fiabilité.

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ées comme indicateurs de niveau de service (SLI). Vous devrez peut-être également suivre des métriques métier spécifiques à l'application, comme 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. Vous pouvez également les utiliser pour les SLI.
  • Une trace représente le parcours d'un utilisateur ou d'une transaction à travers plusieurs 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, à identifier les goulots d'étranglement et à déterminer la durée des parcours.

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

Recommandations

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

Obtenez 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 de Google Cloud SDK.

Effectuer un dépannage proactif

Implémentez gestion des exceptions robuste et activez la journalisation pour tous les composants de vos charges de travail dans Google Cloud. Activez les journaux tels que les journaux d'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'empêcher le stockage de certains journaux.

Optimiser l'utilisation des ressources

Surveillez la consommation de 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.

Hiérarchiser les alertes

Pour les alertes, concentrez-vous sur les métriques critiques, définissez des seuils appropriés pour minimiser 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é des charges de travail. Pour en savoir plus, consultez Aperçu des alertes.

Concevoir pour une dégradation élégante

Ce principe du pilier de fiabilité du Google Cloud Well-Architected Framework fournit des recommandations pour vous aider à concevoir vos Google Cloud charges de travail de manière à ce qu'elles échouent de manière élégante.

Ce principe s'applique au domaine d'intérêt des réponses de la fiabilité.

Présentation des principes

La dégradation progressive est une approche de conception dans laquelle un système soumis à une charge élevée continue de fonctionner, éventuellement avec des performances ou une précision réduites. La dégradation progressive garantit la disponibilité continue du système et empêche 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 retrouve toutes ses fonctionnalités.

Par exemple, en période de forte charge, la recherche Google donne la priorité aux résultats provenant de pages Web mieux classées, ce qui peut nuire à la précision. Lorsque la charge diminue, la recherche Google recalcule les résultats de recherche.

Recommandations

Pour concevoir vos systèmes en vue d'une dégradation progressive, tenez compte des recommandations des sous-sections suivantes.

Implémenter la limitation

Assurez-vous que vos répliques peuvent gérer les surcharges de manière indépendante et limiter les requêtes entrantes en cas de trafic élevé. Cette approche vous permet d'éviter les défaillances en cascade causées par les changements de trafic excédentaire entre les zones.

Utilisez des outils tels qu'Apigee pour contrôler le taux de requêtes API pendant les périodes de fort trafic. 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 demandes en excès de manière anticipée

Configurez vos systèmes pour qu'ils abandonnent les requêtes excédentaires au niveau de l'interface afin de protéger les composants du backend. Le fait d'abandonner certaines requêtes permet d'éviter les échecs globaux et au système de récupérer plus facilement.Avec cette approche, certains utilisateurs peuvent rencontrer des erreurs. Toutefois, vous pouvez minimiser l'impact des pannes, contrairement à une approche telle que le circuit-breaking, 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 s'assurer que le plus de trafic possible est diffusé dans les scénarios de forte charge.

Tester les scénarios de surcharge

Pour vérifier que les mécanismes de limitation et d'abandon de requêtes fonctionnent efficacement, simulez régulièrement des conditions de surcharge dans votre système. Les tests permettent de s'assurer 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 anticiper les pics de trafic et y répondre avant qu'ils ne se transforment en surcharge. La détection et la réponse précoces peuvent vous aider à 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 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.

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

Ce principe du pilier de 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 perte de données.

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 perte ou de corruption de données, vous devez exécuter des tests pour ces scénarios. Les pertes de données peuvent être dues à un bug logiciel ou à une catastrophe naturelle. Après de tels événements, vous devez restaurer les données à partir des 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, la durée maximale d'interruption admissible (DMIA) et la perte de données maximale admissible (RPO). Pour en savoir plus sur les métriques RTO et RPO, consultez Principes de base d'un plan de reprise après sinistre.

L'objectif des tests de restauration de données est de vérifier régulièrement que votre organisation peut continuer à répondre aux exigences de continuité des activités. En plus de mesurer le RTO et le RPO, un test de restauration des 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 confirmer 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 cohérents et utilisables des données 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 des applications, simulez régulièrement des scénarios de récupération de données. Documentez les étapes de restauration des données et formez vos équipes à les 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 respecter les objectifs de perte de données maximale admissible (RPO), il est essentiel de planifier des sauvegardes régulières. Établissez une fréquence de sauvegarde conforme à votre RPO. Par exemple, si votre RPO est de 15 minutes, planifiez l'exécution des sauvegardes au moins toutes les 15 minutes. Optimisez les intervalles de sauvegarde pour réduire le risque de perte de données.

Utilisez des outils tels que Cloud Storage, les sauvegardes automatiques Cloud SQL ou les sauvegardes Spanner pour planifier et gérer les sauvegardes. Google Cloud 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 des besoins de votre entreprise et vérifiez qu'il est 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 service 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.Google Cloud 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 avec 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 post-mortem efficaces après des échecs et des incidents.

Ce principe s'applique au domaine d'apprentissage Fiabilité.

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 premières et des actions de suivi permettant d'éviter que l'incident ne se reproduise. L'objectif d'un post-mortem est d'apprendre de ses erreurs, et non de chercher des responsables.

Le schéma suivant illustre le workflow d'une autopsie :

Workflow d'une analyse post-mortem.

Le workflow d'une autopsie comprend les étapes suivantes :

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

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

  • Indisponibilités ou dégradations visibles par les utilisateurs au-delà d'un certain seuil.
  • Les pertes de données de quelque nature que ce soit.
  • Interventions des ingénieurs d'astreinte, comme un rollback de version ou un reroutage du trafic.
  • Temps de résolution supérieurs à un seuil défini.
  • Échecs de surveillance, qui impliquent généralement une découverte manuelle des incidents.

Recommandations

Définissez des critères de post-mortem avant qu'un incident ne se produise afin que tout le monde sache quand un 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 post-mortem efficaces se concentrent sur les processus, les outils et les technologies, et ne blâment pas les personnes ni les équipes. L'objectif d'une analyse post-mortem est d'améliorer votre technologie et votre avenir, et non de trouver le coupable. Tout le monde fait des erreurs. L'objectif doit être d'analyser les erreurs et d'en tirer des leçons.

Les exemples suivants illustrent la différence entre les commentaires qui attribuent la responsabilité et ceux qui ne le font pas :

  • Commentaires qui attribuent la responsabilité : "Nous devons réécrire l'intégralité du système backend complexe ! Il y a des problèmes chaque semaine depuis trois trimestres. Je suis sûr que nous en avons tous marre de corriger les choses au coup par coup. Sérieusement, si je reçois encore une notification, je vais le réécrire moi-même…"
  • Commentaires sans blâme : "Une tâche consistant à réécrire l'ensemble du système backend pourrait en fait empêcher ces pages de continuer à se produire. Le manuel de maintenance de cette version est assez long et il est vraiment difficile de se former complètement. Je suis sûr que nos futurs ingénieurs d'astreinte nous remercieront !"

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 le public à comprendre ce qui s'est passé. Vous pouvez déplacer les données et explications supplémentaires dans une annexe du rapport. Les examinateurs qui ont besoin d'informations supplémentaires peuvent les demander.

Éviter les solutions complexes ou surdimensionnées

Avant de commencer à explorer 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 se reproduiront probablement plus peut entraîner une instabilité accrue.

Partagez le post-mortem aussi largement que possible

Pour vous assurer que les problèmes ne restent pas sans solution, publiez les résultats de l'autopsie auprès d'une large audience et obtenez l'aide de la direction. La valeur d'une autopsie est proportionnelle à l'apprentissage qui a lieu après l'autopsie. Plus les utilisateurs tirent des enseignements des incidents, moins il est probable que des échecs similaires se reproduisent.