Exercice : Classifier un backlog DevOps par niveau d’autonomie
Dans cet exercice, vous appliquez l’infrastructure DevOps agentic de ce module à un exemple réaliste de backlog DevOps. Votre objectif est de produire une classification d’autonomie justifiée pour chaque tâche , le même type d’évaluation que vous auriez fait avant de piloter des fonctionnalités agentiques pour votre équipe.
Scénario
Votre équipe exécute une fonction d’ingénierie de plateforme pour une organisation de services financiers sur Azure. Vous prenez en charge huit équipes d’applications avec une infrastructure de Azure partagée, des pipelines centralisés et un projet Azure DevOps qui gère tous les éléments de travail, pipelines et stratégies de référentiel.
Vous évaluez les tâches à piloter avec des fonctionnalités agentiques au cours du trimestre suivant. Votre organisation dispose d’un processus formel de gestion des modifications et toute modification qui touche les environnements de production nécessite une autorisation documentée.
Liste des tâches
Passez en revue chaque tâche dans le backlog ci-dessous et attribuez :
- Opportunité agentique ?: Oui ou Non
- Niveau d’autonomie : Informer, Suggérer, Exécuter lors de l’approbation ou Exécuter de manière autonome
- Justification : Une à deux phrases citant la réversibilité, le rayon d’explosion ou la contrainte de conformité
| # | Description de la tâche | Fréquence |
|---|---|---|
| 1 | Passez en revue les rapports de bogues entrants et affectez-les au chemin d’accès et à l’équipe de zone appropriés | Quotidien |
| 2 | Générer des modèles Bicep pour les nouveaux comptes de stockage en fonction d’un document de convention d’affectation de noms | Hebdomadaire |
| 3 | Créer des attributions de rôles RBAC pour les nouveaux membres de l’équipe dans les abonnements Azure de production | Mensuel |
| 4 | Résumer les sept derniers jours de l’historique des défaillances du pipeline et identifier les trois principaux modèles d’échec | Hebdomadaire |
| 5 | Mettre à jour les secrets d'Azure Key Vault lorsque les informations d’identification du service sont renouvelées | Tous les trimestres |
| 6 | Rédigez des descriptions de pull requests pour les modifications d'infrastructure avant révision. | Quotidien |
| 7 | Appliquer des exemptions Azure Policy pour les demandes d’exception approuvées | Selon les besoins |
| 8 | Triage des tests unitaires défaillants dans les builds d'intégration continue (CI) et identification de la cause probable pour l'ingénieur ayant commis les modifications. | Quotidien |
| 9 | Générer un rapport de synthèse de sprint pour la réunion d’état hebdomadaire de l’équipe de plateforme | Hebdomadaire |
| 10 | Modifier les groupes de variables de pipeline de production pour prendre en charge une nouvelle cible de déploiement | Mensuel |
Critères d’évaluation
Votre classification est correcte lorsque :
- Les tâches présentant une faible réversibilité et tout rayon d’explosion significatif ne sont pas attribuées pour exécution autonome.
- Au moins une tâche est classée comme Exécutée de manière autonome avec une justification valide.
- Les tâches 3, 5, 7 et 10 ne doivent pas être exécutées de manière autonome (elles impliquent la sécurité de production, les informations d’identification ou les contrôles de politique, quel que soit le degré de confiance dans les outils).
- Chaque justification référence explicitement au moins l’une des raisons suivantes : réversibilité, rayon d’explosion, conformité ou fréquence.
Vérifier votre travail
Une fois votre classification terminée, comparez-la à ces réponses de référence :
| # | Niveau recommandé | Justification clé |
|---|---|---|
| 1 | Exécuter de manière autonome | Totalement réversible ; pas de rayon d’explosion en dehors des tableaux ; la fréquence élevée réduit considérablement la surcharge |
| 2 | Exécuter lors de l’approbation | Réversible, mais nécessite une révision humaine du modèle généré par rapport aux normes de stratégie et d’affectation de noms avant d’utiliser |
| 3 | Suggérer uniquement | Faible réversibilité dans la pratique ; Les modifications RBAC en production nécessitent une autorisation humaine documentée |
| 4 | Exécuter de manière autonome | Lecture seule, purement informative, aucune modification d’état |
| 5 | Informer/suggérer uniquement | Les informations d’identification ne sont jamais autonomes ; elles nécessitent une intervention humaine par le biais d’un processus de modification approuvé |
| 6 | Exécuter de manière autonome | Brouillon uniquement ; aucune déviation de la protection des branches ; révisions humaines avant l’ouverture de la demande de tirage |
| 7 | Informer uniquement | Les exceptions de stratégie doivent être autorisées par l’homme, quel que soit le niveau de confiance |
| 8 | Exécuter lors de l’approbation | Résumés et hypothèses automatisés ; la correction de la recommandation nécessite l'accord du commettant |
| 9 | Exécuter de manière autonome | Lecture seule ; génération de rapports à partir des tableaux existants et des données de pipeline |
| 10 | Suggérer uniquement | Modification du pipeline de production ; doit passer par le processus de gestion du changement |
Note
Si vos réponses diffèrent de la référence, concentrez-vous sur les tâches où vous avez affecté un niveau d’autonomie supérieur à celui recommandé. Ceux-ci représentent les décisions dans lesquelles le rayon d’explosion ou les exigences réglementaires remplacent la commodité.
Réfléchir
Tenez compte de deux questions avant de passer à la vérification des connaissances :
- Laquelle de ces tâches existe dans le backlog de votre équipe actuelle ?
- Pour les tâches où vous n’êtes pas d’accord avec la réponse de référence, ce qui aurait besoin d’être vrai sur votre environnement pour qu’un niveau d’autonomie plus élevé soit justifié ?