azure-well-architected-review

Par github · awesome-copilot

Effectuer une revue Azure Well-Architected Framework du code IaC et de l'architecture de la charge de travail actuelle, en générant des findings et des issues GitHub pour les améliorations.

npx skills add https://github.com/github/awesome-copilot --skill azure-well-architected-review

Révision Azure Well-Architected

Ce workflow exécute une révision structurée du framework Azure Well-Architected (WAF) sur les fichiers IaC de votre charge de travail et l'infrastructure déployée. Il identifie les risques sur les 5 piliers du WAF et crée des problèmes GitHub pour suivre la correction.

Prérequis

  • Azure CLI (az) configurée et authentifiée
  • Fichiers IaC présents dans le référentiel (Bicep, Terraform ou modèles ARM)
  • Serveur MCP GitHub configuré et authentifié

Étapes du workflow

Étape 1 : Charger la référence Well-Architected Framework

Récupérer les meilleures pratiques actuelles Azure WAF :

  • https://learn.microsoft.com/en-us/azure/well-architected/
  • Guides de service pour les services Azure utilisés (https://learn.microsoft.com/en-us/azure/well-architected/service-guides/)
  • Conseils spécifiques à la charge de travail pertinents pour le type de charge de travail (SaaS, critique, IA, etc.)

Si le serveur MCP microsoft.docs.mcp est disponible, l'utiliser pour interroger les listes de contrôle de piliers les plus récentes et les recommandations spécifiques au service.

Étape 2 : Découvrir IaC et Architecture

Établir le périmètre de la révision, puis inventorier le code et l'environnement actif :

  1. Confirmer le périmètre Azure : Demander à l'utilisateur quels abonnement(s)/groupe(s) de ressources sont en périmètre, ou les déduire des paramètres IaC et confirmer.
  2. Analyser le référentiel pour les fichiers IaC :
    • Bicep : **/*.bicep, bicepconfig.json
    • Terraform : **/*.tf (fournisseurs azurerm/azapi)
    • Modèles ARM : **/azuredeploy*.json, **/*.template.json, fichiers avec $schema contenant deploymentTemplate
  3. Inventorier les ressources actives (toujours, même quand IaC existe) : az resource list --resource-group <rg> --output json (ou à l'échelle de l'abonnement), plus appels ciblés az <service> show pour les détails de configuration que les vérifications de pilier nécessitent.
  4. Comparer IaC avec l'inventaire actif : Signaler la dérive — ressources présentes dans Azure mais absentes de IaC (créées par portail), ressources définies dans IaC mais non déployées, et incompatibilités de configuration. Enregistrer les résultats de dérive pour l'étape 3 (ils correspondent généralement au pilier Excellence Opérationnelle).

Identifier les services Azure clés en usage (calcul, données, réseau, sécurité, observabilité) et générer un diagramme d'architecture Mermaid.

Étape 3 : Révision par Pilier

Pilier 1 : Fiabilité

  • [ ] Zones de disponibilité activées pour les services zonaux (VMs, VMSS, pools de nœuds AKS, App Service, SQL, Storage ZRS)
  • [ ] Les SKU de production supportent le SLA requis (pas de niveaux Basic/Free sur les chemins critiques)
  • [ ] Sauvegarde Azure SQL / Cosmos DB et restauration jusqu'à un point dans le temps configurées avec rétention appropriée
  • [ ] Géo-redondance configurée où RPO l'exige (stockage GRS/RA-GRS, groupes de basculement SQL, Cosmos DB multi-région)
  • [ ] Règles d'autoscaling configurées pour plans App Service, VMSS, AKS (pas d'instance unique fixe pour la production)
  • [ ] Sondes d'intégrité configurées sur backends Load Balancer / Application Gateway / Front Door
  • [ ] Dead-lettering activé pour files d'attente/abonnements Service Bus et abonnements Event Grid
  • [ ] Politiques de relance avec backoff exponentiel implémentées pour la gestion des défaillances transitoires
  • [ ] Plan de récupération d'urgence défini (RTO/RPO documentés, basculement testé)

Pilier 2 : Sécurité

  • [ ] Identités gérées utilisées au lieu de principaux de service avec secrets ou chaînes de connexion
  • [ ] Aucune credential, clé ou chaîne de connexion codée en dur dans IaC ou code
  • [ ] Secrets stockés dans Azure Key Vault avec autorisation RBAC (pas politiques d'accès)
  • [ ] Comptes de stockage refusent l'accès aux blob publics et interdisent l'accès à clé partagée si possible
  • [ ] Points de terminaison privés (ou au minimum points de terminaison de service + règles pare-feu) pour services de données PaaS
  • [ ] NSGs limitent le trafic entrant aux ports/CIDR minimum requis (pas de règles * → * autoriser)
  • [ ] TLS 1.2+ appliqué sur tous les points de terminaison (minimumTlsVersion, httpsOnly)
  • [ ] Azure RBAC suit le principe du moindre privilège (pas Owner/Contributor à l'échelle de l'abonnement pour les identités de charge de travail)
  • [ ] Microsoft Defender for Cloud activé sur les types de ressources pertinents (az security pricing list)
  • [ ] Azure WAF (Application Gateway ou Front Door) configuré pour les points de terminaison web publics
  • [ ] Paramètres de diagnostic envoient les journaux de sécurité à Log Analytics / Microsoft Sentinel

Pilier 3 : Optimisation des Coûts

  • [ ] Réservations ou plans d'économies évalués pour le calcul en régime permanent (VMs, App Service, SQL)
  • [ ] Politiques de gestion du cycle de vie de stockage déplacent les blob vers niveaux chaud/archive
  • [ ] SKUs dimensionnés correctement selon l'utilisation réelle (pas de VMs/plans App Service surdimensionnés)
  • [ ] Environnements dev/test utilisent arrêt automatique et tarification Dev/Test si éligibles
  • [ ] Budgets Azure et alertes de coût configurés (az consumption budget list)
  • [ ] Disques gérés détachés et IPs publiques orphelines identifiés et supprimés
  • [ ] Niveaux Consommation/serverless utilisés pour charges de travail irrégulières ou faible volume (Functions, Container Apps, SQL serverless)
  • [ ] Paramètres de rétention et cap-données Log Analytics réglés pour éviter surutilisation d'ingestion

Pilier 4 : Excellence Opérationnelle

  • [ ] Toute l'infrastructure définie en IaC (pas de modifications manuelles par portail ; assignations de refus ou politique si possible)
  • [ ] Stratégie de marquage cohérente appliquée sur toutes les ressources (propriétaire, environnement, centre de coûts)
  • [ ] Alertes Azure Monitor définies pour les métriques clés et l'intégrité des services
  • [ ] Pipeline de déploiement automatisé présent (GitHub Actions / Azure Pipelines, pas de déploiements manuels)
  • [ ] Journal d'activité Azure et paramètres de diagnostic des ressources acheminés vers Log Analytics
  • [ ] Application Insights (ou équivalent OpenTelemetry) instrumenté pour charges de travail d'application
  • [ ] Assignations Azure Policy appliquent les normes organisationnelles (emplacements autorisés, SKUs, marquages)
  • [ ] Runbooks ou documentation opérationnelle présents

Pilier 5 : Efficacité des Performances

  • [ ] SKUs de calcul correctement dimensionnés validés par rapport aux exigences de charge
  • [ ] Mise en cache implémentée si bénéfique (Azure Cache for Redis, cache CDN/Front Door)
  • [ ] Azure Front Door ou CDN utilisé pour la livraison de contenu statique global
  • [ ] Autoscale basé sur les métriques de charge plutôt que comptages d'instances fixes
  • [ ] Niveau de performance de base de données approprié (DTU vs vCore, pools élastiques, Cosmos DB RU autoscale)
  • [ ] Stockage Premium/zone-redondant utilisé pour charges de travail disque sensibles à la latence
  • [ ] Regroupement de connexions et modèles asynchrones utilisés pour les clients de base de données et HTTP

Étape 4 : Classification des Risques

Pour chaque résultat, classifier :

  • Risque Élevé : Vulnérabilité de sécurité, point unique de défaillance, aucune sauvegarde/récupération
  • Risque Moyen : Fiabilité sous-optimale, inefficacité des coûts, problème de performance
  • Risque Faible : Écart de meilleure pratique, opportunité d'optimisation mineure

Étape 5 : Confirmation Utilisateur

🏗️ Résumé de révision Azure Well-Architected

📊 Résultats de révision :
• Fichiers IaC analysés : X
• Services Azure identifiés : Y
• Résultats totaux : Z
  • Risque élevé : A (action immédiate requise)
  • Risque moyen : B (devraient être adressés bientôt)
  • Risque faible : C (nice to have)

🔴 Résultats principaux à risque élevé :
1. [Pilier] : [Résultat] — [Pourquoi c'est important]
2. [Pilier] : [Résultat] — [Pourquoi c'est important]

💡 Cela créera Z problèmes GitHub individuels + 1 problème EPIC.

❓ Procéder à la création de problèmes GitHub ? (o/n)

Porte : Procéder aux étapes 6–7 seulement si l'utilisateur donne une réponse affirmative explicite (ex. "o", "oui"). Sur réponse négative, ambiguë ou manquante, NE PAS créer de problèmes GitHub — afficher tous les résultats en markdown formaté à la console et arrêter.

Étape 6 : Créer les Problèmes de Résultats Individuels

Labéliser avec "well-architected" et le nom du pilier (ex. "security", "reliability").

Titre : [WAF-<PILIER>] [Résultat Bref] — [Niveau de Risque]

Corps :

## 🏗️ Résultat Well-Architected : [Titre Bref]

**Pilier** : [Nom] | **Niveau de Risque** : [Élevé/Moyen/Faible] | **Effort** : [Faible/Moyen/Élevé]

### 📋 Description
[Explication claire du résultat et pourquoi c'est important]

### 🔧 Correction

**Correctif IaC** (préféré) :
```bicep
// Exemple Bicep
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_ZRS' }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}
```

**Secours Azure CLI** :
```bash
az storage account update --name <name> --resource-group <rg> \
  --min-tls-version TLS1_2 --allow-blob-public-access false --https-only true
```

### 📚 Référence Azure
- [Lien Meilleure Pratique WAF]
- [Lien Documentation Microsoft Learn]

### ✅ Validation
- [ ] Modification implémentée en IaC et déployée
- [ ] Conformité Azure Policy passe (si applicable)
- [ ] Recommandation Microsoft Defender for Cloud résolue (si applicable)

**Recommandation Well-Architected** : [Élément de liste de contrôle WAF auquel cela correspond]

Étape 7 : Créer le Problème de Suivi EPIC

Labéliser avec "well-architected" et "epic".

Titre : [EPIC] Révision Azure Well-Architected — X résultats sur 5 piliers

Corps : Résumé exécutif avec tableau de ventilation par pilier (comptages de résultats par pilier et niveau de risque), diagramme d'architecture Mermaid, liste de contrôle priorisée liant tous les problèmes individuels (Élevé → Moyen → Faible), et critères de succès :

  • Tous les résultats à risque élevé résolus
  • Les résultats moyen ont des plans d'atténuation acceptés
  • Pas de régression dans les alertes Azure Monitor existantes ou conformité Azure Policy

Gestion des Erreurs

  • Aucun fichier IaC trouvé : Limiter la révision à la découverte de ressources actives via Azure CLI (az resource list) et noter le gap
  • Permissions Azure insuffisantes : Lister les rôles en lecture seule requis pour la révision (Reader, Security Reader)
  • Échec création GitHub : Afficher tous les résultats en markdown formaté à la console

Critères de Succès

  • ✅ Les 5 piliers WAF révisés par rapport à IaC et infrastructure actifs
  • ✅ Tous les résultats classifiés par niveau de risque et pilier
  • ✅ Étapes de correction exploitables avec exemples IaC pour chaque résultat
  • ✅ Problèmes GitHub créés pour suivi d'équipe
  • ✅ Diagramme d'architecture généré pour contexte EPIC
  • ✅ Références documentation Microsoft Learn incluses

Skills similaires

agent-observability-auto-experiment
datadog-labs / agent-skills

Automatiser une boucle d'amélioration itérative locale de code via évaluations et commits git.

147
llm-obs-eval-bootstrap
datadog-labs / agent-skills

Générer une suite d'évaluateurs prêts à l'emploi à partir de traces LLM en production.

147
agent-observability-eval-bootstrap
datadog-labs / agent-skills

Analyser des traces LLM de production pour générer et publier une suite d'évaluateurs Datadog.

147
azure-reliability
microsoft / azure-skills

Évaluer et configurer la fiabilité des Azure Functions avec redondance et failover multi-région.

1 328
azure-reliability
microsoft / azure-skills

Évaluer et configurer la fiabilité des ressources Azure Functions et App Service.

1 328