Baserat på en chattdiskussion
Nyligen har verkliga strider blossat upp om definitionen av DevOps och SRE.
Trots att diskussioner om detta ämne på många sätt redan har satt mina tänder på spetsen, inklusive mig, bestämde jag mig för att föra min syn på detta ämne till Habra-gemenskapens domstol. För den som är intresserad, välkommen till katt. Och låt allt börja om!
förhistoria
Så, i forntida tider, bodde ett team av mjukvaruutvecklare och serveradministratörer separat. Den första skrev framgångsrikt koden, den andra, med hjälp av olika varma, tillgivna ord riktade till den första, satte upp servrarna, kom med jämna mellanrum till utvecklarna och fick som svar ett omfattande "allt fungerar på min maskin." Verksamheten väntade på programvaran, allt var inaktivt, det gick sönder med jämna mellanrum, alla var nervösa. Speciellt den som betalade för hela den här röran. Härlig lampa era. Tja, du vet redan var DevOps kommer ifrån.
Födelsen av DevOps-praxis
Sedan kom seriösa killar och sa - det här är ingen bransch, man kan inte jobba så. Och de tog in livscykelmodeller. Här är till exempel V-modellen.
Så vad ser vi? Ett företag kommer med ett koncept, arkitekter designar lösningar, utvecklare skriver kod och sedan misslyckas det. Någon testar produkten på något sätt, någon levererar den till slutanvändaren, och någonstans vid utgången av denna mirakelmodell sitter en ensam företagskund och väntar på det utlovade vädret vid havet. Vi kom till slutsatsen att vi behöver metoder som gör att vi kan etablera denna process. Och vi bestämde oss för att skapa metoder som skulle implementera dem.
En lyrisk utvikning i ämnet vad praktik är
Med praktik menar jag en kombination av teknik och disciplin. Ett exempel är praxis att beskriva infrastruktur med hjälp av terraform-kod. Disciplin är hur man beskriver infrastruktur med kod, det är i utvecklarens huvud, och tekniken är själva terraformen.
Och de bestämde sig för att kalla dem DevOps-praxis - jag tror att de menade från utveckling till drift. Vi kom på olika smarta saker - CI/CD-övningar, övningar baserade på IaC-principen, tusentals av dem. Och iväg, utvecklare skriver kod, DevOps-ingenjörer omvandlar beskrivningen av systemet i form av kod till fungerande system (ja, koden är tyvärr bara en beskrivning, men inte förkroppsligandet av systemet), leveransen fortsätter, och så vidare. Gårdagens administratörer, efter att ha bemästrat nya metoder, omskolade sig stolt till DevOps-ingenjörer, och allt gick därifrån. Och det blev kväll, och det blev morgon... förlåt, inte därifrån.
Allt är inte bra igen, tack och lov
Så fort allt lugnade ner sig, och olika listiga "metodologer" började skriva tjocka böcker om DevOps-praxis, blossade det tyst upp dispyter om vem den ökända DevOps-ingenjören var och att DevOps är en produktionskultur, uppstod missnöje igen. Plötsligt visade det sig att mjukvaruleverans är en absolut icke-trivial uppgift. Varje utvecklingsinfrastruktur har sin egen stack, någonstans måste du montera den, någonstans behöver du distribuera miljön, här behöver du Tomcat, här behöver du ett listigt och komplicerat sätt att lansera den - i allmänhet bultar ditt huvud. Och problemet visade sig, konstigt nog, främst ligga i organisationen av processer - denna leveransfunktion började, som en flaskhals, blockera processer. Dessutom ställde ingen in Operations. Det syns inte i V-modellen, men det finns fortfarande hela livscykeln till höger. Som ett resultat är det nödvändigt att på något sätt underhålla infrastrukturen, övervaka övervakning, lösa incidenter och även hantera leverans. De där. sitta med ena foten i både utveckling och drift – och plötsligt blev det Utveckling & Drift. Och så var det den allmänna hypen för mikrotjänster. Och med dem började utvecklingen från lokala maskiner flytta till molnet - försök att felsöka något lokalt, om det finns dussintals och hundratals mikrotjänster, blir konstant leverans ett sätt att överleva. För ett "litet blygsamt företag" var det okej, men ändå? Hur är det med Google?
SRE från Google
Google kom, åt de största kaktusarna och bestämde - vi behöver inte det här, vi behöver pålitlighet. Och tillförlitlighet måste hanteras. Och jag bestämde mig för att vi behöver specialister som kommer att hantera tillförlitlighet. Jag kallade dem SR-ingenjörer och sa, det är det för dig, gör det bra som vanligt. Här är SLI, här är SLO, här är övervakning. Och han stack in näsan i operationer. Och han kallade sin "pålitliga DevOps" SRE. Allt verkar vara bra, men det finns ett smutsigt hack som Google har råd med – för SR-ingenjörernas position, anställ personer som var kvalificerade utvecklare och som dessutom gjorde lite läxor och förstod hur fungerande system fungerar. Dessutom har Google själv problem med att anställa sådana personer - främst för att det här konkurrerar med sig självt - det är nödvändigt att beskriva affärslogiken för någon. Leverans tilldelades släppingenjörer, SR - ingenjörer hanterar tillförlitlighet (naturligtvis inte direkt, utan genom att påverka infrastrukturen, ändra arkitekturen, spåra förändringar och indikatorer, hantera incidenter). Snyggt, du kan . Men vad händer om du inte är Google, men tillförlitlighet är fortfarande ett problem på något sätt?
Utveckling av DevOps-idéer
Precis då anlände Docker, som växte fram ur lxc, och sedan andades olika orkestreringssystem som Docker Swarm och Kubernetes, och DevOps-ingenjörer ut – enandet av praxis förenklade leveransen. Det förenklade det så till den grad att det blev möjligt att till och med lägga ut leverans till utvecklare - vad är deployment.yaml. Containerisering löser problemet. Och CI/CD-systemens mognad är redan på nivån att skriva en fil och så är vi igång - utvecklarna kan hantera det själva. Och så börjar vi prata om hur vi kan göra vår egen SRE, med... eller åtminstone med någon.
SRE finns inte på Google
Nåväl, ok, vi levererade leveransen, det verkar som om vi kan andas ut, återgå till den gamla goda tiden, när administratörer såg processorn ladda, trimmade systemen och tyst smuttade på något obegripligt ur muggar i lugn och ro... Sluta. Det är inte därför vi startade allt (vilket är synd!). Plötsligt visar det sig att i Googles tillvägagångssätt kan vi lätt anta utmärkta metoder - det är inte processorbelastningen som är viktig, och inte hur ofta vi byter diskar där, eller optimerar kostnaden i molnet, men affärsmåtten är samma ökända SLx. Och ingen har tagit bort infrastrukturhanteringen från dem, och de måste lösa incidenter och vara i tjänst med jämna mellanrum och i allmänhet hålla koll på affärsprocesser. Och killar, börja programmera lite i taget på en bra nivå, Google väntar redan på er.
För att sammanfatta. Plötsligt, men du är redan trött på att läsa och du kan inte vänta med att spotta och skriva till författaren i en kommentar till artikeln. DevOps som leveranspraxis har alltid varit och kommer att vara. Och det går ingenstans. SRE som en uppsättning operativa rutiner gör denna leverans framgångsrik.
Källa: will.com