Come ITIL, DevOps e SRE collaborano per la tua organizzazione
Pubblicato: 2020-03-02Quando qualcuno chiede che tipo di "negozio" è la tua organizzazione, puoi rispondere con sicurezza che è ITIL, DevOps o SRE?
Forse alcune persone possono, ma se sei una grande impresa, la risposta è probabilmente una combinazione di molti di questi modelli operativi, soprattutto perché SRE è diventato un'implementazione chiave di DevOps. ITIL può funzionare efficacemente insieme ai principi DevOps e SRE, anche se a prima vista sembrano essere specie diverse.
Il trucco è garantire che, indipendentemente dai diversi modelli operativi o toolchain delle organizzazioni, vi sia visibilità, comunicazione e collaborazione condivise tra i team. Ciò consentirà ai tuoi team disparati di rimanere allineati utilizzando le migliori pratiche di ciascuna metodologia.
Cos'è ITIL? Se non ti è familiare...
ITIL sta per Information Technology Infrastructure Library ed è una metodologia che è stata sviluppata per creare un'unica fonte di migliori pratiche per la tecnologia dell'informazione. Secondo Sarah K. White e Lynn Greiner:
"Sviluppato dalla Central Computer and Telecommunications Agency (CCTA) del governo britannico negli anni '80, l'ITIL consisteva inizialmente in più di 30 libri, sviluppati e pubblicati nel tempo, che codificavano le migliori pratiche nella tecnologia dell'informazione accumulate da molte fonti (incluse le migliori pratiche) in tutto il mondo”.
ITIL è stato aggiornato alla quarta versione ora e l'approccio è stato condensato in nove libri. Sebbene questi libri riflettano l'era tecnologica moderna, sono ancora incentrati sugli ideali fondamentali originali di ITIL. Questi ideali includono "l'automazione dei processi, il miglioramento della gestione dei servizi e l'integrazione del reparto IT nel business". ITIL è tradizionalmente una metodologia dall'alto verso il basso, altamente strutturata e guidata dai processi e rimane uno dei framework IT più adottati oggi.
Alcune delle pratiche chiave di ITIL includono il catalogo e la progettazione dei servizi, il monitoraggio e la gestione degli eventi, la gestione degli incidenti e dei problemi, la gestione dei rilasci, la gestione della configurazione e altro ancora. Tutte queste pratiche sono valide indipendentemente dal modello operativo, ma possono manifestarsi in modo diverso nel contesto di diverse esigenze architettoniche e flussi di lavoro. Queste pratiche spesso sono utili anche per le organizzazioni che si identificano fortemente come negozi DevOps o SRE.
Qual è il rapporto tra ITIL e ITSM?
L'ITSM, o gestione della sicurezza delle tecnologie dell'informazione, è il processo attraverso il quale un'azienda gestisce i propri servizi IT. Questo processo è molto orientato al cliente e in genere contiene 5 passaggi:
- Strategia di servizio
- Progettazione del servizio
- Transizione del servizio
- Operazione di servizio
- Miglioramento del servizio continuo
ITIL è un framework per l'implementazione delle pratiche ITSM. Questo framework è indipendente dall'organizzazione e quindi può essere applicato a quasi tutte le aziende, anche se gli unici clienti su cui si concentra l'IT sono quelli interni. Poiché sono così strettamente collegati, non sorprende che ITIL e ITSM siano allineati su molte questioni.
Secondo itiltraining.com:
“C'è una grande enfasi sul miglioramento continuo. Ciò implica misurare e migliorare costantemente i processi, i servizi IT e l'infrastruttura IT. In questo modo si massimizza l'efficienza, l'efficacia e l'economicità".
Come ITIL funziona con DevOps
Quando segui il processo ITIL, il tuo obiettivo è allineare l'IT con gli obiettivi di business della tua organizzazione. Ciò si sposa bene con la filosofia DevOps di abbattere i silos in tutta l'organizzazione. Inoltre, abbattendo questi silos, puoi eliminare i colli di bottiglia nella comunicazione, consentendo ai team di inviare le funzionalità che i clienti desiderano più velocemente e di rispettare il modello CAMS (cultura, automazione, misurazione, condivisione) più da vicino. Ma come appare effettivamente questo quando applicato a un'organizzazione?
Quando usare quale?
La tua organizzazione farà probabilmente affidamento su ITIL e DevOps per diverse situazioni, per trovare la soluzione più efficiente per diversi scenari. Ad esempio, può avere senso sfruttare le best practice DevOps tra i team di sviluppo e operativi, che devono essere allineati su flussi di lavoro, push di codice, automazione e monitoraggio.
Tuttavia, quando si comunica tra diverse parti dell'organizzazione che potrebbero funzionare a velocità diverse, ad esempio vendite e IT, le pratiche ITIL potrebbero tornare utili. Il grafico seguente fornisce solo alcuni esempi di come le due metodologie potrebbero essere applicate in situazioni diverse:

Allineamento tra l'IT e il resto dell'organizzazione
Il risultato dell'impiego di una combinazione di best practice ITIL e DevOps è un migliore allineamento agli obiettivi dell'intera organizzazione. Quando l'IT e il resto di un'organizzazione funzionano come entità totalmente indipendenti, è probabile che una parte si sentirà sempre oberata di lavoro e sotto-supportata. In "The Phoenix Project", un romanzo che esamina le lotte di un'organizzazione immaginaria con l'integrazione IT, questo diventa un conflitto centrale.
Nel libro, l'IT era parzialmente responsabile del successo delle iniziative di ricerca e sviluppo e vendita. La ricerca e lo sviluppo richiedeva dati accurati e rapporti sull'inventario per rifornire l'inventario e andare sul mercato con nuovi prodotti in modo tempestivo. Le vendite richiedevano un sistema CRM, telefono/segreteria telefonica e MRP efficace. In caso contrario, non hanno la possibilità di aggiungere o modificare gli ordini dei clienti e non hanno modo di gestire la salute dei clienti.
Senza la comunicazione interfunzionale, non c'era modo di pianificare questi cambiamenti necessari. Invece, i dipartimenti si facevano richieste irragionevoli l'uno all'altro, le palle venivano spesso lasciate cadere e le entrate dell'azienda aumentavano.
Questo conflitto è stato risolto quando l'IT si è allineato e ha comunicato con il resto dell'organizzazione e altri capi dipartimento hanno fornito un buy-in di alto livello per le iniziative IT. Abbattendo i silos e lavorando insieme, molti di questi problemi sono stati risolti.
A volte, i tempi delle iniziative IT e delle iniziative aziendali sembrano asincroni. Tuttavia, utilizzando le best practice ITIL e DevOps, le organizzazioni possono creare una sequenza temporale coerente. Di seguito è riportato un grafico che mostra come questi processi possono funzionare contemporaneamente per soddisfare l'intera organizzazione.

Proprietà condivisa e miglioramento continuo
Oltre ai miglioramenti del processo, la creazione dell'allineamento tra i framework DevOps e ITIL nella tua organizzazione porta anche a un altro vantaggio significativo: un cambiamento di mentalità. DevOps apporta nuove innovazioni al framework ITIL incoraggiando la proprietà condivisa e il miglioramento continuo.
Quando i silos organizzativi sono ridotti al minimo, gli obiettivi dell'organizzazione diventano gli obiettivi degli individui. Ognuno possiede il successo e il fallimento dell'azienda, perché sono tutti membri della stessa squadra, orientati verso gli stessi risultati. I dipartimenti non sono più contrapposti l'uno contro l'altro. Il miglioramento continuo diventa parte della cultura aziendale e il fallimento viene celebrato e riconosciuto come un'opportunità di apprendimento.
Scopri: mentre navighi, scopri come l'affidabilità del software è una priorità assoluta per la tua azienda!
Come ITIL lavora con SRE
Ora che abbiamo spiegato come si allineano DevOps e ITIL, è il momento di parlare di come si allineano SRE e ITIL. Poiché SRE è un'implementazione di DevOps, molti di questi allineamenti sono simili. È possibile utilizzare le migliori pratiche di tutte e tre le metodologie per aiutare un'organizzazione a funzionare al massimo dell'efficienza. In pratica, ITIL e SRE possono effettivamente creare un'ottima combinazione.

Il primo motivo è semplice: ogni organizzazione vuole clienti felici e ITIL e SRE possono aiutare diverse funzioni a lavorare insieme per renderlo realtà. L'integrazione dell'affidabilità durante tutto il ciclo di vita del software può garantire un tasso più elevato di soddisfazione dei clienti. Con l'ultima revisione di ITIL, che introduce sette principi guida, SRE e ITIL si allineano ancora più strettamente.
I sette principi di ITIL 4
Di seguito sono riportati i sette principi di ITIL 4. Discutiamoli in modo più dettagliato.
1. Inizia da dove sei
L'adozione delle migliori pratiche SRE non è una taglia adatta a tutti e tutti iniziano da qualche parte. Fare i primi passi, implementare e ripetere mentre si procede è ciò che conta di più.
2. Mantienilo semplice e pratico
Nel capitolo del libro Google SRE sulla semplicità, si afferma:
“A differenza di qualsiasi altra cosa nella vita, 'noioso' è in realtà un attributo positivo quando si tratta di software! Non vogliamo che i nostri programmi siano spontanei e interessanti; vogliamo che rispettino il copione e raggiungano in modo prevedibile i loro obiettivi di business”.
La semplicità sia nel software che nelle operazioni aziendali semplifica la comunicazione, aumenta la velocità e aiuta a garantire che l'affidabilità non sia compromessa. Meno è di più.
3. Ottimizza e automatizza
Uno degli obiettivi di SRE è automatizzare i processi gravosi e liberare il tempo degli sviluppatori per concentrare l'innovazione anziché il lavoro non pianificato. Ciò ottimizza i flussi di lavoro e consente alle nuove funzionalità di essere spedite più velocemente.
4. Progredisci in modo iterativo con il feedback
Gli SRE impostano avvisi per le metriche più importanti e incentrate sull'utente. Le metriche, gli avvisi e gli SLO a cui sono legati vengono ripetuti per soddisfare le esigenze dei clienti.
5. Collaborare e promuovere la visibilità
SRE è culturalmente collaborativo. Si concentra su una cultura del lavoro irreprensibile che valorizza l'apprendimento dal fallimento e la fiducia che ogni membro del team stia facendo ciò che pensa sia meglio per l'organizzazione.
6. Concentrati sul valore
Senza clienti, non c'è valore nel software. Il valore aziendale viene creato quando i clienti desiderano e ottengono ciò di cui hanno bisogno da un prodotto. Le migliori pratiche SRE garantiscono che il prodotto sia sufficientemente affidabile da fornire valore ai clienti, fornendo quindi valore all'organizzazione.
7. Pensa e lavora in modo olistico
Abbattendo i silos e concentrandosi su scalabilità e affidabilità a livello olistico, gli SRE sono in grado di fornire vantaggi significativi nella maturazione dell'organizzazione. Il successo a livello aziendale è nelle mani di ogni membro del team e gli SRE lavorano per assicurarsi che il prodotto, i sistemi e le procedure dell'azienda siano sufficientemente resilienti da non solo soddisfare ma superare gli standard dei clienti.
Gestione flessibile e rapida del cambiamento
Una delle migliori pratiche di ITIL è la gestione coordinata delle modifiche supervisionata dal comitato di autorizzazione delle modifiche (CAB). Tuttavia, come notato dal partner di Mindbridge Kaimar Karu:
“La revisione di ogni singola richiesta di modifica da parte del CAB non è efficiente e sicuramente non è un buon senso, soprattutto quando i loro costi possono arrivare a decine di migliaia di implementazioni all'ora in alcune organizzazioni. Tuttavia, ha molto senso che il CAB esamini le richieste di modifica a rischio sconosciuto, quando è necessario consultare parti dell'azienda perché potrebbero risentirne".
SRE può aiutare in questo e i suoi principi fondamentali aiutano a facilitare una gestione del cambiamento molto più flessibile e rapida. Le pratiche a chiamata consentono ai team di essere più responsabili 24 ore su 24 per il codice in produzione. I rollback possono essere automatizzati come parte di soluzioni rapide. Gli incidenti post mortem facilitano le informazioni di apprendimento critiche come gli SLO aiutano i team ad allinearsi su ciò che conta e ad eliminare le complessità esplosive della moderna gestione dei servizi.
Inoltre, i budget di errore creano una linea guida per i team di sviluppo su quando è sicuro distribuire una nuova funzionalità. Se c'è ampio spazio nel budget di errore, la modifica viene approvata, ma se il budget di errore è esaurito o prossimo all'esaurimento, la modifica viene posticipata alla finestra successiva.
Questa maggiore flessibilità è anche ispirata dalla mentalità di leadership SRE. Invece della filosofia del comando e del controllo, SRE riconosce la necessità di flessibilità in un ambiente in continua evoluzione e si concentra sul contesto rispetto al controllo. Ciò significa che se una funzionalità business-critical deve essere spedita, verrà spedita.
Il dream team ITIL, DevOps e SRE
Sebbene alcune organizzazioni operino nel contesto di una sola di queste metodologie, molte ritengono che una combinazione delle tre sia il modo più efficiente per allineare gli obiettivi aziendali e IT per creare servizi sicuri e affidabili. Di seguito è riportato un grafico dei punti di forza di ciascuna metodologia. Sebbene possano basarsi sugli stessi principi e stiano cercando di ottenere lo stesso risultato, le metodologie sono in realtà diverse e molto complementari.
ITIL | DevOps | SRE | |
Filosofia e cultura | Allineare l'IT alle esigenze aziendali per creare una relazione simbiotica Comando e controllo e guidati dai processi per mitigare il rischio | Migliora il lavoro di squadra ed elimina i silos Mira a creare allineamento e ridurre al minimo i silos tra sviluppo e operazioni Spesso orientato ad aiutare i team a migliorare la velocità e la qualità delle distribuzioni | Elimina la fatica, progetta per l'operabilità Tratta le operazioni come un problema software per massimizzare l'efficienza Ideale per supportare servizi distribuiti su larga scala che devono essere iperaffidabili |
Pratiche e strumenti chiave | Pianificazione della capacità Catalogo servizi/CMDB Gestione dei problemi Gestione del cambiamento/comitato consultivo | Pianificazione della capacità In chiamata Microservizi CI/CD Infra come codice Monitoraggio e registrazione Comunicazioni e collaborazione | Abbinare le pratiche chiave di DevOps a: rollout progressivi, SLO e budget di errore Osservabilità Ingegneria del caos |
Lavoro di squadra | Modello tradizionale di processo centralizzato e visibilità. Il lavoro è in genere in coda ("cascata"). Gli incidenti sono stati indirizzati attraverso il team centrale del NOC | Dev e op condividono sempre più lo stesso processo e gli stessi strumenti durante l'intero ciclo di vita del servizio. In genere, ciò significa che gli sviluppatori sono disponibili per ciò che creano, ma possono impegnarsi in operazioni per il supporto L2 | Gli SRE spesso agiscono come consulenti per stabilire pratiche orientate all'affidabilità I ruoli degli ingegneri software e degli SRE convergono, allineandosi attorno a processi e risultati condivisi |
Misure chiave | Disponibilità, # incidenti, # escalation, ecc. | Disponibilità, frequenza di distribuzione, ecc. | SLO, disponibilità, frequenza di implementazione, ecc. Budget di errore |
Conclusione
Identificando quali pratiche hanno più senso per il tuo team e, con alcuni tentativi ed errori, puoi trovare la combinazione definitiva che garantisce che la tua organizzazione operi con la massima efficienza.
Più contenuti: continua ad imparare. Scopri come la tua azienda può beneficiare di una cultura irreprensibile.