SpÞrsmÄlet om «hvordan implementere DevOps selv» har vÊrt aktuelt i mange Är, men gode ressurser er ikke sÄ mange. Noen ganger blir man offer for reklame fra mindre kloke konsulenter som bare Þnsker Ä selge sin tid, uansett hvordan. Av og til er det uklare og svÊrt generelle utsagn om hvordan megaselskapenes skip krysser universets rom. Det reiser spÞrsmÄlet: hva fÄr vi ut av dette? KjÊre forfatter, kan du formulere dine ideer pÄ en klar liste?
Alt dette skyldes at det ikke har samlet seg sÄ mye reell erfaring og forstÄelse av utfallene av kulturtransformasjoner. Endringer i kulturen er langsiktige prosesser, hvis resultater ikke vil vise seg pÄ en uke eller en mÄned. Vi trenger noen som er tilstrekkelig erfaren, som har sett hvordan selskaper har blitt til og blitt Þdelagt gjennom mange Är.
John Willis â en av fedrene til DevOps. John har mange Ă„r med erfaring fra et stort antall selskaper. PĂ„ det siste har John lagt merke til spesifikke mĂžnstre som er til stede i arbeidet med hver av dem. Ved Ă„ bruke disse arketypene guider John selskaper pĂ„ den riktige veien for DevOps-transformasjon. Mer om disse arketypene finner du i oversettelsen av hans foredrag fra DevOops-konferansen i 2018.
Om foredragsholderen:
Over 35 Ă„r innen IT-ledelse, deltatt i utviklingen av forgjengeren til OpenCloud i Canonical, vĂŠrt med i 10 oppstartsselskaper, to av dem solgt til Dell og Docker. NĂ„vĂŠrende Vice President of DevOps and Digital Practices i SJ Technologies.
Deretter fĂžlger en beretning fra John.
Mitt navn er John Willis, og jeg er lett Ä finne pÄ Twitter, . Jeg bruker samme pseudonym pÄ Gmail og GitHub. Og kan du finne videoopptak av mine foredrag og presentasjoner.
Jeg har mange mĂžter med CIO-er i forskjellige store selskaper. De klager veldig ofte pĂ„ at de ikke forstĂ„r hva DevOps er, og alle som prĂžver Ă„ forklare det for dem, snakker om noe helt annet. En annen vanlig klage er at DevOps ikke fungerer, selv om direktĂžrene tilsynelatende gjĂžr alt som de har fĂ„tt forklart. Dette gjelder store selskaper som har eksisterte i over hundre Ă„r. Etter Ă„ ha snakket med dem, konkluderte jeg med at lĂžsningen pĂ„ mange problemer best oppnĂ„s med relativt lavteknologiske lĂžsninger, snarere enn hĂžyteknologiske. I uker snakket jeg bare med folk fra forskjellige avdelinger. Det du ser pĂ„ det aller fĂžrste bildet i innlegget â dette var mitt siste prosjekt, rommet sĂ„ slik ut etter tre dagers arbeid.
Hva er DevOps?
Det er sant at hvis du spÞr ti forskjellige mennesker, vil de gi ti forskjellige svar. Men det interessante er at alle disse ti svarene vil vÊre riktige. Det finnes ikke noe galt svar her. Jeg har jobbet dypt med DevOps i omtrent ti Är, var den fÞrste amerikaneren pÄ den fÞrste DevOpsDay. Jeg vil ikke si at jeg er smartere enn alle som jobber med DevOps, men det er neppe noen som har investert like mye tid og krefter som jeg har. Jeg mener at DevOps oppstÄr nÄr menneskelig kapital og teknologi mÞtes. Vi glemmer ofte den menneskelige dimensjonen, selv om vi snakker mye om alle slags kulturer.
NÄ har vi mye data, fem Ärs akademisk forskning, og teoriene er blitt testet i stor skala. Denne forskningen forteller oss fÞlgende: hvis man i organisasjonskulturen forener visse atferdsmÞnstre, kan man oppnÄ en effektivitetsÞkning pÄ 2000 ganger. Denne Þkningen tilsvarer en tilsvarende forbedring i robusthet. Dette er en kvantitativ mÄling av den fordelen DevOps kan gi enhver bedrift. For et par Är siden snakket jeg om DevOps med administrerende direktÞr i et Fortune 5000-selskap. Da jeg forberedte meg til presentasjonen, var jeg veldig nervÞs, fordi jeg mÄtte oppsummere mange Ärs erfaring pÄ fem minutter.
Til slutt gav jeg fÞlgende definisjon av DevOps: det er et sett med praksiser og mÞnstre som gjÞr det mulig Ä omdanne menneskelig kapital til hÞyytelses organisasjonskapital. Et eksempel er mÄten Toyota har operert pÄ de siste 50 eller 60 Ärene.
(Her og videre er sÄdanne skemaer ikke blot til reference, men som illustration. Indholdet vil variere for hver ny virksomhed. Dog kan billedet ses separat og forstÞrres
En af de mest succesfulde praksisser er value stream mapping. Der er skrevet flere gode bÞger om dette emne, hvor den mest succesfulde forfatter er Karen Martin. Men i lÞbet af det sidste Är er jeg kommet til den konklusion, at selv denne tilgang er for hÞjteknologisk. Den har bestemt mange fordele, og jeg har haft stor gavn af den. Men nÄr administrerende direktÞr spÞrger dig, hvorfor hans virksomhed ikke kan skifte til nye spor, er det for tidligt at tale om value stream mapping. Der er mange betydeligt mere fundamentale spÞrgsmÄl, som man fÞrst skal finde svar pÄ.
Jeg mener, at mange af mine kollegaers fejl er, at de blot giver virksomheden en vejledning i fem punkter, og sÄ vender de tilbage om seks mÄneder for at se, hvad der er sket. Selv med et godt skema som value stream mapping er der, lad os sige, blinde omrÄder. Efter hundredevis af interviews med direktÞrer i forskellige virksomheder har jeg udviklet et bestemt mÞnster, der gÞr det muligt at opdele problemet i komponenter, og nu vil vi systematisk diskutere hver af disse komponenter. FÞr jeg anvender nogen teknologiske lÞsninger, bruger jeg dette mÞnster, og resultatet er, at alle mine vÊgge ender med at vÊre dÊkket af skemaer. For nylig arbejdede jeg med en investeringsfond, og jeg endte med 100-150 sÄdanne skemaer.
DĂ„rlig kultur spiser gode tilgange til morgenmad
Hovedideen er, at ingen Lean, Agile, SAFE og DevOps vil hjÊlpe, hvis selve kulturen i organisationen er dÄrlig. Det er ligesom at dykke ned uden iltflaske eller operere uden rÞntgenbillede. Med andre ord, parafraserende Drucker og Deming: en dÄrlig organisationskultur vil opsluge ethvert godt system og ikke kvÊle sig.
For at lĂžse dette hovedproblem er det nĂždvendigt at tage fĂžlgende skridt:
- GÞr alt arbejde synligt: man skal gÞre alt arbejde synligt. Ikke i den forstand, at det nÞdvendigvis skal vises pÄ en skÊrm, men at det skal vÊre observerbart.
- Konsolider arbejdsstyringssystemer: det er nÞdvendig Ä konsolidere systemene for ledelse. I problematikken med «stamme»-kunnskap og institusjonell kunnskap er mennesker ofte flaskehalsen i 9 av 10 tilfeller. I boken lÄ problemet i en enkelt person, Brent, som forÄrsaket at prosjektet ble forsinket med tre Är. Og slike «Brent» mÞter jeg overalt. For Ä lÞse disse flaskehalsene bruker jeg fÞlgende to punkter fra vÄr liste.
- Theory of Constraints Methodology: teorien om begrensninger.
- Collaboration hacks: samarbeidstriks.
- Toyota Kata (): jeg skal ikke ha mye Ä si om Toyota Kata. Hvis du er interessert, har jeg pÄ min GitHub nesten om hvert av disse emnene.
- Market Oriented Organization: markedsorientert organisasjon.
- Shift-left auditors: revisjoner i tidlige faser av syklusen.
Jeg begynner arbeidet med organisasjonen pÄ en veldig enkel mÄte: jeg gÄr inn i selskapet og snakker med de ansatte. Som vi ser, ingen hÞyteknologi. Alt som trengs, er Ä ha noe Ä skrive pÄ. Jeg samler flere team i et rom og analyserer det de sier, ut fra mine 7 arketypene. SÄ gir jeg dem en tusj og ber dem skrive ned pÄ tavlen alt de sÄ langt har sagt hÞyt. Vanligvis er det en person pÄ slike mÞter som skriver alt ned, og i beste fall klarer han Ä notere 10 % av diskusjonen. Med metoden min klarer vi Ä heve den prosentandelen til rundt 40%.
(Denne illustrasjonen kan )
Min tilnÊrming er basert pÄ arbeidet til William Schneider (William Schneider, ). Grunnideen i tilnÊrmingen er at enhver organisasjon kan deles opp i fire kvadranter. Dette diagrammet blir vanligvis resultatet av arbeidet med de hundrevis av andre diagrammene som oppstÄr nÄr man analyserer organisasjonen. La oss anta at vi har en organisasjon med hÞy kontroll, men samtidig lav kompetanse. Dette er et ekstremt uÞnsket scenario: nÄr alle fÞlger reglene, men ingen vet hva de skal gjÞre.
En bedre variant med hÞyt nivÄ av bÄde kontroll og kompetanse. Hvis et slikt selskap har fortjeneste, er det kanskje ikke nÞdvendig med DevOps. Det mest interessante er Ä jobbe med et selskap som har hÞyt nivÄ av kontroll, lav kompetanse og samarbeid, men samtidig hÞy grad av kultur (cultivation). Dette betyr at det er mange ansatte i selskapet som trives med Ä jobbe der, og omsetningen av arbeidskraft er lav.
(Denne illustrasjonen kan )
Jeg mener at metoder med strengt definerte anbefalinger i siste instans hindrer oss i Ä oppnÄ sannheten. Spesielt innen value stream mapping er det mange regler om hvordan informasjon skal struktureres. I de tidlige arbeidsfaser, som jeg snakker om, er disse reglene ikke nÞdvendige for noen. Hvis en person med en marker i hÄnden beskriver den faktiske situasjonen i selskapet pÄ en tavle, er dette den beste mÄten Ä forstÄ situasjonen pÄ. Denne informasjonen nÄr ikke direktÞrene. PÄ dette tidspunktet er det dumt Ä avbryte vedkommende og si at de har tegnet en feil pil. PÄ dette stadiet bÞr en bruke enkle regler, for eksempel at man kan skape et flernivÄ-konsept ved kun Ä bruke merkestifter med forskjellige farger.
Jeg gjentar, ingen hÞyteknologi. Med svart markeravbildes den objektive virkeligheten, hvordan alt fungerer. Med rÞd marker markerer folk hva de misliker med den nÄvÊrende situasjonen. Det er viktig at det er dem som skriver dette, og ikke jeg. NÄr jeg etter mÞtet gÄr til IT-direktÞren, tilbyr jeg ikke en liste med 10 ting som mÄ endres. Jeg prÞver Ä finne forbindelser mellom det folk i selskapet sier og eksisterende, velprÞvde mÞnstre. Til slutt foreslÄr blÄ marker mulige lÞsninger pÄ problemet.
(Denne illustrasjonen kan )
Eksempelet pÄ slik tilnÊrming er vist over. Tidlig i Är jobbet jeg med en bank. Ansatte fra sikkerhetsavdelingen var overbevist om at de ikke kunne delta pÄ krav- og designgjennomganger (design and requirement reviews).
(Denne illustrasjonen kan )
SÄ snakket vi med folk fra andre avdelinger og fant ut at for rundt 8 Är siden hadde programvareutviklerne presset ut sikkerhetsansvarlige fordi de sinket arbeidet. Og sÄ ble dette en forbudt praksis som ble oppfattet som en gitt sannhet. Selv om det i virkeligheten ikke var noe forbud.
MÞtet vÄrt utviklet seg pÄ en svÊrt forvirrende mÄte: I lÞpet av omtrent tre timer klarte fem forskjellige team ikke Ä forklare meg hva som skjer mellom koden og byggingen. Og dette, tilsynelatende, er den enkleste tingen. De fleste DevOps-konsulenter antar pÄ forhÄnd at det allerede er noe alle vet.
Deretter, personen som ansvarte for IT-styring, som hadde vÊrt stille i fire timer, blomstret plutselig opp da vi kom til hans tema, og holdt oss opptatt i betydelig tid. PÄ slutten spurte jeg ham hva han syntes om mÞtet, og jeg vil aldri glemme svaret hans. Han sa: «Tidligere trodde jeg at det var to mÄter Ä levere programvare pÄ i banken vÄr, men nÄ vet jeg at det er hele fem, og jeg var ikke engang klar over tre av dem».
(Denne illustrasjonen kan )
Det siste mÞtet i denne banken var med teamet som jobber med programvare for investeringer. Det ble klart at det er bedre Ä tegne diagrammer med tusj pÄ papir enn pÄ en tavle, og til og med bedre enn pÄ en smarttavle.
Bildene dere ser â dette er hvordan konferanserommet pĂ„ hotellet sĂ„ ut den fjerde dagen av mĂžtet vĂ„rt. Og disse diagrammene brukte vi til Ă„ lete etter mĂžnstre, altsĂ„ arketypene.
SÄ jeg stiller spÞrsmÄl til de ansatte, de noterer svarene med tusjer i tre farger (svart, rÞdt og blÄtt). Jeg analyserer svarene deres for arketypene. NÄ la oss diskutere alle arketypene i rekkefÞlge.
1. Make All Work Visible: GjĂžr alt arbeid synlig
I de fleste selskaper jeg jobber med, er det en veldig hĂžy prosentandel av ukjent arbeid. For eksempel nĂ„r en ansatt ber en annen om Ă„ gjĂžre noe. I store organisasjoner kan det vĂŠre 60% uplanlagt arbeid. Og opp til 40% av arbeidet er aldri dokumentert. Hvis det var Boeing, ville jeg aldri mer satt foten i et av deres fly. Hvis bare halvparten av arbeidet dokumenteres, er det uklart om arbeidet utfĂžres riktig eller ikke. Alle andre metoder blir unyttige â det gir ikke mening Ă„ prĂžve Ă„ automatisere noe, fordi de kjente 50% kan vĂŠre den mest koordinerte og presise delen av arbeidet, automatisering av som ikke gir store resultater, mens alt det mest grufulle ligger i den usynlige halvdelen. Uten dokumentasjon er det umulig Ă„ finne alle slags hacks og skjult arbeid, Ă„ identifisere flaskehalser, de sĂ„kalte «Brentene» jeg allerede har nevnt. Det er en flott bok av Dominica DeGrandis. . Den avdekker fem forskjellige «tidstyver» (thieves of time):
- For mye arbeid i prosess (WIP)
- Ukjente avhengigheter
- Uplanlagt arbeid
- Motstridende prioriteringer
- Negliserte oppgaver
Dette er en svÊrt verdifull analyse, og boken er fantastisk, men alle disse rÄdene er nyttelÞse hvis bare 50% av dataene er synlige. Metodene foreslÄtt av Dominica kan brukes sÄ lenge nÞyaktigheten er over 90%. Jeg snakker om situasjoner der en sjef gir en underordnet en 15-minutters oppgave, som tar tre dager; men sjefen vet faktisk ikke at den underordnede er avhengig av fire eller fem andre personer.
Phoenix Project er en fantastisk fortelling om et prosjekt som var tre Är forsinket. En av heltene stÄr i fare for Ä miste jobben pÄ grunn av dette, og han mÞter en annen karakter som fremstÄr som en slags Sokrates. Denne hjelper ham med Ä forstÄ hva som egentlig gikk galt. Det viser seg at det er en systemadministrator i selskapet som heter Brent, og alt arbeid gÄr pÄ en eller annen mÄte gjennom ham. PÄ et av mÞtene blir en av underordnede spurt: hvorfor tar hver halvtime med oppgaver en uke? Svaret er en veldig forenklet fremstilling av kÞteori og Little's lov, hvor det viser seg at ved 90 % belÊgning tar hver arbeidet time 9 timer. Hver oppgave mÄ sendes til syv andre personer, sÄ denne timen blir til 63 timer, 7 ganger 9. Jeg sier dette fordi for Ä bruke Little's lov eller noen som helst komplisert kÞteori, mÄ man i det minste ha data.
Derfor nÄr jeg snakker om synlighet, mener jeg ikke at alt mÄ vÊre pÄ skjermen, men at man i det minste mÄ ha data. NÄr de er tilgjengelige, viser det seg ofte at det er en stor mengde uplanlagt arbeid som av en eller annen grunn sendes til Brent, selv om det ikke er noe behov for det. Brent er en flott fyr, han sier aldri «nei», men han forteller ingen hvordan han gjÞr jobben sin.
NÄr arbeidet er synlig, kan man systematisk klassifisere dataene (det er akkurat det Dominika gjÞr pÄ bildet), man kan bruke abstraksjonen av de fem tidstyvene og automatisere.
2. Konsolider arbeidsstyringssystemer: Oppgavestyring
Arketypene jeg snakker om, danner en slags pyramide. Hvis det fĂžrste er utfĂžrt riktig, blir det andre en slags overbygning. Mange av dem fungerer ikke for oppstartsbedrifter, de mĂ„ vurderes i tilfelle stĂžrre selskaper, som de som kommer pĂ„ Fortune 5000-listen. I det siste selskapet jeg jobbet for, var det 10 feilsporing systemer (ticketing system). Ăn gruppe brukte Remedy, en annen laget sitt eget system, en tredje benyttet Jira, og noen klarte seg med e-post. Det samme problemet oppstĂ„r hvis et selskap har 30 forskjellige arbeidsflyter, men jeg har ikke tid til Ă„ diskutere alle slike tilfeller.
Eg diskuterer med folk hvordan billettene opprettes, hva som skjer med dem videre, og hvordan de unngÄs. Det mest interessante er at folk pÄ vÄre mÞter snakker ganske Äpent. Jeg spurte hvor mange som setter "mindre / ingen pÄvirkning" pÄ billetter som egentlig burde tildeles "stor pÄvirkning". Det viste seg at nesten alle gjÞr slik. Jeg driver ikke med angiveri og prÞver pÄ alle mÄter Ä ikke avdekke folk. NÄr jeg fÄr en oppriktig bekjennelse, avslÞrer jeg ikke personen. Men nÄr nesten alle unngÄr systemet, betyr det at all sikkerheten, i realiteten, bare er en dekore. Derfor kan ingen konklusjoner trekkes fra dataene i dette systemet.
For Ä lÞse problemet med billetter, er det nÞdvendig Ä velge ett hovedsystem. Hvis du bruker Jira, skal det vÊre bare Jira. Hvis det finnes et alternativ, skal det ogsÄ vÊre det eneste. Poenget er at billetter mÄ betraktes som et nytt trinn i utviklingsprosessen. Hver handling mÄ ha en billett som gÄr gjennom arbeidsprosessen for utvikling. Billetter blir sendt til teamet, som legger dem pÄ storyboard, og deretter tar ansvar for dem.
Dette gjelder for alle avdelinger, inkludert infrastruktur- og operasjonsavdelingen. I sÄ fall kan det lages en mer eller mindre troverdig representasjon av situasjonen. NÄr denne prosessen er pÄ plass, viser det seg plutselig at man lett kan fastslÄ hvem som er ansvarlig for hver applikasjon. For nÄ fÄr vi ikke 50%, men 98% nye tjenester. Hvis den grunnleggende prosessen fungerer, Þker nÞyaktigheten i hele systemet.
Pipeline av tjenester
Dette gjelder igjen kun store selskaper. Hvis du er et nytt selskap i et nytt omrĂ„de â rull opp ermene og arbeid med din Travis CI eller CircleCI. NĂ„r det kommer til Fortune 5000-selskaper, er tilfellet med banken jeg jobbet i, beskrivende. De fikk besĂžk fra Google som viste dem diagrammer fra gamle IBM-systemer. Guttene fra Google spurte med forvirring â men hvor er kildekoden for dette? Det er ingen kildekode, det finnes ikke engang et GUI. Denne virkeligheten er noe store organisasjoner mĂ„ forholde seg til: 40 Ă„r gamle bankoppfĂžringer pĂ„ en gammel mainframe. En av mine kunder bruker Kubernetes-containere med Circuit Breaker-mĂžnstre, pluss Chaos Monkey, alt dette for KeyBank-applikasjonen. Men til slutt kobles disse containerne til en COBOL-applikasjon.
Guttene fra Google var helt sikre pÄ at de skulle lÞse alle problemene til kunden min, men sÄ begynte de Ä stille spÞrsmÄl: hva er IBM datapipe? De fikk svaret: det er en tilkobling. Hva kobles den til? Til Sperry-systemet. Og hva er det? Og sÄ videre. Ved fÞrste Þyekast ser det ut som det ikke er noe DevOps her. Men i realiteten er det mulig. Det finnes leveringssystemer som gjÞr det mulig Ä overfÞre arbeidsflyt til leveringsgruppene.
3. Theory of Constraints: Teorien om begrensninger
La oss gÄ videre til den tredje arketypen: institusjonell / «stamme»-kunnskap. Generelt finnes det i enhver organisasjon noen personer som vet alt og har kontroll over alt. Det er de som har vÊrt lengst i organisasjonen og som kjenner alle snarveiene.
NÄr dette avdekkes pÄ diagrammet, omgir jeg spesifikt slike mennesker med en markÞr: for eksempel viser det seg at en viss Lou er til stede pÄ alle mÞter. Og for meg er det klart: dette er den lokale Brent. NÄr IT-direktÞren velger mellom meg i t-skjorte og joggesko, og en fyr i dress fra IBM, velges jeg fordi jeg kan fortelle direktÞren om ting som den andre fyren ikke vil fortelle, og som kan vÊre ubehagelige for direktÞren Ä hÞre om. Jeg forteller dem at det er et flaskehals i deres selskap, noen ved navn Fred og noen ved navn Lou. Denne flaskehalsen mÄ oppheves, og deres kunnskap mÄ pÄ en eller annen mÄte utvinnes fra dem.
For solving such a problem, I might suggest using Slack, for example. A savvy director would ask, why? Typically, in such cases, DevOps consultants respond: because everyone does it. If the director is truly savvy, they'll say, so what. And thatâs where the dialogue ends. To this, I would respond: because there are four bottlenecks in the company, Fred, Lou, Suzy, and Jane. To institutionalize their knowledge, we first need to implement Slack. All your wikis are complete nonsense because no one knows they exist. If the engineering team is working on both external and internal development, everyone should know that they can reach out to the external development team or the infrastructure team with questions. Thatâs when Lou or Fred will likely have time to engage with the wiki. Then someone might ask in Slack why step 5 isnât working, for example. At that point, Lou or Fred would fix the instruction in the wiki. Once this process is established, many other things will fall into place.
This is my main point: to recommend any high-end technology, you first need to establish a foundation for it, and this can only be done with the low-tech solutions I just described. If you start with high-end technology without explaining why it's needed, it usually doesnât end well. One of our clients uses Azure ML, which is a very cheap and simple solution. About 30% of their queries were already answered by the self-learning machine. And it was created by operators who had no experience in data science, statistics, or mathematics. This is telling. The cost of such a solution is minimal.
4. Collaboration hacks: Hacking cooperation
Den fjerde arketypen handler om Ă„ bekjempe isolasjon. De fleste vet allerede dette: isolasjon skaper fiendskap. Hvis hver avdeling er pĂ„ sitt egne etasje, og folk ikke mĂžter hverandre annet enn i heisen, er det veldig lett for fiendskap Ă„ oppstĂ„. Men hvis folk derimot er i samme rom, forsvinner det straks. NĂ„r noen kommer med en generell anklage, for eksempel at et bestemt grensesnitt aldri fungerer â er det ikke noe enklere enn Ă„ avkrefte en slik anklage. Programmererne som har skrevet grensesnittet, trenger bare Ă„ begynne Ă„ stille konkrete spĂžrsmĂ„l, sĂ„ vil det snart vise seg at brukeren for eksempel bare har brukt verktĂžyet feil.
Det finnes mange mÄter Ä overvinne isolasjon pÄ. Jeg ble en gang bedt om Ä rÄdgive en bank i Australia, men takket nei fordi jeg har to barn og en kone. Alt jeg kunne hjelpe dem med var Ä anbefale dem Ä bruke grafisk historiefortelling. Dette er noe som beviselig fungerer. En annen interessant metode er Ä ha lean coffee-mÞter. I en stor organisasjon er dette et utmerket alternativ for kunnskapsdeling. I tillegg kan man arrangere interne devopsdays, hackathons og sÄ videre.
5. Coaching Kata
Som jeg allerede advarte om i begynnelsen, skal jeg ikke snakke om dette i dag. Hvis du er interessert, kan du se pÄ .
Det er ogsÄ en god presentasjon om dette emnet fra Mike Rother:
6. Markedsorientert: en organisasjon som er orientert mot markedet
Her er det ulike problemer. For eksempel folk som "I", folk som "T" og folk som "E". Folk som "I" er de som kun fokuserer pĂ„ Ă©n ting. De eksisterer vanligvis i organisasjoner med isolerte avdelinger. "T" er nĂ„r en person kjenner Ă©n ting godt, men ogsĂ„ er dyktig i flere andre ting. "E" eller til og med "kam" â det er nĂ„r en person har mange ferdigheter.
Her gjelder Conways lov (), som i sin mest forenklede form kan uttrykkes slik: hvis tre team jobber med en kompilator, vil det resultere i en kompilator delt opp i tre deler. Derfor, hvis det internt i organisasjonen er et hÞyt nivÄ av isolasjon, vil til og med Kubernetes, Circuit breaker, API extensibility og andre trendy ting i denne organisasjonen vÊre strukturert slik som selve organisasjonen. Strengt etter Conway, til tross for alt dere unge nerder.
LĂžysinga pĂ„ dette problemet har blitt omtalt mange gonger. Det er for eksempel organisatoriske arketypa beskriven av Fernando Fernandez. Den problematiske arkitekturen eg nettopp snakka om, med isolasjon â det er ein funksjonelt orientert arkitektur. Den andre typen â den verste, er matrisearkitekturen, der er det ein graut av dei to andre. Den tredje â er det som vert observert i dei fleste oppstartar, og store selskap prĂžver ogsĂ„ Ă„ tilpasse seg denne typen. Det er ei marknadsorientert organisasjon. Her skjer det ei optimalisering for Ă„ oppnĂ„ det raskaste svaret pĂ„ kundens forespĂžrselar. Dette blir av og til kalla ei flat organisasjon.
Mange beskriver denne strukturen pĂ„ ulike mĂ„tar, eg likar formuleringa build/run teams, i Amazon kallar dei det two pizza teams. I denne strukturen blir alle personer av type «I» grupperte rundt ein teneste, og gradvis blir dei nĂŠrmare type «T», og dersom det er etablert god leiing, kan dei til og med bli «E». Det fĂžrste motargumentet her â er at det i ein slik struktur er unĂždvendige element. Kvifor trengs det ein tester i kvar avdeling, nĂ„r ein kan ha eit spesialiserte testingsteam? Til det svarar eg: unĂždvendige kostnader i dette tilfellet er prisen for at heile organisasjonen i framtida skal bli type «E». I ein slik struktur lĂŠrer testaren gradvis om nettverk, arkitektur, design osv. Til slutt blir kvar deltakar i organisasjonen heilt informert om alt som skjer i organisasjonen. Dersom du vil vite korleis denne modellen fungerer i industrien, les .
7. Shift-left auditores: revisjon pÄ tidlege stadium i syklusen. Overholding av sikkerheitsreglane pÄ vis
Dette er nÄr handlingene dine, pÄ en mÄte, ikke klarer lukttesten. Folkene som jobber for deg, er ikke dumme. Hvis de, som i eksempelet ovenfor, hele tiden ga minor/no impact, og dette fortsatte i tre Är uten at noen merket noe, sÄ vet alle at systemet ikke fungerer. Et annet eksempel er endringsrÄdet, hvor hver onsdag mÄ man levere rapporter. Der jobber det en gruppe mennesker (forresten ikke veldig godt betalte), som i teorien burde vite hvordan systemet fungerer som helhet. Over de siste fem Ärene, har du sikkert lagt merke til at systemene vÄre er vanvittig komplekse. Fem eller seks personer mÄ ta beslutninger om endringer de ikke har gjort og som de ikke vet noe om.
SelvfÞlgelig fungerer ikke denne tilnÊrmingen. Jeg mÄ kvitte meg med slike ting, fordi de personene ikke beskytter systemet. Beslutningen mÄ tas av teamet selv, fordi teamet mÄ vÊre ansvarlig for den. Ellers oppstÄr det en paradoksal situasjon, hvor en manager, som aldri har skrevet kode i sitt liv, forteller programmereren hvor lang tid det skal ta Ä skrive koden. I et selskap jeg jobbet med, var det syv forskjellige rÄd som vurderte hver endring, inkludert arkitektur- og produkt rÄdgivning, osv. Det var til og med en obligatorisk ventetid, selv om en ansatt sa til meg at i lÞpet av ti Är har ingen noen gang avvist endringene fra denne personen i denne obligatoriske perioden.
Revisorer bĂžr inviteres til samarbejde i stedet for at blive undgĂ„et. FortĂŠl dem, at du skriver immutable binĂŠre containere, som forbliver uĂŠndrede for always, hvis de bestĂ„r alle tests. FortĂŠl dem, at du har pipeline as code, og forklar, hvad det betyder. Vis dem fĂžlgende skema: en immutable binĂŠr kun til lĂŠsning i en container, der bestĂ„r alle sĂ„rbarhedstests; og dernĂŠst rĂžrer ingen ikke bare ved det â ikke engang ved systemet, der opretter pipeline'en, da det ogsĂ„ oprettes dynamisk. Jeg har kunder, Capital One, der ved hjĂŠlp af Vault skaber noget, der ligner en blockchain. Revisoren behĂžver ikke at fĂ„ vist ârezepteâ fra Chef, det er nok at vise blockchainen, der klart viser, hvad der skete med Jira-billetterne i produktionen, og hvem der er ansvarlig for dem.
I henhold til , der blev oprettet i 2018, var der 87 milliarder OSS-downloadanmodninger i 2017.
Tabene som fÞlge af sÄrbarheder viser sig at vÊre uoverkommelige hÞje. Desuden tÊller de tal, du ser ovenfor, ikke de alternative omkostninger. En kort forklaring pÄ, hvad DevSecOps er. Jeg vil straks sige, at jeg ikke er interesseret i diskussioner om, hvor godt dette navn er. Pointen er, at fordi DevOps har vÊret meget succesfulde, er det nÞdvendigt at forsÞge at tilfÞje sikkerhed til denne pipeline.
Et eksempel pÄ en sÄdan sekvens:
Dette er ikke en anbefaling af specifikke produkter, selvom jeg kan lide dem alle. Jeg har nÊvnt dem som et eksempel for at vise, at DevOps, der oprindeligt er baseret pÄ en industriorganisation, muliggÞr automatisering af hvert trin i produktudviklingen.
Og der er ingen grund til, at vi ikke skulle kunne anvende den samme tilgang til sikkerhed.
Resultat
Som en avslutning vil jeg gi noen rĂ„d til DevSecOps. Inkluder revisorer i prosessen med Ă„ bygge systemene deres, og bruk tid pĂ„ Ă„ utdanne dem. Det er viktig Ă„ samarbeide med revisorer. Videre er det nĂždvendig Ă„ fĂžre en absolutt nĂ„delĂžs kamp mot falske alarmer. Selv med det dyreste verktĂžyet for sĂ„rbarhetsskanning kan man ende opp med Ă„ danne ekstremt skadelige vaner hos utviklerne, hvis man ikke vet forholdet mellom signal og stĂžy. Utviklerne vil bli overveldet av hendelser og vil begynne Ă„ slette dem. Hvis du har hĂžrt om historien med Equifax, skjedde nettopp dette, hvor signalet med hĂžyeste fare ble ignorert. I tillegg mĂ„ sĂ„rbarheter forklares pĂ„ en mĂ„te som gjĂžr det klart hvordan de pĂ„virker forretningen. For eksempel kan man si at dette er den samme sĂ„rbarheten som i historien om Equifax. Sikkerhetsrelaterte sĂ„rbarheter mĂ„ behandles pĂ„ samme mĂ„te som andre programvareproblemer, dvs. de mĂ„ integreres i den generelle DevOps-prosessen. De mĂ„ hĂ„ndteres gjennom Jira, Kanban, osv. Utviklerne mĂ„ ikke tro at dette vil bli gjort av noen andre â tvert imot, dette er noe som alle mĂ„ ta ansvar for. Til slutt mĂ„ man bruke ressurser pĂ„ Ă„ utdanne folk.
Nyttige lenker
Her er noen foredrag fra DevOops-konferansen som kan vĂŠre nyttige for deg:
- Sergie Berdnikov, Artyom Kalichkin â Succes Historie, eller «Dev+DevOps+Ops» (, )
- Baruch Sadogursky, Leonid Igolnik â DevOps i stor skala: en gresk tragedie i tre akter (, )
- Alexander Titov, Kirill Tolkachev â
- Timothy Lister â
Sjekk ut DevOops 2020 Moskva â det er ogsĂ„ mange interessante saker der.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish