SRE (Site Reliability Engineering) is een benadering om webprojecten toegankelijk te maken. Het wordt beschouwd als een raamwerk voor DevOps en vertelt hoe u kunt slagen in de toepassing van DevOps-praktijken. Dit artikel vertaalt boeken van Google. Ik heb deze vertaling zelf voorbereid en vertrouwde op mijn eigen ervaring met het begrijpen van monitoringprocessen. In het telegramkanaal и Ik heb ook een vertaling gepubliceerd van hoofdstuk 6 van hetzelfde boek over serviceniveaudoelen.
Vertaling door kat. Veel plezier met lezen!
Het is onmogelijk een dienst te beheren als er geen inzicht is in welke indicatoren er werkelijk toe doen en hoe deze te meten en evalueren. Daartoe definiëren en bieden wij een bepaald serviceniveau aan onze gebruikers, ongeacht of zij een van onze interne API's of een openbaar product gebruiken.
We gebruiken onze intuïtie, ervaring en begrip van de wens van gebruikers om Service Level Indicators (SLI's), Service Level Objectives (SLO's) en Service Level Agreements (SLA's) te begrijpen. Deze dimensies beschrijven de belangrijkste maatstaven die we willen monitoren en waarop we zullen reageren als we niet de verwachte kwaliteit van de dienstverlening kunnen bieden. Uiteindelijk helpt het kiezen van de juiste statistieken bij het begeleiden van de juiste acties als er iets misgaat, en geeft het het SRE-team ook vertrouwen in de gezondheid van de service.
Dit hoofdstuk beschrijft de aanpak die we gebruiken om de problemen van metrische modellering, metrische selectie en metrische analyse te bestrijden. Het grootste deel van de uitleg zal zonder voorbeelden zijn, dus zullen we de Shakespeare-service gebruiken die wordt beschreven in het implementatievoorbeeld (zoeken naar de werken van Shakespeare) om de belangrijkste punten te illustreren.
Terminologie op serviceniveau
Veel lezers zijn waarschijnlijk bekend met het concept SLA, maar de termen SLI en SLO verdienen een zorgvuldige definitie omdat de term SLA over het algemeen overbelast is en een aantal betekenissen heeft, afhankelijk van de context. Voor de duidelijkheid willen we deze waarden scheiden.
Indicatoren
De SLI is een serviceniveau-indicator: een zorgvuldig gedefinieerde kwantitatieve maatstaf voor één aspect van het geleverde serviceniveau.
Voor de meeste services wordt de belangrijkste SLI beschouwd als de latentie van verzoeken: hoe lang het duurt om een antwoord op een verzoek te retourneren. Andere veel voorkomende SLI's zijn het foutenpercentage, vaak uitgedrukt als een fractie van alle ontvangen verzoeken, en de systeemdoorvoer, meestal gemeten in verzoeken per seconde. Metingen worden vaak geaggregeerd: ruwe gegevens worden eerst verzameld en vervolgens omgezet in een veranderingspercentage, gemiddelde of percentiel.
Idealiter meet SLI rechtstreeks het gewenste serviceniveau, maar soms is alleen een gerelateerde metriek beschikbaar voor meting omdat de oorspronkelijke moeilijk te verkrijgen of te interpreteren is. De latentie aan de clientzijde is bijvoorbeeld vaak een geschiktere maatstaf, maar er zijn momenten waarop de latentie alleen op de server kan worden gemeten.
Een ander type SLI dat belangrijk is voor SRE's is de beschikbaarheid, oftewel het gedeelte van de tijd waarin een dienst kan worden gebruikt. Vaak gedefinieerd als het aantal succesvolle verzoeken, ook wel rendement genoemd. (Levensduur – de waarschijnlijkheid dat gegevens gedurende een langere periode worden bewaard – is ook belangrijk voor gegevensopslagsystemen.) Hoewel 100% beschikbaarheid niet mogelijk is, is een beschikbaarheid van bijna 100% vaak haalbaar; beschikbaarheidswaarden worden uitgedrukt als het aantal "negens" » percentage van beschikbaarheid. De beschikbaarheid van 99% en 99,999% kan bijvoorbeeld worden gelabeld als '2 negens' en '5 negens'. Het huidige beschikbaarheidsdoel van Google Compute Engine is "drie en een halve negens" of 99,95%.
doelen
Een SLO is een serviceniveaudoelstelling: een streefwaarde of bereik van waarden voor een serviceniveau dat wordt gemeten door de SLI. Een normale waarde voor SLO is “SLI ≤ Doel” of “Ondergrens ≤ SLI ≤ Bovengrens”. We kunnen bijvoorbeeld besluiten dat we Shakespeare-zoekresultaten ‘snel’ retourneren door de SLO in te stellen op een gemiddelde latentie voor zoekopdrachten van minder dan 100 milliseconden.
Het kiezen van de juiste SLO is een complex proces. Ten eerste kunt u niet altijd een specifieke waarde kiezen. Voor externe binnenkomende HTTP-verzoeken aan uw service wordt de statistiek Query Per Second (QPS) voornamelijk bepaald door de wens van uw gebruikers om uw service te bezoeken, en u kunt daarvoor geen SLO instellen.
Aan de andere kant kun je zeggen dat je wilt dat de gemiddelde latentie voor elk verzoek minder dan 100 milliseconden bedraagt. Als u een dergelijk doel stelt, kunt u ertoe worden gedwongen uw frontend met een lage latentie te schrijven of apparatuur te kopen die een dergelijke latentie biedt. (100 milliseconden is duidelijk een willekeurig getal, maar het is beter om nog lagere latentiecijfers te hebben. Er zijn aanwijzingen dat hoge snelheden beter zijn dan lage snelheden, en dat latentie bij het verwerken van gebruikersverzoeken boven bepaalde waarden mensen feitelijk dwingt weg te blijven van uw dienst.)
Nogmaals, dit is dubbelzinniger dan het op het eerste gezicht lijkt: je moet QPS niet volledig uitsluiten van de berekening. Feit is dat QPS en latency sterk met elkaar samenhangen: hogere QPS leidt vaak tot hogere latencies, en services ervaren doorgaans een scherpe prestatievermindering wanneer ze een bepaalde belastingsdrempel bereiken.
Door een SLO te selecteren en te publiceren, worden de verwachtingen van de gebruiker bepaald over hoe de service zal werken. Deze strategie kan ongegronde klachten tegen de service-eigenaar, zoals trage prestaties, verminderen. Zonder expliciete SLO creëren gebruikers vaak hun eigen verwachtingen over de gewenste prestaties, die misschien niets te maken hebben met de mening van de mensen die de service ontwerpen en beheren. Deze situatie kan leiden tot te hoge verwachtingen van de dienst, wanneer gebruikers ten onrechte denken dat de dienst toegankelijker zal zijn dan deze in werkelijkheid is, en wantrouwen veroorzaken wanneer gebruikers denken dat het systeem minder betrouwbaar is dan het in werkelijkheid is.
Overeenkomsten
Een Service Level Agreement is een expliciet of impliciet contract met uw gebruikers waarin de gevolgen zijn opgenomen van het al dan niet voldoen aan de SLO's die zij bevatten. Gevolgen zijn het gemakkelijkst te onderkennen als ze van financiële aard zijn (een korting of een boete), maar ze kunnen ook andere vormen aannemen. Een gemakkelijke manier om over het verschil tussen SLO's en SLA's te praten, is door te vragen: "Wat gebeurt er als niet aan de SLO's wordt voldaan?" Als er geen duidelijke consequenties zijn, heb je vrijwel zeker te maken met een SLO.
De SRE is doorgaans niet betrokken bij het opstellen van SLA's, omdat SLA's nauw verbonden zijn met bedrijfs- en productbeslissingen. De SRE is echter betrokken bij het helpen verzachten van de gevolgen van mislukte SLO's. Ze kunnen ook helpen bij het bepalen van de SLI: Uiteraard moet er een objectieve manier zijn om de SLO in de overeenkomst te meten, anders ontstaat er onenigheid.
Google Zoeken is een voorbeeld van een belangrijke dienst die geen publieke SLA kent: we willen dat iedereen Search zo efficiënt mogelijk gebruikt, maar we hebben nog geen contract getekend met de wereld. Er zijn echter nog steeds gevolgen als de zoekopdracht niet beschikbaar is: onbeschikbaarheid resulteert in een daling van onze reputatie en in lagere advertentie-inkomsten. Veel andere Google-services, zoals Google for Work, hebben expliciete Service Level Agreements met gebruikers. Ongeacht of een bepaalde dienst een SLA heeft, is het belangrijk om de SLI en SLO te definiëren en deze te gebruiken om de dienst te beheren.
Zoveel theorie - nu aan de slag.
Indicatoren in de praktijk
Gegeven het feit dat we tot de conclusie zijn gekomen dat het belangrijk is om de juiste maatstaven te selecteren om het serviceniveau te meten, hoe weet je nu welke maatstaven belangrijk zijn voor een dienst of systeem?
Wat vinden u en uw gebruikers belangrijk?
U hoeft niet elke metriek te gebruiken als een SLI die u kunt volgen in een monitoringsysteem; Als u begrijpt wat gebruikers van een systeem willen, kunt u verschillende statistieken selecteren. Als u te veel indicatoren kiest, wordt het moeilijk om u op belangrijke indicatoren te concentreren, terwijl het kiezen van een klein aantal grote delen van uw systeem onbeheerd kan achterlaten. We gebruiken doorgaans verschillende sleutelindicatoren om de gezondheid van een systeem te evalueren en te begrijpen.
Services kunnen over het algemeen worden opgesplitst in verschillende delen in termen van SLI die voor hen relevant zijn:
- Maatwerk front-end systemen, zoals de zoekinterfaces voor de Shakespeare dienst uit ons voorbeeld. Ze moeten beschikbaar zijn, geen vertragingen hebben en voldoende bandbreedte hebben. Er kunnen dan ook vragen gesteld worden: kunnen wij reageren op het verzoek? Hoe lang duurde het voordat er op het verzoek werd gereageerd? Hoeveel verzoeken kunnen worden verwerkt?
- Opslagsystemen. Ze waarderen een lage responslatentie, beschikbaarheid en duurzaamheid. Gerelateerde vragen: Hoe lang duurt het lezen of schrijven van gegevens? Kunnen wij op verzoek inzage krijgen in de gegevens? Zijn de gegevens beschikbaar wanneer we ze nodig hebben? Zie Hoofdstuk 26 Gegevensintegriteit: wat u leest is wat u schrijft voor een gedetailleerde bespreking van deze kwesties.
- Big data-systemen, zoals pijplijnen voor gegevensverwerking, zijn afhankelijk van de doorvoer en de latentie van de verwerking van query's. Gerelateerde vragen: Hoeveel gegevens worden er verwerkt? Hoe lang duurt het voordat gegevens zich verplaatsen vanaf het ontvangen van een verzoek tot het geven van een antwoord? (Sommige delen van het systeem kunnen in bepaalde fasen ook vertraging oplopen.)
Verzameling van indicatoren
Veel serviceniveau-indicatoren worden uiteraard verzameld aan de serverzijde, met behulp van een monitoringsysteem zoals Borgmon (zie hieronder). ) of Prometheus, of eenvoudigweg periodiek de logboeken analyseren, waarbij HTTP-reacties met status 500 worden geïdentificeerd. Sommige systemen moeten echter worden uitgerust met het verzamelen van statistieken aan de clientzijde, omdat het gebrek aan monitoring aan de clientzijde kan leiden tot het missen van een aantal problemen die van invloed zijn op gebruikers, maar hebben geen invloed op de statistieken aan de serverzijde. Als u zich bijvoorbeeld concentreert op de responslatentie van de backend van onze Shakespeare-zoektestapplicatie, kan dit resulteren in latentie aan de gebruikerszijde vanwege JavaScript-problemen: in dit geval is het meten van hoe lang het duurt voordat de browser de pagina heeft verwerkt een betere maatstaf.
Aggregatie
Voor eenvoud en gebruiksgemak aggregeren we vaak ruwe metingen. Dit moet zorgvuldig gebeuren.
Sommige statistieken lijken eenvoudig, zoals verzoeken per seconde, maar zelfs deze ogenschijnlijk eenvoudige meting verzamelt impliciet gegevens in de loop van de tijd. Wordt de meting specifiek één keer per seconde ontvangen of wordt de meting gemiddeld over het aantal verzoeken per minuut? Deze laatste optie kan een veel groter onmiddellijk aantal verzoeken verbergen die slechts een paar seconden duren. Overweeg een systeem dat 200 verzoeken per seconde verwerkt, met even getallen en de rest van de tijd 0. Een constante in de vorm van een gemiddelde waarde van 100 verzoeken per seconde en tweemaal de momentane belasting zijn niet hetzelfde. Op dezelfde manier lijkt het middelen van de latenties van zoekopdrachten misschien aantrekkelijk, maar het verbergt een belangrijk detail: het is mogelijk dat de meeste zoekopdrachten snel zullen zijn, maar er zullen veel zoekopdrachten zijn die langzaam zijn.
De meeste indicatoren kunnen beter worden gezien als verdelingen dan als gemiddelden. Voor SLI-latentie zullen sommige verzoeken bijvoorbeeld snel worden verwerkt, terwijl andere altijd langer, soms veel langer, zullen duren. Een eenvoudig gemiddelde kan deze lange vertragingen verbergen. De figuur toont een voorbeeld: hoewel het verwerken van een typisch verzoek ongeveer 50 ms duurt, is 5% van de verzoeken 20 keer langzamer! Monitoring en waarschuwingen die uitsluitend op gemiddelde latentie zijn gebaseerd, laten geen gedragsveranderingen gedurende de dag zien, terwijl er in feite wel merkbare veranderingen zijn in de verwerkingstijd van sommige verzoeken (bovenste regel).
Systeemlatentie van 50, 85, 95 en 99 percentiel. De Y-as heeft een logaritmisch formaat.
Door percentielen als indicatoren te gebruiken, kunt u de vorm van de verdeling en de kenmerken ervan zien: een hoog percentielniveau, zoals 99 of 99,9, toont de slechtste waarde, terwijl het 50-percentiel (ook bekend als de mediaan) de meest voorkomende toestand toont. de metriek. Hoe groter de spreiding van de responstijd, hoe groter de impact van langlopende verzoeken op de gebruikerservaring. Het effect wordt versterkt bij hoge belasting en bij aanwezigheid van wachtrijen. Uit onderzoek naar gebruikerservaringen is gebleken dat mensen over het algemeen de voorkeur geven aan een langzamer systeem met een hoge responstijdvariantie. Daarom richten sommige SRE-teams zich alleen op hoge percentielscores, op basis van het feit dat als het gedrag van een metriek op het 99,9-percentiel goed is, de meeste gebruikers geen problemen zullen ondervinden. .
Opmerking over statistische fouten
Over het algemeen werken we liever met percentielen dan met het gemiddelde (rekenkundig gemiddelde) van een reeks waarden. Hierdoor kunnen we rekening houden met meer verspreide waarden, die vaak aanzienlijk andere (en interessantere) kenmerken hebben dan het gemiddelde. Vanwege de kunstmatige aard van computersystemen zijn metrische waarden vaak scheef, zodat geen enkel verzoek binnen 0 ms een antwoord kan ontvangen, en een time-out van 1000 ms betekent dat er geen succesvolle antwoorden kunnen zijn met waarden groter dan de time-out. Als gevolg hiervan kunnen we niet accepteren dat het gemiddelde en de mediaan hetzelfde kunnen zijn of dicht bij elkaar kunnen liggen!
Zonder voorafgaande tests, en tenzij bepaalde standaardaannames en benaderingen gelden, zorgen we ervoor dat we niet concluderen dat onze gegevens normaal verdeeld zijn. Als de distributie niet is zoals verwacht, kan het automatiseringsproces dat het probleem oplost (als het bijvoorbeeld uitschieters constateert, de server opnieuw opstarten met hoge latenties voor de verwerking van verzoeken) dit mogelijk te vaak of niet vaak genoeg doen (beide zijn niet erg goed).
Standaardiseer indicatoren
We raden aan de algemene kenmerken voor SLI te standaardiseren, zodat u er niet elke keer over hoeft te speculeren. Elke functie die aan standaardpatronen voldoet, kan worden uitgesloten van de specificatie van een individuele SLI, bijvoorbeeld:
- Aggregatie-intervallen: “gemiddeld over 1 minuut”
- Aggregatiegebieden: “Alle taken in het cluster”
- Hoe vaak er wordt gemeten: “Elke 10 seconden”
- Welke verzoeken zijn ingeschakeld: 'HTTP GET van black box-monitoringtaken'
- Hoe de gegevens worden verkregen: "Dankzij onze monitoring gemeten op de server"
- Latentie voor gegevenstoegang: 'Tijd tot laatste byte'
Om moeite te besparen, kunt u voor elke gemeenschappelijke metriek een set herbruikbare SLI-sjablonen maken; ze maken het ook voor iedereen gemakkelijker om te begrijpen wat een bepaalde SLI betekent.
Doelen in de praktijk
Begin door na te denken over (of erachter te komen!) wat uw gebruikers belangrijk vinden, niet wat u kunt meten. Vaak is datgene wat uw gebruikers belangrijk vinden moeilijk of onmogelijk te meten, waardoor u uiteindelijk dichter bij hun behoeften komt. Als je echter gewoon begint met wat gemakkelijk te meten is, kom je uit op minder bruikbare SLO's. Als gevolg hiervan hebben we soms ontdekt dat het in eerste instantie identificeren van gewenste doelen en vervolgens werken met specifieke indicatoren beter werkt dan het kiezen van indicatoren en het vervolgens bereiken van de doelen.
Definieer uw doelen
Voor maximale duidelijkheid moet worden gedefinieerd hoe SLO's worden gemeten en onder welke omstandigheden ze geldig zijn. We zouden bijvoorbeeld het volgende kunnen zeggen (de tweede regel is hetzelfde als de eerste, maar gebruikt de SLI-standaardwaarden):
- 99% (gemiddeld over 1 minuut) van de Get RPC-aanroepen wordt in minder dan 100 ms voltooid (gemeten op alle backend-servers).
- 99% van de Get RPC-oproepen wordt in minder dan 100 ms voltooid.
Als de vorm van de prestatiecurven belangrijk is, kunt u meerdere SLO's opgeven:
- 90% van de Get RPC-oproepen wordt in minder dan 1 ms voltooid.
- 99% van de Get RPC-oproepen wordt in minder dan 10 ms voltooid.
- 99.9% van de Get RPC-oproepen wordt in minder dan 100 ms voltooid.
Als uw gebruikers heterogene werklasten genereren: bulkverwerking (waarvoor doorvoer belangrijk is) en interactieve verwerking (waarvoor latentie belangrijk is), kan het de moeite waard zijn om voor elke belastingsklasse afzonderlijke doelen te definiëren:
- 95% van de klantverzoeken vereist doorvoer. Stel het aantal uitgevoerde RPC-oproepen in <1 s.
- 99% van de klanten geeft om de latentie. Stel het aantal RPC-oproepen in met verkeer <1 KB en een looptijd van <10 ms.
Het is onrealistisch en onwenselijk om erop te hameren dat de SLO's 100% van de tijd zullen worden nageleefd: dit kan het tempo van de introductie van nieuwe functionaliteit en implementatie vertragen en dure oplossingen vereisen. In plaats daarvan is het beter om een foutenbudget toe te staan (het toegestane percentage systeemuitval) en deze waarde dagelijks of wekelijks te monitoren. Het senior management wil mogelijk maandelijkse of driemaandelijkse evaluaties. (Het foutenbudget is eenvoudigweg een SLO ter vergelijking met een andere SLO.)
Het percentage SLO-schendingen kan worden vergeleken met het foutenbudget (zie Hoofdstuk 3 en sectie ), waarbij de verschilwaarde wordt gebruikt als invoer voor het proces dat beslist wanneer nieuwe releases moeten worden geïmplementeerd.
Doelwaarden selecteren
Het selecteren van planningswaarden (SLO’s) is geen puur technische activiteit vanwege de product- en bedrijfsbelangen die tot uiting moeten komen in de geselecteerde SLI’s, SLO’s (en eventueel SLA’s). Op dezelfde manier moet mogelijk informatie worden uitgewisseld over kwesties die verband houden met personeel, time-to-market, beschikbaarheid van apparatuur en financiering. SRE moet deel uitmaken van dit gesprek en helpen de risico's en haalbaarheid van verschillende opties te begrijpen. We hebben een paar vragen bedacht die kunnen bijdragen aan een productievere discussie:
Kies geen doel op basis van de huidige prestaties.
Hoewel het belangrijk is om de sterke punten en beperkingen van een systeem te begrijpen, kan het zonder reden aanpassen van meetgegevens u ervan weerhouden het systeem in stand te houden: het zal heroïsche inspanningen vergen om doelen te bereiken die niet kunnen worden bereikt zonder een grondig herontwerp.
Wees eenvoudig
Complexe SLI-berekeningen kunnen veranderingen in de systeemprestaties verbergen en het moeilijker maken om de oorzaak van het probleem te vinden.
Vermijd absolute waarden
Hoewel het verleidelijk is om een systeem te hebben dat een oneindig groeiende belasting aankan zonder de latentie te vergroten, is deze vereiste onrealistisch. Een systeem dat dergelijke idealen benadert, zal waarschijnlijk veel tijd vergen om te ontwerpen en te bouwen, zal duur zijn in het gebruik en zal te goed zijn voor de verwachtingen van gebruikers die met minder genoegen zouden nemen.
Gebruik zo min mogelijk SLO's
Selecteer een voldoende aantal SLO's om een goede dekking van systeemkenmerken te garanderen. Bescherm de SLO's die u kiest: Als u een discussie over prioriteiten nooit kunt winnen door een specifieke SLO te specificeren, is het waarschijnlijk niet de moeite waard om die SLO te overwegen. Niet alle systeemkenmerken zijn echter vatbaar voor SLO's: het is moeilijk om het niveau van gebruikerstevredenheid te berekenen met behulp van SLO's.
Streef geen perfectie na
U kunt de definities en doelstellingen van SLO's in de loop van de tijd altijd verfijnen naarmate u meer te weten komt over het gedrag van het systeem onder belasting. Het is beter om te beginnen met een zwevend doel dat je in de loop van de tijd zult verfijnen, dan een al te strikt doel te kiezen dat moet worden versoepeld als je merkt dat het onhaalbaar is.
SLO's kunnen en moeten een belangrijke drijfveer zijn bij het prioriteren van werk voor SRE's en productontwikkelaars, omdat ze een zorg voor gebruikers weerspiegelen. Een goede SLO is een nuttig handhavingsinstrument voor een ontwikkelteam. Maar een slecht ontworpen SLO kan leiden tot verspillend werk als het team heldhaftige pogingen doet om een al te agressieve SLO te bereiken, of tot een slecht product als de SLO te laag is. SLO is een krachtige hefboom, gebruik deze verstandig.
Beheer uw metingen
SLI en SLO zijn sleutelelementen die worden gebruikt om systemen te beheren:
- Bewaak en meet SLI-systemen.
- Vergelijk SLI met SLO en beslis of actie nodig is.
- Als er actie nodig is, bedenk dan wat er moet gebeuren om het doel te bereiken.
- Voltooi deze actie.
Als uit stap 2 bijvoorbeeld blijkt dat het verzoek een time-out heeft en de SLO binnen een paar uur wordt verbroken als er niets wordt gedaan, kan stap 3 het testen van de hypothese inhouden dat de servers CPU-gebonden zijn en het toevoegen van meer servers de belasting zal verdelen. Zonder SLO weet u niet of (en wanneer) u actie moet ondernemen.
Stel SLO in - vervolgens worden de verwachtingen van de gebruiker ingesteld
Het publiceren van een SLO stelt gebruikersverwachtingen voor systeemgedrag vast. Gebruikers (en potentiële gebruikers) willen vaak weten wat ze van een dienst kunnen verwachten om te begrijpen of deze geschikt is voor gebruik. Mensen die bijvoorbeeld een website voor het delen van foto's willen gebruiken, willen mogelijk geen gebruik maken van een dienst die een lange levensduur en lage kosten belooft in ruil voor iets minder beschikbaarheid, ook al zou dezelfde dienst ideaal kunnen zijn voor een archiefbeheersysteem.
Gebruik een of beide van de volgende tactieken om realistische verwachtingen voor uw gebruikers te scheppen:
- Zorg voor een veiligheidsmarge. Gebruik een strengere interne SLO dan wat aan gebruikers wordt geadverteerd. Dit geeft u de mogelijkheid om op problemen te reageren voordat deze extern zichtbaar worden. Met de SLO-buffer beschikt u ook over een veiligheidsmarge bij het installeren van releases die de systeemprestaties beïnvloeden en ervoor zorgen dat het systeem gemakkelijk te onderhouden is zonder gebruikers te frustreren met downtime.
- Overtref de verwachtingen van de gebruiker niet. Gebruikers zijn gebaseerd op wat u aanbiedt, niet op wat u zegt. Als de daadwerkelijke prestaties van uw dienst veel beter zijn dan de aangegeven SLO, zullen gebruikers vertrouwen op de huidige prestaties. U kunt een te grote afhankelijkheid voorkomen door het systeem opzettelijk uit te schakelen of de prestaties onder lichte belasting te beperken.
Als u begrijpt hoe goed een systeem aan de verwachtingen voldoet, kunt u beslissen of u wilt investeren in het versnellen van het systeem en het toegankelijker en veerkrachtiger maken ervan. Als een dienst te goed presteert, moet een deel van de tijd van het personeel aan andere prioriteiten worden besteed, zoals het afbetalen van technische schulden, het toevoegen van nieuwe functies of het introduceren van nieuwe producten.
Afspraken in de praktijk
Het creëren van een SLA vereist dat zakelijke en juridische teams de gevolgen en straffen voor het overtreden ervan definiëren. De rol van de SRE is om hen te helpen inzicht te krijgen in de waarschijnlijke uitdagingen bij het voldoen aan de SLO's die in de SLA zijn opgenomen. De meeste aanbevelingen voor het maken van SLO's zijn ook van toepassing op SLA's. Het is verstandig om conservatief te zijn in wat u gebruikers belooft, want hoe meer u heeft, hoe moeilijker het is om SLA's die onredelijk of moeilijk te voldoen lijken, te wijzigen of te verwijderen.
Bedankt voor het lezen van de vertaling tot het einde. Abonneer je op mijn telegramkanaal over monitoring и .
Bron: www.habr.com