Gestione degli imprevisti IT: come sta cambiando questa pratica

Punti chiave: la gestione degli imprevisti IT è la pratica di rilevare, rispondere e risolvere i+le interruzioni non pianificate dei servizi per ripristinare le normali operazioni il più rapidamente possibile, e, sempre più spesso, per evitarne il ripetersi.

• Che cos'è: storicamente era una funzione solo IT gestita da un Network Operations Center, ora è condivisa tra i team IT, DevOps, SecOps e di architettura secondo il principio "chi sviluppa, gestisce," con creazione di report centralizzata per l'azienda.

• Perché è importante: affidare la risposta agli imprevisti alle persone più vicine al codice riduce i tempi di ripristino e migliora la qualità del codice, ma funziona solo con processi condivisi, documentazione e una cultura di apertura ed empatia tra i team.

• Come ti aiuta Jira Service Management: consente a ogni team di gestire gli imprevisti relativi ai propri servizi, mentre avvisi, timeline, analisi retrospettive e metriche come MTTR restano in un unico posto per leadership e stakeholder.

La gestione degli imprevisti IT è la pratica di rilevare, rispondere e risolvere le interruzioni non pianificate, come interruzioni del servizio, degrado del servizio o eventi di sicurezza, per ripristinare le normali operazioni il più rapidamente possibile e poi imparare da quanto accaduto in modo che non si ripetano. È una pratica ITSM fondamentale con una lunga storia nelle operazioni IT.

In passato, il team incaricato di rispondere agli incidenti tecnologici era quasi sempre l'IT, spesso un Network Operations Center (NOC) che monitorava i sistemi e rispondeva alle interruzioni del servizio, distribuendo e gestendo software sviluppato da un fornitore. Con la diffusione dei servizi cloud, ora sono i fornitori a sviluppare, distribuire e gestire il software, e i team DevOps, SecOps e di architettura sono sempre più coinvolti nella risposta agli imprevisti. Questa guida esamina come sta cambiando questa pratica e cosa significa per i ruoli, i processi e i team.

Il passaggio verso la decentralizzazione

Immagina di tornare indietro nel tempo di cinque anni e di chiedere al team IT chi sia la persona responsabile della gestione degli imprevisti. La risposta inevitabilmente sarà: "noi".

Fai la stessa domanda ora e probabilmente sentirai parlare non solo dell'IT, ma anche dei team DevOps, SecOps e di architettura. Molte organizzazioni si stanno lentamente spostando verso un approccio "You Build It, You Run It".

Questo approccio offre i vantaggi evidenti di ridurre la pressione sui team IT e accelerare i tempi di risposta trasferendo la responsabilità alle persone che hanno più familiarità con il codice. Ciò riduce al minimo il tempo di inattività e massimizza la produttività del team. Inoltre, costituisce un incentivo per un codice di qualità (se la persona che si sveglia alle 3 del mattino per risolvere un bug sei tu, è probabile che, la prossima volta, controllerai il codice anche tre volte prima di pubblicarlo, per evitare che quella telefonata delle 3 del mattino si ripeta).

La difficoltà di questo approccio risiede nel fatto che le organizzazioni hanno in qualche modo ancora bisogno di un certo grado di centralizzazione. La leadership ha la necessità 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 interventi di correzione.

Per molte aziende che stanno passando con successo alla decentralizzazione, la risposta a questa difficoltà risiede nella tecnologia che consente la decentralizzazione e nell'autonomia del team per mantenere agile la risoluzione degli imprevisti pur continuando a centralizzare le informazioni per tenere sempre informata l'azienda.

La lenta strada verso la decentralizzazione

Come per qualsiasi altro grande cambiamento che potrebbe causare interruzioni nei flussi di lavoro e far emergere conseguenze impreviste, è logico che molte organizzazioni affrontino il percorso della decentralizzazione a piccoli passi.

Iniziano identificando un team che rappresenti una scelta culturale adeguata per un cambiamento come questo e che gestisca un'applicazione o un prodotto a basso rischio, quindi trasferiscono al team la gestione degli imprevisti per l'applicazione o il prodotto specifico per quel team. Lo formano, implementano una programmazione su chiamata e ne monitorano l'avanzamento nel corso del tempo con domande come le seguenti:

• Ha migliorato tempi di ripristino?

• Quali barriere culturali ha incontrato?

• Quali strumenti ha dovuto implementare il team IT?

• Quali processi sono stati necessari per comunicare?

• Il team produrrà aggiornamenti di sistema migliori?

• Il numero di imprevisti è diminuito?

• Se decidiamo di applicare la decentralizzazione ad altri team, quali insegnamenti possiamo trarre dall'esecuzione di test iniziali?

Questi casi di test forniscono una base per decidere se implementare un framework "You Build It, You Run It" in tutta l'azienda e, in caso affermativo, capire come distribuirlo in modo efficace tra i team.

Decentralizzazione è sinonimo di collaborazione tra team

Il passaggio alla decentralizzazione richiede anche un passaggio alla collaborazione tra team. Se il team DevOps è coinvolto nella gestione degli imprevisti, deve avere un ruolo in seno alle riunioni sul processo di gestione degli imprevisti IT. Se l'IT sta ancora definendo le pratiche di gestione degli imprevisti, deve essere coinvolto nelle analisi retrospettive condotte da altri team.

Ogni team porta i propri punti di forza nella gestione degli imprevisti. I team IT sono bravi nello sviluppo di pratiche e documentazione, e nel rispetto delle linee guida. I team DevOps sono bravi nel cambiamento e nell'apprendimento. I team SecOps possono offrire una prospettiva di sicurezza.

Le aziende efficaci nella promozione di una maggiore collaborazione tra i team condividono le informazioni in modo aperto, promuovono l'empatia tra i team, eliminano il gioco dello scaricabarile tra i team, utilizzano la chat per mantenere i team connessi durante gli imprevisti e danno priorità alle revisioni degli imprevisti in cui tutti hanno un ruolo.

Il passaggio da un approccio reattivo a un approccio proattivo

Nelle linee guida ITIL, la gestione degli imprevisti è in genere considerata una pratica separata rispetto alla prevenzione degli imprevisti. Entrambi sono elementi importanti del mosaico ITSM, ma non si verificano spesso insieme.

Il problema di questo approccio risiede nel fatto che mantiene la gestione degli imprevisti in uno stato reattivo. I dipendenti su chiamata hanno il compito di occuparsi delle emergenze e, non appena ne risolvono una, passano a quella successiva. Il loro unico obiettivo è il ripristino, cioè rimettere in funzione il sistema.

Il ripristino, tuttavia, non risolve tutto. Sempre più team IT ne sono consapevoli e stanno integrando la prevenzione nel processo di gestione degli imprevisti e utilizzando metriche come il tempo medio di risoluzione invece del tempo medio di ripristino per valutare le proprie prestazioni.

Questo approccio è spesso definito gestione dei problemi e il suo obiettivo è ridurre la distanza tra i processi, per assicurarsi che i team non si limitino a risolvere un'emergenza e a passare a quella successiva, ma rispondano, eseguano il ripristino e imparino dall'imprevisto, applicando gli insegnamenti appresi sia al problema in questione sia ai sistemi più ampi di prodotto e assistenza che gestiscono.

Con ogni probabilità molte organizzazioni IT aziendali dispongono di una pratica dedicata alla gestione dei problemi. In genere la considerano come un processo separato per un team separato. In Atlassian sosteniamo la necessità di compiere un ulteriore passo avanti e di utilizzare un approccio misto in cui i team delle operazioni IT e di sviluppatori includano la pratica di gestione dei problemi nelle loro pratiche relative agli imprevisti. Ciò fornisce una migliore visibilità dell'imprevisto e garantisce che l'analisi degli imprevisti non avvenga molto tempo dopo che l'imprevisto si è effettivamente verificato.

Questo perché, nel lungo periodo, la prevenzione degli imprevisti ha un valore maggiore rispetto alla risposta rapida.

Stare al passo con il processo e la documentazione

Una delle difficoltà intrinseche nel passaggio alla collaborazione tra team sulla gestione degli imprevisti risiede nel fatto che alcuni team hanno un atteggiamento più rilassato rispetto ad altri riguardo ai processi e alla documentazione.

Questo è uno degli ambiti in cui l'IT può fornire supervisione e un valore elevato persino quando altri team si occupano della gestione dei propri prodotti. Perché nessuno vuole affrontare un imprevisto grave alle 3 del mattino con gli occhi ancora offuscati dal sonno senza un piano solido.

Quando i team sono coinvolti nel processo di gestione degli imprevisti, l'IT può aiutarli a rispondere a domande fondamentali che determineranno quel piano. Ad esempio:

• Qual è la vostra risposta agli imprevisti?

• Quali sono i valori che seguirete?

• Come risponderete in caso di imprevisto?

• Dove si trovano le informazioni di cui avete bisogno per i sistemi critici che supportate? Se risiedono in più sistemi, in che modo potete riunire queste informazioni e renderle facilmente accessibili agli esperti su chiamata?

• Il vostro processo e la vostra documentazione sono collaborativi e revisionabili dal team?

La cultura della tua azienda è pronta per il cambiamento?

Il passaggio verso la decentralizzazione, la collaborazione e una combinazione di gestione di imprevisti e problemi richiede molto più della semplice ridistribuzione delle responsabilità e della presenza programmata di un professionista IT a un'analisi retrospettiva DevOps. La chiave del successo in questo ambito non risiede nella tecnologia e nemmeno nei processi, ma nella creazione di una cultura interna che supporti queste modifiche.

Questa è l'aspetto che troppe aziende cercano di eludere ed è alla base di una transizione di successo. Quindi, quali sono le caratteristiche di una cultura che supporta una gestione degli imprevisti decentralizzata, collaborativa e incentrata sul futuro?

In Atlassian, pensiamo che i componenti principali siano i seguenti:

Apertura e condivisione delle informazioni

Se i team non sono al corrente di ciò che stanno facendo gli altri team, e non possono accedervi, perdiamo delle opportunità di conoscenza che determinano un miglioramento della comunicazione, dei processi e dei prodotti.

Approccio incentrato sul cliente

Quando ci poniamo domande del tipo "Che cosa è davvero meglio per il cliente?", a volte le risposte che troviamo non sono in linea con le nostre pratiche attuali. È necessaria un'attenzione deliberata al cliente per passare al tipo di comunicazione, al processo e alle efficienze strutturali che alla fine rendono i nostri prodotti migliori per i clienti.

Controlli sullo stato regolari

Come sta procedendo ogni team? Che impressione hanno i singoli membri del team riguardo alla situazione? Quali sono le aree di miglioramento del team? In cosa sta andando alla grande? In Atlassian, abbiamo un Playbook dei team che ci aiuta a controllare lo stato dei nostri team e a far conoscere loro nuovi modi di lavorare.

Empatia

Se il team DevOps punta il dito contro il team IT e il team IT guarda con sufficienza l'approccio più rilassato del team DevOps, non si parte con il piede giusto verso la collaborazione. Promuovere l'empatia e i rapporti tra i team è essenziale se vogliamo che comunichino, innovino e lavorino bene insieme.

Empowerment

I team dovrebbero avere gli strumenti necessari per correggere rapidamente i problemi e prendere decisioni in modo indipendente ogni qualvolta sia possibile. Le persone al loro interno dovrebbero sentirsi libere di far sentire la loro voce in caso di domande, suggerimenti o dubbi, indipendentemente dalla posizione che hanno nel team o dagli anni di esperienza.

Quando gli sviluppatori junior sentono di poter alzare la mano nelle riunioni e segnalare un problema, anche quando la responsabilità di un codice errato è di una persona senior, nascono idee innovative, i processi migliorano e i bug vengono individuati prima che entrino nel codice.