De sju arketyperna av DevOps-transformation

Frågan "hur man implementerar devops" har funnits i flera år, men det finns inte många bra material. Ibland blir man offer för annonser från inte så smarta konsulter som behöver sälja sin tid, oavsett hur. Ibland är det vaga, extremt allmänna ord om hur megaföretagens skepp plöjer universums vidder. Frågan uppstår: vad betyder detta för oss? Kära författare, kan du tydligt formulera dina idéer i en lista?

Allt detta härrör från det faktum att inte mycket verklig praxis och förståelse för resultatet av omvandlingar av företagets kultur har ackumulerats. Förändringar i kulturen är långsiktiga saker, vars resultat inte kommer att visas på en vecka eller en månad. Vi behöver någon gammal nog att ha sett hur företag har byggts och misslyckats genom åren.

John Willis - en av fäderna till DevOps. John har decennier av erfarenhet av att arbeta med ett stort antal företag. Nyligen började John lägga märke till specifika mönster som uppstår när man arbetar med var och en av dem. Med hjälp av dessa arketyper vägleder John företag på den sanna vägen för DevOps-transformation. Läs mer om dessa arketyper i översättningen av hans rapport från DevOops 2018-konferensen.

Om talaren:

Mer än 35 år inom IT-ledning, deltog i skapandet av föregångaren till OpenCloud på Canonical, deltog i 10 startups, varav två såldes till Dell och Docker. För närvarande är han Vice President för DevOps och Digital Practices på SJ Technologies.

Nästa är historien från Johns synvinkel.

Jag heter John Willis och det enklaste stället att hitta mig är på Twitter, @botchagalupe. Jag har samma alias på Gmail och GitHub. A genom den här länken du kan hitta videoinspelningar av mina rapporter och presentationer för dem.

Jag har många möten med CIO:er på olika stora företag. De klagar väldigt ofta över att de inte förstår vad DevOps är, och alla som försöker förklara det för dem pratar om något annat. Ett annat vanligt klagomål är att DevOps inte fungerar, även om det verkar som att regissörerna gör allt som förklarat för dem. Vi pratar om stora företag som är mer än hundra år gamla. Efter att ha pratat med dem kom jag fram till att för många problem är det inte högteknologi som lämpar sig bäst, utan snarare relativt lågteknologiska lösningar. I veckor har jag bara pratat med folk från olika avdelningar. Det ni ser på den allra första bilden i inlägget är mitt sista projekt, så här såg rummet ut efter tre dagars jobb.

Vad är DevOps?

Faktum är att om du frågar 10 olika personer kommer de att ge 10 olika svar. Men här är det intressanta: alla tio av dessa svar kommer att vara korrekta. Det finns inget fel svar här. Jag var ganska djupt in i DevOps, i ungefär 10 år, och var den första amerikanen på den första DevOpsDay. Jag kommer inte säga att jag är smartare än alla inblandade i DevOps, men det finns knappast någon som har lagt ner så mycket ansträngning på det. Jag tror att DevOps uppstår när humankapital och teknologi möts. Vi glömmer ofta bort den mänskliga dimensionen, även om vi pratar mycket om alla sorters kulturer.

Nu har vi mycket data, fem års akademisk forskning, testning av teorier i industriell skala. Vad dessa studier säger oss är att om du kombinerar vissa beteendemönster i en organisationskultur kan du uppnå en 2000 5000 gånger snabbare hastighet. Denna acceleration matchas av en lika förbättring av stabiliteten. Detta är ett kvantitativt mått på fördelen som DevOps kan ge alla företag. För ett par år sedan pratade jag om DevOps till VD:n för ett Fortune 5-företag. När jag förberedde presentationen var jag väldigt nervös eftersom jag var tvungen att sammanfatta mina år av erfarenhet på XNUMX minuter.

Till slut gav jag följande Definition av DevOps: Det är en uppsättning metoder och mönster som möjliggör omvandling av humankapital till högpresterande organisatoriskt kapital. Ett exempel är hur Toyota har fungerat de senaste 50 eller 60 åren.

(Nedan tillhandahålls sådana diagram inte som referensmaterial, utan som illustrationer. Deras innehåll kommer att skilja sig åt för varje nytt företag. Bilden kan dock ses separat och förstoras på denna länk.)

En av de mest framgångsrika sådana metoderna är värdeflödesanalys. Det har skrivits flera bra böcker om detta, de mest framgångsrika är av Karen Martin. Men under det senaste året har jag kommit fram till att även detta tillvägagångssätt är för högteknologiskt. Det har säkert många fördelar och jag har använt det mycket. Men när VD:n frågar dig varför hans företag inte kan byta till nya räls är det för tidigt att prata om värdeströmskartläggning. Det finns många mycket mer grundläggande frågor som först måste besvaras.

Jag tror att misstaget många av mina kollegor gör är att de helt enkelt ger företaget en fempunktsguide och sedan kommer tillbaka ett halvår senare och se vad som hände. Även ett bra system som värdeströmskartläggning har, låt oss säga, blinda fläckar. Efter hundratals intervjuer med direktörer i olika företag har jag utvecklat ett visst mönster som gör att vi kan bryta ner problemet i dess komponenter, och nu ska vi diskutera var och en av dessa komponenter i ordning. Innan jag applicerar några tekniska lösningar använder jag det här mönstret, och som ett resultat är alla mina väggar täckta med diagram. Nyligen arbetade jag med en värdepappersfond och jag slutade med 100-150 sådana system.

Dålig kultur äter bra tillvägagångssätt till frukost

Huvudtanken är denna: ingen mängd Lean, Agile, SAFE och DevOps kommer att hjälpa om organisationens kultur i sig är dålig. Det är som att dyka till djup utan dykutrustning eller arbeta utan röntgen. Med andra ord, för att parafrasera Drucker och Deming: en dålig organisationskultur kommer att svälja upp alla bra system utan att kvävas av det.

För att lösa detta huvudproblem måste du ta följande steg:

1. Gör allt arbete synligt: du måste göra allt arbete synligt. Inte i den meningen att det nödvändigtvis måste visas på någon skärm, utan i den meningen att det måste vara observerbart.
2. Konsoliderade arbetsledningssystem: ledningssystem måste konsolideras. I problemet med "stamkunskaper" och institutionell kunskap är flaskhalsen i 9 fall av 10 människor. I boken "Phoenix Project" problemet var med en enda person, Brent, som gjorde att projektet låg tre år efter schemat. Och jag stöter på dessa "Brents" överallt. För att lösa dessa flaskhalsar använder jag de följande två punkterna på vår lista.
3. Theory of Constraints Metodologi: Teorin om begränsningar.
4. Samarbetshack: samarbetshack.
5. Toyota Kata (Coaching Kata): Jag ska inte prata mycket om Toyota Kata. Om du är intresserad, på min github det finns presentationer om nästan alla dessa ämnen.
6. Marknadsorienterad organisation: marknadsorienterad organisation.
7. Vänsterskifte revisorer: revision i tidiga skeden av cykeln.

Jag börjar jobba med en organisation väldigt enkelt: jag går till företaget och pratar med de anställda. Som du kan se, ingen högteknologi. Allt du behöver är något att skriva på. Jag samlar flera team i ett rum och analyserar vad de berättar för mig utifrån mina 7 arketyper. Och så ger jag dem själva en markör och ber dem skriva ner på tavlan allt som de har sagt högt hittills. Vanligtvis i den här typen av möten är det en person som skriver ner allt, och i bästa fall kan han skriva ner 10% av diskussionen. Med min metod kan denna siffra höjas till ca 40%.

(Denna illustration kan ses separat se länk)

Mitt tillvägagångssätt är baserat på William Schneiders arbete. Reengineering Alternativet). Tillvägagångssättet bygger på tanken att vilken organisation som helst kan delas in i fyra rutor. Detta schema för mig är vanligtvis resultatet av att arbeta med de hundratals andra scheman som uppstår när man analyserar en organisation. Anta att vi har en organisation med hög kontroll, men med låg kompetens. Det här är ett extremt oönskat alternativ: när alla går på gränsen, men ingen vet vad de ska göra.

Ett något bättre alternativ är ett med hög nivå av både kontroll och kompetens. Om ett sådant företag är lönsamt behöver det kanske inte DevOps. Det är mest intressant att arbeta med ett företag som har hög kontroll, låg kompetens och samarbete men samtidigt hög kultur (odling). Det gör att företaget har många som gillar att jobba där och arbetsomsättningen är låg.

(Denna illustration kan ses separat se länk)

Det verkar för mig att metoder med stela riktlinjer hamnar i vägen för att uppnå sanningen. Särskilt inom värdeströmskartläggning finns det många regler för hur information ska struktureras. I de tidiga stadierna av arbetet, som jag pratar om nu, behöver ingen dessa regler. Om en person med en markör i händerna beskriver den verkliga situationen i företaget i styrelsen, är detta det bästa sättet att förstå läget. Sådan information når inte direktörerna. I det här ögonblicket är det dumt att avbryta personen och säga att han ritade någon typ av pil felaktigt. I detta skede är det bättre att använda enkla regler, till exempel: abstraktion på flera nivåer kan skapas helt enkelt genom att använda flerfärgade markörer.

Jag upprepar, ingen högteknologi. Den svarta markören skildrar den objektiva verkligheten av hur allting fungerar. Med en röd markör markerar människor vad de inte gillar med det aktuella läget. Det är viktigt att de skriver detta, inte jag. När jag går till CIO efter ett möte erbjuder jag inte en lista på 10 saker som måste fixas. Jag strävar efter att hitta kopplingar mellan vad människor i företaget säger och befintliga beprövade mönster. Slutligen föreslår en blå markör möjliga lösningar på problemet.

(Denna illustration kan ses separat se länk)

Ett exempel på detta tillvägagångssätt visas nu ovan. I början av detta år arbetade jag med en bank. Säkerhetsfolket där var övertygade om att de inte borde komma till design- och kravgenomgångar.

(Denna illustration kan ses separat se länk)

Och sedan pratade vi med folk från andra avdelningar och det visade sig att för cirka 8 år sedan sparkade mjukvaruutvecklare säkerhetsarbetare för att de saktade ner arbetet. Och så blev det ett förbud, vilket togs för givet. Även om det i verkligheten inte fanns något förbud.

Vårt möte fortgick på ett extremt förvirrande sätt: under cirka tre timmar kunde fem olika team inte förklara för mig vad som hände mellan koden och sammansättningen. Och detta verkar vara det enklaste. De flesta DevOps-konsulter antar på förhand att alla redan vet detta.

Då vaknade plötsligt den IT-ansvarige, som varit tyst i fyra timmar, till liv när vi kom till hans ämne och sysselsatte oss väldigt länge. I slutet frågade jag honom vad han tyckte om mötet, och jag kommer aldrig att glömma hans svar. Han sa: "Jag trodde att vår bank bara hade två sätt att leverera mjukvara, men nu vet jag att det finns fem av dem, och jag visste inte ens om tre."

(Denna illustration kan ses separat se länk)

Det sista mötet på den här banken var med teamet för investeringsprogramvara. Det var hos henne som det visade sig att det är bättre att skriva diagram med en markör på ett pappersark än på en tavla, och till och med bättre än på en smartboard.

Bilderna du ser är hur hotellets konferensrum såg ut den fjärde dagen av vårt möte. Och vi använde dessa scheman för att söka efter mönster, det vill säga arketyper.

Så jag ställer frågor till arbetarna, de skriver ner svaren med markörer i tre färger (svart, röd och blå). Jag analyserar deras svar för arketyper. Låt oss nu diskutera alla arketyperna i ordning.

1. Gör allt arbete synligt: ​​Gör arbetet synligt

De flesta företag jag jobbar med har en mycket hög andel okänt arbete. Det är till exempel när en anställd kommer till en annan och bara ber om att få göra något. I stora organisationer kan det förekomma 60 % oplanerat arbete. Och upp till 40 % av arbetet är inte dokumenterat på något sätt. Om det var Boeing skulle jag aldrig gå ombord på deras plan igen i mitt liv. Om endast hälften av arbetet är dokumenterat är det inte känt om detta arbete utförs korrekt eller inte. Alla andra metoder visar sig vara värdelösa - det är ingen idé att försöka automatisera någonting, eftersom de kända 50% kan vara den mest sammanhängande och tydliga delen av arbetet, vars automatisering inte kommer att ge bra resultat, och allt det värsta saker är i den osynliga halvan. I avsaknad av dokumentation är det omöjligt att hitta alla typer av hacks och dolt arbete, inte att hitta flaskhalsar, just de där "Brents" som jag redan pratat om. Det finns en underbar bok av Dominica DeGrandis "Göra arbetet synligt". Hon avslöjar fem olika "tidsläckor" (tidstjuvar):

• För mycket arbete pågår (WIP)
• Okända beroenden
• Oplanerat arbete
• Motstridiga prioriteringar
• Försummat arbete

Detta är en mycket värdefull analys och boken är fantastisk, men alla dessa råd är värdelösa om bara 50 % av data är synliga. De metoder som Dominica föreslagit kan användas om en noggrannhet på över 90 % uppnås. Jag pratar om situationer där en chef ger en underordnad en 15-minutersuppgift, men det tar honom tre dagar; men chefen vet inte riktigt att denna underordnade är beroende av fyra eller fem andra personer.

The Phoenix Project är en underbar berättelse om ett projekt som var tre år för sent. En av karaktärerna möter uppsägning på grund av detta, och han möter en annan karaktär som framställs som en sorts Sokrates. Han hjälper till att ta reda på vad som gick fel. Det visar sig att företaget har en systemadministratör, som heter Brent, och allt arbete går på något sätt genom honom. På ett av mötena får en av de underordnade frågan: varför tar varje halvtimmesuppgift en vecka? Svaret är en mycket förenklad presentation av köteori och Littles lag och i denna presentation visar det sig att vid 90 % beläggning tar varje arbetstimme 9 timmar. Varje uppgift måste skickas till sju andra personer, så den timmen blir 63 timmar, 7 gånger 9. Vad jag säger är att för att kunna använda Little's Law eller någon komplex köteori måste du åtminstone ha data.

Så när jag pratar om synlighet menar jag inte att allt är på skärmen utan att man åtminstone har data. När de gör det visar det sig ofta att det är väldigt mycket oplanerat arbete som på något sätt skickas till Brent när det inte behövs. Och Brent är en fantastisk kille, han kommer aldrig att säga nej, men han berättar inte för någon hur han gör sitt jobb.

När verket är synligt kan data prydligt klassificeras (det är vad Dominika gör på bilden), abstraktionen av de fem tidsläckorna kan tillämpas och automatisering kan tillämpas.

2. Konsolidera arbetsledningssystem: Task Management

De arketyper jag pratar om är en sorts pyramid. Om den första görs korrekt är den andra redan ett slags tillägg. Många av dessa fungerar inte för startups, de måste hållas i åtanke för större företag som Fortune 5000. Det senaste företaget jag arbetade för hade 10 biljettsystem. Ett team hade Remedy, ett annat skrev något slags eget system, ett tredje använde Jira och några klarade sig med e-post. Samma problem uppstår om företaget har 30 olika pipelines, men jag har inte tid att diskutera alla sådana fall.

Jag diskuterar med människor exakt hur biljetter skapas, vad som händer med dem härnäst och hur de kringgås. Det mest intressanta är att människor på våra möten talar ganska uppriktigt. Jag frågade hur många som sätter "minor / no impact" på biljetter som egentligen borde ges "stor påverkan". Det visade sig att nästan alla gör detta. Jag ägnar mig inte åt fördömande och försöker på alla möjliga sätt att inte identifiera personer. När de uppriktigt erkänner något för mig, ger jag inte bort personen. Men när nästan alla går förbi systemet betyder det att all säkerhet i huvudsak är fönsterputsning. Därför kan inga slutsatser dras från data från detta system.

För att lösa biljettproblemet måste du välja ett huvudsystem. Om du använder Jira, behåll det Jira. Om det finns något alternativ, låt det vara det enda. Summan av kardemumman är att biljetter ska ses som ytterligare ett steg i utvecklingsprocessen. Varje åtgärd måste ha en biljett, som måste flyta genom utvecklingsarbetsflödet. Biljetter skickas till teamet som lägger upp dem på storyboarden och sedan tar ansvar för dem.

Detta gäller alla avdelningar, inklusive infrastruktur och verksamhet. I det här fallet är det möjligt att bilda sig åtminstone en rimlig uppfattning om tillståndet. När denna process väl är etablerad blir det plötsligt lätt att identifiera vem som är ansvarig för varje ansökan. För nu får vi inte 50 %, utan 98 % av nya tjänster. Om denna kärnprocess fungerar, förbättras noggrannheten i hela systemet.

Tjänster pipeline

Detta gäller återigen bara stora företag. Om du är ett nytt företag inom ett nytt område, kavla upp ärmarna och arbeta med din Travis CI eller CircleCI. När det gäller Fortune 5000-företag, ett exempel som hände på banken där jag arbetade. Google kom till dem och de visades diagram över gamla IBM-system. Killarna från Google frågade förvirrat - var finns källkoden för detta? Men det finns ingen källkod, inte ens ett GUI. Detta är verkligheten som stora organisationer måste hantera: 40-åriga bankregister på en uråldrig stordator. En av mina kunder använder Kubernetes-behållare med Circuit Breaker-mönster, plus Chaos Monkey, allt för KeyBank-applikationen. Men dessa behållare ansluter i slutändan till en COBOL-applikation.

Killarna från Google var helt övertygade om att de skulle lösa alla min klients problem, och sedan började de ställa frågor: vad är IBM datapipe? De får höra: det här är en kontakt. Vad ansluter den till? Till Sperry-systemet. Och vad är det? Och så vidare. Vid första anblicken verkar det: vilken typ av DevOps kan det finnas? Men i själva verket är det möjligt. Det finns leveranssystem som låter dig lämna över arbetsflödet till leveransteamen.

3. Theory of Constraints: Theory of Constraints

Låt oss gå vidare till den tredje arketypen: institutionell/”stam” kunskap. Som regel finns det i vilken organisation som helst flera personer som vet allt och hanterar allt. Det är de som har varit i organisationen längst och som kan alla lösningar.

När detta kommer upp på diagrammet ringar jag specifikt in sådana personer med en markör: till exempel visar det sig att en viss Lou är närvarande vid alla möten. Och det är klart för mig: det här är lokala Brent. När CIO väljer mellan mig i T-shirt och sneakers och killen från IBM i kostym blir jag utvald för att jag kan berätta saker för regissören som den andra killen inte kommer att berätta och som regissören kanske inte gillar att höra . Jag berättar att flaskhalsen i deras företag är någon som heter Fred och någon som heter Lou. Den här flaskhalsen måste lösas, deras kunskap måste hämtas från dem på ett eller annat sätt.

För att lösa den här typen av problem kan jag till exempel tipsa om att använda Slack. En smart regissör kommer att fråga - varför? Vanligtvis, i sådana fall, svarar DevOps-konsulter: eftersom alla gör det. Om regissören är riktigt smart kommer han att säga: så vad. Och det är här dialogen slutar. Och mitt svar på detta är: eftersom det finns fyra flaskhalsar i företaget, Fred, Lou, Susie och Jane. För att institutionalisera sin kunskap måste man först introducera Slack. Alla dina wikis är fullständigt nonsens eftersom ingen vet om deras existens. Om ingenjörsteamet är involverat i front-end- och back-end-utveckling och alla behöver veta att de kan kontakta front-end-utvecklingsteamet eller infrastrukturteamet med frågor. Det är då Lou eller Fred förmodligen kommer att hinna gå med i wikin. Och sedan i Slack kanske någon frågar varför, till exempel, steg 5 inte fungerar. Och då kommer Lou eller Fred att korrigera instruktionerna på wikin. Om du etablerar denna process kommer många saker att falla på plats av sig själva.

Det här är min huvudsakliga poäng: för att rekommendera någon högteknologi måste du först sätta grunden för dem i ordning, och detta kan göras med de lågteknologiska lösningarna som just beskrivits. Om du börjar med högteknologier och inte förklarar varför de behövs, så slutar detta som regel inte bra. En av våra kunder använder Azure ML, en mycket billig och enkel lösning. Cirka 30 % av deras frågor besvarades av den självlärande maskinen. Och den här saken skrevs av operatörer som inte var inblandade i datavetenskap, statistik eller matematik. Detta är betydelsefullt. Kostnaden för en sådan lösning är minimal.

4. Samarbetshack: Samarbetshack

Den fjärde arketypen är behovet av att bekämpa isolering. De flesta vet redan detta: isolering föder fientlighet. Om varje avdelning är på sin egen våning, och människor inte korsar varandra på något sätt, förutom i hissen, uppstår fientlighet mellan dem mycket lätt. Men om människor tvärtom befinner sig i samma rum med varandra går hon genast iväg. När någon slänger ur sig någon allmän anklagelse, till exempel fungerar ett sådant och ett sådant gränssnitt aldrig, det finns inget lättare att dekonstruera en sådan anklagelse. Programmerarna som skrev gränssnittet behöver bara börja ställa specifika frågor, och det kommer snart att stå klart att till exempel användaren helt enkelt använde verktyget felaktigt.

Det finns många sätt att övervinna isolering. Jag blev en gång ombedd att konsultera för en bank i Australien, men jag vägrade att göra det eftersom jag har två barn och en fru. Allt jag kunde göra för att hjälpa dem var att rekommendera grafiskt berättande. Detta är något som bevisligen fungerar. Ett annat intressant sätt är magra kaffemöten. I en stor organisation är detta ett utmärkt alternativ för att sprida kunskap. Dessutom kan du genomföra interna devopsdays, hackathons och så vidare.

5. Coaching Kata

Som jag varnade i början, kommer jag inte att prata om detta idag. Om du är intresserad kan du ta en titt några av mina presentationer.

Det finns också ett bra föredrag om detta ämne från Mike Rother:

6. Marknadsorienterad: marknadsorienterad organisation

Det finns olika problem här. Till exempel "I"-personer, "T"-personer och "E"-personer. "Jag" människor är de som bara gör en sak. Vanligtvis finns de i organisationer med isolerade avdelningar. "T" är när en person är bra på en sak men också bra på vissa andra saker. "E" eller till och med "kam" är när en person har många färdigheter.

Conways lag fungerar här (Conways lag), vilket i den mest förenklade formen kan uttryckas enligt följande: om tre team arbetar på kompilatorn, så blir resultatet en kompilator av tre delar. Därför, om det finns en hög nivå av isolering inom en organisation, så kommer även Kubernetes, Circuit breaker, API-utvidgning och andra tjusiga saker i denna organisation att ordnas på samma sätt som organisationen själv. Strikt enligt Conway och trots alla er unga nördar.

Lösningen på detta problem har beskrivits många gånger. Det finns till exempel organisatoriska arketyper beskrivna av Fernando Fernandez. Den där problematiska arkitekturen som jag just pratade om, med isolering, är en funktionsorienterad arkitektur. Den andra typen är den värsta, matrisarkitektur, en röra av de andra två. Den tredje är vad man ser i de flesta startups, och stora företag försöker också matcha denna typ. Det är en marknadsorienterad organisation. Här optimerar vi för att uppnå snabbast svar på kundförfrågningar. Detta kallas ibland för en platt organisation.

Många beskriver den här strukturen på olika sätt, jag gillar formuleringen bygga/köra lag, på Amazon kallar de det två pizzalag. I den här strukturen är alla typ "I"-personer grupperade runt en tjänst, och gradvis kommer de närmare typ "T", och om rätt ledning finns på plats kan de till och med bli "E". Det första motargumentet här är att en sådan struktur innehåller onödiga element. Varför behöver man en testare på varje avdelning om man kan ha en speciell avdelning med testare? Till vilket jag svarar: extrakostnaderna i det här fallet är priset för att hela organisationen ska bli typ “E” i framtiden. I denna struktur lär sig testaren gradvis om nätverk, arkitektur, design etc. Som ett resultat är varje deltagare i organisationen fullt medveten om allt som händer i organisationen. Om du vill veta hur detta system fungerar i industrin, läs Mike Rother, Toyota Kata.

7. Vänsterskifte-revisorer: revision tidigt i cykeln. Överensstämmelse med säkerhetsregler på displayen

Det är när dina handlingar inte klarar lukttestet så att säga. De som arbetar för dig är inte dumma. Om de, som i exemplet ovan, satte mindre/ingen påverkan överallt, detta varade i tre år, och ingen märkte något, då vet alla mycket väl att systemet inte fungerar. Eller ett annat exempel - en förändringsrådgivning, där rapporter måste lämnas in varje, till exempel, onsdag. Det är en grupp människor som arbetar där (förresten inte särskilt välbetalda) som i teorin borde veta hur systemet som helhet fungerar. Och under de senaste fem åren har du säkert märkt att våra system är otroligt komplexa. Och fem eller sex personer måste fatta ett beslut om en förändring som de inte har gjort och som de inte vet något om.

Naturligtvis fungerar inte detta tillvägagångssätt. Jag måste bli av med sådana saker eftersom dessa människor inte skyddar systemet. Beslutet måste fattas av laget självt, eftersom laget måste ansvara för det. Annars uppstår en paradoxal situation när en chef som aldrig skrivit kod i sitt liv berättar för programmeraren hur lång tid det ska ta att skriva kod. Ett företag jag arbetade med hade 7 olika styrelser som granskade varje förändring, inklusive en arkitekturtavla, en produkttavla, etc. Det fanns till och med en obligatorisk väntetid, även om en anställd berättade för mig att under tio års arbete hade ingen någonsin förkastat en förändring som denna person gjorde under denna obligatoriska period.

Revisorer måste bjudas in till oss och inte bli av med dem. Berätta för dem att du skriver oföränderliga binära behållare som, om de klarar alla tester, förblir oföränderliga för alltid. Berätta för dem att du har en pipeline som kod och förklara vad det betyder. Visa dem följande schema: en oföränderlig skrivskyddad binär i en behållare som klarar alla sårbarhetstester; och då inte bara att ingen rör det, de rör inte ens systemet som skapar pipelinen, eftersom det också skapas dynamiskt. Jag har kunder, Capital One, som använder Vault för att skapa något som liknar en blockchain. Revisorn behöver inte visa "recept" från Chef, det räcker med att visa blockkedjan, från vilken det framgår vad som hände med Jira-biljetten i produktion och vem som är ansvarig för den.

Enligt Rapportera, skapad 2018 av Sonatype, fanns det 2017 miljarder OSS-nedladdningsförfrågningar under 87.

De förluster som uppstår på grund av sårbarheter är oöverkomliga. Dessutom inkluderar siffrorna som du nu ser ovan inte alternativkostnader. Vad är DevSecOps i ett nötskal? Låt mig säga direkt att jag inte är intresserad av att prata om hur framgångsrikt detta namn är. Poängen är att eftersom DevOps har varit så framgångsrikt bör vi försöka lägga till säkerhet till den pipelinen.

Ett exempel på denna sekvens:


Detta är ingen rekommendation för specifika produkter, även om jag gillar dem alla. Jag nämnde dem som ett exempel för att visa att DevOps, som från början baserades på det organisatoriska paradigmet i industrin, låter dig automatisera varje steg i arbetet med en produkt.

Och det finns ingen anledning till varför vi inte skulle kunna ta samma inställning till säkerhet.

Totalt

Som avslutning kommer jag att ge några tips för DevSecOps. Du måste inkludera revisorer i processen att skapa dina system och lägga tid på att utbilda dem. Du måste samarbeta med revisorer. Därefter måste du föra en absolut hänsynslös kamp mot falska positiva resultat. Även med det dyraste verktyget för sårbarhetsskanning kan du skapa extremt dåliga vanor bland dina utvecklare om du inte vet vad ditt signal-brusförhållande är. Utvecklare kommer att bli överväldigade av händelser och kommer helt enkelt att ta bort dem. Om du hörde talas om Equifax-historien så är det i stort sett vad som hände där, där den högsta varningsnivån ignorerades. Dessutom måste sårbarheter förklaras på ett sätt som gör det tydligt hur de påverkar verksamheten. Till exempel kan man säga att detta är samma sårbarhet som i Equifax-berättelsen. Säkerhetssårbarheter bör behandlas på samma sätt som andra programvaruproblem, det vill säga de bör inkluderas i den övergripande DevOps-processen. Du måste arbeta med dem genom Jira, Kanban, etc. Utvecklare ska inte tro att någon annan kommer att göra detta – tvärtom, alla ska göra det här. Slutligen måste du lägga energi på att träna människor.

Användbara länkar

Här är några föredrag från DevOops-konferensen som du kan ha nytta av:

• Sergey Berdnikov, Artyom Kalichkin - Framgångssaga, eller "Dev+DevOps+Ops" (video, utskrift av rapporten)
• Baruch Sadogursky, Leonid Igolnik - DevOps på en skala: en grekisk tragedi i tre akter (video, utskrift av rapporten)
• Alexander Titov, Kirill Tolkachev - DevOps, ingenjörer och community
• Timothy Lister - Karaktärer, gemenskap och kultur: Viktiga faktorer för välstånd

Kolla upp programmet DevOops 2020 Moskva — Det finns också mycket intressant där.

Källa: will.com