La domanda “come implementare il devops” esiste da anni, ma non ci sono molti materiali validi. A volte sei vittima della pubblicità di consulenti non così intelligenti che hanno bisogno di vendere il loro tempo, non importa come. A volte queste sono parole vaghe ed estremamente generiche su come le navi delle megacorporazioni solcano le distese dell'universo. La domanda sorge spontanea: cosa ci importa? Caro autore, puoi formulare chiaramente le tue idee in un elenco?
Tutto ciò deriva dal fatto che non si è accumulata molta pratica reale e comprensione degli esiti delle trasformazioni della cultura aziendale. I cambiamenti culturali sono cose a lungo termine, i cui risultati non si vedranno in una settimana o in un mese. Abbiamo bisogno di qualcuno abbastanza grande da aver visto come le aziende sono state costruite e fallite nel corso degli anni.
Giovanni Willis - uno dei padri di DevOps. John ha decenni di esperienza lavorando con un numero enorme di aziende. Recentemente, John ha iniziato a notare modelli specifici che si verificano quando si lavora con ciascuno di essi. Utilizzando questi archetipi, John guida le aziende nel vero percorso della trasformazione DevOps. Maggiori informazioni su questi archetipi nella traduzione del suo rapporto della conferenza DevOops 2018.
Informazioni sull'oratore:
Oltre 35 anni nella gestione IT, ha partecipato alla creazione del predecessore di OpenCloud presso Canonical, ha preso parte a 10 startup, due delle quali sono state vendute a Dell e Docker. Attualmente è Vice Presidente DevOps e Digital Practices presso SJ Technologies.
La prossima è la storia dal punto di vista di John.
Mi chiamo John Willis e il posto più facile per trovarmi è su Twitter, . Ho lo stesso alias su Gmail e GitHub. UN puoi trovare registrazioni video dei miei rapporti e presentazioni.
Ho molti incontri con i CIO di varie grandi aziende. Molto spesso si lamentano di non capire cosa sia DevOps e tutti coloro che provano a spiegarglielo parlano di qualcosa di diverso. Un'altra lamentela comune è che DevOps non funziona, anche se sembra che i direttori stiano facendo tutto come viene loro spiegato. Parliamo di grandi aziende che hanno più di cento anni. Dopo aver parlato con loro, sono giunto alla conclusione che per molti problemi non è l'alta tecnologia la soluzione migliore, ma piuttosto soluzioni relativamente a bassa tecnologia. Per settimane ho parlato con persone di diversi dipartimenti. Quello che vedi nella primissima immagine del post è il mio ultimo progetto, ecco come appariva la stanza dopo tre giorni di lavoro.
Cos'è DevOps?
Infatti, se chiedi a 10 persone diverse, daranno 10 risposte diverse. Ma ecco la cosa interessante: tutte e dieci queste risposte saranno corrette. Non esiste una risposta sbagliata qui. Sono stato piuttosto coinvolto in DevOps, per circa 10 anni, e sono stato il primo americano al primo DevOpsDay. Non dirò di essere più intelligente di chiunque sia coinvolto in DevOps, ma difficilmente c'è nessuno che ci abbia dedicato così tanto impegno. Credo che DevOps si verifichi quando capitale umano e tecnologia si uniscono. Spesso dimentichiamo la dimensione umana, anche se parliamo molto di tutti i tipi di culture.
Ora abbiamo molti dati, cinque anni di ricerca accademica, sperimentazione di teorie su scala industriale. Ciò che questi studi ci dicono è che se si combinano alcuni modelli comportamentali in una cultura organizzativa, è possibile ottenere un’accelerazione di 2000 volte. Questa accelerazione è accompagnata da un pari miglioramento della stabilità. Si tratta di una misurazione quantitativa del vantaggio che DevOps può apportare a qualsiasi azienda. Un paio di anni fa stavo parlando di DevOps al CEO di un'azienda Fortune 5000. Quando mi preparavo per la presentazione, ero molto nervoso perché dovevo riassumere i miei anni di esperienza in 5 minuti.
Alla fine ho dato quanto segue Definizione di DevOps: è un insieme di pratiche e modelli che consentono la trasformazione del capitale umano in capitale organizzativo ad alte prestazioni. Un esempio è il modo in cui la Toyota ha operato negli ultimi 50 o 60 anni.
(Di seguito tali diagrammi non vengono forniti come materiale di riferimento, ma come illustrazioni. Il loro contenuto sarà diverso per ogni nuova azienda. Tuttavia, l'immagine può essere visualizzata separatamente e ingrandita
Una delle pratiche di maggior successo è value stream mapping. Sono stati scritti molti buoni libri su questo argomento, il più riuscito dei quali è quello di Karen Martin. Ma nell'ultimo anno sono giunto alla conclusione che anche questo approccio è troppo tecnologico. Sicuramente ha molti vantaggi e l'ho usato molto. Ma quando il CEO ti chiede perché la sua azienda non può passare a nuovi binari, è troppo presto per parlare di mappatura del flusso di valore. Ci sono molte altre domande fondamentali a cui è necessario prima rispondere.
Penso che l’errore che fanno molti miei colleghi sia quello di dare all’azienda semplicemente una guida in cinque punti e poi tornare sei mesi dopo e vedere cosa è successo. Anche un buon schema come la mappatura del flusso di valore presenta, diciamo, punti ciechi. Dopo centinaia di interviste con direttori di varie società, ho sviluppato un certo schema che ci consente di scomporre il problema nelle sue componenti, e ora discuteremo ciascuna di queste componenti in ordine. Prima di applicare qualsiasi soluzione tecnologica, utilizzo questo modello e, di conseguenza, tutte le mie pareti sono ricoperte di diagrammi. Recentemente stavo lavorando con un fondo comune di investimento e mi sono ritrovato con 100-150 schemi di questo tipo.
La cattiva cultura mangia buoni approcci a colazione
L’idea principale è questa: nessuna misura di Lean, Agile, SAFE e DevOps sarà di aiuto se la cultura stessa dell’organizzazione è negativa. È come immergersi in profondità senza attrezzatura subacquea o operare senza radiografie. In altre parole, per parafrasare Drucker e Deming: una cattiva cultura organizzativa inghiottirà qualsiasi buon sistema senza soffocarlo.
Per risolvere questo problema principale, è necessario eseguire i seguenti passaggi:
- Rendi visibile tutto il lavoro: è necessario rendere visibile tutto il lavoro. Non nel senso che debba necessariamente essere visualizzato su qualche schermo, ma nel senso che deve essere osservabile.
- Sistemi consolidati di gestione del lavoro: i sistemi di gestione devono essere consolidati. Nel problema della conoscenza “tribale” e della conoscenza istituzionale, in 9 casi su 10 il collo di bottiglia sono le persone. Nel libro il problema è stato con una sola persona, Brent, che ha causato un ritardo del progetto di tre anni rispetto al programma. E mi imbatto in questi “Brent” ovunque. Per risolvere questi colli di bottiglia, utilizzo i prossimi due elementi del nostro elenco.
- Metodologia della teoria dei vincoli: Teoria dei Vincoli.
- Trucchi per la collaborazione: hack di collaborazione.
- Toyota Kata (): Non parlerò molto della Toyota Kata. Se interessati, sul mio github su quasi ognuno di questi argomenti.
- Organizzazione orientata al mercato: organizzazione orientata al mercato.
- Revisori dei conti spostati a sinistra: audit nelle fasi iniziali del ciclo.
Inizio a lavorare con un'organizzazione in modo molto semplice: vado in azienda e parlo con i dipendenti. Come puoi vedere, nessuna alta tecnologia. Tutto ciò di cui hai bisogno è qualcosa su cui scrivere. Raduno diversi team in una stanza e analizzo ciò che mi dicono dal punto di vista dei miei 7 archetipi. E poi do loro stessi un pennarello e chiedo loro di scrivere sulla lavagna tutto ciò che hanno detto ad alta voce finora. Di solito in questi tipi di riunioni c'è una persona che scrive tutto, e nella migliore delle ipotesi riesce a scrivere il 10% della discussione. Con il mio metodo, questa cifra può essere aumentata a circa il 40%.
(Questa illustrazione può essere visualizzata separatamente )
Il mio approccio si basa sul lavoro di William Schneider. ). L’approccio si basa sull’idea che qualsiasi organizzazione può essere divisa in quattro quadrati. Questo schema per me è solitamente il risultato del lavoro con quelle centinaia di altri schemi che emergono quando si analizza un'organizzazione. Supponiamo di avere un'organizzazione con un elevato livello di controllo, ma con scarsa competenza. Questa è un'opzione estremamente indesiderabile: quando tutti sono in linea, ma nessuno sa cosa fare.
Un’opzione leggermente migliore è quella con un alto livello di controllo e competenza. Se un’azienda del genere è redditizia, forse non ha bisogno di DevOps. È molto interessante lavorare con un'azienda che ha un alto livello di controllo, bassa competenza e cooperazione, ma allo stesso tempo un alto livello di cultura (coltivazione). Ciò significa che nell’azienda ci sono molte persone a cui piace lavorare e che il turnover della manodopera è basso.
(Questa illustrazione può essere visualizzata separatamente )
Mi sembra che i metodi con linee guida rigide finiscano per ostacolare il raggiungimento della verità. In particolare, nella mappatura del flusso di valore, ci sono molte regole su come dovrebbero essere strutturate le informazioni. Nelle prime fasi del lavoro, di cui sto parlando ora, nessuno ha bisogno di queste regole. Se una persona con un pennarello in mano descrive sul tabellone la situazione reale dell'azienda, questo è il modo migliore per comprendere la situazione. Tali informazioni non raggiungono gli amministratori. In questo momento, è stupido interrompere una persona e dire che ha disegnato una freccia in modo errato. In questa fase, è meglio utilizzare regole semplici, ad esempio: l'astrazione multilivello può essere creata semplicemente utilizzando pennarelli multicolori.
Ripeto, niente alta tecnologia. Il pennarello nero raffigura la realtà oggettiva di come funziona tutto. Con un pennarello rosso, le persone evidenziano ciò che non gli piace della situazione attuale. L'importante è che lo scrivano loro, non io. Quando vado dal CIO dopo una riunione, non offro un elenco di 10 cose che devono essere risolte. Mi sforzo di trovare connessioni tra ciò che dicono le persone in azienda e i modelli comprovati esistenti. Infine, un indicatore blu suggerisce le possibili soluzioni al problema.
(Questa illustrazione può essere visualizzata separatamente )
Un esempio di questo approccio è ora illustrato sopra. All'inizio di quest'anno ho lavorato con una banca. Gli addetti alla sicurezza erano convinti che non dovessero venire alla revisione della progettazione e dei requisiti.
(Questa illustrazione può essere visualizzata separatamente )
Poi abbiamo parlato con persone di altri dipartimenti e si è scoperto che circa 8 anni fa gli sviluppatori di software licenziavano gli addetti alla sicurezza perché rallentavano il lavoro. E poi si è trasformato in un divieto, che veniva dato per scontato. Anche se in realtà non c'era alcun divieto.
Il nostro incontro si è svolto in maniera estremamente confusa: per circa tre ore cinque diversi team non sono riusciti a spiegarmi cosa stesse succedendo tra il codice e l'assembly. E questa sembrerebbe la cosa più semplice. La maggior parte dei consulenti DevOps presuppone in anticipo che tutti lo sappiano già.
Poi, quando siamo arrivati al suo argomento, il responsabile della governance IT, che era rimasto in silenzio per quattro ore, si è risvegliato e ci ha occupato a lungo. Alla fine gli ho chiesto cosa pensasse dell'incontro e non dimenticherò mai la sua risposta. Ha detto: “Pensavo che la nostra banca avesse solo due modi per fornire software, ma ora so che ce ne sono cinque e non ne sapevo nemmeno tre”.
(Questa illustrazione può essere visualizzata separatamente )
L'ultimo incontro presso questa banca è stato con il team del software di investimento. È stato con lei che si è scoperto che scrivere diagrammi con un pennarello su un foglio di carta è meglio che su una lavagna e persino meglio che su una smartboard.
Le foto che vedete rappresentano l'aspetto della sala conferenze dell'hotel il quarto giorno del nostro incontro. E abbiamo usato questi schemi per cercare modelli, cioè archetipi.
Quindi, faccio domande ai lavoratori, loro scrivono le risposte con pennarelli di tre colori (nero, rosso e blu). Analizzo le loro risposte per archetipi. Ora discutiamo di tutti gli archetipi in ordine.
1. Rendi visibile tutto il lavoro: rendi visibile il lavoro
La maggior parte delle aziende con cui lavoro hanno una percentuale molto alta di lavoro sconosciuto. Ad esempio, questo accade quando un dipendente si avvicina a un altro e chiede semplicemente di fare qualcosa. Nelle grandi organizzazioni, potrebbe esserci il 60% di lavoro non pianificato. E fino al 40% del lavoro non è documentato in alcun modo. Se fosse stato per la Boeing non salirei mai più su un loro aereo in vita mia. Se solo la metà del lavoro è documentata, non è possibile sapere se questo lavoro viene svolto correttamente o meno. Tutti gli altri metodi si rivelano inutili: non ha senso cercare di automatizzare nulla, perché il 50% noto può essere la parte più coerente e chiara del lavoro, la cui automazione non darà grandi risultati, e tutto il peggio le cose sono nella metà invisibile. In assenza di documentazione, è impossibile trovare tutti i tipi di hack e lavori nascosti, né trovare colli di bottiglia, quegli stessi "Brent" di cui ho già parlato. C'è un libro meraviglioso di Dominica DeGrandis . Lei rivela cinque diverse "fughe di tempo" (ladri di tempo):
- Troppo lavoro in corso (WIP)
- Dipendenze sconosciute
- Lavoro non pianificato
- Priorità contrastanti
- Lavoro trascurato
Questa è un'analisi molto preziosa e il libro è fantastico, ma tutti questi consigli sono inutili se è visibile solo il 50% dei dati. I metodi proposti da Dominica possono essere utilizzati se si ottiene una precisione superiore al 90%. Sto parlando di situazioni in cui un capo affida a un subordinato un compito di 15 minuti, ma gli impiega tre giorni; ma il capo non sa veramente che questo subordinato dipende da altre quattro o cinque persone.
The Phoenix Project è una storia meravigliosa su un progetto arrivato tre anni troppo tardi. Uno dei personaggi rischia il licenziamento per questo motivo e incontra un altro personaggio che viene presentato come una specie di Socrate. Aiuta a capire cosa è andato storto esattamente. Si scopre che l'azienda ha un amministratore di sistema, il cui nome è Brent, e tutto il lavoro in qualche modo passa attraverso lui. In uno degli incontri, a uno dei subordinati viene chiesto: perché ogni compito di mezz'ora richiede una settimana? La risposta è una presentazione molto semplificata della teoria delle code e della legge di Little, e in questa presentazione risulta che con un'occupazione del 90%, ogni ora di lavoro dura 9 ore. Ogni attività deve essere inviata ad altre sette persone, quindi quell'ora diventa 63 ore, 7 volte 9. Quello che sto dicendo è che per poter utilizzare la Legge di Little o qualsiasi teoria complessa delle code, devi almeno avere dati.
Quindi quando parlo di visibilità non intendo che tutto sia sullo schermo, ma che almeno tu abbia dei dati. Quando lo fanno, spesso si scopre che c’è una grande quantità di lavoro non pianificato che in qualche modo viene inviato al Brent quando non ce n’è bisogno. E Brent è un bravo ragazzo, non dice mai di no, ma non racconta a nessuno come fa il suo lavoro.
Quando il lavoro è visibile, i dati possono essere classificati con precisione (è quello che sta facendo Dominika nella foto), si può applicare l'astrazione delle cinque perdite temporali e si può applicare l'automazione.
2. Consolidare i sistemi di gestione del lavoro: gestione delle attività
Gli archetipi di cui sto parlando sono una sorta di piramide. Se il primo è eseguito correttamente, il secondo è già una sorta di componente aggiuntivo. Molti di questi non funzionano per le startup, devono essere tenuti a mente per le aziende più grandi come Fortune 5000. L'ultima azienda per cui ho lavorato aveva 10 sistemi di biglietteria. Un team aveva Remedy, un altro ha scritto una sorta di proprio sistema, un terzo ha utilizzato Jira e alcuni si sono accontentati della posta elettronica. Lo stesso problema si presenta se l’azienda ha 30 condutture diverse, ma non ho tempo per discutere tutti questi casi.
Discuto con le persone esattamente come vengono creati i ticket, cosa succede loro dopo e come vengono aggirati. La cosa più interessante è che le persone ai nostri incontri parlano in modo abbastanza sincero. Ho chiesto quante persone mettono "impatto minore/nessun impatto" sui biglietti a cui in realtà dovrebbe essere assegnato "impatto maggiore". Si è scoperto che quasi tutti lo fanno. Non mi impegno nella denuncia e cerco in ogni modo possibile di non identificare le persone. Quando mi confessano sinceramente qualcosa, non lo smaschero. Ma quando quasi tutti aggirano il sistema, significa che tutta la sicurezza è essenzialmente una facciata. Pertanto non è possibile trarre alcuna conclusione dai dati di questo sistema.
Per risolvere il problema dei ticket, è necessario scegliere un sistema principale. Se usi Jira, tienilo Jira. Se esiste un'alternativa, lascia che sia l'unica. La conclusione è che i ticket dovrebbero essere visti come un altro passo nel processo di sviluppo. Ogni azione deve avere un ticket, che deve fluire attraverso il flusso di lavoro di sviluppo. I ticket vengono inviati al team, che li pubblica sullo storyboard e se ne assume la responsabilità.
Questo vale per tutti i dipartimenti, comprese le infrastrutture e le operazioni. In questo caso è possibile farsi almeno un'idea plausibile dello stato delle cose. Una volta stabilito questo processo, diventa improvvisamente facile identificare chi è responsabile di ciascuna richiesta. Perché ora riceviamo non il 50%, ma il 98% dei nuovi servizi. Se questo processo principale funziona, la precisione migliora in tutto il sistema.
Gasdotti di servizi
Anche questo vale solo per le grandi aziende. Se sei una nuova azienda in un nuovo campo, rimboccati le maniche e lavora con il tuo Travis CI o CircleCI. Quando si tratta di aziende Fortune 5000, un esempio calzante è accaduto alla banca in cui lavoravo. Google si è rivolto a loro e gli sono stati mostrati i diagrammi dei vecchi sistemi IBM. I ragazzi di Google hanno chiesto confusi: dov'è il codice sorgente per questo? Ma non esiste un codice sorgente, nemmeno una GUI. Questa è la realtà con cui le grandi organizzazioni devono fare i conti: documenti bancari vecchi di 40 anni su un vecchio mainframe. Uno dei miei clienti utilizza contenitori Kubernetes con pattern Circuit Breaker, oltre a Chaos Monkey, il tutto per l'applicazione KeyBank. Ma questi contenitori alla fine si connettono a un'applicazione COBOL.
I ragazzi di Google erano completamente fiduciosi che avrebbero risolto tutti i problemi del mio cliente, e poi hanno iniziato a fare domande: cos'è IBM datapipe? Viene detto loro: questo è un connettore. A cosa si collega? Al sistema Sperry. E cos'è quello? E così via. A prima vista sembra: che tipo di DevOps può esserci? Ma in realtà è possibile. Esistono sistemi di consegna che ti consentono di consegnare il flusso di lavoro ai team di consegna.
3. Teoria dei Vincoli: Teoria dei Vincoli
Passiamo al terzo archetipo: la conoscenza istituzionale/"tribale". Di norma, in ogni organizzazione ci sono diverse persone che sanno tutto e gestiscono tutto. Questi sono quelli che fanno parte dell'organizzazione da più tempo e che conoscono tutte le soluzioni alternative.
Quando questo appare nel diagramma, cerco specificamente queste persone con un pennarello: ad esempio, si scopre che un certo Lou è presente a tutte le riunioni. E mi è chiaro: questo è il Brent locale. Quando il CIO sceglie tra me in maglietta e scarpe da ginnastica e il ragazzo dell'IBM in giacca e cravatta, vengo scelto perché posso dire al direttore cose che l'altro non dirà e che al direttore potrebbe non piacere sentire . Dico loro che il collo di bottiglia nella loro azienda è qualcuno di nome Fred e qualcuno di nome Lou. Questo collo di bottiglia deve essere sciolto, la loro conoscenza deve essere ottenuta da loro in un modo o nell'altro.
Per risolvere questo tipo di problema posso, ad esempio, suggerire di utilizzare Slack. Un regista intelligente si chiederà: perché? Tipicamente, in questi casi, i consulenti DevOps rispondono: perché lo fanno tutti. Se il regista è davvero intelligente, dirà: e allora? Ed è qui che finisce il dialogo. E la mia risposta è: perché ci sono quattro colli di bottiglia nell'azienda, Fred, Lou, Susie e Jane. Per istituzionalizzare la propria conoscenza, bisogna prima introdurre Slack. Tutti i tuoi wiki sono una totale assurdità perché nessuno sa della loro esistenza. Se il team di ingegneri è coinvolto nello sviluppo front-end e back-end e tutti devono sapere che possono contattare il team di sviluppo front-end o il team dell'infrastruttura per eventuali domande. Questo sarà il momento in cui Lou o Fred avranno probabilmente il tempo di unirsi al wiki. E poi in Slack qualcuno potrebbe chiedersi perché, ad esempio, il passaggio 5 non funziona e poi Lou o Fred correggeranno le istruzioni sul wiki. Se stabilisci questo processo, molte cose andranno a posto da sole.
Questo è il mio punto principale: per consigliare qualsiasi tecnologia elevata, è necessario prima metterne in ordine le basi, e questo può essere fatto con le soluzioni a bassa tecnologia appena descritte. Se inizi con le alte tecnologie e non spieghi perché sono necessarie, di norma non finisce bene. Uno dei nostri clienti utilizza Azure ML, una soluzione molto economica e semplice. Circa il 30% delle loro domande hanno ricevuto risposta dalla stessa macchina di autoapprendimento. E questa cosa è stata scritta da operatori che non si occupavano di data science, statistica o matematica. Questo è significativo. Il costo di una tale soluzione è minimo.
4. Hack di collaborazione: hack di collaborazione
Il quarto archetipo è la necessità di combattere l’isolamento. La maggior parte delle persone lo sa già: l’isolamento genera ostilità. Se ogni dipartimento si trova al proprio piano e le persone non si intersecano tra loro in alcun modo, tranne che nell'ascensore, allora l'ostilità tra loro sorge molto facilmente. Ma se, al contrario, le persone si trovano nella stessa stanza, se ne va immediatamente. Quando qualcuno lancia un'accusa generale, ad esempio, questa o quella interfaccia non funziona mai, non c'è niente di più facile per decostruire tale accusa. I programmatori che hanno scritto l'interfaccia devono solo iniziare a porre domande specifiche e presto diventerà chiaro che, ad esempio, l'utente ha semplicemente utilizzato lo strumento in modo errato.
Esistono molti modi per superare l’isolamento. Una volta mi è stato chiesto di fare consulenza per una banca in Australia, ma mi sono rifiutato perché ho due figli e una moglie. Tutto quello che potevo fare per aiutarli era consigliare la narrazione grafica. Questo è qualcosa che ha dimostrato di funzionare. Un altro modo interessante sono le riunioni di caffè snelle. In una grande organizzazione, questa è un'opzione eccellente per diffondere la conoscenza. Inoltre, puoi organizzare devopsday interni, hackathon e così via.
5. Allenare il Kata
Come avevo avvertito all’inizio, non ne parlerò oggi. Se sei interessato puoi dare un'occhiata .
C'è anche un bel discorso su questo argomento di Mike Rother:
6. Market Oriented: organizzazione orientata al mercato
Ci sono diversi problemi qui. Ad esempio, le persone "I", le persone "T" e le persone "E". Le persone “io” sono quelle che fanno solo una cosa. In genere esistono in organizzazioni con dipartimenti isolati. "T" è quando una persona è brava in una cosa ma è brava anche in altre cose. "E" o anche "pettine" indica quando una persona ha molte abilità.
La legge di Conway funziona qui (), che nella forma più semplificata può essere espresso come segue: se tre squadre lavorano sul compilatore, il risultato sarà un compilatore di tre parti. Pertanto, se è presente un elevato livello di isolamento all'interno di un'organizzazione, anche Kubernetes, l'interruttore automatico, l'estensibilità dell'API e altre cose fantasiose in questa organizzazione saranno organizzate allo stesso modo dell'organizzazione stessa. Rigorosamente secondo Conway e per far dispetto a tutti voi giovani smanettoni.
La soluzione a questo problema è stata descritta molte volte. Esistono, ad esempio, gli archetipi organizzativi descritti da Fernando Fernandez. L’architettura problematica di cui ho appena parlato, con l’isolamento, è un’architettura orientata alle funzioni. Il secondo tipo è il peggiore, l'architettura a matrice, un pasticcio delle altre due. Il terzo è ciò che si osserva nella maggior parte delle startup e anche le grandi aziende stanno cercando di eguagliare questo tipo. È un'organizzazione orientata al mercato. Qui ottimizziamo per ottenere la risposta più rapida alle richieste dei clienti. Questa è talvolta chiamata organizzazione piatta.
Molte persone descrivono questa struttura in modi diversi, mi piace la formulazione costruire/gestire team, su Amazon lo chiamano due squadre di pizzaioli. In questa struttura, tutte le persone di tipo “I” sono raggruppate attorno a un servizio, e gradualmente si avvicinano al tipo “T”, e se c'è la giusta gestione, possono anche diventare “E”. La prima controargomentazione è che una tale struttura contiene elementi non necessari. Perché hai bisogno di un tester in ogni dipartimento se puoi avere un dipartimento speciale di tester? Al che rispondo: i costi aggiuntivi in questo caso sono il prezzo perché l'intera organizzazione diventi in futuro di tipo “E”. In questa struttura, il tester apprende gradualmente le reti, l'architettura, il design, ecc. Di conseguenza, ogni partecipante all'organizzazione è pienamente consapevole di tutto ciò che accade nell'organizzazione. Se vuoi sapere come funziona questo schema nell'industria, leggi .
7. Revisori di turno a sinistra: audit all'inizio del ciclo. Rispetto delle norme di sicurezza in esposizione
Questo è quando le tue azioni non superano il test dell'olfatto, per così dire. Le persone che lavorano per te non sono stupide. Se, come nell’esempio sopra, hanno avuto un impatto minimo/nessun ovunque, e questo è durato tre anni, e nessuno si è accorto di nulla, allora tutti sanno perfettamente che il sistema non funziona. O un altro esempio: un comitato consultivo sul cambiamento, in cui i rapporti devono essere presentati ogni, diciamo, mercoledì. C'è un gruppo di persone che lavora lì (non molto ben pagato, tra l'altro) che, in teoria, dovrebbe sapere come funziona il sistema nel suo insieme. E negli ultimi cinque anni probabilmente avrete notato che i nostri sistemi sono incredibilmente complessi. E cinque o sei persone devono prendere una decisione su un cambiamento che non hanno fatto e di cui non sanno nulla.
Naturalmente, questo approccio non funziona. Devo sbarazzarmi di queste cose perché queste persone non proteggono il sistema. La decisione deve essere presa dalla squadra stessa, perché la squadra deve esserne responsabile. Altrimenti, si verifica una situazione paradossale quando un manager che non ha mai scritto codice in vita sua dice al programmatore quanto tempo dovrebbe impiegare per scrivere il codice. Un'azienda con cui ho lavorato aveva 7 diversi comitati che esaminavano ogni modifica, incluso un comitato di architettura, un comitato di prodotto, ecc. C'era addirittura un periodo di attesa obbligatorio, anche se un dipendente mi ha detto che in dieci anni di lavoro nessuno aveva mai rifiutato una modifica apportata da questa persona durante questo periodo obbligatorio.
I revisori devono essere invitati ad unirsi a noi e non a liberarsene. Di' loro che scrivi contenitori binari immutabili che, se superano tutti i test, rimangono immutabili per sempre. Dì loro che hai una pipeline come codice e spiega cosa significa. Mostra loro il seguente schema: un file binario immutabile di sola lettura in un contenitore che supera tutti i test di vulnerabilità; e poi non solo nessuno lo tocca, ma non tocca nemmeno il sistema che crea la pipeline, visto che anche questa viene creata dinamicamente. Ho clienti, Capital One, che utilizzano Vault per creare qualcosa come una blockchain. L'auditor non ha bisogno di mostrare “ricette” di Chef, è sufficiente mostrare la blockchain, da cui risulta chiaro cosa è successo al ticket Jira in produzione e chi ne è responsabile.
Secondo , creato nel 2018 da Sonatype, nel 2017 ci sono state 87 miliardi di richieste di download di OSS.
Le perdite subite a causa delle vulnerabilità sono proibitive. Inoltre, le cifre che vedete qui sopra non includono i costi opportunità. Cos'è DevSecOps in poche parole? Dico subito che non mi interessa parlare del successo di questo nome. Il punto è che, poiché DevOps ha avuto così tanto successo, dovremmo provare ad aggiungere sicurezza a quella pipeline.
Un esempio di questa sequenza:
Questa non è una raccomandazione per prodotti specifici, anche se mi piacciono tutti. Li ho citati come esempio per dimostrare che DevOps, inizialmente basato sul paradigma organizzativo dell'industria, consente di automatizzare ogni fase di lavoro su un prodotto.
E non c'è motivo per cui non potremmo adottare lo stesso approccio alla sicurezza.
risultato
In conclusione, fornirò alcuni suggerimenti per DevSecOps. È necessario includere gli auditor nel processo di creazione dei sistemi e dedicare tempo alla loro formazione. È necessario collaborare con i revisori dei conti. Successivamente, è necessario condurre una lotta assolutamente spietata contro i falsi positivi. Anche con lo strumento di scansione delle vulnerabilità più costoso, puoi finire per creare pessime abitudini tra i tuoi sviluppatori se non sai qual è il tuo rapporto segnale-rumore. Gli sviluppatori saranno sopraffatti dagli eventi e li elimineranno semplicemente. Se avete sentito parlare della storia di Equifax, è più o meno quello che è successo lì, dove il livello di allerta più alto è stato ignorato. Inoltre, le vulnerabilità devono essere spiegate in modo da rendere chiaro il loro impatto sull’azienda. Ad esempio, si potrebbe dire che si tratta della stessa vulnerabilità della storia di Equifax. Le vulnerabilità della sicurezza dovrebbero essere trattate allo stesso modo degli altri problemi software, ovvero dovrebbero essere incluse nel processo DevOps complessivo. Devi lavorare con loro tramite Jira, Kanban, ecc. Gli sviluppatori non dovrebbero pensare che qualcun altro lo farà, al contrario, dovrebbero farlo tutti. Infine, è necessario spendere energie nella formazione delle persone.
Link utili
Ecco alcuni interventi della conferenza DevOops che potresti trovare utili:
- Sergey Berdnikov, Artyom Kalichkin - Storia di successo, o "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps su larga scala: una tragedia greca in tre atti (, )
- Aleksandr Titov, Kirill Tolkachev -
- Timothy Lister-
Guardare dentro DevOops 2020 Mosca - ci sono anche molte cose interessanti.
Fonte: habr.com