Anton Weiss, grundare och chef för Otomato Software, en av initiativtagarna och instruktörerna till den första DevOps-certifieringen i Israel, talade vid förra årets om kaosteori och huvudprinciperna för kaosteknik, och förklarade även hur framtidens ideala DevOps-organisation fungerar.
Vi har tagit fram en textversion av rapporten.
God morgon!
DevOpsDays i Moskva för andra året i rad, det här är min andra gång på den här scenen, många av er är i det här rummet för andra gången. Vad betyder det? Det betyder att DevOps-rörelsen i Ryssland växer, förökar sig, och viktigast av allt betyder det att det är dags att prata om vad DevOps är 2018.
Räck upp handen som tror att DevOps redan är ett yrke 2018? Det finns sådana. Finns det några DevOps-ingenjörer i rummet vars arbetsbeskrivning säger "DevOps Engineer"? Finns det några DevOps-ansvariga i rummet? Det finns inget sådant. DevOps-arkitekter? Också nej. Inte tillräckligt. Är det verkligen sant att ingen säger att de är en DevOps-ingenjör?
Så de flesta av er tycker att detta är ett antimönster? Att ett sådant yrke inte ska finnas? Vi kan tycka vad vi vill, men medan vi funderar går branschen högtidligt framåt till ljudet av DevOps-trumpeten.
Vem har hört talas om ett nytt ämne som heter DevDevOps? Detta är en ny teknik som möjliggör effektivt samarbete mellan utvecklare och devops. Och inte så nytt. Av Twitter att döma började de prata om detta redan för 4 år sedan. Och fram tills nu växer och växer intresset för detta, det vill säga det finns ett problem. Problemet måste lösas.
Vi är kreativa människor, vi är inte bara lugna. Vi säger: DevOps är inte ett tillräckligt omfattande ord, det saknar fortfarande alla möjliga olika intressanta element. Och vi går till våra hemliga laboratorier och börjar producera intressanta mutationer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logiken är järnklädd, eller hur? Vårt leveranssystem fungerar inte, våra system är instabila och våra användare är missnöjda, vi har inte tid att rulla ut mjukvara i tid, vi passar inte in i budgeten. Hur ska vi lösa allt detta? Vi kommer på ett nytt ord! Det kommer att sluta med "Ops" och problemet är löst.
Så jag kallar detta tillvägagångssätt - "Ops, och problemet är löst."
Allt detta bleknar i bakgrunden om vi påminner oss själva om varför vi kom på allt detta. Vi kom på hela den här DevOps-grejen för att göra leverans av programvara och vårt eget arbete i denna process så obehindrat, smärtfritt, effektivt och viktigast av allt, roligt som möjligt.
DevOps växte ur smärta. Och vi är trötta på att lida. Och för att allt detta ska hända, förlitar vi oss på vintergröna metoder: effektivt samarbete, flödesmetoder och viktigast av allt, systemtänkande, för utan det fungerar ingen DevOps.
Vad är ett system?
Och om vi redan pratar om systemtänkande, låt oss påminna oss själva om vad ett system är.
Om du är en revolutionerande hacker, då är systemet helt klart ont för dig. Det är ett moln som hänger över dig och tvingar dig att göra saker du inte vill göra.
Ur systemtänkandets synvinkel är ett system en helhet som består av delar. I denna mening är var och en av oss ett system. De organisationer vi arbetar i är system. Och det du och jag bygger kallas ett system.
Allt detta är en del av ett stort socioteknologiskt system. Och bara om vi förstår hur detta socioteknologiska system fungerar tillsammans, först då kommer vi att verkligen kunna optimera något i denna fråga.
Ur ett systemtänkande har ett system olika intressanta egenskaper. För det första består den av delar, vilket betyder att dess beteende beror på delarnas beteende. Dessutom är alla dess delar också beroende av varandra. Det visar sig att ju fler delar ett system har, desto svårare är det att förstå eller förutsäga dess beteende.
Ur beteendesynpunkt finns det ett annat intressant faktum. Systemet kan göra något som ingen av dess enskilda delar kan göra.
Som Dr Russell Ackoff (en av systemtänkandets grundare) sa är detta ganska lätt att bevisa med ett tankeexperiment. Vem i rummet vet till exempel hur man skriver kod? Det finns många händer, och detta är normalt, eftersom detta är ett av huvudkraven för vårt yrke. Vet du hur man skriver, men kan dina händer skriva kod separat från dig? Det finns människor som kommer att säga: "Det är inte mina händer som skriver koden, det är min hjärna som skriver koden." Kan din hjärna skriva kod separat från dig? Tja, förmodligen inte.
Hjärnan är en fantastisk maskin, vi vet inte ens 10% av hur den fungerar där, men den kan inte fungera separat från systemet som är vår kropp. Och detta är lätt att bevisa: öppna din skalle, ta ut din hjärna, lägg den framför datorn, låt honom 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 separat, betyder det att dess beteende inte bestäms av dess delars beteende. Vad bestäms det av då? Det bestäms av interaktionen mellan dessa delar. Och följaktligen, ju fler delar, desto mer komplexa interaktioner, desto svårare är det att förstå och förutsäga systemets beteende. Och detta gör ett sådant system kaotiskt, eftersom varje, till och med den mest obetydliga, osynliga förändringen i någon del av systemet kan leda till helt oförutsägbara resultat.
Denna känslighet för initiala förhållanden upptäcktes och studerades först av den amerikanske meteorologen Ed Lorenz. Därefter kallades det "fjärilseffekten" och ledde till utvecklingen av en rörelse av vetenskapligt tänkande som kallas "kaosteori". Denna teori blev ett av de stora paradigmskiftena inom 20-talets vetenskap.
Kaosteori
Människor som studerar kaos kallar sig för kaosologer.
Anledningen till denna rapport var faktiskt att jag, när jag arbetade med komplexa distribuerade system och stora internationella organisationer, vid något tillfälle insåg att det är den jag känner som. Jag är en kaosolog. Det här är i grunden ett smart sätt att säga: "Jag förstår inte vad som händer här och jag vet inte vad jag ska göra åt det."
Jag tror att många av er också ofta känner så, så ni är också kaosologer. Jag inbjuder dig till kaosologernas guild. Systemen som ni och jag, kära 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 delar i ett sådant adaptivt system förändras och självorganiserar, reagerar 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 att självorganisera bygger på frivilligt, helt decentraliserat samarbete mellan fria autonoma agenter.
En annan intressant egenskap hos sådana system är att de är fritt skalbara. Vad borde utan tvekan intressera oss, som kaosologer-ingenjörer. Så om vi sa att beteendet hos ett komplext system bestäms av samspelet mellan dess delar, vad ska vi då vara intresserade av? Samspel.
Det finns ytterligare två intressanta fynd.
För det första förstår vi att ett komplext system inte kan förenklas genom att förenkla dess delar. För det andra är det enda sättet att förenkla ett komplext system genom att förenkla interaktionerna mellan dess delar.
Hur interagerar vi? Du och jag ä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 adaptivt system. Följaktligen, för att interagera mer effektivt och enkelt måste vi skapa någon form av protokoll. Det vill säga någon sekvens av symboler och handlingar som kommer att göra utbytet av information mellan oss enklare, mer förutsägbart, mer begripligt.
Jag vill säga att trender mot komplexitet, mot anpassningsförmåga, mot decentralisering, mot kaos kan spåras i allt. Och i systemen som du och jag bygger, och i de system som vi är en del av.
Och för att inte vara ogrundad, låt oss titta på hur systemen som vi skapar förändras.
Du väntade på det här ordet, jag förstår. Vi är på en DevOps-konferens, idag kommer detta ord att höras ungefär hundra tusen gånger och sedan kommer vi att drömma om det på natten.
Mikrotjänster är den första mjukvaruarkitekturen som uppstod som en reaktion på DevOps-praxis, som är utformad för att göra våra system mer flexibla, mer skalbara och säkerställa kontinuerlig leverans. Hur gör hon detta? Genom att minska volymen av tjänster, minska omfattningen av problem som dessa tjänster bearbetar, minska leveranstiden. Det vill säga att vi minskar och förenklar delar av systemet, ökar deras antal, och följaktligen ökar komplexiteten i interaktioner mellan dessa delar alltid, det vill säga nya problem uppstår som vi måste lösa.
Mikrotjänster är inte slutet, mikrotjänster är i allmänhet redan igår, eftersom Serverless kommer. Alla servrar brann ner, inga servrar, inga operativsystem, bara ren körbar kod. Konfigurationer är separata, tillstånd är separata, allt styrs av händelser. Skönhet, renlighet, tystnad, inga händelser, ingenting händer, fullständig ordning.
Var är komplexiteten? Svårigheten ligger förstås i interaktionerna. Hur mycket kan en funktion göra på egen hand? Hur samverkar det med andra funktioner? Meddelandeköer, databaser, balanserare. Hur återskapar man en händelse när ett fel inträffade? Många frågor och få svar.
Microservices och Serverless är vad vi nördiga hipsters kallar Cloud Native. Allt handlar om molnet. Men molnet är också i sig begränsad i sin skalbarhet. Vi är vana vid att se det som ett distribuerat system. Faktiskt, var bor molnleverantörernas servrar? I datacenter. Det vill säga att vi har en slags centraliserad, mycket begränsad, distribuerad modell här.
Idag förstår vi att Internet of Things inte längre bara är stora ord som även enligt blygsamma förutsägelser väntar miljarder enheter anslutna till Internet under de kommande fem till tio åren. En enorm mängd användbar och värdelös data som kommer att slås samman i molnet och laddas upp från molnet.
Molnet kommer inte att hålla, så vi pratar allt mer om något som kallas edge computing. Eller jag gillar också den underbara definitionen av "fog computing". Den är höljd i romantikens och mystikens mystik.
Dimdatorer. Poängen är att moln är centraliserade klumpar av vatten, ånga, is och stenar. Och dimma är vattendroppar som är utspridda runt omkring oss i atmosfären.
I dimparadigmet görs det mesta av arbetet av dessa droppar helt autonomt eller i samarbete med andra droppar. Och de vänder sig till molnet först när de verkligen blir riktigt pressade.
Det vill säga återigen decentralisering, autonomi, och naturligtvis förstår många av er redan vart allt detta är på väg, eftersom du inte kan prata om decentralisering utan att nämna blockkedjan.
Det finns de som tror, det är de som har investerat i kryptovaluta. Det finns de som tror men är rädda, som jag till exempel. Och det finns de som inte tror. Här kan man behandla olika. Det finns teknik, en ny okänd sak, det finns problem. Som all ny teknik väcker den fler frågor än den svarar.
Hypen kring blockchain är förståelig. Guldrushen åsido, själva tekniken har anmärkningsvärda löften om en ljusare framtid: mer frihet, mer autonomi, distribuerat globalt förtroende. Vad ska man inte vilja?
Följaktligen börjar fler och fler ingenjörer runt om i världen att utveckla decentraliserade applikationer. Och detta är en kraft som inte kan avfärdas genom att bara säga: "Ahh, blockchain är bara en dåligt implementerad distribuerad databas." Eller som skeptiker gillar att säga: "Det finns inga riktiga applikationer för blockchain." Om man tänker efter, för 150 år sedan sa de samma sak om elektricitet. Och de hade till och med rätt på vissa sätt, för det som elektriciteten möjliggör idag var inte på något sätt möjligt på 19-talet.
Förresten, vem vet vilken typ av logotyp som finns på skärmen? Det här är Hyperledger. Detta är ett projekt som utvecklas under The Linux Foundations regi och inkluderar en uppsättning blockchain-teknologier. Detta är verkligen styrkan i vår öppen källkodsgemenskap.
Kaosteknik
Så systemet som vi utvecklar blir mer och mer komplext, mer och mer kaotiskt och mer och mer adaptivt. Netflix är pionjärer inom mikroservicesystem. De var bland de första att förstå detta, de utvecklade en uppsättning verktyg som de kallade Simian Army, varav den mest kända var . Han definierade vad som blev känt som .
Förresten, i arbetet med rapporten översatte vi till och med den här texten till ryska, så gå till , läsa, kommentera, skälla ut.
I korthet säger principerna för kaosteknik följande. Komplexa distribuerade system är i sig oförutsägbara och i sig buggiga. 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 för samma anpassningsförmåga, just denna förmåga till självorganisering, för överlevnad.
Och det förändrar allt. Inte bara hur vi lanserar system i produktion, utan också hur vi utvecklar dem, hur vi testar dem. Det finns ingen process av stabilisering eller frysning av koden, tvärtom, det finns en konstant process av destabilisering. Vi försöker döda systemet och se att det fortsätter att överleva.
Protokoll för distribuerad systemintegration
Följaktligen kräver detta att våra system förändras på något sätt. För att de ska bli mer stabila behöver de några nya protokoll för interaktion mellan sina delar. Så att dessa delar kan komma överens och komma till någon form av självorganisering. Och alla möjliga nya verktyg, nya protokoll uppstår, som jag kallar "protokoll för interaktion mellan distribuerade system."
Vad jag pratar om? Först projektet . Vissa försöker skapa ett allmänt distribuerat spårningsprotokoll, vilket är ett absolut oumbärligt verktyg för att felsöka komplexa distribuerade system.
Ytterligare - . Vi säger att vi inte kan förutsäga vad som kommer att hända med systemet, det vill säga vi behöver öka dess observerbarhet, observerbarhet. Opentracing tillhör en familj av verktyg som ger observerbarhet till våra system. Men vi behöver observerbarhet för att avgöra om systemet beter sig som vi förväntar oss eller inte. Hur definierar vi förväntat beteende? Genom att definiera någon form av policy, någon uppsättning regler. Open Policy Agent-projektet arbetar med att definiera denna uppsättning regler över ett spektrum som sträcker sig från åtkomst till resursallokering.
Som vi sa är våra system allt mer händelsestyrda. Serverless är ett bra exempel på händelsedrivna system. För att vi ska kunna överföra händelser mellan system och spåra dem behöver vi något gemensamt språk, något gemensamt protokoll för hur vi pratar om händelser, hur vi överför dem till varandra. Detta är vad ett projekt kallade .
Den ständiga strömmen av förändringar som sköljer över våra system och ständigt destabiliserar dem, är en kontinuerlig ström av mjukvaruartefakter. För att vi ska kunna upprätthålla detta konstanta flöde av förändringar behöver vi något slags gemensamt protokoll genom vilket vi kan prata om vad en mjukvaruartefakt är, hur den testas, vilken verifiering den har passerat. Detta är vad ett projekt kallade . Det vill säga ett vanligt metadataprotokoll för programvaruartefakter.
Och slutligen, om vi vill att våra system ska vara helt oberoende, adaptiva och självorganiserade, måste vi ge dem rätten till självidentifiering. Projektet kallas Det är precis vad han gör. Detta är också ett projekt i regi av Cloud Native Computing Foundation.
Alla dessa projekt är unga, de behöver alla vår kärlek, vår validering. Allt detta är öppen källkod, vår testning, vår implementering. De visar oss vart tekniken är på väg.
Men DevOps har aldrig i första hand handlat om teknik, det har alltid handlat om samarbete mellan människor. Och följaktligen, om vi vill att de system vi utvecklar ska förändras, måste vi själva förändras. Faktum är att vi förändras ändå, vi har inte så mycket val.
Det finns en underbar Den brittiska författaren Rachel Botsman, där hon skriver om förtroendets utveckling genom mänsklighetens historia. Hon säger att till en början, i primitiva samhällen, var tillit lokal, det vill säga vi litade bara på dem vi kände personligen.
Sedan var det en väldigt lång period – en mörk tid då förtroendet centraliserades, då vi började lita på människor som vi inte känner på grund av att vi tillhör samma offentliga eller statliga institution.
Och detta är vad vi ser i vår moderna värld: förtroendet blir mer och mer distribuerat och decentraliserat, och det bygger på informationsflödenas frihet, på tillgången på information.
Om du tänker efter så är just denna tillgänglighet, som gör detta förtroende möjligt, vad du och jag implementerar. Det betyder att både sättet vi samarbetar på och sättet vi gör det måste förändras, eftersom gamla centraliserade, hierarkiska IT-organisationer inte längre fungerar. De börjar dö av.
DevOps Organisation Fundamentals
Den ideala DevOps-organisationen för framtiden är ett decentraliserat, adaptivt system som består av autonoma team, vart och ett bestående av autonoma individer. Dessa team är utspridda runt om i världen och samarbetar effektivt med varandra med hjälp av asynkron kommunikation, med mycket transparenta kommunikationsprotokoll. Väldigt vackert, eller hur? En mycket vacker framtid.
Naturligtvis är inget av detta möjligt utan kulturell förändring. Vi måste ha transformerande ledarskap, personligt ansvar, intern motivation.
Detta är grunden för DevOps-organisationer: informationstransparens, asynkron kommunikation, transformationsledarskap, decentralisering.
zapping
Systemen vi är en del av och de vi bygger är allt mer kaotiska, och det är svårt för oss människor att klara av denna tanke, det är svårt att ge upp illusionen av kontroll. Vi försöker fortsätta att kontrollera dem, och det leder ofta till utbrändhet. Jag säger detta av egen erfarenhet, jag blev också bränd, jag blev också inaktiverad av oförutsedda fel i produktionen.
Utbrändhet uppstår när vi försöker kontrollera något som i sig är okontrollerbart. När vi brinner ut tappar allt sin mening eftersom vi tappar lusten att göra något nytt, vi blir defensiva och börjar försvara det vi har.
Ingenjörsyrket är, som jag ofta vill påminna mig själv, först och främst ett kreativt yrke. Om vi tappar lusten att skapa något, då förvandlas vi till aska, förvandlas till aska. Människor bränner ut, hela organisationer bränner ut.
Enligt min mening är det bara att acceptera kaosets kreativa kraft, bara att bygga samarbete enligt dess principer som hjälper oss att inte förlora det som är bra i vårt yrke.
Det här är vad jag önskar dig: att älska ditt jobb, att älska det vi gör. Den här världen livnär sig på information, vi har äran att mata den. Så låt oss studera kaos, låt oss vara kaosologer, låt oss skapa värde, skapa något nytt, ja, problem, som vi redan har fått reda på, är oundvikliga, och när de dyker upp kommer vi helt enkelt att säga "Ops!" Och problemet är löst.
Vad annat än Chaos Monkey?
Faktum är att alla dessa instrument är så unga. Samma Netflix byggde verktyg åt sig själva. Bygg dina egna verktyg. Läs principerna för kaosteknik och lev upp till dessa principer 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 och börja bryta ner dem och se hur de håller. Detta kommer först. Och du kan leta efter verktyg. Det finns alla typer av projekt.
Jag förstod inte riktigt ögonblicket när du sa att systemet inte kan förenklas genom att förenkla dess komponenter, och gick genast vidare till mikrotjänster, som förenklar systemet genom att förenkla själva komponenterna och komplicera interaktioner. Dessa är i huvudsak två delar som motsäger varandra.
Det stämmer, mikrotjänster är ett mycket kontroversiellt ämne i allmänhet. Faktum är att förenkling av delar ökar flexibiliteten. Vad tillhandahåller mikrotjänster? De ger oss flexibilitet och snabbhet, men de ger oss verkligen inte enkelhet. De ökar svårigheten.
Så i DevOps-filosofin är mikrotjänster inte så bra?
Alla varor har en baksida. Fördelen är att det ökar flexibiliteten, vilket gör att vi kan göra ändringar snabbare, men det ökar komplexiteten och därmed bräckligheten i hela systemet.
Ändå, vad är mer vikt: på att förenkla interaktion eller på att förenkla delar?
Tyngdpunkten ligger naturligtvis på att förenkla interaktioner, för om vi ser på detta utifrån hur vi arbetar med dig, så måste vi först och främst vara uppmärksamma på att förenkla interaktioner, och inte på att förenkla arbetet av var och en av oss separat. För att förenkla arbetet innebär att förvandlas till robotar. Här på McDonalds fungerar det normalt när du har instruktioner: här lägger du burgaren, här häller du såsen på den. Detta fungerar inte alls i vårt kreativa arbete.
Är det sant att allt du sa lever i en värld utan konkurrens, och kaoset där är så snällt, och det finns inga motsättningar inom detta kaos, ingen vill äta eller döda någon? Hur ska det gå för konkurrens och DevOps?
Det beror väl på vilken typ av tävling vi pratar om. Handlar det om konkurrens på arbetsplatsen eller konkurrens mellan företag?
Om konkurrensen av tjänster som finns eftersom tjänster inte är flera företag. Vi skapar en ny typ av informationsmiljö, och vilken miljö som helst kan inte leva utan konkurrens. Det är konkurrens överallt.
Samma Netflix, vi tar dem som en förebild. Varför kom de på detta? För de behövde vara konkurrenskraftiga. Denna flexibilitet och rörelsehastighet är just det mycket konkurrenskraftiga kravet, det introducerar kaos i våra system. Det vill säga, kaos är inte något vi medvetet gör för att vi vill det, det är något som händer för att världen kräver det. Vi måste bara anpassa oss. Och kaos, det är just resultatet av konkurrens.
Betyder detta att kaos är frånvaron av mål, så att säga? Eller de där målen som vi inte vill se? Vi är i huset och förstår inte andras mål. Konkurrensen beror faktiskt på att vi har tydliga mål och vi vet var vi kommer att hamna vid varje nästa ögonblick. Detta är ur min synvinkel kärnan i DevOps.
Också en titt på frågan. Jag tror att vi alla har samma mål: att överleva och göra det med
största nöje. Och konkurrensmålet för alla organisationer är detsamma. Överlevnad sker ofta genom konkurrens, det finns inget du kan göra åt det.
Årets konferens kommer att äga rum den 7 december på Technopolis. Vi tar emot ansökningar om rapporter fram till den 11 november. oss om du vill prata.
Registreringen för deltagare är öppen, biljetter kostar 7000 XNUMX rubel. Gå med oss!
Källa: will.com