À la fin, vous pouvez écrire le changement et le dossier d'incident
Vous serez en mesure de gérer un agent en tant que service vivant : enregistrer les changements, les valider, communiquer avec les parties prenantes et revenir en arrière ou mettre en pause si nécessaire.
Le comportement des clients, la politique commerciale, les intégrations, les modèles et le contenu changent tous.
Le comportement des clients, la politique commerciale, les intégrations, les modèles et le contenu changent tous. Un flux de travail sans contrôle du changement devient lentement impossible à expliquer. Un flux de travail sans restauration transforme chaque version en un pari.
Passer de l'observation à la validation, à la publication, à la récupération et à l'examen
Termes clés : Incident, dossier de modification, retour en arrière et examen post-incident
Comment rédiger le changement et l'enregistrement de l'incident
Classer le problème
Décidez s'il s'agit d'une erreur de contenu, d'un échec d'intégration, d'un problème d'autorisation, d'une régression de qualité, d'une plainte ou d'un incident à fort impact.
Stabiliser d'abord
Mettez en pause les actions à risque, acheminez le travail affecté vers une personne, préservez les preuves et communiquez par le chemin convenu du client.
Faire un changement limité
Documentez l'hypothèse, le responsable, les cas de test, l'approbation et le plan de restauration avant de modifier le comportement de production.
Réviser pour l'apprentissage
Recherchez la condition qui a permis le problème, puis améliorez les instructions, les sources, les outils, la surveillance ou la portée.
Cas de travail : incidents d'exécution, contrôle des changements et amélioration continue
Un client modifie une politique d'annulation, mais l'agent répond à partir d'un ancien document. L'équipe met en pause les réponses automatisées aux politiques, achemine les demandes pertinentes vers l'assistance et enregistre les cas concernés.
Ils remplacent la source ancienne, exécutent l'ensemble d'évaluation, y compris l'ancienne et la nouvelle politique, et ne publient qu'après l'approbation du responsable de la politique. L'enregistrement des modifications note la date, le responsable, les preuves du test et le chemin de retour en arrière.
L'examen mensuel ajoute un contrôle de fraîcheur pour les sources de politique. Le but n'est pas de blâmer le modèle ou de cacher l'erreur ; c'est de rendre le service plus fiable.
Laboratoire appliqué
Résitez une mauvaise mise en production et une véritable récupération
Utilisez une table et un retour en arrière contrôlé. L'équipe doit être en mesure de détecter un changement nuisible, de réduire l'autorité, de restaurer le service, de communiquer clairement et de préserver les preuves sans inventer le processus lors d'un incident.
- Étape 1
Rédigez l'enregistrement de sortie
Capturez les prompts de version, les modèles, les outils, les index sources, les politiques, les migrations, les résultats d'évaluation, l'approbateur, la taille du déploiement, la fenêtre de surveillance, le déclencheur de retour en arrière et le responsable de la restauration.
- Étape 2
Injecter un échec de mise en production
Utilisez un locataire de test sûr pour introduire une régression : une source obsolète gagne, un outil s'arrête après l'écriture, le transfert s'arrête ou le coût triple. Il ne dit pas à l'opérateur où se trouve le défaut.
- Étape 3
Opérer l'incident
Classez la gravité, ouvrez une chronologie, passez au mode dégradé convenu, conservez les traces, informez le bon contact client et décidez de mettre en pause, d'arrière ou de compenser.
- Étape 4
Prouver la récupération
Exécutez les cas de la porte de mise en production après la restauration, réconciliez les systèmes externes, vérifiez que les files d'attente sont drainées en toute sécurité et enregistrez ce qui empêcherait ou raccourcirait le même incident.
Modèle de travail
release_id: agent-2026-08-13.2
change: retrieval index v17 -> v18
exposure: 10% of test tenant traffic
rollback_trigger: supported-answer rate < 96% or any cross-tenant result
degraded_mode: approved-source search with human-written response
incident_started:
detected_by:
client_notified:
rollback_completed:
reconciliation_completed:
follow_up_owner:Preuve à soumettre
Soumettez le dossier de publication, le calendrier de l'incident, le brouillon de communication, les preuves de retour en arrière, le résultat du rapprochement et trois actions de suivi assignées.
Critères de passage
- La rétrofacturation est exécutable, pas une phrase dans un plan.
- Les effets secondaires externes sont réconciliés après la récupération.
- La mise à jour du client distingue les faits connus de l'enquête.
Rédigez le changement et l'enregistrement de l'incident
Le déploiement nécessite des contrôles de mise en production et de récupération.
Utilisez des environnements de développement, de test et de production distincts. prompts de version, outils, modèles, politiques et connaissances. Une version doit avoir des seuils d'évaluation, un déploiement limité, une surveillance, un décideur nommé et un chemin de retour en arrière testé.
- Enregistrez quelle configuration a géré chaque trace de production.
- Canary un changement avec un public limité ou un trafic d'ombre.
- Entraînez-vous à arrêter les actions tout en préservant les preuves pour examen.
Sources utilisées pour cette vérification
Avant de passer à autre chose
- Rédigez un plan de retour en arrière pour le pilote.
- Exécutez un incident de table où une source se trompe.
- Créez une entrée de journal des modifications d'une ligne pour une amélioration sûre.
- L'équipe peut interrompre rapidement l'automatisation risquée.
- Les changements ont des tests et un responsable.
- La communication avec le client est prise en compte.
- Les incidents améliorent le système d'exploitation.
Progression de la leçon
Vous avez terminé cette leçon ?
Enregistrez votre progression sur cet appareil pour reprendre facilement là où vous vous êtes arrêté.
Cette leçon n'est pas encore marquée comme terminée.