Anton Weiss, grunnlegger og direktør for Otomato Software, en av initiativtakerne og instruktørene til den første DevOps-sertifiseringen i Israel, talte på fjorårets om kaosteori og hovedprinsippene for kaosteknikk, og forklarte også hvordan fremtidens ideelle DevOps-organisasjon fungerer.
Vi har utarbeidet en tekstversjon av rapporten.
God morgen!
DevOpsDays i Moskva for andre år på rad, dette er min andre gang på denne scenen, mange av dere er i dette rommet for andre gang. Hva betyr det? Dette betyr at DevOps-bevegelsen i Russland vokser, formerer seg, og viktigst av alt betyr det at tiden er inne for å snakke om hva DevOps er i 2018.
Rekk opp hendene som tror at DevOps allerede er et yrke i 2018? Det finnes slike. Er det noen DevOps-ingeniører i rommet hvis stillingsbeskrivelse sier "DevOps Engineer"? Er det noen DevOps-administratorer i rommet? Det finnes ikke noe slikt. DevOps-arkitekter? Også nei. Ikke nok. Er det virkelig sant at ingen sier de er DevOps-ingeniører?
Så de fleste av dere tror dette er et antimønster? At et slikt yrke ikke skulle eksistere? Vi kan mene hva vi vil, men mens vi tenker, går bransjen høytidelig fremover til lyden av DevOps-trompeten.
Hvem har hørt om et nytt emne kalt DevDevOps? Dette er en ny teknikk som muliggjør effektivt samarbeid mellom utviklere og devops. Og ikke så ny. Etter Twitter å dømme begynte de allerede å snakke om dette for 4 år siden. Og til nå vokser og vokser interessen for dette, det vil si at det er et problem. Problemet må løses.
Vi er kreative mennesker, vi er ikke bare rolige. Vi sier: DevOps er ikke et omfattende nok ord; det mangler fortsatt alle slags forskjellige, interessante elementer. Og vi går til våre hemmelige laboratorier og begynner å produsere interessante mutasjoner: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logikken er jernbelagt, ikke sant? Vårt leveringssystem er ikke funksjonelt, våre systemer er ustabile og våre brukere er misfornøyde, vi har ikke tid til å rulle ut programvare i tide, vi passer ikke inn i budsjettet. Hvordan skal vi løse alt dette? Vi kommer med et nytt ord! Det vil ende med "Ops" og problemet er løst.
Så jeg kaller denne tilnærmingen - "Ops, og problemet er løst."
Alt dette går i bakgrunnen hvis vi minner oss selv på hvorfor vi kom på alt dette. Vi kom opp med hele denne DevOps-tingen for å gjøre programvarelevering og vårt eget arbeid i denne prosessen så uhindret, smertefritt, effektivt og viktigst av alt, morsomt som mulig.
DevOps vokste ut av smerte. Og vi er lei av lidelse. Og for at alt dette skal skje, er vi avhengige av eviggrønne praksiser: effektivt samarbeid, flytpraksis, og viktigst av alt, systemtenkning, for uten det fungerer ingen DevOps.
Hva er systemet?
Og hvis vi allerede snakker om systemtenkning, la oss minne oss selv på hva et system er.
Hvis du er en revolusjonerende hacker, så er systemet helt klart ondt for deg. Det er en sky som henger over deg og tvinger deg til å gjøre ting du ikke vil.
Fra systemtenkningens synspunkt er et system en helhet som består av deler. I denne forstand er hver av oss et system. Organisasjonene vi jobber i er systemer. Og det du og jeg bygger kalles et system.
Alt dette er en del av ett stort sosioteknologisk system. Og bare hvis vi forstår hvordan dette sosioteknologiske systemet fungerer sammen, først da vil vi virkelig kunne optimalisere noe i denne saken.
Fra et systemtenkende perspektiv har et system ulike interessante egenskaper. For det første består den av deler, noe som betyr at dens oppførsel avhenger av oppførselen til delene. Dessuten er alle delene også avhengige av hverandre. Det viser seg at jo flere deler et system har, desto vanskeligere er det å forstå eller forutsi oppførselen.
Fra et atferdsmessig synspunkt er det et annet interessant faktum. Systemet kan gjøre noe som ingen av dets individuelle deler kan gjøre.
Som Dr. Russell Ackoff (en av grunnleggerne av systemtenkning) sa, er dette ganske enkelt å bevise med et tankeeksperiment. For eksempel, hvem i rommet vet hvordan man skriver kode? Det er mange hender, og dette er normalt, fordi dette er et av hovedkravene til yrket vårt. Vet du hvordan du skriver, men kan hendene dine skrive kode separat fra deg? Det er folk som vil si: "Det er ikke hendene mine som skriver koden, det er hjernen min som skriver koden." Kan hjernen din skrive kode separat fra deg? Vel, sannsynligvis ikke.
Hjernen er en fantastisk maskin, vi vet ikke engang 10% av hvordan den fungerer der, men den kan ikke fungere separat fra systemet som er kroppen vår. Og dette er lett å bevise: åpne skallen din, ta ut hjernen din, legg den foran datamaskinen, la ham prøve å skrive noe enkelt. «Hello, world» i Python, for eksempel.
Hvis et system kan gjøre noe som ingen av delene kan gjøre separat, betyr dette at dets oppførsel ikke bestemmes av oppførselen til delene. Hva er det da bestemt av? Det bestemmes av samspillet mellom disse delene. Og følgelig, jo flere deler, jo mer komplekse interaksjoner er, desto vanskeligere er det å forstå og forutsi systemets oppførsel. Og dette gjør et slikt system kaotisk, fordi enhver, selv den mest ubetydelige, usynlige endringen i noen del av systemet kan føre til helt uforutsigbare resultater.
Denne følsomheten for startforholdene ble først oppdaget og studert av den amerikanske meteorologen Ed Lorenz. Deretter ble det kalt "sommerfugleffekten" og førte til utviklingen av en bevegelse av vitenskapelig tanke kalt "kaosteori." Denne teorien ble et av de store paradigmeskiftene i det 20. århundres vitenskap.
Kaos teori
Folk som studerer kaos kaller seg kaosologer.
Egentlig var grunnen til denne rapporten at jeg, ved å jobbe med komplekse distribuerte systemer og store internasjonale organisasjoner, på et tidspunkt innså at det var denne jeg føler for. Jeg er en kaosolog. Dette er i utgangspunktet en smart måte å si: "Jeg forstår ikke hva som skjer her, og jeg vet ikke hva jeg skal gjøre med det."
Jeg tror at mange av dere også ofte har det slik, så dere er også kaosologer. Jeg inviterer deg til kaosologlauget. Systemene som du og jeg, kjære medkaosologer, vil studere kalles "komplekse adaptive systemer."
Hva er tilpasningsevne? Tilpasningsevne betyr at den individuelle og kollektive atferden til deler i et slikt adaptivt system endrer seg og selvorganiserer, reagerer på hendelser eller kjeder av mikrohendelser i systemet. Det vil si at systemet tilpasser seg endringer gjennom selvorganisering. Og denne evnen til selvorganisering er basert på frivillig, fullstendig desentralisert samarbeid mellom frie autonome agenter.
En annen interessant egenskap ved slike systemer er at de er fritt skalerbare. Hva bør utvilsomt interessere oss, som kaosologer-ingeniører. Så hvis vi sa at oppførselen til et komplekst system bestemmes av samspillet mellom dets deler, hva bør vi da være interessert i? Interaksjon.
Det er ytterligere to interessante funn.
For det første forstår vi at et komplekst system ikke kan forenkles ved å forenkle dets deler. For det andre er den eneste måten å forenkle et komplekst system ved å forenkle samspillet mellom dets deler.
Hvordan samhandler vi? Du og jeg er alle deler av et stort informasjonssystem kalt menneskelig samfunn. Vi samhandler gjennom et felles språk, hvis vi har det, hvis vi finner det.
Men språket i seg selv er et komplekst adaptivt system. Følgelig, for å samhandle mer effektivt og enkelt, må vi lage en slags protokoller. Det vil si en sekvens av symboler og handlinger som vil gjøre utvekslingen av informasjon mellom oss enklere, mer forutsigbar, mer forståelig.
Jeg vil si at trender mot kompleksitet, mot tilpasningsevne, mot desentralisering, mot kaos kan spores i alt. Og i systemene som du og jeg bygger, og i de systemene vi er en del av.
Og for ikke å være ubegrunnet, la oss se på hvordan systemene vi lager endrer seg.
Du ventet på dette ordet, forstår jeg. Vi er på en DevOps-konferanse, i dag vil dette ordet bli hørt rundt hundre tusen ganger og så drømmer vi om det om natten.
Mikrotjenester er den første programvarearkitekturen som dukket opp som en reaksjon på DevOps-praksis, som er designet for å gjøre systemene våre mer fleksible, mer skalerbare og sikre kontinuerlig levering. Hvordan gjør hun dette? Ved å redusere volumet av tjenester, redusere omfanget av problemer som disse tjenestene behandler, redusere leveringstiden. Det vil si at vi reduserer og forenkler deler av systemet, øker antallet, og følgelig øker kompleksiteten av interaksjoner mellom disse delene alltid, det vil si at det oppstår nye problemer som vi må løse.
Mikrotjenester er ikke slutten, mikrotjenester er generelt allerede i går, fordi Serverless kommer. Alle servere brent ned, ingen servere, ingen operativsystemer, bare ren kjørbar kode. Konfigurasjoner er separate, tilstander er separate, alt styres av hendelser. Skjønnhet, renslighet, stillhet, ingen hendelser, ingenting skjer, fullstendig orden.
Hvor er kompleksiteten? Vanskeligheten ligger selvfølgelig i interaksjonene. Hvor mye kan en funksjon gjøre alene? Hvordan samhandler den med andre funksjoner? Meldingskøer, databaser, balansere. Hvordan gjenskape en hendelse når en feil oppstod? Mange spørsmål og få svar.
Microservices og Serverless er det vi nerdehipstere kaller Cloud Native. Alt handler om skyen. Men skyen er også iboende begrenset i sin skalerbarhet. Vi er vant til å tenke på det som et distribuert system. Faktisk, hvor bor skyleverandørenes servere? I datasentre. Det vil si at vi har en slags sentralisert, veldig begrenset, distribuert modell her.
I dag forstår vi at tingenes internett ikke lenger bare er store ord som selv ifølge beskjedne spådommer venter milliarder av enheter koblet til Internett på oss i løpet av de neste fem til ti årene. En enorm mengde nyttige og ubrukelige data som vil bli slått sammen til skyen og lastet opp fra skyen.
Skyen vil ikke vare, så vi snakker i økende grad om noe som kalles edge computing. Eller jeg liker også den fantastiske definisjonen av "fog computing". Den er innhyllet i romantikkens og mystikkens mystikk.
Tåkedatabehandling. Poenget er at skyer er sentraliserte klumper av vann, damp, is og steiner. Og tåke er vanndråper som er spredt rundt oss i atmosfæren.
I tåkeparadigmet gjøres mesteparten av arbeidet av disse dråpene helt autonomt eller i samarbeid med andre dråper. Og de vender seg til skyen først når de virkelig blir presset.
Det vil si igjen desentralisering, autonomi, og selvfølgelig forstår mange av dere allerede hvor alt dette går, fordi dere ikke kan snakke om desentralisering uten å nevne blokkjeden.
Det er de som tror, dette er de som har investert i kryptovaluta. Det er de som tror, men er redde, som meg for eksempel. Og det er de som ikke tror. Her kan du behandle annerledes. Det er teknologi, en ny ukjent sak, det er problemer. Som all ny teknologi, reiser den flere spørsmål enn den svarer.
Hypen rundt blockchain er forståelig. Gullrushet til side, teknologien i seg selv har bemerkelsesverdige løfter for en lysere fremtid: mer frihet, mer autonomi, distribuert global tillit. Hva er det man ikke vil?
Følgelig begynner flere og flere ingeniører rundt om i verden å utvikle desentraliserte applikasjoner. Og dette er en kraft som ikke kan avvises ved bare å si: "Ahh, blockchain er bare en dårlig implementert distribuert database." Eller som skeptikere liker å si: "Det finnes ingen reelle applikasjoner for blockchain." Hvis du tenker på det, for 150 år siden sa de det samme om elektrisitet. Og de hadde til og med rett på noen måter, for det elektrisitet gjør mulig i dag var på ingen måte mulig på 19-tallet.
Forresten, hvem vet hva slags logo som er på skjermen? Dette er Hyperledger. Dette er et prosjekt som utvikles i regi av The Linux Foundation og inkluderer et sett med blokkjedeteknologier. Dette er virkelig styrken til vårt åpen kildekodesamfunn.
Kaosteknikk
Så systemet vi utvikler blir mer og mer komplekst, mer og mer kaotisk og mer og mer tilpasningsdyktig. Netflix er pionerer innen mikroservicesystemer. De var blant de første som forsto dette, de utviklet et sett med verktøy de kalte Simian Army, hvorav det mest kjente var . Han definerte det som ble kjent som .
Forresten, i prosessen med å jobbe med rapporten, oversatte vi til og med denne teksten til russisk, så gå til , lese, kommentere, skjelle ut.
Kort fortalt sier prinsippene for kaosteknikk følgende. Komplekse distribuerte systemer er iboende uforutsigbare og iboende buggy. Feil er uunngåelige, noe som betyr at vi må akseptere disse feilene og jobbe med disse systemene på en helt annen måte.
Vi må selv prøve å introdusere disse feilene i våre produksjonssystemer for å teste systemene våre for den samme tilpasningsevnen, nettopp denne evnen til selvorganisering, for overlevelse.
Og det endrer alt. Ikke bare hvordan vi lanserer systemer i produksjon, men også hvordan vi utvikler dem, hvordan vi tester dem. Det er ingen prosess med stabilisering eller frysing av koden, tvert imot er det en konstant prosess med destabilisering. Vi prøver å drepe systemet og se at det fortsetter å overleve.
Distribuerte systemintegrasjonsprotokoller
Følgelig krever dette at systemene våre på en eller annen måte endres. For at de skal bli mer stabile, trenger de noen nye protokoller for interaksjon mellom delene deres. Slik at disse delene kan bli enige og komme til en slags selvorganisering. Og alle slags nye verktøy, nye protokoller oppstår, som jeg kaller "protokoller for samspillet mellom distribuerte systemer."
Hva snakker jeg om? Først prosjektet . Noen prøver å lage en generell distribuert sporingsprotokoll, som er et helt uunnværlig verktøy for å feilsøke komplekse distribuerte systemer.
Lengre - . Vi sier at vi ikke kan forutsi hva som vil skje med systemet, det vil si at vi må øke dets observerbarhet, observerbarhet. Opentracing tilhører en familie av verktøy som gir observerbarhet til systemene våre. Men vi trenger observerbarhet for å avgjøre om systemet oppfører seg slik vi forventer det skal eller ikke. Hvordan definerer vi forventet atferd? Ved å definere en slags politikk, et sett med regler. Open Policy Agent-prosjektet jobber med å definere dette settet med regler på tvers av et spekter som strekker seg fra tilgang til ressursallokering.
Som vi sa er systemene våre stadig mer hendelsesdrevne. Serverless er et godt eksempel på hendelsesdrevne systemer. For at vi skal overføre hendelser mellom systemer og spore dem, trenger vi et felles språk, en felles protokoll for hvordan vi snakker om hendelser, hvordan vi overfører dem til hverandre. Dette er hva et prosjekt kalt .
Den konstante strømmen av endringer som skyller over systemene våre, som stadig destabiliserer dem, er en kontinuerlig strøm av programvareartefakter. For at vi skal kunne opprettholde denne konstante flyten av endringer, trenger vi en slags felles protokoll der vi kan snakke om hva en programvareartefakt er, hvordan den er testet, hvilken verifisering den har bestått. Dette er hva et prosjekt kalt . Det vil si en vanlig metadataprotokoll for programvareartefakter.
Og til slutt, hvis vi vil at systemene våre skal være helt uavhengige, adaptive og selvorganiserte, må vi gi dem rett til selvidentifikasjon. Prosjekt kalt Det er akkurat det han gjør. Dette er også et prosjekt i regi av Cloud Native Computing Foundation.
Alle disse prosjektene er unge, de trenger alle vår kjærlighet, vår validering. Alt dette er åpen kildekode, vår testing, vår implementering. De viser oss hvor teknologien er på vei.
Men DevOps har aldri først og fremst handlet om teknologi, det har alltid handlet om samarbeid mellom mennesker. Og følgelig, hvis vi vil at systemene vi utvikler skal endres, så må vi selv endre. Faktisk endrer vi oss uansett; vi har ikke mye valg.
Det er en fantastisk Den britiske forfatteren Rachel Botsman, der hun skriver om utviklingen av tillit gjennom menneskets historie. Hun sier at til å begynne med, i primitive samfunn, var tillit lokal, det vil si at vi stolte bare på dem vi kjente personlig.
Så var det en veldig lang periode – en mørk tid da tilliten ble sentralisert, da vi begynte å stole på folk som vi ikke kjenner på bakgrunn av at vi tilhører samme offentlige eller statlige institusjon.
Og dette er hva vi ser i vår moderne verden: tillit blir mer og mer distribuert og desentralisert, og den er basert på friheten til informasjonsflyt, på tilgjengeligheten av informasjon.
Hvis du tenker deg om, er nettopp denne tilgjengeligheten, som gjør denne tilliten mulig, det du og jeg implementerer. Det betyr at både måten vi samarbeider på og måten vi gjør det på må endres, fordi gamle sentraliserte, hierarkiske IT-organisasjoner ikke lenger fungerer. De begynner å dø.
Grunnleggende om DevOps-organisasjonen
Fremtidens ideelle DevOps-organisasjon er et desentralisert, adaptivt system sammensatt av autonome team, som hver består av autonome individer. Disse teamene er spredt over hele verden, og samarbeider effektivt med hverandre ved hjelp av asynkron kommunikasjon, ved hjelp av svært transparente kommunikasjonsprotokoller. Veldig vakkert, ikke sant? En veldig vakker fremtid.
Selvfølgelig er ingenting av dette mulig uten kulturell endring. Vi må ha transformasjonsledelse, personlig ansvar, indre motivasjon.
Dette er grunnlaget for DevOps-organisasjoner: informasjonstransparens, asynkron kommunikasjon, transformasjonsledelse, desentralisering.
zapping
Systemene vi er en del av og de vi bygger er stadig mer kaotiske, og det er vanskelig for oss mennesker å takle denne tanken, det er vanskelig å gi opp illusjonen om kontroll. Vi prøver å fortsette å kontrollere dem, og dette fører ofte til utbrenthet. Jeg sier dette fra egen erfaring, jeg ble også brent, jeg ble også deaktivert av uforutsette feil i produksjonen.
Utbrenthet oppstår når vi prøver å kontrollere noe som er iboende ukontrollerbart. Når vi brenner ut mister alt sin mening fordi vi mister lysten til å gjøre noe nytt, vi blir defensive og begynner å forsvare det vi har.
Ingeniøryrket, som jeg ofte liker å minne meg selv på, er først og fremst et kreativt yrke. Hvis vi mister lysten til å skape noe, blir vi til aske, til aske. Folk brenner ut, hele organisasjoner brenner ut.
Etter min mening er det bare å akseptere kaosets kreative kraft, bare å bygge samarbeid i henhold til dets prinsipper som vil hjelpe oss til ikke å miste det som er bra i yrket vårt.
Dette er hva jeg ønsker deg: å elske jobben din, å elske det vi gjør. Denne verden lever av informasjon, vi har æren av å mate den. Så la oss studere kaos, la oss være kaosologer, la oss bringe verdi, skape noe nytt, vel, problemer, som vi allerede har funnet ut, er uunngåelige, og når de dukker opp, vil vi ganske enkelt si "Ops!" Og problemet er løst.
Hva annet enn Chaos Monkey?
Faktisk er alle disse instrumentene så unge. De samme Netflix bygde verktøy for seg selv. Bygg dine egne verktøy. Les prinsippene for kaosteknikk og lev opp til disse prinsippene i stedet for å prøve å finne andre verktøy som noen andre allerede har bygget.
Prøv å forstå hvordan systemene dine bryter sammen og begynn å bryte dem ned og se hvordan de holder stand. Dette kommer først. Og du kan se etter verktøy. Det er alle slags prosjekter.
Jeg forsto ikke helt øyeblikket da du sa at systemet ikke kan forenkles ved å forenkle komponentene, og gikk umiddelbart videre til mikrotjenester, som forenkler systemet ved å forenkle selve komponentene og komplisere interaksjoner. Dette er i hovedsak to deler som motsier hverandre.
Det stemmer, mikrotjenester er et veldig kontroversielt tema generelt. Faktisk øker det å forenkle deler fleksibiliteten. Hva tilbyr mikrotjenester? De gir oss fleksibilitet og hastighet, men de gir oss absolutt ikke enkelhet. De øker vanskeligheten.
Så i DevOps-filosofien er ikke mikrotjenester så bra?
Enhver god har en bakside. Fordelen er at det øker fleksibiliteten, slik at vi kan gjøre endringer raskere, men det øker kompleksiteten og dermed skjørheten til hele systemet.
Likevel, hva er mer vekt: på å forenkle samhandling eller på å forenkle deler?
Det legges selvfølgelig vekt på å forenkle interaksjoner, for hvis vi ser på dette fra synspunktet om hvordan vi jobber med deg, så må vi først og fremst være oppmerksomme på å forenkle interaksjoner, og ikke på å forenkle arbeidet av hver av oss hver for seg. For å forenkle arbeidet betyr å bli til roboter. Her på McDonald's fungerer det normalt når du har instruksjoner: her legger du burgeren, her heller du sausen på den. Dette fungerer ikke i det hele tatt i vårt kreative arbeid.
Er det sant at alt du sa lever i en verden uten konkurranse, og kaoset der er så snillt, og det er ingen motsetninger i dette kaoset, ingen vil spise eller drepe noen? Hvordan skal det gå med konkurranse og DevOps?
Vel, det kommer an på hva slags konkurranse vi snakker om. Handler det om konkurranse på arbeidsplassen eller konkurranse mellom bedrifter?
Om konkurransen av tjenester som finnes fordi tjenester ikke er flere selskaper. Vi skaper en ny type informasjonsmiljø, og ethvert miljø kan ikke leve uten konkurranse. Det er konkurranse overalt.
Den samme Netflix, vi tar dem som et forbilde. Hvorfor kom de på dette? Fordi de måtte være konkurransedyktige. Denne fleksibiliteten og bevegelseshastigheten er nettopp det svært konkurransemessige kravet; det introduserer kaos i systemene våre. Det vil si at kaos ikke er noe vi bevisst gjør fordi vi ønsker det, det er noe som skjer fordi verden krever det. Vi må bare tilpasse oss. Og kaos, det er nettopp et resultat av konkurranse.
Betyr dette kaos er fraværet av mål, så å si? Eller de målene vi ikke vil se? Vi er i huset og forstår ikke andres mål. Konkurranse skyldes faktisk at vi har klare mål og vi vet hvor vi ender i hvert neste øyeblikk. Dette, fra mitt synspunkt, er essensen av DevOps.
Også en titt på spørsmålet. Jeg tror vi alle har samme mål: å overleve og gjøre det med
største glede. Og konkurransemålet til enhver organisasjon er det samme. Overlevelse skjer ofte gjennom konkurranse, det er ingenting du kan gjøre med det.
Årets konferanse finner sted 7. desember på Technopolis. Vi tar i mot søknader om rapporter frem til 11. november. oss hvis du vil snakke.
Registrering for deltakere er åpen, billetter koster 7000 rubler. Bli med oss!
Kilde: www.habr.com