Riassunto: DevOps Handbook

Questo articolo contiene la mia personale versione “distillata” del libro “The DevOps Handbook”. Riassumere i concetti chiave mi aiuta a ricordarli.

Introduzione

Se avete amato “The Phoenix Project”, apprezzerete questo libro.”The DevOps Handbook” riprende in forma strutturata, da manuale, i concetti base del DevOps che il libro precedente presentava in forma di romanzo.

La prima parte del libro presenta le “tre vie”, la motivazione alla base del devops. La seconda fornisce suggerimenti su come introdurre il devops in azienda. le parti dalla terza alla quindi esplorano in dettaglio le pratiche a supporto di ciascuna delle tre vie. La sesta e ultima parte spiega come aggiungere sicurezza, compliance e change management al mix.

The three way

Flow

La prima via, il flow (flusso), si basa sul concetto di value stream, definito come la sequenza di attività necessarie per soddisfare una richiesta di un cliente, inclusi i duplici flussi di materiali ed informazioni.

Il value stream target per il devops è quello che va dalla commit alla messa in produzione. Questa fase del ciclo di vita del software è assimilabile al lean manufacturing in quanto è caratterizzato da alta prevedibilità, ripetibilità e uniformità. In contrasto, la fase dello sviluppo software, caratterizzata da bassa ripetibilità (ogni richiesta è unica), alta creatività e variabilità è assimilabile a al lean product development.

Le metriche chiave per l’analisi dei value stream sono lead time (o cycle time) e process time, che uniti danno anche l’efficienza del processo e il rapporto “complete/accurate”, metrica di qualità che si ottiene valutando il numero di item che, passate al processo downstream, devono tornare al mittente perché non lavorabili rispetto al numero totale di item… in breve, gli scarti rispetto al totale.

I principi alla base dell’ottimizzazione del flow sono la riduzione del batch size, la visualizzazione del lavoro, la built in quality, il limite al work in progress, la riduzione del numero di handoff. Le pratiche che ne derivano includono il continuous delivery, la creazione di ambienti on demand, il WIP limit e la creazione di un contesto change-safe.

In ogni value stream, in un dato momento, c’è sempre uno e un solo bottleneck. Qualsiasi miglioramento che non agisca sul bottleneck, nella migliore delle ipotesi non darà beneficio, nella peggiore peggiorerà la situazione al bottleneck. Per questo, è fondamentale identificare i constraint e agire su quelli.

Nella tipica trasformazione devops, solitamente i constraint sono i seguenti:

• creazione ambienti: l’obiettivo è di arrivare ad un completo self service on demand.
• deploy: obiettivo, self service deploy.
• test setup and run:obiettivo test automation
• architettura tighly coupled

una volta rimossi questi constraint, i punti rimanenti sono lo sviluppo o il product owner.

Feedback

Se il flow va da “sinistra a destra”, il feedback chiude il cerchio. l’obiettivo è quello di aumentare la qualità evitando che i problemi si ripresentino.

La pratica base è quella dello swarming, in cui i problemi portano all’interruzione delle attività e alla prioritizzazione della soluzione.

La pratica si rifà al principio dell’ “andon cord”: quando c’è un problema, se non si risolve in brevissimo tempo, la corda viene tirata e l’azienda intera si da come prima priorità quella di risolvere il problema, invece di cercare workaround.

Questa pratica sembra contraria al buon senso manageriale, in quanto un problema locale porta all’interruzione delle attività globale. Tuttavia questo modo di fare permette di aumentare la conoscenza, senza la quale la qualità degrada.

In altro principio fondamentale è quello di spostare la responsabilità vicino a chi effettua il lavoro.

Continuous Improvement

La terza via prevede la delega della responsabilità verso il basso e richiede una cultura aziendale basata sulla fiducia che permette alla forza lavoro di sperimentare in un ambiente sicuro, senza tema di sbagliare.

L’assenza di miglioramento non porta alla stabilità: porta al degrado. Quando la situazione degrada troppo, il tempo è speso in attività di emergenza. Per questo il lavoro di miglioramento è piú importante del lavoro stesso.

Il lavoro di miglioramento deve essere riservato nel normale ciclo di sviluppo o durante i cosiddetti kaizen blitzes.

Introdurre il DevOps

Le linee guida sono di buon senso: partire piccoli, portare success stories e avere un obiettivo chiaro in mente.

Selezionare il value stream

La prima cosa da fare è scegliere il value stream da ottimizzare. Come fare?
Alcuni fattori da considerare sono:
greenfield vs brownfield: Il fatto di partire da un sistema esistente non è di per se uno svantaggio. La differenza la fa il fatto che l’applicazione abbia un’architettura pensata con la testabilità e deployabilità in mente.
system of record vs system of engagement: in realtà, anche in questo caso la distinzione conta poco: devops ottimizza velicità e qualità, cose essenziali in entrambi i casi.

Il team con cui partire è fondamentale. Deve essere costituito da innovatori o early adopters che credano nella missione. Questo è indispensabile per accumulare successi con cui poi convertire i team piú avversi al rischio.

Dopo i successi iniziali, si puó crescere. Il processo ideale è il seguente:

• trova innovatori e early adopters, che siano rispettati e influenti. Daranno credibilità all’iniziativa.
• crea massa critica includendo la maggioranza silente.
• identifica gli oppositori: questi vanno affrontati solo dopo aver creato massa critica.

Dopo aver scelto il value stream, dobbiamo capirne la struttura. Un modo per farlo è utilizzare il value stream mapping workshop, un processo fatto per catturare tutti gli step necessari per creare il valore.

Creare la value stream map

Il primo passo consiste nell’identificare i team che supportano (ovvero hanno attività) in un value stream. In un value stream complesso, nessuno conosce da solo l’end to end. Tipicamente servono: il product owner, lo sviluppo, la qa, le operations,security, release management.

Il secondo step consiste nel creare un mappa del value stream per visualizzare il lavoro. In molte organizzazioni, il value stream è composto da centinaia se non migliaia di attività. Il workshop puó richiedere giorni e persone dedicate senza interruzioni. Il livello di approfondimento è medio: non si intende tracciare tutti i dettagli, solo quanto basta per evidenziare punti critici, in particolare:

• punti in cui il lavoro si arena (bottleneck)
• punti in cui si genera significativo rework

Il punto di partenza è costituito da una mappatura di alto livello degli step principali (10-15 blocchi). Ogni blocco dovrebbe avere un’indicazione di lead time, cycle time e %completo/accurato.

Una volta indentificata la metriche che si vuole migliorare (dovrebbe essere sul bottleneck del processo, come da teoria dei vincoli), si passa ad ipotizzare uno stato target da raggiungere in 3-6 mesi, iterando continuamente.

Creare un team dedicato

Le attività di trasformazione entrano in competizione con le attività di linea sulle risorse. Inoltre, un sistema tende a mantenere lo status quo attraverso la burocrazia, la prassi e l’abitudine. Per questo occorre creare un gruppo di trasformazione che possa operare al di fuori delle regole dell’organizzazione. Il team è responsabile di obiettivi sistemici misurabili e ben definiti.

I membri di questo team sono allocati full time. Devono essere generalisti versati, dotati di alta credibilità e fiducia reciproca. Anche fisicamente, il team dovrebbe essere separato dal resto dell’organizzazione.

Condividere l’obiettivo

Una delle cose piú importanti è definire e condividere un obiettivo chiaro, misurabile, con una scadenza precisa. Challenging ma fattibile.

Il team lavorerà in modo iterativo e incrementale (alla scrum) al raggiungimento dell’obiettivo. L’orizzonte di pianificazione deve essere breve, con l’obiettivo di generare risultati visibili in settimane, massimo mesi. In questo modo si puo’ ripianificare velocemente, avere cicli di feedback rapidi e mostrare rapidamente progressi.

Il resto dell’organizzazione deve comunque attuare strategie per mantenere il debito tecnico basso. Tipicamente il 20% del tempo deve essere speso in attività di riduzione del debito.

Applicare la legge di Conway

La legge di conway esprime la relazione che c’è nelle organizzioni tecnico/orgsanizzative tra architettura e divisione del lavoro. In estrema sintesi, dice che ogni organizzazione è destinata a produrre architetture che sono lo specchio della struttura organizzativa. Ne consegue che per avere un’architettura efficace dobbiamo rimodellare la struttura di delivery.

Ci sono 3 strutture principali:

• funzionale: team organizzati per funzione o specializzazione. Cost-effective, struttura tradizionale.
• market-oriented: team cross funzionali, struttura gerarchica piatta.
• matrice: una via di mezzo tra le due, team cross e linea gerarchica funzionale.

Gli svantaggi della struttura funzionale sono:

• il personale dei team funzionali sono lontani dalla “big picture”: vedono solo il loro piccolo task, come ingranaggi di una macchia.
• il personale dei team funzionali lavora spesso in modo concorrente su diversi value stream, con necessità di escalation per prioritizzazione e rallentamenti per lunghe code, handoff.

La struttura funzionale, in breve, è efficiente (cost-effective), ma non efficace in termini di velocità di delivery.

La massima velocità si ottiene con i team market-oriented. Per crearli, non serve una grossa riorganizzazione top-down.

Una via di mezzo è data dall’organizzazione “functional oriented”: alcuni dipartimenti (ad es, i DBA) rimangono gestiti in modo funzionale, ma lavorano per abilitare i team cross-funzionali, fornendo loro strumenti (piú possibile in self service) che velocizzino il loro lavoro.

Altri due fattori chiave di successo sono:

• rendere il team responsabile del prodotto a 360°, compresa sicurezza, monitoraggio, operations, deployment.
• avere un team di generalisti: la specializzazione eccessiva porta ai silo. Sebbene la specializzazione sia necessaria, serve un’infarinatura di tutto.

Questa necessità influenza anche il recruiting e il training: occorre prendere e formale generalisti, la cui capacità di apprendere e innovare è piú importante della profondità degli skill specialistici.

I team devono essere strutturati con la legge di conway in mente, in modo da avere chiari boundaries ed essere piú autonomi possibile (SOA). I team devono soddisfare la regola delle due pizze (max 10 persone, le pizze americane del resto sono enormi).

Siccome i team devono essere cross funzionali (o almeno avere un orientamento cross funzionale anche in presenza di team funzionali), le operation devono essere prese in carico dal team.

Creare team cross funzionali puó essere fatto in due modi:

• embeddando risorse di opeations nei team: scala poco.
• embeddando un ufficiale di collegamento: scala meglio, meno efficace.

Le risorse embeddate devono partecipare alle cerimonie del team (stand up, retrospective) e il loro lavoro deve essere reso visibile (kanban).

Indipendentemente dal modello, i team di opeations devono lavorare con un approccio “di prodotto”. I loro clienti sono i team di sviluppo e devono conquistarseli. Va bene che i team di sviluppo siano dipendenti dai tool che i team di operations creano, non va bene che siano dipendenti dai team stessi, quindi l’approccio da seguire è quello del self servicing.

Pratiche che supportano il Flow

Per raggiungere un flusso di valore costante e spedito, la cosiddetta “first way”, occorre creare le fondamenta della pipeline di delivery. Uno dei pilastri è dato dalla possibilità di creare on demand e in modo automatico ambienti analoghi alla produzione.

Per fare questo, occorre rendere gli ambienti “piú facili da ricreare che da riparare”. Per raggiungere questo obiettivo è necessario che tutto quanto necessario alla creazione di un ambiente sia sotto controllo di versione (infrastructure as code): dagli script per i database, alle immagini, alle macchine virtuali alle configurazioni di rete: TUTTO.

La definition of done deve includere la verifica della funzionalità in un ambiente analogo a quello produttivo. Il passo successivo è costituito dalla deploy pipeline. La deploy pipeline viene esiguita ad ogni commit. Visto che tutto è sotto controllo di versione, non si intende solo commit di codice, ma anche degli ambienti.

La pipeline funziona in stage: dal build al deploy in un ambiente “production like” e all’esecuzione di test automatici. L’approccio suggerito è quello di continuos integration:

• evitare branch lunghi
• cultura dello “stop the line” (se qualcosa non va, ci si ferma finchè non è aggiustato. Questa pratica è anche detta “Andon”, dall’originale cordone degli impianti toyota che, se tirato, bloccava la catena di montaggio).
• copertura elevata di test automatici che assicurino di essere in uno stato deployabile.

La pipeline deve anticipare e rendere il piú veloce possibile l’individuazione degli errori. Per questo, deve essere veloce: la maggior parte degli errori deve essere individuata dai primi stage della pipeline (veloci ed economici).

Una tipica pipeline di test automation è costituita da (nomi presi da “continuous delivery”):

• Unit test.
• Acceptance test, aka System test
• Integration test, aka SIT.

Ai test automatici, si aggiungono poi fasi di test manuale come il testing esplorativo o lo user acceptance test. Le fasi manuali non sono vietate nè sconsigliate: l’importante è che non si faccia manualmente qualcosa che si puó automatizzare.

Visto che l’obiettivo è trovare quanti piú bug possibili nelle fasi iniziali della pipeline, è buona pratica creare uno unit test ogni volta che un bug viene trovato nelle fasi piú costose di test (integration, UAT).

La pipeline di test deve coprire anche gli aspetti non funzionali, performance in primis.

Particolare enfasi va posta sul principio dell’andon cord. Quando la pipeline si ferma, la priorità numero uno di tutti diventa quella di sistemarla. Nient’altro viene committato finchè la build non torna verde. Questo è necessari in quanto la pipeline, contenendo la test automation, è la garanzia dell’affidabilità del nostro codice. Tagliare le curve su questo porta all’aumento dell’instabilità, del debito e conseguente aumento della pressione sul delivery (ciclo vizioso).

Il continuous delivery richiede l’adozione di un approccio trunk based. E’ suggerita inoltre l’adozione di gated commit: nulla che comprometta la stabilità della build viene accettato sulla trunk. Conviene integrare questo nella propria definition of done:

“At the end of each development interval, we must have integrated, tested, working, and potentially shippable code, demonstrated in a production-like environment, created from trunk using a one-click process, and validated with automated tests.”

– the DevOps Handbook

Il processo di deploy deve essere automatizzato, ma prima ancora, deve essere reingegnerizato in modo da ridurre il numero di handoff e di ritardi. Il processo di deploy deve essere ripetibile in ogni ambiente, l’ambiente deve essere smoke-tested (le dipendenze sono raggiungibili). Il deploy in produzione deve idealmente essere fatto dallo sviluppo stesso. Nelle situazioni in cui sicurezza o compliance richiedono una separazione delle responsabilità, si puó ricorrere alla peer review.

Un’altra pratica per raggiungere un flusso costante e frequente di delivery è quella di separare il delivery (installazione in produzione) dalla release (apertura della feature al pubblico). In questo modo i vincoli business (sincronizzare la release con una campagna marketing, attendere un provider esterno, etc…) non disturbano il flusso tecnico di rilascio. Due le strategie: lavorando sull’ambiente produttivo o lavorando a livello applicativo.

Le pratiche basate sull’ambiente includono:

• green/blue deploy: due ambienti, uno solo attivo, si alternano al rilascio. I database costituiscono un problema particolare in questo caso.
• canary release: la nuova versione viene rilasciata su un sottoinsieme dell’ambiente produttivo (o aperto ad un sottoinsieme degli utenti) e il comportamento viene monitorato prima di aprire.

Le pratiche basate sull’applicativo:

• Feature toggles: flag applicativi che permettono di spegnere/accendere specifiche features
• Dark launches: le nuove features sono aperte incrementalmente, solo una parte degli utenti (ad esempio, i dipendenti) vedono e testano le nuove features.

Non tutte le architetture rendono possibile applicare le pratiche viste sopra. Puó essere particolarmente difficile applicarle ad un’architettura monolitica. Per questo bisogna modificare l’architettura in modo progressivo cosí da abilitare i pattern desiderati.

Una delle strategie piú usate per far evolvere l’architettura nella direzione desiderata è quella chiamata “strangler application”: nascondere le funzionalità legacy dietro ad un layer di API e mettere nuove features in questo layer di API, chiamando l’applicazione legacy quando necessario.

L’architettura a servizi, in cui i componenti comunicano tramite chiare API (attenzione: architettura a servizi non significa necessariamente web services) permette di avere rilasci a basso rischio.

Pratiche che supportano il Feedback

Nessun feedback è possibile in assenza di misure. Sono le misure che permettono di valutare l’efficacia delle soluzioni.Per questo, le applicazioni devono essere dotate di telemetria.

La telemetria deve coprire tutti gli aspetti: dal business (metriche di efficacia dei processi, metriche di guadagno), agli aspetti applicativi fino a quelle piú ovvie di infrastruttura (latenza, CPU, memoria).

Tutte le metriche devono essere raccolte insieme, in modo da poterle facilmente correlare. Le metriche devono guidare il problem solving, che deve svolgersi in un ambiente caratterizzato dall’assenza di blaming.

Visto che le metriche sono cosí importanti, la raccolta di metriche deve essere parte del daily work ed estremamente semplice. L’infrastruttura di raccolta metriche deve essere self service: aggiungere una metrica e vederla visualizzata deve essere facile come aggiungere due righe di codice, senza necessità di ticket a team diversi.

Le metriche devono essere accessibili in self service, in quanto devono fungere da radiatori di informazioni. Gli information radiators assolvono due compiti: mostrano che il team non ha nulla da nascondere agli altri e rendono il team autocosciente (non ha nulla da nascondere neanche a se stesso).

Il primo passo verso il feedback è quindi quello di individuare e colmare gap di telemetria. Le misure riguardano non solo le metriche applicative, ma anche quelle di business. Correlare l’attività del team con il raggiungimento degli obiettivi di business aumenta il senso di utilità del team stesso.

Anche le metriche relative alla pipeline di deployment devono essere raccolte e rese evidenti.

Le metriche devono essere tra loro correlate e correlate anche con gli eventi di change: in questo modo è possibile accorgersi che un certo change ha causato un’evoluzione o involuzione di una o piú metriche, stabilendo relazioni causa/effetto.

Raccogliere metriche è inutile se esse non vengono analizzate per trarne informazioni in modo proattivo, prima che i problemi si verifichino. L’accuratezza degli allarmi è importante, in quanto troppi falsi positivi riducono l’autorevolezza del sistema di allarme, troppi falsi negativi hanno impatto sul servizio.

L’analisi delle metriche richiede una conoscenza della metrica stessa per impostare il giusto tipo di anomaly detection. Per le metriche con distribuzione gaussiana (o pseudogaussiana), si puo’ usare la varianza. Per distribuzioni non-gaussiana, meglio usare tecniche di destagionalizzazione come le medie mobili o i filtri Kolmogorov-Smirnov.

Le metriche aiutano anche a rendere piú sicuri i deploy. Poter contare su un sistema di alert basato su metriche permette di individuare tempestivamente problemi introdotti da un rilascio.

Le metriche possono essere usate per stabilire delle soglie di handoff tra operation e sviluppo. Fino a che certe metriche di stabilità non sono ad un certo livello, è il team di sviluppo che si occupa delle operations mentre il team di operation lo aiuta, con approccio consulenziale, a mettere in campo quelle azioni che permettano di riportare l’applicazione al livello desiderato.

L’ A/B testing deve far parte del lavoro quotidiano. Prima di costruire una cosa, bisogna chiedersi perchè dovremmo costruirlo. L’A/B testing nasce in ambito marketing. Funziona in questo modo: si crea un’ipotesi (“il colore del bottone influenza la probabilità di click”) e si creano due scenari: lo scenario che implementa l’ipotesi e uno scenario di riferimento. Poi con tecniche statistiche si valida l’ipotesi.

La fase di definizione dell’esperimento di A/B testing è cruciale. Se non si sa esprimere l’ipotesi, non si dovrebbe procedere. Una buona formulazione dell’esperimento ha questa struttura:

• crediamo che <ipotesi>
• porterà a <conseguenza>
• procederemo con sicurezza se vedremo <risultato atteso>

Esempio:

Crediamo che aumentare le dimensioni dell’immagine del prodotto porterà ad una miglior conversione e procederemo con sicurezza se vedremo un aumento del 5% negli acquisti nei clienti che hanno visto le immagini di maggiori dimensioni in 48 ore.

Un’altra pratica che abilità il feedback è quella della peer review. Storicamente, la misura proposta per ridurre il rischio dei change è quella di inserire gate approvativi. I gate approvativi sono inefficaci quando chi deve approvare è lontano dalla modifica introdotta: non ha le conoscenze o il contesto per poter applicare un filtro efficace e introduce rallentamenti a basso valore aggiunto.

Per contro, la peer review delle commit, eventualmente fatta da “specialisti” (ed es: DBA quando si tratta di query), garantisce un feedback di contenuto, vicino alla modifica, immediato e qualificato.

Perchè la peer revies sia efficace, la dimensione del cambiamento deve essere ridotta. Un aneddoto esplicativo recita: “un reviewer troverà 10 punti di miglioramento in una change di 10 righe. In una change di 500 righe, dirà che è tutto ok”.

Il processo di change e la struttura preposta dovrebbero servire per coordinare change complessi, quali quelli dell’infrastruttura di base o cambiamenti concorrenti in architettura complesse e accoppiate.

Il processo di peer review puó prendere tante forme: pair programming, pull request, review “over the shoulder”. Il pair programming è in un certo senso una pair review potenziata.

Se si procede invece con un approccio basato sulla pull request, occorre valutarne l’efficacia in modo che non diventi un automatismo privo di valore (“rubber stamping”). Si possono usare metriche legate al processo stesso o effettuare ispezioni a campione.

Pratiche a supporto del continuous learning e sperimentazione

Il flow porta al delivery del valore. Il feedback da i meccanismi di controllo. Il continuous learning pone le basi per l’evoluzione del sistema attraverso la sperimentazione, l’accumulo di conoscenza e la sua diffusione.

L’aspetto piú critico del continuous learning è la cultura dell’errore. E’ necessario che gli errori siano visti come un’opportunità di imparare e non come qualcosa che porta ad una punizione. Un buon esempio è dato dall’esperienza di Netflix, dove gli errori produttivi vengono volutamente causati per permettere al “sistema immunitario” di evolvere.

Il punto di partenza mentale corretto è quello di considerare gli incidenti un effetto del sistema che è stato creato e non il risultato delle azioni di una “mela marcia”. Un’atmosfera in cui l’errore è visto come un’opportunità di crescita per l’organizzazione porta alla massima collaborazione. Chi ha commesso l’errore non avrà alcuna ragione per cercare di nascondere informazione e non sprecherà energie nel cercare di difendere se stesso.

Una pratica efficace in tal senso è il blameless post mortem (non lo traduco, rende bene in inglese). Questo evento deve essere fatto subito dopo aver risolto il problema, quando la conoscenza è ancora fresca e ha l’obiettivo di identificare la sequenza di eventi che ha causato il fallimento e studiare misure che lo possano prevenire in futuro. Devono essere coinvolte le persone che hanno causato il problema, quelle che l’hanno identificato, risolto, diagnosticato e subito. E’ importante che il clima sia non punitivo (blameless) e che si evitino scenari ipotetici (“avremmo dovuto, avremmo potuto”) in quanto allontanano il problema dalla realtà del sistema che l’ha generato. Bisogna dedicare tempo sufficiente alla generazione di contromisure, prioritizzarle e assegnare a ciascuna un owner e una timeline di realizzazione. La realizzazione di queste contromisure dovrebbe essere la priorità numero uno dell’azienda.

I risultati delle retrospettive devono essere resi pubblici, in modo da aumentare la conoscenza condivisa.

Man mano che i problemi vengono risolti, occorre ridurre la tolleranza all’errore: in questo modo, si progredisce ulteriormente.

Le chat room sono un buon modo per diffondere la conoscenza, meglio ancora se integrate con la pipeline: poter dare comandi o ricevere notifiche tramite la chat in cui il team normalmente discute è un ottimo radiatore.

Altre pratiche suggerite sono

• la presenza di un unica codebase accessibile a tutti
• la formalizzazione di processi non tramite documenti ma tramite script eseguibili, anch’essi sotto controllo di versione.
• L’adozione di TDD e l’uso dei test automatici come forma di comunicazione.
• L’uso di communities of practice

Ïl miglioramento richiede tempo e risorse. Un modo è quello di istituzionalizzare gli “improvement blitzes”, momenti in cui le risorse si dedicano a risolvere problemi tecnico organizzativi. Durante questi momenti non è ammesso lavoro su features.

L’obbiettivo durante i blitz è di migliorare il lavoro quotidiano. Al termine del blitz, ogni team coinvolto effettua una presentazione dei risultati. Sono i team a portare le proposte: questo da motivazione e fa si che siano quelli piú vicini al lavoro a fare le proposte.

Security, Change management & Compliance

Il DevOps nasce dall’esigenza di aumentare la produttività degli sviluppatori anche a fronte di un aumento degli stessi. Del resto non ci sono mai abbastanza sistemisti. Questo è ancora piú vero per quanto riguarda le figure di infosec: ecco il DevSecOps o Rugged DevOps.

Uno degli obiettivi è quello di avere le figure di sicurezza coinvolte prima possibile nel processo di sviluppo. Uno dei modi è avere le figure di sicurezza coinvolte nelle demo alla fine di ogni ciclo di sviluppo, in modo che possano capire gli obiettivi business e guidare le implementazioni.

Le issue di sicurezza devono essere tracciate alla stessa stregua dei bug. Anche gli incidenti di sicurezza devono essere trattati alla stessa stregua delle altre issue, eseguendo dei blameless post mortem.

I controlli di sicurezza (Security testing), per quanto possibile, devono essere parte della deploy pipeline. Questo approccio è molto piú reattivo del tradizionale “penetration testing a fine progetto”. Il personale deve essere formato su tematiche di sicurezza, in quanto essa deve diventare responsabilità di tutti.

Il security testing delle applicazioni è supportato da diverse pratiche:

• analisi statica, esistono tool specifici per le vulnerabilità di sicurezza (Brakeman, Code Climate, etc…).
• testing dinamico, che tenta di sfruttare eventuali vulnerabilità. (OWASP ZAP, Arachni).
• analisi delle dipendeze (OWASP Dependency Check)
• signing del soruce code per poterne valutare l’integrità.

La telemetria deve includere anche le misure relative alla sicurezza, in modo da poter identificare violazioni con tempestività.

Alcuni esempi di metriche rilevanti per la sicurezza:

• login effettuate con successo/login fallite
• password reset
• email reset
• cambi di carta di credito.

Ad esempio, il numero di login errate puó indicare un tentativo di brute force. Lo stesso si puó applicare a livello di ambiente, misurando cose come cambi di gruppo di sicurezza, cambi di configurazione, etc…

Anche la pipeline di deploy deve essere protetta: se il rilascio in produzione è automatizzato, poter committare codice maligno equivale a poter prendere il controllo dell’applicazione. Code review, hardenizzazione della pipeline stessa, analisi statica e isolamento della pipeline mitigano il rischio.

Compliance e secutiry si basano sull’esistenza di processi dimostrabili. I framework di compliance come ITIL categorizzano i change come:

• Standard change: cambiamenti a basso rischio, che possono seguire un processo ma che possono essere pre-approvate.
• Normal changes: cambiamenti piú rischiosi che richiedono un processo di approvazione formale da parte di un Change Advisory Board. Spesso il CAB non ha idea di cosa sta approvando, cosa che porta all’esigenza di spiegazioni dettagliate che allungano il lead time.
• Urgent changes: cambiamenti d’emergenza e quindi ad alto rischio. Spesso richiedono un’approvazione dal senior management.

Uno degli obiettivi del DevOps è quello di rendere il processo di normal change fluido, cosí da poterlo applicare anche agli urgent changes.

Avere in piedi una pipeline di deployment permette di gestire la maggior parte dei change come standard change, preapprovati, pure mantenendo la necessità di tracciabilità del cambiamento.

Anche gli standard changes possono usare la pipeline di continuous deployment, dove lo strumento stesso (Jenkins, etc…) garantisce il tracciamento. I change possono essere linkati automaticamente alle richieste che li hanno generati (JIRA, etc…), a loro volta linkate al codice modificato.

Le Normal Change devono essere approvate dal CAB. Per questo le richieste devono essere ben formate (complete in tutte le parti) in modo da minimizzare i ricicli (%C/A, ricordate?). Le pipeline di CD moderne permettono di autogenerare delle Request For Change complete e accurate in modo automatico mettendo in relazione change log del VCS, Jira task e risultati del test.

L’obiettivo di un RFC è dare evidenza che la change assolverà il suo compito senza dare problemi.

La separation of duties è alla base delle pratiche di change management volte a ridurre il rischio di frodi o errori. Tuttavia, questo introduce handoff e quindi ritardi. Ove possibile, rimpiazzarla con code review.

Audit e compliance necessitano di evidenze. Il problema è che i team DevOps e la Compliance devono superare il gap conoscitivo reciproco. Un buono spunto per soddisfare le esigenze di compliance è dato dal DevOps Audit Defense Toolkit, una serie di risorse per indirizzare le reticenze della compliance.