Spørgsmålet "hvordan implementeres devops" har eksisteret i årevis, men der er ikke mange gode materialer. Nogle gange bliver du offer for reklamer fra knap så smarte konsulenter, der skal sælge deres tid, uanset hvordan. Nogle gange er disse vage, ekstremt generelle ord om, hvordan megaselskabers skibe pløjer universets vidder. Spørgsmålet opstår: hvad betyder det for os? Kære forfatter, kan du tydeligt formulere dine ideer i en liste?
Alt dette skyldes det faktum, at der ikke er akkumuleret meget reel praksis og forståelse for resultatet af transformationer af virksomhedens kultur. Ændringer i kulturen er langsigtede ting, hvis resultater ikke vises om en uge eller en måned. Vi har brug for en, der er gammel nok til at have set, hvordan virksomheder er blevet bygget og svigtet gennem årene.
John Willis - en af DevOps' fædre. John har årtiers erfaring med at arbejde med et stort antal virksomheder. For nylig begyndte John at bemærke specifikke mønstre, der finder sted, når han arbejder med hver af dem. Ved hjælp af disse arketyper guider John virksomheder på den sande vej til DevOps-transformation. Læs mere om disse arketyper i oversættelsen af hans rapport fra DevOops 2018-konferencen.
Om taleren:
Mere end 35 år i IT-ledelse, deltog i skabelsen af forgængeren til OpenCloud hos Canonical, deltog i 10 startups, hvoraf to blev solgt til Dell og Docker. I øjeblikket er han Vice President for DevOps og Digital Practices hos SJ Technologies.
Dernæst er historien fra Johns synspunkt.
Mit navn er John Willis og det nemmeste sted at finde mig er på Twitter, . Jeg har det samme alias på Gmail og GitHub. EN kan du finde videooptagelser af mine rapporter og præsentationer til dem.
Jeg har mange møder med CIO'er i forskellige store virksomheder. De klager meget ofte over, at de ikke forstår, hvad DevOps er, og alle, der forsøger at forklare dem, taler om noget andet. En anden almindelig klage er, at DevOps ikke virker, selvom det ser ud til, at direktørerne gør alt som forklaret for dem. Vi taler om store virksomheder, der er mere end hundrede år gamle. Efter at have snakket med dem kom jeg frem til, at for mange problemer er det ikke højteknologi, der er bedst egnet, men derimod relativt lavteknologiske løsninger. I ugevis talte jeg bare med folk fra forskellige afdelinger. Det du ser på det allerførste billede i indlægget er mit sidste projekt, sådan så rummet ud efter tre dages arbejde.
Hvad er DevOps?
Faktisk, hvis du spørger 10 forskellige mennesker, vil de give 10 forskellige svar. Men her er det interessante: alle disse ti svar vil være rigtige. Der er ikke noget forkert svar her. Jeg var ret dybt inde i DevOps i omkring 10 år, og var den første amerikaner på den første DevOpsDay. Jeg vil ikke sige, at jeg er klogere end alle involverede i DevOps, men der er næppe nogen, der har brugt så mange kræfter på det. Jeg tror på, at DevOps opstår, når menneskelig kapital og teknologi mødes. Vi glemmer ofte den menneskelige dimension, selvom vi taler meget om alle slags kulturer.
Nu har vi en masse data, fem års akademisk forskning, test af teorier i industriel skala. Hvad disse undersøgelser fortæller os er, at hvis du kombinerer nogle adfærdsmønstre i en organisationskultur, kan du opnå en 2000x speedup. Denne acceleration modsvares af en tilsvarende forbedring af stabiliteten. Dette er en kvantitativ måling af fordelen, som DevOps kan give enhver virksomhed. For et par år siden talte jeg om DevOps til administrerende direktør for et Fortune 5000-firma. Da jeg forberedte præsentationen, var jeg meget nervøs, fordi jeg skulle opsummere mine års erfaring på 5 minutter.
Til sidst gav jeg følgende Definition af DevOps: Det er et sæt af praksisser og mønstre, der muliggør transformation af menneskelig kapital til højtydende organisatorisk kapital. Et eksempel er den måde, Toyota har fungeret på i de sidste 50 eller 60 år.
(Herefter gives sådanne diagrammer ikke som referencemateriale, men som illustrationer. Deres indhold vil variere for hver ny virksomhed. Billedet kan dog ses separat og forstørres
En af de mest succesrige sådanne metoder er værdistrømsanalysen. Det er der skrevet flere gode bøger om, hvoraf de mest succesfulde er af Karen Martin. Men i løbet af det seneste år er jeg kommet til den konklusion, at selv denne tilgang er for højteknologisk. Det har bestemt mange fordele, og jeg har brugt det meget. Men når den administrerende direktør spørger dig, hvorfor hans virksomhed ikke kan skifte til nye skinner, er det for tidligt at tale om kortlægning af værdistrømme. Der er mange meget mere grundlæggende spørgsmål, som først skal besvares.
Jeg tror, at den fejl, mange af mine kolleger begår, er, at de simpelthen giver virksomheden en fem-punkts guide og så kommer tilbage seks måneder senere og ser, hvad der skete. Selv en god ordning som værdistrømskortlægning har, lad os sige, blinde vinkler. Efter hundredvis af interviews med direktører i forskellige virksomheder har jeg udviklet et bestemt mønster, der gør det muligt for os at nedbryde problemet i dets 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 som et resultat er alle mine vægge dækket af diagrammer. For nylig arbejdede jeg med en investeringsforening, og jeg endte med 100-150 sådanne ordninger.
Dårlig kultur spiser gode tilgange til morgenmad
Hovedideen er denne: ingen mængder af Lean, Agile, SAFE og DevOps vil hjælpe, hvis selve organisationens kultur er dårlig. Det er som at dykke til dybder uden dykkerudstyr eller operere uden røntgen. Med andre ord, for at omskrive Drucker og Deming: En dårlig organisationskultur vil opsluge ethvert godt system uden at blive kvalt i det.
For at løse dette hovedproblem skal du tage følgende trin:
- Gør alt arbejde synligt: du skal gøre alt arbejdet synligt. Ikke i den forstand, at det nødvendigvis skal vises på en eller anden skærm, men i den forstand, at det skal kunne observeres.
- Konsoliderede arbejdsledelsessystemer: ledelsessystemerne skal konsolideres. I problemet med "stammeviden" og institutionel viden er flaskehalsen i 9 ud af 10 tilfælde mennesker. I bogen problemet var med en enkelt person, Brent, som fik projektet til at være tre år forsinket. Og jeg støder på disse "Brents" overalt. For at løse disse flaskehalse bruger jeg de næste to punkter på vores liste.
- Teori om begrænsninger Metode: teori om begrænsninger.
- Samarbejde hacks: samarbejde hacks.
- Toyota Kata (): Jeg vil ikke tale meget om Toyota Kata. Hvis du er interesseret, på min github om næsten alle disse emner.
- Markedsorienteret organisation: markedsorienteret organisation.
- Skift-venstre revisorer: audit på de tidlige stadier af cyklussen.
Jeg begynder at arbejde med en organisation meget simpelt: Jeg går til virksomheden og snakker med medarbejderne. Som du kan se, ingen højteknologi. Alt du behøver er noget at skrive på. Jeg samler flere teams i ét rum og analyserer, hvad de fortæller mig ud fra mine 7 arketypers perspektiv. Og så giver jeg dem selv en tusch og beder dem skrive alt, hvad de har sagt højt indtil videre på tavlen. Normalt er der i den slags møder én person, der skriver alt ned, og i bedste fald kan han skrive 10 % af diskussionen ned. Med min metode kan dette tal hæves til omkring 40%.
(Denne illustration kan ses separat )
Min tilgang er baseret på William Schneiders arbejde. ). Tilgangen er baseret på ideen om, at enhver organisation kan opdeles i fire firkanter. Denne ordning for mig er normalt resultatet af at arbejde med de hundredvis af andre ordninger, der opstår, når man analyserer en organisation. Antag, at vi har en organisation med et højt kontrolniveau, men med lav kompetence. Dette er en ekstremt uønsket mulighed: når alle står på linjen, men ingen ved, hvad de skal gøre.
En lidt bedre mulighed er en med et højt niveau af både kontrol og kompetence. Hvis sådan en virksomhed er rentabel, har den måske ikke brug for DevOps. Det er mest interessant at arbejde med en virksomhed, der har en høj grad af kontrol, lav kompetence og samarbejde, men samtidig et højt niveau af kultur (dyrkning). Det betyder, at virksomheden har mange mennesker, der kan lide at arbejde der, og arbejdsomsætningen er lav.
(Denne illustration kan ses separat )
Det forekommer mig, at metoder med stive retningslinjer ender med at komme i vejen for at opnå sandheden. Især inden for værdistrømskortlægning er der mange regler for, hvordan information skal struktureres. I de tidlige stadier af arbejdet, som jeg taler om nu, har ingen brug for disse regler. Hvis en person med en markør i hænderne beskriver den reelle situation i virksomheden i bestyrelsen, er dette den bedste måde at forstå tingenes tilstand på. Sådanne oplysninger når ikke direktørerne. I dette øjeblik er det dumt at afbryde personen og sige, at han tegnede en eller anden form for pil forkert. På dette stadium er det bedre at bruge enkle regler, for eksempel: abstraktion på flere niveauer kan oprettes blot ved at bruge flerfarvede markører.
Jeg gentager, ingen højteknologi. Den sorte markør skildrer den objektive virkelighed af, hvordan alting fungerer. Med en rød markør markerer folk, hvad de ikke kan lide ved den aktuelle situation. Det er vigtigt, at de skriver dette, ikke mig. Når jeg går til CIO'en efter et møde, tilbyder jeg ikke en liste med 10 ting, der skal rettes. Jeg stræber efter at finde sammenhænge mellem det, folk i virksomheden siger, og eksisterende dokumenterede mønstre. Til sidst foreslår en blå markør mulige løsninger på problemet.
(Denne illustration kan ses separat )
Et eksempel på denne fremgangsmåde er nu afbildet ovenfor. I begyndelsen af dette år arbejdede jeg med én bank. Sikkerhedsfolkene der var overbeviste om, at de ikke skulle komme til design- og kravgennemgange.
(Denne illustration kan ses separat )
Og så talte vi med folk fra andre afdelinger, og det viste sig, at softwareudviklere for omkring 8 år siden fyrede sikkerhedsarbejdere, fordi de bremsede arbejdet. Og så blev det til et forbud, som blev taget for givet. Selvom der i virkeligheden ikke var noget forbud.
Vores møde forløb på en ekstremt forvirrende måde: i omkring tre timer kunne fem forskellige hold ikke forklare mig, hvad der skete mellem koden og forsamlingen. Og dette ser ud til at være den enkleste ting. De fleste DevOps-konsulenter antager på forhånd, at alle allerede ved dette.
Så kom den ansvarlige for IT-governance, som havde været tavs i fire timer, pludselig til live, da vi kom til hans emne, og optog os i meget lang tid. Til sidst spurgte jeg ham, hvad han mente om mødet, og jeg vil aldrig glemme hans svar. Han sagde: "Jeg plejede at tro, at vores bank kun havde to måder at levere software på, men nu ved jeg, at der er fem af dem, og jeg vidste ikke engang om tre."
(Denne illustration kan ses separat )
Det sidste møde i denne bank var med investeringssoftwareteamet. Det var hos hende, det viste sig, at det er bedre at skrive diagrammer med en tusch på et ark papir end på en tavle, og endda bedre end på et smartboard.
De billeder, du ser, er, hvordan hotellets konferencelokale så ud på den fjerde dag af vores møde. Og vi brugte disse skemaer til at søge efter mønstre, det vil sige arketyper.
Så jeg stiller spørgsmål til arbejderne, de skriver svarene ned med markører i tre farver (sort, rød og blå). Jeg analyserer deres svar for arketyper. Lad os nu diskutere alle arketyperne i rækkefølge.
1. Gør alt arbejde synligt: Gør arbejdet synligt
De fleste virksomheder, jeg arbejder med, har en meget høj procentdel af ukendt arbejde. Det er for eksempel, når en medarbejder kommer til en anden og blot beder om at gøre noget. I store organisationer kan der være tale om 60 % uplanlagt arbejde. Og op til 40 % af arbejdet er ikke dokumenteret på nogen måde. Hvis det var Boeing, ville jeg aldrig gå ombord på deres fly igen i mit liv. Hvis kun halvdelen af arbejdet er dokumenteret, så vides det ikke, om dette arbejde udføres korrekt eller ej. Alle andre metoder viser sig at være ubrugelige - det nytter ikke at forsøge at automatisere noget, fordi de kendte 50% kan være den mest sammenhængende og klare del af arbejdet, hvis automatisering ikke vil give store resultater, og alt det værste tingene er i den usynlige halvdel. I mangel af dokumentation er det umuligt at finde alle mulige hacks og skjult arbejde, ikke at finde flaskehalse, netop de "Brents", som jeg allerede talte om. Der er en vidunderlig bog af Dominica DeGrandis . Hun afslører fem forskellige "tidslækager" (tidstyve):
- 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 ubrugelige, hvis kun 50% af dataene er synlige. Metoderne foreslået af Dominica kan bruges, hvis der opnås en nøjagtighed på over 90%. Jeg taler om situationer, hvor en chef giver en underordnet en 15-minutters opgave, men det tager ham tre dage; men chefen ved ikke rigtig, at denne underordnede er afhængig af fire eller fem andre mennesker.
The Phoenix Project er en vidunderlig historie om et projekt, der var tre år for sent. En af karaktererne står over for afskedigelse på grund af dette, og han møder en anden karakter, der præsenteres som en slags Sokrates. Han hjælper med at finde ud af, hvad der præcist gik galt. Det viser sig, at virksomheden har én systemadministrator, hvis navn er Brent, og alt arbejde går på en eller anden måde gennem ham. På et af møderne bliver en af de underordnede spurgt: hvorfor tager hver halvtimesopgave en uge? Svaret er en meget forenklet fremstilling af køteori og Littles lov, og i denne præsentation viser det sig, at ved 90 % belægning tager hver times arbejde 9 timer. Hver opgave skal sendes til syv andre personer, så den time bliver 63 timer, 7 gange 9. Det, jeg siger, er, at for at bruge Little's Law eller en hvilken som helst kompleks køteori, skal du i det mindste have data.
Så når jeg taler om synlighed, mener jeg ikke, at alt er på skærmen, men at man i det mindste har data. Når de gør det, viser det sig ofte, at der er en meget stor mængde uplanlagt arbejde, der på en eller anden måde bliver sendt til Brent, når der ikke er behov for det. Og Brent er en fantastisk fyr, han vil aldrig sige nej, men han fortæller ikke nogen, hvordan han udfører sit arbejde.
Når værket er synligt, kan data klassificeres pænt (det er det, Dominika laver på billedet), abstraktionen af de fem tidslækager kan anvendes, og automatisering kan anvendes.
2. Konsolider arbejdsledelsessystemer: Opgavestyring
De arketyper, jeg taler om, er en slags pyramide. Hvis den første er udført korrekt, så er den anden allerede en slags tilføjelse. Mange af disse fungerer ikke for startups, de skal huskes for større virksomheder som Fortune 5000. Det sidste firma, jeg arbejdede for, havde 10 billetsystemer. Et hold havde Remedy, et andet skrev en form for sit eget system, et tredje brugte Jira, og nogle klarede sig med e-mail. Det samme problem opstår, hvis virksomheden har 30 forskellige rørledninger, men jeg har ikke tid til at diskutere alle sådanne sager.
Jeg diskuterer med folk præcis, hvordan billetter skabes, hvad der sker med dem næste gang, og hvordan de omgås. Det mest interessante er, at folk på vores møder taler ganske oprigtigt. Jeg spurgte, hvor mange der satte "mindre / ingen indvirkning" på billetter, der egentlig skulle have "større indflydelse". Det viste sig, at næsten alle gør dette. Jeg engagerer mig ikke i fordømmelse og forsøger på alle mulige måder ikke at identificere personer. Når de oprigtigt bekender noget for mig, giver jeg ikke personen væk. Men når næsten alle går uden om systemet, betyder det, at al sikkerhed i bund og grund er vinduespredning. Derfor kan der ikke drages konklusioner ud fra dataene i dette system.
For at løse billetproblemet skal du vælge ét hovedsystem. Hvis du bruger Jira, behold det Jira. Hvis der er noget alternativ, så lad det være det eneste. Den nederste linje er, at billetter skal ses som endnu et trin i udviklingsprocessen. Hver handling skal have en billet, som skal flyde gennem udviklingsarbejdsgangen. Billetter sendes til holdet, som lægger dem op på storyboardet og derefter tager ansvar for dem.
Det gælder alle afdelinger, herunder infrastruktur og drift. I dette tilfælde er det muligt at danne sig i det mindste en plausibel idé om tingenes tilstand. Når først denne proces er etableret, bliver det pludselig nemt at identificere, hvem der er ansvarlig for hver ansøgning. For nu modtager vi ikke 50 %, men 98 % af nye tjenester. Hvis denne kerneproces fungerer, forbedres nøjagtigheden i hele systemet.
Service pipeline
Dette gælder igen kun for store virksomheder. Hvis du er en ny virksomhed inden for et nyt felt, så smøg ærmerne op og arbejd med din Travis CI eller CircleCI. Når det kommer til Fortune 5000-virksomheder, et eksempel, der skete i den bank, hvor jeg arbejdede. Google kom til dem, og de fik vist diagrammer af gamle IBM-systemer. Fyrene fra Google spurgte forvirret - hvor er kildekoden til dette? Men der er ingen kildekode, ikke engang en GUI. Dette er den virkelighed, som store organisationer skal forholde sig til: 40 år gamle bankoptegnelser på en gammel mainframe. En af mine kunder bruger Kubernetes-beholdere med Circuit Breaker-mønstre, plus Chaos Monkey, alt sammen til KeyBank-applikationen. Men disse beholdere forbindes i sidste ende med en COBOL-applikation.
Fyrene fra Google var fuldstændig sikre på, at de ville løse alle min klients problemer, og så begyndte de at stille spørgsmål: hvad er IBM datapipe? De får at vide: dette er et stik. Hvad forbindes det med? Til Sperry-systemet. Og hvad er det? Og så videre. Ved første øjekast ser det ud til: Hvilken slags DevOps kan der være? Men faktisk er det muligt. Der findes leveringssystemer, der giver dig mulighed for at overdrage arbejdsgangen til leveringsteamene.
3. Theory of Constraints: Theory of Constraints
Lad os gå videre til den tredje arketype: institutionel/"stamme" viden. Som regel er der i enhver organisation flere mennesker, der ved alt og styrer alt. Det er dem, der har været længst i organisationen, og som kender alle løsningerne.
Når dette kommer op på diagrammet, kredser jeg specifikt om sådanne mennesker med en markør: for eksempel viser det sig, at en bestemt Lou er til stede ved alle møder. Og det er klart for mig: det her er lokale Brent. Når CIO'en vælger mellem mig i T-shirt og sneakers og fyren fra IBM i jakkesæt, bliver jeg valgt, fordi jeg kan fortælle direktøren ting, som den anden fyr ikke vil fortælle, og som direktøren måske ikke kan lide at høre . Jeg fortæller dem, at flaskehalsen i deres firma er en, der hedder Fred og en, der hedder Lou. Denne flaskehals skal løses, deres viden skal hentes fra dem på den ene eller anden måde.
For at løse den slags problemer kan jeg for eksempel foreslå at bruge Slack. En smart instruktør vil spørge - hvorfor? Typisk svarer DevOps-konsulenter i sådanne tilfælde: fordi alle gør det. Hvis instruktøren er rigtig klog, vil han sige: hvad så. Og det er her, dialogen slutter. Og mit svar til dette er: fordi der er fire flaskehalse i virksomheden, Fred, Lou, Susie og Jane. For at institutionalisere deres viden skal man først introducere Slack. Alle dine wikier er fuldstændig nonsens, fordi ingen ved om deres eksistens. Hvis ingeniørteamet er involveret i front-end- og back-end-udvikling, og alle skal vide, at de kan kontakte front-end-udviklingsteamet eller infrastrukturteamet med spørgsmål. Det er, når Lou eller Fred formentlig vil have tid til at tilslutte sig wikien. Og så i Slack kan nogen spørge, hvorfor f.eks. trin 5 ikke virker. Og så vil Lou eller Fred rette instruktionerne på wikien. Hvis du etablerer denne proces, så falder mange ting på plads af sig selv.
Dette er min hovedpointe: For at kunne anbefale nogen højteknologier, skal man først bringe grundlaget for dem i orden, og det kan gøres med de netop beskrevne lavteknologiske løsninger. Hvis du starter med højteknologier og ikke forklarer, hvorfor de er nødvendige, så ender det som regel ikke godt. En af vores kunder bruger Azure ML, en meget billig og enkel løsning. Omkring 30 % af deres spørgsmål blev besvaret af selvlærende maskine. Og denne ting blev skrevet af operatører, der ikke var involveret i datavidenskab, statistik eller matematik. Dette er væsentligt. Omkostningerne ved en sådan løsning er minimale.
4. Collaboration hacks: Collaboration hacks
Den fjerde arketype er behovet for at bekæmpe isolation. Det ved de fleste allerede: isolation afføder fjendtlighed. Hvis hver afdeling er på sin egen etage, og folk ikke krydser hinanden på nogen måde, undtagen i elevatoren, så opstår der meget let fjendtlighed mellem dem. Men hvis folk derimod er i samme rum med hinanden, går hun med det samme. Når nogen smider en generel beskyldning ud, for eksempel, fungerer sådan og sådan en grænseflade aldrig, er der ikke noget nemmere at dekonstruere sådan en anklage. De programmører, der har skrevet grænsefladen, skal bare begynde at stille specifikke spørgsmål, og det vil hurtigt blive klart, at for eksempel brugeren simpelthen brugte værktøjet forkert.
Der er mange måder at overvinde isolation på. Jeg blev engang bedt om at konsultere en bank i Australien, men jeg nægtede at gøre det, fordi jeg har to børn og en kone. Alt jeg kunne gøre for at hjælpe dem var at anbefale grafisk historiefortælling. Dette er noget, der har vist sig at virke. En anden interessant måde er magre kaffemøder. I en stor organisation er dette en glimrende mulighed for at formidle viden. Derudover kan du gennemføre interne devopsdays, hackathons og så videre.
5. Coaching Kata
Som jeg advarede i begyndelsen, vil jeg ikke tale om dette i dag. Hvis du er interesseret, kan du tage et kig .
Der er også en god snak om dette emne fra Mike Rother:
6. Markedsorienteret: markedsorienteret organisation
Der er forskellige problemer her. For eksempel "I"-personer, "T"-personer og "E"-personer. "Jeg" mennesker er dem, der kun gør én ting. Typisk findes de i organisationer med isolerede afdelinger. "T" er, når en person er god til én ting, men også god til nogle andre ting. "E" eller endda "kam" er, når en person har mange færdigheder.
Conways lov virker her (), hvilket i den mest forenklede form kan angives som følger: hvis tre hold arbejder på compileren, så vil resultatet være en compiler af tre dele. Derfor, hvis der er et højt niveau af isolation i en organisation, så vil selv Kubernetes, Circuit breaker, API-udvidelsesmuligheder og andre smarte ting i denne organisation blive arrangeret på samme måde som organisationen selv. Strengt ifølge Conway og på trods af alle jer unge nørder.
Løsningen på dette problem er blevet beskrevet mange gange. Der er for eksempel organisatoriske arketyper beskrevet af Fernando Fernandez. Den problematiske arkitektur, som jeg lige har talt om, med isolation, er en funktionsorienteret arkitektur. Den anden type er den værste, matrixarkitektur, et rod af de to andre. Den tredje er, hvad der ses i de fleste startups, og store virksomheder forsøger også at matche denne type. Det er en markedsorienteret organisation. Her optimerer vi for at opnå den hurtigste respons på kundeønsker. Dette kaldes nogle gange en flad organisation.
Mange mennesker beskriver denne struktur på forskellige måder, jeg kan godt lide formuleringen bygge/køre hold, hos Amazon kalder de det to pizzahold. I denne struktur er alle type "I"-personer grupperet omkring én tjeneste, og gradvist kommer de tættere på type "T", og hvis den rigtige ledelse er på plads, kan de endda blive "E". Det første modargument her er, at en sådan struktur har unødvendige elementer. Hvorfor skal man have en tester i hver afdeling, hvis man kan have en særlig afdeling af testere? Hvortil jeg svarer: de ekstra omkostninger i dette tilfælde er prisen for, at hele organisationen i fremtiden bliver type “E”. I denne struktur lærer testeren gradvist om netværk, arkitektur, design mv. Som et resultat er alle deltagere i organisationen fuldt ud klar over alt, hvad der sker i organisationen. Hvis du vil vide, hvordan denne ordning fungerer i industrien, så læs .
7. Skift-venstre auditorer: audit tidligt i cyklussen. Overholdelse af sikkerhedsregler udstillet
Det er, når dine handlinger så at sige ikke består lugtetesten. De mennesker, der arbejder for dig, er ikke dumme. Hvis de, som i eksemplet ovenfor, satte mindre/ingen påvirkning overalt, dette varede tre år, og ingen lagde mærke til noget, så ved alle udmærket, at systemet ikke virker. Eller et andet eksempel - et change advisory board, hvor rapporter skal indsendes hver for eksempel onsdag. Der er en gruppe mennesker, der arbejder der (i øvrigt ikke særlig godt betalt), som i teorien burde vide, hvordan systemet som helhed fungerer. Og i løbet af de sidste fem år har du sikkert bemærket, at vores systemer er utroligt komplekse. Og fem eller seks personer skal træffe en beslutning om en ændring, som de ikke har foretaget, og som de ikke ved noget om.
Selvfølgelig virker denne tilgang ikke. Jeg er nødt til at slippe af med sådanne ting, fordi disse mennesker ikke beskytter systemet. Beslutningen skal tages af teamet selv, for det skal teamet stå for. Ellers opstår der en paradoksal situation, når en leder, der aldrig har skrevet kode i sit liv, fortæller programmøren, hvor lang tid det skal tage at skrive kode. En virksomhed, jeg arbejdede med, havde 7 forskellige bestyrelser, der gennemgik hver ændring, inklusive en arkitekturtavle, en produkttavle osv. Der var endda en obligatorisk venteperiode, selvom en medarbejder fortalte mig, at der i løbet af ti års arbejde, ingen nogensinde havde afvist en ændring foretaget af denne person i denne obligatoriske periode.
Revisorer skal inviteres til at slutte sig til os og ikke slippe af med dem. Fortæl dem, at du skriver uforanderlige binære beholdere, der, hvis de består alle testene, forbliver uforanderlige for evigt. Fortæl dem, at du har en pipeline som kode, og forklar, hvad det betyder. Vis dem følgende skema: en uforanderlig skrivebeskyttet binær i en container, der består alle sårbarhedstests; og så er der ikke kun nogen, der rører ved det, de rører ikke engang det system, der skaber rørledningen, da det også er skabt dynamisk. Jeg har kunder, Capital One, som bruger Vault til at skabe noget som en blockchain. Revisoren behøver ikke at vise "opskrifter" fra Chef; det er nok at vise blockchainen, hvorfra det er klart, hvad der skete med Jira-billetten i produktion, og hvem der er ansvarlig for den.
Ifølge , oprettet i 2018 af Sonatype, var der 2017 milliarder OSS-downloadanmodninger i 87.
Tabene som følge af sårbarheder er uoverkommelige. Desuden inkluderer de tal, som du nu ser ovenfor, ikke alternativomkostninger. Hvad er DevSecOps i en nøddeskal? Lad mig sige med det samme, at jeg ikke er interesseret i at tale om, hvor vellykket dette navn er. Pointen er, at da DevOps har været så succesfuld, bør vi forsøge at tilføje sikkerhed til den pipeline.
Et eksempel på denne sekvens:
Dette er ikke en anbefaling til specifikke produkter, selvom jeg godt kan lide dem alle. Jeg citerede dem som et eksempel for at vise, at DevOps, som oprindeligt var baseret på det organisatoriske paradigme i industrien, giver dig mulighed for at automatisere alle trin i arbejdet med et produkt.
Og der er ingen grund til, at vi ikke kunne tage den samme tilgang til sikkerhed.
Total
Som afslutning vil jeg give nogle tips til DevSecOps. Du skal inkludere revisorer i processen med at skabe dine systemer og bruge tid på at uddanne dem. Du skal samarbejde med revisorer. Dernæst skal du føre en absolut hensynsløs kamp mod falske positiver. Selv med det dyreste sårbarhedsscanningsværktøj kan du ende med at skabe ekstremt dårlige vaner blandt dine udviklere, hvis du ikke ved, hvad dit signal/støjforhold er. Udviklere vil blive overvældet af begivenheder og vil simpelthen slette dem. Hvis du hørte om Equifax-historien, er det stort set det, der skete der, hvor det højeste alarmniveau blev ignoreret. Derudover skal sårbarheder forklares på en måde, der gør det klart, hvordan de påvirker virksomheden. For eksempel kan man sige, at dette er den samme sårbarhed som i Equifax-historien. Sikkerhedssårbarheder bør behandles på samme måde som andre softwareproblemer, det vil sige, at de skal inkluderes i den overordnede DevOps-proces. Du skal arbejde med dem gennem Jira, Kanban osv. Udviklere skal ikke tro, at nogen andre vil gøre dette - tværtimod bør alle gøre dette. Endelig skal du bruge energi på at træne folk.
Nyttige links
Her er et par foredrag fra DevOops-konferencen, som du måske kan finde nyttige:
- Sergey Berdnikov, Artyom Kalichkin - Succeshistorie eller "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps på en skala: en græsk tragedie i tre akter (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Undersøge nærmere DevOops 2020 Moskva - der er også mange interessante ting der.
Kilde: www.habr.com