Évaluation et Configuration de la Fiabilité Azure

Référence Rapide

Quand Utiliser Cette Compétence

Activez cette compétence quand l'utilisateur souhaite :

• « Évaluer la fiabilité de mon application Function »
• « Évaluer la fiabilité de mon application Web »
• « Vérifier la fiabilité de mon groupe de ressources » (App Service et Functions uniquement)
• « Mon app est-elle zone-redondante ? » (App Service et Functions uniquement)
• « Mon plan App Service est-il zone-redondant ? »
• « Rendre mon app zone-redondante » (App Service et Functions uniquement)
• « Rendre mon plan App Service zone-redondant »
• « Configurer le basculement multi-région pour mon app » (App Service et Functions uniquement)
• « Vérifier ma posture de fiabilité »
• « Trouver les points de défaillance uniques » (App Service et Functions uniquement)
• « Activer la haute disponibilité pour mon app » (App Service et Functions uniquement)
• « Vérifier la préparation à la reprise d'activité »
• « Améliorer la résilience de mon app » (App Service et Functions uniquement)

Note d'étendue : Cette compétence couvre actuellement Azure Functions et Azure App Service uniquement. Si l'utilisateur pose des questions sur la fiabilité d'Azure Container Apps, reconnaître que le support est prévu mais pas encore disponible, et procéder uniquement avec les parties qui s'appliquent aux ressources App Service et Functions dans l'étendue.

Prérequis

• Authentification : l'utilisateur est connecté à Azure via az login
• Permissions : accès Lecteur sur l'abonnement/groupe de ressources cible (pour l'évaluation)
• Permissions : accès Contributeur (pour les changements de configuration)
• Extension Azure Resource Graph : az extension add --name resource-graph

Outils MCP

Méthode de requête principale : Azure Resource Graph via az graph query (nécessite az extension add --name resource-graph).

Flux de Travail d'Évaluation

Phase 1 : Découvrir les Ressources

1. Identifier l'étendue — Demander à l'utilisateur le groupe de ressources, l'abonnement ou le nom de l'app
2. Interroger Azure Resource Graph pour découvrir toutes les ressources dans l'étendue
3. Classer les ressources par type de service (Functions, Stockage, etc.). Si un calcul non-Functions (sites App Service qui ne sont pas des Function Apps, Container Apps) est trouvé, le noter mais ne pas approfondir — ces services sont prévus pour une version future de cette compétence.

Important : Toujours limiter les requêtes au groupe de ressources ou à l'abonnement spécifié par l'utilisateur. Ajouter ces filtres à chaque requête Resource Graph :

• Groupe de ressources : | where resourceGroup =~ '<rg-name>'
• Abonnement : utiliser le drapeau --subscriptions <sub-id> sur az graph query
• Nom de l'app : | where name =~ '<app-name>'

Phase 2 : Évaluer la Fiabilité

Évaluation en deux étapes : découverte au niveau plateforme d'abord, puis immersion par service.

Étape 1 — Découverte plateforme (trouver ce qui existe). Utiliser ceux-ci pour énumérer les ressources dans l'étendue et détecter les lacunes de fiabilité transversales :

Étape 2 — Immersion par service. Pour chaque ressource de calcul découverte à l'étape 1, charger la référence de service correspondante. La référence de service est la source unique de vérité pour les règles de plan/SKU de ce service, les requêtes d'évaluation, les commandes CLI, les correctifs IaC (Bicep + Terraform + AVM) et les conseils de rapport.

Cette version de compétence n'expédie que les références Azure Functions et App Service par service. Les autres services de calcul sont listés explicitement ci-dessous afin que la logique de dispatch soit sans ambiguïté : si une ressource correspond à une ligne non supportée, ne pas tenter de charger une référence, fabriquer des commandes CLI ou générer des correctifs IaC pour celle-ci.

Gestion des services non supportés : Si une ressource correspond à une ligne non supportée ci-dessus, la surface dans le résumé de découverte, la marquer comme ⚪ not assessed (planned) dans le tableau Phase 3, et ignorer les étapes de remédiation par service pour celle-ci. Ne pas tenter de fabriquer des commandes CLI ou des correctifs IaC pour ces services.

Phase 3 : Générer la Liste de Contrôle de Fiabilité

Présenter les résultats comme un tableau pivoté par fonctionnalité : une ligne par fonctionnalité de fiabilité (Redondance de zone sur le calcul, Stockage zone-redondant, Sondes de santé, Basculement multi-région), avec un indicateur de statut unique et les ressources spécifiques pertinentes pour cette fonctionnalité. Cela évite le bruit d'une ligne par ressource avec surtout des cellules n/a. Ne pas assigner de scores numériques ou de notes.

🔍 Évaluation de Fiabilité — {scope}
─────────────────────────────────────────────────────────────────────────────────────────────
Fonctionnalité de Fiabilité       Statut      Ressources
─────────────────────────────────────────────────────────────────────────────────────────────
Redondance de zone — calcul      🔴 OFF      • plan-web-ii5trxva2ark4 (P1v3)
                                              • plan-ii5trxva2ark4 (FC1)

Stockage zone-redondant          🔴 GRS      • stii5trxva2ark4 (défaut ; aucun SKU défini en IaC)

Sondes de santé                  🔴 OFF      • func-api-ii5trxva2ark4 — change de code requis (FC1)
                                              • app-web-ii5trxva2ark4 — pas de chemin de contrôle de santé

Basculement multi-région         🔴 OFF      • Région unique (eastus) uniquement — Front Door non configuré
─────────────────────────────────────────────────────────────────────────────────────────────

Voulez-vous que je corrige les éléments 🔴 ? Je commencerai par les quick wins (zone
redondance du plan App + contrôles de santé sur les plans supportés), puis demanderai
avant la migration du stockage et la configuration multi-région. (oui/non)

Règles pour le tableau :

• Quatre lignes de fonctionnalité, dans cet ordre : Redondance de zone — calcul · Stockage zone-redondant · Sondes de santé · Basculement multi-région. Omettre une ligne entièrement uniquement si aucune ressource dans l'étendue ne pourrait jamais s'y appliquer.
• Colonne Statut est un symbole + un mot court, aucun autre caractère :
  • 🟢 ON — la fonctionnalité est entièrement activée sur toutes les ressources pertinentes dans l'étendue
  • 🟡 PARTIAL — certaines ressources l'ont, d'autres non (ou config partielle comme liveness uniquement)
  • 🔴 OFF — la fonctionnalité est manquante sur toutes les ressources pertinentes
  • Pour le stockage, remplacer OFF par le SKU actuel quand pertinent (🔴 LRS, 🔴 GRS, 🟢 ZRS, 🟢 GZRS). Quand aucun SKU n'est défini en IaC, étiqueter comme 🔴 GRS (défaut ARM/AVM) et le noter sur la ligne de ressource.
• Colonne Ressources liste uniquement ce qui est pertinent pour cette fonctionnalité, une puce par ressource :
  • Pour les ressources « à corriger », inclure une brève raison inline ((FC1), (défaut ; aucun SKU défini), liveness uniquement, change de code requis (FC1)).
  • Pour les ressources qui sont déjà ON pour cette fonctionnalité, les mentionner sur la même ligne avec — already ON pour que l'utilisateur voie le crédit pour ce qui est correct.
• Ne pas inclure n/a, — ou des cellules vides. Si une fonctionnalité ne s'applique à aucune ressource dans l'étendue, supprimer la ligne.
• Ne pas inclure de scores numériques, de notes ou de totaux de points.
• Terminer l'évaluation avec une question oui/non unique qui déclenche le flux de remédiation échelonné. Ne pas énumérer ici la liste des corrections par ressource — l'utilisateur la verra après avoir répondu oui (Étape 1 du Flux de Travail de Configuration).

Note UX : Si l'évaluation trouve que l'app a déjà toutes les fonctionnalités de fiabilité essentielles (redondance de zone, stockage ZRS/GZRS, sondes de santé), ignorer la question de correction et aller directement à l'Étape 3 du Flux de Travail de Configuration Étape 3 (suivi multi-région). NE PAS commencer aucun travail multi-région sans consentement explicite.

Flux de Travail de Configuration

Quand l'utilisateur souhaite corriger les résultats de l'évaluation :

⛔ TOUJOURS confirmer avec l'utilisateur avant d'exécuter les changements. Montrer ce qui va changer, les implications de coût et les actions destructives (par exemple, récréation d'environnement).

Étape 1 : Présenter le Plan de Correction + Choisir le Chemin

Après l'évaluation, si l'utilisateur dit « corriger », « améliorer ma fiabilité », « activer la redondance de zone » :

1. Lister chaque résultat corrigeable avec l'action spécifique
2. Signaler les implications de coût ou les changements de rupture
3. Demander à l'utilisateur quel chemin il souhaite :

Je vais commencer par les quick wins (pas de temps d'arrêt, rapide) :

1. ✏️  Activer la redondance de zone sur plan-ii5trxva2ark4 (Flex Consumption — pas de changement de coût)
2. ✏️  Définir le chemin de contrôle de santé à /api/health sur func-api-ii5trxva2ark4

Ensuite, séparément, je demanderai si vous souhaitez mettre à niveau le stockage :

3. 🕒  Mettre à niveau stii5trxva2ark4 de LRS → ZRS (petite augmentation de coût, la migration prend des heures)
   — Requis pour la redondance de zone complète, mais je vais confirmer avant de commencer.

Comment souhaitez-vous appliquer ces changements ?

  A) Corriger maintenant — Exécuter les commandes az CLI sur vos ressources en direct (immédiat, une seule fois)
  B) Corriger mon IaC — Mettre à jour vos fichiers Bicep/Terraform pour que les changements persistent entre les déploiements

(Si vous utilisez azd ou Terraform, l'option B est recommandée pour que `azd up` ne remplace pas les changements.)

Chemin A : Corriger Maintenant (CLI)

Exécuter les corrections contre les ressources en direct en utilisant les commandes CLI az. Quick wins d'abord, puis demander avant la migration de stockage lente.

Les commandes CLI exactes par service vivent dans les références par service — choisir celle(s) correspondant aux ressources découvertes à la Phase 2 :

Ordre d'exécution — toujours les quick wins en premier :

1. Redondance de zone sur le calcul (rapide, mise à jour de propriété en place sur le plan de l'App).

2. Sondes de santé (Premium / Dedicated uniquement — en place ; pour FC1 / Consumption, suivre la porte de consentement dans configure-health-probes.md).

3. Vérifier que les changements de calcul ont réussi avant de faire autre chose.

4. ⛔ ARRÊT — Demander à propos de la mise à niveau du stockage. Le calcul est maintenant zone-redondant, mais le stockage peut encore être LRS ou GRS. Demander explicitement à l'utilisateur :

   ✅ Le calcul est maintenant zone-redondant.
   
   Pour être **entièrement zone-redondant**, votre compte de stockage doit également être mis à niveau :
     • stii5trxva2ark4 : actuellement `Standard_LRS` → nécessite `Standard_ZRS`
   
   ⚠️  Ceci est une conversion de redondance de stockage en direct :
      • Prend des heures à jours selon le volume de données
      • Petite augmentation de coût continu (~0,01 $/Go/mois supplémentaire)
      • Supporté uniquement pour les comptes general-purpose v2 Standard
   
   Voulez-vous que je commence la migration du stockage maintenant ? (oui / non / plus tard)

   • oui → exécuter az storage account update --sku Standard_ZRS (ou migration start si nécessaire) ; interroger az storage account show --query sku.name jusqu'à ce qu'il rapporte Standard_ZRS.
   • non / plus tard → laisser le stockage tel quel ; noter dans la re-évaluation que le stockage ZR reste une lacune.

5. Multi-région — ne PAS exécuter automatiquement. Géré dans l'Étape 3 ci-dessous comme un suivi explicite après la re-évaluation.

⚠️ Avertissement : Si l'utilisateur utilise azd up ou terraform apply plus tard, les changements CLI uniquement peuvent être remplacés par les définitions d'IaC. Recommander également de corriger l'IaC après les corrections CLI.

Chemin B : Corriger l'IaC

Mettre à jour les fichiers Bicep ou Terraform de l'utilisateur pour que les paramètres de fiabilité soient persistants.

Étape 1 : Détecter le type d'IaC

1. Chercher le dossier infra/ à la racine du projet
2. Si non trouvé, vérifier la racine du projet pour les fichiers *.bicep ou *.tf
3. Si toujours non trouvé, demander à l'utilisateur : « Où se trouvent vos fichiers IaC ? »
4. Chercher les fichiers *.bicep → utiliser le correctif Bicep
5. Chercher les fichiers *.tf → utiliser le correctif Terraform
6. Si les deux existent, demander à l'utilisateur lequel corriger
7. Si aucun IaC n'existe, revenir au Chemin A (CLI) et informer l'utilisateur

Étape 2 : Classer chaque correction par niveau de risque

Étape 3 : Appliquer les corrections en deux déploiements (quick wins d'abord)

Le framework de correction d'IaC (détection, guidance module AVM, règle d'ordre de déploiement, correctif SKU de stockage) vit dans :

Les correctifs de calcul par service réels (Function App plan ZR, App Service Plan ZR, etc.) vivent dans les références par service — charger le fichier de service correspondant de la Phase 2 pour les extraits Bicep / Terraform / AVM exacts. Seuls Azure Functions et App Service ont des références par service dans cette version de compétence ; Container Apps est hors scope.

Déploiement 1 — Quick wins uniquement. Corriger les éléments 🟢 Correction sûre (redondance de zone sur le plan App Service/Function App, sondes de santé sur Basic/Standard/Premium / Dedicated). Ne pas inclure le correctif de SKU de stockage dans ce déploiement.

Après correction, la compétence exécute elle-même le déploiement (ne pas arrêter et dire à l'utilisateur de l'exécuter). Détecter l'outil de déploiement et confirmer une fois avant exécution :

📦 Corrections appliquées à votre IaC. Prêt à déployer :
   Outil détecté : azd (trouvé azure.yaml)
   Commande :       azd up

Procéder au déploiement ? (oui / non)

Sur oui, exécuter la commande appropriée, diffuser la sortie en continu vers l'utilisateur, et continuer à l'étape suivante en cas de succès :

• Projet AZD (a azure.yaml) : azd up
• Bicep uniquement : az deployment group create --resource-group <rg> --template-file infra/main.bicep --parameters @infra/main.parameters.json
• Terraform : terraform plan -out tfplan → (afficher le résumé du plan) → terraform apply tfplan

Sur non, arrêter et rapporter les fichiers corrigés ; ne pas procéder à l'étape 4 / Re-Assess.

Si le déploiement échoue, remonter l'erreur et arrêter — ne pas continuer à l'étape de stockage.

⛔ ARRÊT — Demander à propos de la mise à niveau du stockage avant Déploiement 2. Après le succès de Déploiement 1, demander explicitement à l'utilisateur :

✅ Corrections de quick-win déployées. Le calcul est maintenant zone-redondant.

Pour être **entièrement zone-redondant**, votre compte de stockage doit également être mis à niveau :
  • stii5trxva2ark4 : actuellement `Standard_LRS` → nécessite `Standard_ZRS`

⚠️  Ceci est un changement à deux parties :
   1. Migration de stockage en direct (`az storage account migration start`) — prend des heures à jours
   2. Un second déploiement pour mettre à jour le SKU de stockage de votre IaC pour correspondre

Voulez-vous que je commence la migration du stockage maintenant ? (oui / non / plus tard)

• oui → la compétence exécute elle-même la commande de migration, interroge jusqu'à complétion, puis corrige le SKU de stockage dans l'IaC et exécute le Déploiement 2 (maintenant une confirmation no-op). L'utilisateur n'a rien à exécuter manuellement.
• non / plus tard → laisser le correctif de SKU de stockage non appliqué. Noter dans la re-évaluation que le stockage ZR reste une lacune ; suggérer de revisiter plus tard.

Étape 4 : Migration du stockage (uniquement si l'utilisateur a dit oui à l'étape 3)

La compétence exécute ces commandes elle-même — ne pas demander à l'utilisateur de les exécuter. Afficher la progression au fur et à mesure :

🔄 Démarrage de la migration du stockage (peut prendre jusqu'à 72 heures)...

   az storage account migration start --name stii5trxva2ark4 \
     --resource-group rg-example --sku Standard_ZRS --no-wait

   Interrogation : az storage account show --name stii5trxva2ark4 --query sku.name
   ...
   ✅ Migration terminée : sku.name = Standard_ZRS

Pour les migrations très longues, vous pouvez afficher un point de contrôle à l'utilisateur (« c'est toujours en cours, revenez plus tard ») plutôt que de bloquer la conversation entière.

Étape 5 : Déploiement 2 — correctif de SKU de stockage

Après la complétion de la migration, la compétence corrige le SKU de stockage dans l'IaC et exécute la même commande de déploiement qu'à l'étape 3 (par exemple azd up). Ce déploiement est une confirmation no-op que l'IaC correspond à l'état en direct. Confirmer une fois avec l'utilisateur avant exécution, puis l'exécuter directement.

Étape 2 (les deux chemins) : Re-Évaluation

Après l'application des changements (CLI) ou le déploiement (IaC), exécuter automatiquement la re-évaluation et afficher le même tableau pivoté par fonctionnalité que la Phase 3, avec le statut de chaque ligne de fonctionnalité mis à jour pour refléter le nouvel état. Appeler brièvement ce qui a changé depuis la précédente exécution.

🔄 Re-Évaluation de Fiabilité — rg-eventhubs-python-jan13 (eastus)
───────────────────────────────────────────────────────────────────────────────────────
Fonctionnalité de Fiabilité       Statut      Ressources
───────────────────────────────────────────────────────────────────────────────────────
Redondance de zone — calcul      🟢 ON       • plan-ii5trxva2ark4 (FC1)              — maintenant ON
                                             • plan-web-ii5trxva2ark4 (P1v3)         — maintenant ON

Stockage zone-redondant          🟢 ZRS      • stii5trxva2ark4                       — GRS → ZRS

Sondes de santé                  🟡 PARTIAL  • func-api-ii5trxva2ark4                — toujours off (FC1, change de code décliné)
                                             • app-web-ii5trxva2ark4                 — maintenant ON

Basculement multi-région         🔴 OFF      • Région unique (eastus) uniquement
───────────────────────────────────────────────────────────────────────────────────────

Ce qui a changé : redondance de zone du plan Function App et App Service, réplication du stockage et sondes de santé sur App Service.
(Multi-région proposé ensuite — voir étape 3.)

Étape 3 (les deux chemins) : Suivi multi-région — DEMANDER et ATTENDRE

Multi-région est une étape importante en coût/complexité. Ne pas la commencer automatiquement. Après la re-évaluation, uniquement si toutes les fonctionnalités de fiabilité essentielles en région unique sont 🟢 ON (calcul zone-redondant, stockage ZRS/GZRS, sondes de santé), demander explicitement à l'utilisateur et attendre sa réponse avant de faire quoi que ce soit :

🟢 Votre app est maintenant entièrement zone-redondante dans {region}.

L'étape suivante (optionnelle) est le basculement multi-région avec Azure Front Door :
   • Déploie le calcul + stockage dans une deuxième région (région jumelée recommandée)
   • Ajoute Azure Front Door pour l'équilibrage de charge global avec basculement piloté par sonde de santé
   • Protège contre les pannes de région complète
   • Coût supplémentaire estimé : ~2x calcul (actif-passif) ; Front Door ~35 $/mois de base

Voulez-vous que je configure le basculement multi-région maintenant ? (oui / non / plus tard)

• oui → procéder avec references/configure-multi-region.md. Confirmer le choix de région secondaire avec l'utilisateur, puis :
  1. Générer l'IaC multi-région (additions Bicep / Terraform pour la région secondaire + Front Door).
  2. Confirmer une fois avec l'utilisateur : 📦 IaC multi-région généré. Prêt à déployer avec \azd up`. Procéder ? (oui / non)`
  3. Sur oui, la compétence exécute elle-même le déploiement (azd up / az deployment group create / terraform apply) et diffuse la sortie en continu. Ne pas arrêter et dire à l'utilisateur de l'exécuter.
  4. Après le déploiement réussi, exécuter une re-évaluation finale pour que l'utilisateur voie le basculement multi-région passer à 🟢 ON.
• non / plus tard → laisser le déploiement tel quel. Noter que zone-redondant en région unique est un état fiable final ; multi-région peut être revisité anytime.

⛔ Ne pas ignorer l'attente. Ne pas générer l'IaC multi-région, déployer un Front Door ou modifier aucun fichier jusqu'à ce que l'utilisateur ait explicitement dit oui. Si la fiabilité essentielle n'est pas encore tout 🟢, ne pas demander à propos de multi-région — terminer d'abord les lacunes essentielles.

Classification de Priorité

Gestion des Erreurs

Bonnes Pratiques

• Exécuter les évaluations de fiabilité après chaque changement infrastructure significatif
• Tester les scénarios de basculement périodiquement (au moins trimestriellement)

Limites de la Compétence