Baseret på en chatdiskussion
For nylig er virkelige kampe blusset op om definitionen af DevOps og SRE.
På trods af at diskussioner om dette emne på mange måder allerede har sat mine tænder på højkant, inklusive mig, besluttede jeg at bringe mit syn på dette emne til retten i Habra-samfundet. For de interesserede, velkommen til kat. Og lad alt begynde forfra!
forhistorie
Så i oldtiden boede et team af softwareudviklere og serveradministratorer hver for sig. Den første skrev med succes koden, den anden, ved hjælp af forskellige varme, kærlige ord adresseret til den første, satte serverne op, kom med jævne mellemrum til udviklerne og modtog som svar et omfattende "alt fungerer på min maskine." Virksomheden ventede på softwaren, alt var inaktivt, det gik i stykker med jævne mellemrum, alle var nervøse. Især ham, der betalte for hele dette rod. Glorværdig lampeæra. Nå, du ved allerede, hvor DevOps kommer fra.
Fødslen af DevOps-praksis
Så kom seriøse fyre og sagde - det her er ikke en industri, sådan kan man ikke arbejde. Og de bragte livscyklusmodeller ind. Her er det for eksempel V-modellen.
Så hvad ser vi? En virksomhed kommer med et koncept, arkitekter designer løsninger, udviklere skriver kode, og så mislykkes det. Nogen tester på en eller anden måde produktet, nogen leverer det til slutbrugeren, og et sted ved outputtet af denne mirakelmodel sidder en ensom erhvervskunde og venter på det lovede vejr ved havet. Vi kom til den konklusion, at vi har brug for metoder, der gør det muligt for os at etablere denne proces. Og vi besluttede at skabe praksis, der ville implementere dem.
En lyrisk digression om, hvad praksis er
Med praksis mener jeg en kombination af teknologi og disciplin. Et eksempel er praksis med at beskrive infrastruktur ved hjælp af terraform-kode. Disciplin er, hvordan man beskriver infrastruktur med kode, det er i udviklerens hoved, og teknologien er selve terraformen.
Og de besluttede at kalde dem DevOps-praksis – jeg tror, de betød fra udvikling til drift. Vi fandt på forskellige smarte ting - CI/CD-praksis, praksis baseret på IaC-princippet, tusindvis af dem. Og afsted, udviklere skriver kode, DevOps-ingeniører transformerer beskrivelsen af systemet i form af kode til fungerende systemer (ja, koden er desværre kun en beskrivelse, men ikke legemliggørelsen af systemet), leveringen fortsætter, og så videre. Gårsdagens administratorer, efter at have mestret ny praksis, blev stolt omskolet til DevOps-ingeniører, og alt gik derfra. Og der blev aften, og der blev morgen... undskyld, ikke derfra.
Det er ikke alt godt igen, gudskelov
Så snart alt faldt til ro, og forskellige snedige "metodologer" begyndte at skrive tykke bøger om DevOps-praksis, blussede der stille og roligt op om, hvem den berygtede DevOps-ingeniør var, og at DevOps er en produktionskultur, opstod utilfredsheden igen. Pludselig viste det sig, at levering af software er en absolut ikke-triviel opgave. Hver udviklingsinfrastruktur har sin egen stak, et eller andet sted skal du samle det, et eller andet sted skal du implementere miljøet, her har du brug for Tomcat, her har du brug for en snedig og kompliceret måde at starte den på – generelt banker dit hoved. Og problemet viste sig, mærkeligt nok, primært at være i organiseringen af processer - denne leveringsfunktion begyndte som en flaskehals at blokere processer. Derudover var der ingen, der aflyste Operations. Det er ikke synligt i V-modellen, men der er stadig hele livscyklussen til højre. Som et resultat er det nødvendigt på en eller anden måde at vedligeholde infrastrukturen, overvåge overvågning, løse hændelser og også håndtere levering. De der. sidde med én fod i både udvikling og drift – og pludselig blev det Udvikling & Drift. Og så var der den generelle hype for mikrotjenester. Og med dem begyndte udviklingen fra lokale maskiner at flytte til skyen - prøv at fejlsøge noget lokalt, hvis der er snesevis og hundredvis af mikrotjenester, så bliver konstant levering et middel til at overleve. For en "lille beskeden virksomhed" var det i orden, men alligevel? Hvad med Google?
SRE af Google
Google kom, spiste de største kaktusser og besluttede - vi har ikke brug for dette, vi har brug for pålidelighed. Og pålideligheden skal styres. Og jeg besluttede, at vi har brug for specialister, der vil styre pålidelighed. Jeg kaldte dem SR-ingeniører og sagde, det er det for dig, gør det godt som normalt. Her er SLI, her er SLO, her er overvågning. Og han stak næsen ind i operationer. Og han kaldte sin "pålidelige DevOps" SRE. Alt ser ud til at være i orden, men der er et beskidt hack, som Google har råd til - til stillingen som SR-ingeniører, ansæt folk, der var kvalificerede udviklere og også lavede lidt hjemmearbejde og forstod, hvordan fungerende systemer fungerer. Desuden har Google selv problemer med at ansætte sådanne personer - primært fordi det her konkurrerer med sig selv - det er nødvendigt at beskrive forretningslogikken for nogen. Levering blev tildelt frigivelsesingeniører, SR - ingeniører styrer pålidelighed (selvfølgelig ikke direkte, men ved at påvirke infrastrukturen, ændre arkitekturen, spore ændringer og indikatorer, håndtere hændelser). Dejligt, det kan du . Men hvad nu, hvis du ikke er Google, men pålidelighed er stadig et problem?
Udvikling af DevOps ideer
Lige da ankom Docker, som voksede ud af lxc, og så pustede forskellige orkestreringssystemer som Docker Swarm og Kubernetes, og DevOps-ingeniører ud - foreningen af praksis forenklede leveringen. Det forenklede det i en sådan grad, at det blev muligt endda at outsource levering til udviklere - hvad er deployment.yaml. Containerisering løser problemet. Og modenheden af CI/CD-systemer er allerede på niveau med at skrive én fil, og så er vi i gang – udviklerne kan klare det selv. Og så begynder vi at tale om, hvordan vi kan lave vores egen SRE, med... eller i hvert fald med nogen.
SRE er ikke på Google
Nå, ok, vi leverede leveringen, det ser ud til at vi kan puste ud, vende tilbage til de gode gamle dage, hvor admins så processoren loade, tunede systemerne og stille og roligt nippede til noget uforståeligt fra krus i fred og ro... Stop. Det er ikke derfor, vi startede alt (hvilket er ærgerligt!). Pludselig viser det sig, at vi i Googles tilgang nemt kan anvende fremragende praksis - det er ikke processorbelastningen, der er vigtig, og ikke hvor ofte vi skifter diske der, eller optimerer omkostningerne i skyen, men forretningsmålingerne er de samme berygtede SLx. Og ingen har fjernet infrastrukturstyring fra dem, og de skal løse hændelser og være på vagt med jævne mellemrum og generelt holde sig på forkant med forretningsprocesser. Og gutter, begynd at programmere lidt efter lidt på et godt niveau, Google venter allerede på jer.
At opsummere. Pludselig, men du er allerede træt af at læse, og du kan ikke vente med at spytte og skrive til forfatteren i en kommentar til artiklen. DevOps som leveringspraksis har altid været og vil være det. Og det går ingen vegne. SRE som et sæt af operationel praksis gør netop denne levering vellykket.
Kilde: www.habr.com