Gebaseerd op een chatgesprek
De laatste tijd zijn er echte gevechten losgebarsten over de definitie van DevOps en SRE.
Ondanks het feit dat de discussies over dit onderwerp in veel opzichten mijn tanden, inclusief mijzelf, al op scherp hebben gezet, heb ik besloten mijn mening over dit onderwerp voor te leggen aan de rechtbank van de Habra-gemeenschap. Voor degenen die geïnteresseerd zijn, welkom bij cat. En laat alles opnieuw beginnen!
prehistorie
Dus in de oudheid leefde een team van softwareontwikkelaars en serverbeheerders gescheiden van elkaar. De eerste schreef met succes de code, de tweede zette met behulp van verschillende warme, aanhankelijke woorden gericht aan de eerste de servers op, kwam periodiek naar de ontwikkelaars en ontving als reactie een uitgebreid 'alles werkt op mijn machine'. Het bedrijf wachtte op de software, alles stond stil, het ging periodiek kapot, iedereen was nerveus. Vooral degene die voor deze hele puinhoop heeft betaald. Glorieus lampentijdperk. Nou, je weet al waar DevOps vandaan komt.
De geboorte van DevOps-praktijken
Toen kwamen serieuze jongens en zeiden: dit is geen branche, zo kun je niet werken. En ze brachten levenscyclusmodellen binnen. Hier is bijvoorbeeld het V-model.
Dus wat zien we? Een bedrijf komt met een concept, architecten ontwerpen oplossingen, ontwikkelaars schrijven code, en dan mislukt het. Iemand test het product op de een of andere manier, iemand levert het op de een of andere manier af aan de eindgebruiker, en ergens aan de uitgang van dit wondermodel zit een eenzame zakelijke klant te wachten op het beloofde weer aan zee. We kwamen tot de conclusie dat we methoden nodig hebben waarmee we dit proces kunnen bewerkstelligen. En we besloten praktijken te creëren die deze zouden implementeren.
Een lyrische uitweiding over wat praktijk is
Met praktijk bedoel ik een combinatie van technologie en discipline. Een voorbeeld is de praktijk van het beschrijven van infrastructuur met behulp van terraformcode. Discipline is hoe je infrastructuur met code beschrijft; het zit in het hoofd van de ontwikkelaar, en technologie is de terraform zelf.
En ze besloten ze DevOps-praktijken te noemen – ik denk dat ze bedoelden van ontwikkeling naar operaties. We hebben verschillende slimme dingen bedacht: CI/CD-praktijken, praktijken gebaseerd op het IaC-principe, duizenden. En daar gaan we, ontwikkelaars schrijven code, DevOps-ingenieurs transformeren de beschrijving van het systeem in de vorm van code in werkende systemen (ja, de code is helaas slechts een beschrijving, maar niet de belichaming van het systeem), de levering gaat door, enzovoort. De beheerders van gisteren, die nieuwe praktijken onder de knie hadden, lieten zich trots omscholen tot DevOps-ingenieurs, en vanaf daar ging alles verder. En er was avond, en er was ochtend... sorry, niet vanaf daar.
Het is weer niet allemaal goed, godzijdank
Zodra alles weer tot rust kwam en verschillende sluwe ‘methodologen’ dikke boeken begonnen te schrijven over de DevOps-praktijken, laaiden stilletjes meningsverschillen op over wie de beruchte DevOps-ingenieur was en dat DevOps een productiecultuur is, ontstond er opnieuw onvrede. Plotseling bleek dat het leveren van software een absoluut niet-triviale taak is. Elke ontwikkelingsinfrastructuur heeft zijn eigen stapel, ergens moet je hem samenstellen, ergens moet je de omgeving inzetten, hier heb je Tomcat nodig, hier heb je een sluwe en ingewikkelde manier nodig om hem te lanceren - over het algemeen bonst je hoofd. En het probleem bleek, vreemd genoeg, vooral te liggen in de organisatie van processen - deze leveringsfunctie begon, als een knelpunt, processen te blokkeren. Bovendien heeft niemand Operaties geannuleerd. Bij het V-model is het niet zichtbaar, maar rechts staat nog steeds de hele levenscyclus. Als gevolg hiervan is het noodzakelijk om op de een of andere manier de infrastructuur te onderhouden, de monitoring te monitoren, incidenten op te lossen en ook de levering af te handelen. Die. zowel bij de ontwikkeling als bij de exploitatie met één been staan – en opeens bleek dat Development & Operations te zijn. En dan was er de algemene hype voor microservices. En met hen begon de ontwikkeling van lokale machines naar de cloud te verhuizen - probeer iets lokaal te debuggen, als er tientallen en honderden microservices zijn, dan wordt constante levering een middel om te overleven. Voor een “klein, bescheiden bedrijf” was het allemaal oké, maar toch? Hoe zit het met Google?
SRE van Google
Google kwam, at de grootste cactussen en besloot: we hebben dit niet nodig, we hebben betrouwbaarheid nodig. En de betrouwbaarheid moet worden beheerd. En ik besloot dat we specialisten nodig hebben die de betrouwbaarheid beheren. Ik noemde ze SR-ingenieurs en zei: dat is het voor jou, doe het goed zoals gewoonlijk. Hier is SLI, hier is SLO, hier is monitoring. En hij stak zijn neus in operaties. En hij noemde zijn “betrouwbare DevOps” SRE. Alles lijkt in orde te zijn, maar er is één vuile hack die Google zich kon veroorloven: huur voor de functie van SR-ingenieurs mensen in die gekwalificeerde ontwikkelaars waren en ook wat huiswerk deden en de werking van werkende systemen begrepen. Bovendien heeft Google zelf problemen met het aannemen van zulke mensen - vooral omdat het hier met zichzelf concurreert - het is noodzakelijk om de bedrijfslogica aan iemand te beschrijven. De levering werd toegewezen aan release-ingenieurs, SR - ingenieurs beheren de betrouwbaarheid (uiteraard niet rechtstreeks, maar door de infrastructuur te beïnvloeden, de architectuur te veranderen, veranderingen en indicatoren bij te houden, incidenten af te handelen). Leuk, dat kan . Maar wat als u niet Google bent, maar betrouwbaarheid op de een of andere manier nog steeds een probleem is?
Ontwikkeling van DevOps-ideeën
Op dat moment arriveerde Docker, dat voortkwam uit lxc, en toen ademden verschillende orkestratiesystemen zoals Docker Swarm en Kubernetes, en DevOps-ingenieurs uit: de unificatie van praktijken vereenvoudigde de levering. Het vereenvoudigde het in die mate dat het mogelijk werd om de levering zelfs uit te besteden aan ontwikkelaars - wat is deployment.yaml. Containerisatie lost het probleem op. En de volwassenheid van CI/CD-systemen bevindt zich al op het niveau van het schrijven van één bestand en daar gaan we: de ontwikkelaars kunnen het zelf afhandelen. En dan beginnen we te praten over hoe we onze eigen SRE kunnen maken, met... of in ieder geval met iemand.
SRE is niet op Google
Nou, oké, we hebben de bezorging afgeleverd, het lijkt erop dat we kunnen uitademen, terugkeren naar de goede oude tijd, toen admins de belasting van de processor keken, de systemen afstemden en stilletjes in alle rust iets onbegrijpelijks uit mokken dronken... Stop. Dit is niet de reden waarom we met alles begonnen zijn (wat jammer is!). Plots blijkt dat we in de aanpak van Google gemakkelijk uitstekende praktijken kunnen overnemen - het is niet de processorbelasting die belangrijk is, en niet hoe vaak we de schijven daar vervangen of de kosten in de cloud optimaliseren, maar de zakelijke statistieken zijn dezelfde beruchte SLx. En niemand heeft het infrastructuurbeheer van hen afgenomen, en ze moeten incidenten oplossen, periodiek dienst doen en over het algemeen de bedrijfsprocessen onder controle houden. En jongens, begin beetje bij beetje op een goed niveau te programmeren, Google wacht al op je.
Samenvatten. Plotseling, maar je bent het lezen al beu en je kunt niet wachten om te spugen en naar de auteur te schrijven in een reactie op het artikel. DevOps als leveringspraktijk is er altijd geweest en zal dat ook blijven. En het gaat nergens heen. SRE als geheel van operationele praktijken maakt deze uitvoering zeer succesvol.
Bron: www.habr.com