🥇Zeven archetypen van transformatie volgens de principes van DevOps

De vraag ‘hoe implementeer je DevOps bij jezelf’ bestaat al jaren, maar er zijn niet veel goede materialen. Soms word je slachtoffer van de reclame van niet al te slimme consultants, die hun tijd willen verkopen, ongeacht hoe. Soms krijg je vage, uiterst algemene woorden over hoe de schepen van megacorporaties het universum doorkruisen. De vraag rijst: wat hebben wij daar eigenlijk aan? Geachte auteur, kunt u uw ideeën duidelijk opsommen?

Dit komt voort uit het feit dat er niet veel echte praktijkervaring en begrip is van de uitkomsten van cultuurtransformaties in bedrijven. Veranderingen in cultuur zijn langdurige processen, waarvan de resultaten niet binnen een week of een maand zichtbaar zullen zijn. We hebben iemand nodig die voldoende ervaring heeft en heeft gezien hoe bedrijven jarenlang zijn opgebouwd en weer zijn ingestort.

John Willis is een van de grondleggers van DevOps. John heeft tientallen jaren gewerkt met een groot aantal bedrijven. De laatste tijd begint John specifieke patronen op te merken die zich bij elk van hen voordoen. Met behulp van deze archetypes begeleidt John bedrijven op het juiste pad van DevOps-transformatie. Meer over deze archetypes in de vertaling van zijn lezing op de DevOops-conferentie 2018.

Over de spreker:

Met meer dan 35 jaar ervaring in IT-management, was hij betrokken bij de oprichting van de voorganger van OpenCloud bij Canonical, nam deel aan 10 startups, waarvan er twee zijn verkocht aan Dell en Docker. Momenteel is hij Vice President of DevOps and Digital Practices bij SJ Technologies.

Vervolgens: een verhaal vanuit het perspectief van John.

Mijn naam is John Willis, en je kunt me het gemakkelijkst vinden op Twitter, @botchagalupe. Diezelfde pseudoniem gebruik ik voor Gmail en GitHub. En via deze link kun je video-opnames van mijn lezingen en de presentaties ervan vinden.

Ik heb veel vergaderingen met CIO's van verschillende grote bedrijven. Ze klagen heel vaak dat ze niet begrijpen wat DevOps is, en iedereen die het probeert uit te leggen, praat over zijn eigen onderwerpen. Een andere veel gehoorde klacht is dat DevOps niet werkt, ook al doen de directeuren alles zoals hen is uitgelegd. Het gaat om grote bedrijven die al meer dan honderd jaar bestaan. Na gesprekken met hen ben ik tot de conclusie gekomen dat voor veel problemen niet de hoge technologie, maar relatief laagtechnologische oplossingen het beste werken. Wekenlang heb ik gewoon met mensen uit verschillende afdelingen gesproken. Wat je op de allereerste afbeelding in de post ziet, is mijn laatste project, de kamer zag er zo uit na drie dagen werk.

Wat is DevOps?

Inderdaad, als je 10 verschillende mensen vraagt, zullen ze 10 verschillende antwoorden geven. Maar wat interessant is: al deze tien antwoorden zijn correct. Er is geen verkeerd antwoord. Ik heb me ongeveer 10 jaar met DevOps bezighouden, was de eerste Amerikaan op de eerste DevOpsDay. Ik zal niet zeggen dat ik slimmer ben dan iedereen die met DevOps bezig is, maar het is onwaarschijnlijk dat iemand anders zoveel moeite heeft gedaan. Ik geloof dat DevOps ontstaat wanneer menselijk kapitaal en technologie samenkomen. Vaak vergeten we de menselijke dimensie, hoewel we veel praten over allerlei soorten culturen.

Tegenwoordig hebben we veel gegevens, vijf jaar academisch onderzoek, en theorieën worden op industriële schaal getest. Deze onderzoeken vertellen ons het volgende: als je in de organisatorische cultuur bepaalde gedragspatronen combineert, kun je een versnelling van 2000 keer bereiken. Deze versnelling gaat gepaard met eenzelfde verbetering in stabiliteit. Dit is een kwantitatieve maat van het voordeel dat DevOps elke organisatie kan bieden. Een paar jaar geleden vertelde ik over DevOps aan de CEO van een bedrijf uit de Fortune 5000-lijst. Toen ik me voorbereidde op de presentatie, was ik erg nerveus, omdat ik in 5 minuten mijn jarenlange ervaring moest overbrengen.

Uiteindelijk gaf ik de volgende Definitie van DevOps: het is een set van praktijken en patronen die het mogelijk maken om menselijk kapitaal om te zetten in hoogpresterend organisatorisch kapitaal. Een voorbeeld is de manier waarop Toyota de afgelopen 50 of 60 jaar functioneert.

(Hier en verder worden dergelijke schema's niet als referentiemateriaal gepresenteerd, maar als illustratie. De inhoud ervan zal voor elk nieuw bedrijf anders zijn. Desalniettemin kan het plaatje afzonderlijk worden bekeken en vergroot. via deze link.)

Een van de meest succesvolle praktijken is — value stream mapping. Hierover zijn verschillende goede boeken geschreven, de auteur van de meest succesvolle is Karen Martin. Maar het afgelopen jaar ben ik tot de conclusie gekomen dat zelfs deze benadering te technologiegericht is. Het heeft ongetwijfeld veel voordelen, ik heb het veel gebruikt. Maar wanneer de CEO je vraagt waarom zijn bedrijf niet kan overstappen op nieuwe rails, dan is het nog te vroeg om over value stream mapping te praten. Er zijn veel aanzienlijk fundamentelere vragen waarop je eerst antwoorden moet vinden.

Ik denk dat de fout van veel van mijn collega's is dat ze het bedrijf gewoon een handleiding met vijf punten geven, en daarna zes maanden later terugkomen om te zien wat er is gebeurd. Zelfs bij een goed schema zoals value stream mapping zijn er, laten we zeggen, blinde vlekken. Na honderden interviews met directeuren van verschillende bedrijven heb ik een bepaald patroon ontwikkeld dat helpt om het probleem in componenten te splitsen, en nu zullen we elke van deze componenten systematisch bespreken. Voordat ik enige technologische oplossingen toepas, gebruik ik dit patroon, en daardoor hangen al mijn muren vol met schema's. Onlangs werkte ik met een beursfonds en uiteindelijk had ik 100-150 van zulke schema's.

Een slechte cultuur eet goede benaderingen als ontbijt.

De belangrijkste gedachte is: geen enkele Lean, Agile, SAFE of DevOps zal helpen als de cultuur van de organisatie slecht is. Het is hetzelfde als duiken op grote diepte zonder zuurstofapparaat of opereren zonder röntgenfoto. Met andere woorden, parafraseer drukker en Deming: een slechte organisatiestructuur zal elk goed systeem opslokken en niet stikken.

Om dit belangrijkste probleem op te lossen, moeten de volgende stappen worden ondernomen:

Maak al het werk zichtbaar: het werk moet zichtbaar worden gemaakt. Niet in die zin dat het noodzakelijk op een bepaald scherm moet worden weergegeven, maar in die zin dat het observeerbaar moet zijn.
Consolideer werkbeheer systemen: Het is noodzakelijk om managementsystemen te consolideren. In het probleem van ‘stam’ kennis en institutionele kennis zijn in 9 van de 10 gevallen mensen de bottlenecks. In het boek ‘Phoenix Project’ was het probleem een enkele persoon, Brent, waardoor het project drie jaar achterliep. En dergelijke ‘Brents’ kom ik overal tegen. Voor het oplossen van deze bottlenecks gebruik ik de volgende twee punten in onze lijst.
Theory of Constraints Methodology: de theorie van beperkingen.
Collaboration hacks: samenwerkingshacks.
Toyota Kata (Coaching Kata): over Toyota Kata zal ik niet veel zeggen. Als je geïnteresseerd bent, op mijn GitHub zijn presentaties over bijna elk van deze onderwerpen.
Market Oriented Organization: marktorienterende organisatie.
Shift-left auditors: audits in de vroege stadia van de cyclus.

Ik begin mijn werk met de organisatie heel eenvoudig: ik ga naar het bedrijf en spreek met de medewerkers. Zoals we zien, zijn er geen geavanceerde technologieën nodig. Alles wat nodig is, is iets om op te schrijven. Ik verzamel verschillende teams in één kamer en analyseer wat ze me zeggen vanuit het perspectief van mijn 7 archetypen. Vervolgens geef ik hen een markeerstift en vraag ik hen alles wat ze tot nu toe hardop hebben gezegd, schriftelijk op het bord uit te leggen. Gewoonlijk is er tijdens dit soort vergaderingen één persoon die alles opschrijft, en in de beste gevallen kan hij of zij 10% van de discussie vastleggen. Met mijn methode lukt het om dit percentage te verhogen tot ongeveer 40%.

(Deze illustratie kan apart via deze link)

bekeken worden. Mijn aanpak is gebaseerd op het werk van William Schneider (William Schneider, The Reengineering Alternative). De basis van de aanpak is het idee dat elke organisatie kan worden opgedeeld in vier vierkanten. Deze schematische weergave is meestal het resultaat van het werken met de honderden andere schema's die ontstaan tijdens de analyse van de organisatie. Stel dat we een organisatie hebben met een hoog niveau van controle, maar met een lage competentie. Dit is een uiterst ongewenste situatie: wanneer iedereen op de lijn loopt, maar niemand weet wat er gedaan moet worden.

Een iets betere optie met een hoog niveau van zowel controle als competentie. Als zo'n bedrijf winstgevend is, heeft het misschien zelfs geen DevOps nodig. Het is het interessantst om samen te werken met een bedrijf dat een hoog niveau van controle, lage competentie en samenwerking heeft, maar toch een hoge cultuurwaarde (cultivation). Dit betekent dat er veel mensen in het bedrijf zijn die het leuk vinden om daar te werken, met een lage personeelsverloop.

(Deze illustratie kan apart via deze link)

Het lijkt me dat methoden met rigide richtlijnen uiteindelijk de waarheid in de weg staan. In het bijzonder zijn er veel regels in value stream mapping over hoe informatie moet worden gestructureerd. In de vroege stadia van het werk, waar ik nu over spreek, zijn deze regels voor niemand nuttig. Als iemand met een marker in de hand de echte situatie in het bedrijf op een bord beschrijft, is dat de beste manier om de situatie te begrijpen. Dergelijke informatie bereikt de directeuren niet. Op dat moment is het dom om iemand af te kappen en te zeggen dat hij een pijl verkeerd heeft getekend. In deze fase is het beter om eenvoudige regels te gebruiken, bijvoorbeeld: een meervoudige abstractie kan worden gemaakt door gewoon gebruik te maken van markeerstiften in verschillende kleuren.

Ik herhaal, geen geavanceerde technologieën. Met een zwarte marker wordt de objectieve realiteit weergegeven, hoe alles werkt. Met een rode marker geven mensen aan wat ze niet goed vinden in de huidige situatie. Het is belangrijk dat zij dat opschrijven, en niet ik. Wanneer ik na de vergadering naar de IT-directeur ga, bied ik geen lijst van 10 dingen die moeten worden verbeterd aan. Ik probeer de verbindingen te vinden tussen wat de mensen uit het bedrijf zeggen en de bestaande beproefde patronen. Tot slot worden met een blauwe marker mogelijke oplossingen voor het probleem voorgesteld.

(Deze illustratie kan apart via deze link)

Een voorbeeld van deze aanpak is hierboven afgebeeld. Begin dit jaar werkte ik met een bank. Werknemers van de beveiligingsafdeling waren ervan overtuigd dat ze niet mochten komen voor vereisten- en ontwerpbeoordelingen (design and requirement reviews).

(Deze illustratie kan apart via deze link)

En toen spraken we met mensen uit andere afdelingen en ontdekten we dat ongeveer 8 jaar geleden de softwareontwikkelaars de beveiligingsmedewerkers buiten de deur hielden omdat zij het werk vertraagden. En dat veranderde in een verbod dat als vanzelfsprekend werd beschouwd. Hoewel er in werkelijkheid helemaal geen verbod was.

Onze bijeenkomst verliep op zeer verwarrende wijze: gedurende ongeveer drie uur konden vijf verschillende teams mij niet uitleggen wat er gebeurde tussen de code en de build. En dat leek een van de eenvoudigste dingen te zijn. De meeste DevOps-consultants gaan er van tevoren van uit dat dit al algemeen bekend is.

Toen begon de persoon die verantwoordelijk was voor IT-regulering (IT governance), die vier uur lang had gezwegen, ineens te spreken toen we zijn onderwerp bereikten, en hij hield ons nog geruime tijd bezig. Aan het einde vroeg ik hem wat hij van de bijeenkomst dacht, en ik zal zijn antwoord nooit vergeten. Hij zei: 'Eerder dacht ik dat er in onze bank maar twee manieren waren om software te leveren, maar nu weet ik dat het er maar liefst vijf zijn, en van drie had ik zelfs niet vermoedings.'

(Deze illustratie kan apart via deze link)

De laatste bijeenkomst in deze bank was met het team dat zich bezighoudt met software voor investeringen. Het bleek dat het beter is om schema's met een marker op papier te schrijven dan op een bord, en zelfs beter dan op een smartboard.

De foto's die u ziet, tonen hoe de conferentiezaal van het hotel eruitzag op de vierde dag van onze bijeenkomst. En deze schema's hebben we gebruikt om patronen, oftewel archetypes, te zoeken.

Dus stel ik vragen aan de medewerkers, zij noteren de antwoorden met markers in drie kleuren (zwart, rood en blauw). Ik analyseer hun antwoorden op archetypes. Laten we nu alle archetypes één voor één bespreken.

1. Make All Work Visible: Maak alle werk zichtbaar

In de meeste bedrijven waarmee ik werk, is er een zeer hoog percentage onbekend werk. Bijvoorbeeld, wanneer de ene werknemer de andere vraagt om iets te doen. In grote organisaties kan tot 60% van het werk ongepland zijn. Tot 40% van het werk is ook niet gedocumenteerd. Als het Boeing was, zou ik nooit meer in hun vliegtuig stappen. Als slechts de helft van het werk wordt gedocumenteerd, weet je niet of dat werk correct wordt uitgevoerd. Alle andere methoden zijn nutteloos — het heeft geen zin om te proberen iets te automatiseren, omdat de bekende 50% misschien juist het meest gestructureerde en duidelijke deel van het werk is, waarvan automatisering weinig resultaten oplevert, terwijl het ergste zich in de onzichtbare helft bevindt. Zonder documentatie is het onmogelijk om allerlei hacks en verborgen werkzaamheden te vinden, om knelpunten te identificeren, die 'Brent'-problemen die ik al noemde. Er is een geweldig boek van Dominica DeGrandis. «Making Work Visible». Het identificeert vijf verschillende "tijdverspillers" (thieves of time):

Te veel werk in uitvoering (WIP)
Onbekende afhankelijkheden
Ongepland werk
Tegenstrijdige prioriteiten
Verwaarloosd werk

Dit is een zeer waardevolle analyse en het boek is geweldig, maar al deze adviezen zijn nutteloos als slechts 50% van de gegevens zichtbaar is. De technieken voorgesteld door Dominica kunnen worden toegepast als een nauwkeurigheid van meer dan 90% is bereikt. Ik spreek over situaties waarin een manager een medewerker een taak van 15 minuten geeft, maar deze drie dagen in beslag neemt; maar de manager weet in feite niet dat deze medewerker ook afhankelijk is van vier of vijf andere mensen.

Het Phoenix Project is een fascinerend verhaal over een project dat drie jaar achterloopt. Een van de personages bedreigt de ontslagbrief, en hij ontmoet een ander personage die wordt gepresenteerd als een soort Socrates. Hij helpt hem te begrijpen wat er precies misging. Het blijkt dat er in het bedrijf een systeembeheerder is genaamd Brent, en al het werk gaat op de een of andere manier via hem. Tijdens een bijeenkomst vraagt een van de ondergeschikten: waarom kost elke halfuur durende taak een week? Als antwoord volgt een sterk vereenvoudigde uitleg van de wachttheorie en de wet van Little, waaruit blijkt dat bij 90% bezetting elke werkuur 9 uur kost. Elke taak moet naar zeven andere mensen worden gestuurd, waardoor dit uur verandert in 63 uur, 7 keer 9. Ik zeg dit omdat je om de wet van Little of enige complexe wachttheorie te gebruiken, op zijn minst gegevens nodig hebt.

Dus als ik het heb over zichtbaarheid, bedoel ik niet dat alles op het scherm moet staan, maar dat je op zijn minst gegevens moet hebben. Wanneer die er zijn, blijkt vaak dat er een zeer groot volume ongeplande werkzaamheden is die om de een of andere reden naar Brent worden gestuurd, terwijl dat helemaal niet nodig is. Brent is een geweldige kerel, hij zal nooit 'nee' zeggen, maar hij vertelt niemand hoe hij zijn werk doet.

Wanneer het werk zichtbaar is, kunnen we netjes gegevens classificeren (dat is precies wat Dominica doet op de foto), we kunnen de abstractie van de vijf tijdlekken toepassen en automatiseren.

2. Consolideer Werkbeheersystemen: Taakbeheer.

De archetypen waar ik het over heb, vormen een soort piramide. Als de eerste correct is uitgevoerd, is de tweede al een soort uitbreiding. Veel van deze werken niet voor startups, je moet ze in gedachten houden voor grote bedrijven, zoals die op de Fortune 5000-lijst staan. Bij het laatste bedrijf waar ik werkte, waren er 10 foutvolgsystemen (ticketingsystemen). Eén team gebruikte Remedy, een ander had zijn eigen systeem geschreven, een derde gebruikte Jira, en iemand anders kwam helemaal niet verder dan e-mail. Hetzelfde probleem doet zich voor als er in een bedrijf 30 verschillende pipelines zijn, maar ik heb geen tijd om al deze gevallen te bespreken.

Ik bespreek met mensen hoe tickets precies worden aangemaakt, wat er daarna mee gebeurt en hoe ze worden omzeild. Het meest interessante is dat mensen op onze bijeenkomsten behoorlijk oprecht spreken. Ik vroeg hoeveel mensen 'minor / no impact' toekennen aan tickets die eigenlijk 'major impact' zouden moeten krijgen. Het bleek dat bijna iedereen dat doet. Ik ben niet bezig met het verraden van mensen en probeer op alle mogelijke manieren te voorkomen dat ik mensen identificeer. Wanneer iemand oprecht iets aan me toevertrouwt, verklap ik die persoon niet. Maar als bijna iedereen het systeem omzeilt, betekent dat dat alle veiligheid in feite een decoratie is. Daarom kun je geen conclusies trekken uit de gegevens van dit systeem.

Om het probleem met tickets op te lossen, moet je één hoofdsyteem kiezen. Als je Jira gebruikt, laat het dan alleen Jira zijn. Als er een alternatief is, laat dat dan de enige optie zijn. Het idee is dat tickets moeten worden beschouwd als een extra fase in het ontwikkelproces. Elke actie moet een ticket hebben dat door het ontwikkelwerkproces gaat. Tickets worden naar het team gestuurd dat ze op het storyboard plaatst en vervolgens verantwoordelijk voor hen is.

Dit geldt voor alle afdelingen, inclusief infrastructuur en operations. In dat geval kan er een zelfs enigszins geloofwaardige weergave van de situatie worden gemaakt. Wanneer dit proces goed is opgezet, blijkt dat je gemakkelijk kunt vaststellen wie verantwoordelijk is voor elke applicatie. Omdat we nu niet 50%, maar 98% van de nieuwe diensten ontvangen. Als dit primaire proces werkt, dan verbetert de nauwkeurigheid in het hele systeem.

Dienstenpipeline

Dit geldt opnieuw alleen voor grote bedrijven. Als je een nieuw bedrijf in een nieuw gebied bent - rol je mouwen op en werk met je Travis CI of CircleCI. Wat betreft de Fortune 5000-bedrijven, het geval dat zich voordeed bij de bank waar ik werkte, is typerend. Er kwamen mensen van Google langs en toonden hen diagrammen met oude IBM-systemen. De mensen van Google vroegen zich af - waar is de broncode voor? Maar er is geen broncode, er is zelfs geen GUI. Dit is de realiteit waarmee grote organisaties moeten omgaan: 40 jaar oude bankgegevens op een oud mainframe. Een van mijn klanten gebruikt Kubernetes-containers met Circuit Breaker-patronen, plus Chaos Monkey, allemaal voor de KeyBank-app. Maar uiteindelijk worden deze containers verbonden met een COBOL-app.

De mensen van Google waren er volledig van overtuigd dat ze alle problemen van mijn klant zouden oplossen, en toen begonnen ze vragen te stellen: wat is een IBM datapipe? Het antwoord is: dat is een connector. Waar wordt het mee verbonden? Met het Sperry-systeem. En wat is dat? En zo verder. Op het eerste gezicht lijkt het: wat heeft DevOps hiermee te maken? Maar in werkelijkheid is het mogelijk. Er zijn leveringssystemen die het mogelijk maken om werkprocessen over te dragen aan teams die zich bezighouden met levering.

3. Theory of Constraints: Theorie van Beperkingen

Laten we overgaan naar het derde archetype: institutionele / "tribale" kennis. Over het algemeen zijn er binnen elke organisatie een paar mensen die alles weten en die de leiding hebben. Dit zijn de mensen die het langst in de organisatie werken en die alle sluiproutes kennen.

Wanneer dit op de diagram wordt weergegeven, omcirkel ik deze mensen speciaal met een marker: bijvoorbeeld, het blijkt dat een zekere Lou bij alle vergaderingen aanwezig is. En voor mij is het duidelijk: dit is de lokale Brent. Wanneer de IT-directeur moet kiezen tussen mij in een T-shirt en sneakers of een net geklede jongen van IBM, wordt er voor mij gekozen omdat ik de directeur kan vertellen over zaken die de andere jongen niet kan vertellen en waar de directeur misschien niet prettig over hoort. Ik zeg hen dat er in hun bedrijf een knelpunt is, iemand genaamd Fred en iemand genaamd Lou. Dit knelpunt moet worden opgelost, hun kennis moet op de een of andere manier van hen verkregen worden.

Om dit soort problemen op te lossen, kan ik bijvoorbeeld voorstellen om Slack te gebruiken. Een slimme directeur zou vragen: waarom? Gewoonlijk antwoorden DevOps-consultants in zulke gevallen: omdat iedereen dat doet. Als de directeur echt slim is, zou hij zeggen: en wat dan nog? En dan eindigt het gesprek. Mijn antwoord hierop is: omdat er vier knelpunten in het bedrijf zijn, Fred, Lou, Suzy en Jane. Om hun kennis te institutionaliseer, moet Slack eerst worden geïntroduceerd. Al jullie wiki's zijn volkomen onzinnig, omdat niemand weet dat ze bestaan. Als het engineeringteam zich bezighoudt met externe en interne ontwikkeling, moeten alle teamleden weten dat ze met het externe ontwikkelingsteam of het infrastructuurteam kunnen overleggen. Juist dan zal Lou of Fred waarschijnlijk tijd hebben om in de wiki te kijken. En dan kan iemand in Slack vragen waarom stap 5 niet werkt. En dan zal Lou of Fred de instructies in de wiki corrigeren. Als dit proces goed wordt opgezet, zal veel van zelf op zijn plek vallen.

Hierin ligt mijn belangrijkste punt: om geavanceerde technologieën aan te bevelen, moet je eerst de basis op orde brengen, en dat kan met de net beschreven laagtechnologische oplossingen. Als je met geavanceerde technologieën begint en niet uitlegt waarom ze nodig zijn, eindigt dat vaak niet goed. Een van onze klanten gebruikt Azure ML, een zeer goedkope en eenvoudige oplossing. Ongeveer 30% van de vragen werd al beantwoord door de zelflerende machine. Dit is ontwikkeld door operators die zich niet bezighielden met data science, statistiek of wiskunde. Dat is opmerkelijk. De kosten van zo'n oplossing zijn minimaal.

4. Samenwerkingshacks: Hacks voor samenwerking

Het vierde archetype houdt in dat we de isolatie moeten bestrijden. De meeste mensen weten dit al: isolatie genereert vijandigheid. Als elke afdeling op zijn eigen verdieping zit en mensen elkaar niet tegenkomen, behalve in de lift, dan ontstaat er gemakkelijk vijandigheid tussen hen. Indien mensen daarentegen in dezelfde ruimte zijn, verdwijnt die vijandigheid direct. Wanneer iemand een algemeen beschuldiging uitspreekt, zoals dat een bepaalde interface nooit werkt — dan is het eenvoudig om zo'n beschuldiging te ontleden. Voor de programmeurs die de interface hebben geschreven, is het voldoende om gerichte vragen te stellen, en al snel blijkt dat de gebruiker bijvoorbeeld gewoon het hulpmiddel verkeerd heeft gebruikt.

Er zijn veel manieren om isolatie te overwinnen. Een keer werd ik gevraagd om een bank in Australië te adviseren, maar ik weigerde omdat ik twee kinderen en een vrouw heb. Het enige waarmee ik hen kon helpen, was het aanbevelen van graphical storytelling. Dit is iets dat bewezen effectief is. Een andere interessante manier is het organiseren van lean coffee bijeenkomsten. In een grote organisatie is dit een uitstekende optie voor kennisdeling. Daarnaast kunnen interne devopsdays, hackathons, enzovoort gehouden worden.

5. Coaching Kata

Zoals ik in het begin al waarschuwde, zal ik hier vandaag niet over vertellen. Als je geïnteresseerd bent, kun je kijken naar een aantal van mijn presentaties.

Er is ook een goede presentatie over dit onderwerp van Mike Rother:

6. Marktorientatie: marktgericht organisatie

Hier zijn verschillende problemen. Bijvoorbeeld, de 'I'-mensen, 'T'-mensen en 'E'-mensen. 'I'-mensen zijn degenen die zich alleen met één ding bezighouden. Gewoonlijk bestaan zij in organisaties met geïsoleerde afdelingen. 'T' betekent dat iemand goed is in één specifiek ding, maar ook enige andere vaardigheden heeft. 'E' of zelfs 'kam' is wanneer iemand veel vaardigheden heeft.

Hier is de wet van Conway van toepassing (Conway’s law), die in de eenvoudigste vorm kan worden gesteld als: als drie teams aan de compiler werken, zal de uiteindelijke compiler uit drie delen bestaan. Daarom, als er binnen de organisatie een hoog niveau van isolatie is, zullen zelfs Kubernetes, Circuit breaker, API extensibility en andere trendy zaken binnen die organisatie op dezelfde manier zijn georganiseerd als de organisatie zelf. Strikt volgens Conway en tot verdriet van jullie, jonge geeks.

Deze probleemoplossing is al vaak beschreven. Er zijn bijvoorbeeld organisatorische archetypes, beschreven door Fernando Fernandez. Die problematische architectuur waar ik het net over had, met isolatie — dat is functioneel-georiënteerde architectuur. Het tweede type — de slechtste, de matrixarchitectuur, daar zit rommel in van de twee andere. Het derde — dat is wat we bij de meeste startups zien, en grote bedrijven proberen ook aan dit type te voldoen. Dit is een marktgeoriënteerde organisatie. Hier gaat het om optimalisatie om de snelste respons op klantverzoeken te bereiken. Dit wordt soms een platte organisatie genoemd.

Deze structuur wordt door velen op verschillende manieren beschreven, ik hou van de formulering build/run teams, bij Amazon noemt men dat two pizza teams. In deze structuur worden alle mensen van het type "I" gegroepeerd rond één dienst, en geleidelijk worden ze dichter bij het type "T", en als het juiste management aanwezig is, kunnen ze zelfs "E" worden. Het eerste tegenargument hier is dat er in een dergelijke structuur overbodige elementen zijn. Waarom is er een tester in elke afdeling nodig, als er een speciale afdeling voor testers kan zijn? Waarop ik antwoord: overbodige kosten zijn in dit geval de prijs voor de toekomst, zodat de hele organisatie type "E" kan worden. In een dergelijke structuur leert de tester geleidelijk over netwerken, architectuur, ontwerp, enzovoort. Uiteindelijk is elke deelnemer in de organisatie volledig op de hoogte van alles wat er in de organisatie gebeurt. Als je wilt weten hoe dit schema in de industrie werkt, lees dan Mike Rother, Toyota Kata.

7. Shift-left auditors: audit in de vroege fasen van de cyclus. Naleving van de veiligheidsregels zichtbaar.

Dit is wanneer uw acties niet, zeg maar, de geurtest doorstaan. Mensen die voor u werken zijn niet dom. Als zij, zoals in het bovenstaande voorbeeld, overal een minor/no impact aangeven, dit drie jaar aanhoudt en niemand het opmerkt, dan weet iedereen dat het systeem niet werkt. Of een ander voorbeeld — de wijzigingsadviescommissie, waar elke, laten we zeggen, woensdag rapporten moeten worden ingediend. Daar werkt een groep mensen (overigens niet al te goed betaald) die theoretisch moeten weten hoe het systeem als geheel werkt. En de afgelopen vijf jaar heeft u waarschijnlijk gemerkt dat onze systemen ongelooflijk complex zijn. En vijf of zes mensen moeten een beslissing nemen over een wijziging die zij niet hebben aangebracht en waarover zij niets weten.

Natuurlijk werkt deze aanpak niet. Ik moet me van zulke dingen ontdoen, omdat deze mensen het systeem niet verdedigen. De beslissing moet door het team zelf worden genomen, omdat het team verantwoordelijk moet zijn voor die beslissing. Anders ontstaat er een paradoxale situatie waarin een manager, die nooit in zijn leven code heeft geschreven, de programmeur vertelt hoeveel tijd het zou moeten kosten om de code te schrijven. In een bedrijf waar ik werkte, waren er zeven verschillende adviescommissies die elke wijziging behandelden, inclusief de architectuurcommissie, productcommissies, enzovoorts. Er was zelfs een verplichte wachttijd, hoewel een medewerker me vertelde dat in tien jaar tijd niemand ooit in deze verplichte periode wijziging heeft afgewezen die door deze persoon was aangebracht.

U heeft auditors nodig om hen bij u te betrekken, in plaats van hen te negeren. Vertel hen dat u immutabele binaire containers schrijft die, zodra ze alle tests doorstaan, voor altijd onveranderlijk blijven. Leg uit wat pipeline as code betekent. Toon hen het volgende schema: een immutabele binary alleen-lezen in een container die alle kwetsbaarheidstests doorstaat; en verder komt niemand erbij — zelfs het systeem dat de pipeline creëert, wordt dynamisch gegenereerd en niet aangeraakt. Ik heb klanten zoals Capital One die met Vault iets creëren dat lijkt op blockchain. U hoeft de auditor geen 'recepten' van Chef te tonen; het is voldoende om de blockchain te laten zien, waaruit duidelijk blijkt wat er met het Jira-ticket in productie is gebeurd en wie ervoor verantwoordelijk is.

Volgens report, opgericht in 2018, had Sonatype in 2017 87 miljard verzoeken om OSS-downloads.

De verliezen veroorzaakt door kwetsbaarheden zijn extreem hoog. Bovendien bevatten de cijfers die u hierboven ziet geen alternatieve kosten. Een korte uitleg van wat DevSecOps is. Ik wil meteen zeggen dat ik niet geïnteresseerd ben in discussies over hoe goed deze naam is gekozen. Het gaat erom dat, aangezien DevOps erg succesvol is geweest, we de veiligheid aan deze pipeline moeten proberen toe te voegen.

Een voorbeeld van een dergelijke volgorde:

Dit is geen aanbeveling van bepaalde producten, hoewel ik ze allemaal leuk vind. Ik gebruik ze als voorbeeld om aan te tonen dat DevOps, oorspronkelijk gebaseerd op de organisatieparadigma in de industrie, elk stadium van het productontwikkelingsproces kan automatizeren.

En er is geen reden waarom we dezelfde aanpak niet op veiligheid zouden kunnen toepassen.

Conclusie

Als conclusie geef ik enkele tips voor DevSecOps. Betrek auditors bij het proces van het creëren van uw systemen en besteed tijd aan hun opleiding. Het is belangrijk om samen te werken met auditors. Daarnaast moet er een genadeloze strijd worden gevoerd tegen valse positieven. Zelfs met de duurste scanningtools voor kwetsbaarheden kunt u schadelijke gewoonten bij uw ontwikkelaars creëren als u niet weet wat de signaal-ruisverhouding is. Ontwikkelaars zullen overspoeld raken met gebeurtenissen en ze zullen deze gewoon gaan negeren. Als u iets hebt gehoord over het verhaal van Equifax, dan ging daar precies dat fout, het signaal van de hoogste gevarenniveau werd genegeerd. Bovendien moeten kwetsbaarheden worden uitgelegd op een manier die duidelijk maakt hoe ze het bedrijfsleven beïnvloeden. U kunt bijvoorbeeld zeggen dat het dezelfde kwetsbaarheid is als in het verhaal van Equifax. Kwetsbaarheden met betrekking tot beveiliging moeten net zo worden behandeld als andere softwareproblemen, wat betekent dat ze in het algemene DevOps-proces moeten worden geïntegreerd. Werk eraan via Jira, Kanban, enz. Ontwikkelaars moeten niet denken dat anderen deze taak op zich nemen — integendeel, iedereen moet dit doen. Tot slot is het belangrijk om inspanningen te steken in het opleiden van mensen.