Validation humaine des agents DevOps
Les changements risqués attendent l’accord de l’astreinte.
L’ingénieur décide sur son téléphone avant que votre agent modifie l’infrastructure.
Comment un agent IA DevOps obtient-il l’accord de l’ingénieur d’astreinte ?
Pushary demande l’accord de l’ingénieur d’astreinte sur son téléphone. Placez un appel avant la migration, le redémarrage ou la réduction de capacité. L’ingénieur accepte ou refuse sur l’écran verrouillé et l’agent attend. Sans réponse à temps, le changement n’a pas lieu. Chaque décision est conservée avec son auteur et sa date pour l’analyse de l’incident.
Ce qui demande un accord
Les actions à ne pas laisser partir seules
- runMigration(name)
- Une migration difficile à annuler mérite de réveiller une personne. Un agent peut pourtant la lancer sans hésiter au milieu de la nuit.
- scaleDown(service, replicas)
- Réduire la capacité pendant un incident mal diagnostiqué peut transformer une lenteur en panne complète.
- rotateSecret(name)
- Remplacer un secret peut casser tous les services qui utilisent encore l’ancienne valeur en cache. Un seuil ne suffit pas à juger l’impact.
- deleteResource(arn)
- Une ressource apparemment inactive peut encore être indispensable. Le nettoyage ne doit pas la supprimer sans contrôle.
- promoteToProduction(sha)
- Le déploiement est le moment où une erreur touche les utilisateurs au lieu d’être interceptée par les tests.
Le code
Un appel dans votre étape existante
Encadrez l’action concernée, pas l’agent entier. Les tâches sans risque continuent sans demander d’intervention.
pip install pusharyimport os
from pushary import PusharyServer
px = PusharyServer(api_key=os.environ["PUSHARY_API_KEY"])
def remediate(incident, plan):
# Read-only diagnosis and reversible fixes run unattended.
if plan.reversible and plan.blast_radius == "single-pod":
return apply(plan)
decision = px.decisions.ask(
external_id=incident.on_call_id,
type="confirm",
question=f"{plan.summary}\nBlast radius: {plan.blast_radius}. Reversible: {plan.reversible}.",
)
if not decision["approved"]:
return page_secondary(incident, reason="human declined automated remediation")
return apply(plan)Qui décide
Décider sans être devant son ordinateur
La personne d’astreinte n’est pas toujours devant un terminal. Un message dans un canal fonctionne si elle le consulte avec les notifications actives. Sinon, le changement reste bloqué pendant que l’incident continue. Pushary joint son téléphone grâce à l’identifiant de votre planning d’astreinte.
Nous envoyons déjà nos validations dans Slack. Quelle différence ?
Une publication dans un canal montre une demande. Pour que l’agent attende une décision, il faut aussi une réponse exploitable, un délai, des demandes conservées après redémarrage et un historique des validations. Avec un simple message, ces éléments restent à construire. Ils comptent particulièrement lorsque vous déployez un correctif au milieu d’un incident. Pushary gère la demande et renvoie la réponse à votre code. Si votre équipe travaille dans Slack, la demande peut toujours y arriver. Les réponses restent enregistrées au même endroit, plutôt que dispersées dans l’historique des canaux. Votre logique décide toujours des actions autorisées.
Pour approfondir : Livre SRE de Google sur les mises en production et la gestion des changements.
Intégrez-le à votre produit. Vos utilisateurs ne créent pas de compte Pushary et ne nous paient rien.
Questions fréquentes
Les réponses à vos questions
L’attente survit-elle à un déploiement ?
Peut-on suivre un planning d’astreinte ?
Comment éviter les demandes pour chaque petit changement ?
Quels éléments remettre à un auditeur ?
La validation humaine pour d’autres produits
Faites intervenir une personne là où sa décision compte.
Connectez chaque utilisateur une fois. Posez la question par un appel et exécutez l’action seulement après un oui. Chaque réponse est conservée.
Start free