Assegni un'anomalia di costo al team che ne è responsabile, come issue Jira, Linear o GitHub

I Threads di Cloud Intelligence™ ora partono dalle anomalie di costo: apra una issue con le evidenze già allegate, ne segua lo stato dalla pagina dell'anomalia e chiuda il cerchio con l'engineering quando il lavoro è concluso.

Rilevare le anomalie non è mai stata la parte difficile. Il detector scatta, il team FinOps vede che la spesa BigQuery di un progetto è triplicata da un giorno all'altro, e a quel punto la segnalazione entra nella zona grigia tra i team. Il team FinOps può vederla, ma non risolverla. Gli engineer che potrebbero risolverla non passano molto tempo in Cloud Intelligence™: vivono in Jira, Linear o GitHub.

Così qualcuno scrive un messaggio su Slack, o un ticket con i numeri incollati a mano. Da quel momento due versioni della verità iniziano a divergere. Il ticket non sa se la spesa sia rientrata. L'anomalia non sa se qualcuno ci stia lavorando. Un mese dopo nessuno sa dire che fine abbiano fatto i 2.800 $, e la stessa pianificazione mal configurata è tornata silenziosamente in esecuzione.

Da oggi, l'anomalia e il lavoro sono lo stesso record. Da un'occorrenza di anomalia può aprire un Thread, collegato a una issue Jira, Linear o GitHub. La issue arriva già precompilata con le evidenze: cosa è stato rilevato, dove, su quale servizio, quanto è stato osservato rispetto al valore atteso, e un link che riporta esattamente al picco in Cloud Intelligence™. Finisce nel backlog del team responsabile del progetto, nello strumento in cui già pianifica il proprio lavoro. Il suo stato viene riportato sulla pagina dell'anomalia. È lo stesso modello di thread che forse già utilizza da Insights e CloudFlow, ora applicato al momento in cui la responsabilità conta di più.

Perché aprire un thread invece di scrivere un messaggio su Slack

Un'anomalia è una domanda rivolta a un team specifico: intendevate davvero spendere questa cifra? Un thread rende quella domanda permanente. Ha un owner, uno stato e un posto nello sprint di qualcuno, così compete ad armi pari con il resto del lavoro invece di dipendere da chi si è trovato a leggere il canale. L'engineer che la prende in carico trova i numeri, il timestamp e il link alla console direttamente nel ticket. Nessuno deve andare a cercare il team FinOps per chiedere di cosa si trattasse. Quando il fix viene rilasciato e la issue si chiude, il team FinOps vede "Done" sulla pagina dell'anomalia senza dover sollecitare nessuno, e registra poi l'esito sull'anomalia stessa.

Quest'ultimo passaggio è una scelta deliberata. Lo stato di revisione dell'anomalia e lo stato della issue restano indipendenti. La issue appartiene al team di engineering: To Do, In Progress, Done. Il verdetto spetta al team FinOps: In revisione, Anomalia confermata, Non è un'anomalia. Un ticket chiuso non contrassegna silenziosamente un'anomalia come revisionata, e un verdetto di "Non è un'anomalia" non chiude un ticket su cui qualcuno sta ancora lavorando. Ogni team vede lo stato dell'altro; nessuno dei due può sovrascriverlo. Col tempo, l'elenco delle anomalie diventa un registro di decisioni con il lavoro allegato, non una lista di picchi che qualcuno probabilmente ha guardato.

Per i team che stanno costruendo una pratica FinOps, la responsabilità nella pratica è proprio questa: un owner con nome e cognome, uno stato visibile e un esito registrato. Il rilevamento è centralizzato; la remediation è distribuita. I thread sono il modo per affidare una segnalazione al team responsabile della risorsa, mantenere visibilità mentre agisce e dimostrare all'organizzazione che le anomalie vengono risolte, non semplicemente constatate.

Per iniziare

1. Colleghi Jira, Linear o GitHub, se non l'ha già fatto: Jira, Linear o GitHub Issues.
2. Apra un'anomalia da Cost anomalies e scelga Create thread.
3. Segua il lavoro dalla pagina dell'anomalia o da Threads.