Ingegnere sulla piattaforma di comunicazione del team allentamento Ha scritto di come affrontare la loro paura degli schieramenti e di implementare con successo un robot per monitorarli.

Sean McIlroy, un ingegnere informatico senior presso Slack, documenta come sono passati dall'avere un gruppo di sviluppatori che supervisionava l'implementazione delle loro app Web all'utilizzo di un bot per implementare quelle 150 modifiche al giorno. Descrivendo l'apparentemente intimidatoria delega di responsabilità, che alla fine si riduce alla rivelazione matematica di un picco in un grafico, McIlroy spiega il ragionamento e il ragionamento dietro l'assegnazione di un ruolo centrale al loro ReleaseBot in un post dettagliato sul blog.

L'implementazione delle modifiche su una piattaforma su larga scala come Slack presenta una serie di sfide uniche, poiché la maggior parte del servizio viene eseguito da un monolite chiamato “The Webapp” e subisce centinaia di modifiche settimanali. La filosofia di implementazione di Slack è incentrata sulla distribuzione continua, con l'obiettivo di fornire rapidamente il lavoro degli sviluppatori ai clienti attraverso una rapida iterazione basata sul feedback. Tuttavia, gestire il flusso costante di modifiche, con una media di circa 150 modifiche al giorno, richiede un attento equilibrio per evitare di sovraccaricare il sistema e ridurre il rischio di errori.

Tradizionalmente, Slack si affida ai Deployment Leads (DC), individui incaricati di eseguire le fasi di distribuzione durante i turni programmati. Tuttavia, la natura a rotazione dei paesi in via di sviluppo e la crescente complessità del sistema pongono sfide nel creare fiducia e competenze. Pertanto, il team di ingegneri del rilascio ha cercato di risolvere questo problema, concentrandosi sulla fornitura di linee guida più chiare per il processo decisionale nei paesi in via di sviluppo.

Ciò ha portato allo sviluppo di ReleaseBot, un sistema di distribuzione automatizzato dotato di funzionalità di rilevamento e monitoraggio delle anomalie. La transizione dall'implementazione manuale a quella automatizzata è stata graduale, con ReleaseBot che ha lavorato inizialmente a fianco dei DC, dimostrando gradualmente la sua affidabilità ed efficienza nel rilevare i problemi in modo più rapido e coerente rispetto alle sue controparti umane. Sebbene la prospettiva di implementazioni automatizzate avesse inizialmente suscitato preoccupazioni a causa dei rischi percepiti, le prestazioni di ReleaseBot hanno superato le aspettative, infondendo fiducia nella sua capacità di gestire le implementazioni in modo autonomo.

L'efficacia di ReleaseBot risiede nei suoi meccanismi di rilevamento delle anomalie, in particolare attraverso l'uso degli z-score. Z segna Misura la deviazione dei punti dati dalla media, consentendo l'identificazione di valori anomali statistici che indicano potenziali problemi. Ciò viene implementato utilizzando il principio secondo cui se un'applicazione si comporta diversamente dopo la distribuzione rispetto a come si comportava prima, ciò attiva un segnale di “confidenza elevata” che indica la presenza di un problema e consente agli ingegneri di sapere che potrebbe esserci un problema che necessita di intervento. In effetti, questa è una tecnica matematica per rilevare i picchi in un grafico. I segnali di elevata fiducia, causati da ampie deviazioni dai dati storici, meritano un’attenzione immediata, mentre i segnali di bassa fiducia, solitamente governati da soglie fisse, agiscono come avvisi supplementari.

La frequenza e la portata di questi segnali ad alta affidabilità vengono utilizzate per controllare la gravità delle notifiche Slack inviate al team, con una scala di colori bianca, blu e rossa utilizzata per mostrare l'urgenza della considerazione di un segnale. Slack utilizza anche notifiche di soglia statiche come allarmi di bassa affidabilità, ma le utilizza come input per ReleaseBot per calcolare soglie dinamiche che tengono conto del carico normale e delle prestazioni dei componenti al momento della distribuzione. Utilizza i dati storici per distinguere tra picchi anomali e fluttuazioni previste durante le distribuzioni. Questo approccio consente a Slack di filtrare le variazioni di routine identificando al contempo le vere anomalie che richiedono un intervento.

McIlroy conclude evidenziando come il monitoraggio della distribuzione sia diverso dal monitoraggio regolare, che Slack ha sfruttato questa conoscenza per creare uno strumento per rendere le distribuzioni meno intimidatorie e che ora hanno più fiducia in uno strumento di gestione della distribuzione rispetto a quanto fanno gli sviluppatori nelle dashboard. Leggi il Articolo completo qui.