Anton Weiss, grundlægger og direktør for Otomato Software, en af initiativtagerne og instruktørerne til den første DevOps-certificering i Israel, talte ved sidste års om kaosteori og hovedprincipperne for kaosteknik, og forklarede også hvordan fremtidens ideelle DevOps-organisation fungerer.
Vi har udarbejdet en tekstversion af rapporten.
Godmorgen!
DevOpsDays i Moskva for andet år i træk, det er min anden gang på denne scene, mange af jer er i dette rum for anden gang. Hvad betyder det? Det betyder, at DevOps-bevægelsen i Rusland vokser, formerer sig, og vigtigst af alt betyder det, at tiden er inde til at tale om, hvad DevOps er i 2018.
Ræk hænderne op, som tror, at DevOps allerede er et erhverv i 2018? Der er sådanne. Er der nogen DevOps-ingeniører i rummet, hvis jobbeskrivelse siger "DevOps Engineer"? Er der nogen DevOps-managere i rummet? Sådan er der ikke. DevOps arkitekter? Også nej. Ikke nok. Er det virkelig sandt, at ingen siger, at de er en DevOps-ingeniør?
Så de fleste af jer tror, at dette er et anti-mønster? At sådan en profession ikke skulle eksistere? Vi kan mene, hvad vi vil, men mens vi tænker, bevæger branchen sig højtideligt frem til lyden af DevOps-trompeten.
Hvem har hørt om et nyt emne kaldet DevDevOps? Dette er en ny teknik, der giver mulighed for effektivt samarbejde mellem udviklere og devops. Og ikke så nyt. Efter Twitter at dømme begyndte de allerede at tale om dette for 4 år siden. Og indtil nu vokser og vokser interessen for dette, det vil sige, at der er et problem. Problemet skal løses.
Vi er kreative mennesker, vi er ikke bare rolige. Vi siger: DevOps er ikke et omfattende nok ord; det mangler stadig alle mulige forskellige, interessante elementer. Og vi går til vores hemmelige laboratorier og begynder at producere interessante mutationer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logikken er jernbeklædt, ikke? Vores leveringssystem er ikke funktionelt, vores systemer er ustabile og vores brugere er utilfredse, vi har ikke tid til at udrulle software til tiden, vi passer ikke ind i budgettet. Hvordan skal vi løse alt dette? Vi kommer med et nyt ord! Det ender med "Ops", og problemet er løst.
Så jeg kalder denne tilgang - "Ops, og problemet er løst."
Det hele toner i baggrunden, hvis vi minder os selv om, hvorfor vi fandt på alt dette. Vi fandt på hele denne DevOps-ting for at gøre levering af software og vores eget arbejde i denne proces så uhindret, smertefrit, effektivt og vigtigst af alt, underholdende som muligt.
DevOps voksede ud af smerte. Og vi er trætte af at lide. Og for at alt dette kan ske, er vi afhængige af stedsegrønne praksisser: effektivt samarbejde, flowpraksis og vigtigst af alt, systemtænkning, for uden det fungerer ingen DevOps.
Hvad er systemet?
Og hvis vi allerede taler om systemtænkning, så lad os minde os selv om, hvad et system er.
Hvis du er en revolutionær hacker, så er systemet helt klart ondt for dig. Det er en sky, der hænger over dig og tvinger dig til at gøre ting, du ikke vil.
Fra et systemtænknings synspunkt er et system en helhed, der består af dele. I denne forstand er hver af os et system. De organisationer, vi arbejder i, er systemer. Og det, du og jeg bygger, kaldes et system.
Alt dette er en del af ét stort socioteknologisk system. Og kun hvis vi forstår, hvordan dette socio-teknologiske system fungerer sammen, først da vil vi virkelig kunne optimere noget i denne sag.
Fra et systemtænkningsperspektiv har et system forskellige interessante egenskaber. For det første består den af dele, hvilket betyder, at dens adfærd afhænger af delenes adfærd. Desuden er alle dens dele også indbyrdes afhængige. Det viser sig, at jo flere dele et system har, jo sværere er det at forstå eller forudsige dets adfærd.
Fra et adfærdsmæssigt synspunkt er der et andet interessant faktum. Systemet kan noget, som ingen af dets individuelle dele kan.
Som Dr. Russell Ackoff (en af grundlæggerne af systemtænkning) sagde, er dette ret nemt at bevise med et tankeeksperiment. For eksempel, hvem i rummet ved, hvordan man skriver kode? Der er mange hænder, og det er normalt, for det er et af hovedkravene til vores fag. Ved du hvordan man skriver, men kan dine hænder skrive kode adskilt fra dig? Der er mennesker, der vil sige: "Det er ikke mine hænder, der skriver koden, det er min hjerne, der skriver koden." Kan din hjerne skrive kode adskilt fra dig? Nå, sandsynligvis ikke.
Hjernen er en fantastisk maskine, vi ved ikke engang 10% af, hvordan den fungerer der, men den kan ikke fungere adskilt fra det system, som er vores krop. Og det er nemt at bevise: Åbn dit kranium, tag din hjerne ud, sæt det foran computeren, lad ham prøve at skrive noget simpelt. "Hello, world" i Python, for eksempel.
Hvis et system kan gøre noget, som ingen af dets dele kan gøre separat, betyder det, at dets adfærd ikke er bestemt af dets deles adfærd. Hvad bestemmes det så af? Det bestemmes af samspillet mellem disse dele. Og følgelig, jo flere dele, jo mere komplekse interaktioner er, jo sværere er det at forstå og forudsige systemets adfærd. Og dette gør et sådant system kaotisk, fordi enhver, selv den mest ubetydelige, usynlige ændring i enhver del af systemet kan føre til helt uforudsigelige resultater.
Denne følsomhed over for de oprindelige forhold blev først opdaget og undersøgt af den amerikanske meteorolog Ed Lorenz. Efterfølgende blev det kaldt "sommerfugleeffekten" og førte til udviklingen af en videnskabelig tankebevægelse kaldet "kaosteori". Denne teori blev et af de store paradigmeskift i det 20. århundredes videnskab.
Kaosteori
Folk, der studerer kaos, kalder sig selv kaosologer.
Faktisk var årsagen til denne rapport, at jeg ved at arbejde med komplekse distribuerede systemer og store internationale organisationer på et tidspunkt indså, at det er den, jeg har lyst til. Jeg er kaosolog. Dette er dybest set en smart måde at sige: "Jeg forstår ikke, hvad der foregår her, og jeg ved ikke, hvad jeg skal gøre ved det."
Jeg tror, at mange af jer også ofte har det sådan, så I er også kaosologer. Jeg inviterer dig til lauget af kaosologer. De systemer, som du og jeg, kære medkaosologer, vil studere, kaldes "komplekse adaptive systemer."
Hvad er tilpasningsevne? Tilpasningsevne betyder, at den individuelle og kollektive adfærd af dele i et sådant adaptivt system ændrer sig og selvorganiserer, reagerer på hændelser eller kæder af mikrobegivenheder i systemet. Det vil sige, at systemet tilpasser sig ændringer gennem selvorganisering. Og denne evne til selvorganisering er baseret på det frivillige, fuldstændig decentraliserede samarbejde mellem frie autonome agenter.
En anden interessant egenskab ved sådanne systemer er, at de er frit skalerbare. Hvad burde uden tvivl interessere os, som kaosologer-ingeniører. Så hvis vi sagde, at et komplekst systems adfærd er bestemt af samspillet mellem dets dele, hvad skal vi så være interesseret i? Interaktion.
Der er yderligere to interessante resultater.
For det første forstår vi, at et komplekst system ikke kan forenkles ved at forenkle dets dele. For det andet er den eneste måde at forenkle et komplekst system ved at forenkle interaktionerne mellem dets dele.
Hvordan interagerer vi? Du og jeg er alle dele af et stort informationssystem kaldet det menneskelige samfund. Vi interagerer gennem et fælles sprog, hvis vi har det, hvis vi finder det.
Men sproget i sig selv er et komplekst adaptivt system. For at kunne interagere mere effektivt og enkelt er vi derfor nødt til at skabe en form for protokoller. Det vil sige en sekvens af symboler og handlinger, der vil gøre udvekslingen af information mellem os enklere, mere forudsigelig, mere forståelig.
Jeg vil sige, at tendenser mod kompleksitet, mod tilpasningsevne, mod decentralisering, mod kaos kan spores i alt. Og i de systemer, som du og jeg bygger, og i de systemer, som vi er en del af.
Og for ikke at være ubegrundet, lad os se på, hvordan de systemer, vi skaber, ændrer sig.
Du ventede på dette ord, forstår jeg. Vi er til en DevOps-konference, i dag vil dette ord blive hørt omkring hundrede tusinde gange, og så vil vi drømme om det om natten.
Microservices er den første softwarearkitektur, der opstod som en reaktion på DevOps-praksis, som er designet til at gøre vores systemer mere fleksible, mere skalerbare og sikre kontinuerlig levering. Hvordan gør hun det? Ved at reducere mængden af tjenester, reducere omfanget af problemer, som disse tjenester behandler, reducere leveringstiden. Det vil sige, at vi reducerer og forenkler dele af systemet, øger deres antal, og følgelig øges kompleksiteten af interaktioner mellem disse dele uvægerligt, det vil sige, at der opstår nye problemer, som vi skal løse.
Mikrotjenester er ikke enden, mikrotjenester er generelt allerede i går, fordi Serverless kommer. Alle servere brændte ned, ingen servere, ingen operativsystemer, kun ren eksekverbar kode. Konfigurationer er adskilte, tilstande er adskilte, alt er styret af hændelser. Skønhed, renlighed, stilhed, ingen begivenheder, intet sker, fuldstændig orden.
Hvor er kompleksiteten? Vanskeligheden ligger selvfølgelig i interaktionerne. Hvor meget kan en funktion gøre alene? Hvordan interagerer det med andre funktioner? Beskedkøer, databaser, balancerer. Hvordan genskaber man en begivenhed, når der opstod en fejl? Mange spørgsmål og få svar.
Microservices og Serverless er det, vi nørdehipstere kalder Cloud Native. Det hele handler om skyen. Men skyen er også i sagens natur begrænset i sin skalerbarhed. Vi er vant til at tænke på det som et distribueret system. Faktisk, hvor bor cloud-udbydernes servere? I datacentre. Det vil sige, at vi har en slags centraliseret, meget begrænset, distribueret model her.
I dag forstår vi, at tingenes internet ikke længere kun er store ord, at selv ifølge beskedne forudsigelser venter milliarder af enheder forbundet til internettet på os i de næste fem til ti år. En enorm mængde nyttige og ubrugelige data, der vil blive flettet ind i skyen og uploadet fra skyen.
Skyen holder ikke, så vi taler i stigende grad om noget, der hedder edge computing. Eller jeg kan også godt lide den vidunderlige definition af "fog computing". Det er indhyllet i romantikkens og mystikkens mystik.
Tågeberegning. Pointen er, at skyer er centraliserede klumper af vand, damp, is og sten. Og tåge er vanddråber, der er spredt omkring os i atmosfæren.
I tågeparadigmet udføres det meste af arbejdet af disse dråber helt autonomt eller i samarbejde med andre dråber. Og de vender sig først til skyen, når de virkelig bliver pressede.
Det vil sige igen decentralisering, autonomi, og selvfølgelig forstår mange af jer allerede, hvor alt dette er på vej hen, for du kan ikke tale om decentralisering uden at nævne blockchain.
Der er dem, der tror, det er dem, der har investeret i kryptovaluta. Der er dem, der tror, men er bange, som mig f.eks. Og der er dem, der ikke tror. Her kan du behandle anderledes. Der er teknologi, en ny ukendt sag, der er problemer. Som enhver ny teknologi rejser den flere spørgsmål, end den besvarer.
Hypen omkring blockchain er forståelig. Guldfeber til side, selve teknologien rummer bemærkelsesværdige løfter om en lysere fremtid: mere frihed, mere autonomi, distribueret global tillid. Hvad skal man ikke ønske sig?
Derfor begynder flere og flere ingeniører rundt om i verden at udvikle decentrale applikationer. Og dette er en magt, der ikke kan afvises ved blot at sige: "Ahh, blockchain er bare en dårligt implementeret distribueret database." Eller som skeptikere kan lide at sige: "Der er ingen rigtige applikationer til blockchain." Hvis du tænker over det, sagde de det samme om elektricitet for 150 år siden. Og de havde endda ret på nogle måder, for det, elektricitet gør muligt i dag, var på ingen måde muligt i det 19. århundrede.
Hvem ved forresten, hvilken slags logo der er på skærmen? Dette er Hyperledger. Dette er et projekt, der udvikles i regi af The Linux Foundation og omfatter et sæt blockchain-teknologier. Dette er virkelig styrken ved vores open source-fællesskab.
Kaos Engineering
Så det system, som vi udvikler, bliver mere og mere komplekst, mere og mere kaotisk og mere og mere tilpasningsdygtigt. Netflix er pionerer inden for mikroservicesystemer. De var blandt de første til at forstå dette, de udviklede et sæt værktøjer, de kaldte Simian Army, hvoraf det mest berømte var . Han definerede, hvad der blev kendt som .
Forresten, under arbejdet med rapporten oversatte vi endda denne tekst til russisk, så gå til , læse, kommentere, skælde ud.
Kort fortalt siger principperne for kaosteknik følgende. Komplekse distribuerede systemer er i sagens natur uforudsigelige og i sagens natur buggy. Fejl er uundgåelige, hvilket betyder, at vi er nødt til at acceptere disse fejl og arbejde med disse systemer på en helt anden måde.
Vi må selv forsøge at introducere disse fejl i vores produktionssystemer for at teste vores systemer for den samme tilpasningsevne, netop denne evne til selvorganisering, til overlevelse.
Og det ændrer alt. Ikke kun hvordan vi sætter systemer i produktion, men også hvordan vi udvikler dem, hvordan vi tester dem. Der er ingen proces med stabilisering eller frysning af koden, tværtimod er der en konstant proces med destabilisering. Vi forsøger at dræbe systemet og se det fortsætte med at overleve.
Distribuerede systemintegrationsprotokoller
Derfor kræver dette, at vores systemer på en eller anden måde ændrer sig. For at de kan blive mere stabile, har de brug for nogle nye protokoller til interaktion mellem deres dele. For at disse dele kan blive enige og komme til en form for selvorganisering. Og alle mulige nye værktøjer, nye protokoller opstår, som jeg kalder "protokoller til interaktion mellem distribuerede systemer."
Hvad taler jeg om? Først projektet . Nogle forsøger at skabe en generel distribueret sporingsprotokol, som er et helt uundværligt værktøj til fejlretning af komplekse distribuerede systemer.
Yderligere - . Vi siger, at vi ikke kan forudsige, hvad der vil ske med systemet, det vil sige, at vi skal øge dets observerbarhed, observerbarhed. Opentracing tilhører en familie af værktøjer, der giver observerbarhed til vores systemer. Men vi har brug for observerbarhed for at afgøre, om systemet opfører sig, som vi forventer, det skal eller ej. Hvordan definerer vi forventet adfærd? Ved at definere en form for politik, et eller andet sæt regler. Open Policy Agent-projektet er dedikeret til at definere dette sæt regler på tværs af et spektrum lige fra adgang til ressourceallokering.
Som vi sagde, er vores systemer i stigende grad begivenhedsdrevne. Serverløs er et godt eksempel på hændelsesdrevne systemer. For at vi kan overføre hændelser mellem systemer og spore dem, har vi brug for noget fælles sprog, en fælles protokol for, hvordan vi taler om hændelser, hvordan vi overfører dem til hinanden. Sådan hed et projekt .
Den konstante strøm af ændringer, der skyller ind over vores systemer og konstant destabiliserer dem, er en kontinuerlig strøm af softwareartefakter. For at vi kan opretholde denne konstante strøm af ændringer, har vi brug for en slags fælles protokol, hvorigennem vi kan tale om, hvad en softwareartefakt er, hvordan den testes, hvilken verifikation den har bestået. Sådan hed et projekt . Det vil sige en fælles metadataprotokol for softwareartefakter.
Og endelig, hvis vi ønsker, at vores systemer skal være fuldstændig uafhængige, adaptive og selvorganiserede, må vi give dem ret til selvidentifikation. Projekt kaldet Det er præcis, hvad han gør. Dette er også et projekt i regi af Cloud Native Computing Foundation.
Alle disse projekter er unge, de har alle brug for vores kærlighed, vores validering. Dette er alt sammen open source, vores test, vores implementering. De viser os, hvor teknologien er på vej hen.
Men DevOps har aldrig primært handlet om teknologi, det har altid handlet om samarbejde mellem mennesker. Og derfor, hvis vi ønsker, at de systemer, vi udvikler, skal ændre sig, så skal vi selv ændre. Faktisk ændrer vi os alligevel; vi har ikke meget at vælge imellem.
Der er en vidunderlig Den britiske forfatter Rachel Botsman, hvor hun skriver om udviklingen af tillid gennem menneskehedens historie. Hun siger, at til at begynde med, i primitive samfund, var tillid lokal, det vil sige, at vi kun stolede på dem, vi kendte personligt.
Så var der en meget lang periode – en mørk tid, hvor tilliden var centraliseret, hvor vi begyndte at stole på mennesker, som vi ikke kender på baggrund af, at vi tilhører den samme offentlige eller statslige institution.
Og det er det, vi ser i vores moderne verden: Tillid bliver mere og mere distribueret og decentraliseret, og den er baseret på informationsstrømmenes frihed, på tilgængeligheden af information.
Hvis du tænker over det, er netop denne tilgængelighed, som gør denne tillid mulig, det, du og jeg implementerer. Det betyder, at både måden, vi samarbejder på, og måden, vi gør det på, skal ændre sig, for gamle dages centraliserede, hierarkiske it-organisationer fungerer ikke længere. De begynder at dø ud.
DevOps Organisation Fundamentals
Fremtidens ideelle DevOps-organisation er et decentraliseret, adaptivt system sammensat af autonome teams, der hver især består af autonome individer. Disse teams er spredt rundt om i verden og samarbejder effektivt med hinanden ved hjælp af asynkron kommunikation ved hjælp af meget gennemsigtige kommunikationsprotokoller. Meget smuk, ikke? En meget smuk fremtid.
Selvfølgelig er intet af dette muligt uden kulturelle forandringer. Vi skal have transformationsledelse, personligt ansvar, intern motivation.
Dette er grundlaget for DevOps-organisationer: informationsgennemsigtighed, asynkron kommunikation, transformationsledelse, decentralisering.
zapning
De systemer, vi er en del af, og dem, vi bygger, er i stigende grad kaotiske, og det er svært for os mennesker at klare denne tanke, det er svært at opgive illusionen om kontrol. Vi forsøger at fortsætte med at kontrollere dem, og det fører ofte til udbrændthed. Jeg siger dette fra min egen erfaring, jeg blev også brændt, jeg blev også deaktiveret af uforudsete fejl i produktionen.
Udbrændthed opstår, når vi forsøger at kontrollere noget, der i sagens natur er ukontrollerbart. Når vi brænder ud, mister alt sin mening, fordi vi mister lysten til at gøre noget nyt, vi går i forsvar og begynder at forsvare det, vi har.
Ingeniørfaget er, som jeg ofte ynder at minde mig selv om, først og fremmest et kreativt erhverv. Hvis vi mister lysten til at skabe noget, så bliver vi til aske, bliver til aske. Folk brænder ud, hele organisationer brænder ud.
Efter min mening er det kun at acceptere kaosets kreative kraft, kun at bygge samarbejde efter dets principper, hvad der vil hjælpe os til ikke at miste det, der er godt i vores fag.
Dette er, hvad jeg ønsker for dig: at elske dit job, at elske det, vi laver. Denne verden lever af information, vi har æren af at fodre den. Så lad os studere kaos, lad os være kaosologer, lad os bringe værdi, skabe noget nyt, ja, problemer, som vi allerede har fundet ud af, er uundgåelige, og når de dukker op, vil vi blot sige "Ops!" Og problemet er løst.
Hvad andet end Chaos Monkey?
Faktisk er alle disse instrumenter så unge. De samme Netflix byggede værktøjer til sig selv. Byg dine egne værktøjer. Læs principperne for kaosteknik og lev op til disse principper i stedet for at prøve at finde andre værktøjer, som en anden allerede har bygget.
Prøv at forstå, hvordan dine systemer går i stykker, og begynd at nedbryde dem og se, hvordan de holder stand. Dette kommer først. Og du kan lede efter værktøjer. Der er alle mulige slags projekter.
Jeg forstod ikke helt det øjeblik, hvor du sagde, at systemet ikke kan forenkles ved at forenkle dets komponenter, og gik straks videre til mikrotjenester, som forenkler systemet ved at forenkle selve komponenterne og komplicere interaktioner. Disse er grundlæggende to dele, der modsiger hinanden.
Det er rigtigt, mikrotjenester er generelt et meget kontroversielt emne. Faktisk øger forenkling af dele fleksibiliteten. Hvad tilbyder mikrotjenester? De giver os fleksibilitet og hurtighed, men de giver os bestemt ikke enkelhed. De øger sværhedsgraden.
Så i DevOps-filosofien er mikrotjenester ikke så gode?
Ethvert godt har en bagside. Fordelen er, at det øger fleksibiliteten, så vi kan foretage ændringer hurtigere, men det øger kompleksiteten og dermed skrøbeligheden af hele systemet.
Alligevel, hvad er mere vægt: på at forenkle interaktion eller på at forenkle dele?
Vægten er selvfølgelig på at forenkle interaktioner, for hvis vi ser på dette ud fra et synspunkt om, hvordan vi arbejder med dig, så skal vi først og fremmest være opmærksomme på at forenkle interaktioner, og ikke på at forenkle arbejdet af hver af os hver for sig. Fordi at forenkle arbejdet betyder at blive til robotter. Her på McDonald's fungerer det normalt, når du har instruktioner: her sætter du burgeren, her hælder du saucen på. Dette fungerer slet ikke i vores kreative arbejde.
Er det sandt, at alt, hvad du sagde, lever i en verden uden konkurrence, og kaosset der er så venligt, og der er ingen modsætninger i dette kaos, ingen ønsker at spise eller dræbe nogen? Hvordan skal konkurrence og DevOps klare sig?
Nå, det afhænger af, hvilken slags konkurrence vi taler om. Handler det om konkurrence på arbejdspladsen eller konkurrence mellem virksomheder?
Om konkurrencen af tjenester, der eksisterer, fordi tjenester ikke er flere virksomheder. Vi skaber en ny type informationsmiljø, og ethvert miljø kan ikke leve uden konkurrence. Der er konkurrence overalt.
Det samme Netflix, vi tager dem som et forbillede. Hvorfor fandt de på dette? For de skulle være konkurrencedygtige. Denne fleksibilitet og bevægelseshastighed er netop det meget konkurrencemæssige krav; det introducerer kaos i vores systemer. Det vil sige, at kaos ikke er noget, vi bevidst gør, fordi vi ønsker det, det er noget, der sker, fordi verden kræver det. Vi skal bare tilpasse os. Og kaos, det er netop resultatet af konkurrence.
Betyder det, at kaos er fraværet af mål, som det var? Eller de mål, som vi ikke ønsker at se? Vi er i huset og forstår ikke andres mål. Konkurrencen skyldes faktisk, at vi har klare mål, og vi ved, hvor vi ender i hvert næste øjeblik. Dette er fra mit synspunkt essensen af DevOps.
Også et kig på spørgsmålet. Jeg tror, vi alle har det samme mål: at overleve og gøre det med
største fornøjelse. Og konkurrencemålet for enhver organisation er det samme. Overlevelse sker ofte gennem konkurrence, der er intet du kan gøre ved det.
Årets konference finder sted den 7. december på Technopolis. Vi modtager ansøgninger om rapporter indtil den 11. november. os, hvis du vil tale.
Tilmelding for deltagere er åben, billetter koster 7000 rubler. Kom med os!
Kilde: www.habr.com