Comment les cinq rôles ont été choisis
SkillSignal a comparé les skills Microsoft Azure déjà indexés et retenu des rôles répondant à des questions différentes : accès, préparation, validation, preuves d’incident et capacité machine. La sélection se fonde sur périmètres sources, permissions, adéquation et possibilité de revue, pas sur une popularité transformée en approbation de sécurité.
C’est un point de départ éditorial, pas un test comparatif ni une recommandation d’installer cinq paquets ensemble. Gardez le minimum avec responsable, première tâche réversible et acceptation. Si le projet n’utilise pas le parcours Azure correspondant, changez de rôle ou ignorez-le.
- Le skill porte une décision ou preuve Azure claire.
- L’accès nécessaire est proportionné au rôle.
- Source, limites et dépendances aux données actuelles sont visibles avant installation.
- Un humain peut vérifier plan, constat ou attribution obtenus.
1. azure-rbac : commencer par la portée d’accès
azure-rbac est l’étape initiale la plus ciblée pour vérifier l’accès d’un utilisateur, groupe, principal de service ou identité managée. Il aide à examiner définitions et attributions de rôles, distinguer plan de gestion et plan de données, et choisir la plus petite portée pratique avant modification.
Traitez chaque attribution comme un changement d’accès contrôlé. Rôle large, portée héritée, mauvais principal ou retrait prématuré peuvent provoquer escalade de privilèges ou panne. Identifiez les identifiants immuables, examinez l’accès effectif et vérifiez la propagation après un changement approuvé.
2. azure-prepare : planifier avant de générer l’infrastructure
azure-prepare porte la planification des applications Azure orientées azd. Il étudie application et dépendances, consigne les décisions dans .azure/deployment-plan.md, puis prépare azure.yaml, Bicep ou Terraform et ressources de conteneurs après approbation.
Ce n’est pas un raccourci général de déploiement. Le plan doit préciser abonnement, région, identité, réseau, services et recette. Gardez le diff généré examinable et transmettez-le à Azure Validate avant toute écriture de production.
3. azure-validate : préparer RBAC et l’infrastructure déclarative
azure-validate constitue le contrôle de preuves entre préparation et déploiement. Il examine configuration, azure.yaml, Bicep ou Terraform, identité managée, prérequis RBAC et résultats what-if, puis consigne les vrais contrôles étayant un plan Validated.
Un précontrôle réussi réduit les risques connus sans prouver le comportement de l’application déployée. Ne marquez pas manuellement un plan Validated et ne masquez pas un échec ; conservez commandes et résultats pour que le déploiement suivant vérifie la revue réelle.
4. azure-diagnostics : des preuves de production lors d’un incident
azure-diagnostics structure l’enquête depuis les symptômes vers santé des ressources, journaux, métriques, changements récents et prochaines étapes propres au service. Il aide l’opérateur à réduire l’incertitude avant de décider si une correction est justifiée.
Diagnostiquer n’autorise pas à modifier la production. Séparez collecte en lecture seule et écritures, choisissez une période adaptée, expurgez la télémétrie partagée et exigez un plan examiné avant remédiation. Une télémétrie manquante ou une dépendance externe peut laisser la cause non résolue.
5. azure-compute : capacité et coûts des machines virtuelles
azure-compute convient à une VM Azure ou un VM Scale Set quand il faut décider SKU, image, quota, prix, autoscaling, orchestration ou réservations. Il sépare capacité machine et déploiement de plateforme applicative.
Capacité et prix varient selon région et date. Vérifiez quotas actuels, prix, images, exposition réseau et plan exact avant création ou redimensionnement. Pour application web, conteneurs ou serverless, revenez plutôt à la préparation applicative appropriée.
Un ordre d’opérations mieux maîtrisé
Pour une nouvelle charge Azure, clarifiez les accès avec azure-rbac, enregistrez le design approuvé avec azure-prepare et faites consigner les preuves par azure-validate. Azure Deploy reste volontairement une action de production séparée, pas une installation par défaut. En cas d’échec ultérieur, collectez les preuves avec azure-diagnostics avant correction ; pour la capacité machine, utilisez azure-compute avec prix et quotas actuels.
L’ensemble utile est la plus petite séquence de livrables examinables. Cinq entrées ne sont pas une obligation : une revue d’accès peut nécessiter azure-rbac seul, tandis qu’une migration de VM préparée peut demander une autre combinaison et une approbation humaine distincte.
- Accès : principal, rôle et portée explicites.
- Plan : abonnement, région, identité, services et recette consignés.
- Préparation : contrôles en échec résolus ou arrêt explicite, pas dissimulation.
- Opérations : preuves en lecture seule séparées des écritures de production.
- Capacité : quota, prix, image et exposition actuels vérifiés pour la région cible.