Grundlægger og direktør for «Otomato Software», en af initiativtagerne og instruktørerne til den første DevOps-certificering i Israel, Anton Weiss, talte sidste år om kaosteori og hovedprincipperne i kaosingeniørkunst, samt forklarede, hvordan den ideelle DevOps-organisation i fremtiden ser ud.
Vi har forberedt en tekstversion af præsentationen.
Godmorgen!
DevOpsDays i Moskva for andet år i træk, jeg er for anden gang på denne scene, mange af jer er for anden gang i denne sal. Hvad betyder det? Det betyder, at DevOps-bevægelsen i Rusland vokser, multipliceres, og vigtigst af alt, det betyder, at det er tid til at tale om, hvad DevOps egentlig er i 2018.
Hæv hånden, hvis du mener, at DevOps i 2018 allerede er et erhverv? Der er nogle. Er der DevOps-ingeniører her, som har «DevOps-ingeniør» i deres jobbeskrivelse? Er der DevOps-managere til stede? Ingen. DevOps-arkitekter? Også ingen. Det er for lidt. Så virkelig er der ingen, der har skrevet, at de er DevOps-ingeniører?
Så de fleste af jer mener, at det er et antipattern? At der ikke burde eksistere et sådant erhverv? Vi kan tænke, hvad vi vil, men mens vi tænker, bevæger industrien sig fremad under lyden af DevOps-nummeret.
Hvem har hørt om det nye emne, som hedder DevDevOps? Det er en ny metode, der sikrer effektivt samarbejde mellem udviklere og DevOps-teams. Og det er faktisk ikke så nyt. Hvis man dømmer ud fra Twitter, så begyndte man allerede at tale om det for 4 år siden. Og interessen vokser stadig, hvilket betyder, at der er et problem. Problemet skal løses.
Vi er kreative mennesker, vi giver os ikke så let. Vi siger: DevOps er ikke et tilstrækkeligt dækkende ord, der mangler mange interessante elementer. Så vi går ind i vores hemmelige laboratorier og begynder at skabe nysgerrige mutationer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logikken er klar, ikke? Vi har et leveringssystem, der ikke fungerer, vores systemer er ustabile og brugerne er utilfredse, vi kan ikke få software ude til tiden, vi holder os ikke inden for budgettet. Hvordan løser vi alt dette? Vi finder på et nyt ord! Det vil slutte på «Ops», og så er problemet løst.
Sådan kalder jeg denne tilgang — «Ops, og problemet er løst».
Alt dette bliver sekundært, hvis vi minder os selv om, hvorfor vi overhovedet fandt på det hele. Vi fandt på hele dette DevOps for at gøre leveringen af software og vores eget arbejde i denne proces så gnidningsløst, smertefrit, effektivt og vigtigst af alt, behageligt som muligt.
DevOps voksede ud af smerte. Og vi er trætte af at lide. For at få det til at ske, bygger vi på tidløse praksisser: effektivt samarbejde, flow-praksisser og vigtigst af alt, systemisk tænkning, fordi uden det fungerer ingen DevOps.
Hvad er et system?
Og når vi nu taler om systemisk tænkning, lad os minde os selv om, hvad et system er.
Hvis du er en revolutionerende hacker, er systemet entydigt det onde. Det er en skygge, der hænger over dig og tvinger dig til at gøre ting, du ikke ønsker at gøre.
Set fra systemisk tænkning er et system en helhed bestående af dele. I denne forstand er hver enkelt af os et system. De organisationer, vi arbejder i, er systemer. Og det, vi bygger sammen, kaldes netop et system.
Alt dette er en del af et stort socioteknologisk system. Og først når vi forstår, hvordan dette socioteknologiske system arbejder sammen, kan vi virkelig optimere noget i denne henseende.
Set fra systemisk tænkning har systemet forskellige interessante egenskaber. For det første består det af dele, hvilket betyder, at dets adfærd afhænger af adfærden hos delene. Samtidig er alle delene gensidigt afhængige. Det viser sig, at jo flere dele et system har, desto sværere er det at forstå eller forudsige dets adfærd.
Set fra adfærdens synspunkt er der endnu en interessant kendsgerning. Et system kan gøre noget, som ingen af dets enkelte dele kan gøre.
Som Dr. Russell Ackoff (en af grundlæggerne af systemisk tænkning) sagde, er det relativt let at bevise ved hjælp af et tankeeksperiment. For eksempel, hvem i rummet kan skrive kode? Mange hænder, og det er normalt, fordi det er et af de grundlæggende krav til vores profession. Du kan skrive, men kan dine hænder adskilt fra dig selv skrive kode? Der er folk, der vil sige: «Det er ikke mine hænder, der skriver kode, det er min hjerne, der skriver kode». Og kan hjernen adskilt fra dig selv skrive kode? Sandsynligvis ikke.
Hjernen er en fantastisk maskine, og vi ved ikke engang 10% om, hvordan den fungerer, men den kan ikke fungere isoleret fra det system, som vores krop er. Det er let at bevise: åbn din kraniumkasse, tag hjernen ud og læg den foran en computer og lad den prøve at skrive noget simpelt. "Hello, world" i Python, for eksempel.
Hvis systemet kan udføre noget, som ingen af dets dele hver for sig kan, så betyder det, at dets adfærd ikke fastlægges af adfærden i dets dele. Hvad fastlægger det så? Det fastlægges af interaktionerne mellem disse dele. Jo flere dele der er, desto mere komplekse er interaktionerne, og desto sværere er det at forstå og forudsige systemets adfærd. Dette gør et sådant system kaotisk, fordi selv den mindste, usynlige ændring i en af systemets dele kan føre til helt uforudsigelige resultater.
Denne følsomhed over for de indledende betingelser blev første gang opdaget og undersøgt af den amerikanske meteorolog Ed Lorenz. Senere blev den kendt som "sommerfugleeffekten" og førte til udviklingen af en videnskabelig bevægelse kaldet "kaosteori". Denne teori blev en af de grundlæggende paradigmeskift i 20. århundrede.
Kaosteori
Mennesker, der studerer kaos, kalder sig selv kaosologer.
Årsagen til denne præsentation er, at jeg, i mit arbejde med komplekse distribuerede systemer og store internationale organisationer, på et tidspunkt indså, at dette er, hvem jeg føler mig som. Jeg er kaosolog. Det er sådan en snedig måde at sige: "Jeg forstår ikke, hvad der sker her, og jeg ved ikke, hvad jeg skal gøre ved det."
Jeg tror, mange af jer også ofte føler sådan, så I er også kaosologer. Jeg inviterer jer til kaosologernes gildet. De systemer, som vi, kære kollegaer kaosologer, vil studere, kaldes "komplekse adaptive systemer".
Hvad er tilpasningsevne? Tilpasningsevne betyder, at den individuelle og kollektive adfærd af dele i et sådant tilpasset system ændrer sig og selvorganiserer sig som reaktion på hændelser eller kæder af mikro-hændelser i systemet. Med andre ord tilpasser systemet sig ændringer gennem selvorganisering. Og denne evne til selvorganisering er baseret på frivilligt, helt decentraliseret samarbejde mellem frie autonome agenter.
En anden interessant egenskab ved sådanne systemer er, at de er frit skalerbare. Dette burde uden tvivl interessere os som kaosmænd og -ingeniører. Så hvis vi har sagt, at opførelsen af et komplekst system bestemmes af samspillet mellem dets dele, hvad bør vi så være interesserede i? Samspillet.
Der er to interessante konklusioner.
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 på ved at forenkle interaktionerne mellem dets dele.
Hvordan interagerer vi? Vi er alle dele af et stort informationssystem, der kaldes 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. Derfor, for at interagere mere effektivt og enkelt, er vi nødt til at skabe nogle protokoller. Det vil sige en sekvens af symboler og handlinger, der gør informationsudvekslingen mellem os enklere, mere forudsigelig, mere forståelig.
Jeg vil sige, at tendenserne til kompleksitet, tilpasningsevne, decentralisering og kaos kan spores overalt. Både i de systemer, vi bygger, og i de systemer, vi er en del af.
Og for ikke at være substansløs, lad os se på, hvordan de systemer, vi skaber, ændrer sig.
Jeg ved, at du har ventet på dette ord. Vi er til DevOps-konferencen, i dag vil dette ord blive nævnt et sted omkring hundrede tusinde gange og derefter komme til at hjemsøge os om natten.
Mikrotjenester er den første softwarearkitektur, der opstod som reaktion på DevOps-praksis, og den er designet til at gøre vores systemer mere fleksible, mere skalerbare og muliggøre kontinuerlig levering. Hvordan gør den det? Ved at reducere omfanget af tjenester, begrænse grænserne for de problemer, som disse tjenester håndterer, og forkorte leveringstiden. Det vil sige, at vi mindsker og forenkler dele af systemet, øger deres antal, og dermed øges kompleksiteten af interaktionerne mellem disse dele, hvilket skaber nye problemer, som vi skal løse.
Mikrotjenester er ikke enden; mikrotjenester er faktisk i gårsdagens dag, fordi Serverless er på vej. Alle servere er brændt, der er ingen servere, ingen operativsystemer, kun ren eksekverbar kode. Konfigurationer er adskilt, tilstande er adskilte, alt styres af begivenheder. Skønhed, renhed, stilhed, ingen begivenheder, intet sker, fuldstændig orden.
Hvor er kompleksiteten? Komplexiteten ligger åbenlyst i interaktionerne. Hvor meget kan en funktion gøre alene? Hvordan interagerer den med andre funktioner? Meddelelseskøer, databaser, belastningsfordelere. Hvordan genskaber man en begivenhed, når der opstår en fejl? Mange spørgsmål og få svar.
Mikrotjenester og Serverless er alt det, som vi, computerhipstere, kalder Cloud Native. Det handler alt sammen om skyen. Men skyen er i sin kerne også begrænset når det kommer til skalerbarhed. Vi er vant til at tænke på den som et distribueret system. Men hvor bor serverne fra cloududbydere? I datacentre. Det vil sige, at vi her har en form for centraliseret, meget begrænset, distribueret model.
I dag forstår vi, at Internet of Things ikke kun er høje ord; ifølge beskedne forudsigelser vil vi i de næste fem til ti år se milliarder af enheder, der er tilsluttet internettet. En enorm mængde nyttige og unyttige data, der vil strømme ind i skyen og blive sendt ud fra skyen.
Skyen vil ikke kunne klare det, derfor taler vi i stigende grad om det, der kaldes "edge computing". Eller som jeg også kan lide den vidunderlige definition "fog computing". Det har en mystisk romantik og mystik over sig.
Tågecomputing. Det handler om, at skyer er centraliserede samlinger af vand, damp, is og sten. Tåge er derimod vanddråber, der er spredt omkring os i atmosfæren.
I den tågede paradigm udføres størstedelen af arbejdet af disse dråber ganske autonomt eller i samarbejde med andre dråber. De henvender sig kun til skyen, når det virkelig brænder på.
Det vil sige, at vi igen taler om decentralisering, autonomi, og mange af jer forstår sikkert allerede, hvor dette fører hen, for man kan ikke tale om decentralisering uden at nævne blockchain.
Der er dem, der tror på det; det er dem, der har investeret i kryptovaluta. Der er dem, der tror, men som er bange, som for eksempel mig. Og så er der dem, der ikke tror. Man kan forholde sig forskelligt til det. Der er teknologi, en ny og uklar ting, der er problemer. Som enhver ny teknologi rejser den flere spørgsmål, end den giver svar.
Hype omkring blockchain er forståelig. Selvom man ser bort fra guldfeberen, så giver teknologien i sig selv fantastiske løfter om en lys fremtid: mere frihed, mere autonomi, globalt distribueret tillid. Hvad er der ikke at ønske?
Derfor begynder flere og flere ingeniører verden over at udvikle decentrale applikationer. Og det er en kraft, der ikke kan ignoreres blot ved at sige: "Aaa, blockchain er bare en dårligt implementeret distribueret database." Eller som skeptikere elsker at sige: "Der er ingen reelle anvendelser for blockchain." Hvis man tænker over det, så sagde de samme ting for 150 år siden om elektricitet. Og de havde endda delvist ret, for det, elektricitet muliggør i dag, var slet ikke muligt i det 19. århundrede.
Forresten, hvem ved, hvilket logo der er på skærmen? Det er Hyperledger. Det er et projekt, der udvikles under The Linux Foundations' vinger, og det omfatter et sæt blockchain-teknologier. Det er virkelig kraften i vores open source-community.
Kaosingeniørarbejde
Så systemet, som vi udvikler, bliver mere og mere komplekst, mere chaotisk og mere adaptivt. Netflix er pionerer inden for mikrotjenestearkitektur. De var en af de første, der forstod dette, og de udviklede et sæt værktøjer, som de kaldte Simian Army, hvoraf den mest kendte er . Den definerede det, der blev kendt som .
Forresten, mens vi arbejdede på præsentationen, oversatte vi endda denne tekst til russisk, så kig forbi , læs, kommenter, kritiser.
Kort sagt beskriver principperne for kaosingeniørkunst følgende. Komplekse distribuerede systemer er i sin natur uforudsigelige, og de indeholder i sin essens fejl. Fejl er uundgåelige, og det betyder, at vi skal acceptere disse fejl og arbejde med disse systemer helt anderledes.
Vi skal forsøge at introducere disse fejl i vores produktionssystemer for at teste vores systemers tilpasningsevne, deres evne til selvorganisering og overlevelse.
Og det ændrer alt. Ikke kun hvordan vi bringer systemet i produktion, men også hvordan vi udvikler dem, hvordan vi tester dem. Der er ingen stabiliseringsproces, ingen frysing af koden, tværtimod er der en konstant proces med destabilisering. Vi forsøger at dræbe systemet og se, at det fortsætter med at overleve.
Distributed System Integration Protocols
Dette kræver, at vores systemer også ændrer sig på en eller anden måde. For at de kan blive mere robuste, har de brug for nye interaktionsprotokoller mellem deres dele. Så disse dele kan indgå aftaler og nå til en eller anden form for selvorganisering. Der opstår alle mulige nye værktøjer, nye protokoller, som jeg kalder "protokoller for interaktion mellem distribuerede systemer".
Hvad taler jeg om? For det første projektet . Et forsøg på at skabe en fælles protokol for distribueret sporing, som er et uundgåeligt redskab til fejlfinding af komplekse distribuerede systemer.
Next is . Vi siger, at vi ikke kan forudsige, hvad der vil ske med systemet, så vi skal øge dets observabilitet. Opentracing tilhører en familie af værktøjer, der giver observabilitet til vores systemer. Men vi har brug for observabilitet for at bestemme, om systemet opfører sig som forventet eller ej. Hvordan kan vi bestemme det forventede adfærd? Ved at definere en slags politik, et sæt regler i det. Projektet Open Policy Agent beskæftiger sig med at definere dette regelsæt over et bredt spektrum: fra adgang til placering af ressourcer.
Som vi sagde, bliver vores systemer mere og mere hændelsesorienterede. Serverless er et fremragende eksempel på hændelsesorienterede systemer. For at vi kan overføre hændelser mellem systemer og spore dem, har vi brug for et fælles sprog, en fælles protokol for, hvordan vi taler om hændelser, og hvordan vi overbringer dem til hinanden. Det tager et projekt med navnet .
Den kontinuerlige strøm af ændringer, der vasker 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 fælles protokol, som vi kan bruge til at tale om, hvad en softwareartefakt er, hvordan den er blevet verificeret, og hvilken verifikation den har gennemgået. Det tager et projekt med navnet . Altså, en fælles protokol for metadata om softwareartefakter.
Og endelig, hvis vi ønsker, at vores systemer skal være helt selvstændige, adaptive og selvorganiserende, skal vi give dem ret til selvidentifikation. Projektet med navnet er netop det, det beskæftiger sig med. Det er også et projekt under Cloud Native Computing Foundation.
Alle disse projekter er unge, de har alle brug for vores kærlighed, vores test. Det er alt sammen open source, vores testning, vores implementering. De viser os, hvilken retning teknologien bevæger sig i.
Men DevOps har aldrig primært handlet om teknologi, det har altid været om samarbejde mellem mennesker. Og derfor, hvis vi ønsker, at de systemer, vi udvikler, skal ændre sig, så må vi ændre os selv. Faktisk ændrer vi os allerede, vi har ikke rigtig noget valg.
Der er en fantastisk britisk forfatter ved navn Rachel Botsman, som skriver om tillidens evolution gennem menneskehedens historie. Hun siger, at tillid oprindeligt i primitive samfund var lokal, altså vi stolede kun på dem, vi kendte personligt.
Derefter kom der en meget lang periode — en mørk tid, hvor tillid blev centraliseret, hvor vi begyndte at stole på mennesker, vi ikke kender, baseret på det faktum, at vi tilhører samme sociale eller statslige institution.
Og her er, hvad vi ser i vores moderne verden: tillid bliver mere og mere distribueret og decentraliseret, og den er baseret på friheden af informationsstrømme og tilgængeligheden af information.
Hvis man tænker over det, så er det netop denne tilgængelighed, som muliggør denne tillid, som vi skaber sammen. Det betyder, at måden, vi samarbejder på, og måden, vi gør det på, skal ændres, fordi centraliserede, hierarkiske IT-organisationer fra den gamle skole holder op med at fungere. De begynder at uddø.
Grundlaget for DevOps-organisationer
Den ideelle DevOps-organisation i fremtiden er et decentraliseret, adaptivt system bestående af autonome teams, hvor hvert team består af autonome individer. Disse teams er spredt over hele verden og samarbejder effektivt gennem asynkron kommunikation og meget transparente informationsudvekslingsprotokoller. Meget smukt, ikke? En meget smuk fremtid.
Selvfølgelig er alt dette umuligt uden kulturelle ændringer. Vi skal have transformationelt lederskab, personlig ansvarlighed, indre motivation.
Dette er fundamentet for DevOps-organisationer: informationsgennemsigtighed, asynkrone kommunikationer, transformationelt lederskab, decentralisering.
Udbrændthed
De systemer, som vi er en del af, og dem, vi bygger, bliver mere og mere kaotiske, og det er svært for os mennesker at finde fred med denne tanke, svært at give slip på illusionen om kontrol. Vi forsøger at fortsætte med at kontrollere dem, og det fører ofte til udbrændthed. Jeg siger dette ud fra egen erfaring, jeg har også lidt, også blevet rammet af uventede nedbrud i produktionen.
Udbrændthed sker, når vi forsøger at kontrollere det, der i sin natur ikke kan kontrolleres. Når vi bliver udbrændte, mister alt mening, fordi vi mister lysten til at lave noget nyt, vi går i en forsvarsposition og begynder at beskytte det, vi har.
Ingeniøryrket, som jeg ofte elsker at minde mig selv om, er i første række et kreativt erhverv. Hvis vi mister lysten til at skabe noget, så bliver vi til aske, bliver til sod. Folk brænder ud, hele organisationer brænder ud.
Efter min mening er det kun ved at acceptere den skabende kraft af kaos, kun ved at opbygge samarbejde på dets principper, at vi kan undgå at miste det gode, vi har i vores profession.
Det ønsker jeg for jer: at elske jeres arbejde, at elske det, vi laver. Denne verden lever af information, og vi har fået æren af at nære den. Så lad os studere kaos, blive kaosologer, bringe værdi, skabe noget nyt, og når problemerne dukker op, som vi allerede har fundet ud af, er uundgåelige, så siger vi bare "Ops!", og problemet er løst.
Hvad med Chaos Monkey?
I virkeligheden er alle disse værktøjer meget unge. Netflix udviklede også værktøjer til deres egne behov. Byg værktøjer til dig selv. Læs principperne for kaosingeniørarbejde og følg disse principper, i stedet for at lede efter andre værktøjer, som nogen andre allerede har bygget.
Prøv at forstå, hvordan dine systemer går i stykker, og begynd at ødelægge dem og se, hvordan de klarer slagene. Det er det, der kommer først. Værktøjer kan du finde. Der er mange projekter.
Jeg forstod ikke helt det punkt, du nævnte, hvor du sagde, at systemet ikke kan forsimples ved at forsimple dets komponenter, og så gik du straks videre til mikrotjenester, som netop simplificerer systemet ved at forsimple selve komponenterne og gøre interaktionerne mere komplekse. Det er i virkeligheden to dele, der modsiger hinanden.
Helt korrekt, mikrotjenester er en meget modstridende emne overhovedet. I virkeligheden øger simplificeringen af dele fleksibiliteten. Hvad giver mikrotjenester os? De giver os fleksibilitet og hastighed, men de giver os bestemt ikke enkelhed. De øger kompleksiteten.
Så i DevOps-filosofien er mikrotjenester ikke så stor en velsignelse?
Enhver velsignelse har en bagside. Der er en velsignelse: det øger fleksibiliteten, giver os mulighed for at foretage ændringer hurtigere, men det øger kompleksiteten og dermed skrøbeligheden af hele systemet.
Ligger der stadig mere fokus på at forenkle interaktioner eller på at forenkle dele?
Fokus kommer uden tvivl på at forenkle interaktionen, for hvis vi ser på det ud fra, hvordan vi arbejder sammen, så skal vi først og fremmest fokusere på at forenkle interaktionerne og ikke på at forenkle arbejdet for hver enkelt af os. For at forenkle arbejdet er at gøre os til robotter. Det fungerer fint i McDonald's, når du har fået at vide: her skal du lægge burgeren, her skal du hælde saucen på. Men det fungerer slet ikke i vores kreative arbejde.
Er det sandt, at alt, hvad du har fortalt, lever i en verden uden konkurrence, og at kaosset der er så venligt, og der ikke er modsætninger i dette kaos, ingen ønsker at spise eller dræbe hinanden? Hvordan skal konkurrence og DevOps eksistere?
Det afhænger af, hvilken type konkurrence vi taler om. Konkurrence på arbejdspladsen eller konkurrence mellem virksomheder?
Konkurrence mellem de tjenester, der eksisterer, fordi tjenester ikke blot er flere virksomheder. Vi skaber en ny type informationsmiljø, og intet miljø kan eksistere uden konkurrence. Der er konkurrence overalt.
Tag for eksempel Netflix som en rollemodel. Hvorfor kom de op med dette? Fordi de var nødt til at være konkurrencedygtige. Denne fleksibilitet og hastighed er netop det konkurrencemæssige krav; det tilføjer kaotiske elementer til vores systemer. Så kaos er ikke noget, vi bevidst skaber, fordi vi ønsker det; det er noget, der opstår, fordi verden kræver det. Vi må simpelthen tilpasse os. Og kaos er netop resultatet af konkurrencen.
Betyder det, at kaos er en mangel på mål, som det ser ud? Eller måske de mål, vi ikke ønsker at se? Vi befinder os i vores eget hus og forstår ikke andres mål. Konkurrence opstår faktisk, fordi vi har klare mål og ved, hvor vi er på vej hen til hvert enkelt tidspunkt. Dette er, efter min mening, essensen af DevOps.
Det er også en synsvinkel. Jeg mener, at vi alle har det samme mål: at overleve og gøre det med
størst muligt fornøjelse. Den konkurrencemæssige mål for enhver organisation er den samme. Overlevelse foregår ofte i en konkurrence, og der er ikke meget, vi kan gøre ved det.
I år finder konferencen sted den 7. december i "Teknopolis". Vi modtager ansøgninger til foredrag indtil den 11. november. os, hvis du ønsker at deltage som taler.
Registreringen for deltagere er åben, billetten koster 7000 rubler. Kom og vær med!
Kilde: habr.com
