Gestione degli imprevisti per i team high velocity
L'approccio "You Build It, You Run It" è ancora in voga?
Sono passati 13 anni dai tempi del "You Build It, You Run It". Ha mantenuto le sue promesse?
Tredici anni fa, un nuovo grido di battaglia per la distribuzione e il funzionamento del software si è fatto strada durante un'intervista e ha stravolto i processi IT di tutto il mondo. Oggi, più aziende che mai stanno adottando l'approccio collaborativo di DevOps e la mentalità "you build, you run" che di solito lo accompagna. Ma ora che abbiamo più di un decennio di cambiamenti alle spalle, il concetto è ancora pertinente? Ha portato i vantaggi che aveva promesso?
Storia del cambiamento
Tutto è iniziato con un'intervista del 2006 con il CTO di Amazon Werner Vogels:
"Dare agli sviluppatori responsabilità operative ha notevolmente migliorato la qualità dei servizi, sia dal punto di vista del cliente che da quello della tecnologia. Il modello tradizionale prevede che porti il tuo software sul muro che separa lo sviluppo e le operazioni, lo lasci lì e te ne dimentichi. Non in Amazon. Tu lo hai sviluppato, tu lo gestisci. Questo mette gli sviluppatori in contatto con il funzionamento quotidiano del loro software. Inoltre, li mette in contatto quotidiano con il cliente. Questo ciclo di feedback dei clienti è essenziale per migliorare la qualità del servizio."
Qui è nato "you build it, you run it": un nuovo modo di fare le cose che si è fuso perfettamente con la successiva ascesa del movimento collaborativo DevOps, per cui era fondamentale abbattere il muro che divideva chi sviluppava e chi forniva il supporto.
L'idea è decollata, e per una buona ragione. Colmare il divario tra sviluppo e operazioni è molto sensato. Perché il team che ha scritto il codice e ha una forte familiarità con il prodotto, non dovrebbe essere quello che indossa i mantelli da supereroe quando si verifica un imprevisto? Oltre ad accelerare i tempi per la risoluzione, la pratica avvicina gli sviluppatori al feedback dei clienti e ai problemi in tempo reale, contribuendo a offrire servizi sempre attivi.
Vantaggi chiari… e sfide chiare
Come per tutti i cambiamenti di processo, insieme ai vantaggi sono emerse una serie di sfide e una forte resistenza da parte delle aziende strutturate in modo più tradizionale.
I vantaggi includevano una minore pressione sui team IT, una progettazione pronta per la produzione, tempi di risposta più rapidi e un codice testato in maniera più accurata (dopotutto, se sei tu quello che viene chiamato all'una di notte per risolvere un bug, le possibilità che tu dia una ricontrollata prima di procedere alla prossima distribuzione sono destinate ad aumentare). Gli sviluppatori d'altro canto sono diventati più efficienti e più completi, hanno appreso nuove competenze e hanno iniziato a pensare al business in modi nuovi.
Poiché la responsabilità del codice spetta allo stesso team, questo approccio ha anche un impatto positivo sulla prevenzione degli imprevisti. Un report ha rilevato che le aziende che affidano la revisione del codice a team esterni prima della distribuzione avevano la stessa percentuale di successo delle aziende che non effettuavano alcuna revisione del codice. D'altro canto, la revisione tra pari gestita da sviluppatori che già conoscono il prodotto, ha avuto un impatto positivo sulla prevenzione degli imprevisti.
Per quanto riguarda le sfide, il nostro team ha affrontato alcune delle sfide di questo mutevole approccio alla gestione degli imprevisti qui: "La sfida [di decentralizzare la gestione degli imprevisti] è che le organizzazioni hanno ancora bisogno di un certo grado di centralizzazione. La leadership ha bisogno di accedere ai report e alla documentazione. Gli stakeholder vogliono ricevere aggiornamenti e vogliono vedere le metriche degli imprevisti come il tempo medio necessario per risolverli e il tempo medio per prenderne atto. Inoltre, si aspettano aggiornamenti chiari sugli imprevisti, report sulle analisi retrospettive e lavori di riparazione.
Per molte aziende che si stanno muovendo verso il decentramento [e un approccio "you build it, you run it"] e lo fanno bene, la risposta a questa sfida è la tecnologia che consente il decentramento e l'autonomia del team per mantenere agile la risoluzione degli imprevisti e la centralizzazione delle informazioni per mantenere il business aggiornato".
L'altra sfida fondamentale è che per molte aziende, adottare l'approccio "you build it, you run it" significa rivoluzionare le strutture del team e la cultura interna. Per farlo servono apertura alla collaborazione, nuovi modi di pensare al prodotto e nuove strutture di team che abbattano le barriere comunicative. Cambiamenti come questi sono impegnativi e richiedono un approccio molto specifico se vogliono avere successo.
Quindi, il "You Build It, You Run It" sta mantenendo la promessa?
Nonostante le difficoltà, secondo la nostra esperienza la risposta è sì. L'approccio "you build it, you run it" sta ancora trasformando il settore, e anche i team IT tradizionali stanno iniziando lentamente a testare le acque.
Non sono disponibili studi sull'adozione dell'approccio "you build it, you run it", ma secondo la nostra esperienza spesso viene adottato di pari passo con i principi DevOps in generale. E abbiamo dei numeri su quelli. Secondo un report di Forrester, nel 2017 il 63% delle organizzazioni ha dichiarato di aver implementato DevOps. Un altro 27% aveva in programma di salire sul carro entro l'anno. E solo l'1% non ha espresso alcun interesse a mettere in atto un cambiamento.
Cosa ancora più interessante, le aziende hanno riportato un aumento medio del 45% della soddisfazione dei clienti e un aumento del 43% della produttività dei dipendenti in seguito all'adozione dei principi DevOps.
Prima passi con l'approccio "You build it, you run it"
Adottare un approccio "You build it, you run it" è impossibile senza una piattaforma flessibile e altamente collaborativa. È fondamentale che Dev e Ops lavorino insieme senza intoppi e questo tipo di collaborazione può essere sbloccato solo con gli strumenti adeguati.
Jira Service Management unisce i team con una comunicazione integrata e collaborativa, consentendo loro di connettersi mediante il loro metodo di comunicazione preferito, dai canali di chat (Slack, Microsoft Teams) alle videoconferenze (tramite bridge video nativo o Zoom). Quasi ogni aspetto di Jira Service Management può essere personalizzato per soddisfare le esigenze di ogni team, dagli avvisi alle routing rule e altro ancora, per aggiornare gli addetti alla risposta necessari e fornire il contesto a tutte le parti, a partire dalle fasi iniziali della risposta fino alla redazione delle analisi retrospettive e alla gestione dei problemi.
Scopri di più su come Jira Service Management può liberare il potenziale collaborativo del tuo team.
Configurare una On-call Schedule con Opsgenie
In questo tutorial imparerai come configurare una On-call Schedule, applicare le regole di sostituzione, configurare le notifiche su chiamata e molto altro, il tutto in Opsgenie.
Segui il tutorialPro e contro dei diversi approcci alla gestione del servizio su chiamata
I team su chiamata si stanno evolvendo rapidamente. Scopri pro e contro dei diversi approcci alla gestione del servizio su chiamata.
Leggi l'articolo