SpÞrgsmÄlet "hvordan man implementerer DevOps" har vÊret aktuelt i flere Är, men der er ikke mange gode materialer. Nogle gange bliver du offer for reklamer fra ikke sÊrlig kloge konsulenter, der skal sÊlge deres tid, ligegyldigt hvordan. Nogle gange er det uklare, meget generelle ord om, hvordan kÊmpeselskabers skibe sejler pÄ universets vande. SpÞrgsmÄlet opstÄr: hvad har vi egentlig ud af det? KÊre forfatter, kan du tydeligt formulere dine idéer i en liste?
Alt dette skyldes, at der ikke er samlet meget reel praksis og forstĂ„else af udfaldet af virksomhedskulturens transformationer. Ăndringer i kulturen er langsigtede ting, hvis resultater ikke vil vise sig pĂ„ en uge eller en mĂ„ned. Vi har brug for nogen, der er tilpas gammeldags, som har set virksomheder blive skabt og nedlagt over mange Ă„r.
John Willis â en af fĂŠdrene til DevOps. John har mange Ă„rs erfaring med at arbejde med et stort antal virksomheder. PĂ„ det seneste har John bemĂŠrket specifikke mĂžnstre, der opstĂ„r i arbejdet med hver enkelt af dem. Ved at bruge disse arketyper vejleder John virksomhederne pĂ„ den rigtige vej til DevOps-transformation. LĂŠs mere om disse arketyper i oversĂŠttelsen af hans prĂŠsentation fra DevOops 2018-konferencen.
Om foredragsholderen:
Over 35 Ă„rs erfaring inden for IT-ledelse, deltager i udviklingen af en forgĂŠnger til OpenCloud i Canonical, har vĂŠret involveret i 10 startups, hvoraf to blev solgt til Dell og Docker. I Ăžjeblikket er han Vice President of DevOps and Digital Practices hos SJ Technologies.
DernĂŠst â en fortĂŠlling fra Johns synspunkt.
Mit navn er John Willis, og du kan nemmest finde mig pÄ Twitter, . Det er ogsÄ mit pseudonym pÄ Gmail og GitHub. Og kan du finde optagelser af mine foredrag og tilhÞrende prÊsentationer.
Jeg har mange mÞder med CIO'er fra forskellige store virksomheder. De klager ofte over, at de ikke forstÄr, hvad DevOps er, og at alle, der forsÞger at forklare det, taler om noget helt anderledes. En anden hyppig klage er, at DevOps ikke fungerer, selvom direktÞrerne tilsyneladende gÞr alt, som de har fÄet at vide. Det drejer sig om store virksomheder, der har eksisteret i hundrede Är eller mere. Efter at have talt med dem, konkluderede jeg, at mange problemer bedst lÞses med forholdsvis lavteknologiske lÞsninger snarere end avancerede teknologier. I ugevis talte jeg simpelthen med folk fra forskellige afdelinger. Det, du ser pÄ det allerfÞrste billede i indlÊgget, er mit seneste projekt; rummet sÄ sÄdan ud efter tre dages arbejde.
Hvad er DevOps?
Hvis du spÞrger ti forskellige personer, vil de give ti forskellige svar. Men det interessante er, at alle disse ti svar vil vÊre rigtige. Der er ikke noget forkert svar her. Jeg har arbejdet dybt med DevOps i cirka ti Är og var den fÞrste amerikaner til den fÞrste DevOpsDay. Jeg vil ikke pÄstÄ, at jeg er klogere end alle andre, der beskÊftiger sig med DevOps, men jeg tvivler pÄ, at der er nogen, der har brugt sÄ meget energi pÄ det. Jeg mener, at DevOps opstÄr, nÄr menneskelig kapital og teknologi mÞdes. Vi glemmer ofte den menneskelige dimension, selvom vi taler meget om alle mulige kulturer.
Nu har vi mange data, fem Ärs akademisk forskning og en afprÞvning af teorier pÄ industriel skala. Denne forskning viser os fÞlgende: hvis visse adfÊrdsmÞnstre kombineres i organisationskulturen, kan man opnÄ en acceleration pÄ 2000 gange. Denne acceleration svarer til en tilsvarende forbedring i robusthed. Det er en kvantitativ mÄling af den fordel, som DevOps kan give enhver virksomhed. For et par Är siden talte jeg om DevOps til en administrerende direktÞr fra en Fortune 5000-virksomhed. Da jeg forberedte mig til prÊsentationen, var jeg meget nervÞs, fordi jeg skulle opsummere mine mange Ärs erfaring pÄ fem minutter.
Som resultat gav jeg fĂžlgende definition af DevOps: det er et sĂŠt praksisser og mĂžnstre, der muliggĂžr at omdanne menneskelig kapital til hĂžjtydende organisatorisk kapital. Et eksempel er, hvordan Toyota har arbejdet de sidste 50 eller 60 Ă„r.
(Disse skemaer prĂŠsenteres ikke som referencemateriale, men som illustration. Deres indhold vil variere for hver ny virksomhed. Alligevel kan billedet ses individuelt og forstĂžrres
En af de mest succesfulde sÄdanne praksisser er value stream mapping. Der er skrevet flere gode bÞger om dette, og forfatteren af de mest succesfulde af dem er Karen Martin. Men det sidste Är er jeg kommet til den konklusion, at selv denne tilgang er for hÞjteknologisk. Den har bestemt mange fordele, og jeg har brugt den meget. Men nÄr en administrerende direktÞr spÞrger dig, hvorfor hans virksomhed ikke kan skifte til nye spor, er det for tidligt at tale om value stream mapping. Der er mange langt mere fundamentale spÞrgsmÄl, der fÞrst skal besvares.
Jeg mener, at fejlen hos mange af mine kolleger er, at de blot giver virksomheden en vejledning pÄ fem punkter, og derefter vender de tilbage efter et halvt Är for at se, hvad der er sket. Selv med et godt skema som value stream mapping er der, sÄ at sige, blinde zoner. Efter hundreder af interviews med direktÞrer for forskellige virksomheder har jeg udviklet et bestemt mÞnster, der gÞr det muligt at opdele problemet i komponenter, og nu vil vi diskutere hver af disse komponenter i rÊkkefÞlge. FÞr jeg anvender nogen teknologiske lÞsninger, bruger jeg dette mÞnster, og resultatet er, at alle vÊgge ender med at vÊre fyldt med skemaer. For nylig arbejdede jeg med en gensidig fond, og jeg endte med 100-150 sÄdanne skemaer.
DĂ„lig kultur spiser gode tilgange til morgenmad
Hovedtanken er denne: intet Lean, Agile, SAFE eller DevOps vil hjÊlpe, hvis virksomhedens kultur er dÄrlig. Det er som at dykke i dybden uden dykkerudstyr eller operere uden rÞntgenbillede. Med andre ord, for at parafrasere Drucker og Deming: en dÄrlig organisationskultur vil opsluge ethvert godt system og ikke kvÊles.
For at lĂžse dette hovedproblem skal fĂžlgende skridt tages:
- GÞr alt arbejde synligt: du skal gÞre alt arbejde synligt. Ikke i den forstand, at det nÞdvendigvis skal vises pÄ en skÊrm, men i den forstand, at det skal kunne observeres.
- Konsolider arbejdshÄndteringssystemer: det er nÞdvendigt at konsolidere ledelsessystemerne. I problemet med «stammekendskab» og institutionelt kendskab er menneskene i 9 ud af 10 tilfÊlde flaskehalsene. I bogen var problemet i én enkelt person, Brent, som fik projektet til at blive tre Är forsinket. Og jeg stÞder pÄ sÄdanne «Brent» overalt. For at lÞse disse flaskehalse anvender jeg fÞlgende to punkter pÄ vores liste.
- Theory of Constraints Methodology: teori om begrĂŠnsninger.
- Collaboration hacks: samarbejdshacks.
- Toyota Kata (): jeg vil ikke tale meget om Toyota Kata. Hvis du er interesseret, har jeg pÄ min GitHub om nÊrmest hver af disse emner.
- Market Oriented Organization: markedsorienteret organisation.
- Shift-left auditors: revision i de tidlige faser af cyklussen.
Jeg starter arbejdet med organisationen meget simpelt: jeg gÄr ind i virksomheden og taler med medarbejderne. Som vi ser, er der ingen hÞj teknologi. Alt der krÊves er, at der er noget at skrive med. Jeg samler flere teams i et rum og analyserer, hvad de fortÊller mig, ud fra mine 7 arketyper. SÄ giver jeg dem selv en markÞr og beder dem udtrykke alt det, de indtil nu har sagt hÞjt, skriftligt pÄ tavlen. Normalt er der én person til stede pÄ sÄdanne mÞder, der skriver alt ned, og i bedste fald fÄr han indfanger 10% af diskussionen. Ved min metode lykkes det at hÊve denne procentdel til omkring 40%.
(Separat kan denne illustration )
Mit tilgang er baseret pÄ arbejde af William Schneider (William Schneider, ). Grundtanken i tilgangen er, at enhver organisation kan opdeles i fire kvadrater. Dette diagram er typisk resultatet af mit arbejde med de hundredvis af andre diagrammer, der opstÄr under analysen af organisationen. Antag, at vi har en organisation med hÞj kontrol, men samtidig med lav kompetence. Dette er en yderst uÞnsket situation: nÄr alle gÄr efter reglerne, men ingen ved, hvad der skal gÞres.
En bedre mulighed med hÞjt niveau af bÄde kontrol og kompetence. Hvis en virksomhed er profitabel, er DevOps mÄske ikke nÞdvendigt for dem. Det mest interessante er at arbejde med en virksomhed, som har hÞjt niveau af kontrol, lav kompetence og samarbejde, men samtidig en hÞj kultur (cultivation). Det betyder, at der er mange mennesker i virksomheden, som nyder at arbejde der, og medarbejderomsÊtningen er lav.
(Separat kan denne illustration )
Jeg tror, at metoder med strenge retningslinjer i sidste ende hindrer os i at nÄ sandheden. IsÊr i value stream mapping er der mange regler om, hvordan information skal struktureres. I de tidlige faser, som jeg taler om nu, er disse regler unÞdvendige. Hvis en person med en marker i hÄnden beskriver den reelle situation i virksomheden pÄ en tavle, er det den bedste mÄde at fÄ indsigt i situationen. Den information nÄr aldrig op til lederne. I det Þjeblik er det dumt at afbryde personen og sige, at de har tegnet en pil forkert. I denne fase er det bedre at bruge enkle regler, for eksempel kan man skabe en flerlagdet abstraktion ved bare at bruge farverige markÞrer.
Jeg gentager, ingen hÞjteknologi. Den objektive virkelighed, hvordan alt fungerer, tegnes med sort marker. Med rÞd marker angiver folk, hvad de ikke kan lide ved den nuvÊrende situation. Det er vigtigt, at det er dem, der skriver det, og ikke mig. NÄr jeg efter mÞdet gÄr til IT-direktÞren, prÊsenterer jeg ikke en liste med 10 ting, der skal rettes. Jeg forsÞger at finde forbindelser mellem det, som folk siger i virksomheden, og eksisterende bekrÊftede mÞnstre. Til sidst foreslÄr man mulige lÞsninger pÄ problemet med den blÄ marker.
(Separat kan denne illustration )
Et eksempel pÄ denne tilgang er vist ovenfor. I begyndelsen af dette Är arbejdede jeg med en bank. Medarbejdere fra sikkerhedsafdelingen der var overbeviste om, at de ikke mÄtte deltage i krav- og designgennemgange (design and requirement reviews).
(Separat kan denne illustration )
Og sÄ talte vi med folk fra andre afdelinger og fandt ud af, at for omkring 8 Är siden havde softwareudviklerne ekskluderet sikkerhedsmedarbejderne, fordi de forsinkede arbejdet. Og sÄ blev det til et forbud, der blev opfattet som en given ting. Selvom der reelt ikke var noget forbud.
Vores mÞde forlÞb pÄ en ekstremt forvirrende mÄde: i omkring tre timer kunne fem forskellige teams slet ikke forklare mig, hvad der sker mellem koden og bygningen. Og det burde egentlig vÊre den enkleste ting. De fleste DevOps-konsulenter antager pÄ forhÄnd, at alle allerede kender dette.
SĂ„ pludselig gik personen, der stod for IT-reguleringen (IT governance), der havde vĂŠret tavs i fire timer, i gang, da vi nĂ„ede til hans emne, og han optog os i lang tid. Til sidst spurgte jeg ham, hvad han tĂŠnkte om mĂždet, og jeg vil aldrig glemme hans svar. Han sagde: âTidligere troede jeg, at der kun var to metoder til at levere software i vores bank, men nu ved jeg, at der er hele fem, og at jeg ikke engang anede, at der var tre af dem.â
(Separat kan denne illustration )
Det sidste mÞde i denne bank var med teamet, der arbejdede med software til investeringer. Det viste sig, at det er bedre at skrive diagrammer med en tusch pÄ papir end pÄ en tavle, og endda bedre end pÄ en smartboard.
Billederne, du ser, er hvordan konferencerummet i hotellet sÄ ud pÄ den fjerde dag af vores mÞde. Og disse diagrammer brugte vi til at finde mÞnstre, det vil sige archetyper.
SÄ jeg stiller spÞrgsmÄl til medarbejderne, de skriver deres svar med tuscher i tre farver (sort, rÞd og blÄ). Jeg analyserer deres svar for archetyper. Lad os nu diskutere alle archetyperne i rÊkkefÞlge.
1. Make All Work Visible: GĂžre al arbejde synligt
I de fleste virksomheder, jeg arbejder med, er der en meget hÞj procentdel af ukendt arbejde. For eksempel nÄr en medarbejder gÄr til en anden og bare beder om at fÄ noget gjort. I store organisationer kan op til 60% af arbejdet vÊre uplanlagt. Og op til 40% af arbejdet er slet ikke dokumenteret. Hvis det var Boeing, ville jeg aldrig sÊtte mig ind i deres fly igen. Hvis kun halvdelen af arbejdet bliver dokumenteret, er det uklart, om dette arbejde bliver udfÞrt korrekt eller ej. Alle andre metoder viser sig at vÊre ubrugelige - der er ikke nogen mening i at forsÞge at automatisere noget, fordi de kendte 50% muligvis er den mest velkoordinerede og prÊcise del af arbejdet, hvor automatisering ikke vil give store resultater, mens det vÊrste findes i den usynlige halvdel. Uden dokumentation er det umuligt at finde forskellige hacks og skjult arbejde, samt identificere flaskehalse og de sÄkaldte 'Brent's', som jeg allerede har nÊvnt. Der er en fremragende bog skrevet af Dominica DeGrandis. . Den identificerer fem forskellige 'tidstyve' (thieves of time):
- For meget arbejde i proces (WIP)
- Ukendte afhĂŠngigheder
- Uplanlagt arbejde
- Modstridende prioriteter
- ForsĂžmt arbejde
Dette er en meget vÊrdifuld analyse, og bogen er fantastisk, men alle disse rÄd er nyttelÞse, hvis kun 50% af dataene er synlige. Metoderne foreslÄet af Dominica kan anvendes, hvis nÞjagtigheden er over 90%. Jeg taler om situationer, hvor chefen giver en medarbejder en opgave pÄ 15 minutter, men den tager tre dage; men chefen ved faktisk ikke, at denne medarbejder afhÊnger af fire eller fem andre personer.
Phoenix Project er en fascinerende fortÊlling om et projekt, der er tre Är forsinket. En af karaktererne stÄr over for opsigelse pÄ grund af dette, og han mÞder en anden karakter, der reprÊsenteres som en slags Sokrates. Denne hjÊlper med at klarlÊgge, hvad der prÊcist er gÄet galt. Det viser sig, at der i virksomheden er en systemadministrator ved navn Brent, og alt arbejde gÄr ind og ud af ham. PÄ et mÞde spÞrger en af underordnede: hvorfor tager hver halv times opgave en uge? Svaret er en meget forenklet forklaring pÄ kÞteori og Little's lov, og i denne forklaring viser det sig, at ved 90 % belÊgning tager hver arbejdstime 9 timer. Hver opgave skal sendes til syv andre personer, hvilket betyder, at den time bliver til 63 timer, 7 ganget med 9. Jeg siger dette for at pÄpege, at for at kunne anvende Little's lov eller nogen som helst kompleks kÞteori, skal man i det mindste have data.
NÄr jeg taler om synlighed, mener jeg ikke, at alt skal vÊre pÄ skÊrmen, men at man mindst skal have dataene. NÄr de er til stede, viser det sig ofte, at der er en meget stor mÊngde planlagt arbejde, som af en eller anden grund sendes til Brent, selvom der ikke er nogen nÞdvendighed for det. Brent er en fantastisk fyr, han vil aldrig sige 'nej', men han fortÊller aldrig nogen, hvordan han udfÞrer sit arbejde.
NÄr arbejdet er synligt, kan dataene omhyggeligt klassificeres (det er netop, hvad Dominika gÞr pÄ billedet), man kan anvende abstrahering af fem tidstyve, og man kan automatisere.
2. Konsolider arbejdsstyringssystemer: Opgavestyring
De arketyper, jeg taler om, udgĂžr en form for pyramide. Hvis den fĂžrste udfĂžres korrekt, fungerer den anden som en form for overbygning. Mange af dem virker ikke for startups; de skal overvejes i forbindelse med store virksomheder, der kommer pĂ„ Fortune 5000-listen. I den sidste virksomhed, hvor jeg arbejdede, var der 10 systemer til fejlhĂ„ndtering (ticketing system). Ăn gruppe brugte Remedy, en anden havde skrevet deres eget system, en tredje brugte Jira, og nogen klarede sig endda med e-mail. Det samme problem opstĂ„r, hvis et firma har 30 forskellige pipelines, men jeg har ikke tid til at diskutere alle disse tilfĂŠlde.
Jeg diskuterer med folk, hvordan billetter oprettes, hvad der sker med dem bagefter, og hvordan de omgÄs. Det mest interessante er, at folk pÄ vores mÞder taler ret Êrligt. Jeg spurgte, hvor mange der markerer 'mindre / ingen indvirkning' for billetter, der faktisk skulle have fÄet 'stor indvirkning'. Det viste sig, at nÊsten alle gÞr det. Jeg er ikke en anmelder og forsÞger pÄ alle mÄder ikke at identificere folk. NÄr jeg fÄr en oprigtig indrÞmmelse, afslÞrer jeg ikke personen. Men nÄr nÊsten alle omgÄr systemet, betyder det, at hele sikkerheden i bund og grund er en facade. SÄ man kan ikke drage nogen konklusioner ud fra dataene fra dette system.
For at lÞse problemet med billetterne er det nÞdvendigt at vÊlge et hovedsystem. Hvis du bruger Jira, sÄ lad det vÊre kun Jira. Hvis der er et alternativ, sÄ lad det vÊre kun det. Sagen er, at billetter skal betragtes som endnu et trin i udviklingsprocessen. Hver handling skal have en billet, som skal gennemlÞbe arbejdsprocessen for udviklingen. Billetter sendes til teamet, som placerer dem pÄ storyboardet, og derefter har ansvaret for dem.
Dette gÊlder for alle afdelinger, herunder bÄde infrastruktur- og driftsafdelingen. PÄ den mÄde kan man danne et hvilket som helst plausibelt billede af situationen. NÄr denne proces er etableret, viser det sig pludselig, at man nemt kan fastslÄ, hvem der har ansvaret for hver applikation. For nu fÄr vi ikke 50%, men 98% af de nye tjenester. Hvis denne centrale proces fungerer, sÄ Þges nÞjagtigheden i hele systemet.
Pipeline for tjenester
Det handler igen kun om store virksomheder. Hvis du er et nyt firma inden for et nyt omrÄde, sÄ opretter du dine Êrmer og arbejder med din Travis CI eller CircleCI. Hvad angÄr Fortune 5000-virksomheder, er der et relevant eksempel fra banken, hvor jeg arbejdede. De blev kontaktet af Google, som viste dem diagrammer med de gamle IBM-systemer. Google-folkene spurgte forundret: hvor er koden til dette? Der er ingen kildekode, ikke engang et GUI. Dette er den virkelighed, som store organisationer mÄ arbejde med: 40-Ärige bankoptegnelser pÄ en gammel mainframe. En af mine kunder bruger Kubernetes-containere med Circuit Breaker-mÞnstre plus Chaos Monkey, alt dette til KeyBank-applikationen. Men i sidste ende forbindes disse containere til en applikation skrevet i COBOL.
Google-folkene var overbevist om, at de ville lÞse alle mine kunders problemer, men begyndte sÄ at stille spÞrgsmÄl: hvad er IBM datapipe? De fÄr at vide: det er en connector. Hvad forbinder det? Til Sperry-systemet. Og hvad er det? Og sÄ videre. Ved fÞrste Þjekast ser det ud til, at der ikke kan vÊre nogen DevOps her. Men faktisk er det muligt. Der findes leveringssystemer, der gÞr det muligt at overfÞre workflow til de teams, der arbejder med leveringen.
3. Theory of Constraints: BegrĂŠnsningsteori
Lad os gÄ videre til den tredje arketype: institutionel / "stamme" viden. Som regel er der i enhver organisation et par personer, der ved alt og leder alle. Det er dem, der har vÊret lÊngst i organisationen, og som kender alle genveje.
NÄr dette identificeres pÄ diagrammet, markerer jeg med vilje sÄdanne personer med en markeringspen: for eksempel viser det sig, at en person ved navn Lou er til stede ved alle mÞder. Og for mig er det klart: han er den lokale Brent. NÄr IT-chefen vÊlger mellem mig i T-shirt og sneakers og en fyr fra IBM i jakkesÊt, vÊlger de mig, fordi jeg kan fortÊlle chefen om ting, som den anden fyr ikke vil fortÊlle, og som chefen mÄske ikke Þnsker at hÞre. Jeg fortÊller dem, at der er et flaskehals i deres firma, der hedder Fred og en der hedder Lou. Denne flaskehals skal lÞses, og deres viden skal pÄ en eller anden mÄde udvindes fra dem.
For at lĂžse denne type problem kan jeg for eksempel foreslĂ„ at bruge Slack. Den snedige direktĂžr ville spĂžrge â hvorfor? Typisk vil DevOps-konsulenter i sĂ„danne tilfĂŠlde svare: fordi alle andre gĂžr det. Hvis direktĂžren er virkelig snedig, vil han sige: og sĂ„? Og sĂ„ er dialogen sluttet. Og jeg svarer: fordi der i virksomheden er fire flaskehalse, Fred, Lou, Suzy og Jane. For at gĂžre deres viden institutionaliseret, skal Slack indfĂžres. Alle jeres wikis er totalt vĂŠrdilĂžse, fordi ingen ved, at de eksisterer. Hvis ingeniĂžrteamet arbejder med ekstern og intern udvikling, skal alle vide, at de kan kontakte den eksterne udvikling eller infrastrukturteamet med spĂžrgsmĂ„l. Lige dĂ©r kan det vĂŠre, at Lou eller Fred fĂ„r tid til at tilfĂžje noget til wikis. Og senere kan nogen i Slack spĂžrge, hvorfor for eksempel trin 5 ikke virker. Og sĂ„ vil Lou eller Fred rette vejledningen i wikis. Hvis denne proces er pĂ„ plads, vil meget af sig selv falde pĂ„ plads.
Mit hovedbudskab er: for at anbefale hÞjteknologi, skal man fÞrst fÄ fundamentet pÄ plads, og dette kan gÞres med de lavteknologiske lÞsninger, jeg netop har beskrevet. Hvis man derimod starter med hÞjteknologi uden at forklare, hvorfor de er nÞdvendige, ender det som regel ikke godt. En af vores kunder bruger Azure ML, et meget billigt og simpelt lÞsning. Omkring 30% af deres spÞrgsmÄl blev allerede besvaret af den selvlÊrende maskine. Og denne lÞsning blev udviklet af operatÞrer, der ikke havde erfaring med data science, statistik eller matematik. Det er sigende. Omkostningerne ved denne lÞsning er minimale.
4. Samarbejds hacks: Hacks til samarbejde
Den fjerde arketype handler om, at man skal bekĂŠmpe isolation. De fleste mennesker ved allerede: isolation skaber fjendskab. Hvis hver afdeling er pĂ„ sin egen etage, og folk kun mĂždes i elevatoren, sĂ„ opstĂ„r fjendskab let mellem dem. Men hvis folk derimod er i samme rum, forsvinder det straks. NĂ„r nogen fremsĂŠtter en fĂŠlles anklage, for eksempel at en bestemt grĂŠnseflade aldrig fungerer â sĂ„ er det ikke svĂŠrt at dekonstruere sĂ„dan en anklage. ProgrammĂžrerne, der har skrevet grĂŠnsefladen, skal blot begynde at stille konkrete spĂžrgsmĂ„l, og snart vil det vise sig, at brugeren bare har brugt vĂŠrktĂžjet forkert.
Der er mange mĂ„der at overvinde isolation pĂ„. Jeg blev engang bedt om at rĂ„dgive en bank i Australien, men jeg afslog, fordi jeg har to bĂžrn og en kone. Alt hvad jeg kunne hjĂŠlpe dem med â jeg anbefalede dem grafisk storytelling. Det er noget, der viser sig at virke. En anden interessant metode er mĂžder i lean coffee-format. I en stor organisation er det en udmĂŠrket mĂ„de at sprede viden pĂ„. Derudover kan man afholde interne devopsdays, hackathons og sĂ„ videre.
5. Coaching Kata
Som jeg allerede har advaret om i starten, vil jeg ikke tale om dette i dag. Hvis du er interesseret, kan du tage et kig pÄ .
Der er ogsÄ et godt foredrag om dette emne fra Mike Rother:
6. Market Oriented: markedsorienteret organisation
Her er der forskellige problemer. For eksempel, "I" mennesker, "T" mennesker og "E" mennesker. "I" mennesker er dem, der kun beskĂŠftiger sig med Ă©n ting. Normalt eksisterer de i organisationer med isolerede afdelinger. "T" er, hvis en person er dygtig til Ă©n ting, men ogsĂ„ excel pĂ„ nogle andre omrĂ„der. "E" eller endda "kĂŠmpe" â nĂ„r en person har mange fĂŠrdigheder.
Her gÊlder Conways lov (), som i en maximalt forenklet form kan opsummeres sÄdan: hvis tre teams arbejder pÄ en compiler, ender man med en compiler bestÄende af tre dele. Derfor, hvis der i organisationen er et hÞjt niveau af isolation, sÄ vil selv Kubernetes, Circuit breaker, API extensibility og andre trendy ting i denne organisation vÊre struktureret pÄ samme mÄde som selve organisationen. Strengt ifÞlge Conway og trods alt jer, unge nÞrder.
Problemet er blevet beskrevet mange gange. Der er for eksempel organisatoriske arketyper, beskrevet af Fernando Fernandez. Den problematiske arkitektur, jeg netop har nĂŠvnt, med isolation â det er en funktionsorienteret arkitektur. Den anden type â den vĂŠrste, er den matrixarkitektur, hvor der er en blanding af de to andre. Den tredje â er den, der ses i de fleste startups, og som store virksomheder ogsĂ„ forsĂžger at tilpasse sig. Det er en markedsorienteret organisation. Her sker der en optimering for at opnĂ„ den hurtigst mulige respons pĂ„ kundernes forespĂžrgsler. Nogle gange kaldes dette en flad organisation.
Denne struktur beskriver mange forskelligt, jeg kan lide formuleringen build/run teams, i Amazon kaldes det two pizza teams. I denne struktur samles alle personer af typen 'I' omkring en enkelt service, og gradvist bliver de tÊttere pÄ typen 'T', og hvis ledelsen er korrekt, kan de til og med blive 'E'. Det fÞrste modargument her er, at der i en sÄdan struktur er overflÞdige elementer. Hvorfor have en tester i hvert afdeling, hvis man kan have en specialiseret testafdeling? Til dette svarer jeg: overflÞdige udgifter er i dette tilfÊlde prisen for, at hele organisationen i fremtiden kan blive type 'E'. I en sÄdan struktur lÊrer testeren gradvist om netvÊrk, arkitektur, design og sÄ videre. I sidste ende er hver deltager i organisationen fuldt informeret om alt, hvad der sker i organisationen. Hvis du vil vide, hvordan dette system fungerer i industrien, sÄ lÊs .
7. Shift-left auditors: revision i de tidlige faser af cyklus. Overholdelse af sikkerhedsregler belyst
Det er, nĂ„r ens handlinger ikke, sĂ„ at sige, bestĂ„r lugttesten. Folk, der arbejder for dig, er ikke dumme. Hvis de, som i eksemplet ovenfor, har angivet minor/no impact overalt, og det har varet i tre Ă„r, og ingen har bemĂŠrket noget, sĂ„ ved alle, at systemet ikke fungerer. Eller et andet eksempel â rĂ„d om ĂŠndringer (change advisory board), hvor hver onsdag man skal indsende rapporter. Der arbejder en gruppe mennesker (for Ăžvrigt ikke alt for godt betalt), som i teorien burde vide, hvordan systemet fungerer som helhed. Og i de sidste fem Ă„r har du sikkert bemĂŠrket, at vores systemer er vanvittigt komplekse. Og fem-seks personer skal trĂŠffe en beslutning om en ĂŠndring, de ikke har bidraget til, og som de ikke ved noget om.
SelvfÞlgelig fungerer en sÄdan tilgang ikke. Jeg mÄ slippe af med sÄdan noget, fordi disse mennesker ikke beskytter systemet. Beslutningen skal trÊffes af teamet selv, fordi teamet skal vÊre ansvarligt for den. Ellers opstÄr der en paradoxal situation, hvor en manager, der aldrig har skrevet kode i sit liv, fortÊller udvikleren, hvor lang tid det skal tage at skrive koden. I et firma, jeg arbejdede for, var der syv forskellige rÄd, der overvejede hver Êndring, herunder arkitekturrÄdet, produkt- osv. Der var endda en obligatorisk ventetid, selvom en medarbejder fortalte mig, at ingen nogensinde i lÞbet af ti Ärs ansÊttelse har afvist Êndringer, som denne person har foreslÄet, inden for den obligatoriske periode.
Revisorer skal inviteres, ikke skubbes vĂŠk. FortĂŠl dem, at du skriver uforanderlige binĂŠre containere, som, hvis de bestanden alle tests, forbliver uĂŠndrede for altid. FortĂŠl dem, at du har pipeline as code, og forklar hvad det betyder. Vis dem fĂžlgende diagram: uforanderlig binĂŠr kun til lĂŠsning i en container, der har bestĂ„et alle sĂ„rbarhedstests; og dernĂŠst rĂžr ingen ved det â ikke engang systemet, der skaber pipeline, da det ogsĂ„ oprettes dynamisk. Jeg har kunder, Capital One, som ved hjĂŠlp af Vault skaber noget lignende en blockchain. Revisoren behĂžver ikke at se "opskrifterne" fra Chef, det er tilstrĂŠkkeligt at vise blockchainen, som klart viser, hvad der skete med Jira-ticketen i produktionen, og hvem der er ansvarlig for den.
IfĂžlge , oprettet i 2018, blev der i 2017 registreret 87 milliarder downloads af OSS.
Tabene forÄrsaget af sÄrbarheder er uforholdsmÊssigt hÞje. Desuden inkluderer de tal, du ser ovenfor, ikke alternativer omkostninger. Kort om, hvad DevSecOps er. Jeg vil straks sige, at jeg ikke er interesseret i diskussioner om, hvorvidt dette navn er vellykket. Pointen er, at nÄr DevOps var meget succesfulde, sÄ skal der prÞves at tilfÞje sikkerhed til denne pipeline.
Et eksempel pÄ en sÄdan sekvens:
Dette er ikke en anbefaling af bestemte produkter, selvom jeg synes godt om dem alle. Jeg nÊvner dem som eksempler for at vise, at DevOps, der oprindeligt er baseret pÄ en industriel organisationsparadigme, kan automatisere hver fase af produktarbejdet.
Og der er ingen grund til, at vi ikke kunne anvende den samme tilgang til sikkerhed.
Resultat
Som afslutning vil jeg give et par rĂ„d til DevSecOps. Det er vigtigt at inkludere revisorer i processen med at opbygge jeres systemer og at bruge tid pĂ„ deres uddannelse. Samarbejd med revisorerne. DernĂŠst skal der fĂžres en absolut nĂ„deslĂžs kamp mod falske alarmer. Selv med det dyreste vĂŠrktĂžj til scanning af sĂ„rbarheder kan man ende med at skabe skadelige vaner hos jeres udviklere, hvis man ikke ved, hvordan signalet stĂ„r i forhold til stĂžj. Udviklerne vil ende med at blive overvĂŠldet af hĂŠndelser, og de vil blot slette dem. Hvis du har hĂžrt om historien med Equifax, sĂ„ skete der noget lignende der; et signal af hĂžjeste fare blev ignoreret. Desuden skal sĂ„rbarheder forklares, sĂ„ det er klart, hvordan de pĂ„virker forretningen. For eksempel kan det nĂŠvnes, at det er den samme sĂ„rbarhed som i historien med Equifax. Sikkerhedsrelaterede sĂ„rbarheder skal behandles ligesom andre softwareproblemer, det vil sige, de skal indgĂ„ i den samlede DevOps-proces. De skal behandles gennem Jira, Kanban osv. Udviklerne mĂ„ ikke tro, at dette er noget, nogen andre skal tage sig af â tvĂŠrtimod skal alle vĂŠre involveret. Endelig skal der investeres ressourcer i at uddanne folk.
Nyttige links
Her er et par prÊsentationer fra DevOops-konferencen, som du mÄske finder nyttige:
- Sergey Berdnikov, Artyom Kalichkin â En succeshistorie, eller 'Dev+DevOps+Ops' (, )
- Baruch Sadogursky, Leonid Igolnik â DevOps i stor skala: en grĂŠsk tragedie i tre akter (, )
- Alexander Titov, Kirill Tolkachev â
- Timothy Lister â
Tag et kig pĂ„ DevOops 2020 Moscow â der er ogsĂ„ meget interessant der.
Kilde: habr.com
