La questione «come implementare DevOps» è in circolazione da anni, ma le risorse valide non sono molte. A volte si diventa vittime della pubblicità di consulenti non particolarmente intelligenti, che cercano di vendere il loro tempo, indipendentemente da come. Talvolta si tratta di discorsi vaghi e estremamente generali su come le navi delle mega-corporazioni solcano l'universo. Nasce la domanda: e a noi che importa? Stimato autore, potrebbe elencare chiaramente le sue idee?
Tutto ciò deriva dal fatto che non c'è molta pratica reale e comprensione dei risultati delle trasformazioni culturali aziendali. I cambiamenti nella cultura richiedono tempo, e i risultati non si vedranno né dopo una settimana né dopo un mese. Abbiamo bisogno di qualcuno abbastanza esperto, che abbia visto come sono nate e cadute le aziende nel corso degli anni.
John Willis è uno dei padri fondatori di DevOps. John ha alle spalle decenni di lavoro con un numero enorme di aziende. Recentemente, ha iniziato a notare modelli specifici che emergono nel lavoro con ciascuna di esse. Utilizzando questi archetipi, John guida le aziende verso un'autentica trasformazione DevOps. Maggiori dettagli su questi archetipi sono disponibili nella traduzione del suo intervento alla conferenza DevOops 2018.
Informazioni sul relatore:
Oltre 35 anni di esperienza nella gestione IT, ha contribuito alla creazione del predecessore di OpenCloud in Canonical, ha partecipato 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, la narrazione da parte di John.
Mi chiamo John Willis, e il modo più semplice per trovarmi è su Twitter, . Ho lo stesso pseudonimo anche su Gmail e GitHub. A puoi trovare le registrazioni video delle mie presentazioni e le diapositive associate.
Ho molte conversazioni con CIO di grandi aziende. Spesso si lamentano di non capire cosa sia DevOps, mentre chi cerca di spiegarlo parla di argomenti estranei. Un'altra lamentela comune è che DevOps non funziona, anche se i direttori seguono le istruzioni. Si parla di grandi aziende, con oltre cento anni di storia. Dopo aver parlato con loro, ho concluso che per molti problemi, le soluzioni più appropriate sono le meno tecnologiche. Ho passato settimane semplicemente parlando con persone di diversi reparti. Quello che vedi nell'immagine all'inizio del post è il mio ultimo progetto, la stanza aveva questo aspetto dopo tre giorni di lavoro.
Che cos'è il DevOps?
Infatti, se chiedi a 10 persone diverse, ognuna darà una risposta diversa. Ma c'è una cosa interessante: tutte queste dieci risposte saranno corrette. Non esiste una risposta sbagliata. Mi sono immerso nel DevOps per circa 10 anni, sono stato il primo americano al primo DevOpsDay. Non dirò di essere più intelligente di tutti gli altri che lavorano nel DevOps, ma è difficile trovare qualcuno che abbia dedicato così tanto impegno. Credo che il DevOps emerga quando si combinano capitale umano e tecnologia. Spesso dimentichiamo il fattore umano, anche se parliamo tanto di vari tipi di cultura.
Ora abbiamo una grande quantità di dati, cinque anni di studi accademici, e la verifica delle teorie è diventata una pratica scalabile. Questi studi ci dicono che se in una cultura organizzativa si combinano alcuni modelli comportamentali, si può ottenere un'accelerazione di 2000 volte. Questa accelerazione corrisponde a un miglioramento equivalente della stabilità. Questa è una misurazione quantitativa del vantaggio che DevOps può offrire a qualsiasi azienda. Alcuni anni fa, ho parlato di DevOps con il CEO di una società della lista Fortune 5000. Quando mi stavo preparando per la presentazione, ero molto nervoso, perché dovevo riassumere anni di esperienza in 5 minuti.
Alla fine ho dato la seguente definizione di DevOps: è un insieme di pratiche e modelli che consentono di trasformare il capitale umano in capitale organizzativo altamente produttivo. Un esempio è come Toyota lavora da ultimo 50 o 60 anni.
(Da qui in poi, tali schemi non sono presentati come materiali di riferimento, ma come illustrazioni. Il loro contenuto varierà per ogni nuova azienda. Tuttavia, puoi visualizzare e ingrandire l'immagine separatamente
Una delle pratiche di maggior successo è la value stream mapping. Sono stati scritti diversi buoni libri su questo argomento, il più famoso dei quali è di Karen Martin. Tuttavia, nell'ultimo anno ho concluso che persino questo approccio è troppo tecnologico. Ha indubbiamente molti vantaggi, di cui ho beneficiato ampiamente. Ma quando l'amministratore delegato ti chiede perché la sua azienda non riesca a passare a nuove ferrovie, è ancora presto per parlare di value stream mapping. Ci sono molte domande molto più fondamentali a cui è necessario rispondere in anticipo.
A mio avviso, l'errore di molti dei miei colleghi è che forniscono semplicemente all'azienda una guida in cinque punti e poi tornano dopo sei mesi per vedere cosa è successo. Anche uno schema buono come il value stream mapping ha, diciamo così, zone morte (blind spots). Dopo centinaia di interviste con direttori di diverse aziende, ho sviluppato un certo schema che consente di suddividere il problema in componenti, e ora discuteremo ciascuna di queste componenti in ordine. Prima di applicare qualsiasi soluzione tecnologica, utilizzo questo schema, e alla fine ho le pareti coperte di diagrammi. Di recente ho lavorato con un fondo comune e alla fine ho avuto 100-150 di questi diagrammi.
Una cattiva cultura divora buoni approcci a colazione.
Il concetto principale è questo: nessun Lean, Agile, SAFE o DevOps funzionerà se la cultura stessa dell'organizzazione è scarsa. È come tuffarsi in profondità senza un respiratore o operare senza una radiografia. In altre parole, parafrasando Drucker e Deming: una cattiva cultura organizzativa inghiottirà qualsiasi buon sistema e non si soffermerà.
Per risolvere questo problema principale, è necessario compiere i seguenti passi:
- Rendere tutto il lavoro visibile: è necessario rendere visibile tutto il lavoro. Non nel senso che debba necessariamente essere visualizzato su uno schermo, ma nel senso che deve essere osservabile.
- Consolidare i sistemi di gestione del lavoro: è necessario consolidare i sistemi di management. Nel problema della conoscenza 'tribale' e della conoscenza istituzionale, nel 9 casi su 10 il collo di bottiglia sono le persone. Nel libro la questione riguardava una sola persona, Brent, che ha causato un ritardo nel progetto di tre anni. E persone come questo ‘Brent’ le incontro ovunque. Per risolvere questi colli di bottiglia, utilizzo i seguenti due punti nella nostra lista.
- Metodologia della Teoria dei Vincoli: teoria dei vincoli.
- Trucchi di collaborazione: hack della collaborazione.
- Toyota Kata (): Non parlerò molto di Toyota Kata. Se sei interessato, sul mio GitHub su quasi ciascuno di questi temi.
- Organizzazione orientata al mercato: organizzazione orientata al mercato.
- Auditor sinistra: audit nelle fasi iniziali del ciclo.
Inizio il lavoro con un'organizzazione in modo molto semplice: vado in azienda e parlo con i dipendenti. Come si può vedere, nessuna alta tecnologia. Tutto ciò che serve è avere qualcosa su cui scrivere. Riunisco alcune squadre in una stanza e analizzo ciò che mi dicono, dal punto di vista dei miei 7 archetipi. Poi do loro un marcatore e chiedo di esporre sulla lavagna tutto ciò che hanno detto finora ad alta voce. Di solito in questi incontri c'è una persona che prende appunti, e nel migliore dei casi riesce a registrare il 10% della discussione. Con il mio metodo, riesco a far salire questa cifra a circa il 40%.
(Questa illustrazione può essere )
Il mio approccio si basa sul lavoro di William Schneider (William Schneider, ). L'idea alla base dell'approccio è che qualsiasi organizzazione può essere suddivisa in quattro quadranti. Questo schema di solito è il risultato del lavoro con le centinaia di altri schemi che sorgono durante l'analisi dell'organizzazione. Supponiamo che abbiamo un'organizzazione con un alto livello di controllo, ma con una bassa competenza. Questo è un’opzione estremamente indesiderabile: quando tutti seguono le regole, ma nessuno sa cosa fare.
Una situazione leggermente migliore è quella con un alto livello sia di controllo che di competenza. Se un'azienda di questo tipo è profittevole, potrebbe darsi che non abbia nemmeno bisogno di DevOps. È molto più interessante lavorare con un'azienda che ha un alto livello di controllo, bassa competenza e collaborazione, ma con un alto livello di cultura (cultivation). Questo significa che in azienda ci sono molte persone che amano lavorare lì, e il turnover del personale è basso.
(Questa illustrazione può essere )
Ritengo che i metodi con linee guida rigide 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 del lavoro, di cui parlo ora, queste regole non servono a nessuno. Se una persona con un evidenziatore in mano descrive la situazione reale di un'azienda su una lavagna, questo è il miglior modo per capire lo stato delle cose. Queste informazioni non arrivano ai direttori. In quel momento, sarebbe sciocco interrompere qualcuno dicendo che ha disegnato male una freccia. In questa fase, è meglio seguire semplici regole, come: è possibile creare un'astrazione multilivello usando semplicemente evidenziatori di colori diversi.
Ripeto, niente tecnologie avanzate. La realtà oggettiva viene rappresentata con un evidenziatore nero, come funziona tutto. Con un evidenziatore rosso le persone segnalano 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 legami tra ciò che dicono le persone dell'azienda e i modelli consolidati esistenti. Infine, con un evidenziatore blu vengono suggerite possibili soluzioni ai problemi.
(Questa illustrazione può essere )
Un esempio di questo approccio è mostrato sopra. All'inizio di quest'anno ho lavorato con una banca. I dipendenti del dipartimento di sicurezza erano convinti che non potessero partecipare alle revisioni di requisiti e progetti (design and requirement reviews).
(Questa illustrazione può essere )
Poi abbiamo parlato con persone di altri dipartimenti e si è scoperto che circa 8 anni fa gli sviluppatori di software avevano messo da parte i dipendenti della sicurezza perché rallentavano il lavoro. E poi questo si è trasformato in un divieto considerato una realtà. Anche se in realtà non c'era alcun divieto.
La nostra riunione ha preso un percorso estremamente confuso: per circa tre ore cinque team diversi non sono riusciti a spiegarmi cosa stesse succedendo tra il codice e la build. E questa, a prima vista, sembrerebbe la cosa più semplice. La maggior parte dei consulenti DevOps presume in anticipo che questo sia già noto a tutti.
Poi, la persona responsabile della governance IT, che era rimasta in silenzio per quattro ore, si è improvvisamente animata quando abbiamo toccato il suo argomento, e ci ha tenuto occupati per un periodo piuttosto lungo. Alla fine, gli ho chiesto cosa pensasse dell'incontro, e non dimenticherò mai la sua risposta. Ha detto: «Prima pensavo che nella nostra banca ci fossero solo due modi di consegna del software, ma ora so che ce ne sono cinque, e di tre nemmeno sospettavo».
(Questa illustrazione può essere )
L'ultima riunione in questa banca è stata con il team che si occupa del software per gli investimenti. È proprio con loro che si è scoperto che scrivere schemi con un evidenziatore su un foglio è meglio che farlo su una lavagna, e persino meglio che su una smartboard.
Le foto che vedete mostrano come appariva la sala conferenze dell'hotel nel quarto giorno della nostra riunione. E questi schemi li abbiamo utilizzati per cercare modelli, ovvero archetipi.
Quindi, faccio domande ai dipendenti, e loro annotano le risposte con evidenziatori di tre colori (nero, rosso e blu). Analizzo le loro risposte in cerca 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, esiste una percentuale molto alta di lavoro sconosciuto. Ad esempio, quando un dipendente si avvicina a un altro e gli chiede semplicemente di fare qualcosa. Nelle grandi organizzazioni, può arrivare fino al 60% del lavoro non pianificato. E fino al 40% del lavoro non è documentato in alcun modo. Se fosse Boeing, non prendere più mai un loro aereo. Se viene documentata solo metà del lavoro, non si sa se quel lavoro venga eseguito correttamente o meno. Tutti gli altri metodi si rivelano inutili: non ha senso cercare di automatizzare qualcosa, perché il 50% noto potrebbe essere proprio la parte più coordinata e chiara del lavoro, la cui automazione non porta grandi risultati, mentre la parte peggiore è nella metà invisibile. Senza documentazione, è impossibile scoprire vari tipi di hack e lavoro nascosto, individuare colli di bottiglia, quei famosi «Brent» di cui ho già parlato. C'è un ottimo libro di Dominica DeGrandis . Identifica cinque diverse «fughe di tempo» (thieves of time):
- Troppo lavoro in corso (WIP)
- Dipendenze sconosciute
- Lavoro non pianificato
- Priorità conflittuali
- Lavoro trascurato
Questa è un'analisi molto preziosa e il libro è straordinario, ma tutti questi consigli sono inutili se si vede solo il 50% dei dati. I metodi suggeriti da Dominika possono essere applicati solo se si raggiunge una precisione superiore al 90%. Parlo di situazioni in cui un manager assegna un compito di 15 minuti a un subordinato, ma questo impiega tre giorni; e il manager in realtà non sa che quel subordinato dipende anche da altre quattro o cinque persone.
Phoenix Project è una storia affascinante su un progetto che ha subito un ritardo di tre anni. Uno dei personaggi rischia di essere licenziato a causa di ciò e incontra un altro personaggio, che è presentato come una sorta di Socrate. Questi 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 passa, in un modo o nell'altro, attraverso di lui. In una delle riunioni, a uno dei subordinati viene chiesto: perché ogni compito di mezz'ora impiega una settimana? La risposta è una sintesi molto semplificata della teoria delle code e della legge di Little, e in questa sintesi emerge che con una saturazione del 90%, ogni ora di lavoro richiede 9 ore. Ogni incarico deve essere inviato ad altre sette persone, quindi quell'ora diventa 63 ore, 7 moltiplicato per 9. Lo dico per sottolineare che, per utilizzare la legge di Little o qualsiasi altra teoria complessa sulle code, almeno dei dati devono essere disponibili.
Quindi, quando parlo di visibilità, non mi riferisco al fatto che tutto debba essere sullo schermo, ma che sia necessario almeno avere dei dati. Quando questi dati ci sono, spesso si scopre che c'è un grande volume di lavoro non pianificato che viene in qualche modo indirizzato a Brent, anche se non c'è bisogno di farlo. E Brent è un ottimo ragazzo, non dirà mai "no", ma non racconta a nessuno come svolge il suo lavoro.
Quando il lavoro è visibile, è possibile classificare i dati con attenzione (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 dei compiti
Gli archetipi di cui parlo rappresentano una sorta di piramide. Se il primo è eseguito correttamente, il secondo è una sorta di sovrastruttura. Molti di questi non funzionano per le startup; è necessario tenerli a mente nel caso di grandi aziende, come quelle che rientrano 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 ha sviluppato un proprio sistema, un terzo utilizzava Jira, qualcun altro si limitava a usare la posta elettronica. La stessa problematica si presenta se in azienda ci sono 30 pipeline diverse, ma non ho tempo per discutere tutte queste situazioni.
Parlo con le persone su come vengono creati i ticket, cosa succede loro dopo, come vengono elusi. La cosa interessante è che le persone alle nostre riunioni parlano abbastanza sinceramente. Ho chiesto quante persone assegnano "minor / no impact" a ticket che in realtà avrebbero dovuto ricevere "major impact". È emerso che quasi tutti lo fanno. Non mi occupo di fare la spia e cerco di non identificare le persone. Quando qualcuno mi confida sinceramente qualcosa, non rivelo chi è. Ma quando praticamente tutti eludono il sistema, ciò significa che tutta 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 sistema principale. Se usate Jira, che sia solo Jira. Se c'è un'altra alternativa, che sia solo quella. L'importante è che i ticket siano considerati come un ulteriore passo del processo di sviluppo. Ogni azione deve avere un ticket che deve passare attraverso il flusso di lavoro di sviluppo. I ticket vengono inviati al team, che li espone sullo storyboard, e poi ne assume la responsabilità.
Questo riguarda tutti i reparti, incluso quello infrastrutturale e operativo. In questo modo, è possibile avere una rappresentazione credibile della situazione. Quando questo processo è ben articolato, si scopre che è facile stabilire chi è responsabile per ciascuna applicazione. Perché ora riceviamo non il 50%, ma il 98% dei nuovi servizi. Se questo processo principale funziona, la precisione aumenta in tutto il sistema.
Pipeline dei servizi
Questo vale principalmente per le grandi imprese. Se sei una nuova azienda in un settore nuovo, rimboccati le maniche e lavora con Travis CI o CircleCI. Per quanto riguarda le aziende Fortune 5000, c'è un caso emblematico che mi riguarda, quello di una banca dove ho lavorato. Sono stati visitati da Google, e hanno mostrato loro dei grafici delle vecchie sistemi IBM. I ragazzi di Google hanno chiesto, con un certo stupore: "E dove si trova il codice sorgente?". Ma non c'è codice sorgente, non c'è nemmeno un'interfaccia grafica. Questa è la realtà con cui devono confrontarsi le grandi organizzazioni: registrazioni bancarie di 40 anni su un antico mainframe. Uno dei miei clienti utilizza contenitori Kubernetes con schemi Circuit Breaker, oltre a Chaos Monkey, il tutto per l'applicazione di KeyBank. Tuttavia, questi contenitori alla fine si collegano a un'applicazione in COBOL.
I ragazzi di Google erano certi di poter risolvere tutti i problemi del mio cliente, e poi hanno iniziato a fare domande: cos'è un IBM datapipe? E gli rispondono: è un connettore. A cosa si collega? Al sistema Sperry. E cos'è questo? E così via. A prima vista si potrebbe pensare: dove sarebbe il DevOps qui? Ma in realtà è possibile. Esistono sistemi di consegna che permettono di trasferire il flusso di lavoro ai team responsabili della consegna.
3. Teoria dei vincoli: Theory of Constraints
Passiamo al terzo archetipo: la conoscenza istituzionale / "tribale". Di solito, all'interno di un'organizzazione ci sono alcune persone che sanno tutto e dirigono tutti. Sono coloro che sono nell'organizzazione da più tempo e conoscono tutte le scorciatoie.
Quando questo emerge nel diagramma, evidenzio appositamente queste persone con un evidenziatore: ad esempio, si scopre che un certo Lu è presente in tutte le riunioni. E per me è chiaro: questo è il nostro Brent locale. Quando il direttore IT deve scegliere tra me in t-shirt e scarpe da ginnastica e un ragazzo vestito in giacca e cravatta di IBM, mi scelgono perché posso raccontare al direttore cose che l'altro ragazzo non dirà e che potrebbero metterlo a disagio. Gli dico che nella loro azienda c'è un collo di bottiglia, rappresentato da qualcuno di nome Fred e da qualcuno di nome Lu. Questo collo di bottiglia deve essere sciolto, e in un modo o nell'altro il loro sapere deve essere estratto.
Per affrontare questo tipo di problema, posso, ad esempio, suggerire di utilizzare Slack. Un direttore sveglio potrebbe chiedere: perché? Di solito in questi casi i consulenti DevOps rispondono: perché tutti lo fanno. Se il direttore è veramente sveglio, dirà: e allora? E a quel punto il dialogo finisce. E io rispondo: perché ci sono quattro colli di bottiglia in azienda, Fred, Lu, Suzy e Jane. Per trasformare la loro conoscenza in qualcosa di istituzionale, bisogna, innanzitutto, introdurre Slack. Tutti i vostri wiki sono una completa sciocchezza, perché nessuno sa che esistono. Se il team di ingegneria si occupa sia dello sviluppo esterno che interno, tutti devono sapere che possono rivolgersi al team di sviluppo esterno o al team dell'infrastruttura con domande. Solo in quel momento, probabilmente Lu o Fred troveranno il tempo per collegarsi al wiki. E poi in Slack qualcuno potrà chiedere perché, ad esempio, il passo 5 non funziona. E allora Lu o Fred correggeranno le istruzioni nel wiki. Se questo processo viene sistematizzato, molte cose si sistemeranno da sole.
Qui sta la mia idea principale: per raccomandare tecnologie avanzate, bisogna prima sistemare le fondamenta per queste, e questo può essere fatto con le soluzioni a bassa tecnologia di cui abbiamo appena parlato. Iniziare con tecnologie avanzate senza spiegare perché siano necessarie, di solito non porta a buone conclusioni. Uno dei nostri clienti utilizza Azure ML, una soluzione molto economica e semplice. Circa il 30% delle domande riceve già risposte dalla macchina auto-apprendente. E questa cosa è stata scritta da operatori che non si occupavano di data science, statistica o matematica. Questo è emblematico. Il costo di tale soluzione è minimo.
4. Hacks di collaborazione: Collaboration hacks
Il quarto archetipo riguarda la necessità di combattere l'isolamento. La maggior parte delle persone lo sa già: l'isolamento genera ostilità. Se ogni dipartimento è sul proprio piano, e le persone non si incrociano affatto, se non in ascensore, l'ostilità tra loro nasce molto facilmente. Se, al contrario, le persone si trovano nella stessa stanza, l'ostilità svanisce immediatamente. Quando qualcuno lancia un'accusa generale, ad esempio, che un certo interfaccia non funziona mai, non c'è niente di più facile che deconstruire tale accusa. Gli sviluppatori che hanno creato l'interfaccia devono solo iniziare a fare domande specifiche, e ben presto emergerà che, ad esempio, l'utente ha semplicemente usato lo strumento in modo incorretto.
Ci sono molti modi per superare l'isolamento. Una volta mi hanno chiesto di consigliare una banca in Australia, ma ho rifiutato perché ho due figli e una moglie. L'unica cosa che ho potuto fare è stata raccomandare loro il graphical storytelling. È un metodo che funziona dimostrabilmente. Un altro modo interessante sono gli incontri in formato lean coffee. In una grande organizzazione, è un'ottima opzione per diffondere le conoscenze. Inoltre, è possibile organizzare devopsdays interni, hackathon e così via.
5. Coaching Kata
Come ho già avvertito all'inizio, oggi non ne parlerò. Se siete interessati, potete dare un'occhiata a .
C'è anche una buona conferenza su questo tema da parte di Mike Rother:
6. Market Oriented: organizzazione orientata al mercato
Ci sono diverse problematiche. Ad esempio, le persone «I», le persone «T» e le persone «E». Le persone «I» sono quelle che si occupano solo di un'unica cosa. Esistono solitamente in organizzazioni con reparti isolati. «T» indica una persona che conosce bene un aspetto, ma eccelle anche in altre aree. «E» o persino «pettine» si riferisce a una persona con molte competenze.
Qui si applica la legge di Conway (), che in termini molto semplici si può riassumere così: se tre squadre si occupano di un compilatore, alla fine si otterrà un compilatore composto da tre parti. Pertanto, se all'interno dell'organizzazione c'è un alto livello di isolamento, anche Kubernetes, Circuit breaker, API extensibility e altre tendenze saranno strutturati in modo simile all'organizzazione stessa. Rigorosamente secondo Conway e a dispetto di voi, giovani geek.
La soluzione a questo problema è stata descritta molte volte. Ci sono, ad esempio, archetipi organizzativi descritti da Fernando Fernandez. L'architettura problematica di cui stavo parlando, caratterizzata dall'isolamento, è un'architettura funzionalmente orientata. Il secondo tipo, il peggiore, è l'architettura a matrice, in cui c'è un miscuglio dei due precedenti. Il terzo è quello che si osserva nella maggior parte delle startup, e le grandi aziende stanno cercando di adattarsi a questo modello. È un'organizzazione orientata al mercato. Qui si ottimizza per avere la risposta più rapida alle richieste dei clienti. A volte si parla di organizzazione piatta.
Questa struttura è descritta in vari modi, a me piace la formulazione build/run teams, in Amazon si parla di two pizza teams. In questa struttura tutte le persone tipo «I» si raggruppano attorno a un servizio e gradualmente si avvicinano al tipo «T», e se c'è una buona gestione, possono diventare persino «E». Il primo controargomento è che in una tale struttura ci sono elementi superflui. Perché è necessario avere un tester in ogni reparto, quando si può avere un dipartimento di tester dedicato? A ciò rispondo: le spese superflue in questo caso sono il prezzo da pagare affinché in futuro tutta l'organizzazione diventi tipo «E». In una tale struttura, il tester impara gradualmente a conoscere reti, architettura, progettazione, ecc. Alla fine, ogni membro dell'organizzazione è completamente informato su tutto ciò che accade nell'organizzazione. Se volete sapere come funziona questo modello nell'industria, leggete .
7. Shift-left auditors: auditing nelle fasi iniziali del ciclo. Conformità alle normative di sicurezza in modo evidente
Questo accade quando le vostre azioni non superano, per così dire, la prova dell'olfatto. Le persone che lavorano con voi non sono stupide. Se, come nell'esempio precedente, hanno sempre segnalato minor/no impact, e questo è continuato per tre anni senza che nessuno se ne accorgesse, tutti sanno perfettamente che il sistema non funziona. O un altro esempio: il comitato consultivo per i cambiamenti (change advisory board), dove ogni mercoledì devono essere presentati report. Qui lavora un gruppo di persone (tra l'altro, non molto ben pagate), che in teoria dovrebbero sapere come funziona il sistema nel suo complesso. E negli ultimi cinque anni, probabilmente avete notato che i nostri sistemi sono incredibilmente complessi. E cinque o sei persone devono prendere una decisione riguardo a un cambiamento che non hanno introdotto e di cui non sanno nulla.
Certo, questo approccio non funziona. Devo separarmi da queste cose perché queste persone non proteggono il sistema. La decisione dovrebbe essere presa dal team stesso, perché il team deve esserne responsabile. Altrimenti, si crea una situazione paradossale in cui un manager, che non ha mai scritto codice in vita sua, dice a un programmatore quanto tempo dovrebbe richiedere scrivere il codice. In un'azienda con cui ho lavorato, c'erano 7 diversi consigli che esaminavano ogni modifica, incluso il consiglio di architettura, sui prodotti, ecc. C'era persino un periodo di attesa obbligatorio, anche se un dipendente mi ha detto che in dieci anni di lavoro nessuno aveva mai rifiutato modifiche proposte da quella persona durante quel periodo obbligatorio.
Gli auditor devono essere chiamati a collaborare, non trascurati. Spiegategli che state scrivendo contenitori binari immutabili che, se superano tutti i test, rimangono invariati per sempre. Spiegategli che avete un pipeline as code e chiarite cosa significa. Mostrate loro il seguente schema: un binary immutabile di sola lettura in un contenitore che supera tutti i test sulle vulnerabilità; e poi non solo nessuno lo tocca — non si tocca nemmeno il sistema che crea il pipeline, poiché anch'esso viene creato dinamicamente. Ho clienti, come Capital One, che utilizzano Vault per creare qualcosa di simile a una blockchain. Non è necessario mostrare le 'ricette' di Chef all'auditor, basta mostrare la blockchain, da cui risulta chiaramente cosa è successo con il ticket Jira in produzione e chi è responsabile.
Secondo , creato nel 2018, Sonatype ha registrato 87 miliardi di richieste di download di OSS nel 2017.
Le perdite causate dalle vulnerabilità si rivelano estremamente elevate. Inoltre, i numeri che vedete sopra non includono i costi alternativi. In poche parole, cosa significa DevSecOps. Vorrei subito dire che non mi interessa il dibattito su quanto sia opportuno questo nome. Il punto è che, poiché i DevOps sono stati molto efficaci, vale la pena provare ad aggiungere la sicurezza a quel pipeline.
Un esempio di tale sequenza:
Questo non è un invito a determinati prodotti, anche se mi piacciono tutti. Li ho menzionati come esempio per dimostrare che il DevOps, originariamente basato sulla paradigma dell'organizzazione industriale, consente di automatizzare ogni fase del lavoro sul prodotto.
E non c'è motivo per cui non potremmo applicare lo stesso approccio alla sicurezza.
Risultato
In conclusione, darò alcuni suggerimenti per DevSecOps. È necessario coinvolgere gli auditor nel processo di creazione dei vostri sistemi, dedicare tempo alla loro formazione. È fondamentale collaborare con gli auditor. Inoltre, è indispensabile affrontare in modo spietato i falsi positivi. Anche con lo strumento di scansione delle vulnerabilità più costoso, si possono creare abitudini estremamente dannose per i vostri sviluppatori, se non si comprende il rapporto segnale-rumore. Gli sviluppatori si ritroveranno sommersi dagli eventi e inizieranno a eliminarli. Se avete sentito parlare della storia di Equifax, è proprio questo che è successo, dove è stato ignorato un segnale di massimo pericolo. Inoltre, è necessario spiegare le vulnerabilità in modo chiaro su come influenzano il business. Ad esempio, si può dire che questa è la stessa vulnerabilità della storia di Equifax. Le vulnerabilità relative alla sicurezza devono essere trattate come qualsiasi altro problema software, e quindi devono essere integrate nel processo DevOps generale. Devono essere gestite tramite Jira, Kanban, ecc. Gli sviluppatori non devono pensare che qualcun altro si occuperà di questo — al contrario, devono occuparsene tutti. Infine, è fondamentale investire nella formazione delle persone.
Link utili
Ecco alcune presentazioni dalla conferenza DevOops che potrebbero esservi utili:
- Sergei Berdnikov, Artyom Kalichkin — Una storia di successo, ovvero "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps su larga scala: una tragedia greca in tre atti (, )
- Alexander Titov, Kirill Tolkachev —
- Timothy Lister —
Dai un'occhiata a DevOops 2020 Mosca — ci sono molte altre cose interessanti.
Fonte: habr.com
