DevOps och Kaos: programvaruleverans i en decentraliserad värld

Grundare och direktör för "Otomato Software", en av initiativtagarna och instruktörerna till den första DevOps-certifieringen i Israel, Anton Weiss, talade förra året om DevOpsDays Moskva kaosteorin och de viktigaste principerna för kaosingenjöring, samt förklarade hur den perfekta DevOps-organisationen i framtiden är uppbyggd.

Vi har förberett en textversion av föreläsningen.

God morgon!

DevOpsDays i Moskva för andra året i rad, jag är här på denna scen för andra gången, många av er är här i detta rum för andra gången. Vad betyder det? Det betyder att DevOps-rörelsen i Ryssland växer, multipliceras, och framför allt betyder det att det är dags att prata om vad DevOps är år 2018.

Lyft upp händerna de som tror att DevOps år 2018 redan är ett yrke? Finns det sådana? Finns det DevOps-ingenjörer i rummet som har "DevOps-ingenjör" i sin jobbeskrivning? Finns det DevOps-chefer? Det verkar inte finnas. DevOps-arkitekter? Inte heller. Inte så många. Så, är det ingen som har skrivit att de är DevOps-ingenjörer?

Så, de flesta av er tycker att det är ett antipattern? Att det inte borde finnas ett sådant yrke? Vi kan tänka vad vi vill, men medan vi tänker, går industrin framåt under ljudet av DevOps-trumpeten.

Har någon hört talas om det nya ämnet som kallas DevDevOps? Det är en ny metodik som möjliggör effektivt samarbete mellan utvecklare och DevOps. Egentligen är det inte så nytt. Om man dömer av Twitter, så började man prata om det för 4 år sedan. Och intresset växer fortfarande, det vill säga problemet finns kvar. Problemet måste lösas.

Vi är kreativa människor, vi lugnar oss inte så enkelt. Vi säger: DevOps är inte ett tillräckligt omfattande ord, det saknas olika intressanta element. Och vi går till våra hemliga laboratorier och börjar skapa nyfikna mutationer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

Logiken är orubblig, eller hur? Vårt leveranssystem är icke-funktionellt, våra system är instabila och användarna är missnöjda, vi hinner inte lansera mjukvara i tid, vi håller inte budgeten. Hur ska vi lösa allt detta? Vi kommer att hitta på ett nytt ord! Det kommer att sluta på "Ops", och så är problemet löst.

Så kallar jag detta tillvägagångssätt — "Ops, och problemet är löst".

All of this fades into the background when we remind ourselves why we came up with all this. We created all this DevOps to make software delivery and our own work in this process as seamless, painless, efficient, and most importantly, enjoyable as possible.

DevOps grew out of pain. And we were tired of suffering. For this to happen, we rely on evergreen practices: effective collaboration, flow practices, and most importantly, systemic thinking, because without it, no DevOps works.

What is a system?

And since we are talking about systemic thinking, let's remind ourselves what a system is.

If you are a revolutionary hacker, then for you, the system is unequivocally evil. It's a cloud that looms over you and forces you to do things you don't want to do.

From the perspective of systemic thinking, a system is a whole made up of parts. In this sense, each of us is a system. The organizations we work in are systems. And what we are building together is called a system.

All of this is part of one large sociotechnical system. Only if we understand how this sociotechnical system works together can we truly optimize anything in this matter.

From the perspective of systemic thinking, a system has various interesting properties. Firstly, it is made up of parts, which means that its behavior depends on the behavior of these parts. Moreover, all parts are interdependent. Thus, the more parts a system has, the harder it is to understand or predict its behavior.

From the perspective of behavior, there is another interesting fact. A system can do something that none of its individual parts can do.

As Dr. Russell Ackoff (one of the founders of systemic thinking) said, this can be easily proven through a thought experiment. For example, who in the room knows how to code? Many hands, and that's normal because this is one of the basic requirements of our profession. You can code, but can your hands write code separately from you? There are those who would say, "My hands don't write code, my brain writes code." But can the brain write code separately from you? Well, probably not.

Hjärnan är en fantastisk maskin, vi vet knappt 10 % av hur den fungerar, men den kan inte fungera separat från det system som vår kropp utgör. Och det är lätt att bevisa: öppna ditt skalle, ta ut hjärnan därifrån, lägg den framför en dator och låt den försöka skriva något enkelt. "Hello, world" i Python, till exempel.

Om ett system kan göra något som ingen av dess delar kan göra var för sig, betyder det att dess beteende inte bestäms av beteendet hos dess delar. Vad bestäms det då av? Det bestäms av interaktionen mellan dessa delar. Ju fler delar det finns, desto mer komplexa blir interaktionerna, och desto svårare blir det att förstå och förutsäga systemets beteende. Detta gör systemet kaotiskt, eftersom varje, även den minsta, osynliga förändringen i någon del av systemet kan leda till fullständigt oförutsägbara resultat.

Denna känslighet för initiala förhållanden upptäcktes och studerades först av den amerikanske meteorologen Edward Lorenz. Senare fick den namnet "fjärilseffekten" och ledde till utvecklingen av en vetenskaplig rörelse som kallas "kaosteori". Denna teori blev en av de grundläggande paradigmskiftena inom 1900-talets vetenskap.

Kaosteori

Människor som sysslar med att studera kaos kallar sig själva kaosologer.

Anledningen till den här presentationen var att jag, när jag arbetade med komplexa distribuerade system och stora internationella organisationer, vid något tillfälle insåg att detta är vad jag känner att jag är. Jag är en kaosolog. Det är i grunden en intrikat sätt att säga: "Jag förstår inte vad som händer här och vet inte vad jag ska göra med det."

Jag tror att många av er ofta känner er på samma sätt, så ni är också kaosologer. Jag inbjuder er till gilden av kaosologer. De system som vi, kära kollegor kaosologer, kommer att studera kallas "komplexa adaptiva system".

Vad är anpassningsförmåga? Anpassningsförmåga innebär att det individuella och kollektiva beteendet hos delarna i ett sådant anpassningsbart system förändras och självorganiserar sig som svar på händelser eller kedjor av mikrohändelser i systemet. Det vill säga, systemet anpassar sig till förändringar genom självorganisering. Och denna förmåga till självorganisering baseras på frivilligt, helt decentraliserat samarbete mellan fria autonoma agenter.

En annan intressant egenskap hos sådana system är att de kan skalas fritt. Detta är något som vi, som ingenjörer inom kaosteori, definitivt bör vara intresserade av. Så om vi säger att beteendet hos ett komplext system definieras av interaktionen mellan dess delar, vad bör då intressera oss? Interaktionen.

Det finns ytterligare två intressanta slutsatser.


För det första förstår vi att det är omöjligt att förenkla ett komplext system genom att förenkla dess delar. För det andra är den enda metoden för att förenkla ett komplext system att förenkla interaktionerna mellan dess delar.

Hur interagerar vi? Vi är alla delar av ett stort informationssystem som kallas mänskligt samhälle. Vi interagerar genom ett gemensamt språk, om vi har det, om vi hittar det.

Men språket i sig är ett komplext anpassningsbart system. Därför, för att interagera mer effektivt och enkelt, behöver vi skapa vissa protokoll. Det vill säga en viss sekvens av symboler och handlingar som gör informationsutbytet mellan oss enklare, mer förutsägbart och mer förståeligt.

Jag vill säga att tendenser mot komplexitet, anpassningsförmåga, decentralisering och kaotiska egenskaper kan ses överallt. Både i de system vi bygger och i de system vi är en del av.

Och för att inte bara tala i allmänna termer, låt oss titta på hur de system vi skapar förändras.

Du har väntat på det här ordet, det förstår jag. Vi är på en DevOps-konferens, idag kommer det här ordet att nämnas någonstans hundratusen gånger och sedan drömma om oss på natten.

Mikrotjänster är den första programvaruarkitekturen som uppstod som en reaktion på DevOps-praktiker, och syftar till att göra våra system mer flexibla, mer skalbara och att möjliggöra kontinuerlig leverans. Hur gör den det? Genom att minska volymen av tjänster, begränsa gränserna för de problem som dessa tjänster hanterar och förkorta leveranstiden. Det vill säga, vi minskar och förenklar delar av systemet, ökar deras antal, vilket innebär att interaktionernas komplexitet ständigt ökar, vilket skapar nya problem som vi måste lösa.

Mikrotjänster är inte slutet, mikrotjänster är faktiskt redan igår, eftersom Serverless träder fram. Alla servrar har brunnit, det finns inga servrar, inga operativsystem, bara ren körbar kod. Konfigurationer är separata, tillstånd är separata, allt hanteras av händelser. Skönhet, renhet, tystnad, inga händelser, inget händer, fullständig ordning.

Var ligger komplexiteten? Komplexiteten ligger, förstås, i interaktionerna. Hur mycket kan en funktion göra på egen hand? Hur interagerar den med andra funktioner? Meddelandeköer, databaser, belastningsbalanserare. Hur återskapar man en händelse när ett fel inträffar? Massor av frågor och få svar.

Mikrotjänster och Serverless är allt det som vi, datorkänsliga, kallar Cloud Native. Det handlar allt om molnet. Men molnet är i sin kärna också begränsat i skala. Vi är vana vid att tänka på det som ett distribuerat system. Men där lever egentligen servrarna hos molnleverantörerna? I datacenters. Det innebär att vi här har en centralt begränsad, mycket distribuerad modell.

Idag förstår vi att internet of things inte bara är tomma ord, utan att enligt blygsamma förutsägelser väntar miljarder enheter som kopplas till internet under de kommande fem till tio åren. En enorm mängd användbara och värdelösa data som kommer att strömma in och ut ur molnet.

Molnet kommer inte att klara det, därför pratar vi allt mer om det som kallas "edge computing". Eller så gillar jag den fantastiska definitionen "fog computing". Den är insvept i mystik, romantik och mysterium.

Dimhöga beräkningar. Det handlar om att moln är centrala ansamlingar av vatten, ånga, is och stenar. Dimma är droppar av vatten som är spridda runt omkring oss i atmosfären.

I det dimmiga paradigmet utför dessa droppar det mesta av arbetet helt autonomt eller i samarbete med andra droppar. De vänder sig till molnet endast när det verkligen är nödvändigt.

Det handlar alltså om decentralisering, autonomi, och många av er förstår redan vart detta är på väg, eftersom man inte kan prata om decentralisering utan att nämna blockchain.

Det finns de som tror på det, de som investerat i kryptovaluta. Det finns de som tror, men är tveksamma, som jag till exempel. Och så finns det de som inte tror. Man kan ha olika inställningar till detta. Det finns teknologi, en ny otydlig sak, och det finns problem. Som med all ny teknologi väcker den fler frågor än den ger svar.

Hajpen kring blockchain är förståelig. Även om man bortser från guldfebern, ger teknologin i sig fantastiska löften om en ljus framtid: mer frihet, mer autonomi, distribuerat globalt förtroende. Vad finns det inte att vilja ha?

Allt fler ingenjörer över hela världen börjar utveckla decentraliserade applikationer. Och detta är en kraft som man inte kan bortse ifrån genom att säga: 'Åh, blockchain är bara en dåligt implementerad distribuerad databas.' Eller som skeptikerna gärna säger: 'Det finns inga verkliga tillämpningar för blockchain.' Om man tänker efter, så sa man samma sak för 150 år sedan om elektricitet. Och de hade faktiskt rätt på vissa punkter, eftersom det som elektriciteten möjliggör idag var helt orealistiskt för 1800-talet.

Förresten, vet någon vad logotypen på skärmen är? Det är Hyperledger. Det är ett projekt som utvecklas under auspices av The Linux Foundation, som omfattar en uppsättning blockchain-teknologier. Det är verkligen kraften i vårt öppna källkodssamhälle.

Kaosingenjörskap

Så systemet som vi utvecklar blir allt mer komplext, allt mer kaotiskt och allt mer adaptivt. Netflix är pionjärer inom mikrotjänstsystem. De var bland de första som förstod detta, och de utvecklade en uppsättning verktyg som de kallade Simian Army, den mest kända av dem är Chaos Monkey. Det definierade vad som blev känt som «principer för kaosengineering».

För övrigt, under arbetet med presentationen översatte vi faktiskt den här texten till ryska, så kolla gärna in länken, läs, kommentera, kritisera.

Kort sagt säger principerna för kaosengineering att komplexa distribuerade system i grunden är oförutsägbara, och de innehåller i sin natur fel. Fel är oundvikliga, vilket innebär att vi måste acceptera dessa fel och arbeta med dessa system på ett helt annat sätt.

Vi måste själva försöka införa dessa fel i våra produktionssystem för att testa våra system på just den anpassningsförmågan, den kapaciteten för självorganisering, för överlevnad.

Och det förändrar allt. Inte bara hur vi sätter system i produktion, utan också hur vi utvecklar dem, hur vi testar dem. Det finns ingen process för stabilisering, ingen kodfrysning; tvärtom finns det en ständig process av destabilisering. Vi försöker döda systemet och se om det fortsätter att överleva.

För protokoll för integration av distribuerade system

Detta kräver därefter att våra system också måste förändras på något sätt. För att de ska bli mer motståndskraftiga behöver de nya protokoll för interaktion mellan sina delar. Så att dessa delar kan kommunicera och nå någon form av självorganisering. Nya verktyg och protokoll dyker upp, som jag kallar "protokoll för interaktion av distribuerade system".

Vad pratar jag om? Först och främst projektet Opentracing. Ett försök att skapa ett gemensamt protokoll för distribuerad spårning, vilket är ett helt ovärderligt verktyg för att felsöka komplexa distribuerade system.

Därefter — Open Policy Agent. Vi säger att vi inte kan förutsäga vad som kommer att hända med systemet, vilket innebär att vi måste öka dess observabilitet. Opentracing tillhör familjen av verktyg som ger observabilitet till våra system. Men vi behöver observabilitet för att avgöra om systemet beter sig som vi förväntar oss eller inte. Hur kan vi avgöra det förväntade beteendet? Genom att definiera någon form av politik, någon uppsättning regler. Projektet Open Policy Agent sysslar med att definiera denna uppsättning regler över ett brett spektrum: från åtkomst till resursallokering.

Som vi har sagt, våra system blir alltmer händelsestyrda. Serverless är ett utmärkt exempel på händelsestyrda system. För att kunna överföra händelser mellan systemen och spåra dem behöver vi ett gemensamt språk, ett gemensamt protokoll för hur vi pratar om händelser, hur vi överför dem till varandra. Det här hanteras av projektet som heter Cloudevents.

Den kontinuerliga strömmen av förändringar som flödar genom våra system, ständigt destabilisera dem, är en kontinuerlig ström av programvaruartefakter. För att vi ska kunna stödja denna ständiga ström av förändringar, behöver vi ett gemensamt protokoll som gör att vi kan diskutera vad som är ett programvaruartefakt, hur det har verifierats och vilken verifiering det har genomgått. Det här hanteras av projektet som heter Grafeas. Det vill säga ett gemensamt protokoll för metadata av programvaruartefakter.

Och slutligen, om vi vill att våra system ska vara helt självständiga, adaptiva och självorganiserade, måste vi ge dem rätt till självidentifiering. Projektet som heter spiffe handlar just om detta. Det är också ett projekt under Cloud Native Computing Foundation.

Alla dessa projekt är unga och de behöver all vår kärlek, vår verifiering. De är alla öppna källkodsprojekt, vår testning, vår implementation. De visar oss i vilken riktning teknologin rör sig.

Men DevOps har aldrig handlat om teknologi i första hand, det har alltid handlat om samarbete mellan människor. Och enligt det, om vi vill att de system vi utvecklar ska förändras, måste vi förändras själva. Egentligen förändras vi redan, vi har inte mycket val.

Det finns en fantastisk en bok bok av den brittiska författaren Rachel Botsman, där hon skriver om evolutionen av förtroende genom mänsklighetens historia. Hon säger att i början, i ursprungliga samhällen, var förtroende lokalt, det vill säga vi litade bara på dem vi kände personligen.

Därefter följde en mycket lång period – en mörk tid, när förtroende var centraliserat, när vi började lita på människor vi inte känner baserat på att vi tillhör samma sociala eller statliga institution.

Och här är vad vi ser i vår moderna värld: förtroendet blir allt mer distribuerat och decentraliserat, och det baseras på friheten i informationsflöden, på tillgången till information.

Om man tänker efter så är det just denna tillgång, som gör detta förtroende möjligt, som vi åstadkommer. Det betyder att sättet vi samarbetar och hur vi gör det måste förändras, eftersom centraliserade, hierarkiska IT-organisationer av gammal sort slutar fungera. De börjar avta.

Grunderna i DevOps-organisationer

Den perfekta DevOps-organisationen i framtiden är ett decentraliserat, adaptivt system bestående av autonoma team, där varje team består av självständiga individer. Dessa team är spridda över hela världen, de samarbetar effektivt med varandra genom asynkron kommunikation, med hjälp av högtransparenta informationsutbyteprotokoll. Mycket vackert, eller hur? En mycket vacker framtid.

Självklart är allt detta omöjligt utan kulturella förändringar. Vi måste ha transformationsledarskap, personlig ansvarighet och inre motivation.

Detta är grunden för DevOps-organisationer: transparens i information, asynkron kommunikation, transformationsledarskap, decentralisering.

Utmattning

De system vi är en del av, och de vi bygger, blir alltmer kaotiska, och för oss människor är det svårt att hantera denna tanke, svårt att ge upp illusionen om kontroll. Vi försöker fortsätta kontrollera dem, och detta leder ofta till utmattning. Jag säger detta av egen erfarenhet; jag har också bränt mig, jag är också ett offer för oförutsedda driftsstörningar.

Utmattning inträffar när vi försöker kontrollera det som i sin natur inte kan kontrolleras. När vi blir utmattade förlorar allt sin mening eftersom vi mister lusten att göra något nytt, vi går i försvarsställning och börjar försvara det som finns.

Ingenjörsyrket, som jag ofta påminner mig själv om, är först och främst ett kreativt yrke. Om vi tappar lusten att skapa något så förvandlas vi till aska, till stoft. Människor blir utmattade, hela organisationer blir utmattade.

Enligt min åsikt är det endast genom att omfamna den konstruktiva kraften i kaos och bygga partnerskap baserat på dess principer som vi kan bevara det goda i vårt yrke.

Det önskar jag er: att älska ert arbete, att älska det vi gör. Denna värld lever på information, och vi har äran att ge den näring. Låt oss därför studera kaoset, bli kaosologer och skapa värde, skapa något nytt. Problem, som vi redan har konstaterat, är oundvikliga och när de dyker upp, kommer vi helt enkelt att säga 'Ops!', och problemet är löst.

Vad finns det mer än Chaos Monkey?

I själva verket är alla dessa verktyg ganska unga. Netflix utvecklade sina verktyg för sina behov. Bygg verktyg som passar er. Läs om principerna för kaosingenjöring och följ dem, istället för att försöka hitta andra verktyg som någon annan redan har byggt.

Försök att förstå hur dina system går sönder, börja bryta dem och se hur de tål stöten. Det är det första steget. Verktyg kan man alltid leta efter. Det finns massor av olika projekt.

Jag förstod inte riktigt vad du menade när du sa att man inte kan förenkla systemet genom att förenkla dess komponenter, och direkt efter gick över till mikrotjänster som just förenklar systemet genom att förenkla komponenterna men komplicerar interaktionerna. Det är egentligen två delar som motsäger varandra.

Helt korrekt, mikrotjänster är en mycket motsägelsefull fråga. Faktum är att förenkling av delar ökar flexibiliteten. Vad ger mikrotjänster? De ger oss flexibilitet och hastighet, men de ger definitivt ingen enkelhet. De ökar komplexiteten.

Så i DevOps-filosofin är mikrotjänster inte så mycket en tillgång?

Som med allt gott finns det en baksida. Det finns fördelar: det ökar flexibiliteten, ger oss möjlighet att göra förändringar snabbare, men det ökar också komplexiteten och därmed skörheten i hela systemet.

Vad fokuserar vi mer på: att förenkla interaktionen eller att förenkla delarna?

Fokus ligger onekligen på att förenkla interaktionen, för om vi ser på det ur vår arbets synvinkel, så är det framför allt viktigt att fokusera på att förenkla interaktionerna, inte att förenkla arbetet för varje enskild individ. För att förenkla arbetet innebär att bli till robotar. Det fungerar bra på McDonald's, där du är föreskriven: här lägger du hamburgaren, här häller du såsen på. Det fungerar överhuvudtaget inte i vårt kreativa arbete.

Är det verkligen så att allt ni berättade lever i en värld utan konkurrens, där kaoset är vänligt, och det inte finns några motsägelser inom detta kaos, ingen vill äta upp eller döda varandra? Hur ska konkurrens och DevOps samexistera?

Det beror på vilken typ av konkurrens vi pratar om. Är det konkurrens på arbetsplatsen eller mellan företag?

Om konkurrensen mellan tjänster, för tjänster är inte bara några företag. Vi skapar en ny typ av informationsmiljö, och ingen miljö kan existera utan konkurrens. Överallt finns det konkurrens.

Ta till exempel Netflix som en modell. Varför skapade de detta? För att de behövde vara konkurrenskraftiga. Denna flexibilitet och hastighet är just det konkurrenskrav och bidrar till kaos i våra system. Så kaos är inte något vi medvetet skapar för att vi vill ha det, det är en följd av det som världen kräver. Vi måste bara anpassa oss. Kaos är i själva verket en följd av konkurrens.

Betyder det att kaos är avsaknad av mål, eller är det de mål vi inte vill se? Vi sitter i vår bubbla och förstår inte andras mål. Konkurrens handlar faktiskt om att vi har tydliga mål, och vi vet vart vi är på väg vid varje given tidpunkt. Ur min synvinkel är detta kärnan i DevOps.

Det är också en synvinkel på frågan. Jag tror att vi alla har ett gemensamt mål: att överleva och göra det med
största möjliga nöje. Den konkurrensmål för vilken organisation som helst är densamma. Överlevnad sker ofta i konkurrenssituationer, det är något vi inte kan komma bort ifrån.

I år kommer konferensen DevOpsDays Moskva att hållas den 7 december i "Technopolis". Vi tar emot anmälningar för föredrag fram till den 11 november. Skriv till oss om du vill tala.

Registreringen för deltagare är öppen, biljetten kostar 7000 rubel. Anslut er!

Källa: habr.com