Basert på en chat-diskusjon
Nylig har virkelige kamper blusset opp om definisjonen av DevOps og SRE.
Til tross for at diskusjoner om dette emnet på mange måter allerede har satt tennene mine på spissen, inkludert meg, bestemte jeg meg for å bringe mitt syn på dette emnet til domstolen i Habra-samfunnet. For de som er interessert, velkommen til katt. Og la alt begynne på nytt!
forhistorie
Så i eldgamle tider bodde et team av programvareutviklere og serveradministratorer hver for seg. Den første skrev vellykket koden, den andre, ved å bruke forskjellige varme, kjærlige ord adressert til den første, satte opp serverne, kom med jevne mellomrom til utviklerne og mottok som svar et omfattende "alt fungerer på maskinen min." Bedriften ventet på programvaren, alt var inaktivt, det gikk i stykker med jevne mellomrom, alle var nervøse. Spesielt han som betalte for hele dette rotet. Strålende lampeæra. Vel, du vet allerede hvor DevOps kommer fra.
Fødselen av DevOps-praksis
Så kom seriøse karer og sa - dette er ikke en bransje, du kan ikke jobbe slik. Og de brakte inn livssyklusmodeller. Her er for eksempel V-modellen.
Så hva ser vi? En virksomhet kommer med et konsept, arkitekter designer løsninger, utviklere skriver kode, og så mislykkes det. Noen tester produktet på en eller annen måte, noen leverer det til sluttbrukeren, og et sted ved utgangen av denne mirakelmodellen sitter en ensom bedriftskunde og venter på det lovede været ved sjøen. Vi kom til den konklusjonen at vi trenger metoder som gjør at vi kan etablere denne prosessen. Og vi bestemte oss for å lage praksiser som ville implementere dem.
En lyrisk digresjon om hva praksis er
Med praksis mener jeg en kombinasjon av teknologi og disiplin. Et eksempel er praksisen med å beskrive infrastruktur ved hjelp av terraform-kode. Disiplin er hvordan man beskriver infrastruktur med kode, det er i utviklerens hode, og teknologien er selve terraformen.
Og de bestemte seg for å kalle dem DevOps-praksis – jeg tror de mente fra utvikling til drift. Vi fant på forskjellige smarte ting - CI/CD-praksis, praksis basert på IaC-prinsippet, tusenvis av dem. Og i gang, utviklere skriver kode, DevOps-ingeniører forvandler beskrivelsen av systemet i form av kode til fungerende systemer (ja, koden er dessverre bare en beskrivelse, men ikke legemliggjørelsen av systemet), leveringen fortsetter, og så videre. Gårsdagens administratorer, etter å ha mestret ny praksis, omskolerte seg stolt til DevOps-ingeniører, og alt gikk derfra. Og det ble kveld, og det ble morgen... beklager, ikke derfra.
Alt er ikke bra igjen, gudskjelov
Så snart alt roet seg, og ulike utspekulerte «metodologer» begynte å skrive tykke bøker om DevOps-praksis, blusset det stille opp tvister om hvem den beryktede DevOps-ingeniøren var og at DevOps er en produksjonskultur, oppsto misnøyen igjen. Plutselig viste det seg at levering av programvare er en absolutt ikke-triviell oppgave. Hver utviklingsinfrastruktur har sin egen stabel, et sted må du sette den sammen, et sted må du distribuere miljøet, her trenger du Tomcat, her trenger du en utspekulert og komplisert måte å lansere den på – generelt sett banker hodet ditt. Og problemet, merkelig nok, viste seg først og fremst å være i organiseringen av prosesser - denne leveringsfunksjonen, som en flaskehals, begynte å blokkere prosesser. I tillegg var det ingen som kansellerte Operations. Det er ikke synlig i V-modellen, men det er fortsatt hele livssyklusen til høyre. Som et resultat er det nødvendig å på en eller annen måte vedlikeholde infrastrukturen, overvåke overvåking, løse hendelser og også håndtere levering. De. sitte med én fot i både utvikling og drift – og plutselig viste det seg å være Utvikling & Drift. Og så var det den generelle hypen for mikrotjenester. Og med dem begynte utviklingen fra lokale maskiner å flytte til skyen - prøv å feilsøke noe lokalt, hvis det er dusinvis og hundrevis av mikrotjenester, blir konstant levering et middel for å overleve. For et "lite beskjedent selskap" var det greit, men likevel? Hva med Google?
SRE av Google
Google kom, spiste de største kaktusene og bestemte - vi trenger ikke dette, vi trenger pålitelighet. Og pålitelighet må styres. Og jeg bestemte meg for at vi trenger spesialister som skal administrere pålitelighet. Jeg kalte dem SR-ingeniører og sa, det er det for deg, gjør det bra som vanlig. Her er SLI, her er SLO, her er overvåking. Og han stakk nesen inn i operasjoner. Og han kalte sin "pålitelige DevOps" SRE. Alt ser ut til å være i orden, men det er ett skittent hack som Google har råd til - for stillingen som SR-ingeniører, ansett folk som var kvalifiserte utviklere og også gjorde litt lekser og forsto hvordan fungerende systemer fungerer. Dessuten har Google selv problemer med å ansette slike folk – hovedsakelig fordi det her konkurrerer med seg selv – det er nødvendig å beskrive forretningslogikken for noen. Levering ble tildelt utgivelsesingeniører, SR - ingeniører styrer pålitelighet (selvfølgelig ikke direkte, men ved å påvirke infrastrukturen, endre arkitekturen, spore endringer og indikatorer, håndtere hendelser). Fint, du kan . Men hva om du ikke er Google, men pålitelighet fortsatt er en bekymring på en eller annen måte?
Utvikling av DevOps ideer
Akkurat da ankom Docker, som vokste ut av lxc, og da pustet ulike orkestreringssystemer som Docker Swarm og Kubernetes, og DevOps-ingeniører ut – foreningen av praksis forenklet leveringen. Det forenklet det i en slik grad at det ble mulig å til og med outsource levering til utviklere - hva er deployment.yaml. Containerisering løser problemet. Og modenheten til CI/CD-systemer er allerede på nivå med å skrive én fil, og så er vi i gang – utviklerne kan håndtere det selv. Og så begynner vi å snakke om hvordan vi kan lage vår egen SRE, med... eller i det minste med noen.
SRE er ikke på Google
Vel, ok, vi leverte leveransen, det ser ut til at vi kan puste ut, gå tilbake til de gode gamle dager, da admins så prosessoren laste, innstilte systemene og stille nippet til noe uforståelig fra krus i fred og ro... Stopp. Det er ikke derfor vi startet alt (noe som er synd!). Plutselig viser det seg at i Googles tilnærming kan vi enkelt ta i bruk utmerket praksis - det er ikke prosessorbelastningen som er viktig, og ikke hvor ofte vi bytter disker der, eller optimerer kostnadene i skyen, men forretningsmålene er de samme beryktede SLx. Og ingen har fjernet infrastrukturstyring fra dem, og de må løse hendelser, og være på vakt med jevne mellomrom, og generelt holde seg på toppen av forretningsprosessene. Og folkens, begynn å programmere litt etter litt på et godt nivå, Google venter allerede på deg.
Å oppsummere. Plutselig, men du er allerede lei av å lese, og du kan ikke vente med å spytte og skrive til forfatteren i en kommentar til artikkelen. DevOps som leveringspraksis har alltid vært og vil være. Og det går ingen steder. SRE som et sett med operasjonelle praksiser gjør denne leveransen vellykket.
Kilde: www.habr.com