Spørsmålet "hvordan implementere devops" har eksistert i årevis, men det er ikke mange gode materialer. Noen ganger blir du offer for annonser fra ikke fullt så smarte konsulenter som trenger å selge tiden sin, uansett hvordan. Noen ganger er dette vage, ekstremt generelle ord om hvordan skipene til megakorporasjoner pløyer universets vidder. Spørsmålet oppstår: hva betyr dette for oss? Kjære forfatter, kan du tydelig formulere ideene dine i en liste?
Alt dette stammer fra det faktum at ikke mye reell praksis og forståelse av resultatet av transformasjoner av selskapets kultur har samlet seg. Endringer i kultur er langsiktige ting, hvis resultater ikke vises om en uke eller en måned. Vi trenger noen som er gamle nok til å ha sett hvordan bedrifter har blitt bygget og sviktet opp gjennom årene.
John Willis - en av fedrene til DevOps. John har flere tiår med erfaring fra å jobbe med et stort antall selskaper. Nylig begynte John å legge merke til spesifikke mønstre som finner sted når han jobber med hver av dem. Ved å bruke disse arketypene veileder John selskaper på den sanne veien til DevOps-transformasjon. Les mer om disse arketypene i oversettelsen av rapporten hans fra DevOops 2018-konferansen.
Om foredragsholderen:
Mer enn 35 år i IT-ledelse, deltok i etableringen av forgjengeren til OpenCloud hos Canonical, deltok i 10 startups, hvorav to ble solgt til Dell og Docker. For tiden er han visepresident for DevOps og Digital Practices hos SJ Technologies.
Neste er historien fra Johns synspunkt.
Jeg heter John Willis og det enkleste stedet å finne meg er på Twitter, . Jeg har det samme aliaset på Gmail og GitHub. EN du kan finne videoopptak av rapportene mine og presentasjoner for dem.
Jeg har mange møter med CIOer i ulike store selskaper. De klager veldig ofte over at de ikke forstår hva DevOps er, og alle som prøver å forklare det til dem snakker om noe annet. En annen vanlig klage er at DevOps ikke fungerer, selv om det ser ut til at direktørene gjør alt som forklart for dem. Vi snakker om store selskaper som er mer enn hundre år gamle. Etter å ha snakket med dem kom jeg frem til at for mange problemer er det ikke høyteknologi som er best egnet, men relativt lavteknologiske løsninger. I flere uker snakket jeg bare med folk fra forskjellige avdelinger. Det du ser på det aller første bildet i innlegget er mitt siste prosjekt, slik så rommet ut etter tre dagers arbeid.
Hva er DevOps?
Faktisk, hvis du spør 10 forskjellige personer, vil de gi 10 forskjellige svar. Men her er det interessante: alle ti av disse svarene vil være riktige. Det er ikke noe feil svar her. Jeg var ganske dypt inne i DevOps, i omtrent 10 år, og var den første amerikaneren på den første DevOpsDay. Jeg vil ikke si at jeg er smartere enn alle som er involvert i DevOps, men det er knapt noen som har brukt så mye krefter på det. Jeg tror at DevOps oppstår når menneskelig kapital og teknologi kommer sammen. Vi glemmer ofte den menneskelige dimensjonen, selv om vi snakker mye om alle slags kulturer.
Nå har vi mye data, fem år med akademisk forskning, testing av teorier i industriell skala. Det disse studiene forteller oss er at hvis du kombinerer noen atferdsmønstre i en organisasjonskultur, kan du oppnå en 2000 ganger hastighetsøkning. Denne akselerasjonen motsvares av en lik forbedring i stabilitet. Dette er en kvantitativ måling av fordelen som DevOps kan gi ethvert selskap. For et par år siden snakket jeg om DevOps til administrerende direktør i et Fortune 5000-selskap. Da jeg forberedte presentasjonen, var jeg veldig nervøs fordi jeg måtte oppsummere mine mange års erfaring på 5 minutter.
Til slutt ga jeg følgende Definisjon av DevOps: Det er et sett med praksiser og mønstre som muliggjør transformasjon av menneskelig kapital til organisasjonskapital med høy ytelse. Et eksempel er måten Toyota har operert på de siste 50 eller 60 årene.
(Heretter er slike diagrammer ikke gitt som referansemateriale, men som illustrasjoner. Innholdet vil variere for hvert nytt selskap. Bildet kan imidlertid ses separat og forstørres
En av de mest vellykkede slike praksisene er verdi stream mapping. Det er skrevet flere gode bøker om dette, de mest vellykkede er av Karen Martin. Men i løpet av det siste året har jeg kommet til den konklusjon at selv denne tilnærmingen er for høyteknologisk. Den har absolutt mange fordeler og jeg har brukt den mye. Men når administrerende direktør spør deg hvorfor selskapet hans ikke kan bytte til nye skinner, er det for tidlig å snakke om verdistrømskartlegging. Det er mange mye mer grunnleggende spørsmål som først må besvares.
Jeg tror feilen mange av kollegene mine gjør er at de rett og slett gir selskapet en fempunktsguide og så kommer tilbake seks måneder senere og ser hva som skjedde. Selv et godt opplegg som verdistrømskartlegging har, la oss si, blindsoner. Etter hundrevis av intervjuer med direktører i ulike selskaper har jeg utviklet et visst mønster som gjør at vi kan bryte ned problemet i dets komponenter, og nå skal vi diskutere hver av disse komponentene i rekkefølge. Før jeg bruker noen teknologiske løsninger, bruker jeg dette mønsteret, og som et resultat er alle veggene mine dekket med diagrammer. Nylig jobbet jeg med et aksjefond, og jeg endte opp med 100-150 slike ordninger.
Dårlig kultur spiser gode tilnærminger til frokost
Hovedideen er denne: ingen mengde Lean, Agile, SAFE og DevOps vil hjelpe hvis organisasjonens kultur i seg selv er dårlig. Det er som å dykke til dybder uten dykkeutstyr eller operere uten røntgen. Med andre ord, for å parafrasere Drucker og Deming: en dårlig organisasjonskultur vil sluke opp ethvert godt system uten å kvele det.
For å løse dette hovedproblemet, må du ta følgende trinn:
- Gjør alt arbeid synlig: du må gjøre alt arbeidet synlig. Ikke i den forstand at det nødvendigvis må vises på en eller annen skjerm, men i den forstand at det må være observerbart.
- Konsoliderte arbeidsledelsessystemer: styringssystemene må konsolideres. I problemet med "stammekunnskap" og institusjonell kunnskap er flaskehalsen i 9 tilfeller av 10 mennesker. I boken problemet var med én enkelt person, Brent, som førte til at prosjektet var tre år etter planen. Og jeg støter på disse "Brents" overalt. For å løse disse flaskehalsene bruker jeg de to neste elementene på listen vår.
- Teori om begrensninger Metodikk: teori om begrensninger.
- Samarbeidshack: samarbeidshack.
- Toyota Kata (): Jeg vil ikke snakke mye om Toyota Kata. Hvis du er interessert, på min github på nesten alle disse temaene.
- Markedsorientert organisasjon: markedsorientert organisasjon.
- Skift-venstre revisorer: revisjon på tidlige stadier av syklusen.
Jeg begynner å jobbe med en organisasjon veldig enkelt: Jeg går til bedriften og snakker med de ansatte. Som du kan se, ingen høyteknologi. Alt du trenger er noe å skrive på. Jeg samler flere team i ett rom og analyserer hva de forteller meg fra perspektivet til mine 7 arketyper. Og så gir jeg dem en tusj selv og ber dem skrive ned på tavlen alt de har sagt høyt så langt. Vanligvis i denne typen møter er det én person som skriver ned alt, og i beste fall kan han skrive ned 10 % av diskusjonen. Med min metode kan dette tallet heves til ca 40%.
(Denne illustrasjonen kan sees separat )
Min tilnærming er basert på arbeidet til William Schneider. ). Tilnærmingen er basert på ideen om at enhver organisasjon kan deles inn i fire firkanter. Denne ordningen for meg er vanligvis et resultat av å jobbe med de hundrevis av andre ordningene som oppstår når man analyserer en organisasjon. Anta at vi har en organisasjon med høy kontroll, men med lav kompetanse. Dette er et ekstremt uønsket alternativ: når alle står på linjen, men ingen vet hva de skal gjøre.
Et noe bedre alternativ er et med høy grad av både kontroll og kompetanse. Hvis et slikt selskap er lønnsomt, trenger det kanskje ikke DevOps. Det er mest interessant å jobbe med en bedrift som har høy kontroll, lav kompetanse og samarbeid, men samtidig høy kultur (dyrking). Det betyr at bedriften har mange som liker å jobbe der og arbeidsomsetningen er lav.
(Denne illustrasjonen kan sees separat )
Det virker for meg som om metoder med rigide retningslinjer ender opp med å komme i veien for å oppnå sannheten. Spesielt i verdistrømskartlegging er det mange regler for hvordan informasjon skal struktureres. I de tidlige stadiene av arbeidet, som jeg snakker om nå, trenger ingen disse reglene. Hvis en person med en markør i hendene beskriver den virkelige situasjonen i selskapet i styret, er dette den beste måten å forstå tingenes tilstand på. Slik informasjon når ikke styremedlemmer. I dette øyeblikket er det dumt å avbryte personen og si at han tegnet en slags pil feil. På dette stadiet er det bedre å bruke enkle regler, for eksempel: multi-level abstraksjon kan lages ganske enkelt ved å bruke flerfargede markører.
Jeg gjentar, ingen høyteknologi. Den svarte markøren skildrer den objektive virkeligheten av hvordan alt fungerer. Med en rød markør markerer folk det de ikke liker med den nåværende situasjonen. Det er viktig at de skriver dette, ikke jeg. Når jeg går til CIO etter et møte, tilbyr jeg ikke en liste over 10 ting som må fikses. Jeg streber etter å finne sammenhenger mellom hva folk i selskapet sier og eksisterende utprøvde mønstre. Til slutt foreslår en blå markør mulige løsninger på problemet.
(Denne illustrasjonen kan sees separat )
Et eksempel på denne tilnærmingen er nå avbildet ovenfor. I begynnelsen av dette året jobbet jeg med én bank. Sikkerhetsfolkene der var overbevist om at de ikke skulle komme til design- og kravgjennomganger.
(Denne illustrasjonen kan sees separat )
Og så snakket vi med folk fra andre avdelinger, og det viste seg at programvareutviklere for omtrent 8 år siden sparket sikkerhetsarbeidere fordi de bremset arbeidet. Og så ble det forbud, som ble tatt for gitt. Selv om det i realiteten ikke var noe forbud.
Møtet vårt foregikk på en ekstremt forvirrende måte: i omtrent tre timer kunne ikke fem forskjellige team forklare meg hva som skjedde mellom koden og forsamlingen. Og dette ser ut til å være det enkleste. De fleste DevOps-konsulenter antar på forhånd at alle allerede vet dette.
Så kom den med ansvar for IT-styring, som hadde vært stille i fire timer, plutselig til liv da vi kom til temaet hans, og opptatt oss veldig lenge. På slutten spurte jeg ham hva han syntes om møtet, og jeg kommer aldri til å glemme svaret hans. Han sa: "Jeg pleide å tro at banken vår bare hadde to måter å levere programvare på, men nå vet jeg at det er fem av dem, og jeg visste ikke engang om tre."
(Denne illustrasjonen kan sees separat )
Det siste møtet i denne banken var med investeringsprogramvareteamet. Det var hos henne det viste seg at det er bedre å skrive diagrammer med en tusj på et ark enn på en tavle, og enda bedre enn på en smartboard.
Bildene du ser er hvordan hotellets konferanserom så ut den fjerde dagen av møtet vårt. Og vi brukte disse ordningene til å søke etter mønstre, det vil si arketyper.
Så jeg stiller arbeiderne spørsmål, de skriver ned svarene med markører i tre farger (svart, rød og blå). Jeg analyserer svarene deres for arketyper. La oss nå diskutere alle arketypene i rekkefølge.
1. Gjør alt arbeid synlig: Gjør arbeidet synlig
De fleste bedrifter jeg jobber med har en veldig høy andel ukjent arbeid. Det er for eksempel når en ansatt kommer til en annen og bare ber om å få gjøre noe. I store organisasjoner kan det være 60 % uplanlagt arbeid. Og opptil 40 % av arbeidet er ikke dokumentert på noen måte. Hvis det var Boeing, ville jeg aldri gått om bord på flyet deres igjen i mitt liv. Hvis bare halvparten av arbeidet er dokumentert, så er det ikke kjent om dette arbeidet blir utført korrekt eller ikke. Alle andre metoder viser seg å være ubrukelige - det er ingen vits i å prøve å automatisere noe, fordi de kjente 50% kan være den mest sammenhengende og klare delen av arbeidet, hvis automatisering ikke vil gi gode resultater, og alt det verste ting er i den usynlige halvdelen. I mangel av dokumentasjon er det umulig å finne alle slags hacks og skjult arbeid, ikke å finne flaskehalser, akkurat de "Brents" som jeg allerede har snakket om. Det er en fantastisk bok av Dominica DeGrandis . Hun avslører fem forskjellige "tidslekkasjer" (tidstyver):
- For mye arbeid i prosess (WIP)
- Ukjente avhengigheter
- Uplanlagt arbeid
- Motstridende prioriteringer
- Forsømt arbeid
Dette er en veldig verdifull analyse og boken er flott, men alle disse rådene er ubrukelige hvis bare 50 % av dataene er synlige. Metodene foreslått av Dominica kan brukes hvis en nøyaktighet på over 90 % oppnås. Jeg snakker om situasjoner der en sjef gir en underordnet en 15-minutters oppgave, men det tar ham tre dager; men sjefen vet egentlig ikke at denne underordnede er avhengig av fire-fem andre personer.
The Phoenix Project er en fantastisk historie om et prosjekt som var tre år for sent. En av karakterene står overfor oppsigelse på grunn av dette, og han møter en annen karakter som blir presentert som en slags Sokrates. Han hjelper til med å finne ut nøyaktig hva som gikk galt. Det viser seg at selskapet har én systemadministrator, som heter Brent, og alt arbeid går på en eller annen måte gjennom ham. På et av møtene blir en av de underordnede spurt: hvorfor tar hver halvtimesoppgave en uke? Svaret er en svært forenklet fremstilling av køteori og Littles lov, og i denne fremstillingen viser det seg at ved 90 % belegg tar hver time arbeid 9 timer. Hver oppgave må sendes til syv andre personer, slik at timen blir 63 timer, 7 ganger 9. Det jeg sier er at for å bruke Little's Law eller en hvilken som helst kompleks køteori, må du i det minste ha data.
Så når jeg snakker om synlighet, mener jeg ikke at alt er på skjermen, men at du i det minste har data. Når de gjør det, viser det seg ofte at det er veldig mye uplanlagt arbeid som på en eller annen måte sendes til Brent når det ikke er behov for det. Og Brent er en flott fyr, han vil aldri si nei, men han forteller ingen hvordan han gjør jobben sin.
Når arbeidet er synlig, kan data klassifiseres pent (det er det Dominika gjør på bildet), abstraksjonen av de fem tidslekkasjene kan brukes, og automatisering kan brukes.
2. Konsolider arbeidsledelsessystemer: Oppgavestyring
Arketypene jeg snakker om er en slags pyramide. Hvis den første er gjort riktig, er den andre allerede et slags tillegg. Mange av disse fungerer ikke for startups, de må huskes for større selskaper som Fortune 5000. Det siste selskapet jeg jobbet for hadde 10 billettsystemer. Ett team hadde Remedy, et annet skrev et slags eget system, et tredje brukte Jira, og noen klarte seg med e-post. Det samme problemet oppstår hvis selskapet har 30 forskjellige rørledninger, men jeg har ikke tid til å diskutere alle slike saker.
Jeg diskuterer med folk nøyaktig hvordan billetter lages, hva som skjer med dem videre, og hvordan de omgås. Det mest interessante er at folk på møtene våre snakker ganske oppriktig. Jeg spurte hvor mange som setter "minor / no impact" på billetter som egentlig burde gis "major impact". Det viste seg at nesten alle gjør dette. Jeg engasjerer meg ikke i oppsigelse og prøver på alle mulige måter å ikke identifisere personer. Når de oppriktig tilstår noe for meg, gir jeg ikke personen bort. Men når nesten alle omgår systemet, betyr det at all sikkerhet i hovedsak er vinduspredning. Derfor kan ingen konklusjoner trekkes fra dataene i dette systemet.
For å løse billettproblemet må du velge ett hovedsystem. Hvis du bruker Jira, behold den Jira. Hvis det er noe alternativ, la det være det eneste. Poenget er at billetter bør ses på som et annet trinn i utviklingsprosessen. Hver handling må ha en billett, som må flyte gjennom utviklingsarbeidsflyten. Billetter sendes til teamet, som legger dem ut på storyboardet og tar ansvar for dem.
Dette gjelder alle avdelinger, inkludert infrastruktur og drift. I dette tilfellet er det mulig å danne seg i det minste en plausibel ide om tingenes tilstand. Når denne prosessen er etablert, blir det plutselig lett å identifisere hvem som er ansvarlig for hver søknad. For nå mottar vi ikke 50 %, men 98 % av nye tjenester. Hvis denne kjerneprosessen fungerer, forbedres nøyaktigheten gjennom hele systemet.
Tjenester pipeline
Dette gjelder igjen bare for store selskaper. Hvis du er et nytt selskap på et nytt felt, brett opp ermene og arbeid med din Travis CI eller CircleCI. Når det gjelder Fortune 5000-selskaper, et eksempel som skjedde i banken der jeg jobbet. Google kom til dem og de ble vist diagrammer over gamle IBM-systemer. Gutta fra Google spurte forvirret - hvor er kildekoden for dette? Men det er ingen kildekode, ikke engang en GUI. Dette er virkeligheten som store organisasjoner må forholde seg til: 40 år gamle bankposter på en eldgammel stormaskin. En av kundene mine bruker Kubernetes-beholdere med Circuit Breaker-mønstre, pluss Chaos Monkey, alt for KeyBank-applikasjonen. Men disse beholderne kobles til slutt til en COBOL-applikasjon.
Gutta fra Google var helt sikre på at de ville løse alle problemene til kunden min, og så begynte de å stille spørsmål: hva er IBM datapipe? De blir fortalt: dette er en kontakt. Hva kobles den til? Til Sperry-systemet. Og hva er det? Og så videre. Ved første øyekast ser det ut som: hva slags DevOps kan det være? Men faktisk er det mulig. Det finnes leveringssystemer som lar deg overlevere arbeidsflyten til leveringsteamene.
3. Theory of Constraints: Theory of Constraints
La oss gå videre til den tredje arketypen: institusjonell/«stamme» kunnskap. Som regel er det i enhver organisasjon flere personer som vet alt og administrerer alt. Dette er de som har vært i organisasjonen lengst og som kjenner alle løsningene.
Når dette kommer opp på diagrammet, ringer jeg spesifikt inn slike personer med en markør: for eksempel viser det seg at en viss Lou er til stede på alle møter. Og det er klart for meg: dette er lokale Brent. Når CIO velger mellom meg i T-skjorte og joggesko og fyren fra IBM i dress, blir jeg valgt fordi jeg kan fortelle regissøren ting som den andre fyren ikke vil fortelle og som regissøren kanskje ikke liker å høre . Jeg forteller dem at flaskehalsen i selskapet deres er en som heter Fred og en som heter Lou. Denne flaskehalsen må løses, kunnskapen deres må hentes fra dem på en eller annen måte.
For å løse denne typen problemer kan jeg for eksempel foreslå å bruke Slack. En smart regissør vil spørre - hvorfor? Vanligvis, i slike tilfeller, svarer DevOps-konsulentene: fordi alle gjør det. Hvis regissøren er virkelig smart, vil han si: hva så. Og det er her dialogen slutter. Og svaret mitt på dette er: fordi det er fire flaskehalser i selskapet, Fred, Lou, Susie og Jane. For å institusjonalisere kunnskapen deres, må man først introdusere Slack. Alle wikiene dine er fullstendig tull fordi ingen vet om deres eksistens. Hvis ingeniørteamet er involvert i front-end- og back-end-utvikling og alle trenger å vite at de kan kontakte front-end-utviklingsteamet eller infrastrukturteamet med spørsmål. Det er da Lou eller Fred sannsynligvis vil ha tid til å bli med på wikien. Og så i Slack kan noen spørre hvorfor, for eksempel, trinn 5 ikke fungerer. Og da vil Lou eller Fred korrigere instruksjonene på wikien. Hvis du etablerer denne prosessen, vil mange ting falle på plass av seg selv.
Dette er hovedpoenget mitt: For å anbefale noen høyteknologier, må du først sette grunnlaget for dem i orden, og dette kan gjøres med de lavteknologiske løsningene som nettopp er beskrevet. Hvis du starter med høyteknologier og ikke forklarer hvorfor de trengs, så ender dette som regel ikke bra. En av våre kunder bruker Azure ML, en veldig billig og enkel løsning. Omtrent 30 % av spørsmålene deres ble besvart av selvlærende maskinen. Og denne tingen ble skrevet av operatører som ikke var involvert i datavitenskap, statistikk eller matematikk. Dette er betydelig. Kostnaden for en slik løsning er minimal.
4. Samarbeidshack: Samarbeidshack
Den fjerde arketypen er behovet for å bekjempe isolasjon. De fleste vet dette allerede: isolasjon avler fiendtlighet. Hvis hver avdeling er i sin egen etasje, og folk ikke krysser hverandre på noen måte, bortsett fra i heisen, så oppstår det veldig lett fiendtlighet mellom dem. Men hvis folk tvert imot er i samme rom med hverandre, går hun umiddelbart. Når noen kaster ut en generell anklage, for eksempel, fungerer en slik og et slikt grensesnitt aldri, det er ikke noe lettere å dekonstruere en slik anklage. Programmererne som skrev grensesnittet trenger bare å begynne å stille spesifikke spørsmål, og det vil snart bli klart at for eksempel brukeren rett og slett brukte verktøyet feil.
Det er mange måter å overvinne isolasjon på. Jeg ble en gang bedt om å konsultere for en bank i Australia, men jeg nektet å gjøre det fordi jeg har to barn og en kone. Alt jeg kunne gjøre for å hjelpe dem var å anbefale grafisk historiefortelling. Dette er noe som har vist seg å fungere. En annen interessant måte er magre kaffemøter. I en stor organisasjon er dette et utmerket alternativ for å spre kunnskap. I tillegg kan du gjennomføre interne devopsdays, hackathons og så videre.
5. Coaching Kata
Som jeg advarte helt i begynnelsen, vil jeg ikke snakke om dette i dag. Hvis du er interessert, kan du ta en titt .
Det er også et godt foredrag om dette emnet fra Mike Rother:
6. Markedsorientert: markedsorientert organisasjon
Det er forskjellige problemer her. For eksempel «jeg»-mennesker, «T»-mennesker og «E»-mennesker. "Jeg"-mennesker er de som bare gjør én ting. Vanligvis eksisterer de i organisasjoner med isolerte avdelinger. "T" er når en person er god på én ting, men også god på noen andre ting. "E" eller til og med "kam" er når en person har mange ferdigheter.
Conways lov fungerer her (), som i den mest forenklede formen kan angis som følger: hvis tre team jobber med kompilatoren, vil resultatet være en kompilator av tre deler. Derfor, hvis det er et høyt nivå av isolasjon i en organisasjon, vil til og med Kubernetes, Circuit breaker, API-utvidbarhet og andre fancy ting i denne organisasjonen ordnes på samme måte som organisasjonen selv. Strengt i henhold til Conway og til tross for alle dere unge nerder.
Løsningen på dette problemet har blitt beskrevet mange ganger. Det er for eksempel organisatoriske arketyper beskrevet av Fernando Fernandez. Den problematiske arkitekturen som jeg nettopp snakket om, med isolasjon, er en funksjonsorientert arkitektur. Den andre typen er den verste, matrisearkitektur, et rot av de to andre. Det tredje er det man ser i de fleste startups, og store selskaper prøver også å matche denne typen. Det er en markedsorientert organisasjon. Her optimerer vi for å oppnå raskest respons på kundeforespørsler. Dette kalles noen ganger en flat organisasjon.
Mange beskriver denne strukturen på forskjellige måter, jeg liker ordlyden bygge/kjøre lag, hos Amazon kaller de det to pizzalag. I denne strukturen er alle type "I"-personer gruppert rundt en tjeneste, og gradvis kommer de nærmere typen "T", og hvis riktig ledelse er på plass, kan de til og med bli "E". Det første motargumentet her er at en slik struktur inneholder unødvendige elementer. Hvorfor trenger man en tester i hver avdeling hvis man kan ha en spesiell avdeling med testere? Til det svarer jeg: ekstrakostnadene i dette tilfellet er prisen for at hele organisasjonen skal bli type "E" i fremtiden. I denne strukturen lærer testeren gradvis om nettverk, arkitektur, design osv. Som et resultat er hver deltaker i organisasjonen fullstendig klar over alt som skjer i organisasjonen. Hvis du vil vite hvordan denne ordningen fungerer i industrien, les .
7. Skift-venstre revisorer: revisjon tidlig i syklusen. Overholdelse av sikkerhetsregler på utstilling
Dette er når handlingene dine ikke består lukttesten, for å si det sånn. De som jobber for deg er ikke dumme. Hvis de, som i eksempelet ovenfor, satte liten/ingen påvirkning overalt, dette varte i tre år, og ingen merket noe, så vet alle godt at systemet ikke fungerer. Eller et annet eksempel - et endringsråd, der rapporter må sendes inn hver, for eksempel, onsdag. Det er en gruppe mennesker som jobber der (ikke særlig godt betalt, forresten) som i teorien burde vite hvordan systemet som helhet fungerer. Og i løpet av de siste fem årene har du sikkert lagt merke til at systemene våre er utrolig komplekse. Og fem eller seks personer må ta en avgjørelse om en endring som de ikke har gjort og som de ikke vet noe om.
Selvfølgelig fungerer ikke denne tilnærmingen. Jeg må kvitte meg med slike ting fordi disse menneskene ikke beskytter systemet. Beslutningen må tas av laget selv, for det må laget stå for. Ellers oppstår en paradoksal situasjon når en leder som aldri har skrevet kode i sitt liv, forteller programmereren hvor lang tid det bør ta å skrive kode. Ett selskap jeg jobbet med hadde 7 forskjellige styrer som gjennomgikk hver endring, inkludert et arkitekturtavle, et produkttavle, etc. Det var til og med en obligatorisk ventetid, selv om en ansatt fortalte meg at i løpet av ti års arbeid hadde ingen noen gang avvist en endring gjort av denne personen i løpet av denne obligatoriske perioden.
Revisorer må inviteres til å bli med oss, og ikke bli kvitt dem. Fortell dem at du skriver uforanderlige binære beholdere som, hvis de består alle testene, forblir uforanderlige for alltid. Fortell dem at du har en pipeline som kode og forklar hva det betyr. Vis dem følgende skjema: en uforanderlig skrivebeskyttet binær i en beholder som består alle sårbarhetstester; og ikke bare berører ingen den, de rører ikke engang systemet som skaper rørledningen, siden den også er skapt dynamisk. Jeg har kunder, Capital One, som bruker Vault for å lage noe som en blokkjede. Revisoren trenger ikke å vise "oppskrifter" fra Chef; det er nok å vise blokkjeden, hvorfra det er klart hva som skjedde med Jira-billetten i produksjon og hvem som er ansvarlig for den.
Ifølge , opprettet i 2018 av Sonatype, var det 2017 milliarder OSS-nedlastingsforespørsler i 87.
Tapene påført på grunn av sårbarheter er uoverkommelige. Dessuten inkluderer tallene du nå ser ovenfor ikke alternativkostnader. Hva er DevSecOps i et nøtteskall? La meg si med en gang at jeg ikke er interessert i å snakke om hvor vellykket dette navnet er. Poenget er at siden DevOps har vært så vellykket, bør vi prøve å legge til sikkerhet til den rørledningen.
Et eksempel på denne sekvensen:
Dette er ikke en anbefaling for spesifikke produkter, selv om jeg liker dem alle. Jeg nevnte dem som et eksempel for å vise at DevOps, som opprinnelig var basert på det organisatoriske paradigmet i industrien, lar deg automatisere alle trinn i arbeidet med et produkt.
Og det er ingen grunn til at vi ikke kunne ha samme tilnærming til sikkerhet.
Total
Som en konklusjon vil jeg gi noen tips til DevSecOps. Du må inkludere revisorer i prosessen med å lage systemene dine og bruke tid på å utdanne dem. Du må samarbeide med revisorer. Deretter må du føre en absolutt hensynsløs kamp mot falske positiver. Selv med det dyreste sårbarhetsskanningsverktøyet kan du ende opp med å skape ekstremt dårlige vaner blant utviklerne dine hvis du ikke vet hva signal-til-støy-forholdet ditt er. Utviklere vil bli overveldet av hendelser og vil ganske enkelt slette dem. Hvis du hørte om Equifax-historien, er det stort sett det som skjedde der, hvor det høyeste varslingsnivået ble ignorert. I tillegg må sårbarheter forklares på en måte som gjør det klart hvordan de påvirker virksomheten. For eksempel kan du si at dette er den samme sårbarheten som i Equifax-historien. Sikkerhetssårbarheter bør behandles på samme måte som andre programvareproblemer, det vil si at de bør inkluderes i den generelle DevOps-prosessen. Du må jobbe med dem gjennom Jira, Kanban, etc. Utviklere skal ikke tro at noen andre vil gjøre dette – tvert imot bør alle gjøre dette. Til slutt må du bruke energi på å trene folk.
Nyttige lenker
Her er noen foredrag fra DevOops-konferansen som du kan finne nyttige:
- Sergey Berdnikov, Artyom Kalichkin - Suksesshistorie, eller "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps på en skala: en gresk tragedie i tre akter (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Se nærmere på DevOops 2020 Moskva — Det er også mye interessant der.
Kilde: www.habr.com