Die vraag "hoe om devops te implementeer" bestaan al jare, maar daar is nie baie goeie materiale nie. Soms word jy die slagoffer van advertensies van nie-so-slim konsultante wat hul tyd moet verkoop, maak nie saak hoe nie. Soms is dit vae, uiters algemene woorde oor hoe die skepe van megakorporasies die uitspansels van die heelal ploeg. Die vraag ontstaan: wat maak dit vir ons saak? Geagte skrywer, kan jy jou idees duidelik in 'n lys formuleer?
Dit alles spruit uit die feit dat daar nie veel werklike praktyk en begrip van die uitkoms van transformasies van die maatskappy se kultuur opgehoop het nie. Veranderinge in kultuur is langtermyn dinge, waarvan die resultate nie oor 'n week of 'n maand sal verskyn nie. Ons het iemand nodig wat oud genoeg is om te sien hoe maatskappye oor die jare gebou en misluk is.
John Willis - een van die vaders van DevOps. John het dekades se ondervinding om met 'n groot aantal maatskappye te werk. Onlangs het John spesifieke patrone begin raaksien wat plaasvind wanneer daar met elkeen van hulle gewerk word. Deur hierdie argetipes te gebruik, lei John maatskappye op die ware pad van DevOps-transformasie. Lees meer oor hierdie argetipes in die vertaling van sy verslag van die DevOops 2018-konferensie.
Oor die spreker:
Meer as 35 jaar in IT-bestuur, deelgeneem aan die skepping van die voorganger van OpenCloud by Canonical, het deelgeneem aan 10 opstartondernemings, waarvan twee aan Dell en Docker verkoop is. Tans is hy vise-president van DevOps en digitale praktyke by SJ Technologies.
Volgende is die verhaal vanuit John se oogpunt.
My naam is John Willis en die maklikste plek om my te vind is op Twitter, . Ek het dieselfde alias op Gmail en GitHub. A jy kan video-opnames van my verslae en aanbiedings daarvoor vind.
Ek het baie vergaderings met CIO's van verskeie groot maatskappye. Hulle kla baie dikwels dat hulle nie verstaan wat DevOps is nie, en almal wat dit aan hulle probeer verduidelik, praat oor iets anders. Nog 'n algemene klagte is dat DevOps nie werk nie, hoewel dit blyk dat die direkteure alles doen soos aan hulle verduidelik is. Ons praat van groot maatskappye wat meer as honderd jaar oud is. Nadat ek met hulle gepraat het, het ek tot die gevolgtrekking gekom dat dit vir baie probleme nie hoë tegnologie is wat die beste geskik is nie, maar eerder relatief lae-tegnologie oplossings. Ek het weke lank net met mense van verskillende departemente gepraat. Wat jy op die heel eerste foto in die pos sien is my laaste projek, so het die kamer gelyk na drie dae se werk.
Wat is DevOps?
Inderdaad, as jy 10 verskillende mense vra, sal hulle 10 verskillende antwoorde gee. Maar hier is die interessante ding: al tien hierdie antwoorde sal korrek wees. Hier is geen verkeerde antwoord nie. Ek was vir ongeveer 10 jaar redelik diep in DevOps en was die eerste Amerikaner by die eerste DevOpsDay. Ek sal nie sê dat ek slimmer is as almal wat by DevOps betrokke is nie, maar daar is skaars iemand wat soveel moeite daaraan bestee het. Ek glo dat DevOps plaasvind wanneer mensekapitaal en tegnologie bymekaarkom. Ons vergeet dikwels van die menslike dimensie, hoewel ons baie oor allerhande kulture praat.
Nou het ons baie data, vyf jaar se akademiese navorsing, toetsing van teorieë op 'n industriële skaal. Wat hierdie studies vir ons sê, is dat as jy 'n paar gedragspatrone in 'n organisasiekultuur kombineer, jy 'n 2000 5000x versnelling kan bereik. Hierdie versnelling word geëwenaar deur 'n gelyke verbetering in stabiliteit. Dit is 'n kwantitatiewe meting van die voordeel wat DevOps vir enige maatskappy kan bring. 'n Paar jaar gelede het ek met die HUB van 'n Fortune 5-maatskappy oor DevOps gepraat. Toe ek vir die aanbieding voorberei het, was ek baie senuweeagtig, want ek moes my jare se ondervinding in XNUMX minute opsom.
Op die ou end het ek die volgende gegee Definisie van DevOps: Dit is 'n stel praktyke en patrone wat die transformasie van menslike kapitaal in hoëprestasie organisasiekapitaal moontlik maak. 'n Voorbeeld is die manier waarop Toyota die afgelope 50 of 60 jaar bedrywig is.
(Hierna word sulke diagramme nie as verwysingsmateriaal verskaf nie, maar as illustrasies. Die inhoud daarvan sal verskil vir elke nuwe maatskappy. Die prentjie kan egter apart bekyk en vergroot word
Een van die suksesvolste sulke praktyke is waarde stroom kartering. Verskeie goeie boeke is hieroor geskryf, waarvan die suksesvolste deur Karen Martin is. Maar oor die afgelope jaar het ek tot die gevolgtrekking gekom dat selfs hierdie benadering te hoëtegnologie is. Dit het beslis baie voordele en ek het dit al baie gebruik. Maar wanneer die HUB jou vra hoekom sy maatskappy nie na nuwe spoorstawe kan oorskakel nie, is dit te vroeg om oor waardestroomkartering te praat. Daar is baie meer fundamentele vrae wat eers beantwoord moet word.
Ek dink die fout wat baie van my kollegas maak, is dat hulle bloot vir die maatskappy 'n vyfpuntgids gee en dan ses maande later terugkom en kyk wat gebeur het. Selfs 'n goeie skema soos waardestroomkartering het, kom ons sê, blindekolle. Na honderde onderhoude met direkteure van verskeie maatskappye, het ek 'n sekere patroon ontwikkel wat ons in staat stel om die probleem in sy komponente af te breek, en nou sal ons elkeen van hierdie komponente in volgorde bespreek. Voordat ek enige tegnologiese oplossings toepas, gebruik ek hierdie patroon, en gevolglik is al my mure met diagramme bedek. Ek het onlangs met 'n onderlinge fonds gewerk en ek het met 100-150 sulke skemas geëindig.
Slegte kultuur eet goeie benaderings vir ontbyt
Die hoofgedagte is dit: geen hoeveelheid Lean, Agile, SAFE en DevOps sal help as die organisasie se kultuur self sleg is nie. Dit is soos om na dieptes te duik sonder skuba-toerusting of om sonder 'n x-straal te werk. Met ander woorde, om Drucker en Deming te parafraseer: 'n slegte organisasiekultuur sal enige goeie stelsel insluk sonder om daaraan te verstik.
Om hierdie hoofprobleem op te los, moet u die volgende stappe neem:
- Maak alle werk sigbaar: jy moet al die werk sigbaar maak. Nie in die sin dat dit noodwendig op een of ander skerm vertoon moet word nie, maar in die sin dat dit waarneembaar moet wees.
- Gekonsolideerde werkbestuurstelsels: bestuurstelsels moet gekonsolideer word. In die probleem van "stam" kennis en institusionele kennis, in 9 gevalle uit 10 is die bottelnek mense. In die boek die probleem was met een enkele persoon, Brent, wat veroorsaak het dat die projek drie jaar agter skedule was. En ek loop oral hierdie “Brents” raak. Om hierdie knelpunte op te los, gebruik ek die volgende twee items op ons lys.
- Teorie van Beperkings Metodologie: teorie van beperkings.
- Samewerking hacks: samewerking hacks.
- Toyota Kata (): Ek sal nie veel oor die Toyota Kata praat nie. As jy belangstel, op my github oor byna elkeen van hierdie onderwerpe.
- Markgerigte organisasie: markgerigte organisasie.
- Skuif-links ouditeure: oudit in die vroeë stadiums van die siklus.
Ek begin baie eenvoudig met 'n organisasie werk: ek gaan na die maatskappy en praat met die werknemers. Soos jy kan sien, geen hoë tegnologie. Al wat jy nodig het is iets om op te skryf. Ek versamel verskeie spanne in een vertrek en ontleed wat hulle vir my sê vanuit die perspektief van my 7 argetipes. En dan gee ek vir hulle self 'n merker en vra hulle om alles op die bord neer te skryf wat hulle tot dusver hardop gesê het. Gewoonlik in hierdie tipe vergaderings is daar een persoon wat alles neerskryf, en op sy beste kan hy 10% van die bespreking neerskryf. Met my metode kan hierdie syfer tot sowat 40% verhoog word.
(Hierdie illustrasie kan afsonderlik bekyk word )
My benadering is gebaseer op die werk van William Schneider. ). Die benadering is gebaseer op die idee dat enige organisasie in vier vierkante verdeel kan word. Hierdie skema vir my is gewoonlik die resultaat van die werk met daardie honderde ander skemas wat ontstaan wanneer 'n organisasie ontleed word. Gestel ons het 'n organisasie met 'n hoë vlak van beheer, maar met lae bevoegdheid. Dit is 'n uiters ongewenste opsie: wanneer almal die lyn staan, maar niemand weet wat om te doen nie.
'n Ietwat beter opsie is een met 'n hoë vlak van beide beheer en bevoegdheid. As so 'n maatskappy winsgewend is, het dit miskien nie DevOps nodig nie. Dit is baie interessant om met 'n maatskappy te werk wat 'n hoë vlak van beheer, lae bevoegdheid en samewerking het, maar terselfdertyd 'n hoë vlak van kultuur (verbouing). Dit beteken die maatskappy het baie mense wat daarvan hou om daar te werk en die arbeidsomset is laag.
(Hierdie illustrasie kan afsonderlik bekyk word )
Dit lyk vir my dat metodes met rigiede riglyne uiteindelik in die pad staan om die waarheid te bereik. In veral waardestroomkartering is daar baie reëls oor hoe inligting gestruktureer moet word. In die vroeë stadiums van werk, waarvan ek nou praat, het niemand hierdie reëls nodig nie. As 'n persoon met 'n merker in sy hande die werklike situasie in die maatskappy op die direksie beskryf, is dit die beste manier om die stand van sake te verstaan. Sulke inligting bereik nie direkteure nie. Op hierdie oomblik is dit dom om die persoon te onderbreek en te sê dat hy 'n soort pyl verkeerd geteken het. Op hierdie stadium is dit beter om eenvoudige reëls te gebruik, byvoorbeeld: multi-vlak abstraksie kan eenvoudig geskep word deur veelkleurige merkers te gebruik.
Ek herhaal, geen hoë tegnologie nie. Die swart merker beeld die objektiewe werklikheid uit van hoe alles werk. Met 'n rooi merker merk mense wat hulle nie van die huidige stand van sake hou nie. Dit is belangrik dat hulle dit skryf, nie ek nie. Wanneer ek na 'n vergadering na die CIO gaan, bied ek nie 'n lys van 10 dinge wat reggemaak moet word nie. Ek streef daarna om verbande te vind tussen wat mense in die maatskappy sê en bestaande bewese patrone. Ten slotte, 'n blou merker stel moontlike oplossings vir die probleem voor.
(Hierdie illustrasie kan afsonderlik bekyk word )
'n Voorbeeld van hierdie benadering word nou hierbo uitgebeeld. Aan die begin van hierdie jaar het ek by een bank gewerk. Die sekuriteitsmense daar was oortuig dat hulle nie na ontwerp en vereiste hersiening moet kom nie.
(Hierdie illustrasie kan afsonderlik bekyk word )
En toe praat ons met mense van ander departemente en dit blyk dat sagteware-ontwikkelaars sowat 8 jaar gelede sekuriteitswerkers afgedank het omdat hulle werk vertraag het. En toe ontaard dit in 'n verbod, wat as vanselfsprekend aanvaar is. Alhoewel daar in werklikheid geen verbod was nie.
Ons vergadering het op 'n uiters verwarrende wyse verloop: vir ongeveer drie uur kon vyf verskillende spanne nie aan my verduidelik wat tussen die kode en die vergadering gebeur nie. En dit blyk die eenvoudigste ding te wees. Die meeste DevOps-konsultante neem vooraf aan dat almal dit reeds weet.
Toe kom die persoon in beheer van IT-bestuur, wat vier uur lank stil was, skielik lewe toe ons by sy onderwerp kom, en het ons baie lank besig gehou. Aan die einde het ek hom gevra wat hy van die vergadering dink, en ek sal nooit sy antwoord vergeet nie. Hy het gesê: "Ek het vroeër gedink ons bank het net twee maniere om sagteware te lewer, maar nou weet ek dat daar vyf van hulle is, en ek het nie eens geweet van drie nie."
(Hierdie illustrasie kan afsonderlik bekyk word )
Die laaste vergadering by hierdie bank was met die beleggingsagteware-span. Dit was by haar dat dit geblyk het dat die skryf van diagramme met 'n merker op 'n vel papier beter is as op 'n bord, en selfs beter as op 'n slimbord.
Die foto's wat jy sien is hoe die hotelkonferensiekamer gelyk het op die vierde dag van ons vergadering. En ons het hierdie skemas gebruik om na patrone te soek, dit wil sê argetipes.
So, ek vra die werkers vrae, hulle skryf die antwoorde neer met merkers van drie kleure (swart, rooi en blou). Ek ontleed hul antwoorde vir argetipes. Kom ons bespreek nou al die argetipes in volgorde.
1. Maak alle werk sigbaar: Maak werk sigbaar
Die meeste maatskappye met wie ek werk, het 'n baie hoë persentasie onbekende werk. Dit is byvoorbeeld wanneer een werknemer na 'n ander kom en bloot vra om iets te doen. In groot organisasies kan daar 60% onbeplande werk wees. En tot 40% van die werk is op geen manier gedokumenteer nie. As dit Boeing was, sou ek nooit weer in my lewe op hul vliegtuig klim nie. As slegs die helfte van die werk gedokumenteer is, is dit nie bekend of hierdie werk korrek gedoen word of nie. Alle ander metodes blyk nutteloos te wees - dit is geen sin om enigiets te probeer outomatiseer nie, want die bekende 50% kan die mees samehangende en duidelikste deel van die werk wees, waarvan die outomatisering nie goeie resultate sal lewer nie, en al die ergste dinge is in die onsigbare helfte. In die afwesigheid van dokumentasie is dit onmoontlik om allerhande hacks en versteekte werk te vind, nie om bottelnekke te vind nie, daardie einste "Brents" waarvan ek reeds gepraat het. Daar is 'n wonderlike boek deur Dominica DeGrandis . Sy onthul vyf verskillende "tydlekkasies" (tyddiewe):
- Te veel werk in proses (WIP)
- Onbekende afhanklikhede
- Onbeplande werk
- Botsende prioriteite
- Verwaarloosde Werk
Dit is baie waardevolle ontleding en die boek is wonderlik, maar al hierdie raad is nutteloos as net 50% van die data sigbaar is. Die metodes wat deur Dominica voorgestel word, kan gebruik word as 'n akkuraatheid van meer as 90% behaal word. Ek praat van situasies waar 'n baas 'n ondergeskikte 'n taak van 15 minute gee, maar dit neem hom drie dae; maar die baas weet nie eintlik dat hierdie ondergeskikte van vier of vyf ander mense afhanklik is nie.
Die Phoenix-projek is 'n wonderlike storie oor 'n projek wat drie jaar te laat was. Een van die karakters staar ontslag in die gesig as gevolg hiervan, en hy ontmoet 'n ander karakter wat as 'n soort Sokrates voorgestel word. Hy help om uit te vind wat presies verkeerd geloop het. Dit blyk dat die maatskappy een stelseladministrateur het, wie se naam Brent is, en alle werk gaan op een of ander manier deur hom. By een van die vergaderings word een van die ondergeskiktes gevra: hoekom neem elke halfuurtaak 'n week? Die antwoord is 'n baie vereenvoudigde aanbieding van toustaanteorie en Little se wet, en in hierdie aanbieding blyk dit dat elke uur se werk by 90% besetting 9 uur neem. Elke taak moet na sewe ander mense gestuur word, sodat die uur 63 uur word, 7 keer 9. Wat ek sê, is dat jy ten minste data moet hê om Little's Law of enige komplekse toustaanteorie te gebruik.
So as ek oor sigbaarheid praat, bedoel ek nie dat alles op die skerm is nie, maar dat jy ten minste data het. Wanneer hulle dit doen, blyk dit dikwels dat daar 'n baie groot hoeveelheid onbeplande werk is wat op een of ander manier na Brent gestuur word wanneer dit nie nodig is nie. En Brent is 'n wonderlike ou, hy sal nooit nee sê nie, maar hy vertel vir niemand hoe hy sy werk doen nie.
Wanneer die werk sigbaar is, kan die data netjies geklassifiseer word (dis wat Dominika op die foto doen), die abstraksie van die vyf tydlekkasies kan toegepas word en outomatisering kan toegepas word.
2. Konsolideer Werkbestuurstelsels: Taakbestuur
Die argetipes waarvan ek praat is 'n soort piramide. As die eerste een korrek gedoen is, dan is die tweede een reeds 'n soort byvoeging. Baie hiervan werk nie vir beginners nie, hulle moet in gedagte gehou word vir groter maatskappye soos die Fortune 5000. Die laaste maatskappy waarvoor ek gewerk het, het 10 kaartjiestelsels gehad. Een span het Remedy gehad, 'n ander het 'n soort van sy eie stelsel geskryf, 'n derde het Jira gebruik, en sommige het met e-pos klaargemaak. Dieselfde probleem ontstaan as die maatskappy 30 verskillende pyplyne het, maar ek het nie tyd om al sulke gevalle te bespreek nie.
Ek bespreek met mense presies hoe kaartjies geskep word, wat volgende met hulle gebeur en hoe dit omseil word. Die interessantste is dat mense by ons vergaderings nogal opreg praat. Ek het gevra hoeveel mense plaas "minor / no impact" op kaartjies wat eintlik "major impact" moet kry. Dit het geblyk dat byna almal dit doen. Ek is nie besig met veroordeling nie en probeer op elke moontlike manier om nie mense te identifiseer nie. Wanneer hulle opreg iets aan my bely, gee ek nie die persoon weg nie. Maar wanneer byna almal die stelsel omseil, beteken dit dat alle sekuriteit in wese window dressing is. Daarom kan geen gevolgtrekkings gemaak word uit die data van hierdie stelsel nie.
Om die kaartjieprobleem op te los, moet jy een hoofstelsel kies. As jy Jira gebruik, hou dit Jira. As daar enige alternatief is, laat dit die enigste een wees. Die slotsom is dat kaartjies as nog 'n stap in die ontwikkelingsproses beskou moet word. Elke aksie moet 'n kaartjie hê, wat deur die ontwikkelingswerkvloei moet vloei. Kaartjies word aan die span gestuur, wat dit op die storiebord plaas en dan verantwoordelikheid daarvoor neem.
Dit geld vir alle departemente, insluitend infrastruktuur en bedrywighede. In hierdie geval is dit moontlik om ten minste 'n geloofwaardige idee van die stand van sake te vorm. Sodra hierdie proses vasgestel is, word dit skielik maklik om te identifiseer wie vir elke aansoek verantwoordelik is. Want nou ontvang ons nie 50% nie, maar 98% van nuwe dienste. As hierdie kernproses werk, verbeter akkuraatheid regdeur die stelsel.
Dienste pypleiding
Dit geld weer net vir groot korporasies. As jy 'n nuwe maatskappy in 'n nuwe veld is, rol jou moue op en werk saam met jou Travis CI of CircleCI. As dit by Fortune 5000-maatskappye kom, 'n voorbeeld wat gebeur het by die bank waar ek gewerk het. Google het na hulle gekom en hulle is diagramme van ou IBM-stelsels gewys. Die ouens van Google het verward gevra – waar is die bronkode hiervoor? Maar daar is geen bronkode nie, nie eers 'n GUI nie. Dit is die realiteit waarmee groot organisasies te doen het: 40 jaar oue bankrekords op 'n antieke hoofraam. Een van my kliënte gebruik Kubernetes-houers met Circuit Breaker-patrone, plus Chaos Monkey, alles vir die KeyBank-toepassing. Maar hierdie houers koppel uiteindelik aan 'n COBOL-toepassing.
Die ouens van Google was heeltemal vol vertroue dat hulle al my kliënt se probleme sou oplos, en toe begin hulle vrae vra: wat is IBM datapipe? Daar word vir hulle gesê: dit is 'n koppelaar. Waarmee verbind dit? Na die Sperry-stelsel. En wat is dit? En so aan. Met die eerste oogopslag lyk dit: watter soort DevOps kan daar wees? Maar in werklikheid is dit moontlik. Daar is afleweringstelsels wat jou toelaat om die werkvloei aan die afleweringspanne te oorhandig.
3. Theory of Constraints: Theory of Constraints
Kom ons gaan oor na die derde argetipe: institusionele/"stam" kennis. As 'n reël, in enige organisasie is daar verskeie mense wat alles weet en alles bestuur. Dit is diegene wat die langste in die organisasie is en wat al die oplossings ken.
Wanneer dit op die diagram kom, omkring ek sulke mense spesifiek met 'n merker: dit blyk byvoorbeeld dat 'n sekere Lou by alle vergaderings teenwoordig is. En dit is vir my duidelik: dit is plaaslike Brent. Wanneer die CIO kies tussen my in 'n T-hemp en tekkies en die ou van IBM in 'n pak, word ek gekies omdat ek vir die direkteur dinge kan vertel wat die ander ou nie sal vertel nie en wat die direkteur dalk nie graag wil hoor nie . Ek sê vir hulle dat die bottelnek in hul geselskap iemand met die naam Fred en iemand met die naam Lou is. Hierdie knelpunt moet losgemaak word, hul kennis moet op een of ander manier by hulle verkry word.
Om hierdie soort probleem op te los, kan ek byvoorbeeld voorstel om Slack te gebruik. ’n Slim regisseur sal vra – hoekom? Tipies, in sulke gevalle, antwoord DevOps-konsultante: want almal doen dit. As die regisseur regtig slim is, sal hy sê: so what. En dit is waar die dialoog eindig. En my antwoord hierop is: want daar is vier knelpunte in die maatskappy, Fred, Lou, Susie en Jane. Om hul kennis te institusionaliseer, moet 'n mens eers Slack bekendstel. Al jou wiki's is volslae nonsens want niemand weet van hul bestaan nie. As die ingenieurspan betrokke is by front-end en back-end ontwikkeling en almal moet weet dat hulle die front-end ontwikkelingspan of die infrastruktuurspan met vrae kan kontak. Dit is wanneer Lou of Fred waarskynlik tyd sal hê om by die wiki aan te sluit. En dan sal iemand dalk in Slack vra hoekom, sê, stap 5 nie werk nie. En dan sal Lou of Fred die instruksies op die wiki regstel. As jy hierdie proses vestig, sal baie dinge vanself in plek val.
Dit is my hoofpunt: om enige hoë tegnologieë aan te beveel, moet jy eers die grondslag daarvoor in orde stel, en dit kan gedoen word met die lae-tegnologie-oplossings wat sopas beskryf is. As jy met hoë tegnologieë begin en nie verduidelik hoekom dit nodig is nie, dan eindig dit as 'n reël nie goed nie. Een van ons kliënte gebruik Azure ML, 'n baie goedkoop en eenvoudige oplossing. Sowat 30% van hul vrae is deur die selfleermasjien self beantwoord. En hierdie ding is geskryf deur operateurs wat nie betrokke was by datawetenskap, statistiek of wiskunde nie. Dit is betekenisvol. Die koste van so 'n oplossing is minimaal.
4. Samewerking hacks: Collaboration hacks
Die vierde argetipe is die behoefte om isolasie te bekamp. Die meeste mense weet dit reeds: isolasie kweek vyandigheid. As elke departement op sy eie vloer is, en mense op geen manier met mekaar sny nie, behalwe in die hysbak, dan ontstaan vyandigheid tussen hulle baie maklik. Maar as mense inteendeel in dieselfde vertrek met mekaar is, gaan sy dadelik weg. Wanneer iemand byvoorbeeld een of ander algemene beskuldiging uitgooi, so en so 'n koppelvlak werk nooit nie, is daar niks makliker om so 'n beskuldiging te dekonstrueer nie. Die programmeerders wat die koppelvlak geskryf het, moet net spesifieke vrae begin vra, en dit sal binnekort duidelik word dat die gebruiker byvoorbeeld bloot die hulpmiddel verkeerd gebruik het.
Daar is baie maniere om isolasie te oorkom. Ek is eenkeer gevra om vir 'n bank in Australië te konsulteer, maar ek het geweier om dit te doen omdat ek twee kinders en 'n vrou het. Al wat ek kon doen om hulle te help, was om grafiese storievertelling aan te beveel. Dit is iets wat bewys is om te werk. Nog 'n interessante manier is maer koffievergaderings. In 'n groot organisasie is dit 'n uitstekende opsie om kennis te versprei. Daarbenewens kan jy interne devopsdays, hackathons, ensovoorts hou.
5. Afrigting Kata
Soos ek heel aan die begin gewaarsku het, sal ek nie vandag hieroor praat nie. As jy belangstel, kan jy gaan kyk .
Daar is ook 'n goeie praatjie oor hierdie onderwerp deur Mike Rother:
6. Markgeoriënteerd: markgerigte organisasie
Hier is verskillende probleme. Byvoorbeeld, "I" mense, "T" mense en "E" mense. "Ek" mense is diegene wat net een ding doen. Tipies bestaan hulle in organisasies met geïsoleerde departemente. "T" is wanneer 'n persoon goed is in een ding, maar ook goed in ander dinge. "E" of selfs "kam" is wanneer 'n persoon baie vaardighede het.
Conway se wet werk hier (), wat in die mees vereenvoudigde vorm soos volg gestel kan word: as drie spanne aan die samesteller werk, dan sal die resultaat 'n samesteller van drie dele wees. As daar dus 'n hoë vlak van isolasie binne 'n organisasie is, sal selfs Kubernetes, Circuit breaker, API-uitbreidbaarheid en ander fancy dinge in hierdie organisasie op dieselfde manier as die organisasie self gereël word. Streng volgens Conway en ten spyte van al julle jong geeks.
Die oplossing vir hierdie probleem is al baie keer beskryf. Daar is byvoorbeeld organisatoriese argetipes wat deur Fernando Fernandez beskryf word. Daardie problematiese argitektuur waaroor ek sopas gepraat het, met isolasie, is 'n funksie-georiënteerde argitektuur. Die tweede tipe is die ergste, matriksargitektuur, 'n gemors van die ander twee. Die derde is wat gesien word in die meeste startups, en groot maatskappye probeer ook om hierdie tipe te pas. Dit is 'n markgerigte organisasie. Hier optimaliseer ons om die vinnigste reaksie op klantversoeke te kry. Dit word soms 'n plat organisasie genoem.
Baie mense beskryf hierdie struktuur op verskillende maniere, ek hou van die bewoording bou/hardloop spanne, by Amazon noem hulle dit twee pizza-spanne. In hierdie struktuur word alle tipe "I" mense rondom een diens gegroepeer, en geleidelik word hulle nader aan tipe "T", en as die regte bestuur in plek is, kan hulle selfs "E" word. Die eerste teenargument hier is dat so 'n struktuur onnodige elemente bevat. Hoekom het jy 'n toetser in elke departement nodig as jy 'n spesiale departement toetsers kan hê? Waarop ek antwoord: die ekstra koste in hierdie geval is die prys vir die hele organisasie om in die toekoms tipe “E” te word. In hierdie struktuur leer die toetser geleidelik van netwerke, argitektuur, ontwerp, ens. Gevolglik is elke deelnemer in die organisasie ten volle bewus van alles wat in die organisasie gebeur. As jy wil weet hoe hierdie skema in die industrie werk, lees .
7. Skuif-links ouditeure: oudit vroeg in die siklus. Voldoening aan veiligheidsreëls wat vertoon word
Dit is wanneer jou optrede so te sê nie die reuktoets slaag nie. Die mense wat vir jou werk is nie dom nie. As hulle, soos in die voorbeeld hierbo, oral geringe/geen impak gestel het, dit het drie jaar geduur, en niemand het iets opgemerk nie, dan weet almal baie goed dat die stelsel nie werk nie. Of 'n ander voorbeeld - 'n adviesraad vir verandering, waar verslae elke, sê, Woensdag ingedien moet word. Daar is 'n groep mense wat daar werk (terloops nie baie goed betaal nie) wat in teorie behoort te weet hoe die stelsel as geheel werk. En oor die afgelope vyf jaar het jy waarskynlik opgemerk dat ons stelsels ongelooflik kompleks is. En vyf of ses mense moet 'n besluit neem oor 'n verandering wat hulle nie gemaak het nie en waarvan hulle niks weet nie.
Natuurlik werk hierdie benadering nie. Ek moet van sulke goed ontslae raak, want hierdie mense beskerm nie die stelsel nie. Die besluit moet deur die span self geneem word, want die span moet daarvoor verantwoordelik wees. Andersins ontstaan 'n paradoksale situasie wanneer 'n bestuurder wat nog nooit in sy lewe kode geskryf het, vir die programmeerder sê hoe lank dit moet neem om kode te skryf nie. Een maatskappy waarmee ek gewerk het, het 7 verskillende direksies gehad wat elke verandering hersien het, insluitend 'n argitektuurbord, 'n produkbord, ens. Daar was selfs 'n verpligte wagtydperk, alhoewel een werknemer vir my gesê het dat in tien jaar se werk, niemand ooit 'n verandering wat deur hierdie persoon gedurende hierdie verpligte tydperk gemaak is, verwerp het nie.
Ouditeure moet genooi word om by ons aan te sluit, en nie van hulle ontslae te raak nie. Sê vir hulle dat jy onveranderlike binêre houers skryf wat, as hulle al die toetse slaag, vir ewig onveranderlik bly. Sê vir hulle dat jy 'n pyplyn as kode het en verduidelik wat dit beteken. Wys hulle die volgende skema: 'n onveranderlike leesalleen-binêr in 'n houer wat alle kwesbaarheidstoetse slaag; en dan raak niemand dit net nie, hulle raak nie eers aan die stelsel wat die pyplyn skep nie, aangesien dit ook dinamies geskep word. Ek het kliënte, Capital One, wat Vault gebruik om iets soos 'n blokketting te skep. Die ouditeur hoef nie "resepte" van Chef te wys nie; dit is genoeg om die blokketting te wys, waaruit dit duidelik is wat met die Jira-kaartjie in produksie gebeur het en wie daarvoor verantwoordelik is.
Volgens , geskep in 2018 deur Sonatype, was daar 2017 miljard OSS-aflaaiversoeke in 87.
Die verliese wat gely word as gevolg van kwesbaarhede is onbetaalbaar. Boonop sluit die syfers wat u nou hierbo sien nie geleentheidskoste in nie. Wat is DevSecOps in 'n neutedop? Laat ek dadelik sê dat ek nie belangstel om te praat oor hoe suksesvol hierdie naam is nie. Die punt is dat aangesien DevOps so suksesvol was, ons moet probeer om sekuriteit by daardie pyplyn te voeg.
'n Voorbeeld van hierdie volgorde:
Dit is nie 'n aanbeveling vir spesifieke produkte nie, hoewel ek van almal hou. Ek het hulle as 'n voorbeeld aangehaal om te wys dat DevOps, wat aanvanklik op die organisatoriese paradigma in die industrie gebaseer was, jou toelaat om elke stadium van werk aan 'n produk te outomatiseer.
En daar is geen rede waarom ons nie dieselfde benadering tot sekuriteit kon volg nie.
Totale
As gevolgtrekking gee ek 'n paar wenke vir DevSecOps. Jy moet ouditeure insluit in die proses om jou stelsels te skep en tyd daaraan bestee om hulle op te voed. Jy moet met ouditeure saamwerk. Vervolgens moet jy 'n absoluut meedoënlose stryd teen vals positiewes voer. Selfs met die duurste kwesbaarheidskanderingsinstrument, kan jy uiteindelik uiters slegte gewoontes onder jou ontwikkelaars skep as jy nie weet wat jou sein-tot-geraas-verhouding is nie. Ontwikkelaars sal oorweldig word met gebeure en sal dit eenvoudig uitvee. As jy van die Equifax-storie gehoor het, is dit omtrent wat daar gebeur het, waar die hoogste waarskuwingsvlak geïgnoreer is. Boonop moet kwesbaarhede verduidelik word op 'n manier wat dit duidelik maak hoe dit die besigheid beïnvloed. Byvoorbeeld, jy kan sê dat dit dieselfde kwesbaarheid is as in die Equifax-verhaal. Sekuriteitskwesbaarhede moet dieselfde hanteer word as ander sagtewarekwessies, dit wil sê, dit moet by die algehele DevOps-proses ingesluit word. Jy moet met hulle werk deur Jira, Kanban, ens. Ontwikkelaars moenie dink dat iemand anders dit sal doen nie – inteendeel, almal moet dit doen. Ten slotte moet jy energie spandeer om mense op te lei.
nuttige skakels
Hier is 'n paar praatjies van die DevOops-konferensie wat jy dalk nuttig kan vind:
- Sergey Berdnikov, Artyom Kalichkin - Suksesverhaal, of "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps op 'n skaal: 'n Griekse tragedie in drie bedrywe (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Kyk na DevOops 2020 Moskou — daar is ook baie interessante dinge daar.
Bron: will.com