De fraach "hoe kinne jo devops útfiere" bestiet al jierren, mar d'r binne net in protte goede materialen. Soms wurde jo it slachtoffer wurden fan advertinsjes fan net sa tûke adviseurs dy't har tiid moatte ferkeapje, hoe dan ek. Soms binne dit vage, ekstreem algemiene wurden oer hoe't de skippen fan megakorporaasjes de útwreidingen fan it universum ploegje. De fraach ûntstiet: wat docht dit foar ús? Beste skriuwer, kinne jo jo ideeën dúdlik formulearje yn in list?
Dit alles komt út it feit dat net folle echte praktyk en begryp fan 'e útkomst fan transformaasjes fan' e bedriuwskultuer hawwe sammele. Feroaringen yn kultuer binne dingen op lange termyn, wêrfan de resultaten net yn in wike of in moanne ferskine. Wy hawwe ien âld genôch nedich om te sjen hoe't bedriuwen yn 'e rin fan' e jierren binne boud en mislearre.
John Willis - ien fan 'e heiten fan DevOps. John hat tsientallen jierren ûnderfining mei it wurkjen mei in grut oantal bedriuwen. Koartlyn begon John spesifike patroanen op te merken dy't plakfine by it wurkjen mei elk fan har. Mei dizze argetypen begeliedt John bedriuwen op it wiere paad fan DevOps-transformaasje. Lês mear oer dizze argetypen yn 'e oersetting fan syn rapport fan 'e DevOops 2018-konferinsje.
Oer de sprekker:
Mear as 35 jier yn IT-behear, die mei oan 'e skepping fan' e foargonger fan OpenCloud by Canonical, naam diel oan 10 startups, wêrfan twa waarden ferkocht oan Dell en Docker. Op it stuit is hy Vice President fan DevOps en Digital Practices by SJ Technologies.
Folgjende is it ferhaal út John syn eachpunt.
Myn namme is John Willis en it maklikste plak om my te finen is op Twitter, . Ik haw deselde alias op Gmail en GitHub. IN Jo kinne fideo-opnames fine fan myn rapporten en presintaasjes foar har.
Ik haw in protte gearkomsten mei CIO's fan ferskate grutte bedriuwen. Se klagje heul faak dat se net begripe wat DevOps is, en elkenien dy't it har besiket te ferklearjen, praat oer wat oars. In oare mienskiplike klacht is dat DevOps net wurket, hoewol it liket dat de direkteuren alles dogge lykas har útlein. Wy hawwe it oer grutte bedriuwen dy't mear as hûndert jier âld binne. Nei it praten mei harren, kaam ik ta de konklúzje dat foar in protte problemen, it is net hege technology dat is it bêste geskikt, mar earder relatyf leech-tech oplossings. Wiken lang haw ik gewoan mei minsken fan ferskate ôfdielingen praat. Wat jo sjogge op 'e earste foto yn' e post is myn lêste projekt, dit is hoe't de keamer der út seach nei trije dagen wurk.
Wat is DevOps?
Yndied, as jo 10 ferskillende minsken freegje, sille se 10 ferskillende antwurden jaan. Mar hjir is it nijsgjirrige: alle tsien fan dizze antwurden sille korrekt wêze. D'r is hjir gjin ferkeard antwurd. Ik siet sa'n 10 jier aardich djip yn DevOps, en wie de earste Amerikaan op 'e earste DevOpsDay. Ik sil net sizze dat ik slimmer bin as elkenien dy't belutsen is by DevOps, mar d'r is amper ien dy't der safolle muoite oan hat bestege. Ik leau dat DevOps foarkomt as minsklik kapitaal en technology byinoar komme. Wy ferjitte faaks de minsklike diminsje, hoewol wy it in protte oer allerhanne kultueren hawwe.
No hawwe wy in protte gegevens, fiif jier fan akademysk ûndersyk, testen fan teoryen op yndustriële skaal. Wat dizze stúdzjes ús fertelle is dat as jo wat gedrachspatroanen kombinearje yn in organisatoaryske kultuer, jo in 2000x fersnelling kinne berikke. Dizze fersnelling wurdt matched troch in lykweardige ferbettering fan stabiliteit. Dit is in kwantitative mjitting fan it foardiel dat DevOps kin bringe foar elk bedriuw. In pear jier lyn hie ik it oer DevOps mei de CEO fan in Fortune 5000-bedriuw Doe't ik my tariede op de presintaasje, wie ik heul senuweftich, om't ik myn jierrenlange ûnderfining yn 5 minuten moast gearfetsje.
Op it lêst joech ik it folgjende Definysje fan DevOps: It is in set fan praktiken en patroanen dy't de transformaasje fan minsklik kapitaal yn hege prestaasjes organisatoarysk kapitaal mooglik meitsje. In foarbyld is de manier wêrop Toyota de lêste 50 of 60 jier operearre hat.
(Hjirnei wurde sokke diagrammen net as referinsjemateriaal, mar as yllustraasjes oanbean. De ynhâld dêrfan sil foar elk nij bedriuw ferskille. De foto kin lykwols apart en fergrutte wurde besjoen.
Ien fan 'e meast suksesfolle sokke praktiken is wearde streaming mappen. Der binne ferskate goede boeken oer skreaun, de meast suksesfolle fan Karen Martin. Mar it ôfrûne jier bin ik ta de konklúzje kommen dat sels dizze oanpak te heechtechnysk is. It hat grif in protte foardielen en ik haw it in protte brûkt. Mar as de CEO freget jo wêrom't syn bedriuw kin net oerstappe nei nije rails, it is te betiid om te praten oer wearde stream mapping. D'r binne folle folle mear fûnemintele fragen dy't earst moatte wurde beantwurde.
Ik tink dat de flater in protte fan myn kollega's meitsje is dat se it bedriuw gewoan in fiifpuntsgids jouwe en dan seis moanne letter weromkomme en sjen wat der bard is. Sels in goed skema lykas weardestreammapping hat, lit ús sizze, bline flekken. Nei hûnderten ynterviews mei direkteuren fan ferskate bedriuwen, haw ik in bepaald patroan ûntwikkele wêrtroch wy it probleem yn syn komponinten kinne brekke, en no sille wy elk fan dizze komponinten yn oarder besprekke. Foardat ik alle technologyske oplossingen tapasse, brûk ik dit patroan, en as gefolch binne al myn muorren bedekt mei diagrammen. Koartlyn wurke ik mei in ûnderlinge fûns en ik einige mei 100-150 sokke regelingen.
Mine kultuer yt goede oanpak foar moarnsiten
It haadidee is dit: gjin bedrach fan Lean, Agile, SAFE en DevOps sil helpe as de kultuer fan 'e organisaasje sels min is. It is as dûke nei djipten sûnder scuba gear of operearje sûnder in x-ray. Mei oare wurden, om Drucker en Deming te parafrasearjen: in minne organisaasjekultuer sil elk goed systeem opslokje sûnder der yn te fersmoarjen.
Om dit haadprobleem op te lossen, moatte jo de folgjende stappen nimme:
- Meitsje alle wurk sichtber: jo moatte al it wurk sichtber meitsje. Net yn 'e sin dat it needsaaklik op ien of oare skerm werjûn wurde moat, mar yn' e sin dat it waarnimmber wêze moat.
- Konsolidearre wurkbehearsystemen: behearsystemen moatte konsolidearre wurde. Yn it probleem fan "tribale" kennis en ynstitúsjonele kennis is yn 9 gefallen fan 10 de knelpunt minsken. Yn it boek it probleem wie mei ien inkelde persoan, Brent, dy't feroarsake it projekt te wêzen trije jier efter skema. En ik rin dizze "Brents" oeral tsjin. Om dizze knyppunten op te lossen, brûk ik de folgjende twa items op ús list.
- Teory of Constraints Methodology: teory fan beheinings.
- Gearwurking hacks: gearwurking hacks.
- Toyota Kata (): Ik sil net prate folle oer de Toyota Kata. As ynteressearre, op myn github oer hast elk fan dizze ûnderwerpen.
- Marktrjochte organisaasje: merk-rjochte organisaasje.
- Skift-links auditors: audit yn 'e iere stadia fan' e syklus.
Ik begjin gewoan mei in organisaasje te wurkjen: ik gean nei it bedriuw en praat mei de meiwurkers. Sa't jo sjen kinne, gjin hege technology. Alles wat jo nedich binne is wat om op te skriuwen. Ik sammelje ferskate teams yn ien keamer en analysearje wat se my fertelle út it perspektyf fan myn 7 argetypen. En dan jou ik se sels in marker en freegje se alles op it boerd te skriuwen wat se oant no ta lûdop sein hawwe. Meastentiids is der yn dit soarte fan gearkomsten ien persoan dy't alles opskriuwt, en op syn bêst kin hy 10% fan 'e diskusje opskriuwe. Mei myn metoade kin dit sifer ferhege wurde oant sawat 40%.
(Dizze yllustraasje kin apart besjoen wurde )
Myn oanpak is basearre op it wurk fan William Schneider. ). De oanpak is basearre op it idee dat elke organisaasje ferdield wurde kin yn fjouwer fjilden. Dit skema foar my is meastal it resultaat fan it wurkjen mei dy hûnderten oare skema's dy't ûntsteane by it analysearjen fan in organisaasje. Stel dat wy in organisaasje hawwe mei in heech nivo fan kontrôle, mar mei lege kompetinsje. Dit is in ekstreem net winske opsje: as elkenien oan 'e line is, mar gjinien wit wat te dwaan.
In wat bettere opsje is ien mei in heech nivo fan kontrôle en kompetinsje. As sa'n bedriuw rendabel is, dan hat it miskien gjin DevOps nedich. It is it meast nijsgjirrich om te wurkjen mei in bedriuw dat in heech nivo fan kontrôle, lege kompetinsje en gearwurking hat, mar tagelyk in heech nivo fan kultuer (kultivaasje). Dat betsjut dat it bedriuw in soad minsken hat dy't dêr graach wurkje en de arbeidsomset leech is.
(Dizze yllustraasje kin apart besjoen wurde )
It liket my ta dat metoaden mei stive rjochtlinen úteinlik yn 'e wei komme om de wierheid te berikken. Benammen yn weardestreammapping binne d'r in protte regels oangeande hoe't ynformaasje strukturearre wurde moat. Yn 'e iere stadia fan wurk, dêr't ik it no oer ha, hat gjinien dizze regels nedich. As in persoan mei in marker yn 'e hannen beskriuwt de echte situaasje yn it bedriuw op it bestjoer, dit is de bêste manier om de stân fan saken te begripen. Sokke ynformaasje berikt direkteuren net. Op dit stuit is it dom om de persoan te ûnderbrekken en te sizzen dat hy in soarte fan pylk ferkeard tekene. Op dit poadium is it better om ienfâldige regels te brûken, bygelyks: abstraksje op meardere nivo's kin gewoan makke wurde troch mearkleurige markers te brûken.
Ik werhelje, gjin hege technology. De swarte marker ferbyldet de objektive realiteit fan hoe't alles wurket. Mei in reade marker markearje minsken wat se net leuk fine oer de hjoeddeistige stân fan saken. It is wichtich dat se dit skriuwe, net ik. As ik nei in gearkomste nei de CIO gean, bied ik gjin list fan 10 dingen oan dy't reparearre wurde moatte. Ik stribje om ferbinings te finen tusken wat minsken yn it bedriuw sizze en besteande bewezen patroanen. Uteinlik suggerearret in blauwe marker mooglike oplossingen foar it probleem.
(Dizze yllustraasje kin apart besjoen wurde )
In foarbyld fan dizze oanpak is no hjirboppe ôfbylde. Begjin dit jier wurke ik mei ien bank. De befeiligingsminsken wiene der fan oertsjûge dat se net ta ûntwerp- en easkbeoardielingen komme moatte.
(Dizze yllustraasje kin apart besjoen wurde )
En doe ha wy praat mei minsken fan oare ôfdielingen en it die bliken dat sa'n 8 jier lyn softwareûntwikkelders befeiligingswurkers ûntslein hawwe om't se it wurk fertrage. En doe waard it in ferbod, dat wie fanselssprekkend. Hoewol't yn werklikheid wie der gjin ferbod.
Us gearkomste ferrûn op in heul betiizjende manier: sawat trije oeren koene fiif ferskillende teams my net útlizze wat der bart tusken de koade en de gearkomste. En dit soe lykje te wêzen it simpelste ding. De measte DevOps-konsultanten geane der fan út dat elkenien dit al wit.
Doe kaam de persoan dy't ferantwurdlik wie foar IT-bestjoer, dy't fjouwer oeren stil hie, ynienen ta libben doe't wy by syn ûnderwerp kamen, en besette ús hiel lang. Oan 'e ein frege ik him wat er tocht oer de gearkomste, en ik sil syn antwurd noait ferjitte. Hy sei: "Ik tocht eartiids dat ús bank mar twa manieren hie om software te leverjen, mar no wit ik dat d'r fiif binne, en ik wist net iens fan trije."
(Dizze yllustraasje kin apart besjoen wurde )
De lêste gearkomste by dizze bank wie mei it team fan ynvestearringssoftware. It wie by har dat it die bliken dat it skriuwen fan diagrammen mei in marker op in blêd papier better is as op in boerd, en noch better as op in smartboard.
De foto's dy't jo sjogge binne hoe't de konferinsjeromte fan it hotel der út seach op 'e fjirde dei fan ús gearkomste. En wy brûkten dizze skema's om te sykjen nei patroanen, dat is, argetypen.
Dat, ik freegje de arbeiders fragen, se skriuwe de antwurden op mei markers fan trije kleuren (swart, read en blau). Ik analysearje har antwurden foar argetypen. Litte wy no alle argetypen yn oarder besprekke.
1. Meitsje alle wurk sichtber: Meitsje wurk sichtber
De measte bedriuwen wêrmei ik wurkje, hawwe in heul heech persintaazje ûnbekend wurk. Dit is bygelyks as de iene meiwurker nei de oare komt en gewoan freget om wat te dwaan. Yn grutte organisaasjes kin d'r 60% net pland wurk wêze. En oant 40% fan it wurk is op gjin inkelde manier dokumintearre. As it wie Boeing, Ik soe nea board harren fleantúch wer yn myn libben. As mar de helte fan it wurk dokumintearre is, dan is net bekend oft dit wurk goed of net dien wurdt. Alle oare metoaden blike nutteloos te wêzen - it hat gjin punt om alles te automatisearjen, om't de bekende 50% it meast gearhingjende en dúdlike diel fan it wurk kin wêze, wêrfan de automatisearring gjin geweldige resultaten sil jaan, en al it slimste dingen binne yn 'e ûnsichtbere helte. By it ûntbrekken fan dokumintaasje is it ûnmooglik om allerhanne hacks en ferburgen wurk te finen, gjin knelpunten te finen, dy eigen "Brents" dêr't ik it al oer hie. D'r is in prachtich boek fan Dominica DeGrandis . Sy ferriedt fiif ferskillende "tiidlekken" (tiiddieven):
- Tefolle wurk yn proses (WIP)
- Unbekende Ofhinklikens
- Unplanned wurk
- Tsjinstridige prioriteiten
- Negearre wurk
Dit is tige weardefolle analyze en it boek is geweldich, mar al dit advys is nutteloos as mar 50% fan 'e gegevens sichtber is. De metoaden foarsteld troch Dominica kinne brûkt wurde as in krektens fan boppe 90% wurdt berikt. Ik haw it oer situaasjes dêr't in baas jout in ûndergeskikte in 15-minuten taak, mar it duorret him trije dagen; mar de baas wit eins net dat dizze ûnderhearrige ôfhinklik is fan fjouwer of fiif oare minsken.
The Phoenix Project is in prachtich ferhaal oer in projekt dat trije jier te let wie. Ien fan 'e personaazjes krijt ûntslach fanwegen dit, en hy moetet in oar personaazje dat wurdt presintearre as in soarte fan Sokrates. Hy helpt út te finen wat der krekt misgien is. It docht bliken dat it bedriuw ien systeembehearder hat, waans namme is Brent, en al it wurk giet op ien of oare manier troch him. Op ien fan de gearkomsten wurdt ien fan de ûndergeskikten frege: wêrom duorret elke healoere taak in wike? It antwurd is in tige ferienfâldige presintaasje fan de wachtrige teory en de wet fan Little, en yn dizze presintaasje docht bliken dat by 90% besetting elk oere wurk 9 oeren duorret. Elke taak moat nei sân oare minsken stjoerd wurde, sadat dat oere 63 oeren wurdt, 7 kear 9. Wat ik sis is dat om Little's Law of in komplekse wachtrigeteory te brûken, jo op syn minst gegevens moatte hawwe.
Dus as ik praat oer sichtberens, bedoel ik net dat alles op it skerm stiet, mar dat jo op syn minst gegevens hawwe. As se dat dogge, docht it faaks bliken dat der in hiel soad net pland wurk is dat op ien of oare manier nei Brent stjoerd wurdt as it net nedich is. En Brent is in geweldige keardel, hy sil nea nee sizze, mar hy fertelt gjinien hoe't er syn wurk docht.
As it wurk sichtber is, kinne de gegevens kreas yndield wurde (dat docht Dominika op de foto), de abstraksje fan de fiif tiidlekken kin tapast wurde en automatisearring kin tapast wurde.
2. Konsolidearje wurkbehearsystemen: taakbehear
De argetypen dêr't ik it oer ha, binne in soarte fan piramide. As de earste goed dien is, dan is de twadde al in soarte fan add-on. In protte fan dizze wurkje net foar startups, se moatte yn gedachten hâlden wurde foar gruttere bedriuwen lykas de Fortune 5000. It lêste bedriuw wêrfoar ik wurke hie 10 ticketingsystemen. Ien team hie Remedy, in oar skreau in soarte fan syn eigen systeem, in tredde brûkte Jira, en guon makken it mei e-post. Itselde probleem ûntstiet as it bedriuw hat 30 ferskillende pipelines, mar ik haw gjin tiid om te besprekken al sokke gefallen.
Ik beprate mei minsken krekt hoe't kaartsjes makke wurde, wat der dêrnei mei bart en hoe't se omseame. It meast nijsgjirrige is dat minsken op ús gearkomsten frij oprjocht prate. Ik frege hoefolle minsken "minder / gjin ynfloed" sette op kaartsjes dy't eins "grutte ynfloed" moatte krije. It die bliken dat hast elkenien dit docht. Ik doch net mei oan ûntslach en besykje op alle mooglike manieren gjin minsken te identifisearjen. As se my oprjocht wat bekenne, jou ik de persoan net fuort. Mar as hast elkenien it systeem omgiet, betsjut dit dat alle feiligens yn essinsje finsters is. Dêrom kinne gjin konklúzjes lutsen wurde út de gegevens fan dit systeem.
Om it kaartsjeprobleem op te lossen, moatte jo ien haadsysteem kieze. As jo Jira brûke, hâld it dan Jira. As d'r in alternatyf is, lit it dan de iennichste wêze. De ûnderste rigel is dat kaartsjes moatte wurde sjoen as in oare stap yn it ûntwikkelingsproses. Elke aksje moat in kaartsje hawwe, dy't troch de ûntwikkelingsworkflow streame moat. Kaarten wurde stjoerd nei it team, dat se op it storyboard pleatst en dan ferantwurdlikens foar har nimt.
Dit jildt foar alle ôfdielingen, ynklusyf ynfrastruktuer en operaasjes. Yn dit gefal is it mooglik om op syn minst in plausibel idee te foarmjen fan 'e stân fan saken. As dit proses ienris fêststeld is, wurdt it ynienen maklik te identifisearjen wa't ferantwurdlik is foar elke applikaasje. Want no krije wy net 50%, mar 98% fan nije tsjinsten. As dit kearnproses wurket, ferbetteret de krektens yn it heule systeem.
Tsjinsten pipeline
Dat jildt wer allinnich foar grutte bedriuwen. As jo in nij bedriuw binne yn in nij fjild, rôlje dan jo mouwen op en wurkje mei jo Travis CI of CircleCI. As it giet om Fortune 5000 bedriuwen, in gefal yn punt dat barde by de bank dêr't ik wurke. Google kaam by harren en se waarden sjen litten diagrammen fan âlde IBM systemen. De jonges fan Google fregen yn betizing - wêr is de boarnekoade foar dit? Mar d'r is gjin boarnekoade, net iens in GUI. Dit is de realiteit dêr't grutte organisaasjes mei te krijen hawwe: 40 jier âlde bankrekken op in âlde mainframe. Ien fan myn kliïnten brûkt Kubernetes-konteners mei Circuit Breaker-patroanen, plus Chaos Monkey, allegear foar de KeyBank-applikaasje. Mar dizze konteners ferbine úteinlik mei in COBOL-applikaasje.
De jonges fan Google wiene folslein wis dat se alle problemen fan myn kliïnt soene oplosse, en doe begûnen se fragen te stellen: wat is IBM datapipe? Se wurde ferteld: dit is in ferbiner. Wat docht it oan? Nei it Sperry-systeem. En wat is dat? Ensafuorthinne. Op it earste each liket it: hokker soarte fan DevOps kinne der wêze? Mar yn feite is it mooglik. D'r binne leveringssystemen wêrmei jo de workflow kinne oerjaan oan de leveringsteams.
3. Teory of Constraints: Teory of Constraints
Lit ús gean nei it tredde argetype: ynstitúsjonele / "stamme" kennis. As regel, yn elke organisaasje binne d'r ferskate minsken dy't alles witte en alles beheare. Dit binne dejingen dy't it langst yn de organisaasje sitte en dy't alle oplossingen kenne.
As dit op it skema komt, omrin ik sokke minsken spesifyk mei in marker: it docht bygelyks bliken dat in bepaalde Lou by alle gearkomsten oanwêzich is. En it is my dúdlik: dit is lokale Brent. As in CIO kiest tusken my yn in T-shirt en sneakers en in man yn pak klaaid fan IBM, bin ik keazen om't ik de direkteur dingen kin fertelle dy't de oare keardel net fertelt en dy't de direkteur miskien net graach hearre sil . Ik fertel har dat de knelpunt yn har bedriuw ien is mei de namme Fred en ien mei de namme Lou. Dy knelpunt moat losmakke wurde, harren kennis moat op de ien of oare manier fan harren helle wurde.
Om dit soarte fan probleem op te lossen, kin ik bygelyks foarstelle om Slack te brûken. In tûke direkteur sil freegje - wêrom? Typysk, yn sokke gefallen, antwurdzje DevOps-adviseurs: om't elkenien it docht. As de direkteur echt tûk is, sil er sizze: wat dan. En dit is wêr't de dialooch einiget. En myn antwurd hjirop is: om't d'r fjouwer knelpunten binne yn it bedriuw, Fred, Lou, Susie en Jane. Om har kennis te ynstitúsjonalisearjen, moat men earst Slack yntrodusearje. Al dyn wiki's binne folsleine ûnsin, want nimmen wit fan har bestean. As it yngenieurteam belutsen is by front-end en back-end ûntwikkeling en elkenien moat witte dat se mei fragen kontakt opnimme kinne mei it front-end ûntwikkelingsteam of it ynfrastruktuerteam. Dan sille Lou of Fred nei alle gedachten tiid hawwe om mei te dwaan oan de wiki. En dan yn Slack kin immen freegje wêrom, sis, stap 5 net wurket En dan korrigearje Lou of Fred de ynstruksjes op de wiki. As jo dit proses fêststelle, dan sille in protte dingen op har eigen plak falle.
Dit is myn haadpunt: om alle hege technologyen oan te rieden, moatte jo earst de stifting foar har yn oarder sette, en dit kin dien wurde mei de krekt beskreaune low-tech oplossingen. As jo begjinne mei hege technologyen en net útlizze wêrom't se nedich binne, dan, as regel, dit einiget net goed. Ien fan ús kliïnten brûkt Azure ML, in heul goedkeap en ienfâldige oplossing. Sawat 30% fan har fragen waard beantwurde troch de selslearmasine sels. En dit ding waard skreaun troch operators dy't net belutsen wiene by gegevenswittenskip, statistyk of wiskunde. Dit is wichtich. De kosten fan sa'n oplossing binne minimaal.
4. Gearwurking hacks: Gearwurking hacks
It fjirde argetype is de needsaak om isolaasje te bestriden. De measte minsken witte dit al: isolemint bringt fijannigens. As elke ôfdieling op syn eigen ferdjipping is, en minsken krúsje elkoar op gjin inkelde manier, útsein yn 'e lift, dan ûntstiet der tige maklik fijânskip tusken harren. Mar as minsken oarsom mei elkoar yn deselde keamer sitte, giet se daliks fuort. As immen ien of oare algemiene beskuldiging útsmyt, bygelyks sa'n en sa'n ynterface wurket noait, is der neat makliker om sa'n beskuldiging te dekonstruearjen. De programmeurs dy't de ynterface skreaun hawwe, moatte gewoan spesifike fragen stelle, en it sil gau dúdlik wurde dat bygelyks de brûker it ark gewoan ferkeard brûkte.
D'r binne in protte manieren om isolaasje te oerwinnen. Ik waard ienris frege om te rieplachtsjen foar in bank yn Austraalje, mar ik wegere it te dwaan omdat ik twa bern en in frou haw. Alles wat ik dwaan koe om har te helpen wie grafyske ferhalen oan te rieden. Dit is iets dat is bewiisd te wurkjen. In oare nijsgjirrige manier is mager kofjegearkomsten. Yn in grutte organisaasje is dit in poerbêste opsje foar it fersprieden fan kennis. Derneist kinne jo ynterne devopsdays, hackathons, ensfh.
5. Kata coaching
Lykas ik oan it begjin warskôge, sil ik hjir hjoed net oer prate. As jo ynteressearre binne, kinne jo sjen .
D'r is ek in goed petear oer dit ûnderwerp fan Mike Rother:
6. Market Oriented: merk-rjochte organisaasje
D'r binne hjir ferskate problemen. Bygelyks, "I" minsken, "T" minsken en "E" minsken. "Ik" minsken binne dejingen dy't mar ien ding dogge. Typysk besteane se yn organisaasjes mei isolearre ôfdielingen. "T" is as in persoan goed is yn ien ding, mar ek goed yn guon oare dingen. "E" of sels "kam" is as in persoan in protte feardichheden hat.
De wet fan Conway wurket hjir (), dy't yn 'e meast ferienfâldige foarm as folget steld wurde kin: as trije teams wurkje oan 'e gearstaller, dan sil it resultaat in gearstaller fan trije dielen wêze. Dêrom, as der in hege nivo fan isolemint binnen in organisaasje, dan sels Kubernetes, Circuit breaker, API útwreidzjen en oare fancy dingen yn dizze organisaasje sil wurde regele op deselde wize as de organisaasje sels. Strikt neffens Conway en nettsjinsteande al jim jonge geeks.
De oplossing foar dit probleem is in protte kearen beskreaun. Der binne bygelyks organisatoaryske argetypen beskreaun troch Fernando Fernandez. Dy problematyske arsjitektuer dêr't ik it krekt oer hie, mei isolemint, is in funksje-rjochte arsjitektuer. It twadde type is de minste, matrix-arsjitektuer, in puinhoop fan 'e oare twa. De tredde is wat te sjen is yn de measte startups, en grutte bedriuwen besykje ek dit type te passen. It is in merkrjochte organisaasje. Hjir optimalisearje wy om it rapste antwurd te berikken op oanfragen fan klanten. Dit wurdt soms in platte organisaasje neamd.
In protte minsken beskriuwe dizze struktuer op ferskate manieren, ik hâld fan 'e formulearring bouwe / rinne teams, by Amazon neame se it twa pizza teams. Yn dizze struktuer, alle type "I" minsken wurde groepearre om ien tsjinst, en stadichoan wurde se tichter by it type "T", en as it rjocht behear is yn plak, se kinne sels wurden "E". It earste tsjinargumint hjir is dat sa'n struktuer ûnnedige eleminten hat. Wêrom hawwe jo in tester nedich yn elke ôfdieling as jo in spesjale ôfdieling testers hawwe kinne? Dêrop antwurdzje ik: de ekstra kosten binne yn dit gefal de priis dat de hiele organisaasje yn de takomst type “E” wurdt. Yn dizze struktuer leart de tester stadichoan oer netwurken, arsjitektuer, ûntwerp, ensfh. Dêrtroch is elke dielnimmer yn 'e organisaasje folslein bewust fan alles wat yn 'e organisaasje bart. As jo wolle witte hoe't dit skema wurket yn 'e yndustry, lês dan .
7. Shift-left auditors: audit betiid yn 'e syklus. Neilibjen fan feiligens regels op display
Dit is as jo aksjes de geurtest net trochjaan, sa te sizzen. De minsken dy't foar jo wurkje binne net dom. As se, lykas yn it foarbyld hjirboppe, oeral lytse/gjin ynfloed sette, dit duorre trije jier, en gjinien hat wat opmurken, dan wit elkenien goed dat it systeem net wurket. Of in oar foarbyld - in wizigingsadvysried, dêr't alle, bygelyks, woansdei rapporten yntsjinne wurde moatte. Dêr wurket in groep minsken (net sa goed betelle trouwens) dy't yn teory witte moatte hoe't it systeem as gehiel wurket. En yn 'e ôfrûne fiif jier hawwe jo wierskynlik opfallen dat ús systemen ongelooflijk kompleks binne. En fiif of seis minsken moatte in beslút nimme oer in feroaring dy't se net makke hawwe en dêr't se neat fan witte.
Fansels wurket dizze oanpak net. Ik moat fan sokke dingen ôf, om't dizze minsken it systeem net beskermje. It beslút moat troch it team sels makke wurde, want it team moat dêr ferantwurdlik foar wêze. Oars ûntstiet in paradoksale situaasje as in manager dy't yn syn libben noch noait koade skreaun hat de programmeur fertelt hoe lang it duorje moat om koade te skriuwen. Ien bedriuw wêrmei't ik wurke hie 7 ferskillende boerden dy't elke feroaring beoardiele, ynklusyf in arsjitektuerboerd, in produktboerd, ensfh. Der wie sels in ferplichte wachttiid, hoewol't ien meiwurker fertelde my dat yn tsien jier fan wurk, gjinien hie ea ôfwiisd in feroaring makke troch dizze persoan yn dizze ferplichte perioade.
Auditors moatte wurde útnoege om mei te dwaan, en net kwyt te reitsjen fan harren. Fertel har dat jo ûnferoarlike binêre konteners skriuwe dy't, as se alle tests passe, foar altyd ûnferoarlik bliuwe. Fertel harren dat jo in pipeline as koade hawwe en ferklearje wat dat betsjut. Lit har it folgjende skema sjen: in ûnferoarlik allinich-lês-binêr yn in kontener dy't alle kwetsberenstests trochmakket; en dan net allinnich net ien oanreitsje it, se net iens oanreitsje it systeem dat makket de pipeline, sûnt it wurdt ek makke dynamysk. Ik haw kliïnten, Capital One, dy't Vault brûke om wat te meitsjen as in blockchain. De auditor hoecht gjin "resepten" fan Chef te sjen, it is genôch om de blockchain te sjen, wêrfan dúdlik is wat der bard is mei it Jira-ticket yn 'e produksje en wa't der ferantwurdlik foar is.
Neffens , makke yn 2018 troch Sonatype, wiene d'r 2017 miljard OSS-downloadoanfragen yn 87.
De ferliezen dy't ûntstien binne troch kwetsberens binne ferbean. Boppedat binne de sifers dy't jo no hjirboppe sjogge gjin kânskosten. Wat is DevSecOps yn in notedop? Lit my daliks sizze dat ik net ynteressearre bin om te praten oer hoe suksesfol dizze namme is. It punt is dat, om't DevOps sa suksesfol is, wy moatte besykje feiligens ta te foegjen oan dy pipeline.
In foarbyld fan dizze folchoarder:
Dit is gjin oanbefelling foar spesifike produkten, hoewol ik se allegear leuk fyn. Ik neamde se as foarbyld om sjen te litten dat DevOps, dy't yn earste ynstânsje basearre wie op it organisatoaryske paradigma yn 'e yndustry, lit jo elke faze fan wurk oan in produkt automatisearje.
En d'r is gjin reden wêrom't wy deselde oanpak fan feiligens net koene nimme.
It resultaat
As konklúzje sil ik wat tips jaan foar DevSecOps. Jo moatte auditors opnimme yn it proses fan it meitsjen fan jo systemen en tiid besteegje oan it oplieden fan har. Jo moatte gearwurkje mei auditors. Folgjende, jo moatte fiere in absolút meidogensleaze striid tsjin falske positiven. Sels mei it djoerste ark foar kwetsberens skennen, kinne jo einigje mei it meitsjen fan ekstreem minne gewoanten ûnder jo ûntwikkelders as jo net witte wat jo sinjaal-to-lûd-ferhâlding is. Untwikkelders sille oerweldige wurde mei eveneminten en sille se gewoan wiskje. As jo hearden oer it Equifax-ferhaal, dat is sawat wat der barde, wêr't it heechste warskôgingsnivo waard negearre. Derneist moatte kwetsberens wurde ferklearre op in manier dy't dúdlik makket hoe't se ynfloed hawwe op it bedriuw. Jo kinne bygelyks sizze dat dit deselde kwetsberens is as yn it Equifax-ferhaal. Feiligens kwetsberens moatte itselde wurde behannele as oare softwareproblemen, dat is, se moatte wurde opnommen yn it algemiene DevOps-proses. Jo moatte mei har wurkje fia Jira, Kanban, ensfh. Untwikkelders moatte net tinke dat in oar dit sil dwaan - krekt oarsom, elkenien moat dit dwaan. Uteinlik moatte jo enerzjy besteegje oan it oplieden fan minsken.
Nuttige keppelings
Hjir binne in pear petearen fan 'e DevOops-konferinsje dy't jo miskien nuttich fine:
- Sergey Berdnikov, Artyom Kalichkin - Súksesferhaal, of "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps op skaal: in Grykske trageedzje yn trije bedriuwen (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Sjoch ris nei DevOops 2020 Moskou - dêr binne ek in protte nijsgjirrige dingen.
Boarne: www.habr.com