É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 Functions »
• « Vérifier la fiabilité de mon groupe de ressources » (Functions uniquement)
• « Mon application de fonction est-elle redondante par zone ? »
• « Rendre mon application de fonction redondante par zone »
• « Configurer le basculement multi-région pour mon application Functions »
• « Vérifier ma posture de fiabilité »
• « Trouver les points de défaillance unique » (dans les charges de travail Functions)
• « Activer la haute disponibilité pour mon application Functions »
• « Vérifier la préparation à la récupération d'urgence »
• « Améliorer la résilience de mon application Functions »

Note de portée : Cette compétence couvre actuellement Azure Functions uniquement. Si l'utilisateur pose des questions sur la fiabilité d'Azure App Service ou d'Azure Container Apps, reconnaissez que le support est prévu mais pas encore disponible, et ne procédez que sur les parties qui s'appliquent aux ressources Functions dans la portée.

Prérequis

• Authentification : l'utilisateur est connecté à Azure via az login
• Permissions : accès en Lecture sur l'abonnement/groupe de ressources cible (pour l'évaluation)
• Permissions : accès Contributeur (pour les modifications 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 d'évaluation

Phase 1 : Découvrir les ressources

1. Identifier la portée — Demander à l'utilisateur le groupe de ressources, l'abonnement ou le nom de l'application
2. Interroger Azure Resource Graph pour découvrir toutes les ressources dans la portée
3. Classer les ressources par type de service (Functions, Storage, etc.). Si des ressources de calcul non-Functions sont trouvées (sites App Service qui ne sont pas des Function Apps, Container Apps), les 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'application : | where name =~ '<app-name>'

Phase 2 : Évaluer la fiabilité

Évaluation en deux étapes : découverte au niveau de la plateforme d'abord, puis approche approfondie par service.

Étape 1 — Découverte au niveau de la plateforme (trouver ce qui existe). Utiliser celles-ci pour énumérer les ressources dans la portée et détecter les lacunes de fiabilité transversales :

Étape 2 — Approche approfondie 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, les requêtes d'évaluation, les commandes CLI, les correctifs IaC (Bicep + Terraform + AVM) et les conseils de rapport du service.

Cette version de la compétence n'inclut que la référence per-service pour Azure Functions. Les autres services de calcul sont listés ci-dessous explicitement pour 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, inventer des commandes CLI ou générer des correctifs IaC pour elle.

Gestion des services non supportés : Si une ressource correspond à une ligne non supportée ci-dessus, la surfacer dans le résumé de découverte, la marquer comme ⚪ non évaluée (planifiée) dans le tableau de la Phase 3, et ignorer les étapes de correction per-service pour elle. Ne pas tenter d'inventer des commandes CLI ou des correctifs IaC pour ces services.

Phase 3 : Générer une liste de vérification de fiabilité

Présenter les résultats sous forme de tableau centré sur les fonctionnalités : une ligne par fonctionnalité de fiabilité (Redondance de zone sur le calcul, Stockage redondant par zone, Sondes de santé, Basculement multi-région), avec un seul indicateur d'état 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 attribuer de scores numériques ou de notes.

🔍 Évaluation de fiabilité — {portée}
─────────────────────────────────────────────────────────────────────────────────────────────
Fonctionnalité de fiabilité           État        Ressources
─────────────────────────────────────────────────────────────────────────────────────────────
Redondance de zone — calcul           🔴 OFF      • plan-ii5trxva2ark4 (FC1)

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

Sondes de santé                       🔴 OFF      • func-api-ii5trxva2ark4 — nécessite changement de code (FC1)

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

Voulez-vous que je corrige les éléments 🔴 ? Je vais d'abord faire les gains rapides (redondance
de zone du plan Function App + vérifications de santé sur les plans supportés), puis demander avant
la migration de stockage et la configuration multi-région. (oui/non)

Règles pour le tableau :

• Quatre lignes de fonctionnalités, dans cet ordre : Redondance de zone — calcul · Stockage redondant par zone · Sondes de santé · Basculement multi-région. Omettre une ligne entièrement seulement si aucune ressource dans la portée ne pourrait jamais s'y appliquer.
• Colonne État est un symbole + un mot court, pas d'autres caractères :
  • 🟢 ON — la fonctionnalité est entièrement activée sur toutes les ressources pertinentes dans la portée
  • 🟡 PARTIAL — certaines ressources l'ont, d'autres non (ou configuration partielle comme liveness uniquement)
  • 🔴 OFF — la fonctionnalité manque 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, marquer comme 🔴 GRS (défaut ARM/AVM) et le noter sur la ligne de ressource.
• Colonne Ressources liste seulement ce qui est pertinent pour cette fonctionnalité, une puce par ressource :
  • Pour les ressources « à corriger », inclure une courte raison inline ((FC1), (par défaut ; aucun SKU défini), liveness uniquement, nécessite changement de code (FC1)).
  • Pour les ressources qui sont déjà ON pour cette fonctionnalité, les mentionner sur la même ligne avec — déjà ON pour que l'utilisateur voit 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 la portée, supprimer la ligne.
• Ne pas inclure de scores numériques, de notes ou de totaux de points.
• Terminer l'évaluation avec une unique question oui/non qui démarre le flux de correction par étapes. Ne pas énumérer la liste des corrections per-ressource ici — l'utilisateur la verra après avoir dit oui (Étape 1 du flux de configuration).

Note UX : Si l'évaluation trouve que l'application possède déjà toutes les fonctionnalités de fiabilité fondamentales (redondance de zone, stockage ZRS/GZRS, sondes de santé), ignorer la question de correction et passer directement à Étape 3 du flux de configuration (Suivi multi-région). Ne pas commencer aucun travail multi-région sans consentement explicite.

Flux de configuration

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

⛔ TOUJOURS confirmer avec l'utilisateur avant d'exécuter les modifications. Montrer ce qui va changer, les implications de coût et les actions destructrices (p. ex. recré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 corrigible 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 gains rapides (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 vérification de santé sur /api/health pour func-api-ii5trxva2ark4

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

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

Comment voulez-vous appliquer ces modifications ?

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

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

Chemin A : Corriger maintenant (CLI)

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

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

Ordre d'exécution — toujours les gains rapides en premier :

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

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 modifications 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 redondant par zone, mais le stockage peut toujours être LRS ou GRS. Demander à l'utilisateur explicitement :

   ✅ Le calcul est maintenant redondant par zone.
   
   Pour être **complètement redondant par zone**, votre compte de stockage doit également être mis à niveau :
     • stii5trxva2ark4 : actuellement `Standard_LRS` → nécessite `Standard_ZRS`
   
   ⚠️  C'est une conversion de redondance de stockage en direct :
      • Prend des heures à des jours selon le volume de données
      • Petite augmentation de coût continu (~0,01 $/Go/mois de plus)
      • Seulement supporté pour les comptes Standard general-purpose v2
   
   Voulez-vous que je commence la migration de 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 auto-exécuter. Géré en Étape 3 ci-dessous comme suivi explicite après re-évaluation.

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

Chemin B : Corriger 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 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ù sont situés vos fichiers IaC ? »
4. Vérifier les fichiers *.bicep → utiliser la correction Bicep
5. Vérifier les fichiers *.tf → utiliser la correction 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 (gains rapides d'abord)

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

Les corrections de calcul per-service réelles (Function App plan ZR, etc.) vivent dans les références per-service — charger le fichier de service correspondant depuis la Phase 2 pour les extraits Bicep / Terraform / AVM exacts. Seul Azure Functions a une référence per-service dans cette version de la compétence ; le calcul non-Functions (App Service / Container Apps) est hors de portée.

Déploiement 1 — Gains rapides uniquement. Corriger les éléments 🟢 Sûrs (redondance de zone sur le plan Function App, sondes de santé sur Premium / Dedicated). Ne pas inclure la correction SKU de stockage dans ce déploiement.

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

Au oui, exécuter la commande appropriée, diffuser la sortie à 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 → (montrer le résumé du plan) → terraform apply tfplan

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

Si le déploiement échoue, surfacer 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 du Déploiement 1, demander à l'utilisateur explicitement :

✅ Corrections de gain rapide déployées. Le calcul est maintenant redondant par zone.

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

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

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

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

Étape 4 : Migration de stockage (seulement 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. Montrer la progression au fur et à mesure :

🔄 Démarrage de la migration de stockage (cela 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 complète : sku.name = Standard_ZRS

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

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

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

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

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

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

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

Sondes de santé                       🔴 OFF      • func-api-ii5trxva2ark4                — toujours off (FC1, changement de code décliné)

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

Ce qui a changé : redondance de zone du plan Function App et réplication de stockage.
(Multi-région offert ensuite — voir Étape 3.)

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

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

🟢 Votre application est maintenant complètement redondante par zone dans {région}.

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 appairé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. Au oui, la compétence exécute le déploiement elle-même (azd up / az deployment group create / terraform apply) et diffuse la sortie. 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 voit le basculement multi-région passer à 🟢 ON.
• non / plus tard → laisser le déploiement tel quel. Noter que la redondance de zone région unique est un état fiable final ; multi-région peut être revisité n'importe quand.

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

Classification des priorités

Gestion des erreurs

Meilleures pratiques

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

Limites de la compétence