Créer automatiquement des tickets Jira ou Linear à partir d'événements d'infrastructure

Quand un certificat est sur le point d'expirer ou qu'un moniteur tombe, la correction n'est généralement pas le plus difficile. Le plus dur, c'est de faire apparaître le problème sur le tableau de votre équipe. Les automatisations peuvent désormais ouvrir un ticket Jira ou Linear directement à partir de n'importe quel événement d'infrastructure, avec le projet, le résumé et les détails déjà renseignés. Le ticket existe ainsi avant que quiconque ait dû remarquer l'alerte et la saisir à la main.

Cet article explique comment cela fonctionne, à quoi ressemble un ticket créé par une règle et comment tout configurer sans recopier d'informations d'un outil à l'autre.

Pourquoi transformer les événements d'infrastructure en tickets

Les alertes vivent dans les outils de monitoring. Le travail, lui, vit dans Jira ou Linear. Si personne ne fait le lien entre les deux, l'une de deux choses se produit. Soit quelqu'un ouvre manuellement un ticket pour chaque alerte, ce qui fonctionne jusqu'au jour où il est 2 h du matin et où personne ne le fait. Soit l'alerte est acquittée dans Slack sans jamais être suivie nulle part : elle n'a alors ni responsable, ni statut, ni trace une fois que le fil du canal l'a fait disparaître.

Le ticket est la bonne unité de travail pour tout ce qui exige qu'un humain agisse concrètement : renouveler un certificat, enquêter sur un moniteur en panne, renouveler un identifiant avant l'expiration d'un domaine. L'événement déclencheur relève de l'infrastructure, mais ce qui en assure le suivi jusqu'à sa résolution devrait être l'outil que votre équipe utilise déjà pour son travail. Créer le ticket automatiquement supprime le fossé entre les deux.

Comment fonctionne l'automatisation, de bout en bout

Dans InfraNest, une règle d'automatisation tient en une phrase : quand ceci se produit, si cela est vrai, faire ces actions. Pour la création de tickets, la structure est presque toujours la même :

1. Déclencheur : un certificat approche de son expiration, un moniteur tombe, le renouvellement d'un domaine approche, une dérive est détectée.
2. Condition (facultative) : uniquement pour les tags de production, uniquement sous un certain seuil, uniquement en dehors d'une fenêtre de maintenance.
3. Action : créer un ticket Jira ou un ticket Linear, dans le projet ou l'équipe de votre choix, avec des champs renseignés à partir de l'événement.

Comme la règle s'exécute sur l'événement réel, le ticket contient le nom de domaine, le nom du moniteur ou le certificat concerné, et non un résumé générique du type « quelque chose est cassé » qu'il faudrait analyser en partant de zéro.

Connecter Jira ou Linear comme destination

Les deux intégrations se connectent de la même façon : en un clic via OAuth, ou avec un jeton ou une clé API si votre organisation n'a pas encore enregistré d'application.

Pour Jira, rendez-vous dans Settings → Integrations et connectez votre site .atlassian.net (Jira Cloud uniquement : Data Center et Server ne sont pas pris en charge). InfraNest confirme alors avec quel compte il communique. Pour Linear, l'équivalent est une connexion via Settings → Integrations ou une clé API personnelle disposant des droits de lecture et d'écriture, limitée à l'équipe dans laquelle vos règles doivent créer les tickets.

WarningAvec l'option de jeton API de Jira, l'adresse e-mail avec laquelle vous vous connectez doit correspondre exactement. Une autre adresse sur le même site est refusée, et l'erreur ressemble à celle d'un jeton invalide plutôt qu'à celle d'une mauvaise adresse e-mail : vérifiez d'abord ce champ si une connexion refuse de s'authentifier.

Un jeton ou une clé est lié à la personne qui l'a créé : il cesse donc de fonctionner si elle quitte l'entreprise. Pour une règle dont toute l'équipe dépend, utilisez les identifiants d'un administrateur ou l'option de connexion en un clic plutôt que des identifiants personnels.

Ce que contient réellement le ticket

Lorsque l'action Create Jira issue ou Create Linear issue s'exécute, elle renseigne les champs que vous avez mappés lors de la création de la règle :

Une règle qui crée des tickets pour les certificats arrivant à expiration peut par exemple définir le résumé sur Certificate expiring: {{domain}} — {{days_remaining}} days left, avec une description indiquant l'émetteur, la date d'expiration et un lien direct vers le certificat dans InfraNest. C'est toute la différence entre un ticket sur lequel il faut enquêter et un ticket sur lequel on peut agir immédiatement.

Boucler la boucle, pas seulement l'ouvrir

Créer le ticket ne représente que la moitié du travail. L'autre moitié consiste à le mettre à jour quand la situation évolue, et cela passe par une paire d'actions distinctes, et non par un envoi ponctuel sans suivi :

• Commenter le ticket : quand le moniteur se rétablit, ajoutez un commentaire pour le signaler, sur le ticket même que la première règle a ouvert.
• Changer son statut : passez-le à Done, ou au nom que votre workflow donne à cette transition, une fois le certificat renouvelé.
• Créer un lien retour : Jira permet de lier le ticket au certificat, au moniteur ou au domaine concerné, dans le panneau Links. Exécuter de nouveau la règle met à jour ce lien au lieu de créer un doublon.

Le ticket créé par la première action est disponible pour les étapes suivantes de la même règle : vous pouvez donc publier son lien dans Slack juste après sa création, ou y ajouter un commentaire plus loin dans la même exécution. C'est ce qui transforme « ouvrir un ticket » en véritable workflow plutôt qu'en simple notification à sens unique.

TipAssociez un déclencheur « tombé en panne » et un déclencheur « rétabli » à la même référence de ticket, plutôt que de créer une règle pour chaque sens. L'incident reste ainsi regroupé dans un seul fil, au lieu de deux tickets qui ne communiquent jamais entre eux.

Tester une règle avant de lui faire confiance

Avant qu'une règle ne touche à un vrai projet, effectuez une simulation (dry run) sur un objet réel de votre compte : elle indique exactement ce qu'elle créerait, sans rien créer. Vous pouvez aussi la tester rétroactivement (backtest) sur les 30 derniers jours d'événements pour voir combien de tickets elle aurait ouverts et sur quoi. C'est le moyen le plus rapide de repérer une règle trop large (chaque micro-coupure d'un moniteur) ou trop restrictive (elle ne se déclenche jamais). Après cinq échecs consécutifs, une règle est automatiquement désactivée, plutôt que d'échouer silencieusement à chaque événement suivant.

C'est encore plus important pour les règles de création de tickets que pour la plupart des autres, car un afflux de tickets en double dans un projet partagé est le genre d'erreur que votre équipe remarque immédiatement, et qu'elle n'apprécie guère de devoir nettoyer.

Un exemple concret

Une règle qui surveille les certificats et crée des tickets Jira se lit, en langage courant, à peu près ainsi :

Quand il reste 14 jours ou moins à un certificat et que son tag est production, créer un ticket Jira dans OPS de type Task, avec le résumé « Certificate expiring: {{domain}} » et l'ingénieur d'astreinte comme responsable.

Si le certificat est renouvelé avant que quiconque ne touche au ticket, une seconde règle, déclenchée par le renouvellement du certificat et associée au même domaine, peut commenter « Renouvelé automatiquement » et passer le ticket à Done. La boucle est bouclée sans que personne n'ait eu à ouvrir Jira.

Ce schéma n'est pas propre aux certificats. La même structure fonctionne pour un moniteur qui tombe, un domaine qui approche de son expiration ou une dérive d'infrastructure détectée sur une zone : n'importe lequel des quelque soixante-dix événements pouvant déclencher une règle, via le même moteur d'automatisations.

Comment cela s'intègre au reste de vos automatisations

La création de tickets fait généralement partie des quelques règles à mettre en place en priorité, aux côtés des notifications et des escalades : consultez ce qu'il faut automatiser en premier si vous partez de zéro. Elle est aussi très proche de la liaison des incidents de la page de statut aux tickets de support : dans les deux cas, il s'agit d'éviter qu'un événement ne se perde dans un canal que personne ne consulte, et de lui offrir à la place un emplacement permanent et traçable.

Si votre équipe travaille déjà dans Jira ou Linear, connectez-le une fois pour toutes et laissez les règles créer les tickets : consultez Connecter Jira, Connecter Linear et la page automatisations pour la liste complète des déclencheurs et des actions que vous pouvez combiner.