ITSM per team high velocity
Come gestire l'IT per supportare il modo di operare di DevOps
È stato dimostrato che l'introduzione dei principi DevOps nei team di assistenza e progettazione IT migliora la qualità del servizio, il morale del team, la risoluzione dei problemi e la produttività aziendale. Difatti, le aziende che adottano i principi DevOps segnalano una soddisfazione dei clienti superiore in media del 45%, una produttività dei dipendenti superiore del 43%, un miglioramento del 41% delle percentuali di difetti e il 38% in meno dei costi relativi all'IT.
Con statistiche come queste, l'integrazione dei principi DevOps nella gestione dei servizi IT è un grande risultato per le aziende. Tuttavia, può anche sembrare un cambiamento complicato per i team. La buona notizia è che non è complicato come sembra. I fattori su cui puoi fare leva per migliorare le prestazioni dei servizi sono così semplici che potrebbero sorprenderti.
Cos'è DevOps?
Quindi, che cos'è esattamente DevOps? È un insieme di pratiche che riuniscono due team spesso divisi in silos e che hanno alle spalle una lunga storia di rapporti conflittuali: sviluppo e operazioni. L'obiettivo è la collaborazione, la comunicazione aperta e la ricerca di modi che consentano a entrambi i reparti di raggiungere i rispettivi obiettivi.
Come spiegano i nostri esperti: "DevOps è un insieme di procedure che automatizza i processi tra lo sviluppo del software e i team IT, affinché possano creare, testare e rilasciare software in modo più rapido e affidabile. Il concetto di DevOps è basato sulla creazione di una cultura di collaborazione tra team che storicamente operavano in silos. I vantaggi promessi includono una maggiore fiducia, rilasci software più rapidi, la capacità di risolvere rapidamente problemi critici e una migliore gestione del lavoro non pianificato".
Perché utilizzare DevOps per l'assistenza IT?
Dal punto di vista del business, i numeri sono eloquenti. 45% di miglioramento della soddisfazione dei clienti. 43% di aumento della produttività dei dipendenti. 38% di riduzione dei costi correlati all'IT. Il movimento DevOps ha contribuito notevolmente a incrementare i profitti aziendali. Questo è probabilmente il motivo per cui 4 aziende su 5 affermano di utilizzare almeno alcuni principi DevOps.
Un altro aspetto altrettanto interessante per i team è il fatto che i principi DevOps, se applicati nel modo appropriato, migliorano la soddisfazione, la collaborazione e il riconoscimento dei dipendenti e dei team. Semplifica i processi difficili, accelera i task ed elimina in parte la burocrazia che da tempo è motivo di tensioni tra IT, sviluppo e altri team correlati.
Se da un lato i team operativi avvertivano un senso di frustrazione quando venivano introdotti nuovi rilasci di cui non sapevano nulla e che non erano pronti a supportare (e che, secondo Gartner, causano l'85-87% degli imprevisti), DevOps agevola la comunicazione e pone le basi per il futuro delle operazioni IT. I team di sviluppo, a loro volta, erano frustrati dai ritardi delle operazioni che causavano un rallentamento dei lanci, mentre ora possono lavorare insieme per velocizzarli senza correre il rischio di non rispettare gli SLA e gli obiettivi SLO.
DevOps per l'assistenza IT: best practice
Definizione delle priorità del cambiamento culturale
La sfida più grande dell'integrazione DevOps è il cambiamento culturale.
Le organizzazioni IT tradizionali lavorano spesso a compartimenti stagni: il team di sviluppo opera all'interno del proprio ecosistema separato e, una volta introdotta una modifica, il team operativo prende il sopravvento, spesso senza neppure fornire un preavviso delle modifiche apportate ai sistemi o fornendo un preavviso minimo.
Le organizzazioni DevOps, invece, danno priorità alla collaborazione e alla comunicazione tra team (attraverso pratiche e strumenti come hack day, stand-up e chat room).
Accogliere questo cambiamento significa adottare nuovi strumenti, nuovi processi e una nuova prospettiva culturale che dia priorità alla comunicazione tra team e al successo condiviso.
Automatizza dove è possibile
Gli incrementi di produttività di DevOps sono dovuti, almeno in parte, a una filosofia che dà priorità all'automazione. Adottare l'approccio DevOps significa incoraggiare i team a chiedersi costantemente: "In quali ambiti possiamo automatizzare?"
Possiamo automatizzare la revisione del codice per gli errori più comuni? Possiamo automatizzare i sistemi per collegare problemi, imprevisti e richieste alle modifiche o ai rilasci che potrebbero averli attivati? Possiamo automatizzare i pesi e contrappesi che ci impediscono di rilasciare codice non conforme ai requisiti di sicurezza o legali? Possiamo automatizzare i sistemi per "congelare" i nuovi rilasci quando siamo pericolosamente vicini ai nostri obiettivi SLO?
Esistono decine di modi per automatizzare e migliorare le metriche DevOps. Di seguito sono riportati tre dei più comuni.
- Flusso di lavoro (ad esempio: spostamento più rapido dei ticket di assistenza tramite il service desk)
- Conoscenza (quando si verifica un imprevisto, lo strumento di gestione dei servizi dovrebbe far emergere automaticamente le informazioni e la documentazione pertinenti)
- Escalation (se nella tua organizzazione ci sono solo due persone che possono risolvere un problema, un sistema intelligente dovrebbe inoltrarlo direttamente a loro invece di seguire percorsi di escalation rigidi e lineari)
Tieni traccia delle metriche importanti
Nell'ambito della collaborazione tra team di sviluppo e team delle operazioni IT, le best practice impongono anche di monitorare come stanno andando le cose.
I più comuni indicatori di prestazioni chiave (KPI) di DevOps includono MTBF (tempo medio tra guasti), MTTR (tempo medio al ripristino, alla riparazione, alla risposta o alla risoluzione), MTTF (tempo medio al verificarsi di un guasto) e MTTA (tempo medio di conferma di ricezione). Molte aziende utilizzano anche dati come il numero di richieste o di avvisi generati in un determinato periodo di tempo, il costo dei tempo di inattività al minuto o il costo dell'assistenza per chiamata/richiesta.
Le metriche che i tuoi team dovranno monitorare dipendono dai team stessi, dalle promesse fatte ia clienti negli accordi SLA, dagli obiettivi SLO concordati con l'organizzazione e da eventuali criticità specifiche. È importante anche capire che le metriche costituiscono un obiettivo mobile. Man mano che le cose cambiano all'interno dell'azienda, dai prodotti supportati dall'IT alle esigenze degli stakeholder fino agli obblighi esterni previsti dalla legge o in materia di sicurezza, potrebbe essere necessario cambiare anche le metriche monitorate e il modo in cui vengono monitorate.
Definisci le priorità della condivisione
DevOps serve a colmare il divario tra creazione e manutenzione, autori e sostenitori. Ha a che fare con la creazione di viste, obiettivi, processi e terminologia condivisi, con la condivisione di conoscenze e comunicazioni, con set di strumenti, risorse e basi di codice condivisi. E, aspetto forse in assoluto più importante, ha a che fare con l'ownership condivisa, il che significa responsabilità condivise e successi condivisi.
Per molte organizzazioni tradizionali, passare a DevOps significherà ripensare al modo in cui definiscono, premiano e monitorano tali responsabilità e successi condivisi. Gli obiettivi del team di sviluppo e del team operativo sono in conflitto? Il successo di un team rende più difficile il successo per l'altro team?
Ad esempio: se il team di sviluppo ha il compito di lanciare nuove funzioni il più rapidamente possibile e il team operativo IT ha il compito di mantenere il tempo di attività, questi due obiettivi potrebbero avere un impatto reciproco negativo. Il team operativo potrebbe voler rallentare quello di sviluppo allo scopo di superare gli obiettivi del tempo di attività e il team di sviluppo potrebbe nutrire risentimenti verso il team operativo perché ostacola il raggiungimento degli obiettivi di lancio.
Per molti team DevOps la soluzione è rappresentata da un approccio SRE, in cui, a condizione che il tempo di attività rientri negli obiettivi SLO, i team di sviluppo possono effettuare tutti i lanci desiderati. E quando il tempo di attività scende a livelli inaccettabili, tutti i lanci vengono bloccati fino a quando i team non collaborano per riportarlo nei giusti binari.
ITIL e DevOps
Se segui ITIL forse ti starai chiedendo in che modo DevOps si inserisce nel quadro. Per molte aziende, le pratiche ITIL e DevOps possono funzionare insieme. Di fatto, in Atlassian vediamo che molte aziende accettano i punti di forza e di debolezza di entrambe.
Come spiega questo articolo su DevOps e ITIL: "Ci servono entrambe. Parliamo di contenitori complementari, non competitivi. Dobbiamo essere in grado di lavorare in modo più intelligente e veloce, ma abbiamo anche bisogno di processi e controlli. Le organizzazioni e i team moderni e ad alte prestazioni iniziano a rendersene conto e utilizzano elementi di entrambe le pratiche: sono andate oltre la logica secondo cui una esclude l'altra".
ITIL tende ad affrontare le best practice per le operazioni, l'assistenza, la governance e altre funzioni aziendali essenziali. DevOps mette in campo aspetti come la continuous delivery, una cultura che non si focalizza sulla ricerca delle colpe, gli strumenti di collaborazione e le pratiche Agile che migliorano e sono basate su pratiche da tempo integrate nelle linee guida ITIL.
Strumenti per organizzazioni orientate a DevOps
Adottare un approccio DevOps può anche significare adottare nuovi strumenti per la comunicazione, l'automazione e la collaborazione tra team.
Nella valutazione di nuovi strumenti, è importante porsi domande come le seguenti:
- Questo strumento funziona nel nostro ambiente e si integra con gli strumenti esistenti?
- Soddisfa le nostre esigenze?
- Tutti i nuovi strumenti funzionano insieme in un set di strumenti completo e coeso?
Potremmo essere di parte, ma in Atlassian utilizziamo Jira Service Management per la gestione dei servizi IT, Jira Software per lo sviluppo software e Bitbucket per il nostro repository di codice.
Il motivo per cui questi strumenti funzionano così bene risiede in parte nel fatto che funzionano bene insieme. E quando abbandoni i silos all'interno delle strutture del tuo team, vorrai anche abbandonarli in qualsiasi strumento tu scelga di utilizzare.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
Leggi il whitepaperAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Leggi il whitepaper