La questione di come implementare DevOps non è nuova, ma ci sono pochi materiali di qualità. A volte si diventa vittime della pubblicità di consulenti poco brillanti, che cercano solo di vendere il loro tempo, senza preoccuparsi di come. A volte si tratta di parole vaghe e generiche su come le mega-corporazioni solcano gli spazi dell'universo. Sorge la domanda: e a noi che importa? Gentile autore, potresti elencare le tue idee in modo chiaro?
Tutto ciò deriva dal fatto che la reale pratica e comprensione delle trasformazioni culturali nelle aziende non è così diffusa. I cambiamenti culturali sono processi a lungo termine, i cui risultati non si manifesteranno né nella settimana né nel mese successivo. Abbiamo bisogno di qualcuno con una certa esperienza, che abbia visto come si siano create e distrutte aziende nel corso degli anni.
John Willis è uno dei padri del DevOps. John ha un'esperienza di decenni con un gran numero di aziende. Negli ultimi tempi, ha iniziato a notare schemi specifici che emergono nel lavoro con ciascuna di esse. Utilizzando questi archetipi, John guida le aziende verso il vero percorso di trasformazione DevOps. Maggiori dettagli su questi archetipi possono essere trovati nella traduzione del suo intervento alla conferenza DevOops 2018.
Informazioni sul relatore:
Con oltre 35 anni di esperienza nella gestione IT, ha partecipato alla creazione del predecessore di OpenCloud in Canonical, e ha preso parte a 10 startup, due delle quali sono state vendute a Dell e Docker. Attualmente è Vice President of DevOps and Digital Practices in SJ Technologies.
Di seguito, il racconto di John.
Mi chiamo John Willis e puoi trovarmi facilmente su Twitter, . Lo stesso pseudonimo che uso su Gmail e GitHub. Inoltre, puoi trovare registrazioni video delle mie presentazioni e le relative slide.
Ho molte riunioni con CIO di grandi aziende. Spesso si lamentano di non capire cosa sia il DevOps, mentre chi cerca di spiegarglielo parla di argomenti completamente diversi. Un'altra lamentela frequente è che il DevOps non funziona, anche se sembra che i direttori seguano correttamente le istruzioni ricevute. Si tratta di aziende enormi, alcune delle quali hanno più di cento anni. Parlando con loro, sono giunto alla conclusione che per molte problematiche sono più adatte soluzioni relativamente low-tech piuttosto che tecnologie avanzate. Ho passato settimane a parlare con persone di vari dipartimenti. Quello che vedete nella prima immagine del post è il risultato del mio ultimo progetto, la stanza era così dopo tre giorni di lavoro.
Che cos'è DevOps?
In effetti, se chiedi a dieci persone diverse, riceverai dieci risposte diverse. Ma ciò che è interessante è che tutte e dieci le risposte saranno corrette. Non esiste una risposta sbagliata. Mi sono occupato di DevOps in modo abbastanza approfondito per circa dieci anni, sono stato il primo americano al primo DevOpsDay. Non dirò che sono più intelligente di chiunque altro si occupi di DevOps, ma è difficile trovare qualcuno che abbia investito altrettanta determinazione. Credo che il DevOps emerga quando si connettono capitale umano e tecnologia. Spesso dimentichiamo la dimensione umana, anche se parliamo molto di varie culture.
Ora abbiamo molti dati, cinque anni di ricerca accademica, e la verifica delle teorie è stata stabilita su scala industriale. Questi studi ci dicono che, se nella cultura organizzativa si uniscono certi modelli comportamentali, si può ottenere un'accelerazione di 2000 volte. Questa accelerazione corrisponde a un miglioramento analogo nella stabilità. Questa è una misura quantitativa del vantaggio che il DevOps può offrire a qualsiasi azienda. Un paio di anni fa, ho presentato il DevOps a un CEO di una delle aziende nella lista Fortune 5000. Quando mi sono preparato per la presentazione, ero molto nervoso perché dovevo riassumere la mia esperienza pluriennale in cinque minuti.
Alla fine ho fornito la seguente definizione di DevOps: è un insieme di pratiche e modelli che permettono di trasformare il capitale umano in capitale organizzativo ad alte prestazioni. Un esempio è il modo in cui Toyota lavora da circa 50 o 60 anni.
(Qui e oltre, tali schemi sono presentati non come materiale di riferimento, ma come illustrazione. Il loro contenuto varierà per ogni nuova azienda. Tuttavia, puoi visualizzare e ingrandire l'immagine separatamente
Una delle pratiche più riuscite è value stream mapping. A questo riguardo sono stati scritti diversi buoni libri, il principale autore dei quali è Karen Martin. Tuttavia, nell'ultimo anno, sono giunto alla conclusione che anche questo approccio è troppo tecnologico. Certamente ha molti pregi e io l'ho usato molto. Ma quando il CEO ti chiede perché la sua azienda non può passare a nuovi binari, è ancora troppo presto per parlare di value stream mapping. Ci sono molte domande molto più fondamentali alle quali è necessario trovare risposta prima.
Ritengo che l'errore di molti dei miei colleghi sia che forniscono semplicemente all'azienda una guida in cinque punti e poi tornano dopo sei mesi per vedere cosa è successo. Anche un buon schema come il value stream mapping ha, per così dire, delle zone morte (blind spots). Dopo centinaia di interviste con direttori di varie aziende, ho sviluppato un certo modello che consente di scomporre il problema in componenti, e ora discuteremo ciascuno di questi componenti in ordine. Prima di applicare qualsiasi soluzione tecnologica, utilizzo questo modello, e di conseguenza tutte le mie pareti finiscono per essere coperte di schemi. Recentemente ho lavorato con un fondo comune e alla fine avevo da 100 a 150 di tali schemi.
Una cattiva cultura divora buoni approcci a colazione
Il messaggio principale è il seguente: nessun Lean, Agile, SAFE o DevOps aiuterà se la cultura organizzativa è scadente. È come immergersi in profondità senza un respiratore o operare senza una radiografia. In altre parole, parafrasando Drucker e Deming: una cattiva cultura organizzativa consumerà qualsiasi buon sistema e non si soffermerà.
Per affrontare questo problema principale, è necessario intraprendere i seguenti passaggi:
- Rendi tutto il lavoro visibile: devi rendere tutto il lavoro visibile. Non nel senso che debba necessariamente apparire su qualche schermo, ma nel senso che deve essere osservabile.
- Consolida i sistemi di gestione del lavoro: è necessario consolidare i sistemi di gestione. Nel problema della conoscenza «tribale» e della conoscenza istituzionale, nel 9 casi su 10 il collo di bottiglia è rappresentato dalle persone. Nel libro il problema era un'unica persona, Brent, che ha causato un ritardo di tre anni nel progetto. E incontro «Brent» ovunque. Per risolvere questi collo di bottiglia, utilizzo i seguenti due punti nella nostra lista.
- Teoria dei Vincoli: teoria dei vincoli.
- Collaborative hacks: hack della collaborazione.
- Toyota Kata (): non parlerò molto di Toyota Kata. Se sei interessato, sul mio GitHub quasi su ciascuno di questi argomenti.
- Organizzazione Orientata al Mercato: organizzazione orientata al mercato.
- Auditori Shift-left: audit nelle fasi iniziali del ciclo.
Inizio il lavoro con l'organizzazione in modo molto semplice: vado in azienda e parlo con i dipendenti. Come vediamo, non c'è nulla di tecnologico avanzato. Tutto ciò di cui ho bisogno è avere qualcosa su cui scrivere. Raduno diversi team in una stanza e analizzo ciò che mi dicono, in base ai miei 7 archetipi. Poi do loro un marcatore e chiedo di scrivere sulla lavagna tutto ciò che hanno detto finora a voce alta. Di solito, in questo tipo di riunioni, c'è una persona che scrive tutto, e nel miglior dei casi riesce a registrare il 10% della discussione. Con il mio metodo, riusciamo ad aumentare questa percentuale a circa il 40%.
(Questa illustrazione può essere )
Il mio approccio si basa sul lavoro di William Schneider (William Schneider, ). Alla base dell'approccio c'è l'idea che qualsiasi organizzazione possa essere suddivisa in quattro quadranti. Questo schema di solito rappresenta il risultato del lavoro con le centinaia di altri schemi che emergono durante l'analisi dell'organizzazione. Supponiamo di avere un'organizzazione con un alto livello di controllo, ma con una bassa competenza. Questa è una situazione estremamente indesiderabile: quando tutti seguono le regole, ma nessuno sa cosa fare.
Un'opzione leggermente migliore con un alto livello di controllo e competenza. Se un'azienda ha profitto, potrebbe non avere nemmeno bisogno di DevOps. È più interessante lavorare con una compagnia che ha un alto livello di controllo, bassa competenza e collaborazione, ma allo stesso tempo un alto livello di cultura (cultivation). Questo significa che ci sono molte persone in azienda che apprezzano lavorare lì, e il turnover è basso.
(Questa illustrazione può essere )
Credo che i metodi con raccomandazioni rigorosamente definite finiscano per ostacolare il raggiungimento della verità. In particolare, nel value stream mapping ci sono molte regole su come strutturare le informazioni. Nelle fasi iniziali di lavoro, di cui parlo ora, queste regole non servono a nessuno. Se una persona con un marcatore in mano descrive su una lavagna la situazione reale dell'azienda, questo è il miglior modo per comprendere lo stato delle cose. Tale informazione non arriva ai direttori. In quel momento è ridicolo interrompere la persona e dire che ha disegnato male qualche freccia. In questa fase è meglio seguire regole semplici, ad esempio: si può creare un'astrazione multilivello usando semplicemente marcatori di diversi colori.
Ripeto, niente tecnologie avanzate. Con il marcatore nero si rappresenta la realtà oggettiva, come funziona tutto. Con il marcatore rosso le persone evidenziano cosa non gli piace della situazione attuale. È importante che lo scrivano loro e non io. Quando dopo la riunione mi reco dal direttore IT, non propongo un elenco di 10 cose da correggere. Cerco di trovare connessioni tra ciò che dicono le persone dell'azienda e i modelli comprovati esistenti. Infine, con il marcatore blu vengono suggerite possibili soluzioni al problema.
(Questa illustrazione può essere )
Un esempio di tale approccio è mostrato sopra. All'inizio di quest'anno ho lavorato con una banca. I dipendenti del dipartimento di sicurezza erano convinti di non dover partecipare alle revisioni di requisiti e progettazione (design and requirement reviews).
(Questa illustrazione può essere )
Poi abbiamo parlato con persone di altri dipartimenti e abbiamo scoperto che circa 8 anni fa gli sviluppatori di software avevano escluso i dipendenti della sicurezza poiché rallentavano il lavoro. E poi questo si è trasformato in un divieto che è stato percepito come un dato di fatto. Anche se in realtà non c'era alcun divieto.
Il nostro incontro si è svolto in un modo estremamente confuso: per circa tre ore cinque diversi team non sono riusciti a spiegarmi cosa stesse succedendo tra il codice e la build. E questo dovrebbe essere, a dire il vero, la cosa più semplice. La maggior parte dei consulenti DevOps presume che questo sia già noto a tutti.
Poi, la persona responsabile della governance IT, che era rimasta in silenzio per quattro ore, ha preso la parola quando siamo arrivati al suo argomento e ci ha intrattenuto per un bel po'. Alla fine, gli ho chiesto cosa pensasse dell'incontro e non dimenticherò mai la sua risposta. Ha detto: ‘In precedenza pensavo che nella nostra banca ci fossero solo due modi di fornire software, ora so che ci sono ben cinque metodi, e di tre non avevo nemmeno idea’.
(Questa illustrazione può essere )
L'ultimo incontro in questa banca è stato con il team che si occupa del software per gli investimenti. Con loro ho scoperto che è meglio scrivere schemi con un evidenziatore su un foglio piuttosto che su una lavagna, e anche meglio che su una smartboard.
Le foto che vedete sono di come appariva la sala conferenze dell'hotel il quarto giorno del nostro incontro. E questi schemi li abbiamo utilizzati per cercare modelli, ovvero archetipi.
Quindi, faccio domande ai dipendenti, loro annotano le risposte con evidenziatori di tre colori (nero, rosso e blu). Analizzo le loro risposte alla ricerca di archetipi. Adesso discutiamo tutti gli archetipi in ordine.
1. Make All Work Visible: Rendere il lavoro visibile
Nella maggior parte delle aziende con cui lavoro, c'è una percentuale molto alta di lavoro non noto. Ad esempio, quando un dipendente si avvicina a un altro e chiede semplicemente di fare qualcosa. Nelle grandi organizzazioni, può trattarsi del 60% di lavoro non pianificato. Fino al 40% del lavoro non è affatto documentato. Se fosse Boeing, non prenderei mai più un loro aereo. Se solo metà del lavoro è documentato, non si sa se questo lavoro venga svolto correttamente o meno. Tutti gli altri metodi risultano inutili: non ha senso cercare di automatizzare qualcosa, perché il 50% noto potrebbe essere proprio la parte più coordinata e precisa del lavoro, la cui automazione non porterebbe grandi risultati, mentre il peggio si cela nella metà invisibile. Senza documentazione, è impossibile scoprire vari hack e lavori occulti, non trovare colli di bottiglia, i famosi 'Brent' di cui ho già parlato. C'è un ottimo libro di Dominica DeGrandis . Essa identifica cinque diversi «ladri di tempo» (thieves of time):
- Troppo lavoro in corso (WIP)
- Dipendenze sconosciute
- Lavoro non pianificato
- Priorità in conflitto
- Lavoro trascurato
Questa è un'analisi molto preziosa, e il libro è fantastico, ma tutti questi consigli sono inutili se si vedono solo il 50% dei dati. È possibile applicare i metodi proposti da Dominica solo quando si raggiunge un'accuratezza superiore al 90%. Parlo di situazioni in cui un supervisore dà a un subordinato un compito di 15 minuti, ma questo richiede tre giorni; ma il supervisore non sa veramente che questo subordinato dipende anche da altre quattro o cinque persone.
Il Progetto Phoenix è un racconto straordinario su un progetto che è arrivato in ritardo di tre anni. Uno dei protagonisti rischia di essere licenziato e incontra un altro personaggio, presentato come una sorta di Socrate. Quest'ultimo lo aiuta a capire cosa sia andato storto. Si scopre che in azienda c'è un amministratore di sistema di nome Brent, e tutto il lavoro, in un modo o nell'altro, passa attraverso di lui. In una delle riunioni, uno dei subordinati chiede: perché ogni compito di mezza ora richiede una settimana? La risposta è una spiegazione molto semplificata della teoria delle code e della legge di Little, e da questa spiegazione emerge che con un'occupazione del 90% ogni ora di lavoro richiede 9 ore. Ogni compito deve essere inviato a sette altre persone, quindi quest'ora si trasforma in 63 ore, 7 per 9. Dico questo per sottolineare che, per utilizzare la legge di Little o una qualsiasi teoria delle code, è necessario avere almeno dei dati.
Quindi, quando parlo di visibilità, non intendo che tutto debba essere visibile sullo schermo, ma che è necessario almeno avere dei dati. Quando ci sono, spesso si scopre che c'è un grande volume di lavoro non pianificato che, per qualche motivo, viene indirizzato a Brent, anche se non ce n'è bisogno. E Brent è un ottimo ragazzo, non dirà mai di "no", ma non racconta a nessuno come fa il suo lavoro.
Quando il lavoro è visibile, è possibile classificare i dati in modo accurato (questo è precisamente ciò che Dominika fa nella foto), applicare l'astrazione delle cinque perdite di tempo e automatizzare.
2. Consolidare i Sistemi di Gestione del Lavoro: Gestione delle Attività
Gli archetipi a cui mi riferisco costituiscono una sorta di piramide. Se il primo è eseguito correttamente, il secondo rappresenta già una sorta di sovrastruttura. Molti di essi non funzionano per le startup e devono essere considerati nel caso di grandi aziende, come quelle che compaiono nella lista Fortune 5000. Nell'ultima azienda in cui ho lavorato, c'erano 10 sistemi di tracciamento dei ticket. In un team c'era Remedy, un altro ne ha scritto uno proprio, il terzo utilizzava Jira, mentre qualcuno si arrangiava con la posta elettronica. Lo stesso problema si presenta se l'azienda ha 30 pipeline diverse, ma non ho tempo per discutere di tutti questi casi.
Discutiamo con le persone su come vengono creati i ticket, cosa succede dopo e come vengono aggirati. La cosa più interessante è che le persone nei nostri incontri parlano abbastanza sinceramente. Ho chiesto a quante persone attribuiscono 'minore / nessun impatto' ai ticket che avrebbero effettivamente dovuto avere 'impatto maggiore'. È emerso che quasi tutti lo fanno. Non mi occupo di spionaggio e cerco in ogni modo di non far emergere le persone. Quando qualcuno si confida sinceramente con me, non rivelo il nome. Ma quando praticamente tutti aggirano il sistema, significa che la sicurezza è, in sostanza, solo una facciata. Quindi non si possono trarre conclusioni dai dati di questo sistema.
Per risolvere il problema con i ticket, è necessario scegliere un unico sistema principale. Se usi Jira, deve esserci solo Jira. Se c'è un'alternativa, deve essere solo quella. Il punto è che i ticket devono essere considerati come una fase del processo di sviluppo. Ogni azione dovrebbe avere un ticket che passa attraverso il flusso di lavoro dello sviluppo. I ticket vengono inviati al team che li mostra sullo storyboard e poi se ne assume la responsabilità.
Questo riguarda tutti i reparti, incluso quello infrastrutturale e operativo. In tal caso, si può avere una rappresentazione anche solo vagamente plausibile della situazione. Quando questo processo è ben organizzato, si scopre che è facile stabilire chi è responsabile di ogni applicazione. Perché ora otteniamo non il 50%, ma il 98% dei nuovi servizi. Se questo processo principale funziona, l'accuratezza aumenta in tutto il sistema.
Pipeline dei servizi
Questo riguarda ancora una volta solo le grandi aziende. Se sei una nuova azienda in un settore nuovo, rimboccati le maniche e lavora con il tuo Travis CI o CircleCI. Per quanto riguarda le aziende Fortune 5000, è emblematico il caso di una banca in cui ho lavorato. Sono stati contattati da Google, che ha mostrato loro grafici con vecchi sistemi IBM. I ragazzi di Google hanno chiesto un po' confusi: dove sta il codice sorgente? E non c'era alcun codice sorgente, non c'era nemmeno un'interfaccia grafica. Questa è la realtà con cui devono fare i conti le grandi organizzazioni: registrazioni bancarie di 40 anni su un vecchio mainframe. Uno dei miei clienti utilizza contenitori Kubernetes con modelli Circuit Breaker, più Chaos Monkey, tutto questo per l'applicazione KeyBank. Alla fine, questi contenitori si collegano a un'applicazione COBOL.
I ragazzi di Google erano convinti che avrebbero risolto tutti i problemi del mio cliente, e poi hanno iniziato a fare domande: che cos'è l'IBM datapipe? Gli viene risposto: è un connettore. A cosa si collega? Al sistema Sperry. E cos'è? E così via. A prima vista sembra: che DevOps può esserci qui? Ma in realtà, è possibile. Esistono sistemi di consegna che consentono di trasferire il flusso di lavoro ai team coinvolti nella consegna.
3. Teoria dei vincoli: Theory of Constraints
Passiamo al terzo archetipo: conoscenza istituzionale / "tribale". Di solito, in qualsiasi organizzazione ci sono alcune persone che sanno tutto e gestiscono tutti. Sono coloro che lavorano nell'organizzazione da più tempo e che conoscono tutte le scorciatoie.
Quando questo emerge nel diagramma, evidenzio appositamente queste persone con un evidenziatore: ad esempio, si scopre che un certo Luigi è presente a tutte le riunioni. E per me è chiaro: è il Brent locale. Quando il direttore IT deve scegliere tra me in t-shirt e scarpe da ginnastica e un ragazzo vestito in abito da IBM, viene scelto me perché posso parlare al direttore di cose che l'altro ragazzo non dirà e di cui il direttore potrebbe non gradire sentire. Gli dico che nella loro azienda c'è un collo di bottiglia, una certa persona di nome Fred e un certo Luigi. Questo collo di bottiglia deve essere sbloccato, la loro conoscenza deve essere estratta in un modo o nell'altro.
Per risolvere questo tipo di problema, posso, ad esempio, proporre di utilizzare Slack. Un direttore intelligente chiederebbe: perché? Di solito, in tali casi, i consulenti DevOps rispondono: perché lo fanno tutti. Se il direttore è davvero intelligente, dirà: e quindi?. E a questo punto il dialogo si concluderà. La mia risposta è: perché in azienda ci sono quattro colli di bottiglia, Fred, Lou, Suzy e Jane. Per rendere le loro conoscenze istituzionalizzate, è necessario, prima di tutto, introdurre Slack. Tutti i vostri wiki sono completamente inutili, perché nessuno sa della loro esistenza. Se il team di ingegneri si occupa di sviluppo esterno e interno e tutti devono sapere che possono contattare il team di sviluppo esterno o il team infrastrutturale per domande. È proprio allora che Lou o Fred avranno probabilmente tempo per consultare il wiki. E poi in Slack qualcuno potrebbe chiedere perché, diciamo, il passo 5 non funziona. E allora Lou o Fred correggeranno le istruzioni nel wiki. Se si riesce a stabilire questo processo, molte altre cose saranno risolte da sole.
Ecco il mio pensiero principale: per raccomandare tecnologie avanzate, è prima necessario sistemare le basi, e ciò può essere fatto con le soluzioni low-tech descritte poco fa. Se si inizia con tecnologie avanzate senza spiegare a cosa servono, di solito non porta a buoni risultati. Uno dei nostri clienti utilizza Azure ML, una soluzione molto economica e semplice. Circa il 30% delle domande ha già ricevuto risposta dall'auto-apprendimento della macchina. E questa cosa è stata scritta da operatori che non si occupavano di data science, statistica o matematica. Questo è significativo. Il costo di tale soluzione è minimo.
4. Hacks di collaborazione: Hacking della collaborazione
Il quarto archeotipo si basa sul fatto che è necessario combattere l'isolamento. La maggior parte delle persone lo sa già: l'isolamento genera ostilità. Se ogni dipartimento è al proprio piano e le persone non si incontrano mai, se non in ascensore, l'ostilità tra di loro nasce molto facilmente. Ma se, al contrario, le persone sono nella stessa stanza, essa scompare immediatamente. Quando qualcuno lancia un'accusa generale, ad esempio, che un'interfaccia non funziona mai, non c'è niente di più semplice che decostruire tale accusa. Ai programmatori che hanno scritto l'interfaccia basta iniziare a porre domande specifiche e presto si scoprirà che, ad esempio, l'utente ha semplicemente usato male lo strumento.
Ci sono molti modi per superare l'isolamento. Una volta mi hanno chiesto di fare consulenza per una banca in Australia, ho rifiutato perché ho due figli e una moglie. Tutto ciò che potevo fare per aiutarli è stato raccomandare il graphical storytelling. È una cosa che funziona dimostrabilmente. Un altro modo interessante è quello di organizzare incontri in formato lean coffee. In una grande organizzazione è un'ottima opzione per diffondere conoscenza. Inoltre, è possibile organizzare eventi interni come devopsdays, hackathon e così via.
5. Coaching Kata
Come ho già avvertito all'inizio, oggi non ne parlerò. Se siete interessati, potete guardare .
C'è anche una buona presentazione su questo tema da parte di Mike Rother:
6. Market Oriented: organizzazione orientata al mercato
Ci sono diversi problemi qui. Ad esempio, persone "I", persone "T" e persone "E". Le persone "I" sono quelle che si occupano solo di una cosa. Di solito esistono in organizzazioni con reparti isolati. "T" è quando una persona conosce bene una cosa ma riesce anche in altre cose. "E" o addirittura "pettine" è quando una persona ha molte competenze.
Qui si applica la legge di Conway (), che in forma molto semplificata può essere espressa così: se tre team si occupano di un compilatore, alla fine otterrete un compilatore composto da tre parti. Pertanto, se all'interno di un'organizzazione c'è un alto livello di isolamento, anche Kubernetes, Circuit breaker, API extensibility e altre cose alla moda saranno organizzate come l'organizzazione stessa. Strictly secondo Conway, e in sfida a tutti voi, giovani geek.
La soluzione a questo problema è stata descritta molte volte. Ci sono, per esempio, archetipi organizzativi descritti da Fernando Fernandez. L'architettura problematica di cui ho appena parlato, con isolamento, è un'architettura funzionale-orientata. Il secondo tipo è il peggiore, l'architettura a matrice, un miscuglio dei due precedenti. Il terzo è quello che si osserva nella maggior parte delle startup, e anche le grandi aziende cercano di conformarsi a questo modello. È un'organizzazione orientata al mercato. Qui si ottimizza per ottenere il più rapido riscontro alle richieste dei clienti. Talvolta viene chiamata organizzazione piatta.
Questa struttura è descritta da molti in modi diversi, a me piace la formulazione build/run teams, in Amazon viene chiamata two pizza teams. In questa struttura, tutte le persone di tipo «I» si raggruppano attorno a un servizio e gradualmente diventano più simili a quello di tipo «T», e se viene gestito correttamente, possono anche diventare «E». Il primo controargomento qui è che in questa struttura ci sono elementi superflui. Perché avere un tester in ogni filiale, se invece si può avere un dipartimento di tester specializzati? A ciò rispondo: le spese superflue in questo caso sono il prezzo da pagare affinché in futuro l'intera organizzazione diventi di tipo «E». In tale struttura, il tester gradualmente apprende delle reti, dell'architettura, del design, ecc. Alla fine, ogni partecipante dell'organizzazione risulta essere completamente informato su tutto ciò che accade all'interno dell'organizzazione. Se desiderate sapere come funziona questo schema nell'industria, leggete .
7. Shift-left auditors: audit nelle fasi iniziali del ciclo. Osservanza delle regole di sicurezza in maniera visibile
È quando le tue azioni non superano, per così dire, il controllo dell'odore. Le persone che lavorano per te non sono stupide. Se, come nell'esempio sopra, hanno sempre indicato un impatto minore o nullo, per tre anni, e nessuno ha notato nulla, è chiaro che il sistema non funziona. Oppure un altro esempio: il consiglio per le modifiche (change advisory board), al quale ogni mercoledì bisogna presentare rapporti. Lì lavora un gruppo di persone (tra l'altro, non molto ben pagate) che in teoria dovrebbero sapere come funziona il sistema nel suo complesso. Negli ultimi cinque anni, probabilmente hai notato che i nostri sistemi sono estremamente complessi. E cinque o sei persone devono prendere decisioni riguardo a modifiche che non hanno proposto e di cui non sanno nulla.
Certo, questo approccio non funziona. Devo liberarmi di queste cose, perché queste persone non proteggono il sistema. La decisione deve prendere la squadra stessa, perché la squadra deve esserne responsabile. Altrimenti, si crea una situazione paradossale, in cui un manager, che non ha mai scritto codice nella sua vita, dice a uno sviluppatore quanto tempo dovrebbe richiedere la scrittura del codice. In una azienda per cui ho lavorato, c'erano 7 diversi consigli che esaminavano ogni modifica, incluso il consiglio di architettura, di prodotto, ecc. Esisteva anche un periodo di attesa obbligatorio, anche se un dipendente mi ha detto che in dieci anni di lavoro nessuno ha mai rifiutato, durante quel periodo obbligatorio, modifiche proposte da quella persona.
È necessario coinvolgere gli auditor, invece di allontanarli. Spiegate loro che state scrivendo contenitori binari immutabili che, se superano tutti i test, rimangono invariati per sempre. Dite loro che avete un pipeline as code e spiegate cosa significa. Mostrate loro il seguente schema: un binary immutabile in sola lettura all'interno di un contenitore che supera tutti i test di vulnerabilità; e non solo nessuno può toccarlo, ma non si tocca nemmeno il sistema che crea il pipeline, poiché viene anch'esso generato dinamicamente. Ho clienti, come Capital One, che utilizzano Vault per creare qualcosa che assomiglia a una blockchain. Non è necessario mostrare al revisore i “cooking” di Chef, è sufficiente presentare la blockchain, da cui è chiaro cosa è successo al ticket Jira nella produzione e chi è responsabile.
Secondo , creato nel 2018 da Sonatype, nel 2017 ci sono stati 87 miliardi di richieste di download di OSS.
Le perdite subite a causa delle vulnerabilità risultano essere estremamente elevate. Inoltre, le cifre che vedete sopra non includono i costi alternativi. In poche parole, cos'è il DevSecOps. Voglio subito sottolineare che non mi interessano le discussioni su quanto sia azzeccato questo nome. Il punto è che, poiché i DevOps hanno avuto un grande successo, bisogna provare ad aggiungere la sicurezza a questo pipeline.
Un esempio di tale sequenza:
Questa non è una raccomandazione per determinati prodotti, anche se a me piacciono tutti. Li ho citati come esempio per mostrare che il DevOps, fondato inizialmente sulla paradigma dell'organizzazione industriale, consente di automatizzare ogni fase del lavoro sul prodotto.
E non c'è alcuna ragione per cui non possiamo applicare lo stesso approccio alla sicurezza.
Risultato
In conclusione, vorrei dare alcuni consigli per il DevSecOps. È fondamentale includere gli auditor nel processo di creazione dei vostri sistemi e investire tempo nella loro formazione. È importante collaborare con gli auditor. Inoltre, è necessario combattere senza pietà i falsi positivi. Anche con il più costoso strumento di scansione delle vulnerabilità, si possono creare abitudini estremamente dannose per i vostri sviluppatori se non si comprende il rapporto segnale-rumore. Gli sviluppatori potrebbero essere sopraffatti dagli eventi e iniziare a ignorarli. Se avete sentito la storia di Equifax, è proprio ciò che è accaduto: il segnale di allerta massimo è stato ignorato. Inoltre, le vulnerabilità devono essere spiegate in modo che sia chiaro come influenzano il business. Ad esempio, si può dire che è la stessa vulnerabilità della storia di Equifax. Le vulnerabilità legate alla sicurezza devono essere trattate come qualsiasi altro problema software, cioè devono essere incluse nel processo generale di DevOps. Devono essere gestite tramite Jira, Kanban, ecc. Gli sviluppatori non devono pensare che qualcun altro si occupi di questo: al contrario, tutti devono assumersi la responsabilità. Infine, è importante dedicare energie alla formazione delle persone.
Link utili
Ecco alcune relazioni dalla conferenza DevOops che potrebbero essere utili:
- Sergej Berdnikov, Artyom Kalichkin — Storia di successo, o «Dev + DevOps + Ops» (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps su scala: una tragedia greca in tre atti (, )
- Aleksandr Titov, Kirill Tolkachyov —
- Timothy Lister —
Date un'occhiata a DevOops 2020 Mosca — ci sono anche molte altre cose interessanti.
Fonte: habr.com
