Modèle de maturité de fiabilité

Établir un terrain solide pour la résilience dans l’infrastructure et les opérations de charge de travail, plutôt que de consacrer du temps aux tâches d’optimisation.

Le niveau 1 du modèle de maturité est conçu pour aider les équipes de charge de travail à créer une base solide pour la fiabilité du système. L’accent est mis sur l’amorçage, qui est le processus de mise en place des principes de base pour les décisions futures en matière de fiabilité. Cette étape implique principalement l’implémentation fonctionnelle avec des extensions mineures aux pratiques actuelles.

Cette étape comprend la recherche, l’obtention d’insights et la création d’un inventaire de vos systèmes. Il utilise également des fonctionnalités de fiabilité intégrées sur Azure, telles que l’activation de la redondance de zone pour des améliorations immédiates.

En établissant ces principes de base, vous pouvez préparer votre équipe à passer par les niveaux du modèle de maturité de fiabilité afin d’améliorer progressivement la résilience et les performances de votre système.

Stratégies clés

• Évaluer les opportunités de décharger la responsabilité opérationnelle

Cette stratégie est fondamentalement une approche de construction par rapport à des options d'achat ou de reliance. La décision dépend de la responsabilité gérable à ce stade tout en soutenant le développement futur. Vous souhaitez utiliser des ressources pertinentes pour la charge de travail, mais vous devez toujours explorer les opportunités de décharger leur maintenance. Voici quelques cas d’usage classiques où vous souhaiterez peut-être appliquer cette approche.

• Déchargez les responsabilités sur la plateforme cloud en choisissant des solutions PaaS (Platform as a Service). Ils fournissent des solutions prêtes à l'emploi pour des besoins de résilience courants tels que la réplication, le basculement et les sauvegardes. Lorsque vous prenez cette approche, le fournisseur de cloud gère les améliorations apportées à l’hébergement, à la maintenance et à la résilience.

  Par exemple, le fournisseur de cloud réplique des données sur plusieurs nœuds de calcul et distribue les réplicas entre les zones de disponibilité. Si vous créez votre propre solution sur des machines virtuelles, vous devez gérer ces aspects vous-même, ce qui peut prendre du temps et être complexe.

• Déléguer les responsabilités pour les opérations qui ne sont pas directement liées aux objectifs métier de la charge de travail. Certaines opérations spécialisées, telles que la gestion et la sécurité de la base de données, peuvent avoir une incidence sur la fiabilité de votre charge de travail. Explorez la possibilité de faire gérer ces tâches par des équipes expérimentées, par la technologie ou par les deux.

  Par exemple, si votre équipe n’a pas d’expertise en base de données, utilisez des services managés pour aider à transférer la responsabilité au fournisseur. Cette approche peut être utile lorsque vous démarrez, car elle permet à votre équipe de se concentrer sur les fonctionnalités de la charge de travail. De nombreuses entreprises ont partagé des services gérés de manière centralisée. Si des équipes de plateforme sont disponibles, utilisez-les pour gérer ces opérations. Toutefois, cette approche peut ajouter des dépendances et une complexité organisationnelle.

  Sinon, si votre équipe a la bonne expertise, vous pouvez prendre une décision explicite d’utiliser ses compétences et sélectionner des services qui n’incluent pas de fonctionnalités de gestion.

• Déchargez les responsabilités des fournisseurs non-Microsoft. Choisissez les produits hors étagère comme point de départ. Créez des solutions personnalisées uniquement lorsqu’elles contribuent à la valeur métier de votre charge de travail.

Risque: Si l’option d’achat ou de confiance répond partiellement à vos besoins, vous devrez peut-être implémenter des extensions personnalisées. Cette méthode peut entraîner une situation de « verrouillage de personnalisation », où les mises à jour et la modernisation deviennent irréalisables. Passez régulièrement en revue vos besoins et comparez-les aux fonctionnalités de la solution. Développez une stratégie de sortie pour le moment où il y a un écart significatif entre les deux.

Le scénario opposé est également un risque. Bien que l’option d’achat ou de confiance semble plus simple au début, elle peut nécessiter une nouvelle évaluation et une refonte ultérieurement si les limitations du service PaaS, de la solution fournisseur ou des ressources appartenant à la plateforme ne répondent pas à la granularité ou au niveau d’autonomie nécessaire pour la charge de travail.

✓ Identifier les flux critiques utilisateur et système

La décomposition de la charge de travail en flux est cruciale à ce stade. Concentrez-vous sur les flux utilisateur et système . Les flux utilisateur déterminent les interactions utilisateur et les flux système déterminent la communication entre les composants de charge de travail qui ne sont pas directement associés aux tâches utilisateur.

Par exemple, dans une application de commerce électronique, les clients effectuent des activités frontales telles que la navigation et la commande. Pendant ce temps, les transactions principales et les processus déclenchés par le système répondent aux demandes des utilisateurs et gèrent d’autres tâches. Ces flux distincts font partie du même système, mais ils impliquent différents composants et servent des objectifs différents.

Commencez à créer un catalogue de flux à ce stade. Observez les interactions utilisateur et la communication des composants. Répertoriez et catégorisez les flux, définissez leurs points de départ et de fin, et notez les dépendances. Documentez les résultats et les exceptions à l’aide de diagrammes pour plus de clarté. Ce catalogue peut servir d’outil important pour la conversation initiale avec les parties prenantes de l’entreprise afin d’identifier les aspects les plus importants de leur point de vue. Cette conversation peut informer le premier niveau de hiérarchisation.

Classifiez un flux comme critique en évaluant le risque et l’impact sur les activités principales de l’entreprise. Si vous prévoyez une panne, la dégradation progressive se concentre sur le maintien de ces flux critiques. Dans l’exemple de commerce électronique, les flux critiques incluent les recherches de produits, l’ajout d’éléments au panier et l’extraction, car ces tâches sont essentielles pour l’entreprise. D’autres processus, tels que la mise à jour des données de produit et la maintenance des images de produit, ne sont pas aussi critiques. Assurez-vous que les flux critiques restent opérationnels pendant une panne afin d’éviter toute perte de revenus en permettant aux utilisateurs de continuer à rechercher des produits et à ajouter des éléments au panier.

Pour plus d’informations, consultez Azure Well-Architected Framework : Optimiser la conception de la charge de travail à l’aide de flux.

• Sélectionner le modèle de conception, les ressources et les fonctionnalités appropriés

Vous devez appliquer cette stratégie aux niveaux suivants :

• Architecture: La conception de la charge de travail doit tenir compte des attentes en matière de fiabilité dans différentes couches d’infrastructure. Vos décisions initiales peuvent être le choix entre la conteneurisation ou PaaS pour l’hébergement de l’application. Vous pouvez également envisager des configurations réseau telles que hub-and-spoke ou un seul réseau virtuel.

  Vous devez également définir des limites qui créent une segmentation basée sur les fonctionnalités. Par exemple, au lieu d’héberger tout sur une machine virtuelle avec un disque virtuel à zone unique, envisagez de fractionner le calcul et le stockage des données et d’utiliser des services dédiés.

  Avertissement

  Dans les scénarios de migration, l’adoption d’une approche lift-and-shift sans examiner les nouvelles opportunités peut entraîner des avantages manqués et des inefficacités. Il est important de rechercher rapidement la modernisation afin d’éviter d’être bloqué avec les configurations difficiles à modifier et de tirer parti de meilleures options et améliorations.

• Services Azure : Utilisez des arbres de décision pour vous aider à sélectionner les services appropriés pour votre conception. Choisissez les composants qui répondent à vos besoins actuels, mais restent flexibles afin de pouvoir changer de service à mesure que votre charge de travail évolue et nécessite davantage de fonctionnalités.

• Références SKU ou niveaux au sein des services Azure : Passez en revue les fonctionnalités de chaque référence SKU et comprenez les garanties de disponibilité de la plateforme. Évaluez les contrats de niveau de service pour comprendre la couverture fournie autour du centile publié.

• Fonctionnalités qui prennent en charge la fiabilité : Choisissez des services cloud natifs pour améliorer la disponibilité via des configurations simples sans modifier le code. Il est important de comprendre les options et de sélectionner intentionnellement des configurations, telles que l’augmentation de la redondance de zone ou la réplication de données dans une région secondaire.

✓ Déployer avec un niveau de redondance de base

Dans chaque partie de votre solution, évitez les points de défaillance uniques, tels que les instances uniques. Créez plusieurs instances pour la redondance à la place. Les services Azure gèrent souvent la redondance pour vous, en particulier avec les services PaaS, qui incluent généralement la redondance locale par défaut et les options à mettre à niveau. De préférence, utilisez la redondance de zone pour répartir ces instances sur plusieurs centres de données Azure. Si ce n’est pas le cas, assurez-vous au moins la redondance locale, mais cette méthode présente un risque plus élevé. Dans les niveaux futurs, vous évaluez si vos exigences de fiabilité peuvent être satisfaites en étendant la solution avec des composants géoredondants.

Compromis: Un compromis important est l’augmentation du coût de la redondance. En outre, la communication interzone peut introduire une latence. Pour les applications héritées qui nécessitent une latence minimale, la redondance peut dégrader les performances.

Risque: Si une application n’est pas conçue pour un environnement à plusieurs instances, elle peut rencontrer des difficultés avec plusieurs instances actives, ce qui peut entraîner des données incohérentes. En outre, si une application est créée pour une configuration locale qui a une faible latence, l’utilisation de zones de disponibilité peut perturber ses performances.

• Activer les métriques, les logs et les traces pour surveiller les flux

Choisissez des outils natifs de la plateforme comme Azure Monitor pour garantir la visibilité sur les métriques, les journaux et les traces. Utilisez des fonctionnalités intégrées pour définir des alertes pour les problèmes potentiels. Vous devez disposer d’alertes de base en place pour envoyer des notifications et obtenir des alertes. Tirez parti des fonctionnalités de plateforme Azure qui indiquent les modifications apportées à l’état d’intégrité des services, telles que :

• Azure Service Health pour vérifier l’état du système au niveau de la plateforme.

• Azure Resource Health pour vérifier l’état de santé à l’échelle des ressources.

Configurez des groupes d’actions Azure Monitor pour l’infrastructure et l’application.

Compromis : À mesure que vous collectez plus de logs, vous devez gérer le volume croissant, ce qui affecte les coûts de stockage de ces logs. Utilisez des stratégies de rétention pour gérer le volume. Utilisez Azure Monitor pour définir une limite quotidienne sur un espace de travail. Pour plus d’informations, consultez les recommandations de configuration pour la fiabilité.

Commencez à créer une observabilité aux couches suivantes.

Infrastructure

Commencez par activer les journaux de diagnostic et assurez-vous de collecter des métriques natives à partir de composants de plateforme à des fins d’analyse. Rassemblez des informations sur l’utilisation des ressources, telles que l’UC, la mémoire, l’entrée/sortie et l’activité réseau.

Application

Collectez les métriques au niveau de l'application, telles que la consommation de mémoire ou la latence des requêtes, et journalisez les activités de l'application. Effectuez des opérations de journalisation dans un thread ou un processus distinct du thread d’application principal. Cette approche n’entraîne pas la journalisation à ralentir les tâches principales de l’application.

Vérifiez également les tests de disponibilité de base dans Application Insights.

Données

Pour surveiller les bases de données à un niveau de base, collectez les métriques clés émises par les ressources de base de données. Comme pour les composants d’infrastructure, effectuez le suivi de l’utilisation des ressources dans le contexte des magasins de données, tels que les indicateurs réseau. La collecte de données sur la façon dont les connexions sont mises en pool est importante pour améliorer l’efficacité à des étapes ultérieures.

Pour une fiabilité, il est important de suivre les métriques de connexion, telles que la surveillance des connexions actives et ayant échoué. Par exemple, dans Azure Cosmos DB, un code d’état 429 est retourné lorsque le nombre de requêtes dépasse les unités de requête allouées et que les connexions commencent à échouer.

✓ Commencer à créer un playbook d’atténuation des défaillances

Les défaillances varient des pannes intermittentes aux pannes temporaires légèrement prolongées et aux pannes catastrophiques.

Au niveau 1, concentrez-vous sur les défaillances de la plateforme. Même s’ils sont au-delà de votre contrôle, vous devriez toujours avoir des stratégies pour les gérer. Par exemple, traitez les pannes zonales à l’aide de zones de disponibilité. Anticiper les erreurs temporaires au niveau de la plateforme et les gérer dans votre charge de travail.

Le processus de gestion de ces défaillances varie en fonction de la complexité. Commencez à documenter les défaillances potentielles au niveau de la plateforme, leurs risques associés et les stratégies d’atténuation. Cet exercice est principalement théorique et mûrit avec l’automatisation à des niveaux ultérieurs.

Vous devez documenter les échecs, y compris les facteurs tels que leur probabilité, leur impact et leurs stratégies d’atténuation. Utilisez une échelle de criticité qui s’aligne sur les objectifs de votre charge de travail. Votre échelle peut inclure :

• Élevé. Panne complète du système qui entraîne une perte financière significative et une baisse de confiance des utilisateurs.

• Moyen. Une interruption temporaire qui affecte une partie de la charge de travail et provoque des inconvénients de l’utilisateur.

• Faible. Un problème logiciel mineur qui affecte une fonctionnalité nonessential de l’application et provoque un temps d’arrêt minimal pour les utilisateurs.

Voici un exemple de modèle :

Au niveau 1, ne vous efforcez pas d'atteindre la complétude, car il y a toujours des cas d’échec imprévus. Si vous rencontrez des pannes inattendues, documentez les causes et les atténuations dans le playbook. Traitez cette ressource comme un document vivant que vous mettez à jour au fil du temps.

✓ Ajouter des mécanismes de récupération à partir d’échecs temporaires

Dans un environnement cloud, les défaillances temporaires sont courantes. Ils indiquent des problèmes à court terme que les nouvelles tentatives peuvent généralement résoudre en quelques secondes.

Utilisez des kits sdk et des configurations intégrés pour gérer ces erreurs pour maintenir le système actif. Les configurations intégrées sont souvent le paramètre par défaut. Vous devrez peut-être donc tester pour valider l’implémentation. Implémentez également des modèles conçus pour gérer les défaillances temporaires dans votre architecture. Pour plus d’informations, consultez Modèles de conception d’architecture qui prennent en charge la fiabilité.

Les problèmes persistants peuvent indiquer un échec qui n’est pas temporaire ou le début d’une panne. Ce scénario nécessite plus que de résoudre simplement les problèmes localisés au sein de l’application. Il s'agit d'examiner les flux critiques des utilisateurs et des systèmes et d'ajouter des techniques de préservation automatique ainsi que des stratégies de récupération. Ces méthodes sont des pratiques matures décrites par le niveau 2.

✓ Exécuter des tests de base

Intégrez les tests de fiabilité de base aux premières étapes du cycle de vie du développement logiciel. Recherchez les opportunités de test, en commençant par des tests unitaires pour valider les fonctionnalités et les configurations.

En outre, développez des cas de test simples pour les problèmes que vous identifiez dans le playbook d’atténuation des risques. Concentrez-vous sur un impact plus élevé, et réduisez les mesures d’atténuation des efforts. Par exemple, simuler des pannes réseau ou des problèmes de connectivité intermittente pour voir comment votre logique de nouvelle tentative résout les interruptions.

Risque: Les tests introduisent souvent des frictions dans le cycle de développement. Pour atténuer ce risque, effectuez des tests de fiabilité pouvant être suivis en même temps que les tâches de développement.

Le développement de fonctionnalités est la priorité et les tests peuvent introduire des frictions dans le cycle de développement. Il est plus facile de commencer à tester avant la fin du développement des fonctionnalités. La conception d’aspects non fonctionnels de l’application au début vous permet de les étendre au fur et à mesure que vous ajoutez des fonctionnalités fonctionnelles, plutôt que de créer un backlog de problèmes pour résoudre plus tard. Bien que cette approche nécessite plus d’efforts initialement, elle est gérable et empêche les problèmes plus importants ultérieurement.

Vérifier que le système reste fonctionnel et stable en incorporant des fonctionnalités de conservation automatique et en ayant un plan de récupération de base pour gérer les défaillances.

Les défaillances dans le cloud sont inévitables. Vos stratégies de résilience doivent s’efforcer de maintenir le système fonctionnel dans toutes les conditions. Le niveau 1 introduit des méthodes pour résoudre les défaillances temporaires. Le niveau 2 se concentre sur l’incorporation de stratégies de préservation de soi pour empêcher, détecter et récupérer des défaillances plus durables. Si elle n’est pas résolue, ces problèmes peuvent se transformer en pannes complètes.

Les flux critiques que vous identifiez au niveau 1 prennent la priorité. Ils nécessitent une résilience et des efforts de récupération accrus pour tous les composants, notamment les applications, les services et les bases de données. Attendez-vous à ajuster vos tailles d’approvisionnement initiales, les nombres d’instances et les stratégies de mise à l’échelle automatique pour réduire les risques de fiabilité.

Dans ce niveau, soyez intentionnel sur vos pratiques de surveillance et de test. Utilisez des techniques de supervision avancées qui s’alignent sur les besoins techniques et sont étendues aux équipes de développement. Développez le playbook simple pour couvrir les composants architecturaux que vous développez et possédez, comme le code d’application.

Stratégies clés

• Évaluer l’état actuel de résilience pour se protéger contre les défaillances

• Le niveau de redondance est-il suffisant pour résister aux défaillances ? Définissez une stratégie de redondance qui spécifie le nombre de ressources redondantes à gérer. Déterminez où placer ces ressources, que ce soit localement, entre des zones ou dans des emplacements géographiquement distribués. Évaluez les paramètres de la plateforme cloud et sélectionnez un niveau répondant aux besoins de l’entreprise et aux compromis acceptables.

• Les composants de charge de travail sont-ils suffisamment isolés pour contenir leurs défaillances ? Les modèles comme le modèle Bulkhead aident à renforcer la résilience et l’isolation des erreurs. Le modèle de cloisonnement partitionne un système en composants isolés, appelés bulkheads, pour empêcher les défaillances de cascader dans d’autres parties du système.

• Les composants du chemin critique communiquent-ils de façon asynchrone ? Si ce n’est pas le cas, utilisez des méthodes de communication, telles que des files d’attente. Cette approche maintient le système opérationnel même si un composant en aval échoue. Il empêche également le système d’entrer dans un état indéterminé. Explorez les options Azure, notamment Azure Service Bus pour les files d’attente et Azure Event Hubs pour les flux d’événements.

  Compromis: La communication asynchrone peut aider à empêcher les défaillances en cascade en découplant les processus. Toutefois, elle ajoute une latence dans le chemin de communication, ce qui peut poser un problème pour les composants critiques. Évaluez l’impact sur les performances avant d’apporter des modifications de modèle de conception.

• Les opérations sont-elles conçues pour la cohérence ? Les ressources telles que les secrets et certificats d’application peuvent expirer et nécessiter une actualisation régulière. Les incohérences dans les mises à jour de routine peuvent entraîner des problèmes de fiabilité.

  Dans l’idéal, identifiez et éliminez les tâches humaines en cours, car elles sont sujettes à des erreurs et peuvent entraîner des incohérences qui présentent des risques de fiabilité. Déchargez autant de tâches opérationnelles que possible sur le fournisseur de cloud. Par exemple, utilisez des identités managées que Microsoft Entra ID fournit et des certificats TLS (Transport Layer Security) gérés par Azure Front Door.

  La surveillance est requise pour les mesures proactives, telles que le suivi de l’expiration du certificat et la réception de notifications. L’application doit consigner des événements importants, comme un certificat TLS proche de l’expiration. L’utilisation de plusieurs méthodes pour vérifier les défaillances potentielles permet de s’assurer que les actions nécessaires sont effectuées.

✓ Ajouter des fonctionnalités techniques dans votre système de supervision

Au niveau 1, vous avez collecté des données de surveillance à partir des composants de charge de travail, avec un focus sur l’infrastructure. L’analyse de base est terminée et les alertes de base sont définies. Cette configuration est essentielle pour comprendre les performances de référence des composants de charge de travail et identifier le comportement anormal.

Le niveau 2 effectue une surveillance plus poussée en ajoutant des fonctionnalités d’observabilité avancées à vos ressources de charge de travail et en adoptant une approche plus structurée pour analyser les données de surveillance. Tirez parti des outils d’analyse fournis par votre service cloud. Par exemple, les outils d’insights Azure Monitor, tels que VM Insights et Network Insights, fournissent des visualisations de l’état de santé et des performances à travers les dépendances.

Planifiez les capacités d'observabilité aux niveaux suivants.

Application

• Répondez au sondage de l'état de santé. Permettre à l’application de répondre aux demandes de contrôle d’intégrité des sondes. L'application doit avoir des points de terminaison dédiés pour les vérifications de santé, qui fournissent au minimum des informations d'état telles qu'en bonne santé ou en mauvaise santé. Cette approche permet aux systèmes de surveillance d’évaluer si l’application fonctionne correctement et peut gérer les demandes, ou s’il existe des problèmes qui doivent être résolus.

  Les services d'équilibrage de charge Azure, tels qu'Azure Front Door, Azure Traffic Manager, Azure Application Gateway et Azure Load Balancer, prennent en charge les sondes de santé. Les sondes d’intégrité envoient des demandes de contrôle d’intégrité aux applications.

• Passez à la journalisation sémantique. Incluez des informations structurées sur les événements et les actions dans l’application. Avec la journalisation structurée, les données de journal sont enregistrées dans un format cohérent à l’aide d’un schéma bien défini. Ce schéma facilite la création d’automatisation, de recherche et d’analyse dans les phases ultérieures. Incluez des champs spécifiques tels que les horodatages et les codes d’erreur pour vous aider à identifier et résoudre rapidement les problèmes.

• Implémentez le suivi distribué. Lorsqu’une demande transite par différents composants du système, il est important de capturer les données de trace entre les limites. Ces données sont utiles pour obtenir des informations sur le comportement de l’application et identifier les goulots d’étranglement, erreurs et problèmes de latence des performances. Azure Monitor prend en charge la collecte de données basée sur OpenTelemetry avec Application Insights.

Données

• Suivez la durée des requêtes, les requêtes ayant échoué et d’autres métriques pertinentes. Les requêtes longues peuvent indiquer des contraintes de ressources et éventuellement une nécessité d’ajuster la conception du schéma.

  À ce stade, votre base de données fonctionne depuis un certain temps. Faites attention au taux de croissance des données, en particulier dans les tables qui augmentent rapidement de façon inattendue. Ces informations sont cruciales pour planifier les besoins futurs de stockage et résoudre les problèmes de performances dès le début.

• Surveillez l’état de la réplication de base de données à l’aide des outils et du tableau de bord fournis par le système de gestion de base de données. Par exemple, si vous utilisez Azure Cosmos DB, utilisez Azure Cosmos DB Insights. Pour Azure SQL Database ou Azure SQL Managed Instance, envisagez d’utiliser l’observateur de base de données pour obtenir des détails de diagnostic sur vos bases de données.

  À mesure que la base de données augmente, les problèmes de schéma peuvent devenir plus apparents, ce qui affecte les performances. Pour optimiser l’efficacité des requêtes, envisagez d’ajouter des index ou de modifier le schéma, car ces modifications peuvent affecter la fiabilité.

Opérations

Le niveau 1 se concentre sur les couches précédentes. Au niveau 2, vous commencez à créer des opérations autour du système de surveillance.

• Conservez les journaux suffisamment longtemps pour obtenir des informations. Du point de vue de la fiabilité, configurez la durée de rétention afin de pouvoir collecter suffisamment de données pour détecter les modèles d’échec, résoudre les problèmes et effectuer une analyse de la cause racine.

• Surveillez les processus de sauvegarde et de récupération. Vérifiez que les sauvegardes sont correctement stockées dans des emplacements comme prévu et que les données de charge de travail sont récupérées dans un délai raisonnable. La surveillance de ces processus est importante pour définir des lignes de base pour vos métriques d’objectif de point de récupération (RPO) à des niveaux ultérieurs.

- Étendre votre guide d’atténuation des défaillances

Le niveau 1 se concentre sur les échecs de plateforme attendus. Au niveau 2, vous résolvez les points d’échec sur les composants et les opérations au sein de votre propre charge de travail. À mesure que votre code s’exécute sur la plateforme, les points d’interaction entre la plateforme et l’application augmentent. Attendez-vous à des échecs de bogues dans votre code, à des déploiements infructueuses et à des erreurs humaines. Réduisez ces problèmes en utilisant des tactiques de préservation ou de récupération.

Étendez votre playbook d’atténuation des défaillances pour inclure des bogues et des problèmes de déploiement. Le tableau suivant s’appuie sur le modèle de niveau 1 :

Cet exercice peut devenir écrasant si vous essayez de tenir compte de chaque échec possible. Pour faciliter la tâche, concentrez-vous sur les composants qui font partie des flux utilisateur critiques. Ce document vivant continue de croître à mesure que la charge de travail arrive à maturité.

✓ Développer un plan de récupération de base

Le manuel d’atténuation des défaillances est la base de la création d’un plan de reprise de base. Les stratégies d’atténuation peuvent inclure l’implémentation du modèle de conception, les ajustements de configuration de la plateforme, la gestion des incidents de site en direct, les tests automatisés et le personnel de formation pour détecter les problèmes pendant les révisions de code.

Commencez par une stratégie de dégradation normale, qui inclut des correctifs temporaires lorsque des parties du système ne fonctionnent pas correctement. L’objectif est de continuer à servir les utilisateurs malgré les échecs en désactivant les parties non travaillées et en ajustant l’expérience utilisateur. Par exemple, si une base de données est en panne, l’application peut désactiver la fonctionnalité affectée et informer les clients que le service est temporairement indisponible à l’aide de codes d’état HTTP.

Pour que la dégradation progressive fonctionne, isolez les composants du système de sorte qu'uniquement les parties affectées rencontrent des problèmes tandis que le reste des composants continue de fonctionner. Utilisez le modèle Bulkhead pour assurer l'isolation des défauts.

Prenez cette occasion revisiter les choix de conception susceptibles de ralentir la récupération. Par exemple, le pointage des enregistrements DNS (Domain Name System) directement vers votre application sur Azure App Service peut entraîner des retards lors de la récupération en raison de la propagation DNS. Utilisez un service dédié comme Azure Front Door comme point d’entrée pour faciliter la reconfiguration pendant les étapes de récupération.

Attendez-vous à ce que ce plan de base évolue dans un plan de récupération d’urgence complet à des niveaux plus matures.

✓ Créer des plans de test

Créez des plans de test en simulant des pannes et des problèmes identifiés dans le playbook d’atténuation des risques. Compléter ces atténuations avec des cas de test simples pour s’assurer qu’elles fonctionnent comme prévu et sont réalisables. Vérifiez que ces fonctionnalités fonctionnent correctement et effectuent des tests de dégradation pour voir comment le système fonctionne quand des composants spécifiques échouent. Gardez le résultat simple en veillant à ce que le test échoue ou réussisse.

Utilisez des outils de test comme des frameworks fictifs pour injecter des erreurs dans des requêtes HTTP, ce qui vous aide à tester les stratégies de nouvelle tentative plus explicitement. Azure Chaos Studio fournit une suite de test complète pour simuler des pannes de composants et d’autres problèmes, ce qui en fait un service précieux à explorer. Vous pouvez adopter progressivement Chaos Studio au fur et à mesure que vous connaissez ses fonctionnalités.

• Évaluer l’impact des opérations de mise à l’échelle sur la fiabilité

Pour gérer les pics de charge, les composants critiques doivent pouvoir effectuer un scale-out ou un scale-up efficace. Tirez parti des fonctionnalités de mise à l’échelle automatique qu’Azure fournit. Ces fonctionnalités ajustent les limites de capacité d’un service en fonction des configurations prédéfinies. Cet ajustement vous permet d’effectuer un scale-up ou un scale-down du service en fonction des besoins.

• Identifiez les goulots d’étranglement potentiels et comprenez les risques qu’ils peuvent présenter. Par exemple, le débit élevé ne doit pas entraîner la panne du flux.

• Comprendre les modèles de charge. Les modèles d’utilisation statique peuvent réduire les goulots d’étranglement, mais les modifications apportées à l’utilisation et à la dynamique de la consommation peuvent aggraver les risques.

  Remarque

  Il peut y avoir des composants qui ne peuvent pas être mis à l’échelle, tels que des bases de données monolithiques et des applications héritées. Surveillez de manière proactive la courbe de charge pour permettre une nouvelle architecture si nécessaire.

• Déterminez les limites de mise à l’échelle raisonnables en fonction des exigences de performances et de fiabilité. Pour des raisons de performance, l'augmentation progressive de l'échelle est la plus courante. Toutefois, les préoccupations en matière de fiabilité pour les flux critiques peuvent nécessiter une mise à l’échelle plus rapide pour éviter les pannes. Dans les deux cas, évitez une mise à l’échelle infinie.

Risque: Lorsque vous rencontrez des problèmes liés aux performances, la mise à l’échelle peut être une stratégie d’atténuation utile. Toutefois, la mise à l’échelle est un correctif temporaire et non une solution. Examinez et résolvez le problème sous-jacent, tel qu’une fuite de mémoire ou un processus de fuite. Sinon, vous risquez d’appliquer à nouveau la même atténuation à un autre point de basculement et de payer pour les ressources dont vous n’avez pas besoin. En traitant la cause racine, vous pouvez garantir la stabilité à long terme et l’efficacité des coûts.

Définir des objectifs et des cibles de fiabilité pour que l’équipe reste responsable sur les procédures de récupération.

À des niveaux précoces, vos équipes se concentrent sur des gains faciles et des fonctionnalités de base. Ils commencent par de petites améliorations, résolvent des problèmes simples pour créer une base solide tout en s’appuyant principalement sur les fonctionnalités de fiabilité Azure. À mesure que vos équipes évoluent, elles gèrent des défis plus techniques liés à leurs propres ressources et processus.

Au niveau 3, vos équipes doivent intégrer des insights métier et des compétences techniques pour la planification de la récupération. Ils définissent des objectifs et planifient des processus de récupération à l’aide d’une surveillance avancée. Cette approche permet aux ingénieurs de fiabilité de site de répondre rapidement aux objectifs de fiabilité.

Stratégies clés

✓ Formaliser les capacités de fiabilité en tant qu’objectifs

Les objectifs de fiabilité aident à définir la responsabilité des équipes de charge de travail. Il est important d’avoir une conversation collaborative avec les parties prenantes de l’entreprise pour discuter des temps de récupération et des coûts, et de faire des compromis qui s’alignent sur les objectifs de l’entreprise. Rassemblez les parties prenantes et organisez cette discussion en tant qu’atelier. Tenez compte des points suivants pour l’ordre du jour de l’atelier :

• Expliquer les métriques derrière les objectifs. Commencez par expliquer les métriques clés utilisées pour définir des objectifs tels que des objectifs de niveau de service, des objectifs de temps de récupération (RTO) et des objectifs de point de récupération (RPO). Montrez comment ces métriques s’alignent sur les objectifs métier. Concentrez-vous sur les flux utilisateur critiques. Par exemple, dans une application d’e-commerce, l’objectif de temps de récupération pour la mise à jour des préférences de messagerie est moins important que le passage de la commande par les utilisateurs.

• Communiquez les compromis. Les parties prenantes s’attendent souvent plus que ce qui peut être réalisé. Expliquez comment l’expansion de l’étendue affecte le budget, les exigences opérationnelles et les performances.

• Proposer des cibles objectives. En fonction de l’expérience architecturale et de la conception de la charge de travail, recommandez des cibles telles que 99,9 % de disponibilité, avec l’objectif de point de récupération et l’objectif de temps de récupération définis à quatre heures. Faciliter une discussion pour les parties prenantes afin de fournir des commentaires et d’apporter des ajustements. Assurez-vous que les parties prenantes commerciales et techniques se gardent contre les attentes irréalistes. Approchez les discussions avec un état d’esprit collaboratif.

• Atteindre un consensus ou une décision. Visez un consensus, mais si cela n’est pas possible, qu’un décideur finalise les objectifs pour assurer la progression.

• Surveiller de manière proactive à l’aide de votre modèle de santé

Au niveau 1, les données de surveillance sont collectées à partir de composants de charge de travail, notamment les services de plateforme et les applications. L’analyse de base et les alertes sont définies pour établir les performances de référence et identifier les anomalies. Au niveau 2, le focus passe à l’obtention de données d’observabilité à partir de composants de charge de travail, tels que le code d’application.

Le niveau 3 améliore la surveillance en ajoutant le contexte métier aux flux critiques et en définissant des états sains, non sains et détériorés par le biais de la modélisation de l’intégrité. L'accord des parties prenantes est nécessaire pour déterminer les compromis acceptables concernant l'expérience utilisateur et doit être utilisé comme entrée pour définir les états de santé.

La modélisation de la santé nécessite une maturité opérationnelle et une expertise dans les outils de surveillance. Votre équipe examine les données brutes, les niveaux de performances et les journaux pour créer des métriques et des seuils personnalisés qui définissent l’état d’intégrité du flux. Ils doivent comprendre comment ces valeurs sont liées à l’intégrité globale du système. Communiquez des définitions et des seuils clairs aux parties prenantes.

Visualisez le modèle d’intégrité dans les tableaux de bord pour aider les ingénieurs de fiabilité à identifier rapidement les problèmes en mettant l’accent sur des flux non sains ou détériorés.

Le modèle d’intégrité définit l’état de l’application et les flux critiques. Vert indique que tous les flux critiques fonctionnent comme prévu. Rouge indique un échec. Et le jaune montre les tendances vers les problèmes. L'itération à travers les versions du modèle de santé garantit la fiabilité et la précision, mais nécessite un effort important pour les applications volumineuses.

Une modification de l’état de santé doit être configurée sous forme d’alerte. Toutefois, pour conserver les alertes intentionnelles, la criticité du composant doit être prise en compte.

Pour plus d’informations, consultez Well-Architected Framework : Modélisation de la santé.

✓ Définir des alertes actionnables

Pour améliorer l’efficacité de la réponse, définissez clairement les alertes et fournissez suffisamment d’informations pour une action rapide. Les noms et descriptions d’alertes détaillés peuvent vous aider à gagner du temps et des efforts pendant la résolution des problèmes. Configurez soigneusement la sévérité, le nom et la description, avec une attention particulière aux niveaux de sévérité. Chaque événement n’est pas une urgence. Évaluez de manière réfléchie les niveaux de gravité et établissez des critères pour chaque niveau, par exemple si un pic de processeur de 80% à 90% se qualifie comme une urgence. Définissez les seuils appropriés pour vous assurer que les alertes sont définies efficacement.

Une gestion efficace des alertes garantit que les alertes informent les bonnes personnes au bon moment. Les alertes fréquentes et perturbatrices indiquent un besoin d’ajustement et peuvent devenir contre-productives lorsqu’elles sont ignorées. Réduisez les notifications inutiles en définissant les seuils appropriés pour filtrer les fausses alarmes. Identifiez les opportunités où l’automatisation peut déclencher des procédures opérationnelles.

Créez une page d’accueil unique qui contient les informations nécessaires pour résoudre efficacement les problèmes d’alertes. Cette approche permet de gagner du temps par rapport à la connexion au portail Azure et à la recherche de métriques. Si les fonctionnalités intégrées d’Azure Monitor ne répondent pas entièrement à vos besoins, envisagez de développer un tableau de bord personnalisé.

✓ Effectuer une analyse du mode d’échec

Dans les niveaux précédents, vous avez créé un playbook d’atténuation des défaillances simple pour les composants individuels. À ce niveau, faites évoluer ce playbook en un exercice d’analyse formelle du mode d’échec (FMA). L’objectif de cet exercice est d’identifier de manière proactive les modes d’échec potentiels.

FMA vous oblige à identifier les points de défaillance potentiels au sein de votre charge de travail et à planifier des actions d’atténuation, telles que l'auto-réparation ou la reprise après sinistre. Pour commencer, surveillez les taux d’erreur accrus et détectez les impacts sur les flux critiques. Utilisez les expériences passées et les données de test pour identifier les défaillances potentielles et évaluer leur rayon d’explosion. Hiérarchiser les problèmes majeurs tels qu’une panne à l’échelle de la région.

Il est important de classer les actions comme préventives ou réactives. Les actions préventives identifient les risques avant qu’elles ne provoquent une panne, ce qui réduit leur probabilité ou leur gravité. Les actions réactives traitent les problèmes pour atténuer un état de santé dégradé ou une panne.

Dans l’exemple d’application de commerce électronique, l’équipe de charge de travail souhaite effectuer une FMA pour se préparer à un événement majeur. L’un des flux utilisateur clés ajoute des éléments au panier. Les composants qui font partie du flux sont le front-end, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB et Azure Event Hubs.

FMA est complexe et peut prendre du temps, alors construisez votre analyse progressivement. Ce processus est itératif et continue à évoluer à des stades ultérieurs.

Pour plus d’informations, consultez RE:03 Recommandations pour effectuer une FMA.

✓ Préparer un plan de récupération après sinistre

Au niveau 2, vous avez créé un plan de récupération axé sur les contrôles techniques pour restaurer les fonctionnalités système. Toutefois, une catastrophe nécessite une approche plus large en raison d’une perte ou d’une défaillance catastrophiques. Les plans de reprise après sinistre sont basés sur des processus. Ils couvrent la communication, les étapes de récupération détaillées et peuvent inclure des artefacts techniques tels que des scripts.

Tout d’abord, identifiez les types de sinistres à planifier, tels que les pannes de région, les défaillances à l’échelle d’Azure, les interruptions d’infrastructure, la corruption de base de données et les attaques par ransomware. Ensuite, développez des stratégies de récupération pour chaque scénario et assurez-vous que les mécanismes sont en place pour restaurer les opérations. Les exigences métier, les RTO et les RPO doivent guider les plans de récupération d’urgence. Les RPO et les RPO faibles nécessitent des processus automatisés explicites, tandis que des RPO et des RPO plus élevés permettent de simplifier les méthodes de récupération et l’analyse manuelle.

Les DR incluent principalement ce qui suit :

• Informez les parties responsables. Il est important d’avoir de la clarté sur les personnes à impliquer et quand. Assurez-vous que votre équipe utilise les processus appropriés, dispose des autorisations appropriées et comprend leurs rôles dans la récupération. Certaines responsabilités, telles que le PDG présentant des rapports au marché ou traitant des exigences réglementaires, devraient être identifiées au plus tôt.

  Dans l’idéal, vous devez disposer de rôles de récupération et de communication distincts et attribuer des personnes différentes à chaque rôle. Initialement, la personne chargée des opérations informatiques qui découvre le problème peut gérer les deux rôles. Mais à mesure que la situation augmente, le personnel supérieur peut gérer la récupération technique pendant qu’une personne d’entreprise gère les communications.

• Prenez des décisions commerciales. Au cours d’une catastrophe, les niveaux de stress peuvent être élevés, ce qui rend la prise de décision claire essentielle. Un plan de récupération d’urgence bien structuré nécessite des discussions continues entre l’équipe technique et les parties prenantes de l’entreprise pour définir des options de décision préliminaires. Par exemple, déterminez si les ressources de charge de travail doivent s’exécuter dans une région Azure avec des sauvegardes dans une autre région, ou si les ressources IaC doivent être préparées à l’avance pour créer de nouvelles ressources ou restaurer à partir d’une sauvegarde pendant le basculement.

  Les mesures prises selon les plans de récupération d’urgence peuvent être destructrices ou avoir des effets secondaires importants. Il est essentiel de comprendre les options, de peser leurs avantages et leurs inconvénients, et de déterminer le bon moment pour les appliquer. Par exemple, évaluez si la récupération dans une autre région est nécessaire si la région primaire est censée être opérationnelle dans un délai acceptable.

• Restaurer les opérations système. Lors d’un sinistre, le focus doit être mis sur la restauration des opérations et non sur l’identification de la cause. Pour la récupération technique, en particulier dans le basculement régional, décidez à l’avance des approches comme actif/actif, actif/passif, secours semi-automatique ou reprise progressive.

  Préparez des étapes de récupération spécifiques en fonction de l’approche choisie. Commencez par une liste concrète des étapes de restauration. À mesure que le processus arrive à maturité, visez à définir le plan de récupération d’urgence en tant que script avec une interaction manuelle minimale. Utilisez le contrôle de version et stockez le script de manière sécurisée pour faciliter l’accès. Cette approche nécessite un effort plus rapide, mais réduit le stress pendant un incident réel.

  Pour plus d’informations, consultez Déployer en mode actif-passif pour le Plan de Reprise d'Activité (PRA).

• Effectuez une analyse post-incident. Identifiez la cause de l’incident et trouvez des moyens de l’empêcher à l’avenir. Apportez des modifications pour améliorer les processus de récupération. Cet exercice peut également découvrir de nouvelles stratégies. Par exemple, si le système est passé à l’environnement secondaire, déterminez si l’environnement principal est encore nécessaire et quel processus de retour au système principal doit être appliqué.

Un plan de récupération d’urgence est un document vivant qui s’adapte aux modifications de votre charge de travail. Mettez à jour votre plan de DR à mesure que de nouveaux composants et risques émergent. Affinez le plan en fonction des informations obtenues lors des exercices ou des catastrophes réelles en collectant des données pertinentes auprès des opérateurs de DR.

icône Contrôler les risques qui découlent des modifications techniques et opérationnelles, et hiérarchiser la gestion des incidents.

Dans les niveaux précédents, votre équipe de charge de travail se concentre sur la création de fonctionnalités et le fonctionnement du système. Au niveau 4, l'accent est mis sur le maintien de la fiabilité du système en production. La gestion des incidents devient aussi importante que de s’assurer que les modifications introduites sont soigneusement testées et déployées en toute sécurité pour éviter que le système ne soit instable.

Ce processus nécessite des améliorations dans les contrôles opérationnels, tels que l’investissement dans des équipes dédiées pour gérer les incidents de fiabilité. Il nécessite également des contrôles techniques pour améliorer la fiabilité du système au-delà des composants critiques renforcés dans les niveaux précédents. À mesure que le système continue à s’exécuter en production, la croissance des données peut nécessiter des refontes, telles que le partitionnement, pour garantir un accès et une maintenance fiables.

Stratégies clés

✓ Gestion fiable des changements

Les risques de fiabilité les plus importants se produisent pendant les modifications, telles que les mises à jour logicielles, les ajustements de configuration ou les modifications de processus. Ces événements sont essentiels du point de vue de la fiabilité. L’objectif est de réduire la probabilité de problèmes, de pannes, de temps d’arrêt ou de perte de données. Chaque type de changement nécessite des activités spécifiques pour gérer efficacement ses risques uniques.

Au niveau 4, la fiabilité se croise avec les pratiques de déploiement sécurisées décrites dans l’excellence opérationnelle, dans le maintien d’un environnement stable lors de la gestion des modifications. La gestion fiable des changements est nécessaire pour assurer la stabilité de la charge de travail. Tenez compte des aspects clés suivants :

• Réagir aux mises à jour de la plateforme. Les services Azure ont différents mécanismes pour mettre à jour les services.

  • Familiarisez-vous avec les processus de maintenance et mettez à jour les stratégies de chaque service que vous utilisez. Découvrez si le service prend en charge les mises à niveau automatiques ou manuelles et le délai d’exécution des mises à jour manuelles.

  • Pour les services qui ont planifié des mises à jour, gérez ces mises à jour efficacement en les planifiant pendant des périodes à faible impact. Évitez les mises à jour automatiques et les reportez jusqu’à ce que vous évaluez le risque. Certains services vous permettent de contrôler le minutage, tandis que d’autres services fournissent une période de grâce. Par exemple, avec Azure Kubernetes Service (AKS), vous avez 90 jours pour choisir avant que la mise à jour ne devienne automatique. Testez les mises à jour dans un cluster hors production qui met en miroir votre configuration de production pour empêcher les régressions.

    Appliquez progressivement les mises à jour. Même si les tests montrent que la mise à jour est sécurisée, l’application simultanée à toutes les instances peut être risquée. À la place, mettez à jour quelques instances à la fois et attendez entre chaque ensemble.

  • Vérifiez régulièrement les notifications relatives aux mises à jour, qui peuvent être disponibles dans les journaux d’activité ou d’autres canaux spécifiques au service.

  • Surveillez les modifications soudaines ou progressives après l’application d’une mise à jour. Dans l’idéal, votre modèle de santé doit vous informer de ces modifications.

• Tests approfondis avec automatisation. Intégrez davantage de tests à vos pipelines de build et de déploiement lorsque vous déployez des modifications. Recherchez des opportunités de conversion de processus manuels en parties automatisées de vos pipelines.

  Effectuez des tests complets à l’aide d’une combinaison de différents types de tests à différentes étapes pour confirmer que les modifications fonctionnent comme prévu et n’affectent pas d’autres parties de l’application. Par exemple, les tests positifs peuvent vérifier que le système fonctionne comme prévu. Il doit vérifier qu’il n’y a pas d’erreurs et que le trafic circule correctement.

  Lorsque vous planifiez des mises à jour, identifiez les portes de test et les types de tests à appliquer. La plupart des tests doivent se produire dans les phases de prédéploiement, mais les tests de fumée doivent également être effectués dans chaque environnement lorsque vous la mettez à jour.

• Suivez les pratiques de déploiement sécurisées. Utilisez des topologies de déploiement qui incluent des fenêtres de validation et des pratiques de déploiement sécurisées. Implémentez des modèles de déploiement sécurisés, tels que les déploiements canari et bleu-vert, pour améliorer la flexibilité et la fiabilité.

  Par exemple, dans les déploiements canary, un petit sous-ensemble d’utilisateurs reçoit d’abord la nouvelle version. Ce processus permet la surveillance et la validation avant le déploiement sur l’ensemble de la base utilisateur. Les techniques telles que les indicateurs de fonctionnalité et les lancements sombres facilitent les tests en production avant de publier des modifications pour tous les utilisateurs.

• Mettez à jour votre plan de reprise après sinistre. Mettez régulièrement à jour votre Plan de reprise d'activité pour qu’il reste pertinent et efficace. Évitez les instructions obsolètes. Cette approche garantit que le plan reflète l'état actuel de votre système déployé en production et fiable pour les utilisateurs. Incorporez les leçons tirées des exercices et des incidents réels.

Pour plus d’informations, consultez Le niveau d’excellence opérationnelle 4

• Investir dans une équipe dédiée pour gérer les incidents

Initialement, l’équipe de développement peut être impliquée pendant les incidents. Au niveau 4, investissez dans l’ingénierie de fiabilité de site (SRE) pour la gestion des incidents. Les SSR se spécialisent dans les problèmes de production et sont des experts en efficacité, en gestion des changements, en surveillance, en réponse aux urgences et en gestion de la capacité. Une équipe SRE compétent peut réduire considérablement la dépendance vis-à-vis de l’équipe d’ingénierie.

Fournissez aux SSR les outils, les informations et les connaissances nécessaires pour gérer les incidents indépendamment. Cette préparation réduit la dépendance de l’équipe d’ingénierie. Les SRE doivent être formés dans les manuels d'intervention et le modèle de santé de la charge de travail développé dans les niveaux précédents pour reconnaître rapidement les modèles courants et initier le processus d'atténuation.

L’équipe d’ingénierie doit avoir le temps de réfléchir à des problèmes récurrents et de développer des stratégies à long terme, au lieu de les traiter individuellement à chaque fois.

✓ Automatiser les processus d'auto-réparation

Dans les niveaux précédents, les stratégies d’auto-guérison sont conçues à l’aide de modèles de redondance et de conception. Maintenant que votre équipe a une expérience d’utilisation réelle, vous pouvez intégrer l’automatisation pour atténuer les modèles d’échec courants et réduire la dépendance vis-à-vis de l’équipe d’ingénierie.

Compromis: L’automatisation peut prendre du temps et être coûteuse à configurer. Concentrez-vous sur l’automatisation des tâches les plus impactées en premier, telles que les tâches qui se produisent souvent ou susceptibles d’entraîner des pannes.

Configurez des actions basées sur des déclencheurs et automatisez les réponses au fil du temps pour créer un playbook automatisé pour les SSR. Une approche consiste à améliorer le playbook avec des scripts qui implémentent des étapes d’atténuation. Explorez les options natives Azure, telles que l’utilisation de groupes d’actions Azure Monitor, pour configurer des déclencheurs qui lancent automatiquement différentes tâches.

✓ Étendre la résilience aux tâches en arrière-plan

La plupart des charges de travail incluent des composants qui ne prennent pas directement en charge les flux utilisateur, mais jouent un rôle essentiel dans le flux de travail global d’une application. Par exemple, dans un système de commerce électronique, lorsqu’un utilisateur place une commande, le système ajoute un message à une file d’attente. Cette action déclenche plusieurs tâches en arrière-plan, telles que la confirmation par e-mail, la finalisation des frais de carte de crédit et la notification d’entrepôt pour la préparation de la distribution. Ces tâches fonctionnent séparément des fonctions qui servent les demandes des utilisateurs sur le site web, ce qui réduit la charge et améliore la fiabilité. Les systèmes s’appuient également sur des tâches en arrière-plan pour le nettoyage des données, la maintenance régulière et les sauvegardes.

Après avoir évalué et amélioré vos flux d’utilisateurs principaux, tenez compte des tâches en arrière-plan. Utilisez les techniques et l’infrastructure déjà en place et ajoutez des améliorations pour les tâches en arrière-plan.

• Appliquez le processus de vérification par points de contrôle. Le point de contrôle est une technique permettant d’enregistrer l’état d’un processus ou d’une tâche à des points spécifiques. Le point de contrôle est particulièrement utile pour les tâches ou processus de longue durée susceptibles d’être interrompus en raison de problèmes inattendus tels que les défaillances réseau ou les incidents système. Lorsque le processus redémarre, il peut récupérer à partir du dernier point de contrôle enregistré, ce qui réduit l’impact des interruptions.

• Conservez les processus idempotents. Assurez-vous de l'idempotence dans les processus en arrière-plan afin qu'en cas d'échec d'une tâche, une autre instance puisse la reprendre et continuer le traitement sans problème.

• Vérifiez la cohérence. Empêchez le système d’entrer un état incohérent si une tâche en arrière-plan s’arrête pendant le traitement. Les points de contrôle et l’idempotence au niveau des tâches sont des techniques permettant une plus grande cohérence entre les opérations de tâches en arrière-plan. Exécutez chaque tâche en tant que transaction atomique. Pour une tâche qui s’étend sur plusieurs magasins de données ou services, garantissez son achèvement à l’aide de l’idempotence au niveau des tâches ou de transactions de compensation.

• Intégrez des tâches en arrière-plan à votre système de surveillance et à vos pratiques de test. Détectez les défaillances et empêchez les interruptions qui peuvent entraîner des conséquences fonctionnelles et non fonctionnelles. Votre système de surveillance doit capturer des données à partir de ces composants, définir des alertes pour les interruptions et utiliser des déclencheurs pour réessayer ou reprendre automatiquement le processus. Traitez ces ressources dans le cadre de la charge de travail et effectuez des tests automatisés de la même façon que pour les composants critiques.

Azure fournit plusieurs services et fonctionnalités pour les travaux en arrière-plan, tels qu’Azure Functions et Azure App Service WebJobs. Passez en revue leurs meilleures pratiques et limites lorsque vous implémentez des flux qui se concentrent sur la fiabilité.

Reste résiliente à mesure que l’architecture de charge de travail évolue, ce qui permet au système de résister aux risques nouveaux et imprévus.

Au niveau 5, l’amélioration de la fiabilité de votre solution s’éloigne de l’implémentation de contrôles techniques. Votre infrastructure, vos applications et vos opérations doivent être suffisamment fiables pour être résilientes aux pannes et récupérer à partir de celles-ci dans les délais de récupération cibles.

Utilisez des données et des objectifs métier futurs pour reconnaître que si votre entreprise doit aller plus loin, les modifications architecturales peuvent être nécessaires. À mesure que votre charge de travail évolue et que de nouvelles fonctionnalités sont ajoutées, essayez de réduire les pannes liées à ces fonctionnalités tout en réduisant davantage les pannes pour les fonctionnalités existantes.

Stratégies clés

✓ Utiliser des insights de fiabilité pour guider l’évolution de l’architecture

À ce niveau, prenez des décisions en collaboration avec les parties prenantes de l’entreprise. Tenez compte des facteurs suivants :

• Analysez les métriques qui indiquent combien de fois votre système dépasse les seuils de fiabilité dans un délai et indique si cela est acceptable. Par exemple, cinq pannes majeures en un an peuvent déclencher une réévaluation de la conception du système et des pratiques opérationnelles.

• Évaluez la criticité métier du système. Par exemple, un service qui prend en charge les flux de travail stratégiques peut nécessiter une nouvelle conception pour les déploiements sans temps d’arrêt et le basculement instantané, même s’il augmente le coût ou la complexité. À l’inverse, un service à usage réduit peut bénéficier d’objectifs de niveau de service plus souples.

• Évaluez la façon dont les changements dans d’autres piliers affectent la fiabilité. Par exemple, des mesures de sécurité accrues peuvent nécessiter des atténuations de fiabilité pour des tronçons de sécurité supplémentaires, ce qui peut introduire des points de défaillance potentiels.

• Évaluez les coûts opérationnels de la maintenance de la fiabilité. Si ces coûts dépassent les contraintes budgétaires, envisagez des modifications architecturales pour optimiser et contrôler les dépenses.

Pour aider les parties prenantes, les ingénieurs et les responsables de produits à prendre des décisions éclairées, envisagez de visualiser les points de données précédents avec des insights supplémentaires. Cette approche fournit une image complète de la fiabilité.

✓ Exécuter des tests contrôlés en production

À ce niveau, envisagez des expériences contrôlées en production uniquement si la charge de travail nécessite les garanties de résilience les plus élevées. Ces pratiques de test sont appelées ingénierie du chaos. Les tests valident que le système peut récupérer correctement et continuer à fonctionner dans des conditions défavorables.

Prenons l’exemple de cas d’usage suivant :

• Analyse du flux de dépendances : Un cas d’usage courant consiste à tester des applications conçues en tant que microservices. Vous pouvez désactiver les instances de microservice aléatoires pour vous assurer que les échecs ne se cascadent pas ou interrompent l’expérience utilisateur. Vous pouvez étendre cette approche aux flux système en désactivant des composants spécifiques pour analyser la façon dont les systèmes en aval réagissent. L’objectif est d’identifier un couplage étroit ou des dépendances masquées et de tester la façon dont les plans de redondance du système s’exécutent.

• Test de dégradation gracieuse : Évaluez la façon dont le système s’exécute avec des fonctionnalités réduites en cas de défaillance. Par exemple, vous pouvez masquer les fonctionnalités non critiques si un moteur de recommandation échoue.

• Simulation d’échec tierce : Désactivez ou limitez les appels aux API externes pour voir comment votre système fonctionne et si les secours ou les nouvelles tentatives sont correctement implémentées.

L’ingénierie du chaos est une norme d’or pour tester la résilience. Toutefois, réservez cette pratique pour les systèmes et les équipes de charge de travail matures. Assurez-vous que les mesures de protection sont en place pour limiter le rayon d’explosion et empêcher l’impact de l’utilisateur.

• Préparez-vous en organisant des journées de simulation. Commencez dans des environnements hors production qui simulent des conditions réelles à l’aide de configurations à faible risque avec des transactions synthétiques. Cette approche permet d’identifier les lacunes de processus, les chemins d’erreur humains et les défauts architecturaux.

  Lorsque les tests hors production arrêtent de produire des insights précieux, il peut être temps de passer à la production si vous êtes confiant. Veillez à répertorier tous les problèmes, à évaluer la résilience et à résoudre les problèmes avant la transition.

• Limitez l’étendue des expériences. Par exemple, vous ne pouvez arrêter qu’une seule instance. Définissez clairement l’objectif du test. Comprenez ce que vous testez et pourquoi.

Ces tests doivent respecter les contrats de niveau de service en fonctionnant dans des limites prédéfinies et des budgets d’erreur. Sélectionnez les délais appropriés pour ces expériences. En règle générale, les effectuer pendant un jour de travail garantit que l’équipe est entièrement en personnel et dispose de ressources suffisantes pour répondre à tous les incidents susceptibles de se produire.

• Effectuer des exercices de récupération d’urgence

L’ingénierie du chaos teste la résilience des mesures techniques. Les exercices de récupération d’urgence évaluent la résilience des contrôles de processus. L’objectif des exercices de récupération d’urgence est de valider l’efficacité des procédures, de la coordination et des actions humaines lorsque votre système récupère des défaillances ou des sinistres majeurs.

Pour les charges de travail réglementaires, les exigences de conformité peuvent dicter la fréquence des exercices de DR pour garantir un enregistrement des efforts. Pour d’autres charges de travail, il est recommandé de procéder régulièrement à ces exercices. Un intervalle de six mois permet de capturer les modifications de charge de travail et de mettre à jour les procédures de récupération d’urgence en conséquence.

Les exercices de récupération d’urgence doivent être plus que des exercices de routine. Lorsqu’elles sont effectuées correctement, les exercices DR aident à former de nouveaux membres de l’équipe et à identifier les lacunes dans les outils, la communication et d’autres tâches liées aux exercices. Ils peuvent également mettre en évidence de nouvelles perspectives qui pourraient autrement être ignorées.

Tenez compte des méthodes clés suivantes pour effectuer des exercices de récupération d’urgence, chacune variable en termes de risque et de pratique :

• Entièrement simulé : Ces exercices sont entièrement basés sur des tableaux blancs et incluent des procédures pas à pas sans affecter de systèmes. Ils conviennent à la formation et à la validation initiale. Toutefois, ils ne fournissent pas d’informations sur les incidents réels.

• Exercices réels dans des environnements hors production : Ces exercices vous permettent de valider l’automatisation, les scripts et les processus sans risque métier.

• Exercices réels en production : Ces exercices fournissent le niveau de confiance et de réalisme le plus élevé. Effectuez ces exercices uniquement après avoir testé les deux méthodes précédentes. La planification minutieuse et les stratégies de restauration sont essentielles pour réduire les risques. Ne continuez pas s’il y a des chances de provoquer des pannes.

Quel que soit le type d’exercice de DR, définissez clairement les scénarios de reprise de charge de travail. Effectuez des exercices comme s’il s’agit d’incidents réels. Cette approche garantit que l’équipe suit des listes de contrôle bien comprises. Documentez et classifiez les résultats pour favoriser l’amélioration continue. Votre préparation de reprise après sinistre peut inclure les processus suivants :

• Comprenez les systèmes de gestion des incidents et assurez-vous que l’équipe est formée sur des chemins d’escalade.

• Répertoriez les outils de communication pour la collaboration et les mises à jour d’état, y compris les alternatives dans le cas où les systèmes principaux sont affectés.

• Fournissez des documents de compétence sur des scénarios de test pertinents pour la charge de travail.

• Suivez les différences pour capturer les problèmes rencontrés lors de l’implémentation.

Compromis : Ces exercices ne sont généralement pas perturbants, mais ils prennent du temps. Pour optimiser leur efficacité, concentrez-vous sur les aspects clés et évitez les tâches inutiles. Veillez à allouer du temps pour cette pratique dans votre liste de tâches.

Lorsque vous créez des plans de récupération d’urgence ou effectuez des exercices de récupération d’urgence, en particulier pour les premiers exercices, envisagez d’inclure une expertise spécialisée. Leur contribution sur la conception multirégionale, les stratégies de basculement et de reprise, ainsi que les services ou outils, peut être inestimable. Si votre organisation dispose d’une équipe Cloud Center of Excellence, veillez à les inclure dans le processus de planification.

✓ Évaluer votre modèle de données et un segment si nécessaire

Les données sont dynamiques et en constante évolution. Contrairement aux autres composants de votre architecture, les données augmentent généralement à mesure que les utilisateurs interagissent avec votre système. La surveillance des modèles de données au fil du temps et l’évaluation de leur impact sur d’autres parties de votre architecture est essentielle. À ce niveau, envisagez des techniques qui simplifient la gestion des données et améliorent les performances pour améliorer la fiabilité globale. Le partitionnement est une stratégie clé pour atteindre ces résultats.

Explorez des techniques telles que le partitionnement à froid chaud, qui divise les données en fonction des modèles d’accès et les stocke séparément. Utilisez des critères tels que la fréquence d’accès ou la pertinence pour décider de ce qu’il faut partitionner.

Le partitionnement chaud-froid peut être combiné avec le partitionnement, à savoir un processus qui divise une base de données volumineuse en unités plus petites appelées partitions. Chaque fragment contient une partie des données, et ensemble, ils forment le jeu de données complet. Cette approche permet la gestion indépendante des données.

Compromis : l’équilibrage des partitions nécessite des processus opérationnels permettant d’évaluer et de vérifier leur distribution. Cette approche permet d’éviter les partitions chaudes où une partition est surutilisée. Toutefois, il nécessite également des efforts et des ressources continus pour maintenir l’équilibre.

Lorsque vous choisissez une technique de partitionnement, tenez compte des avantages de fiabilité suivants :

• Performances améliorées : En distribuant des requêtes sur plusieurs partitions, vous pouvez réduire la charge sur des magasins individuels. En cas d’implémentation efficace, le partitionnement permet à un système de traiter des millions de demandes d’écriture par jour. Cette stratégie améliore les performances et réduit la latence.

  Le partitionnement peut simplifier la mise à l’échelle horizontale. Par exemple, le partitionnement peut diviser les utilisateurs ou les clients en compartiments de taille égale.

• Gestion améliorée des données : Le partitionnement à froid chaud permet d’appliquer différents niveaux de gestion des données à chaque niveau de stockage. Par exemple, le déplacement de données d’archivage vers un magasin distinct permet d’éviter les ralentissements des opérations et des sauvegardes. De même, toutes les données de journal ne doivent pas être stockées dans une base de données relationnelle. Il peut être stocké dans un autre magasin de données, tandis que les données de charge de travail actives restent relationnelles.

• Stratégies de fiabilité personnalisées : Différentes stratégies de fiabilité peuvent être appliquées pour vous assurer que chaque partition a le bon niveau de résilience et empêche tout magasin unique de devenir un goulot d’étranglement. Les partitions à chaud peuvent être entièrement redondantes, notamment la redondance de zone et la géoredondance, tandis que les partitions à froid s’appuient sur des sauvegardes. Un avantage de fiabilité supplémentaire est que vous pouvez réduire le rayon d’explosion de certains types de défaillances. Par exemple, si une défaillance affecte une partition, elle peut ne pas affecter les autres partitions.

Compromis: Il peut être difficile de conserver ou de modifier des partitions en raison des interdépendances fortes entre différentes partitions de données. Ces modifications peuvent affecter la possibilité de vérifier la cohérence et l’intégrité des données, en particulier par rapport à un magasin de données unique. À mesure que le nombre de partitions augmente, la nécessité de processus robustes pour maintenir l’intégrité des données devient plus cruciale. Sans ces mesures, la fiabilité peut être compromise.