Déployer une passerelle pour webhook
Créez un petit service qui écoute les événements PagerDuty Créez un utilisateur de service dans Settings > Utilisateurs de service sur app.devin.ai avec l’autorisation
incident.resolved et lance une session Devin pour rédiger le post-mortem. Déployez-le sous forme de fonction serverless (AWS Lambda, Cloudflare Worker) ou de conteneur léger :ManageOrgSessions. Copiez le jeton d’API affiché après la création et enregistrez-le sous DEVIN_API_KEY sur votre service relais. Définissez DEVIN_ORG_ID sur l’identifiant de votre organisation — obtenez-le en appelant GET https://api.devin.ai/v3/enterprise/organizations avec votre jeton. Définissez WEBHOOK_SECRET sur un secret partagé que vous configurerez également dans PagerDuty.Configurer PagerDuty
- Dans PagerDuty, accédez à Services > [votre service] > Integrations
- Cliquez sur Add Integration et sélectionnez Generic Webhooks (v3)
- Définissez la Webhook URL sur l’endpoint de votre bridge (par ex.
https://your-bridge.example.com/pagerduty-resolved) - Sous Custom Headers, ajoutez
X-Webhook-Secretavec la même valeur que celle que vous avez enregistrée sousWEBHOOK_SECRET - Sous Event Subscription, filtrez par type d’événement
incident.resolvedafin que le post-mortem se déclenche uniquement une fois l’incident fermé
Vous pouvez également vous abonner à
incident.acknowledged si vous souhaitez que Devin commence à collecter des données pendant que l’incident est encore en cours, puis finalise le post-mortem lors de sa résolution.Connecter des MCP d’observabilité (facultatif)
Devin rédige de meilleurs post-mortems lorsqu’il peut accéder à vos données de télémétrie. Activez un ou plusieurs MCP afin que Devin puisse extraire des données réelles sur la période de l’incident :Datadog MCP — Accédez à Settings > MCP Marketplace, trouvez Datadog, cliquez sur Enable et saisissez vos clés API et Application. Devin interrogera les journaux, les métriques, les événements de déploiement et l’historique des moniteurs.Sentry MCP — Trouvez Sentry dans le MCP Marketplace, cliquez sur Enable et terminez le processus OAuth. Devin extraira les détails des erreurs, les stack traces et les tags de release.Une fois connecté, Devin corrèle automatiquement la télémétrie avec la chronologie de l’incident afin de build un post-mortem étayé par des preuves. Pour en savoir plus, consultez connecter des serveurs MCP.
Ce que génère Devin
Lorsqu’un incident PagerDuty est résolu, Devin analyse la période de l’incident et rédige un post-mortem structuré :Exemple de post-mortem généré par Devin :
Personnaliser le post-mortem
Adaptez le pipeline au processus de postmortem de votre équipe :Utilisez un Playbook pour définir votre modèle de postmortem — sections, niveaux de sévérité, champs obligatoires et emplacement de stockage du résultat. Transmettez un
playbook_id dans la requête API pour standardiser chaque postmortem.Orientez selon la sévérité. Ajoutez une logique dans votre passerelle pour générer des postmortems uniquement pour les incidents P1/P2. Les incidents moins graves ne nécessitent pas forcément un compte rendu complet.Ajoutez à Knowledge des informations sur votre architecture, les responsables de services et les incidents passés afin que Devin puisse faire les rapprochements — par exemple, “orders-service dépend de inventory-service, qui est connu pour des problèmes de timeout sous charge.”Publiez sur votre wiki. Au lieu de faire un commit dans un repo, demandez à Devin de publier le postmortem sur Confluence, Notion ou votre wiki interne via le prompt de session.