Anomalies de coûts transformées en tickets, assignées à la bonne équipe avant même que quiconque ne lise Slack

Acheminez les anomalies vers l'équipe propriétaire de la ressource, sous forme de tickets Jira, Linear ou GitHub, selon la sévérité, le périmètre de facturation et leur mode de détection.

La détection d'anomalies souffre d'un problème d'acheminement, pas d'un problème de détection. Le détecteur se déclenche, le canal Slack et la boîte mail s'affolent, et la notification atteint tous les abonnés. Dans une petite équipe, cela fonctionne. Dans une organisation où l'équipe checkout gère un ensemble de comptes de facturation, où l'équipe data platform en gère un autre et où le platform engineering est responsable de tout ce qui est critique, la même notification touche quarante personnes, dont trente-huit ne peuvent rien y faire. Au bout de quelques semaines, le canal est mis en sourdine. Pendant ce temps, les deux personnes qui auraient pu corriger la planification mal configurée l'apprennent le jour où la finance pose la question.

Threads dispose désormais de règles d'automatisation : vous décrivez quelles anomalies (ou quels insights) relèvent de quelle équipe et où leurs tickets doivent être créés, et Cloud Intelligence™ ouvre le thread dans le backlog de cette équipe dès qu'une anomalie correspondante est détectée.

Ce que cela vous apporte

Une règle, c'est un ensemble de conditions et une destination. Les conditions correspondent aux caractéristiques propres de l'anomalie : sévérité, périmètre de facturation où elle a été détectée, provenance (données de facturation ou utilisation en temps réel), statut de triage, labels/tags, etc. La destination est un projet, une équipe ou un dépôt dans un outil de suivi (Jira, Linear ou GitHub), avec la personne assignée, les labels et le titre de ticket de votre choix. Ainsi, toute anomalie critique devient un ticket GitHub pour le platform engineering, les anomalies moyennes dans les comptes de facturation du checkout deviennent un ticket Jira pour l'équipe checkout, et les anomalies temps réel dans les projets analytics deviennent un ticket Linear pour l'équipe data platform. Personne d'autre n'est sollicité. Les personnes qui reçoivent le thread sont celles qui peuvent réellement agir.

Vous pouvez prévisualiser une règle sur les anomalies récentes avant de l'activer — rien n'est créé en mode prévisualisation. Les règles s'exécutent de haut en bas et la première règle active qui correspond traite l'anomalie : placez donc les règles spécifiques au-dessus des règles générales. Une règle peut être mise en pause sans être supprimée.

La première règle qui correspond à une anomalie crée son Thread principal, avec les mêmes éléments qu'un thread créé manuellement : ce qui a été détecté, où, l'écart entre les montants observés et attendus, et un lien direct vers le pic. Les anomalies ne sont pas figées. Si une révision ultérieure de la même anomalie correspond toujours, la règle ajoute un commentaire au ticket existant plutôt que d'en ouvrir un second, même si le ticket est déjà fermé, et elle ne touche ni à la personne assignée, ni au statut, ni à quoi que ce soit d'autre que vos ingénieurs ont défini. Chaque modification de règle est conservée sous forme de révision immuable, et un journal d'exécution montre ce qui s'est déclenché, ce qui a été créé et pourquoi.

Si Jira, Linear ou GitHub Issues est déjà connecté pour Threads, il n'y a rien de nouveau à installer. L'automatisation et la création manuelle partagent un même enregistrement : si un collègue ouvre d'abord un thread à la main, la règle le détecte et ne crée pas de doublon. Une limite quotidienne de création par compte évite par ailleurs qu'une matinée agitée n'inonde un backlog.

Pour commencer

1. Connectez Jira, Linear ou GitHub Issues, si ce n'est pas déjà fait.
2. Vérifiez que la détection d'anomalies couvre le périmètre qui vous intéresse, y compris les allocations sur lesquelles vos règles doivent s'appuyer. Les règles ne voient que les anomalies produites par le détecteur.
3. Ouvrez Threads, sélectionnez Thread automation et créez votre première règle.

Les règles d'automatisation sont disponibles pour tout compte disposant de la permission Thread Manager. Ce qui nous intéresse le plus à présent, c'est de savoir comment vos règles se comportent face à un mois réel d'anomalies : lesquelles se sont déclenchées à tort, et quelles équipes vous n'avez toujours pas pu atteindre avec les conditions disponibles.