Återigen om DevOps och SRE

Baserat på diskussionen i chatten AWS Minsk Community

Den senaste tiden har det pågått riktiga strider om definitionen av begreppen DevOps och SRE.
Trots att diskussionerna om detta ämne redan känns uttjatade, även för mig, har jag beslutat att lyfta fram min synpunkt för Habragemenskapen. De som är intresserade, välkomna under katten. Låt oss börja om på nytt!

Bakgrund

Så, i gamla tider fanns det ett separat team av mjukvaruutvecklare och serveradministratörer. De förstnämnda skrev kod, medan de senare, med olika varma och kärleksfulla ord till de första, konfigurerade servrar, och då och då kom till utvecklarna och fick det uttömmande svaret: "Det fungerar på min maskin." Företaget väntade på programvaran, allt stod still, gick sönder ibland, och alla var stressade. Särskilt den som betalade för allt detta kaos. Den goda gamla lampans tid. Men ni vet redan var DevOps kommer ifrån.

Födelset av DevOps-praktiker

Senare kom allvarliga män och sa - detta är ingen industri, så här kan man inte jobba. Och de tog med sig livscykelmodeller. Här är till exempel V-modellen.

Så, vad ser vi? Affären kommer med en koncept, arkitekterna utformar lösningar, utvecklarna skriver kod, och därefter - en krasch. Någon testar produkten på något sätt, någon på något sätt levererar den till slutanvändaren, och någonstans i slutet av denna mirakelmodell sitter en ensam affärsbeställare och väntar på lovad väder vid havet. Slutsatsen var - det behövs metoder som kan etablera denna process. De bestämde sig för att skapa praktiker som skulle genomföra dem.

En poetisk avstickare om vad som är praktik
Med praktik menar jag en koppling mellan teknik och disciplin. Exempel - praktik i att beskriva infrastruktur som kod med terraform. Disciplin handlar om hur man beskriver infrastrukturen med kod, den finns i utvecklarens huvud, medan tekniken är själva terraform.

De bestämde sig för att kalla dem DevOps-praktiker – jag tror de syftade på från utveckling till drift. De kom på olika komplicerade saker – CI/CD-praktiker, praktiker baserade på IaC-principen, tusentals av dem. Och så började det, utvecklarna skriver kod, DevOps-ingenjörer omvandlar systembeskrivningen i kodform till fungerande system (ja, koden är tyvärr bara en beskrivning, men inte en konkretisering av systemet), leveransen snurrar, och så vidare. Tidigare administratörer, som bemästrade de nya praktikerna, omklassificerade stolt sig själva till DevOps-ingenjörer, och allt satte fart. Och det blev kväll, och det blev morgon… förlåt, inte därifrån.

Allt är återigen inte bra.

Så fort allt lagt sig, började olika smarta "metodologer" skriva tjocka böcker om DevOps-praktiker, det blossade upp diskussioner om vem den där beryktade DevOps-ingenjören egentligen är och vad DevOps – är en kultur för produktion, missnöjet växte återigen. Plötsligt upptäcktes det att mjukvaruleverans är en absolut icke-trivial uppgift. Varje utvecklingsinfrastruktur har sin egen stack, ibland behöver man bygga, ibland behöver man sätta upp miljöer, här behövs tomcat, här behövs en ytterst intrikat metod för uppstart – i allmänhet, huvudet spränger. Och så var problemet, konstigt nog, först och främst i processorganisationen – denna leveransfunktion, som en flaskhals, började blockera processerna. Dessutom har driftsättningen (Operations) inte blivit avskaffad. Den syns inte i V-modellen, och där är hela livscykeln till höger. Så i slutändan behöver man hitta sätt att stödja infrastrukturen, håll koll på övervakningen och hantera incidenter, och dessutom syssla med leveranser. Det vill säga, sitta med ett ben i utvecklingen och ett i driftsättningen – och plötsligt fick vi Development & Operations. Och så kom också en massiv hype kring mikrotjänster. Med dem började utvecklingen flytta från lokala maskiner till molnet – försök att debugga något lokalt när det finns tiotals och hundratals mikrotjänster, här blir konstant leverans ett överlevnadsmedel. För ett "litet blygsamt företag" är det okej, men ändå? Och Google?

SRE från Google

Google kom, åt de största kaktusarna och bestämde sig – vi behöver inte det här, vi behöver pålitlighet. Och pålitlighet måste vi hantera. De insåg – vi behöver specialister som kan hantera pålitligheten. De kallade dem SR-ingenjörer och sa, här har ni allt, gör det som vanligt, bra. Här har ni SLI, här har ni SLO, här har ni övervakning. Och de pekade med magen på operations. De kallade sin 'pålitliga DevOps' SRE. Det verkar bra, men det finns ett fult hack som Google kunde tillåta sig – att anställa personer som hade kvalifikationer som utvecklare och bara lite förståelse för hur fungerande system fungerar just för SR-ingenjörspositionerna. Det finns fortfarande problem med att anställa sådana personer, även för Google, främst för att de tävlar mot sig själva – någon måste ju beskriva affärslogiken. De lade leveransen på release-ingenjörerna, SR-ingenjörerna hanterar pålitligheten (självklart inte direkt, utan genom att påverka infrastrukturen, ändra arkitekturen, övervaka förändringar och parametrar, och hantera incidenter). Det ser bra ut. skriva böcker. Vad ska man göra om man inte är Google, men ändå är orolig för pålitlighet?

Utvecklingen av DevOps-idéer

Här kom Docker in, som växte fram ur lxc, och senare olika orkestreringssystem som Docker Swarm och Kubernetes, och DevOps-ingenjörerna andades ut – enhetligheten av praxis förenklade leveransen. Det blev så enkelt att det till och med var möjligt att lämna över leveransen till utvecklarna – vad är deployment.yaml. Containerisering löser problemet. Och mognaden av CI/CD-systemen är nu på nivå att man bara behöver skriva en fil och allt är igång – utvecklarna klarar sig själva. Och här börjar vi prata om hur vi ska skapa vårt SRE, med… ja, vem som helst.

SRE inte i Google

Nåväl, vi har släppt leveransen, och vi kan tydligen andas ut, återvända till de gamla goda tiderna när administratörer övervakade processorbelastning, finjusterade system och tyst sippade något oklart ur muggar i tystnad och lugn... Stopp. Det var inte därför vi satte igång allt detta (vilket är synd!). Plötsligt visar det sig att med Googles angreppssätt kan vi mycket väl använda utmärkta metoder — det handlar inte om processorbelastning, och inte hur ofta vi byter ut hårddiskar, eller hur vi optimerar kostnaderna i molnet, utan affärsmetrikarna — de sedvanliga SLx. Infrastrukturhantering har ingen tagit bort, incidenter måste hanteras, man måste stå vakt ibland, och man måste överhuvudtaget vara insatt i affärsprocesserna. Och hörni, börja gärna programmera på en högre nivå, Google har redan väntat på er.

Sammanfattningsvis. Plötsligt, men ni är redan trötta på att läsa och ni längtar efter att skriva en kommentar till artikeln. DevOps som en leveransmetod har funnits, finns och kommer alltid att finnas. Det kommer inte att försvinna. SRE som en uppsättning driftsmetoder gör denna leverans framgångsrik.

Källa: habr.com