A quistione "cumu implementà i devops" hè stata dipoi anni, ma ùn sò micca assai boni materiali. Calchì volta vi cadete vittima di publicità da cunsultanti micca cusì intelligenti chì anu bisognu di vende u so tempu, ùn importa micca cumu. Calchì volta si tratta di parole vagi, estremamente generali nantu à cumu e navi di megacorporazioni arananu e estensioni di l'universu. Ci hè a quistione: chì ci importa à noi? Caru autore, pudete formulà chjaramente e vostre idee in una lista?
Tuttu chistu vene da u fattu chì micca assai pratica reale è capiscitura di u risultatu di trasfurmazioni di a cultura di a cumpagnia anu accumulatu. I cambiamenti in a cultura sò cose à longu andà, i risultati di quale ùn pareranu micca in una settimana o un mesi. Avemu bisognu di qualcunu abbastanza vechja per avè vistu cumu l'imprese sò state custruite è falluti annantu à l'anni.
Ghjuvanni Willis - unu di i babbi di DevOps. Ghjuvanni hà decennii di sperienza à travaglià cù un gran numaru di cumpagnie. Ricertamenti, Ghjuvanni hà cuminciatu à nutà mudelli specifichi chì si facenu quandu u travagliu cù ognunu di elli. Utilizendu questi archetipi, Ghjuvanni guida l'imprese nantu à a vera strada di a trasformazione DevOps. Leghjite più nantu à questi archetipi in a traduzzione di u so rapportu da a cunferenza DevOops 2018.
À propositu di u parlante:
Più di 35 anni in a gestione di l'informatica, hà participatu à a creazione di u predecessore di OpenCloud à Canonical, hà participatu à 10 startups, duie chì sò state vendute à Dell è Docker. Attualmente hè vicepresidentu di DevOps è pratiche digitali in SJ Technologies.
Dopu hè a storia da u puntu di vista di Ghjuvanni.
Mi chjamu John Willis è u locu più faciule per truvà mi hè in Twitter, . Aghju u listessu alias in Gmail è GitHub. A pudete truvà video registrazioni di i mo rapporti è presentazioni per elli.
Aghju parechje riunioni cù CIO di diverse grande cumpagnie. Spessu si lamentanu ch'elli ùn capiscenu micca ciò chì DevOps hè, è tutti quelli chì prova di spiegà à elli parlanu di qualcosa di sfarente. Un'altra lagnanza cumuni hè chì DevOps ùn funziona micca, ancu se pare chì i direttori facenu tuttu ciò chì li spiega. Si parla di grande cumpagnie chì anu più di centu anni. Dopu avè parlatu cun elli, aghju ghjuntu à a cunclusione chì, per parechji prublemi, ùn hè micca l'alta tecnulugia chì hè megliu adattatu, ma solu solu solu tecnulugia relativamente bassa. Per settimane aghju parlatu solu cù persone di diversi dipartimenti. Ciò chì vede in a prima foto in u post hè u mo ultimu prughjettu, questu hè ciò chì pareva a stanza dopu à trè ghjorni di travagliu.
Cosa hè DevOps?
Infatti, se dumandate à 10 persone diverse, daranu 10 risposte diverse. Ma quì hè l'interessante: tutte e dece risposte seranu currette. Ùn ci hè micca una risposta sbagliata quì. Eru abbastanza prufonda in DevOps, per circa 10 anni, è era u primu americanu à u primu DevOpsDay. Ùn diceraghju micca chì sò più intelligente di tutti quelli chì participanu à DevOps, ma ùn ci hè quasi nimu chì hà spesu tantu sforzu nantu à questu. Credu chì DevOps si trova quandu u capitale umanu è a tecnulugia si riuniscenu. Spessu si scurdemu di a dimensione umana, ancu s'ellu si parla assai di ogni tipu di culture.
Avà avemu assai dati, cinque anni di ricerca accademica, teste di teorie à scala industriale. Ciò chì sti studii ci dicenu hè chì se combina qualchi mudelli di cumportamentu in una cultura di l'urganizazione, pudete ottene una accelerazione di 2000x. Questa accelerazione hè cumminata da una migliione uguale in a stabilità. Questa hè una misurazione quantitativa di u benefiziu chì DevOps pò purtà à qualsiasi cumpagnia. Un paru d'anni fà, parlava di DevOps à u CEO di una cumpagnia di Fortune 5000. Quandu mi preparava per a presentazione, era assai nervoso perchè aghju avutu a riassuntu i mo anni di sperienza in 5 minuti.
In fine, aghju datu i seguenti Definizione di DevOps: Hè un inseme di pratiche è mudelli chì permettenu a trasfurmazioni di u capitale umanu in un capitale di l'urganizazione d'altu rendiment. Un esempiu hè a manera chì Toyota hà operatu per l'ultimi 50 o 60 anni.
(In seguitu, tali diagrammi ùn sò micca furniti cum'è materiale di riferimentu, ma cum'è illustrazioni. U so cuntenutu differiscerà per ogni nova cumpagnia. Tuttavia, a stampa pò esse vista separatamente è ingrandata.
Unu di i più riesciuti tali pratiche hè valutazione di viaghju di valore. Parechje boni libri sò stati scritti annantu à questu, i più riesciuti di quale sò di Karen Martin. Ma annantu à l'annu passatu, aghju ghjuntu à a cunclusione chì ancu questu approcciu hè troppu high-tech. Certamente hà assai vantaghji è l'aghju utilizatu assai. Ma quandu u CEO vi dumanda perchè a so cumpagnia ùn pò micca cambià à novi rails, hè troppu prestu per parlà di a mappa di u flussu di valore. Ci hè parechje dumande assai più fundamentali chì deve esse prima risposta.
Pensu chì l'errore chì parechji di i mo culleghi facenu hè chì solu dà à a cumpagnia una guida di cinque punti è poi tornanu sei mesi dopu è vede ciò chì hè accadutu. Ancu un bonu schema cum'è a mappatura di u flussu di valore hà, per dì, punti cecu. Dopu à centinaie d'entrevista cù i direttori di diverse cumpagnie, aghju sviluppatu un certu mudellu chì ci permette di scumpressà u prublema in i so cumpunenti, è avà discuteremu ogni unu di sti cumpunenti in ordine. Prima di applicà ogni suluzione tecnologica, aghju utilizatu stu mudellu, è in u risultatu, tutti i mo mura sò cuparti di diagrammi. Ricertamenti aghju travagliatu cù un mutuale è aghju finitu cù 100-150 tali schemi.
A mala cultura manghja boni approcci per u colazione
L'idea principale hè questu: nisuna quantità di Lean, Agile, SAFE è DevOps aiuterà se a cultura di l'urganizazione stessu hè male. Hè cum'è immersione in prufundità senza scuba gear o operante senza una radiografia. In altre parolle, per parafrasà Drucker è Deming: una cattiva cultura di l'urganisazione inghiottirà ogni bonu sistema senza affucà.
Per risolve stu prublema principali, avete bisognu di piglià i seguenti passi:
- Fate visibili tutti i travaglii: avete bisognu di fà vede tuttu u travagliu. Micca in u sensu chì deve esse necessariamente affissatu nantu à qualchì schermu, ma in u sensu chì deve esse osservatu.
- Sistemi di gestione di u travagliu cunsolidati: i sistemi di gestione deve esse cunsulidati. In u prublema di a cunniscenza "tribale" è a cunniscenza istituzionale, in 9 casi fora di 10 u bottleneck hè persone. In u libru u prublema era cù una sola persona, Brent, chì hà fattu u prugettu per esse trè anni in ritardu. È aghju incuntratu in questi "Brents" in ogni locu. Per risolve questi colli di bottiglia, aghju utilizatu i prossimi dui elementi nantu à a nostra lista.
- Metodologia di Teoria di i Limitazioni: teoria di i limiti.
- Hacks di cullaburazione: pirate di cullaburazione.
- Toyota Kata (): Ùn parlà micca assai di a Toyota Kata. Sè interessatu, nantu à u mo github nantu à quasi tutti questi temi.
- Urganizazione Orientata à u Mercatu: urganizazione orientata à u mercatu.
- Auditori di turnu à manca: auditu in i primi fasi di u ciculu.
Accuminciau à travaglià cù una urganizazione assai simplice: vai à a cumpagnia è parle cù l'impiegati. Comu pudete vede, ùn hè micca alta tecnulugia. Tuttu ciò chì avete bisognu hè qualcosa per scrive. Aghju riunitu parechje squadre in una stanza è analizà ciò chì mi dicenu da a perspettiva di i mo archetipi 7. E poi li dugnu un marcatu stessu è li dumandu di scrive nantu à a lavagna tuttu ciò chì anu dettu à voce alta finu à avà. Di solitu in questi tipi di riunioni ci hè una persona chì scrive tuttu, è in u megliu pò scrive u 10% di a discussione. Cù u mo metudu, sta figura pò esse elevata à circa 40%.
(Questa illustrazione pò esse vista separatamente )
U mo approcciu hè basatu annantu à u travagliu di William Schneider. ). L'approcciu hè basatu annantu à l'idea chì ogni urganizazione pò esse divisa in quattru quadrati. Stu schema per mè hè di solitu u risultatu di travaglià cù quelli cintunari di altri schemi chì nascenu quandu analizà una urganizazione. Suppone chì avemu una urganizazione cù un altu livellu di cuntrollu, ma cù una cumpetenza bassa. Questa hè una opzione estremamente indesiderata: quandu tutti sò toeing the line, ma nimu ùn sà chì fà.
Una opzione ligeramente megliu hè una cun un altu livellu di cuntrollu è cumpetenza. Se una tale cumpagnia hè prufittuosa, allora forsi ùn hà micca bisognu di DevOps. Hè più interessante di travaglià cù una cumpagnia chì hà un altu livellu di cuntrollu, pocu cumpetenza è cooperazione, ma à u stessu tempu un altu livellu di cultura (cultivazione). Questu significa chì a cumpagnia hà assai persone chì piace à travaglià quì è u turnover di u travagliu hè bassu.
(Questa illustrazione pò esse vista separatamente )
Mi pare chì i metudi cù linee guida rigide finiscinu in u modu di ottene a verità. In a mappa di u flussu di valore in particulare, ci sò parechje regule riguardanti cumu l'infurmazione deve esse strutturata. In i primi tempi di u travagliu, chì parlu avà, nimu hà bisognu di sti reguli. Se una persona cù un marcatore in e so mani descrive a situazione reale in a cumpagnia nantu à u bordu, questu hè u megliu modu per capisce u statu di l'affari. Tali informazioni ùn ghjunghje micca à i direttori. À questu mumentu, hè stupidu per interrompe a persona è dicenu chì hà tiratu un tipu di freccia incorrectamente. À questu stadiu, hè megliu aduprà regule simplici, per esempiu: l'astrazione multi-livellu pò esse creata simpliciamente cù marcatori multicolori.
Ripecu, senza alta tecnulugia. U marcatu neru riprisenta a realità objetiva di cumu tuttu funziona. Cù un marcatu rossu, a ghjente marca ciò chì ùn li piace micca di u statu attuale di l'affari. Hè impurtante chì scrivenu questu, micca mè. Quandu anderaghju à u CIO dopu una reunione, ùn offre micca una lista di 10 cose chì deve esse riparatu. Mi sforzu di truvà cunnessione trà ciò chì a ghjente in a cumpagnia dicenu è mudelli pruvati esistenti. Infine, un marcatore blu suggerisce pussibuli suluzioni à u prublema.
(Questa illustrazione pò esse vista separatamente )
Un esempiu di stu approcciu hè avà illustratu sopra. À u principiu di questu annu aghju travagliatu cù un bancu. A ghjente di sicurità ci era cunvinta chì ùn deve micca vene à cuncepimentu è esigenza recensioni.
(Questa illustrazione pò esse vista separatamente )
E dopu avemu parlatu cù e persone di altri dipartimenti è hè risultatu chì circa 8 anni fà, i sviluppatori di software licenziavanu i travagliadori di sicurità perchè rallentavanu u travagliu. E poi si trasformò in una pruibizione, chì hè stata presa per scontru. Ancu s'è in realtà ùn ci era micca pruibitu.
A nostra riunione hà procedutu in una manera estremamente confusa: per circa trè ore, cinque squadre diverse ùn mi pudianu spiegà ciò chì succede trà u codice è l'assemblea. È questu pare esse a cosa più simplice. A maiò parte di i cunsultanti di DevOps assumanu in anticipu chì tutti sanu digià questu.
Allora a persona incaricata di a governanza di l'IT, chì era in silenziu per quattru ore, hà subitu à a vita quandu avemu ghjuntu à u so tema, è ci hà occupatu per un bellu pezzu. À a fine l'aghju dumandatu ciò chì pensava di a riunione, è ùn aghju mai scurdatu di a so risposta. Ellu disse: "Pensu chì u nostru bancu avia solu duie manere di furnisce u software, ma avà sò chì sò cinque, è ùn ne sapia mancu trè".
(Questa illustrazione pò esse vista separatamente )
L'ultima riunione in questu bancu hè stata cù a squadra di u software d'investimentu. Hè stata cun ella chì hà risultatu chì scrive diagrammi cù un marcatore nantu à un fogliu di carta hè megliu cà nantu à una tavula, è ancu megliu cà nantu à un smartboard.
I ritratti chì vede sò ciò chì a sala di cunferenza di l'hotel pareva u quartu ghjornu di a nostra riunione. E avemu usatu sti schemi per circà mudelli, vale à dì, archetipi.
Allora, dumandu e dumande à i travagliadori, scrivenu e risposte cù marcatori di trè culori (negru, rossu è blu). Analizà e so risposte per archetipi. Avà discutemu tutti l'archetipi in ordine.
1. Fate tutti i travaglii visibili: rende u travagliu visibili
A maiò parte di l'imprese cù u travagliu anu un percentinu assai altu di travagliu scunnisciutu. Per esempiu, questu hè quandu un impiigatu vene à un altru è solu dumanda à fà qualcosa. In i grandi urganisazioni, pò esse 60% di travagliu imprevisu. È finu à u 40% di u travagliu ùn hè micca documentatu in ogni modu. S'ellu fussi Boeing, ùn aghju mai più imbarcatu in u so aviò in a mo vita. Se solu a mità di u travagliu hè documentatu, ùn hè micca cunnisciutu se stu travagliu hè fattu bè o micca. Tutti l'altri metudi sò inutili - ùn ci hè nunda di pruvà à automatizà qualcosa, perchè u 50% cunnisciutu pò esse a parte più coherente è chjara di u travagliu, l'automatizazione di quale ùn darà micca grandi risultati, è tuttu u peghju. e cose sò in a mità invisibile. In l'absenza di ducumentazione, hè impussibile di truvà ogni tipu di pirate è travaglii nascosti, per micca di truvà buttiglii, quelli assai "Brents" chì aghju digià parlatu. Ci hè un libru maravigliu di Dominica DeGrandis . Ella rivela cinque diverse "fughe di tempu" (ladri di tempu):
- Troppu travagliu in prucessu (WIP)
- Dipendenze scunnisciute
- U travagliu micca pianificatu
- Priorità cunflitti
- Travagliu trascuratu
Questu hè un analisi assai preziosu è u libru hè grande, ma tutti questi cunsiglii sò inùtuli se solu 50% di e dati sò visibili. I metudi pruposti da Dominica ponu esse aduprati se una precisione di sopra à 90% hè ottenuta. Parlu di situazioni induve un capu dà à un subordinatu un compitu di 15 minuti, ma si piglia trè ghjorni; ma u capu ùn sà micca veramente chì stu subordinatu hè dipendente di quattru o cinque altre persone.
U Prughjettu Phoenix hè una storia maravigliosa nantu à un prughjettu chì era trè anni troppu tardi. Unu di i caratteri face u licenziamentu per quessa, è si scontra cù un altru caratteru chì hè prisentatu cum'è una spezia di Socrate. Ellu aiuta à capisce ciò chì hè esattamente sbagliatu. Risulta chì a cumpagnia hà un amministratore di sistema, chì si chjama Brent, è tuttu u travagliu passa per ellu. À una di e riunioni, unu di i subordinati hè dumandatu: perchè ogni travagliu di meza ora dura una settimana? A risposta hè una presentazione assai simplificata di a teoria di a fila è a lege di Little, è in questa presentazione si trova chì à 90% d'occupazione, ogni ora di travagliu dura 9 ore. Ogni compitu deve esse mandatu à sette altre persone, cusì chì l'ora diventa 63 ore, 7 volte 9. Ciò chì dicu hè chì per aduprà a Legge di Little o qualsiasi teoria cumplessa di fila, almenu avete bisognu di dati.
Allora quandu parlu di visibilità, ùn vogliu micca dì chì tuttu hè nantu à u screnu, ma chì avete almenu dati. Quandu si facenu, spessu si trova chì ci hè una quantità assai grande di travagliu imprevisu chì hè in qualchì modu mandatu à Brent quandu ùn ci hè micca bisognu. È Brent hè un grande tippu, ùn dicerà mai di nò, ma ùn dice à nimu cumu faci u so travagliu.
Quandu u travagliu hè visibile, i dati ponu esse classificatu bè (hè ciò chì Dominika face in a photo), l'astrazione di e cinque fughe di tempu pò esse applicata, è l'automatizazione pò esse applicata.
2. Consolidate i Sistemi di Gestione di u travagliu: Task Management
L'archetipi chì parlu sò una spezia di piramide. Se u primu hè fattu bè, u sicondu hè digià un tipu di add-on. Parechje di questi ùn sò micca travagliatu per startups, anu da esse tenuti in mente per cumpagnie più grande cum'è a Fortune 5000. L'ultima cumpagnia chì aghju travagliatu hà avutu 10 sistemi di ticketing. Una squadra hà avutu Remedy, un altru hà scrittu un tipu di u so propiu sistema, un terzu hà utilizatu Jira, è alcuni anu fattu per email. U listessu prublemu si nasce si a cumpagnia hà 30 pipelines differenti, ma ùn aghju micca tempu per discutiri tutti questi casi.
Discutemu cù e persone esattamente cumu si creanu i biglietti, ciò chì li succede dopu, è cumu si sò aggirati. A cosa più interessante hè chì e persone à e nostre riunioni parlanu assai sinceramente. Aghju dumandatu quante persone mettenu "impattu minore / senza impattu" nantu à i biglietti chì anu da esse datu "impattu maiò". Hè risultatu chì quasi tutti facenu questu. Ùn aghju micca ingaghjatu in a denuncia è pruvate in ogni modu pussibule per ùn identificà e persone. Quandu mi cunfessu sinceramente qualcosa, ùn aghju micca dà a persona. Ma quandu quasi tutti passanu u sistema, significa chì tutta a sicurità hè essenzialmente a finestra. Per quessa, nisuna cunclusioni pò esse trattu da i dati di stu sistema.
Per risolve u prublema di u bigliettu, avete bisognu di sceglie un sistema principale. Se utilizate Jira, mantene a Jira. Se ci hè una alternativa, ch'ella sia l'unica. U fondu hè chì i biglietti deve esse vistu cum'è un altru passu in u prucessu di sviluppu. Ogni azzione deve avè un bigliettu, chì deve passà per u flussu di travagliu di sviluppu. I biglietti sò mandati à a squadra, chì li mette nantu à u storyboard è poi piglia a rispunsabilità per elli.
Questu hè applicatu à tutti i dipartimenti, cumprese l'infrastruttura è l'operazioni. In questu casu, hè pussibule di furmà almenu una idea plausibile di u statu di l'affari. Una volta chì stu prucessu hè stabilitu, subitu diventa faciule per identificà quale hè rispunsevule per ogni applicazione. Perchè avà avemu ricevutu micca 50%, ma 98% di novi servizii. Se stu prucessu core funziona, allora a precisione migliora in tuttu u sistema.
Pipeline di servizii
Questu novu s'applicà solu à e grandi corporazioni. Sè vo site una nova cumpagnia in un novu campu, arrotolate e maniche è travaglià cù u vostru Travis CI o CircleCI. Quandu si tratta di cumpagnie Fortune 5000, un casu chì hè accadutu à u bancu induve aghju travagliatu. Google hè ghjuntu à elli è sò stati mostrati diagrammi di vechji sistemi IBM. I picciotti di Google anu dumandatu in cunfusione - induve hè u codice fonte per questu? Ma ùn ci hè micca codice fonte, mancu una GUI. Questa hè a realità chì e grande urganisazione anu da trattà: i registri bancari di 40 anni in un anticu mainframe. Unu di i mo clienti usa cuntenituri Kubernetes cù mudelli Circuit Breaker, più Chaos Monkey, tuttu per l'applicazione KeyBank. Ma questi cuntenituri in ultimamente cunnette à una applicazione COBOL.
I picciotti di Google eranu cumplettamente cunfidenti chì risolveranu tutti i prublemi di u mo cliente, è dopu cuminciaru à dumandà dumande: chì hè IBM datapipe? Ci sò dettu: questu hè un connector. À chì cunnetta? À u sistema Sperry. È ciò chì hè ? Eccetera. À u primu sguardu pare: chì tipu di DevOps pò esse? Ma in fatti, hè pussibule. Ci sò sistemi di consegna chì permettenu di trasmette u flussu di travagliu à e squadre di consegna.
3. Theory of Constraints: Theory of Constraints
Passemu à u terzu archetipu : a cunniscenza istituziunale/« tribale ». In regula, in ogni urganizazione ci sò parechje persone chì cunnosci tuttu è gestisce tuttu. Quessi sò quelli chì sò stati in l'urganizazione u più longu è chì cunnoscenu tutte e soluzioni.
Quandu questu vene nantu à u diagramma, aghju circundatu specificamente tali persone cun un marcatore: per esempiu, si trova chì un certu Lou hè presente à tutte e riunioni. È hè chjaru per mè: questu hè u Brent locale. Quandu u CIO sceglie trà mè in una T-shirt è sneakers è u tippu di IBM in un vestitu, sò sceltu perchè possu dì à u direttore cose chì l'altru tippu ùn dicerà micca è chì u direttore puderia micca piace à sente. . Li dicu chì u collu di buttiglia in a so cumpagnia hè qualcunu chjamatu Fred è qualchissia chjamatu Lou. Stu collu di bottiglia deve esse sbulicatu, a so cunniscenza deve esse acquistata da elli in un modu o un altru.
Per risolve stu tipu di prublema, possu, per esempiu, suggerisce l'usu di Slack. Un direttore intelligente dumandarà - perchè? Di genere, in tali casi, i cunsultanti DevOps rispondenu: perchè tutti facenu. Se u direttore hè veramente intelligente, diciarà: allora chì. È questu hè induve finisce u dialogu. E a mo risposta à questu hè: perchè ci sò quattru buttiglii in a cumpagnia, Fred, Lou, Susie è Jane. Per istituziunalizà a so cunniscenza, prima deve esse introdutte Slack. Tutti i vostri wikis sò una sciocchezza cumpleta perchè nimu ùn sà di a so esistenza. Se a squadra di l'ingegneria hè implicata in u sviluppu front-end è back-end è ognunu hà bisognu di sapè chì ponu cuntattà u squadra di sviluppu di front-end o a squadra di l'infrastruttura cù dumande. Hè quandu Lou o Fred hà prubabilmente u tempu di unisce à u wiki. È dopu in Slack qualchissia puderia dumandà perchè, per dì, u passu 5 ùn hè micca travagliatu. E poi Lou o Fred correggeranu l'istruzzioni nantu à a wiki. Sè vo stabilisce stu prucessu, allura un saccu di cosi caderanu in u so propiu.
Questu hè u mo puntu principalu: per ricumandemu ogni alta tecnulugia, prima deve mette a fundazione per elli in ordine, è questu pò esse fattu cù e soluzioni low-tech appena descritte. Sè avete principiatu cù l'alte tecnulugii è ùn spiegà micca perchè sò necessarii, allora, in regula, questu ùn finisce micca bè. Unu di i nostri clienti usa Azure ML, una suluzione assai economica è simplice. Circa 30% di e so dumande sò stati risposti da a macchina d'auto-apprendimentu stessu. E sta cosa hè stata scritta da l'operatori chì ùn eranu micca implicati in a scienza di dati, statistiche o matematica. Questu hè significativu. U costu di tali suluzione hè minimu.
4. Hacks di cullaburazione: Hacks di cullaburazione
U quartu archetipu hè a necessità di cumbatte l'isolamentu. A maiò parte di a ghjente sapi digià questu: l'isolamentu genera ostilità. Sì ogni dipartimentu hè nantu à u so propiu pianu, è a ghjente ùn si intersecta cù l'altri in ogni modu, salvu in l'elevatore, allora l'ostilità trà elli nasce assai facilmente. Ma s'ellu, à u cuntrariu, a ghjente hè in a stessa stanza cù l'altri, ella esce immediatamente. Quandu qualchissia scaccià una accusazione generale, per esempiu, una tale interfaccia ùn funziona mai, ùn ci hè nunda più faciule per deconstruisce una tale accusa. I programatori chì anu scrittu l'interfaccia solu bisognu di cumincià à dumandà e dumande specifiche, è prestu diventerà chjaru chì, per esempiu, l'utilizatore era simpricimenti utilizendu l'uttellu in modu incorrectu.
Ci hè parechje manere di superà l'isulazione. Una volta era dumandatu à cunsultà per un bancu in Australia, ma aghju ricusatu di fà perchè aghju dui figlioli è una moglia. Tuttu ciò chì pudia fà per aiutà era di ricumandà a narrazione grafica. Questu hè qualcosa chì hè pruvatu à travaglià. Un altru modu interessante hè a riunioni di caffè magre. In una grande urganizazione, questa hè una excelente opzione per sparghje a cunniscenza. Inoltre, pudete fà devopsdays internu, hackathons, etc.
5. Coaching Kata
Cumu l'aghju avvistatu à u principiu, ùn parleraghju micca oghje. Sè site interessatu, pudete piglià un ochju .
Ci hè ancu una bona discussione annantu à questu tema da Mike Rother:
6. Market Oriented : urganizazione orientata à u mercatu
Ci sò diversi prublemi quì. Per esempiu, persone "I", persone "T" è persone "E". E persone "I" sò quelli chì facenu solu una cosa. Di solitu esistenu in urganisazioni cù dipartimenti isolati. "T" hè quandu una persona hè bona in una cosa, ma ancu bè in altre cose. "E" o ancu "pettine" hè quandu una persona hà parechje cumpetenze.
A lege di Conway funziona quì (), chì in a forma più simplificata pò esse dichjaratu cusì: se trè squadre travaglianu nantu à u compilatore, u risultatu serà un compilatore di trè parte. Dunque, s'ellu ci hè un altu livellu di isolamentu in una urganizazione, allora ancu Kubernetes, Circuit breaker, extensibilità API è altre cose fantastiche in questa urganizazione seranu disposti in u listessu modu cum'è l'urganizazione stessa. Strictamente secondu Conway è per disprezzà tutti i ghjovani geeks.
A suluzione à stu prublema hè statu discrittu parechje volte. Ci sò, per esempiu, archetipi urganisazione descritti da Fernando Fernandez. Ddu architettura problematica chì aghju appena parlatu, cù isolamentu, hè una architettura orientata à a funzione. U sicondu tipu hè u peghju, l'architettura matrice, un mess di l'altri dui. U terzu hè ciò chì si vede in a maiò parte di i startups, è e grande cumpagnie anu ancu pruvatu à currisponde à stu tipu. Hè una urganizazione orientata à u mercatu. Quì ottimisimu per ottene a risposta più veloce à e richieste di i clienti. Questu hè qualchì volta chjamatu una urganizazione flat.
Parechje persone descrizanu sta struttura in modi diffirenti, mi piace a parolla custruisce / gestisce squadre, in Amazon si chjamanu duie squadre di pizza. In questa struttura, tutte e persone di u tipu "I" sò raggruppati intornu à un serviziu, è gradualmente diventanu più vicinu à u tipu "T", è se a gestione curretta hè in u locu, ponu ancu diventà "E". U primu contraargumentu quì hè chì una tale struttura hà elementi innecessarii. Perchè avete bisognu di un tester in ogni dipartimentu se pudete avè un dipartimentu speciale di tester? À quale risponde: i costi extra in questu casu sò u prezzu per l'urganizazione sana per diventà u tipu "E" in u futuru. In questa struttura, u testatore ampara gradualmente nantu à e rete, l'architettura, u disignu, etc. In u risultatu, ogni participante in l'urganizazione hè sanu sanu di tuttu ciò chì succede in l'urganizazione. Se vulete sapè cumu funziona stu schema in l'industria, leghjite .
7. Auditori Shift-left: auditu principiu di u ciculu. U rispettu di e regule di sicurezza in mostra
Questu hè quandu e vostre azzioni ùn passanu micca a prova di l'olfattu, per dì cusì. E persone chì travaglianu per voi ùn sò micca stupidi. Se, cum'è in l'esempiu di sopra, anu stabilitu minore / senza impattu in ogni locu, questu durò trè anni, è nimu hà nutatu nunda, allora ognunu sapi perfettamente chì u sistema ùn funziona micca. O un altru esempiu - un cunsigliu di cunsigliu di cambiamentu, induve i rapporti anu da esse presentati ogni, per dì, u mercuri. Ci hè un gruppu di persone chì travaglianu quì (micca ben pagatu, per via) chì, in teoria, deve sapè cumu u sistema in tuttu u travagliu. È in l'ultimi cinque anni, probabilmente avete nutatu chì i nostri sistemi sò incredibbilmente cumplessi. E cinque o sei persone anu da piglià una decisione annantu à un cambiamentu chì ùn anu micca fattu è di quale ùn sanu nunda.
Di sicuru, stu approcciu ùn hè micca travagliatu. Aghju da sbarazzà di tali cose perchè queste persone ùn sò micca prutegge u sistema. A decisione deve esse fatta da a squadra stessu, perchè a squadra deve esse rispunsevuli di questu. Altrimenti, una situazione paradossale si sviluppa quandu un manager chì ùn hà mai scrittu codice in a so vita dice à u programatore quantu duverebbe piglià à scrive codice. Una sucietà cù quale aghju travagliatu hà avutu 7 schede diffirenti chì anu rivisatu ogni cambiamentu, cumpresa una tavola di architettura, una tavola di produttu, etc. Ci era ancu un periodu d'attesa ubligatoriu, ancu s'ellu un impiigatu m'hà dettu chì in deci anni di travagliu, nimu ùn avia mai rifiutatu un cambiamentu fattu da sta persona durante stu periodu ubligatoriu.
L'auditori deve esse invitati à unisce à noi, è micca sbarazzarsi di elli. Dite à elli chì scrivite cuntenituri binari immutabili chì, se passanu tutti i testi, fermanu immubili per sempre. Dite à elli chì avete un pipeline cum'è codice è spiegà ciò chì significa. Mostra à elli u schema seguente: un binariu di sola lettura immutable in un containeru chì passa tutte e teste di vulnerabilità; è tandu ùn solu ùn tocca à nimu, ùn tocca ancu u sistema chì crea u pipeline, postu chì hè ancu creatu dinamicamente. Aghju clienti, Capital One, chì utilizanu Vault per creà qualcosa cum'è una blockchain. L'auditore ùn hà micca bisognu di mostrà "ricette" da Chef; hè abbastanza per vede u blockchain, da quale hè chjaru ciò chì hè accadutu à u bigliettu Jira in a pruduzzione è quale hè rispunsevule per questu.
Sicondu , creatu in 2018 da Sonatype, ci era 2017 miliardi di richieste di scaricamentu OSS in 87.
E perdite incurrute per via di vulnerabilità sò pruibitive. Inoltre, i figuri chì avà vede sopra ùn includenu micca i costi di opportunità. Cos'è DevSecOps in poche parole? Lasciami dì subitu chì ùn sò micca interessatu à parlà di u successu di stu nome. U puntu hè chì, postu chì DevOps hè statu cusì successu, duvemu pruvà à aghjunghje a sicurità à quella pipeline.
Un esempiu di sta sequenza:
Questa ùn hè micca una ricunniscenza per i prudutti specifichi, ancu s'ellu mi piace tutti. L'aghju citatu cum'è un esempiu per dimustrà chì DevOps, chì era inizialmente basatu annantu à u paradigma di l'urganizazione in l'industria, permette di automatizà ogni tappa di u travagliu nantu à un pruduttu.
È ùn ci hè nisuna ragione perchè ùn pudemu micca piglià u listessu approcciu à a sicurità.
U risultatu
In cunclusione, daraghju qualchi cunsiglii per DevSecOps. Avete bisognu di include l'auditori in u prucessu di creazione di i vostri sistemi è passanu u tempu per educà. Avete bisognu di cooperà cù l'auditori. Dopu, avete bisognu di fà una lotta assolutamente spietata contr'à falsi pusitivi. Ancu cù u più caru strumentu di scansione di vulnerabilità, pudete finisce per creà abitudini estremamente cattivi trà i vostri sviluppatori se ùn sapete micca quale hè u vostru rapportu signal-à-rumore. I sviluppatori saranu sopraffatti da l'avvenimenti è li elimineranu solu. Se avete intesu parlà di a storia di Equifax, hè quasi ciò chì hè accadutu quì, induve u più altu livellu d'alerta hè statu ignoratu. Inoltre, i vulnerabili anu da esse spiegati in una manera chì rende chjaru cumu impactanu l'affari. Per esempiu, pudete dì chì questu hè a stessa vulnerabilità cum'è in a storia Equifax. I vulnerabilità di a sicurità devenu esse trattate cum'è l'altri prublemi di software, vale à dì, anu da esse incluse in u prucessu generale di DevOps. Avete bisognu di travaglià cun elli attraversu Jira, Kanban, etc. I sviluppatori ùn anu micca pensatu chì qualchissia altru farà questu - à u cuntrariu, tutti duveranu fà questu. Infine, avete bisognu di gastru energia in a furmazione di e persone.
E ligami utili
Eccu alcuni discorsi da a cunferenza DevOops chì pudete truvà utile:
- Sergey Berdnikov, Artyom Kalichkin - Storia di successu, o "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps in scala: una tragedia greca in trè atti (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Fighjate in DevOops 2020 Mosca - ci sò ancu assai cose interessanti quì.
Source: www.habr.com