Het webinar heeft slechte audio, dus we hebben het getranscribeerd.
Mijn naam is Medvedev Eduard. Vandaag zal ik het hebben over wat SRE is, hoe SRE verscheen, welke werkcriteria SRE-ingenieurs hebben, een beetje over betrouwbaarheidscriteria, een beetje over het monitoren ervan. We zullen over de toppen lopen, omdat je in een uur niet veel kunt vertellen, maar ik zal materiaal geven voor aanvullende beoordeling, en we wachten allemaal op je . in Moskou eind januari.
Laten we eerst eens kijken naar wat SRE is: Site Reliability Engineering. En hoe het verscheen als een aparte positie, als een aparte richting. Het begon allemaal met het feit dat Dev en Ops in traditionele ontwikkelingskringen twee totaal verschillende teams zijn, meestal met twee totaal verschillende doelen. Het doel van het ontwikkelingsteam is om nieuwe functies uit te rollen en aan de behoeften van het bedrijf te voldoen. Het doel van het Ops-team is ervoor te zorgen dat alles werkt en dat er niets kapot gaat. Het is duidelijk dat deze doelen elkaar rechtstreeks tegenspreken: om alles te laten werken en niets kapot te maken, moet je zo min mogelijk nieuwe functies uitrollen. Hierdoor zijn er veel interne conflicten die de methodologie die nu DevOps heet, probeert op te lossen.
Het probleem is dat we geen duidelijke definitie van DevOps en een duidelijke implementatie van DevOps hebben. Ik sprak twee jaar geleden op een conferentie in Jekaterinenburg, en tot nu toe begon de DevOps-sectie met het rapport “Wat is DevOps”. Anno 2 bestaat Devops bijna 2017 jaar, maar we discussiëren nog steeds over wat het is. En dit is een heel vreemde situatie die Google een paar jaar geleden probeerde op te lossen.
In 2016 bracht Google een boek uit met de titel Site Reliability Engineering. En in feite was het met dit boek dat de SRE-beweging begon. SRE is een specifieke implementatie van het DevOps-paradigma in een specifiek bedrijf. SRE-ingenieurs streven ernaar ervoor te zorgen dat systemen betrouwbaar werken. Ze komen meestal van ontwikkelaars, soms beheerders met een sterke ontwikkelingsachtergrond. En ze doen wat systeembeheerders vroeger deden, maar een sterke achtergrond in ontwikkeling en kennis van het systeem op het gebied van code leidt ertoe dat deze mensen niet geneigd zijn tot routinematig administratief werk, maar tot automatisering.
Het blijkt dat het DevOps-paradigma in SRE-teams wordt geïmplementeerd doordat er SRE-ingenieurs zijn die structurele problemen oplossen. Hier is het, dezelfde connectie tussen Dev en Ops waar mensen al 8 jaar over praten. De rol van een SRE is vergelijkbaar met die van een architect, in die zin dat nieuwkomers geen SRE worden. Mensen die aan het begin van hun carrière staan, hebben nog geen ervaring, beschikken niet over de benodigde breedte van kennis. Omdat SRE een heel subtiele kennis vereist van wat en wanneer precies mis kan gaan. Daarom is hier in de regel enige ervaring nodig, zowel binnen het bedrijf als daarbuiten.
Ze vragen of het verschil tussen SRE en devops wordt beschreven. Ze is zojuist beschreven. We kunnen praten over de plaats van de SRE in de organisatie. In tegenstelling tot deze klassieke DevOps-aanpak, waarbij Ops nog steeds een aparte afdeling is, maakt SRE deel uit van het ontwikkelteam. Zij zijn betrokken bij de productontwikkeling. Er is zelfs een aanpak waarbij SRE een rol is die van de ene ontwikkelaar naar de andere overgaat. Ze nemen op dezelfde manier deel aan coderecensies als bijvoorbeeld UX-ontwerpers, ontwikkelaars zelf, soms productmanagers. SRE's werken op hetzelfde niveau. We moeten ze goedkeuren, we moeten ze beoordelen, zodat SRE voor elke implementatie zegt: “Oké, deze implementatie, dit product zal de betrouwbaarheid niet negatief beïnvloeden. En als dat zo is, dan binnen aanvaardbare grenzen. Wij zullen hier ook over praten.
Dienovereenkomstig heeft de SRE een veto om de code te wijzigen. En over het algemeen leidt dit ook tot een soort klein conflict als de SRE verkeerd wordt geïmplementeerd. In hetzelfde boek over Site Reliability Engineering wordt in veel delen, zelfs niet één, beschreven hoe deze conflicten kunnen worden vermeden.
Zij vragen hoe SRE zich verhoudt tot informatiebeveiliging. SRE houdt zich niet direct bezig met informatiebeveiliging. Kortom, bij grote bedrijven wordt dit gedaan door individuen, testers, analisten. Maar SRE heeft ook interactie met hen in de zin dat sommige operaties, sommige commits en sommige implementaties die de veiligheid beïnvloeden, ook de beschikbaarheid van het product kunnen beïnvloeden. Daarom heeft SRE als geheel interactie met alle teams, inclusief beveiligingsteams, inclusief analisten. Daarom zijn SRE’s vooral nodig als ze DevOps proberen te implementeren, maar tegelijkertijd wordt de last voor ontwikkelaars te groot. Dat wil zeggen dat het ontwikkelingsteam zelf niet langer kan omgaan met het feit dat ze nu ook verantwoordelijk moeten zijn voor Ops. En er is een aparte rol. Deze rol is gepland in de begroting. Soms wordt deze rol vastgelegd in de grootte van het team, verschijnt er een aparte persoon, soms wordt een van de ontwikkelaars deze. Dit is hoe de eerste SRE in het team verschijnt.
De complexiteit van het systeem dat door SRE wordt beïnvloed, de complexiteit die de betrouwbaarheid van de operatie beïnvloedt, is noodzakelijk en toevallig. Er is sprake van noodzakelijke complexiteit wanneer de complexiteit van een product toeneemt in de mate die vereist is door nieuwe productkenmerken. Van willekeurige complexiteit is sprake wanneer de complexiteit van het systeem toeneemt, maar de productkenmerken en bedrijfsvereisten hier geen directe invloed op hebben. Het blijkt dat de ontwikkelaar ergens een fout heeft gemaakt, of dat het algoritme niet optimaal is, of dat er extra interesses zijn geïntroduceerd die de complexiteit van het product vergroten zonder speciale noodzaak. Een goede SRE moet deze situatie altijd voorkomen. Dat wil zeggen dat elke commit, elke implementatie, elk pull-verzoek, waarbij de moeilijkheidsgraad wordt verhoogd als gevolg van willekeurige toevoeging, moet worden geblokkeerd.
De vraag is waarom we niet gewoon een engineer, een systeembeheerder met veel kennis, in het team inhuren. Een ontwikkelaar in de rol van ingenieur, zo wordt ons verteld, is niet de beste personeelsoplossing. Een ontwikkelaar in de rol van engineer is niet altijd de beste personeelsoplossing, maar het punt hier is dat een ontwikkelaar die zich bezighoudt met Ops iets meer verlangen naar automatisering heeft, iets meer kennis en vaardigheden heeft om deze te implementeren. deze automatisering. En dienovereenkomstig verkorten we niet alleen de tijd voor sommige specifieke handelingen, niet alleen de routine, maar ook belangrijke bedrijfsparameters als MTTR (Mean Time To Recovery, hersteltijd). Zo, en daar zullen we later ook over praten, besparen we geld voor de organisatie.
Laten we het nu hebben over de criteria voor de werking van SRE. En in de eerste plaats over de betrouwbaarheid. Bij kleine bedrijven, startups, komt het vaak voor dat mensen ervan uitgaan dat als de dienst goed is geschreven, als het product goed en correct is geschreven, het zal werken en niet kapot zal gaan. Dat is alles, we schrijven goede code, dus er valt niets te breken. De code is heel eenvoudig, er valt niets te breken. Dit zijn ongeveer dezelfde mensen die zeggen dat we geen tests nodig hebben, want kijk, dit zijn de drie VPI-methoden, waarom zou je hier breken?
Dit is natuurlijk allemaal verkeerd. En deze mensen worden in de praktijk heel vaak gebeten door dergelijke code, omdat dingen kapot gaan. Dingen gaan soms kapot op de meest onvoorspelbare manieren. Soms zeggen mensen nee, het zal nooit gebeuren. En het gebeurt de hele tijd. Gebeurt vaak genoeg. En daarom streeft niemand ooit naar 100% beschikbaarheid, want 100% beschikbaarheid gebeurt nooit. Dit is de norm. En daarom praten we altijd over negens als we het hebben over de beschikbaarheid van een dienst. 2 negens, 3 negens, 4 negens, 5 negens. Als we dit vertalen naar downtime, dan bijvoorbeeld 5 negens, dan is dit iets meer dan 5 minuten downtime per jaar, 2 negens is 3,5 dag downtime.
Maar het is duidelijk dat er op een gegeven moment sprake is van een afname van de POI, het rendement op de investering. Van twee negens naar drie negens gaan, betekent minder downtime met meer dan drie dagen. Door van vier negens naar vijf te gaan, wordt de downtime met 3 minuten per jaar verminderd. En het blijkt dat het voor het bedrijfsleven misschien niet van cruciaal belang is. En over het algemeen is de vereiste betrouwbaarheid geen technisch vraagstuk; het is in de eerste plaats een zakelijk vraagstuk, het is een productvraagstuk. Welk niveau van downtime is acceptabel voor gebruikers van het product, wat ze verwachten, hoeveel ze betalen, bijvoorbeeld, hoeveel geld ze verliezen, hoeveel geld het systeem verliest.
Een belangrijke vraag hierbij is wat de betrouwbaarheid is van de overige componenten. Omdat het verschil tussen 4 en 5 negens niet zichtbaar zal zijn op een smartphone met 2 negens betrouwbaarheid. Grof gezegd: als er 10 keer per jaar iets kapot gaat op een smartphone die u gebruikt, is de storing hoogstwaarschijnlijk 8 keer aan de kant van het besturingssysteem. De gebruiker is dit gewend en zal er niet nog een keer per jaar op letten. Het is noodzakelijk om de prijs van toenemende betrouwbaarheid en toenemende winsten met elkaar in verband te brengen.
Alleen al in het boek over SRE staat een goed voorbeeld van het verhogen van 4 negens naar 3 negens. Het blijkt dat de toename in beschikbaarheid iets minder dan 0,1% bedraagt. En als de omzet van de dienst 1 miljoen dollar per jaar bedraagt, dan is de omzetstijging 900 dollar. Als het ons minder dan 900 dollar per jaar kost om de betaalbaarheid met een factor negen te verhogen, is deze verhoging financieel zinvol. Als het meer dan 900 dollar per jaar kost, heeft het geen zin meer, omdat de stijging van de inkomsten simpelweg niet compenseert voor de arbeidskosten en de kosten van hulpbronnen. En 3 negens zijn genoeg voor ons.
Dit is natuurlijk een vereenvoudigd voorbeeld waarbij alle verzoeken gelijk zijn. En van 3 negens naar 4 negens gaan is eenvoudig genoeg, maar tegelijkertijd is het bijvoorbeeld, als je van 2 negens naar 3 gaat, al een besparing van 9 dollar, het kan financieel zinvol zijn. In werkelijkheid is het mislukken van het registratieverzoek uiteraard erger dan het niet weergeven van de pagina, verzoeken hebben verschillende gewichten. Vanuit zakelijk oogpunt hebben ze misschien een heel ander criterium, maar hoe dan ook, als we het niet over bepaalde specifieke diensten hebben, is dit in de regel een redelijk betrouwbare benadering.
Wij kregen de vraag of SRE één van de coördinatoren is bij het kiezen van een bouwkundige oplossing voor de dienst. Laten we zeggen in termen van integratie in de bestaande infrastructuur, zodat er geen verlies aan stabiliteit optreedt. Ja, SRE's, op dezelfde manier waarop pull-requests, commits en releases invloed hebben op de architectuur, de introductie van nieuwe services, microservices en de implementatie van nieuwe oplossingen. Waarom zei ik eerder dat ervaring nodig is, kwalificaties nodig zijn. In feite is SRE een van de blokkerende stemmen in elke architectuur- en softwareoplossing. Dienovereenkomstig moet een SRE als ingenieur in de eerste plaats niet alleen begrijpen, maar ook begrijpen hoe sommige specifieke beslissingen de betrouwbaarheid en stabiliteit zullen beïnvloeden, en begrijpen hoe dit verband houdt met de zakelijke behoeften, en vanuit welk gezichtspunt dit aanvaardbaar en aanvaardbaar kan zijn. welke niet.
Daarom kunnen we nu alleen maar spreken over betrouwbaarheidscriteria, die traditioneel in SRE worden gedefinieerd als SLA (Service Level Agreement). Waarschijnlijk een bekende term. SLI (Serviceniveau-indicator). SLO (Serviceniveaudoelstelling). Service Level Agreement is misschien een symbolische term, zeker als je met netwerken, met providers, met hosting hebt gewerkt. Dit is een algemene overeenkomst die de prestaties van uw gehele service beschrijft, inclusief boetes, enkele boetes voor fouten, statistieken en criteria. En SLI is de beschikbaarheidsmetriek zelf. Dat wil zeggen, wat SLI kan zijn: responstijd van de dienst, het aantal fouten als percentage. Het kan bandbreedte zijn als het een soort bestandshosting is. Als het om herkenningsalgoritmen gaat, kan de indicator bijvoorbeeld zelfs de juistheid van het antwoord zijn. SLO (Service Level Objective) is respectievelijk een combinatie van de SLI-indicator, de waarde en de periode ervan.
Laten we zeggen dat de SLA er zo uit zou kunnen zien. De dienst is het hele jaar door 99,95% van de tijd beschikbaar. Of 99 kritieke supporttickets worden binnen 3 uur per kwartaal gesloten. Ofwel 85% van de vragen krijgt elke maand binnen 1,5 seconde antwoord. Dat wil zeggen dat we geleidelijk aan gaan begrijpen dat fouten en mislukkingen heel normaal zijn. Dit is een acceptabele situatie, we zijn het aan het plannen, we rekenen er zelfs tot op zekere hoogte op. Dat wil zeggen, SRE bouwt systemen die fouten kunnen maken, die normaal op fouten moeten reageren en daar rekening mee moeten houden. En waar mogelijk moeten ze fouten zo afhandelen dat de gebruiker ze niet opmerkt, of opmerkt, maar er is een soort oplossing, waardoor niet alles volledig zal instorten.
Upload je bijvoorbeeld een video naar YouTube, en YouTube kan deze niet direct converteren, is de video te groot, is het formaat niet optimaal dan mislukt het verzoek uiteraard niet met een time-out, YouTube geeft geen 502 error , zal YouTube zeggen: “We hebben alles gemaakt, je video wordt verwerkt. Binnen tien minuten is het klaar." Dit is het principe van sierlijke degradatie, dat bijvoorbeeld bekend is uit front-end-ontwikkeling, als je dit ooit hebt gedaan.
De volgende termen waar we het over zullen hebben, die erg belangrijk zijn voor het werken met betrouwbaarheid, met fouten, met verwachtingen, zijn MTBF en MTTR. MTBF is de gemiddelde tijd tussen mislukkingen. MTTR Mean Time To Recovery, gemiddelde tijd tot herstel. Dat wil zeggen, hoeveel tijd is verstreken vanaf het moment dat de fout werd ontdekt, vanaf het moment dat de fout zich voordeed tot het moment dat de service weer volledig normaal functioneerde. MTBF wordt voornamelijk opgelost door te werken aan codekwaliteit. Dat wil zeggen, het feit dat SRE's "nee" kunnen zeggen. En je moet door het hele team begrijpen dat wanneer SRE 'nee' zegt, hij dat niet zegt omdat hij schadelijk is, niet omdat hij slecht is, maar omdat anders iedereen eronder zal lijden.
Nogmaals, er zijn veel artikelen, veel methoden, veel manieren, zelfs in het boek waar ik zo vaak naar verwijs, hoe je ervoor kunt zorgen dat andere ontwikkelaars SRE niet gaan haten. MTTR daarentegen gaat over het werken aan uw SLO's (Service Level Objective). En het is vooral automatisering. Omdat onze SLO bijvoorbeeld een uptime van 4 negens per kwartaal is. Dit betekent dat we in 3 maanden 13 minuten downtime kunnen toestaan. En het blijkt dat MTTR niet langer dan 13 minuten kan duren. Als we reageren op minimaal 13 downtime in 1 minuten, betekent dit dat we het volledige budget voor het kwartaal al hebben opgebruikt. Wij doorbreken de SLO. Dertien minuten om te reageren en een crash te verhelpen is veel voor een machine, maar erg kort voor een mens. Want totdat iemand een waarschuwing ontvangt, totdat hij reageert, totdat hij de fout begrijpt, duurt het al enkele minuten. Totdat iemand begrijpt hoe hij het moet repareren, wat hij precies moet repareren, wat hij moet doen, dan duurt dit nog een paar minuten. En zelfs als je de server gewoon opnieuw moet opstarten, zo blijkt, of een nieuw knooppunt moet verhogen, dan is MTTR handmatig al ongeveer 13-7 minuten. Bij het automatiseren van het proces bereikt MTTR vaak een seconde, soms milliseconden. Google praat meestal over milliseconden, maar in werkelijkheid is alles natuurlijk niet zo goed.
Idealiter zou de SRE zijn werk vrijwel volledig moeten automatiseren, omdat dit rechtstreeks van invloed is op de MTTR, de statistieken, de SLO van de hele dienst en daarmee op de bedrijfswinst. Bij overschrijding van de tijd wordt ons gevraagd of SRE schuld heeft. Gelukkig heeft niemand de schuld. En dit is een aparte cultuur die balmeloze postmortem wordt genoemd, waar we het vandaag niet over zullen hebben, maar die we op Slurm zullen analyseren. Dit is een zeer interessant onderwerp waar veel over gesproken kan worden. Grof gezegd, als de toegewezen tijd per kwartaal wordt overschreden, heeft een klein deel van iedereen de schuld, wat betekent dat het niet productief is om iedereen de schuld te geven. Laten we in plaats daarvan misschien niemand de schuld geven, maar de situatie corrigeren en werken met wat we hebben. In mijn ervaring is deze aanpak een beetje vreemd voor de meeste teams, vooral in Rusland, maar het is logisch en werkt heel goed. Daarom zal ik aan het einde van het artikel en de literatuur aanbevelen dat u over dit onderwerp kunt lezen. Of kom naar Slurm SRE.
Laat het me uitleggen. Als de SLO-tijd per kwartaal wordt overschreden en de downtime niet 13 minuten maar 15 minuten bedraagt, wie kan hier dan de schuld van krijgen? Natuurlijk kan SRE de schuldige zijn, omdat hij duidelijk een of andere slechte inzet of inzet heeft gedaan. Mogelijk heeft de beheerder van het datacenter hier de schuld van, omdat hij mogelijk ongepland onderhoud heeft gepleegd. Als de beheerder van het datacentrum hier de schuld van heeft, dan is dat de schuld van de persoon van Ops, die het onderhoud niet heeft berekend toen hij de SLO coördineerde. De oorzaak hiervan is de manager, technisch directeur of iemand die het datacentercontract heeft getekend en er geen aandacht aan heeft besteed dat de SLA van het datacenter niet is ingericht op de benodigde downtime. Dienovereenkomstig is iedereen beetje bij beetje in deze situatie de schuldige. En het betekent dat het geen zin heeft om iemand in deze situatie de schuld te geven. Maar uiteraard moet dit gecorrigeerd worden. Daarom zijn er postmortems. En als je bijvoorbeeld postmortems van GitHub leest, en dit is in elk geval altijd een heel interessant, klein en onverwacht verhaal, dan kun je vervangen dat niemand ooit zegt dat deze specifieke persoon de schuldige was. De schuld wordt altijd gelegd bij specifieke imperfecte processen.
Laten we verder gaan met de volgende vraag. Automatisering. Als ik het in andere contexten over automatisering heb, verwijs ik vaak naar een tabel die je vertelt hoe lang je kunt werken aan het automatiseren van een taak zonder dat je meer tijd nodig hebt om deze te automatiseren dan je daadwerkelijk bespaart. Er zit een addertje onder het gras. Het addertje onder het gras is dat wanneer SRE's een taak automatiseren, ze niet alleen tijd, maar ook geld besparen, omdat automatisering rechtstreeks van invloed is op MTTR. Ze redden als het ware het moreel van werknemers en ontwikkelaars, wat ook een onuitputtelijke hulpbron is. Ze verminderen de routine. En dit alles heeft een positief effect op het werk en, als gevolg daarvan, op het bedrijfsleven, ook al lijkt het erop dat automatisering geen zin heeft in termen van tijdskosten.
In feite is dat bijna altijd zo, en er zijn maar weinig gevallen waarin iets in de rol van SRE niet geautomatiseerd zou moeten worden. Vervolgens zullen we het hebben over wat het foutenbudget wordt genoemd, het budget voor fouten. Sterker nog, het blijkt dat als alles veel beter voor je is dan de SLO die je jezelf stelt, dit ook niet zo goed is. Dit is nogal slecht, omdat SLO niet alleen als ondergrens werkt, maar ook als geschatte bovengrens. Wanneer je jezelf een SLO stelt van 99% beschikbaarheid, en feitelijk heb je 99,99%, dan blijkt dat je ruimte hebt voor experimenten die de business helemaal niet schaden, omdat je dit allemaal zelf hebt bepaald, en je bent deze ruimte wordt niet gebruikt. Je hebt een budget voor fouten, dat in jouw geval niet wordt opgebruikt.
Wat doen we ermee. Wij gebruiken het voor letterlijk alles. Voor testen in productieomstandigheden, voor het uitrollen van nieuwe functies die de prestaties kunnen beïnvloeden, voor releases, voor onderhoud, voor geplande downtime. De omgekeerde regel geldt ook: als het budget is uitgeput, kunnen we niets nieuws vrijgeven, omdat we anders de SLO overschrijden. Het budget is al op, we hebben iets vrijgegeven als het de prestaties negatief beïnvloedt, dat wil zeggen: als dit niet een soort oplossing is die op zichzelf de SLO direct verhoogt, dan gaan we verder dan het budget, en dit is een slechte situatie , het moet worden geanalyseerd, postmortem en mogelijk enkele procesoplossingen.
Dat wil zeggen, het blijkt dat als de service zelf niet goed werkt, en SLO wordt uitgegeven en het budget niet wordt besteed aan experimenten, niet aan sommige releases, maar aan zichzelf, dan in plaats van enkele interessante oplossingen, in plaats van interessante functies, in plaats van interessante releases. In plaats van enig creatief werk zul je te maken krijgen met domme oplossingen om de begroting weer op orde te krijgen, of de SLO te bewerken, en dit is ook een proces dat niet te vaak mag voorkomen.
Daarom blijkt dat in een situatie waarin we meer budget hebben voor fouten, iedereen geïnteresseerd is: zowel SRE als ontwikkelaars. Voor ontwikkelaars betekent een groot budget voor bugs dat je met releases, tests en experimenten om kunt gaan. Voor SRE’s betekent een budget voor fouten en het invoeren van dat budget dat ze hun werk direct goed doen. En dit beïnvloedt de motivatie van een soort gezamenlijk werk. Als je als ontwikkelaars naar je SRE’s luistert, heb je meer ruimte voor goed werk en veel minder routine.
Het blijkt dat experimenten in de productie een behoorlijk belangrijk en bijna integraal onderdeel zijn van SRE in grote teams. En het wordt meestal chaos-engineering genoemd, afkomstig van het team van Netflix dat een hulpprogramma heeft uitgebracht met de naam Chaos Monkey.
Chaos Monkey maakt verbinding met de CI/CD-pijplijn en crasht willekeurig de server tijdens productie. Nogmaals, in de SRE-structuur hebben we het over het feit dat een neergehaalde server op zichzelf niet slecht is, zo wordt verwacht. En als het binnen het budget valt, is het acceptabel en is het niet schadelijk voor het bedrijf. Natuurlijk heeft Netflix voldoende redundante servers, voldoende replicatie, zodat dit allemaal kan worden opgelost, en zodat de gebruiker als geheel het niet eens merkt, en meer nog, niemand verlaat één server voor welk budget dan ook.
Netflix beschikte al een tijdje over een hele reeks van dergelijke hulpprogramma's, waarvan er één, Chaos Gorilla, een van de beschikbaarheidszones van Amazon volledig afsluit. En zulke dingen helpen om in de eerste plaats verborgen afhankelijkheden aan het licht te brengen, wanneer het niet helemaal duidelijk is wat wat beïnvloedt, wat waarvan afhangt. En dit, als u met een microservice werkt en de documentatie niet helemaal perfect is, komt dit u misschien bekend voor. En nogmaals, dit helpt veel om fouten in de code op te sporen die je niet kunt ontdekken bij staging, omdat elke staging niet bepaald een exacte simulatie is, vanwege het feit dat de belastingsschaal anders is, het belastingspatroon anders is, de apparatuur is ook, hoogstwaarschijnlijk, anders. Piekbelastingen kunnen ook onverwacht en onvoorspelbaar zijn. En dergelijke tests, die wederom niet verder gaan dan het budget, helpen heel goed om fouten in de infrastructuur op te sporen die staging, autotests en CI / CD-pijplijn nooit zullen opvangen. En zolang het allemaal binnen je budget valt, maakt het niet uit dat je service daar uitviel, ook al lijkt het heel beangstigend, de server ging uit de lucht, wat een nachtmerrie. Nee, dat is normaal, dat is goed, dat helpt bij het opsporen van insecten. Als je een budget hebt, kun je het uitgeven.
Vraag: Welke literatuur kan ik aanbevelen? Lijst aan het einde. Er is veel literatuur, ik zal een paar rapporten adviseren. Hoe werkt het en werkt SRE in bedrijven zonder eigen softwareproduct of met minimale ontwikkeling. Bijvoorbeeld in een onderneming waar de hoofdactiviteit niet uit software bestaat. In een onderneming, waar de hoofdactiviteit niet software is, werkt SRE precies hetzelfde als overal elders, omdat je in een onderneming ook softwareproducten moet gebruiken, ook al zijn ze niet ontwikkeld, je updates moet uitrollen, je moet veranderen de infrastructuur, je moet groeien, je moet opschalen. En SRE's helpen bij het identificeren en voorspellen van mogelijke problemen in deze processen en het beheersen ervan nadat er enige groei is begonnen en de bedrijfsbehoeften zijn veranderd. Want het is absoluut niet nodig om betrokken te zijn bij softwareontwikkeling om een SRE te hebben als je minimaal een paar servers hebt en er minimaal enige groei van je wordt verwacht.
Hetzelfde geldt voor kleine projecten, kleine organisaties, omdat grote bedrijven het budget en de ruimte hebben om te experimenteren. Maar tegelijkertijd kunnen al deze vruchten van experimenten overal worden gebruikt, dat wil zeggen dat SRE natuurlijk verscheen in Google, op Netflix, in Dropbox. Maar tegelijkertijd kunnen kleine bedrijven en startups al beknopt materiaal lezen, boeken lezen, rapporten bekijken. Ze beginnen er vaker over te horen, ze kijken naar specifieke voorbeelden, ik vind het oké, het kan echt nuttig zijn, we hebben dit ook nodig, het is geweldig.
Dat wil zeggen dat al het belangrijkste werk voor het standaardiseren van deze processen al voor u is gedaan. Het blijft aan u om de rol van SRE specifiek in uw bedrijf te bepalen en al deze praktijken, die wederom al zijn beschreven, daadwerkelijk te implementeren. Dat wil zeggen, vanuit nuttige principes voor kleine bedrijven is dit altijd de definitie van SLA, SLI, SLO. Als je niet met software bezig bent, dan zijn dat interne SLA's en interne SLO's, een intern foutenbudget. Dit leidt bijna altijd tot interessante discussies binnen het team en binnen de business, omdat het kan blijken dat je geld uitgeeft aan infrastructuur, aan een soort organisatie van ideale processen, de ideale pijplijn is veel meer dan nodig is. En deze 4 negens die je hebt op de IT-afdeling, heb je nu niet echt nodig. Maar tegelijkertijd kunt u tijd besteden en het budget voor fouten aan iets anders besteden.
Daarom is monitoring en organisatie van monitoring nuttig voor een bedrijf van elke omvang. En over het algemeen is deze manier van denken, waarbij fouten acceptabel zijn, waar er een budget is, waar doelstellingen zijn, weer nuttig voor een bedrijf van elke omvang, beginnend bij startups voor 3 personen.
De laatste technische nuance waar we het over moeten hebben is monitoring. Want als we het hebben over SLA, SLI, SLO, kunnen we zonder te monitoren niet begrijpen of we in het budget passen, of we aan onze doelstellingen voldoen en hoe we de uiteindelijke SLA beïnvloeden. Ik heb zo vaak gezien dat monitoring op deze manier gebeurt: er zit een bepaalde waarde in, bijvoorbeeld de tijd van een verzoek aan de server, de gemiddelde tijd of het aantal verzoeken aan de database. Hij heeft een norm die is vastgesteld door een ingenieur. Als de statistiek afwijkt van de norm, komt er een e-mail binnen. Dit is in de regel allemaal absoluut nutteloos, omdat het leidt tot zo'n overvloed aan waarschuwingen, een overvloed aan berichten van monitoring, wanneer een persoon ze in de eerste plaats elke keer moet interpreteren, dat wil zeggen bepalen of de waarde van de metriek betekent de noodzaak van enige actie. En ten tweede merkt hij al deze waarschuwingen gewoon niet meer op, terwijl er eigenlijk geen actie van hem vereist is. Dat is een goede controleregel en de allereerste regel bij de implementatie van SRE is dat melding alleen mag plaatsvinden als er actie nodig is.
In het standaard geval zijn er 3 niveaus van gebeurtenissen. Er zijn waarschuwingen, er zijn tickets, er zijn logboeken. Waarschuwingen zijn alles waarvoor u onmiddellijk actie moet ondernemen. Dat wil zeggen, alles is kapot, je moet het nu repareren. Tickets vereisen vertraagde actie. Ja, je moet iets doen, je moet iets handmatig doen, de automatisering is mislukt, maar je hoeft het de komende minuten niet te doen. Logboeken zijn alles waarvoor geen actie nodig is, en over het algemeen zal niemand ze ooit lezen als alles goed gaat. Je hoeft de logs pas te lezen als achteraf blijkt dat er al een tijdje iets kapot is gegaan, wij wisten er niets van. Of moet je wat onderzoek doen. Maar over het algemeen gaat alles waarvoor geen actie nodig is, naar de logboeken.
Als neveneffect van dit alles: als we hebben gedefinieerd welke gebeurtenissen acties vereisen en goed hebben beschreven wat deze acties zouden moeten zijn, betekent dit dat de actie kan worden geautomatiseerd. Dat wil zeggen, wat er gebeurt. We gaan van alarm. Laten we tot actie overgaan. We gaan naar de beschrijving van deze actie. En dan gaan we verder met automatisering. Dat wil zeggen dat elke automatisering begint met een reactie op een gebeurtenis.
Van monitoring gaan we over naar een term die Observability wordt genoemd. Er is de afgelopen jaren ook een beetje hype rond dit woord geweest. En weinig mensen begrijpen wat het betekent zonder context. Maar het belangrijkste punt is dat waarneembaarheid een maatstaf is voor systeemtransparantie. Als er iets mis is gegaan, hoe snel kun je dan vaststellen wat er precies mis is gegaan en wat de staat van het systeem op dat moment was. In termen van code: welke functie faalde, welke service faalde. Wat was de status van bijvoorbeeld interne variabelen, configuratie. In termen van infrastructuur is dit de beschikbaarheidszone waarin de fout heeft plaatsgevonden, en als u Kubernetes heeft, in welke pod de fout heeft plaatsgevonden en wat de status van de pod was. En dienovereenkomstig heeft Observability een directe relatie met MTTR. Hoe hoger de waarneembaarheid van de service, hoe gemakkelijker het is om de fout te identificeren, hoe gemakkelijker het is om de fout op te lossen, hoe gemakkelijker het is om de fout te automatiseren, hoe lager de MTTR.
Als we weer naar de kleine bedrijven kijken, is het heel gebruikelijk om, zelfs nu nog, te vragen hoe om te gaan met de teamgrootte en of een klein team een aparte SRE moet inhuren. Hierover werd al iets eerder gesproken. In de eerste fasen van de ontwikkeling van een startup of bijvoorbeeld een team is dit helemaal niet nodig, omdat SRE een overgangsrol kan worden. En dit zal het team een beetje doen herleven, omdat er in ieder geval enige diversiteit is. En bovendien zal het mensen voorbereiden op het feit dat met de groei in het algemeen de verantwoordelijkheden van SRE aanzienlijk zullen veranderen. Als je iemand inhuurt, heeft hij natuurlijk enkele verwachtingen. En deze verwachtingen zullen in de loop van de tijd niet veranderen, maar de vereisten zullen wel heel erg veranderen. Daarom is het in de beginfase behoorlijk moeilijk om een SRE in te huren. Zelf kweken is veel eenvoudiger. Maar het is de moeite waard om erover na te denken.
De enige uitzondering is misschien wanneer er zeer strikte en goed gedefinieerde groei-eisen zijn. Dat wil zeggen, in het geval van een startup kan dit een soort druk van investeerders zijn, een soort voorspelling voor groei meerdere keren tegelijk. Dan is het inhuren van een SRE in principe gerechtvaardigd omdat het gerechtvaardigd kan worden. We hebben vereisten voor groei, we hebben een persoon nodig die verantwoordelijk is voor het feit dat met een dergelijke groei niets kapot zal gaan.
Nog een vraag. Wat te doen als de ontwikkelaars meerdere keren een functie hebben geknipt die de tests doorstaat, maar de productie verbreekt, de basis laadt, andere functies verbreekt, welk proces moet worden geïmplementeerd. In dit geval wordt dus het foutenbudget ingevoerd. En sommige services en sommige functies worden al in de productie getest. Het kan kanarie zijn, wanneer slechts een klein aantal gebruikers, maar al in de productie, een feature wordt ingezet, maar al met de verwachting dat als er iets kapot gaat, bijvoorbeeld voor een half procent van alle gebruikers, het nog steeds voldoet aan de budget voor fouten. Dienovereenkomstig, ja, er zal een fout optreden, voor sommige gebruikers zal alles kapot gaan, maar we hebben al gezegd dat dit normaal is.
Er was een vraag over SRE-tools. Dat wil zeggen: is er iets specifieks dat SRE's zouden gebruiken, wat alle anderen niet zouden gebruiken? In feite zijn er enkele zeer gespecialiseerde hulpprogramma's, er is een soort software die bijvoorbeeld belastingen simuleert of zich bezighoudt met kanarie A / B-testen. Maar feitelijk is de SRE-toolkit wat uw ontwikkelaars al gebruiken. Omdat SRE rechtstreeks samenwerkt met het ontwikkelingsteam. En als je verschillende tools hebt, zal het tijd kosten om te synchroniseren. Vooral als SRE's in grote teams werken, in grote bedrijven waar er meerdere teams kunnen zijn, zal bedrijfsbrede standaardisatie hier veel helpen, want als er in 50 teams 50 verschillende hulpprogramma's worden gebruikt, betekent dit dat de SRE ze moet kennen alle. En dit zal uiteraard nooit gebeuren. En de kwaliteit van het werk, de kwaliteit van de controle van ten minste enkele teams, zal aanzienlijk afnemen.
Ons webinar loopt ten einde. Ik heb enkele basiszaken kunnen vertellen. Natuurlijk is niets over SRE in een uur te vertellen en te begrijpen. Maar ik hoop dat ik deze manier van denken, de belangrijkste kernpunten, heb kunnen overbrengen. En dan zal het, als je geïnteresseerd bent, mogelijk zijn om je in het onderwerp te verdiepen, zelf te leren, te kijken hoe het door andere mensen, in andere bedrijven, wordt geïmplementeerd. Kom daarom begin februari naar Slurm SRE.
De Slurm SRE is een driedaagse intensieve cursus die gaat over waar ik het nu over heb, maar dan met veel meer diepgang, met echte cases, met praktijk, de hele intensive is gericht op praktisch werk. De mensen worden in teams verdeeld. Jullie gaan allemaal aan echte zaken werken. Daarom hebben we Booking.com-instructeurs Ivan Kruglov en Ben Tyler. We hebben een geweldige Eugene Barabbas van Google, uit San Francisco. En ik zal je ook iets vertellen. Kom dus zeker eens bij ons langs.
De bibliografie dus. Er zijn referenties over SRE. op hetzelfde boek, of beter gezegd op 2 boeken over SRE, geschreven door Google. Nog een , waar de voorwaarden en hun toepassing iets gedetailleerder zijn. De volgende 3 zijn rapporten over MVO in verschillende bedrijven. Eerst - , dit is een keynote van Ben Trainer van Google. Seconde - . De derde is alweer . Vierde rapport van , dat slechts vijf belangrijke SRE-werknemers heeft in 5 landen. Het is heel interessant om dit allemaal te bekijken, want net zoals DevOps heel verschillende dingen betekent voor verschillende bedrijven en zelfs verschillende teams, heeft SRE heel verschillende verantwoordelijkheden, zelfs in bedrijven van vergelijkbare grootte.
Nog 2 links over de principes van chaos engineering: , . En aan het eind staan er 3 lijstjes uit de serie Awesome Lists over , over en over . De lijst op SRE is ongelooflijk groot, het is niet nodig om alles door te nemen, er zijn ongeveer 200 artikelen. Ik kan artikelen van daar over capaciteitsplanning en over onberispelijke postmortem ten zeerste aanbevelen.
Interessant artikel:
Bedankt dat je al die tijd naar mij hebt geluisterd. Ik hoop dat je iets hebt geleerd. Ik hoop dat je genoeg materiaal hebt om nog meer te leren. En zie je. Hopelijk in februari.
Het webinar werd gepresenteerd door Eduard Medvedev.
PS: voor wie graag leest, Eduard gaf een lijst met referenties. Degenen die het liever in de praktijk willen begrijpen, zijn welkom .
Bron: www.habr.com