De vraag “hoe devops te implementeren” bestaat al jaren, maar er zijn niet veel goede materialen. Soms word je het slachtoffer van advertenties van niet zo slimme consultants die hoe dan ook hun tijd moeten verkopen. Soms zijn dit vage, uiterst algemene woorden over hoe de schepen van megabedrijven de uitgestrektheid van het universum ploegen. De vraag rijst: wat maakt dit ons uit? Beste auteur, kunt u uw ideeën duidelijk formuleren in een lijst?
Dit alles komt voort uit het feit dat er niet veel echte praktijk en begrip van de uitkomst van transformaties van de bedrijfscultuur is ontstaan. Cultuurveranderingen zijn zaken van de langere termijn, waarvan de resultaten niet binnen een week of een maand zichtbaar zullen zijn. We hebben iemand nodig die oud genoeg is om te zien hoe bedrijven door de jaren heen zijn opgebouwd en gefaald.
Johannes Willis - een van de grondleggers van DevOps. John heeft tientallen jaren ervaring in het werken met een groot aantal bedrijven. Onlangs begon John specifieke patronen op te merken die optreden bij het werken met elk van deze patronen. Met behulp van deze archetypen begeleidt John bedrijven op het ware pad van DevOps-transformatie. Lees meer over deze archetypen in de vertaling van zijn rapport van de DevOops 2018-conferentie.
Over de spreker:
Meer dan 35 jaar in IT-beheer, deelgenomen aan de oprichting van de voorganger van OpenCloud bij Canonical, deelgenomen aan 10 startups, waarvan er twee werden verkocht aan Dell en Docker. Momenteel is hij vice-president van DevOps en Digital Practices bij SJ Technologies.
Het volgende is het verhaal vanuit het perspectief van John.
Mijn naam is John Willis en de gemakkelijkste plaats om mij te vinden is op Twitter, . Ik heb dezelfde alias op Gmail en GitHub. A Voor hen kunt u video-opnames vinden van mijn reportages en presentaties.
Ik heb veel meetings met CIO's van diverse grote bedrijven. Ze klagen heel vaak dat ze niet begrijpen wat DevOps is, en iedereen die het hen probeert uit te leggen, heeft het over iets anders. Een andere veelgehoorde klacht is dat DevOps niet werkt, al lijkt het erop dat de directeuren alles doen zoals hen wordt uitgelegd. We hebben het over grote bedrijven die meer dan honderd jaar oud zijn. Na met hen te hebben gesproken, kwam ik tot de conclusie dat voor veel problemen niet de hoogwaardige technologie het meest geschikt is, maar eerder relatief low-tech oplossingen. Wekenlang sprak ik gewoon met mensen van verschillende afdelingen. Wat je ziet op de allereerste foto in de post is mijn laatste project, zo zag de kamer eruit na drie dagen werken.
Wat is DevOps?
Als je het aan tien verschillende mensen vraagt, zullen ze tien verschillende antwoorden geven. Maar het interessante is: alle tien deze antwoorden zullen correct zijn. Er is hier geen fout antwoord. Ik was behoorlijk diep in DevOps, ongeveer 10 jaar lang, en was de eerste Amerikaan op de eerste DevOpsDay. Ik zal niet zeggen dat ik slimmer ben dan iedereen die betrokken is bij DevOps, maar er is bijna niemand die er zoveel moeite aan heeft besteed. Ik geloof dat DevOps ontstaat wanneer menselijk kapitaal en technologie samenkomen. Vaak vergeten we de menselijke maat, ook al praten we veel over allerlei culturen.
Nu hebben we veel gegevens, vijf jaar academisch onderzoek en het testen van theorieën op industriële schaal. Wat deze onderzoeken ons vertellen is dat als je bepaalde gedragspatronen in een organisatiecultuur combineert, je een snelheidswinst van 2000x kunt behalen. Deze versnelling gaat gepaard met een gelijke verbetering van de stabiliteit. Dit is een kwantitatieve meting van de voordelen die DevOps voor elk bedrijf kan opleveren. Een paar jaar geleden sprak ik over DevOps met de CEO van een bedrijf uit de Fortune 5000. Toen ik me aan het voorbereiden was op de presentatie, was ik erg zenuwachtig omdat ik mijn jarenlange ervaring in 5 minuten moest samenvatten.
Uiteindelijk heb ik het volgende gegeven DevOps-definitie: Het is een reeks praktijken en patronen die de transformatie van menselijk kapitaal in krachtig organisatorisch kapitaal mogelijk maken. Een voorbeeld is de manier waarop Toyota de afgelopen vijftig tot zestig jaar heeft geopereerd.
(Hierna worden dergelijke diagrammen niet als referentiemateriaal verstrekt, maar als illustraties. De inhoud ervan zal per nieuw bedrijf verschillen. De afbeelding kan echter afzonderlijk en vergroot worden bekeken
Een van de meest succesvolle dergelijke praktijken is value stream mapping. Hierover zijn verschillende goede boeken geschreven, waarvan de meest succesvolle van Karen Martin. Maar het afgelopen jaar ben ik tot de conclusie gekomen dat zelfs deze aanpak te hightech is. Het heeft zeker veel voordelen en ik heb er veel gebruik van gemaakt. Maar als de CEO je vraagt waarom zijn bedrijf niet kan overstappen op nieuwe rails, is het nog te vroeg om te praten over het in kaart brengen van de waardestromen. Er zijn veel fundamentelere vragen die eerst moeten worden beantwoord.
Ik denk dat de fout die veel van mijn collega's maken is dat ze het bedrijf eenvoudigweg een vijfpuntengids geven en dan zes maanden later terugkomen om te zien wat er is gebeurd. Zelfs een goed schema als het in kaart brengen van waardestromen heeft, laten we zeggen, blinde vlekken. Na honderden interviews met directeuren van verschillende bedrijven heb ik een bepaald patroon ontwikkeld waarmee we het probleem in zijn componenten kunnen opsplitsen, en nu zullen we elk van deze componenten achtereenvolgens bespreken. Voordat ik technologische oplossingen toepas, gebruik ik dit patroon, en als gevolg daarvan zijn al mijn muren bedekt met diagrammen. Onlangs werkte ik met een beleggingsfonds en eindigde met 100-150 van dergelijke regelingen.
Slechte cultuur vraagt om goede benaderingen voor het ontbijt
Het hoofdidee is dit: geen enkele hoeveelheid Lean, Agile, SAFE en DevOps zal helpen als de cultuur van de organisatie zelf slecht is. Het is alsof je naar de diepte duikt zonder duikuitrusting of opereert zonder röntgenfoto. Met andere woorden, om Drucker en Deming te parafraseren: een slechte organisatiecultuur zal elk goed systeem opslokken zonder erin te stikken.
Om dit hoofdprobleem op te lossen, moet u de volgende stappen ondernemen:
- Maak al het werk zichtbaar: je moet al het werk zichtbaar maken. Niet in de zin dat het noodzakelijkerwijs op een scherm moet worden weergegeven, maar in de zin dat het waarneembaar moet zijn.
- Geconsolideerde werkbeheersystemen: managementsystemen moeten worden geconsolideerd. In het probleem van “tribale” kennis en institutionele kennis is het knelpunt in negen van de tien gevallen de mens. In het boek het probleem lag bij één persoon, Brent, die ervoor zorgde dat het project drie jaar achterliep op schema. En overal kom ik deze “Brents” tegen. Om deze knelpunten op te lossen, gebruik ik de volgende twee items op onze lijst.
- Theorie van beperkingen Methodologie: theorie van beperkingen.
- Samenwerkingshacks: samenwerkingshacks.
- Toyota Kata (): Ik zal niet veel praten over de Toyota Kata. Indien interesse, op mijn github over bijna elk van deze onderwerpen.
- Marktgerichte organisatie: marktgerichte organisatie.
- Shift-left-auditors: audit in een vroeg stadium van de cyclus.
Ik ga heel eenvoudig bij een organisatie aan de slag: ik ga naar het bedrijf en praat met de medewerkers. Zoals u kunt zien, geen geavanceerde technologie. Het enige wat je nodig hebt is iets om op te schrijven. Ik verzamel verschillende teams in één kamer en analyseer wat ze mij vertellen vanuit het perspectief van mijn 7 archetypen. En dan geef ik ze zelf een stift en vraag ze om alles wat ze tot nu toe hebben gezegd op het bord te schrijven. Meestal is er bij dit soort bijeenkomsten één persoon die alles opschrijft, en op zijn best kan hij 10% van de discussie opschrijven. Met mijn methode kan dit cijfer worden verhoogd tot ongeveer 40%.
(Deze illustratie kan afzonderlijk worden bekeken )
Mijn aanpak is gebaseerd op het werk van William Schneider. ). De aanpak is gebaseerd op het idee dat elke organisatie in vier vierkanten kan worden verdeeld. Dit schema is voor mij meestal het resultaat van het werken met die honderden andere schema’s die ontstaan bij het analyseren van een organisatie. Stel dat we een organisatie hebben met een hoog niveau van controle, maar met een lage competentie. Dit is een uiterst ongewenste optie: wanneer iedereen zich aan de lijn houdt, maar niemand weet wat te doen.
Een iets betere optie is er een met een hoog niveau van zowel controle als competentie. Als zo’n bedrijf winstgevend is, heeft het misschien geen DevOps nodig. Het is het meest interessant om te werken met een bedrijf dat een hoog niveau van controle, lage competentie en samenwerking heeft, maar tegelijkertijd een hoog cultuurniveau (cultivatie). Dit betekent dat het bedrijf veel mensen heeft die er graag werken en dat het personeelsverloop laag is.
(Deze illustratie kan afzonderlijk worden bekeken )
Het lijkt mij dat methoden met rigide richtlijnen uiteindelijk het bereiken van de waarheid in de weg staan. Vooral bij het in kaart brengen van waardestromen zijn er veel regels over hoe informatie moet worden gestructureerd. In de vroege stadia van het werk, waar ik het nu over heb, heeft niemand deze regels nodig. Als een persoon met een marker in zijn handen de werkelijke situatie in het bedrijf op het bord beschrijft, is dit de beste manier om de stand van zaken te begrijpen. Dergelijke informatie bereikt bestuurders niet. Op dit moment is het dom om de persoon te onderbreken en te zeggen dat hij een soort pijl verkeerd heeft getekend. In dit stadium is het beter om eenvoudige regels te gebruiken, bijvoorbeeld: abstractie op meerdere niveaus kan eenvoudig worden gecreëerd door eenvoudigweg veelkleurige markeringen te gebruiken.
Ik herhaal: geen geavanceerde technologie. De zwarte marker geeft de objectieve realiteit weer van hoe alles werkt. Met een rode markering markeren mensen wat ze niet leuk vinden aan de huidige stand van zaken. Het is belangrijk dat zij dit schrijven, niet ik. Als ik na een vergadering naar de CIO ga, geef ik geen lijst met tien dingen die moeten worden opgelost. Ik streef ernaar om verbindingen te vinden tussen wat mensen in het bedrijf zeggen en bestaande bewezen patronen. Ten slotte suggereert een blauwe markering mogelijke oplossingen voor het probleem.
(Deze illustratie kan afzonderlijk worden bekeken )
Een voorbeeld van deze aanpak is nu hierboven afgebeeld. Begin dit jaar werkte ik samen met één bank. De beveiligingsmensen daar waren ervan overtuigd dat ze niet naar ontwerp- en eisenbeoordelingen moesten komen.
(Deze illustratie kan afzonderlijk worden bekeken )
En toen spraken we met mensen van andere afdelingen en het bleek dat softwareontwikkelaars ongeveer acht jaar geleden beveiligingspersoneel ontsloegen omdat ze het werk vertraagden. En toen werd het een verbod, dat als vanzelfsprekend werd beschouwd. Hoewel er in werkelijkheid geen verbod was.
Onze bijeenkomst verliep uiterst verwarrend: ongeveer drie uur lang konden vijf verschillende teams mij niet uitleggen wat er tussen de code en de vergadering gebeurde. En dit lijkt het eenvoudigste. De meeste DevOps-consultants gaan er vooraf van uit dat iedereen dit al weet.
Toen kwam de persoon die verantwoordelijk was voor het IT-beheer, die vier uur lang had stilgestaan, plotseling tot leven toen we bij zijn onderwerp kwamen, en hij hield ons heel lang bezig. Aan het eind vroeg ik hem wat hij van de bijeenkomst vond, en zijn antwoord zal ik nooit vergeten. Hij zei: “Vroeger dacht ik dat onze bank maar twee manieren had om software te leveren, maar nu weet ik dat het er vijf zijn, en van drie wist ik niet eens.”
(Deze illustratie kan afzonderlijk worden bekeken )
De laatste bijeenkomst bij deze bank was met het beleggingssoftwareteam. Met haar bleek dat het schrijven van diagrammen met een stift op een vel papier beter is dan op een bord, en zelfs beter dan op een smartboard.
De foto's die u ziet zijn hoe de vergaderruimte van het hotel eruit zag op de vierde dag van onze bijeenkomst. En we gebruikten deze schema's om naar patronen te zoeken, dat wil zeggen archetypen.
Dus ik stel de arbeiders vragen, ze schrijven de antwoorden op met stiften in drie kleuren (zwart, rood en blauw). Ik analyseer hun antwoorden op archetypen. Laten we nu alle archetypen in volgorde bespreken.
1. Maak al het werk zichtbaar: maak werk zichtbaar
De meeste bedrijven waarmee ik werk, hebben een zeer hoog percentage onbekend werk. Dit is bijvoorbeeld wanneer de ene medewerker naar de andere komt en eenvoudigweg vraagt om iets te doen. In grote organisaties kan er 60% ongepland werk zijn. En tot 40% van het werk is op geen enkele manier gedocumenteerd. Als het Boeing was, zou ik nooit meer van mijn leven aan boord van hun vliegtuig gaan. Als slechts de helft van het werk wordt gedocumenteerd, is het niet bekend of dit werk correct wordt uitgevoerd of niet. Alle andere methoden blijken nutteloos te zijn - het heeft geen zin om iets te automatiseren, omdat de bekende 50% misschien wel het meest coherente en duidelijke deel van het werk is, waarvan de automatisering geen geweldige resultaten zal opleveren, en al het ergste dingen bevinden zich in de onzichtbare helft. Bij gebrek aan documentatie is het onmogelijk om allerlei hacks en verborgen werk te vinden, en niet om knelpunten te vinden, diezelfde “Brents” waar ik het al over had. Er is een prachtig boek van Dominica DeGrandis . Ze onthult vijf verschillende "tijdlekken" (dieven van de tijd):
- 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 dit advies is nutteloos als slechts 50% van de gegevens zichtbaar is. De door Dominica voorgestelde methoden kunnen worden gebruikt als een nauwkeurigheid van meer dan 90% wordt bereikt. Ik heb het over situaties waarin een baas een ondergeschikte een taak van vijftien minuten geeft, maar het kost hem drie dagen; maar de baas weet eigenlijk niet dat deze ondergeschikte afhankelijk is van vier of vijf andere mensen.
The Phoenix Project is een prachtig verhaal over een project dat drie jaar te laat kwam. Eén van de personages dreigt hierdoor te worden ontslagen en hij ontmoet een ander personage dat wordt gepresenteerd als een soort Socrates. Hij helpt uitzoeken wat er precies is misgegaan. Het blijkt dat het bedrijf één systeembeheerder heeft, wiens naam Brent is, en al het werk gaat op de een of andere manier via hem. Op een van de bijeenkomsten wordt aan een van de ondergeschikten gevraagd: waarom duurt elke taak van een half uur een week? Het antwoord is een zeer vereenvoudigde presentatie van de wachtrijtheorie en de wet van Little, en in deze presentatie blijkt dat bij een bezetting van 90% elk uur werken 9 uur duurt. Elke taak moet naar zeven andere mensen worden gestuurd, zodat dat uur 63 uur wordt, 7 keer 9. Wat ik wil zeggen is dat om de wet van Little of welke complexe wachtrijtheorie dan ook te gebruiken, je op zijn minst over gegevens moet beschikken.
Als ik het dus over zichtbaarheid heb, bedoel ik niet dat alles op het scherm staat, maar dat je in ieder geval data hebt. Als ze dat doen, blijkt vaak dat er een zeer grote hoeveelheid ongepland werk op de een of andere manier naar Brent wordt gestuurd terwijl dat niet nodig is. En Brent is een geweldige kerel, hij zal nooit nee zeggen, maar hij vertelt aan niemand hoe hij zijn werk doet.
Als het werk zichtbaar is, kunnen de gegevens netjes worden geclassificeerd (dat is wat Dominique op de foto doet), kan de abstractie van de vijf tijdlekken worden toegepast en kan automatisering worden toegepast.
2. Consolideer werkbeheersystemen: taakbeheer
De archetypen waar ik het over heb zijn een soort piramide. Als de eerste correct is uitgevoerd, is de tweede al een soort add-on. Veel hiervan werken niet voor startups; ze moeten in gedachten worden gehouden voor grotere bedrijven zoals de Fortune 5000. Het laatste bedrijf waarvoor ik werkte, had 10 ticketingsystemen. Het ene team had Remedy, het andere schreef een soort eigen systeem, een derde gebruikte Jira en sommigen deden het met e-mail. Hetzelfde probleem doet zich voor als het bedrijf dertig verschillende pijpleidingen heeft, maar ik heb geen tijd om al deze gevallen te bespreken.
Ik bespreek met mensen hoe tickets precies worden aangemaakt, wat er vervolgens mee gebeurt en hoe ze worden omzeild. Het meest interessante is dat mensen op onze bijeenkomsten heel oprecht spreken. Ik vroeg hoeveel mensen ‘kleine/geen impact’ op kaartjes zetten die eigenlijk ‘grote impact’ zouden moeten krijgen. Het bleek dat bijna iedereen dit doet. Ik houd mij niet bezig met aanklacht en probeer op alle mogelijke manieren mensen niet te identificeren. Als ze mij oprecht iets bekennen, geef ik de persoon niet weg. Maar als bijna iedereen het systeem omzeilt, betekent dit dat alle beveiliging in wezen window dressing is. Er kunnen daarom geen conclusies worden getrokken uit de gegevens van dit systeem.
Om het ticketprobleem op te lossen, moet u één hoofdsysteem kiezen. Als je Jira gebruikt, behoud het dan Jira. Als er een alternatief is, laat dit dan het enige zijn. Het komt erop neer dat tickets moeten worden gezien als een nieuwe stap in het ontwikkelingsproces. Elke actie moet een ticket hebben, dat door de ontwikkelingsworkflow moet stromen. Tickets worden naar het team gestuurd, dat ze op het storyboard plaatst en er vervolgens de verantwoordelijkheid voor neemt.
Dit geldt voor alle afdelingen, inclusief infrastructuur en bedrijfsvoering. In dit geval is het mogelijk om op zijn minst een plausibel idee van de stand van zaken te vormen. Zodra dit proces is opgezet, wordt het plotseling gemakkelijk om te identificeren wie verantwoordelijk is voor elke toepassing. Omdat we nu niet 50%, maar 98% van de nieuwe diensten ontvangen. Als dit kernproces werkt, verbetert de nauwkeurigheid in het hele systeem.
Dienstenpijplijn
Dit geldt wederom alleen voor grote bedrijven. Als u een nieuw bedrijf bent in een nieuw vakgebied, stroop dan uw mouwen op en werk met uw Travis CI of CircleCI. Als het om Fortune 5000-bedrijven gaat: een voorbeeld dat gebeurde bij de bank waar ik werkte. Google kwam naar hen toe en ze kregen diagrammen te zien van oude IBM-systemen. De jongens van Google vroegen in verwarring: waar is de broncode hiervoor? Maar er is geen broncode, zelfs geen GUI. Dit is de realiteit waar grote organisaties mee te maken hebben: 40 jaar oude bankgegevens op een eeuwenoud mainframe. Een van mijn klanten gebruikt Kubernetes-containers met Circuit Breaker-patronen, plus Chaos Monkey, allemaal voor de KeyBank-applicatie. Maar deze containers maken uiteindelijk verbinding met een COBOL-applicatie.
De jongens van Google hadden er alle vertrouwen in dat ze alle problemen van mijn klant zouden oplossen, en toen begonnen ze vragen te stellen: wat is IBM datapipe? Ze krijgen te horen: dit is een connector. Waarmee wordt verbinding gemaakt? Naar het Sperry-systeem. En wat is dat? Enzovoort. Op het eerste gezicht lijkt het: wat voor soort DevOps kan er zijn? Maar in feite is het mogelijk. Er zijn bezorgsystemen waarmee je de workflow aan de bezorgteams kunt overdragen.
3. Theorie van beperkingen: Theorie van beperkingen
Laten we verder gaan met het derde archetype: institutionele/"tribale" kennis. In de regel zijn er in elke organisatie meerdere mensen die alles weten en alles beheren. Dit zijn degenen die het langst in de organisatie zitten en alle oplossingen kennen.
Als dit in het schema verschijnt, omcirkel ik zulke mensen specifiek met een stift: het blijkt bijvoorbeeld dat een bepaalde Lou bij alle bijeenkomsten aanwezig is. En het is mij duidelijk: dit is lokale Brent. Als de CIO kiest tussen mij in een T-shirt en sneakers en de man van IBM in een pak, word ik gekozen omdat ik de directeur dingen kan vertellen die de andere man niet zal vertellen en die de directeur misschien niet graag wil horen . Ik vertel ze dat het knelpunt in hun bedrijf iemand is die Fred heet en iemand die Lou heet. Dit knelpunt moet worden opgelost, hun kennis moet op de een of andere manier van hen worden verkregen.
Om dit soort problemen op te lossen, kan ik bijvoorbeeld voorstellen om Slack te gebruiken. Een slimme regisseur zal vragen: waarom? Meestal antwoorden DevOps-consultants in dergelijke gevallen: omdat iedereen het doet. Als de regisseur echt slim is, zal hij zeggen: so what. En hier eindigt de dialoog. En mijn antwoord hierop is: omdat er vier knelpunten zijn in het bedrijf, Fred, Lou, Susie en Jane. Om hun kennis te industrialiseren, moet je eerst Slack introduceren. Al jouw wiki's zijn complete onzin omdat niemand van hun bestaan af weet. Als het engineeringteam betrokken is bij front-end- en back-end-ontwikkeling en iedereen moet weten dat ze met vragen contact kunnen opnemen met het front-end-ontwikkelteam of het infrastructuurteam. Dan hebben Lou of Fred waarschijnlijk tijd om zich bij de wiki aan te sluiten. En dan zou iemand in Slack kunnen vragen waarom bijvoorbeeld stap 5 niet werkt, en dan zullen Lou of Fred de instructies op de wiki corrigeren. Als je dit proces in gang zet, vallen veel dingen vanzelf op hun plaats.
Dit is mijn belangrijkste punt: om hoogwaardige technologieën aan te bevelen, moet je eerst de basis ervoor op orde brengen, en dit kan worden gedaan met de zojuist beschreven low-tech oplossingen. Als je begint met geavanceerde technologieën en niet uitlegt waarom ze nodig zijn, dan loopt dit in de regel niet goed af. Eén van onze klanten maakt gebruik van Azure ML, een zeer goedkope en eenvoudige oplossing. Ongeveer 30% van hun vragen werd door de zelflerende machine zelf beantwoord. En dit ding is geschreven door operators die niet betrokken waren bij datawetenschap, statistiek of wiskunde. Dit is aanzienlijk. De kosten van een dergelijke oplossing zijn minimaal.
4. Samenwerkingshacks: Samenwerkingshacks
Het vierde archetype is de noodzaak om isolement te bestrijden. De meeste mensen weten dit al: isolatie leidt tot vijandigheid. Als elke afdeling zich op zijn eigen verdieping bevindt en mensen elkaar op geen enkele manier kruisen, behalve in de lift, ontstaat er heel gemakkelijk vijandigheid tussen hen. Maar als mensen daarentegen met elkaar in dezelfde kamer zijn, vertrekt ze onmiddellijk. Wanneer iemand een algemene beschuldiging uit, bijvoorbeeld dat deze en die interface nooit werkt, is er niets gemakkelijker om zo'n beschuldiging te deconstrueren. De programmeurs die de interface hebben geschreven, hoeven alleen maar specifieke vragen te stellen, en al snel zal duidelijk worden dat de gebruiker de tool bijvoorbeeld eenvoudigweg verkeerd heeft gebruikt.
Er zijn veel manieren om isolement te doorbreken. Ik werd ooit gevraagd om advies te geven voor een bank in Australië, maar ik weigerde dat te doen omdat ik twee kinderen en een vrouw heb. Het enige dat ik kon doen om hen te helpen, was het aanbevelen van grafische verhalen. Dit is iets waarvan bewezen is dat het werkt. Een andere interessante manier zijn lean coffee-bijeenkomsten. In een grote organisatie is dit een uitstekende mogelijkheid om kennis te verspreiden. Daarnaast kun je interne devopsdays, hackathons, enzovoort houden.
5. Kata coachen
Zoals ik aan het begin waarschuwde, zal ik hier vandaag niet over praten. Als u geïnteresseerd bent, kunt u een kijkje nemen .
Er is ook een goed gesprek over dit onderwerp door Mike Rother:
6. Marktgericht: marktgerichte organisatie
Er zijn hier verschillende problemen. Bijvoorbeeld "I"-mensen, "T"-mensen en "E"-mensen. ‘Ik’-mensen zijn degenen die maar één ding doen. Meestal bestaan ze in organisaties met geïsoleerde afdelingen. "T" is wanneer iemand goed is in één ding, maar ook goed in andere dingen. "E" of zelfs "kam" is wanneer een persoon veel vaardigheden heeft.
De wet van Conway werkt hier (), wat in de meest vereenvoudigde vorm als volgt kan worden uitgedrukt: als drie teams aan de compiler werken, is het resultaat een compiler van drie delen. Als er dus sprake is van een hoge mate van isolatie binnen een organisatie, dan zullen zelfs Kubernetes, Circuit breaker, API-uitbreidbaarheid en andere mooie zaken in deze organisatie op dezelfde manier worden geregeld als de organisatie zelf. Strikt volgens Conway en tot spijt van jullie jonge nerds.
De oplossing voor dit probleem is al vele malen beschreven. Er zijn bijvoorbeeld organisatorische archetypen beschreven door Fernando Fernandez. Die problematische architectuur waar ik het zojuist over had, met isolatie, is een functiegerichte architectuur. Het tweede type is het ergste: matrixarchitectuur, een puinhoop van de andere twee. De derde is wat je ziet bij de meeste startups, en ook grote bedrijven proberen dit type te evenaren. Het is een marktgerichte organisatie. Hier optimaliseren we om de snelste reactie op klantverzoeken te bereiken. Dit wordt ook wel een platte organisatie genoemd.
Veel mensen beschrijven deze structuur op verschillende manieren, ik vind de bewoording leuk teams bouwen / runnen, bij Amazon noemen ze dat twee pizzateams. In deze structuur zijn alle mensen van type ‘I’ gegroepeerd rond één dienst, en geleidelijk komen ze dichter bij type ‘T’, en als het juiste management aanwezig is, kunnen ze zelfs ‘E’ worden. Het eerste tegenargument hier is dat een dergelijke structuur onnodige elementen bevat. Waarom heb je op elke afdeling een tester nodig als je een speciale afdeling testers kunt hebben? Waarop ik antwoord: de extra kosten zijn in dit geval de prijs voor de hele organisatie om in de toekomst type “E” te worden. In deze structuur leert de tester geleidelijk over netwerken, architectuur, ontwerp, enz. Hierdoor is iedere deelnemer in de organisatie volledig op de hoogte van alles wat er in de organisatie gebeurt. Wilt u weten hoe deze regeling in de industrie werkt, lees dan .
7. Shift-left-auditors: auditeren vroeg in de cyclus. Naleving van veiligheidsregels tentoongesteld
Dit is wanneer je acties de geurtest niet doorstaan, om zo te zeggen. De mensen die voor jou werken zijn niet dom. Als ze, zoals in bovenstaand voorbeeld, overal een kleine/geen impact neerzetten, dit heeft drie jaar geduurd, en niemand heeft er iets van gemerkt, dan weet iedereen heel goed dat het systeem niet werkt. Of een ander voorbeeld: een wijzigingsadviesraad, waar bijvoorbeeld elke woensdag rapporten moeten worden ingediend. Er werkt daar een groep mensen (overigens niet zo goed betaald) die in theorie zouden moeten weten hoe het systeem als geheel werkt. En de afgelopen vijf jaar heb je waarschijnlijk gemerkt dat onze systemen ongelooflijk complex zijn. En vijf of zes mensen moeten een beslissing nemen over een verandering die ze niet hebben doorgevoerd en waar ze niets van weten.
Deze aanpak werkt uiteraard niet. Ik moet van zulke dingen af, omdat deze mensen het systeem niet beschermen. De beslissing moet door het team zelf worden genomen, omdat het team er verantwoordelijk voor moet zijn. Anders ontstaat er een paradoxale situatie wanneer een manager die nog nooit in zijn leven code heeft geschreven, de programmeur vertelt hoe lang het moet duren om code te schrijven. Eén bedrijf waarmee ik samenwerkte, had zeven verschillende borden die elke verandering beoordeelden, waaronder een architectuurbord, een productbord, enz. Er was zelfs een verplichte wachtperiode, hoewel een medewerker me vertelde dat in de tien jaar dat hij werkte nog nooit iemand een wijziging had afgewezen die deze persoon tijdens deze verplichte periode had aangebracht.
Auditors moeten worden uitgenodigd om zich bij ons aan te sluiten en ze niet weg te doen. Vertel hen dat u onveranderlijke binaire containers schrijft die, als ze alle tests doorstaan, voor altijd onveranderlijk blijven. Vertel hen dat je een pipeline als code hebt en leg uit wat dat betekent. Laat ze het volgende schema zien: een onveranderlijk alleen-lezen binair bestand in een container dat alle kwetsbaarheidstests doorstaat; en dan raakt niet alleen niemand het aan, ze raken zelfs niet het systeem aan dat de pijplijn creëert, aangezien deze ook dynamisch wordt gecreëerd. Ik heb klanten, Capital One, die Vault gebruiken om zoiets als een blockchain te creëren. De auditor hoeft geen ‘recepten’ van Chef te laten zien; het volstaat om de blockchain te laten zien, waaruit duidelijk wordt wat er met het Jira-ticket in productie is gebeurd en wie daarvoor verantwoordelijk is.
Volgens , gemaakt in 2018 door Sonatype, waren er in 2017 87 miljard OSS-downloadverzoeken.
De verliezen als gevolg van kwetsbaarheden zijn onbetaalbaar. Bovendien zijn in de cijfers die je nu hierboven ziet geen rekening gehouden met opportuniteitskosten. Wat is DevSecOps in een notendop? Laat ik meteen zeggen dat ik niet geïnteresseerd ben om te praten over hoe succesvol deze naam is. Het punt is dat, aangezien DevOps zo succesvol is, we moeten proberen beveiliging aan die pijplijn toe te voegen.
Een voorbeeld van deze reeks:
Dit is geen aanbeveling voor specifieke producten, ook al vind ik ze allemaal leuk. Ik heb ze als voorbeeld genoemd om te laten zien dat DevOps, dat aanvankelijk gebaseerd was op het organisatorische paradigma in de industrie, je in staat stelt elke fase van het werken aan een product te automatiseren.
En er is geen reden waarom we niet dezelfde benadering van beveiliging zouden kunnen hanteren.
Totaal
Als afsluiting geef ik nog enkele tips voor DevSecOps. U moet auditors betrekken bij het proces van het creëren van uw systemen en tijd besteden aan het opleiden ervan. U moet samenwerken met auditors. Vervolgens moet je een absoluut meedogenloze strijd voeren tegen valse positieven. Zelfs met de duurste tool voor het scannen van kwetsbaarheden kun je extreem slechte gewoonten creëren onder je ontwikkelaars als je niet weet wat je signaal-ruisverhouding is. Ontwikkelaars zullen overweldigd raken door gebeurtenissen en deze eenvoudigweg verwijderen. Als je van het Equifax-verhaal hebt gehoord: dat is ongeveer wat daar gebeurde, waar het hoogste waarschuwingsniveau werd genegeerd. Bovendien moeten kwetsbaarheden worden uitgelegd op een manier die duidelijk maakt welke impact ze hebben op het bedrijf. Je zou bijvoorbeeld kunnen zeggen dat dit dezelfde kwetsbaarheid is als in het Equifax-verhaal. Beveiligingsproblemen moeten op dezelfde manier worden behandeld als andere softwareproblemen, dat wil zeggen dat ze moeten worden opgenomen in het algehele DevOps-proces. Je moet met ze samenwerken via Jira, Kanban, enz. Ontwikkelaars moeten niet denken dat iemand anders dit zal doen - integendeel, iedereen zou dit moeten doen. Ten slotte moet je energie steken in het opleiden van mensen.
Nuttige links
Hier zijn enkele toespraken van de DevOops-conferentie die u wellicht nuttig vindt:
- Sergey Berdnikov, Artyom Kalichkin - Succesverhaal, of “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps op schaal: een Griekse tragedie in drie bedrijven (, )
- Alexander Titov, Kirill Tolkachev -
- Timotheüs Lister -
Naar kijken DevOops 2020 Moskou - er zijn ook veel interessante dingen.
Bron: www.habr.com