🥇Sju arketyper för transformation baserat på DevOps-principer

Frågan om "hur man implementerar DevOps" har ställts under många år, men det finns inte så många bra material. Ibland blir man ett offer för reklamen från inte så smarta konsulter, vars enda mål är att sälja sin tid, oavsett hur. Ibland handlar det om otydliga, extremt generella påståenden om hur megaföretagens fartyg navigerar genom universum. Frågan uppstår: vad har vi att vinna på det? Bäste författare, kan du tydligt lista dina idéer?

Allt detta beror på att det inte finns så mycket verklig praktik och förståelse för resultatet av företagskulturens transformation. Förändringar i kulturen är långsiktiga processer vars resultat inte visar sig om en vecka eller en månad. Vi behöver någon som är tillräckligt gammal och har sett hur företag har skapats och kollapsat under många år.

John Willis är en av fäderna till DevOps. John har hundratals års erfarenhet av att arbeta med ett stort antal företag. På senare tid har John börjat märka specifika mönster som förekommer i arbetet med var och en av dem. Genom att använda dessa arketypier vägleder John företag mot den sanna vägen för DevOps-transformation. Mer om dessa arketypier finns i översättningen av hans föreläsning från konferensen DevOops 2018.

Om föreläsaren:

Mer än 35 års erfarenhet inom IT-ledarskap, deltog i skapandet av föregångaren till OpenCloud på Canonical, har varit involverad i 10 startups, två av dem sålda till Dell och Docker. Just nu är han Vice President of DevOps and Digital Practices på SJ Technologies.

Härnäst – en berättelse från Johns perspektiv.

Jag heter John Willis och det enklaste sättet att nå mig på Twitter är @botchagalupe. Jag använder samma pseudonym på Gmail och GitHub. Du kan också hitta videoinspelningar av mina föreläsningar och tillhörande presentationer. via denna länk du kan hitta videoinspelningar av mina föreläsningar och presentationer till dem.

Jag har många möten med CIO:er från olika stora företag. De klagar ofta på att de inte förstår vad DevOps är, och alla som försöker förklara det pratar om något helt annat. En annan vanlig klagomål är att DevOps inte fungerar, även om direktörerna verkar följa instruktionerna. Det handlar om stora företag som har funnits i över hundra år. Efter att ha pratat med dem har jag kommit fram till att för många problem är det inte högteknologiska lösningar som passar bäst, utan relativt lågteknologiska. Jag har i veckor bara pratat med folk från olika avdelningar. Det som ni ser på den första bilden i inlägget är mitt senaste projekt; rummet såg ut så här efter tre dagars arbete.

Vad är DevOps?

Verkligen, om man frågar 10 olika personer kommer de att ge 10 olika svar. Men här är det intressanta: alla dessa tio svar är korrekta. Det finns inget fel svar här. Jag har sysslat djupt med DevOps i ungefär 10 år och var den första amerikanen på den första DevOps Day. Jag skulle inte säga att jag är smartare än alla som arbetar med DevOps, men det finns nog ingen som har lagt ner lika mycket tid och energi. Jag anser att DevOps uppstår när människokapital och teknologi förenas. Vi glömmer ofta det mänskliga perspektivet, även om vi pratar mycket om olika kulturer.

Nu har vi mycket data, fem års akademisk forskning, och teorierna har testats i industriell skala. Denna forskning säger oss följande: om man kopplar samman vissa beteendemönster i organisationskulturen kan man få en acceleration på 2000 gånger. Denna acceleration återspeglar en motsvarande förbättring i hållbarhet. Det är en kvantitativ mätning av den fördel som DevOps kan ge vilket företag som helst. För ett par år sedan berättade jag om DevOps för VD:n i ett företag på Fortune 5000-listan. När jag förberedde mig för presentationen var jag oerhört nervös, eftersom jag behövde sammanfatta mina många års erfarenhet på fem minuter.

Som ett resultat gav jag följande definition av DevOps: det är en uppsättning praktiker och mönster som gör det möjligt att omvandla människokapital till högpresterande organisatoriskt kapital. Ett exempel är hur Toyota har arbetat de senaste 50 eller 60 åren.

(Här och vidare ges sådana scheman inte som referensmaterial, utan som illustration. Innehållet kommer att skilja sig åt för varje ny företag. Ändå kan man titta på bilden separat och förstora den. via denna länk.)

En av de mest framgångsrika sådana praktiker är value stream mapping. Det har skrivits flera bra böcker om detta, den mest framgångsrika av dem är av Karen Martin. Men under det senaste året har jag kommit fram till att även denna metod är för högteknologisk. Den har utan tvekan många fördelar, och jag har använt den mycket. Men när VD:n frågar dig varför hans företag inte kan gå över till nya spår, är det för tidigt att prata om value stream mapping. Det finns många betydligt mer grundläggande frågor som måste besvaras först.

Jag tror att felet hos många av mina kollegor är att de helt enkelt ger företaget en vägledning med fem punkter och sedan kommer tillbaka efter sex månader för att se vad som har hänt. Även med ett bra schema som value stream mapping finns det, för att säga så, döda zoner (blind spots). Efter hundratals intervjuer med direktörer från olika företag har jag utvecklat ett visst mönster som gör att jag kan bryta ner problemet i dess beståndsdelar, och nu kommer vi att diskutera var och en av dessa beståndsdelar i tur och ordning. Innan jag tillämpar några tekniska lösningar använder jag detta mönster, och i resultatet visar sig alla mina väggar vara fulla av scheman. Nyligen arbetade jag med en viss fond, och jag slutade med 100-150 sådana scheman.

Dålig kultur äter bra metoder till frukost

Huvudtanken är: inga Lean, Agile, SAFE och DevOps kommer att hjälpa om själva kulturen i organisationen är dålig. Det är som att dyka på djupet utan dykardräkt eller operera utan röntgenbild. Med andra ord, för att omformulera Drucker och Deming: dålig organisationskultur kommer att sluka vilket bra system som helst och inte kvävas.

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

Make All Work Visible: man 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.
Consolidate Work Management Systems: det är nödvändigt att konsolidera ledningssystemen. I frågan om "stam" kunskap och institutionell kunskap är det i 9 av 10 fall de människor som utgör flaskhalsen. I boken "Phoenix Project" handlade problemet om en enda person, Brent, som gjorde att projektet var tre år försenat. Och jag stöter på sådana "Brent" överallt. För att lösa dessa flaskhalsar använder jag följande två punkter i vår lista.
Theory of Constraints Methodology: teorin om begränsningar.
Collaboration hacks: samarbete hacks.
Toyota Kata (Coaching Kata): jag kommer inte att prata mycket om Toyota Kata. Om du är intresserad, på min github finns presentationer nästan om varje av dessa ämnen.
Market Oriented Organization: marknadsorienterad organisation.
Shift-left auditors: revision i tidiga skeden av cykeln.

Jag börjar arbeta med organisationen ganska enkelt: jag går in i företaget och pratar med medarbetarna. Som vi ser, inga högteknologiska lösningar. Allt som behövs är något att skriva på. Jag samlar flera team i ett rum och analyserar vad de säger utifrån mina 7 arketyper. Och sen ger jag dem en marker och ber dem skriva ner allt de hittills har sagt högt på tavlan. Vanligtvis är det en person på sådana möten som skriver ner allt, och i bästa fall lyckas han fånga 10% av diskussionen. Med min metod kan den siffran höjas till omkring 40%.

(Den här illustrationen kan ses via länken)

Min metod bygger på arbetet av William Schneider (William Schneider, The Reengineering Alternative). Grunden för metoden är tanken att varje organisation kan delas upp i fyra kvadranter. Denna modell är ofta resultatet av arbetet med de hundratals andra modeller som uppstår vid analysen av organisationen. Anta att vi har en organisation med hög kontrollnivå, men samtidigt låg kompetens. Detta är en extremt oönskad variant: där alla följer reglerna, men ingen vet vad de ska göra.

Ett något bättre alternativ med hög nivå av både kontroll och kompetens. Om ett sådant företag är lönsamt, kanske DevOps inte ens behövs. Mest intressant är det att arbeta med ett företag som har hög kontroll, låg kompetens och samarbete, men samtidigt en hög nivå av kultur. Det betyder att det finns många människor i företaget som trivs där och att personalomsättningen är låg.

(Den här illustrationen kan ses via länken)

Jag tror att metoder med fastställda rekommendationer i slutändan förhindrar att man når sanningen. Specifikt i value stream mapping finns det många regler för hur information ska struktureras. I de tidiga faser av arbetet, som jag pratar om nu, behövs dessa regler inte. Om någon med en markeringspenna beskriver den verkliga situationen på en tavla är det det bästa sättet att förstå läget. Den informationen når inte direktörerna. Just då är det dumt att avbryta personen och säga att de har ritat en pil fel. I det här skedet är det bättre att använda enkla regler, till exempel: en flernivåabstraktion kan skapas genom att bara använda färgglada markörer.

Jag upprepar, inga högteknologiska lösningar. Med en svart markeringspenna avbildas den objektiva verkligheten, hur allt fungerar. Med en röd markeringspenna markerar folk vad de inte gillar med den aktuella situationen. Det viktiga är att det är de som skriver det, inte jag. När jag efter mötet går till IT-chefen föreslår jag inte en lista med 10 saker som måste åtgärdas. Jag försöker hitta samband mellan vad företagsmedlemmarna säger och de befintliga beprövade mönstren. Slutligen föreslås trevliga lösningar på problemet med en blå markeringspenna.

(Den här illustrationen kan ses via länken)

Ett exempel på ett sådant tillvägagångssätt visas ovan. I början av året arbetade jag med en bank. Anställda från säkerhetsavdelningen var övertygade om att de inte fick delta i kontroller av krav och design (design and requirement reviews).

(Den här illustrationen kan ses via länken)

Sedan pratade vi med människor från andra avdelningar och det visade sig att för ungefär 8 år sedan hade mjukvaruutvecklarna stängt ute säkerhetsanställda eftersom de fördröjde arbetet. Och sedan utvecklades det till ett förbud som uppfattades som en självklarhet. Även om det egentligen inte fanns något förbud.

Vår möte fortskred på en mycket förvirrad väg: under ungefär tre timmar kunde fem olika team inte förklara för mig vad som händer mellan koden och byggandet. Det borde vara den enklaste saken. Många DevOps-konsulter förutsätter i förväg att detta redan är allmängiltig kunskap.

Sedan vaknade personen som ansvarade för IT-styrning, och som varit tyst i fyra timmar, plötsligt till liv när vi nådde hans ämne och höll oss sysselsatta under en ganska lång tid. Mot slutet frågade jag honom vad han tyckte om mötet, och jag kommer aldrig att glömma hans svar. Han sa: "Tidigare trodde jag att det fanns två sätt att leverera mjukvara i vår bank, men nu vet jag att det finns hela fem, och jag hade ingen aning om tre av dem."

(Den här illustrationen kan ses via länken)

Det sista mötet i denna bank var med ett team som arbetar med investeringprogramvara. Just med dem blev det tydligt att det är bättre att skriva scheman med en penna på papper än på en tavla, och till och med bättre än på en smartboard.

Foton som ni ser är hur konferensrummet på hotellet såg ut den fjärde dagen av vårt möte. Dessa scheman använde vi för att identifiera mönster, det vill säga arketyper.

Så jag ställer frågor till medarbetarna, och de skriver ner svaren med tre olika färger (svart, röd och blå). Jag analyserar deras svar efter arketyper. Nu ska vi diskutera alla arketyper i ordning.

1. Make All Work Visible: Göra allt arbete synligt

I de flesta företag jag arbetar med är en stor andel av arbetet oklart. Till exempel när en anställd ber en annan om något. I stora organisationer kan upp till 60% av arbetet vara oplanerat. Även så mycket som 40% av arbetet är på något sätt icke-dokumenterat. Om det var Boeing skulle jag aldrig våga flyga med dem igen. Om bara hälften av arbetet dokumenteras vet man inte om det görs rätt. Alla andra metoder visar sig vara värdelösa - det finns inget syfte med att försöka automatisera någonting, eftersom de kända 50% kan vara just den mest strukturerade och tydliga delen av arbetet, automatisering av vilket inte ger stora resultat, medan allt som är problematiskt finns i den osynliga hälften. Utan dokumentation är det omöjligt att hitta olika knep och dolda arbeten, att identifiera flaskhalsar, de så kallade "Brentarna" som jag redan har nämnt. Det finns en utmärkt bok av Dominica DeGrandis. «Making Work Visible». Den identifierar fem olika "tjuvar av tid" (thieves of time):

För mycket arbete i process (WIP)
Okända beroenden
Oplanerat arbete
Motsägelsefulla 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 endast 50% av datan är synlig. Att använda metoderna som föreslås av Dominica kan endast ske om man har en noggrannhet över 90%. Jag pratar om situationer där en chef ger en anställd en 15-minutersuppgift, men det tar tre dagar; men chefen vet faktiskt inte att den anställde är beroende av fyra eller fem andra personer.

Phoenix Project är en fantastisk berättelse om ett projekt som är tre år försenat. En av hjältarna riskerar att bli avskedad på grund av detta och han träffar en annan karaktär, som presenteras som en sorts Sokrates. Denne hjälper till att förstå vad som egentligen har gått fel. Det visar sig att det finns en systemadministratör i företaget som heter Brent, och allt arbete går på ett eller annat sätt genom honom. På ett av mötena frågar en av hans underställda: varför tar varje halvtimmesuppgift en vecka? Som svar ges en mycket förenklad redogörelse för köteori och Littles lag, och i denna redogörelse framkommer att vid 90 % beläggning tar varje arbetstimme 9 timmar. Varje uppgift måste skickas till sju andra personer, vilket gör att denna timme förvandlas till 63 timmar, 7 multiplicerat med 9. Jag säger detta för att poängtera att för att kunna använda Littles lag eller någon som helst avancerad köteori måste man åtminstone ha data.

Så när jag talar om synlighet menar jag inte att allt ska vara på skärmen, utan att man åtminstone behöver ha data. När de finns, visar det sig ofta att det finns en väldigt stor mängd oplanerat arbete som av någon anledning riktas till Brent, fast det inte finns något behov av det. Och Brent är en fantastisk kille, han skulle aldrig säga "nej", men samtidigt berättar han inte för någon hur han gör sitt arbete.

När arbetet är synligt kan man noggrant klassificera data (detta är exakt vad Dominika gör på bilden), man kan tillämpa abstraktionen av de fem tidsläckorna och automatisera.

2. Konsolidera arbetsledningssystem: Uppgiftsledning

Arketyperna, som jag talar om, utgör en slags pyramid. Om den första är korrekt utförd, blir den andra en slags överbyggnad. Många av dem fungerar inte för startups; de bör beaktas i fallet med stora företag, som de som hamnar på Fortune 5000-listan. På det senaste företaget jag arbetade för fanns det 10 system för ärendehantering (ticketing system). I ett team fanns Remedy, ett annat hade skrivit sitt eget system, det tredje använde Jira, någon klarade sig till och med med e-post. Samma problem uppstår om företaget har 30 olika pipeliner, men jag har ingen tid att diskutera alla dessa fall.

Jag diskuterar med människor hur biljetter skapas, vad som händer med dem efteråt och hur de kringgås. Det mest intressanta är att människor på våra möten pratar ganska uppriktigt. Jag frågade hur många som sätter "mindre / ingen påverkan" på biljetter som egentligen borde ha fått "stor påverkan". Det visade sig att nästan alla gör så. Jag sysslar inte med angiveri och försöker på alla sätt att inte identifiera människor. När jag får uppriktiga erkännanden i något, avslöjar jag inte personen. Men när praktiskt taget alla kringgår systemet, betyder det att hela säkerheten i grunden är en dekoration. Därför kan inga slutsatser dras från uppgifterna i det här systemet.

För att lösa problemet med biljetter måste en huvudsystem väljas. Om du använder Jira, låt bara vara Jira. Om det finns något alternativ, låt det bara vara det. Poängen är att biljetter måste ses som ett ytterligare steg i utvecklingsprocessen. Varje åtgärd måste ha en biljett som går igenom utvecklingsprocessen. Biljetterna skickas till teamet som lägger upp dem på storyboarden och som sedan ansvarar för dem.

Detta gäller alla avdelningar, inklusive infrastruktur- och driftsavdelningen. På så sätt kan man skapa en mer eller mindre trovärdig bild av läget. När denna process är på plats visar det sig plötsligt att det är lätt att fastställa vem som ansvarar för varje tillämpning. För nu får vi inte 50 %, utan 98 % av nya tjänster. Om denna huvudprocess fungerar, ökar noggrannheten i hela systemet.

Tjänstepipeline

Det här gäller återigen bara stora företag. Om du är ett nytt företag inom ett nytt område - rulla upp ärmarna och arbeta med din Travis CI eller CircleCI. När det kommer till Fortune 5000-företag, är ett exempel fallet med banken där jag arbetade. Google kom dit och visade diagram med gamla IBM-system. Killarna från Google frågade förvånat - var är koden för detta? Det finns ingen kod, inte ens något GUI. Det är verkligheten stora organisationer måste hantera: 40-åriga banktransaktioner på en gammal mainframe. En av mina kunder använder Kubernetes-containrar med Circuit Breaker-mönster, plus Chaos Monkey, allt detta för applikationen KeyBank. Men till slut ansluts dessa containrar till en applikation i COBOL.

Killarna från Google var helt övertygade om att de skulle lösa alla problem för min kund, och sedan började de ställa frågor: vad är IBM datapipe? De får svaret: det är en anslutning. Vad ansluter den till? Till systemet Sperry. Och vad är det? Och så vidare. Vid första anblick verkar det: vad har vi för DevOps här? Men egentligen är det möjligt. Det finns leveranssystem som tillåter att överföra arbetsflödet till team som arbetar med leverans.

3. Begränsningarnas teori: Theory of Constraints

Låt oss gå vidare till den tredje arketypen: institutionell / "tribal" kunskap. Det finns vanligtvis några personer inom varje organisation som vet allt och styr alla. Det är de som har varit störst tid i organisationen och som känner till alla omvägar.

När detta framgår i diagrammet markerar jag avsiktligt sådana personer med en markeringspenna: till exempel visar det sig att en viss Lou är närvarande på alla möten. Och för mig är det klart: detta är den lokala Brent. När it-chefen måste välja mellan mig i t-shirt och sneakers och en kille från IBM i kostym, väljer de mig för att jag kan berätta för chefen om saker som den andra killen inte kommer att berätta och som kan vara obehagliga för chefen att höra. Jag säger till dem att det finns en flaskhals i deras företag, någon vid namn Fred och någon vid namn Lou. Denna flaskhals måste lösas, deras kunskap måste på ett eller annat sätt fås fram.

För att lösa denna typ av problem kan jag till exempel föreslå att använda Slack. En smart chef skulle fråga – varför? Vanligtvis svarar DevOps-konsulter så här: därför att alla gör så. Om chefen faktiskt är smart skulle han säga: och vadå? Och där slutar dialogen. Och jag svarar: därför att företaget har fyra flaskhalsar, Fred, Lou, Suzy och Jane. För att institutionaliserad kunskap ska uppnås måste Slack införas. Alla era wikis är fullständigt meningslösa eftersom ingen vet att de existerar. Om ingenjörsteamet arbetar med både extern och intern utveckling måste alla veta att de kan kontakta den externa utvecklingsteamet eller infrastrukturteamet med frågor. Just då kan Lou eller Fred ha tid att kolla wikin. Och sen kan någon fråga i Slack varför steg 5 inte fungerar, och då kan Lou eller Fred rätta instruktionerna i wikin. Om man får den här processen att fungera kommer mycket annat att falla på plats av sig själv.

Min huvudpoäng är att för att kunna rekommendera högteknologiska lösningar måste man först få grunden i ordning, och det är något som kan göras med de just beskrevna lågteknologiska lösningarna. Om man börjar med högteknologi och inte förklarar varför de behövs, slutar det oftast med inget bra. En av våra kunder använder Azure ML, en väldigt billig och enkel lösning. Någonstans runt 30% av frågorna besvarades redan av den självlärande maskinen. Och det var operatörer som skrev detta, som inte hade sysslat med data science, statistik eller matematik. Det är intressant. Kostnaden för en sådan lösning är minimal.

4. Samarbetsförbättringar: Hacka samarbetet

Den fjärde arketypen handlar om att bekämpa isolering. De flesta vet redan detta: isolering skapar fientlighet. Om varje avdelning är på sin egen våning, och människor inte träffas annat än i hissen, uppstår fientlighet lätt. Men om människor istället är i samma rum försvinner den genast. När någon framför en allmän anklagelse, till exempel att ett visst gränssnitt aldrig fungerar — finns det inget enklare än att avfärda en sådan anklagelse. För programmerarna som har skrivit gränssnittet räcker det att börja ställa specifika frågor, så visar det sig snart att användaren helt enkelt har använt verktyget felaktigt.

Det finns många sätt att övervinna isolering. Jag blev en gång ombedd att rådgiva en bank i Australien, men jag avböjde för jag har två barn och en fru. Allt jag kunde hjälpa dem med var att rekommendera dem graphical storytelling. Det är något som bevisligen fungerar. Ett annat intressant sätt är möten i lean coffee-format. I en stor organisation är detta ett utmärkt alternativ för kunskapsdelning. Dessutom kan man anordna interna devopsdays, hackathons och så vidare.

5. Coaching Kata

Som jag redan varnat i början kommer jag inte att berätta om detta idag. Om du är intresserad kan du titta på några av mina presentationer.

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

6. Marknadsinriktad: marknadsorienterad organisation

Här finns olika problem. Till exempel personer med typ "I", personer med typ "T" och personer med typ "E". Personer med typ "I" är de som håller på med endast en sak. De finns vanligtvis i organisationer med isolerade avdelningar. "T" innebär att personen är duktig på en sak, men också framgångsrik inom vissa andra områden. "E" eller till och med "kam” — det är när en person har många färdigheter.

Här gäller Conway's lag (Conway’s law), som i sin mest förenklade form kan uttryckas så här: om tre team arbetar med en kompilator, kommer det att resultera i en kompilator som består av tre delar. Därför, om det finns en hög nivå av isolering inom organisationen, kommer till och med Kubernetes, Circuit breaker, API extensibility och andra moderna lösningar i denna organisation att organiseras på samma sätt som själva organisationen. Strikt enligt Conway och till trots för er alla, unga nördar.

Problemet har beskrivits många gånger. Det finns till exempel organisatoriska arketyper som beskrivits av Fernando Fernandez. Den problematiska arkitektur som jag just har nämnt, med isolering, är en funktionsorienterad arkitektur. Den andra typen, som är den sämsta, är en matrisarkitektur som består av en blandning av de två andra. Den tredje typen är vad man ser i de flesta startups, och stora företag försöker också anpassa sig till denna typ. Det är en marknadsorienterad organisation. Här handlar det om att optimera för att uppnå det snabbaste svaret på kundförfrågningar. Ibland kallas det en platt organisation.

Många beskriver denna struktur på olika sätt, jag gillar formuleringen build/run teams, på Amazon kallas det two pizza teams. I denna struktur grupperas alla personer av typ "I" runt en tjänst, och gradvis närmar de sig typ "T", och om rätt ledarskap finns kan de till och med bli "E". Det första motargumentet här är att det finns onödiga element i en sådan struktur. Varför behövs en testare på varje avdelning, när man kan ha en speciell testavdelning? Till detta svarar jag: onödiga kostnader i detta fall är priset för att hela organisationen i framtiden ska bli type "E". I en sådan struktur lär sig testaren gradvis om nätverk, arkitektur, design osv. I slutändan är varje deltagare i organisationen helt informerad om allt som pågår i organisationen. Om du vill veta hur denna modell fungerar inom industrin, läs Mike Rother, Toyota Kata.

7. Shift-left auditors: revision i de tidiga faserna av cykeln. Efterlevnad av säkerhetsregler i förgrunden

Det handlar om när dina åtgärder inte klarar, som man säger, lukttestet. Människor som arbetar för dig är inte dumma. Om de, som i exemplet ovan, alltid har angivit minor/no impact, har det pågått i tre år, och ingen har märkt något, så vet alla att systemet inte fungerar. Eller ett annat exempel — en förändringsstyrgrupp, dit varje, låt oss säga, onsdag, rapporter måste lämnas in. Där arbetar en grupp människor (för övrigt inte särskilt välbetalda) som i teorin borde förstå hur systemet fungerar i stort. Och under de senaste fem åren har du nog märkt att våra system är extremt komplexa. Och fem till sex personer borde fatta beslut om en förändring som de inte själva har genomfört och som de inget vet om.

Självklart fungerar inte ett sådant tillvägagångssätt. Jag måste bli av med sådana saker eftersom dessa människor inte skyddar systemet. Beslutet bör fattas av teamet självt, eftersom teamet måste stå ansvarigt för det. Annars uppstår en paradoxal situation där en chef, som aldrig har skrivit en rad kod, berättar för en programmerare hur lång tid det ska ta att skriva koden. På ett företag jag arbetade med fanns det 7 olika råd som granskade varje förändring, inklusive arkitektur- och produktstyrelser, osv. Det fanns till och med en obligatorisk väntetid, även om en kollega sa till mig att ingen under tio år haft avslag på förändringar från den personen under den obligatoriska väntetiden.

Auditorer ska bjudas in istället för att bli av med. Berätta för dem att du skriver oföränderliga binära containrar, som om de klarar alla tester förblir oförändrade för alltid. Berätta för dem att du har pipeline as code och förklara vad det innebär. Visa dem följande schema: en oföränderlig binärfil som är skrivskyddad i en container som klarar alla tester för sårbarheter; och sedan är det inte bara så att ingen rör vid den — ingen rör ens vid systemet som skapar pipeline, eftersom det också skapas dynamiskt. Jag har kunder, Capital One, som med hjälp av Vault skapar något liknande en blockchain. Det är inte nödvändigt att visa auditorn några

Enligt rapportenrecept" från Chef, det räcker att visa blockkedjan, där det tydligt framgår vad som hänt med Jira-biljetten i produktionen och vem som är ansvarig.

Förlusterna på grund av sårbarheter visar sig vara orimligt höga. Och de siffror som du nu ser ovan inkluderar inte alternativa kostnader. I korthet, vad DevSecOps handlar om. Jag vill genast säga att jag inte är intresserad av diskussioner om hur lyckat det namnet är. Poängen är att eftersom DevOps har varit mycket framgångsrika, måste vi försöka lägga till säkerhet till den här pipeline.

Ett exempel på en sådan sekvens:

Detta är inget rekommendation av specifika produkter, även om jag gillar dem alla. Jag tar dem som exempel för att visa att DevOps, som ursprungligen grundades på industriell organisationsparadigm, möjliggör automatisering av varje steg i produktutvecklingen.

Och det finns ingen anledning till varför vi inte skulle kunna tillämpa samma tillvägagångssätt för säkerhet.

Resultat

Som avslutning vill jag ge några råd för DevSecOps. Inkludera auditerare i skapandet av era system och investera tid i deras utbildning. Samarbeta med auditerare. Vidare, bedriv en fullständig och obarmhärtig kamp mot falska positiva resultat. Även med det dyraste verktyget för sårbarhetsskanning kan ni skapa mycket skadliga vanor hos era utvecklare om ni inte förstår signalen till brus-förhållandet. Utvecklarna kommer att bli överbelastade med händelser och börja radera dem. Om ni hört talas om historien med Equifax, så hände just det där; det högsta signalvärdet ignorerades. Dessutom bör sårbarheter förklaras på ett sätt som gör det tydligt hur de påverkar företaget. Till exempel kan ni säga att det är samma sårbarhet som i historien med Equifax. Säkerhetsrelaterade sårbarheter bör behandlas som andra mjukvaruproblem, det vill säga de bör ingå i den övergripande DevOps-processen. De bör hanteras genom Jira, Kanban, etc. Utvecklarna ska inte tro att någon annan ska ta hand om detta — tvärtom, alla ska vara involverade. Slutligen måste ni lägga tid och energi på att utbilda människor.