Aller au contenu
NextiaNextia Learning
English

Travail final

  • Après le module 5
  • environ 3 h

Ce que vous saurez faire

Utilisez votre pipeline comme une équipe, pour un vrai changement. Vous transformez le signalement d’un utilisateur en exigences et en vérifications. Vous livrez le changement par une demande de tirage (pull request). Vous promouvez une seule image en préproduction, puis en production, après une approbation. Ensuite, vous prouvez que vous pouvez revenir en arrière et corriger le problème. Vous conservez les preuves de chaque étape pour qu’une autre personne puisse vérifier votre travail.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 180 minutes

Ce que vous devez savoir

  • Vous avez terminé les modules 1 à 5. Chaque partie ci-dessous nomme les leçons utilisées.

Ce qu’il vous faut sur votre ordinateur

La solution a été testée avec Python 3.14.6 et les vérifications du projet de référence. Les étapes pour Windows et Linux n’ont pas été testées.

La situation

Section intitulée « La situation »

Sam signale un problème. Le centre d’assistance a reçu le billet de soutien « J’ai perdu mon mot de passe » avec la priorité 1, la plus urgente. Le classificateur keywords-1.1 considère chaque occurrence de « perdu » comme urgente. Dans le module 4, une première tentative retirait « perdu » des mots urgents. La barrière d’évaluation l’a bloquée : « Colis perdu en transit » perdait sa priorité 1.

La personne responsable du centre d’assistance demande ceci :

  1. Un mot de passe perdu a la priorité 2. Un colis perdu garde la priorité 1. Un billet urgent pour une autre raison (« j’ai perdu mon mot de passe et mon accès est maintenant bloqué ») garde la priorité 1.
  2. Aucun autre billet ne reçoit un résultat moins bon qu’avec le classificateur en production.
  3. Aucun risque pour la production avant que le changement passe la préproduction et obtienne une approbation. Il faut aussi un retour rapide en arrière si un problème survient.

Règles pour chaque partie

Section intitulée « Règles pour chaque partie »
  • Créez evidence.md à l’extérieur du dépôt (par exemple ~/projects/c19-evidence.md). Après chaque partie, ajoutez les commandes, les sorties et les liens demandés. Mettez des liens vers vos propres demandes de tirage, exécutions et mises en production.
  • Chaque changement passe par une demande de tirage. Ne sautez aucune vérification, même pour le correctif urgent de la partie 5.
  • Aucun secret dans un fichier, un journal ou une preuve.

Partie 1 : exigences et vérifications

Section intitulée « Partie 1 : exigences et vérifications »

Utilise Définir les vérifications : huit vérifications, huit objectifs, Barrière d’évaluation de l’IA : la barrière : trois questions et Barrière d’évaluation de l’IA : à vous de jouer : rendre la réussite du billet de Sam obligatoire.

  1. Présentez les trois exigences du centre d’assistance dans un tableau : exigence, vérification qui la prouve et lieu d’exécution (demande de tirage, envoi vers main, déploiement).
  2. Vérifiez le point de départ : wc -l evaluation/tickets.jsonl indique 51, comme dans l’instantané end-of-m05. (La ligne E052 du module 4 était une expérience que vous n’avez pas enregistrée dans un commit.) Ajoutez deux billets à réussite obligatoire aux données réservées. E052 : « J’ai perdu mon mot de passe » (connexion, priorité 2). E053 : « Mot de passe perdu, accès bloqué » (connexion, priorité 1).
  3. Exécutez la barrière pour le classificateur en production : python -m evaluation.run --classifier 1.1. Elle doit maintenant échouer. Notez pourquoi c’est le bon résultat.
  4. La production utilise keywords-1.1 depuis le déploiement canari du module 4. Faites-en la référence de base : évaluez la version 1.1 et écrivez ses résultats dans evaluation/baseline.json, en conservant la structure actuelle du fichier. (Parcours simulé : deploy/local/production.env dans Git indique encore CLASSIFIER_VERSION=1.0. Remplacez cette valeur par 1.1, comme lors de la promotion dans Mise en production progressive : le parcours simulé : un canari sur votre ordinateur. Votre production locale utilisera alors aussi la référence de base.)

Preuves pour la partie 1 : le tableau; la sortie de l’étape 3; le nouveau baseline.json, avec une phrase expliquant pourquoi la référence de base devait changer.

Ce que vous devriez voir

keywords-1.1 échoue à la vérification à réussite obligatoire pour le nouveau billet « J’ai perdu mon mot de passe ». Il lui donne la priorité 1. C’est le bogue signalé, maintenant détecté par une vérification. Si la référence de base reste keywords-1.0, l’exactitude d’un nouveau classificateur pourrait passer de 0,914 à environ 0,63. Il réussirait quand même la vérification « aucune régression ». La référence de base doit être le classificateur que les utilisateurs ont aujourd’hui. Avec les deux nouveaux billets, keywords-1.1 a une exactitude de 0,914 sur 35 billets réservés.

Partie 2 : le changement, par une demande de tirage

Section intitulée « Partie 2 : le changement, par une demande de tirage »

Utilise Construire et tester : les mêmes vérifications sur votre ordinateur, Barrière d’évaluation de l’IA : exemple détaillé : keywords-1.1 derrière un indicateur, Barrière d’évaluation de l’IA : la barrière dans la CI et Mise en production progressive : Exercice du module.

  1. Créez une branche, par exemple feature/lost-password.
  2. Ajoutez le classificateur keywords-1.2 dans ticket_api/classifier.py. Il fonctionne comme la version 1.1, mais un mot de passe perdu seul reçoit la priorité 2. Sélectionnez-le avec CLASSIFIER_VERSION=1.2. La valeur par défaut reste 1.0.
  3. Ajoutez des tests pour les trois cas de l’exigence 1.
  4. Faites tester le nouveau candidat par la barrière. Remplacez --classifier 1.1 par --classifier 1.2 dans le flux de travail CI et dans scripts/check.sh.
  5. Passez à la version 1.3.0, exportez de nouveau le contrat et rédigez docs/releases/1.3.0.md.
  6. Exécutez scripts/check.sh. Envoyez ensuite les changements, ouvrez la demande de tirage (feature/lost-password vers main) et attendez les vérifications.

Preuves pour la partie 2 : le lien vers la demande de tirage avec ses vérifications réussies; la sortie de la barrière dans le journal CI; les différences dans classifier.py.

Ce que vous devriez voir

La sortie de la barrière pour keywords-1.2 sur 35 billets réservés : exactitude de 0,914, aucune régression par rapport à keywords-1.1, must-pass failures: 0 (aucun échec à réussite obligatoire), Gate passed. (barrière franchie). Une solution correcte ajoute une sous-classe du classificateur 1.1. Elle réduit la priorité à 2 quand le texte contient « j’ai perdu mon mot de passe » sans autre mot urgent. D’autres solutions sont correctes si les tests et la barrière réussissent.

Partie 3 : une seule image promue

Section intitulée « Partie 3 : une seule image promue »

Utilise Publier les preuves : build-info.json : empreinte, commit et exécution dans un seul fichier, Séparer la configuration : une image, plusieurs environnements, Promouvoir en préproduction : approuver le déploiement en production, Promouvoir en préproduction : une version sans nouvelle construction et Promouvoir en préproduction : le parcours local.

  1. Fusionnez la demande de tirage. Trouvez l’empreinte de la nouvelle image dans le fichier build-info.json de l’exécution CI.
  2. Observez l’exécution Deploy déployer l’image en préproduction et lancer la vérification sommaire.
  3. En préproduction, activez le nouveau classificateur : définissez CLASSIFIER_VERSION=1.2 sur l’application de préproduction. Vérifiez « J’ai perdu mon mot de passe » dans cet environnement.
  4. Approuvez le déploiement en production, avec un commentaire indiquant ce que vous avez vérifié.
  5. Ajoutez l’étiquette v1.3.0 au commit de fusion et envoyez-la. Vérifiez la mise en production créée par le flux de travail Release.
  6. Montrez l’empreinte à quatre endroits : build-info.json, l’étiquette d’image 1.3.0, l’application de préproduction et l’application de production.

Preuves pour la partie 3 : les quatre empreintes, qui doivent être identiques; l’approbation (un lien ou une trace écrite); la réponse pour « J’ai perdu mon mot de passe » en préproduction; le lien vers la mise en production.

Partie 4 : identifiants et environnements protégés

Section intitulée « Partie 4 : identifiants et environnements protégés »

Utilise Identifiants et accès : identités à portée limitée (réel), Identifiants et accès : les environnements GitHub et Identifiants et accès : les permissions du jeton lui-même.

  1. Montrez les règles de protection de vos environnements : gh api repos/<you>/ticket-api-ci/environments --jq '.environments[] | {name, rules: [.protection_rules[].type]}', ou une description de la page Settings (paramètres).
  2. Montrez que les fichiers du dépôt ne contiennent aucun secret : git grep -n -i -E "api[_-]?key|password|secret" -- . ':!*.md'. Expliquez chaque ligne trouvée.
  3. Parcours réel : montrez le sujet de chaque identifiant fédéré (az identity federated-credential list …), ainsi que le rôle et la portée de chaque identité de déploiement.
  4. Montrez les permissions: (permissions) de chaque tâche du flux de travail et expliquez pourquoi chaque permission est nécessaire.

Preuves pour la partie 4 : les sorties et, pour chacune, une phrase expliquant ce qu’un attaquant pourrait faire sans cette protection.

Partie 5 : exercice de retour en arrière et de correctif urgent

Section intitulée « Partie 5 : exercice de retour en arrière et de correctif urgent »

Utilise Stratégie de retour en arrière : exemple détaillé : le retour en arrière du modèle seulement (réel), Stratégie de retour en arrière : exemple détaillé : le retour en arrière de l’application (réel), Procédure de correctif urgent : exemple détaillé : correctif urgent 1.2.1 et Communiquer une mise en production : la transmission d’un incident.

  1. Retour en arrière du modèle. En production, désactivez keywords-1.2 avec l’indicateur (CLASSIFIER_VERSION=1.1). Mesurez le temps avant que les réponses changent. Réactivez-le.
  2. Retour en arrière de l’application. Déployez l’empreinte 1.2.1 avec le flux de travail Deploy (Run workflow (exécuter le flux de travail), avec l’empreinte et la raison). Vérifiez ce qui a changé pour les clients. Déployez ensuite de nouveau l’empreinte 1.3.0.
  3. Correctif urgent. Simulez un bogue urgent dans la version 1.3.0 dans les environnements locaux. Créez la branche hotfix/1.3.1 à partir de l’étiquette v1.3.0. Écrivez un test qui échoue, corrigez le bogue et laissez la CI exécuter chaque vérification. Ajoutez l’étiquette v1.3.1, déployez le correctif et fusionnez-le dans main par une demande de tirage.
  4. Prouvez que le correctif n’est pas perdu : git branch -r --contains <hotfix commit> affiche origin/main, et le nouveau test est sur main.
  5. Rédigez les notes de mise en production de la version 1.3.1 et un court transfert de l’incident : événements, conséquences, chronologie, état actuel, prochaines étapes et responsable.

Preuves pour la partie 5 : les durées des étapes 1 et 2; ce que le retour en arrière de l’application a retiré aux clients; les liens vers l’exécution CI de la branche du correctif urgent, la mise en production et la demande de tirage de fusion; la sortie de l’étape 4; les notes de mise en production et le transfert.

Ce que vous devriez voir

L’indicateur change le modèle en moins d’une minute, et l’API conserve les mêmes champs. Le retour de l’application à la version 1.2.1 prend environ deux minutes, en passant par la préproduction et la production. Il retire aussi keywords-1.2 : la version 1.2.1 ne reconnaît pas CLASSIFIER_VERSION=1.2. Elle échoue donc au démarrage (unknown CLASSIFIER_VERSION '1.2' (version du classificateur inconnue)), sauf si vous rétablissez d’abord l’indicateur à 1.1. Vérifiez cela avant de revenir en arrière. Dans l’exécution de référence, le retour de la version 1.2.1 à 1.1.0 retirait score (score) des réponses pour la même raison. Une ancienne version ne reconnaît pas les nouveaux paramètres et champs. L’étape 4 affiche origin/main et la branche du correctif urgent.

Vérifiez votre travail

Section intitulée « Vérifiez votre travail »

Ce cours n’a pas encore de personne responsable de la révision. Examinez vos preuves avec ce tableau, ou demandez à un collègue de l’utiliser. Marquez chaque élément comme démontré, partiellement démontré ou pas encore démontré, avec une raison. Le cours est terminé quand chaque élément est démontré. Vous pouvez améliorer un élément et le réexaminer aussi souvent que nécessaire.

Preuves requises Démontré quand
Vérifications liées aux exigences Chaque exigence a une vérification automatique; les nouveaux billets à réussite obligatoire échouent pour keywords-1.1 et réussissent pour keywords-1.2; la référence de base est le classificateur en production.
Promotion d’un artefact immuable Une seule empreinte apparaît dans build-info.json, l’étiquette de version, la préproduction et la production; aucune image n’a été reconstruite pour un environnement ou la mise en production.
Identifiants et environnements protégés La production exige une approbation; les déploiements se connectent sans mot de passe stocké (ou, en simulation, les clés sont uniquement dans des fichiers ignorés); le dépôt ne contient aucun secret; chaque permission du flux de travail a une raison.
Procédure vérifiée de retour en arrière et de correctif urgent Le modèle et l’application ont été rétablis aux versions précédentes, puis récentes, avec des durées mesurées; le correctif urgent a passé chaque vérification, a été mis en production et déployé, et son commit est sur main.

Le bon fonctionnement du scénario normal ne suffit pas. Peut-être que la barrière compare encore avec keywords-1.0, que la mise en production a construit une nouvelle image ou que le correctif urgent n’est pas sur main. L’élément est alors pas encore démontré, même si tout le reste fonctionne.

Erreur courante

Le retour en arrière ne démarre pas

Symptôme : après le déploiement de l’empreinte 1.2.1, la nouvelle révision n’est jamais prête et la tâche de déploiement s’arrête après 5 minutes.

Cause : la production utilise encore CLASSIFIER_VERSION=1.2. La version 1.2.1 reconnaît seulement 1.0 et 1.1. Elle s’arrête donc au démarrage avec ValueError: unknown CLASSIFIER_VERSION '1.2' (erreur de valeur : version du classificateur inconnue). L’ancienne révision continue de recevoir le trafic. Les utilisateurs ne voient donc aucune erreur, mais le retour en arrière n’a pas eu lieu.

Correction : le retour en arrière de l’application doit aussi rétablir les paramètres que seule la nouvelle version reconnaît. Définissez d’abord CLASSIFIER_VERSION=1.1, puis déployez l’ancienne empreinte. Écrivez cela dans la section de retour en arrière de vos notes de mise en production avant d’en avoir besoin.

Récapitulatif

  • Le signalement d’un utilisateur devient une exigence, une vérification et un billet à réussite obligatoire, avant le correctif.
  • La référence de base est ce que les utilisateurs ont aujourd’hui. Quand la production change, la référence de base change.
  • Une seule image va partout. Seuls les paramètres diffèrent entre les environnements, et la production attend une approbation.
  • Exercez-vous au retour en arrière avant d’en avoir besoin : l’indicateur, l’empreinte précédente, le correctif urgent depuis l’étiquette et la fusion dans la branche d’origine.

Vous avez construit et exécuté un processus complet de mise en production. La prochaine étape, MLOps et LLMOps : exploiter l’IA en production, maintient le service en bon état après la mise en production : surveillance, dérive et réentraînement.