Anomalie di costo trasformate in ticket, assegnate al team giusto prima che qualcuno legga Slack

Instradi le anomalie al team responsabile della risorsa, sotto forma di issue Jira, Linear o GitHub, in base a gravità, ambito di fatturazione e modalità di rilevamento.

Il rilevamento delle anomalie ha un problema di recapito, non di rilevamento. Il rilevatore scatta, il canale Slack e la casella di posta si riempiono e la notifica raggiunge tutti gli iscritti. In un team piccolo funziona. In un'organizzazione in cui il team checkout gestisce un gruppo di account di fatturazione, il team della piattaforma dati ne gestisce un altro e il platform engineering risponde di tutto ciò che è critico, la stessa notifica arriva a quaranta persone, trentotto delle quali non possono farci nulla. Dopo qualche settimana il canale viene silenziato. Nel frattempo, le due persone che avrebbero potuto correggere la pianificazione mal configurata lo scoprono soltanto quando arriva la domanda dal reparto finance.

Threads ora dispone di regole di automazione: si definisce quali anomalie (o insight) competono a quale team e dove devono finire le relative issue, e Cloud Intelligence™ apre il thread nel backlog di quel team nel momento stesso in cui viene rilevata un'anomalia corrispondente.

Cosa ottiene

Una regola è un insieme di condizioni più una destinazione. Le condizioni sono i dettagli propri dell'anomalia: la gravità, l'ambito di fatturazione in cui è stata rilevata, se proviene dai dati di fatturazione o dall'utilizzo in tempo reale, lo stato di triage, label/tag, ecc. La destinazione è un progetto, un team o un repository in un tracker (Jira, Linear o GitHub), insieme ad assegnatario, label e titolo dell'issue desiderati. Così "qualsiasi anomalia critica" diventa una issue GitHub per il platform engineering, "anomalie di gravità media negli account di fatturazione del checkout" diventa un ticket Jira per il team checkout e "anomalie in tempo reale nei progetti di analytics" diventa una issue Linear per il team della piattaforma dati. Nessun altro viene disturbato. Chi riceve il thread è chi può davvero cambiare qualcosa.

È possibile testare una regola in anteprima sulle anomalie recenti prima di attivarla: in anteprima non viene creato nulla. Le regole vengono eseguite dall'alto verso il basso e la prima regola attiva che corrisponde gestisce l'anomalia, quindi conviene trascinare le regole più specifiche sopra quelle generiche. Una regola può essere messa in pausa senza doverla eliminare.

La prima regola che corrisponde a un'anomalia crea il suo Thread principale, con le stesse informazioni a corredo di un thread creato manualmente: cosa è stato rilevato, dove, quanto è stato osservato rispetto al valore atteso e un link diretto al picco. Le anomalie non sono statiche. Quando una revisione successiva della stessa anomalia soddisfa ancora i criteri, la regola aggiunge un commento alla issue esistente invece di aprirne una seconda, anche se la issue è già chiusa, e lascia intatti assegnatario, stato e tutto il resto impostato dai Suoi Engineers. Ogni modifica a una regola viene conservata come revisione immutabile e il Run log mostra cosa è scattato, cosa è stato creato e perché.

Se Jira, Linear o GitHub Issues è già connesso per Threads, non c'è nulla di nuovo da installare. Automazione e creazione manuale condividono un unico record: se un collega apre prima un thread manualmente, la regola lo rileva e non crea un duplicato. Esiste inoltre un limite giornaliero di creazione per account, così una mattinata movimentata non può inondare il backlog.

Per iniziare

1. Colleghi Jira, Linear o GitHub Issues, se non l'ha già fatto.
2. Verifichi che il rilevamento delle anomalie copra l'ambito di Suo interesse, incluse eventuali allocazioni che desidera utilizzare come condizioni nelle regole. Le regole vedono solo le anomalie prodotte dal rilevatore.
3. Apra Threads, selezioni Thread automation e crei la Sua prima regola.

Le regole di automazione sono disponibili per qualsiasi account con il permesso Thread Manager. Ciò che più ci interessa sapere ora è come si comportano le Sue regole su un mese reale di anomalie: quali sono scattate quando non avrebbero dovuto e quali team non è ancora riuscito a raggiungere con le condizioni disponibili.