SRE (Site Reliability Engineering) je prístup k zabezpečeniu dostupnosti webových projektov. Považuje sa za rámec pre DevOps a hovorí o tom, ako dosiahnuť úspech pri uplatňovaní postupov DevOps. Preklad v tomto článku knihy od spoločnosti Google. Tento preklad som pripravil sám a opieral som sa o vlastné skúsenosti s pochopením monitorovacích procesov. V telegramovom kanáli и Publikoval som aj preklad 6. kapitoly tej istej knihy o cieľoch úrovne služieb.
Preklad kat. Užívať si čítanie!
Je nemožné riadiť službu, ak nerozumiete tomu, na ktorých ukazovateľoch skutočne záleží a ako ich merať a vyhodnocovať. Na tento účel definujeme a poskytujeme určitú úroveň služieb našim používateľom bez ohľadu na to, či používajú jedno z našich interných rozhraní API alebo verejný produkt.
Používame našu intuíciu, skúsenosti a pochopenie túžby používateľov porozumieť indikátorom úrovne služieb (SLI), cieľom úrovne služieb (SLO) a dohodám o úrovni služieb (SLA). Tieto dimenzie popisujú hlavné metriky, ktoré chceme sledovať a na ktoré budeme reagovať, ak nedokážeme poskytnúť očakávanú kvalitu služby. V konečnom dôsledku výber správnych metrík pomáha viesť správne kroky, ak sa niečo pokazí, a tiež dáva tímu SRE dôveru v zdravie služby.
Táto kapitola popisuje prístup, ktorý používame na boj proti problémom metrického modelovania, výberu metrík a metrickej analýzy. Väčšina vysvetlení bude bez príkladov, preto na ilustráciu hlavných bodov použijeme službu Shakespeare opísanú v jej príklade implementácie (vyhľadávanie Shakespearových diel).
Terminológia úrovne služieb
Mnohí čitatelia pravdepodobne poznajú koncept SLA, ale pojmy SLI a SLO si zaslúžia dôkladnú definíciu, pretože vo všeobecnosti je pojem SLA preťažený a má množstvo významov v závislosti od kontextu. Kvôli prehľadnosti chceme tieto hodnoty oddeliť.
Ukazovatele
SLI je indikátor úrovne služieb – starostlivo definované kvantitatívne meranie jedného aspektu úrovne poskytovaných služieb.
Pre väčšinu služieb sa kľúč SLI považuje za latenciu požiadavky – ako dlho trvá vrátenie odpovede na požiadavku. Ďalšie bežné SLI zahŕňajú chybovosť, často vyjadrenú ako zlomok všetkých prijatých požiadaviek, a priepustnosť systému, ktorá sa zvyčajne meria v požiadavkách za sekundu. Merania sú často agregované: najprv sa zozbierajú nespracované údaje a potom sa prevedú na mieru zmeny, priemer alebo percentil.
V ideálnom prípade SLI priamo meria úroveň záujmu o službu, ale niekedy je na meranie k dispozícii iba súvisiaca metrika, pretože pôvodnú metriku je ťažké získať alebo interpretovať. Napríklad latencia na strane klienta je často vhodnejšou metrikou, no sú chvíle, keď možno latenciu merať iba na serveri.
Ďalším typom SLI, ktorý je dôležitý pre SRE, je dostupnosť alebo čas, počas ktorého je možné službu používať. Často sa definuje ako miera úspešných žiadostí, niekedy nazývaná výnos. (Pre systémy na ukladanie údajov je dôležitá aj životnosť – pravdepodobnosť, že údaje sa budú uchovávať dlhší čas.) Hoci 100 % dostupnosť nie je možná, často sa dá dosiahnuť dostupnosť takmer 100 %; hodnoty dostupnosti sú vyjadrené ako počet "deviatok" » percento dostupnosti. Napríklad dostupnosť 99 % a 99,999 % môže byť označená ako „2 deviatky“ a „5 deviatky“. Aktuálny cieľ dostupnosti Google Compute Engine je „tri a pol deviatky“ alebo 99,95 %.
ciele
SLO je cieľ úrovne služby: cieľová hodnota alebo rozsah hodnôt pre úroveň služby, ktorú meria SLI. Normálna hodnota pre SLO je „SLI ≤ Target“ alebo „Lower Limit ≤ SLI ≤ Horná hranica“. Môžeme sa napríklad rozhodnúť, že výsledky vyhľadávania Shakespeara vrátime „rýchlo“ nastavením SLO na priemernú latenciu vyhľadávacieho dopytu menšiu ako 100 milisekúnd.
Výber správneho SLO je zložitý proces. Po prvé, nie vždy si môžete vybrať konkrétnu hodnotu. Pre externé prichádzajúce HTTP požiadavky na vašu službu je metrika Query Per Second (QPS) primárne určená túžbou vašich používateľov navštíviť vašu službu a nemôžete pre to nastaviť SLO.
Na druhej strane môžete povedať, že chcete, aby priemerná latencia pre každú požiadavku bola menšia ako 100 milisekúnd. Stanovenie takéhoto cieľa vás môže prinútiť napísať váš frontend s nízkou latenciou alebo kúpiť zariadenie, ktoré takúto latenciu poskytuje. (100 milisekúnd je samozrejme ľubovoľné číslo, ale je lepšie mať ešte nižšie čísla latencie. Existujú dôkazy, ktoré naznačujú, že vysoké rýchlosti sú lepšie ako nízke rýchlosti a že latencia pri spracovaní požiadaviek používateľov nad určitými hodnotami v skutočnosti núti ľudí držať sa ďalej z vašej služby.)
Opäť je to nejednoznačnejšie, ako by sa mohlo na prvý pohľad zdať: z výpočtu by ste nemali úplne vylúčiť QPS. Faktom je, že QPS a latencia spolu úzko súvisia: vyššie QPS často vedie k vyšším latenciám a služby zvyčajne zaznamenajú prudký pokles výkonu, keď dosiahnu určitú hranicu zaťaženia.
Výber a zverejnenie SLO určuje očakávania používateľov o tom, ako bude služba fungovať. Táto stratégia môže znížiť neopodstatnené sťažnosti voči vlastníkovi služby, ako je napríklad pomalý výkon. Bez explicitného SLO si používatelia často vytvárajú svoje vlastné očakávania o požadovanom výkone, ktoré nemusia mať nič spoločné s názormi ľudí, ktorí navrhujú a riadia službu. Táto situácia môže viesť k prehnaným očakávaniam od služby, keď sa používatelia mylne domnievajú, že služba bude dostupnejšia, než v skutočnosti je, a spôsobiť nedôveru, keď sa používatelia domnievajú, že systém je menej spoľahlivý, než v skutočnosti je.
Dohody
Dohoda o úrovni služieb je explicitná alebo implicitná zmluva s vašimi používateľmi, ktorá zahŕňa dôsledky splnenia (alebo nesplnenia) SLO, ktoré obsahujú. Dôsledky sa dajú najľahšie rozpoznať, keď sú finančné – zľava alebo pokuta – ale môžu mať aj iné formy. Jednoduchý spôsob, ako hovoriť o rozdieloch medzi SLO a SLA, je opýtať sa „čo sa stane, ak SLO nie sú splnené?“ Ak neexistujú žiadne jasné dôsledky, takmer určite sa pozeráte na SLO.
SRE sa zvyčajne nezúčastňuje vytvárania SLA, pretože SLA sú úzko spojené s obchodnými a produktovými rozhodnutiami. SRE sa však podieľa na pomoci pri zmierňovaní následkov neúspešných SLO. Môžu tiež pomôcť určiť SLI: Je zrejmé, že v dohode musí existovať objektívny spôsob merania SLO, inak dôjde k nezhode.
Vyhľadávanie Google je príkladom dôležitej služby, ktorá nemá verejnú zmluvu SLA: chceme, aby každý používal vyhľadávanie čo najefektívnejšie, ale nepodpísali sme zmluvu so svetom. Stále však existujú dôsledky, ak je vyhľadávanie nedostupné – nedostupnosť má za následok pokles našej reputácie, ako aj zníženie príjmov z reklamy. Mnohé ďalšie služby Google, ako napríklad Google for Work, majú s používateľmi explicitné zmluvy o úrovni služieb. Bez ohľadu na to, či konkrétna služba má SLA, je dôležité definovať SLI a SLO a použiť ich na správu služby.
Toľko teórie - teraz zažiť.
Ukazovatele v praxi
Vzhľadom na to, že sme dospeli k záveru, že je dôležité vybrať vhodné metriky na meranie úrovne služieb, ako teraz viete, ktoré metriky sú dôležité pre službu alebo systém?
Čo vás a vašich používateľov zaujíma?
Nemusíte používať každú metriku ako SLI, ktorú môžete sledovať v monitorovacom systéme; Pochopenie toho, čo používatelia od systému požadujú, vám pomôže vybrať niekoľko metrík. Výber príliš veľkého počtu indikátorov sťažuje zameranie sa na dôležité indikátory, zatiaľ čo výber malého počtu môže nechať veľké časti vášho systému bez dozoru. Na vyhodnotenie a pochopenie stavu systému zvyčajne používame niekoľko kľúčových indikátorov.
Služby možno vo všeobecnosti rozdeliť na niekoľko častí z hľadiska SLI, ktoré sú pre ne relevantné:
- Vlastné front-end systémy, ako napríklad vyhľadávacie rozhrania pre službu Shakespeare z nášho príkladu. Musia byť dostupné, bez oneskorenia a musia mať dostatočnú šírku pásma. V súlade s tým možno položiť otázky: môžeme odpovedať na žiadosť? Ako dlho trvalo odpovedať na žiadosť? Koľko žiadostí je možné spracovať?
- Skladovacie systémy. Oceňujú nízku latenciu odozvy, dostupnosť a odolnosť. Súvisiace otázky: Ako dlho trvá čítanie alebo zápis údajov? Môžeme na požiadanie získať prístup k údajom? Sú údaje dostupné, keď ich potrebujeme? Podrobnú diskusiu o týchto problémoch nájdete v kapitole 26 Integrita údajov: Čo čítate, to píšete.
- Systémy veľkých údajov, ako sú kanály na spracovanie údajov, sa spoliehajú na priepustnosť a latenciu spracovania dotazov. Súvisiace otázky: Koľko údajov sa spracúva? Ako dlho trvá prenos údajov od prijatia žiadosti po odoslanie odpovede? (Niektoré časti systému môžu mať v určitých fázach aj oneskorenia.)
Zbierka ukazovateľov
Mnoho indikátorov úrovne služieb sa najprirodzenejšie zhromažďuje na strane servera pomocou monitorovacieho systému, ako je Borgmon (pozri nižšie). ) alebo Prometheus, alebo jednoducho periodicky analyzuje protokoly, identifikuje odpovede HTTP so stavom 500. Niektoré systémy by však mali byť vybavené zberom metrík na strane klienta, pretože nedostatok monitorovania na strane klienta môže viesť k vynechaniu množstva problémov, ktoré ovplyvňujú používateľov, ale neovplyvňujú metriky na strane servera. Napríklad zameranie sa na latenciu odozvy koncového servera našej vyhľadávacej testovacej aplikácie Shakespeare môže viesť k oneskoreniu na strane používateľa v dôsledku problémov s JavaScriptom: v tomto prípade je lepšou metrikou meranie, ako dlho prehliadaču trvá spracovanie stránky.
Agregácia
Pre jednoduchosť a jednoduchosť použitia často agregujeme surové merania. Toto sa musí robiť opatrne.
Niektoré metriky sa zdajú jednoduché, napríklad požiadavky za sekundu, ale aj toto zjavne jednoduché meranie implicitne zhromažďuje údaje v priebehu času. Prijíma sa meranie konkrétne raz za sekundu alebo je meranie spriemerované z počtu žiadostí za minútu? Posledná možnosť môže skrývať oveľa vyšší okamžitý počet požiadaviek, ktoré trvajú len niekoľko sekúnd. Predstavte si systém, ktorý obsluhuje 200 požiadaviek za sekundu s párnymi číslami a nulou po zvyšok času. Konštanta v podobe priemernej hodnoty 0 požiadaviek za sekundu a dvojnásobok okamžitého zaťaženia nie je to isté. Podobne aj spriemerovanie latencie dotazov sa môže zdať atraktívne, ale skrýva dôležitý detail: je možné, že väčšina dopytov bude rýchla, ale bude veľa dopytov, ktoré budú pomalé.
Väčšinu ukazovateľov je lepšie vnímať ako distribúcie, nie ako priemery. Napríklad pre latenciu SLI budú niektoré požiadavky spracované rýchlo, zatiaľ čo niektoré budú trvať vždy dlhšie, niekedy oveľa dlhšie. Jednoduchý priemer môže skryť tieto dlhé oneskorenia. Obrázok ukazuje príklad: hoci doručenie typickej požiadavky trvá približne 50 ms, 5 % požiadaviek je 20-krát pomalších! Monitorovanie a upozorňovanie založené len na priemernej latencii nevykazuje zmeny v správaní počas dňa, pričom v skutočnosti dochádza k citeľným zmenám v dobe spracovania niektorých požiadaviek (najvyšší riadok).
Systémová latencia 50, 85, 95 a 99 percentilov. Os Y je v logaritmickom formáte.
Používanie percentilov pre ukazovatele vám umožňuje vidieť tvar rozdelenia a jeho charakteristiky: vysoká úroveň percentilu, ako napríklad 99 alebo 99,9, ukazuje najhoršiu hodnotu, zatiaľ čo percentil 50 (známy aj ako medián) zobrazuje najčastejší stav metrika. Čím väčší je rozptyl času odozvy, tým viac dlhotrvajúcich požiadaviek ovplyvňuje používateľskú skúsenosť. Účinok sa zvyšuje pri vysokom zaťažení a v prítomnosti front. Prieskum používateľskej skúsenosti ukázal, že ľudia vo všeobecnosti uprednostňujú pomalší systém s veľkým rozptylom času odozvy, takže niektoré tímy SRE sa zameriavajú iba na vysoké percentilové skóre na základe toho, že ak je správanie metriky na 99,9 percentile dobré, väčšina používateľov nebude mať problémy. .
Poznámka k štatistickým chybám
Vo všeobecnosti radšej pracujeme s percentilmi ako s priemerom (aritmetickým priemerom) súboru hodnôt. To nám umožňuje uvažovať o viac rozptýlených hodnotách, ktoré majú často výrazne odlišné (a zaujímavejšie) charakteristiky ako priemer. Kvôli umelej povahe výpočtových systémov sú metrické hodnoty často skreslené, napríklad žiadna požiadavka nemôže dostať odpoveď za menej ako 0 ms a časový limit 1000 ms znamená, že nemôžu byť úspešné odpovede s vyššími hodnotami. ako časový limit. V dôsledku toho nemôžeme akceptovať, že priemer a medián môžu byť rovnaké alebo blízko seba!
Bez predchádzajúceho testovania a pokiaľ neplatia určité štandardné predpoklady a aproximácie, dávame pozor, aby sme nedospeli k záveru, že naše údaje sú normálne distribuované. Ak distribúcia nie je taká, ako sa očakávalo, automatizačný proces, ktorý rieši problém (napríklad, keď vidí odľahlé hodnoty, reštartuje server s vysokým oneskorením spracovania požiadaviek), to môže robiť príliš často alebo nedostatočne často (oba nie sú veľmi dobre).
Štandardizovať ukazovatele
Odporúčame štandardizovať všeobecné charakteristiky pre SLI, aby ste o nich nemuseli zakaždým špekulovať. Akákoľvek funkcia, ktorá spĺňa štandardné vzory, môže byť vylúčená zo špecifikácie individuálneho SLI, napríklad:
- Intervaly agregácie: „v priemere za 1 minútu“
- Oblasti agregácie: „Všetky úlohy v klastri“
- Ako často sa vykonávajú merania: „Každých 10 sekúnd“
- Aké požiadavky sú zahrnuté: „HTTP GET z úloh monitorovania čiernej skrinky“
- Ako sa údaje získavajú: "Vďaka nášmu monitoringu meranému na serveri"
- Latencia prístupu k údajom: „Čas do posledného bajtu“
Ak chcete ušetriť námahu, vytvorte sadu opakovane použiteľných šablón SLI pre každú spoločnú metriku; tiež uľahčujú každému pochopiť, čo znamená určité SLI.
Ciele v praxi
Začnite tým, že sa zamyslíte (alebo zistíte!), čo vašich používateľov zaujíma, nie to, čo môžete merať. To, čo vašich používateľov zaujíma, je často ťažké alebo nemožné zmerať, takže sa nakoniec priblížite k ich potrebám. Ak však začnete s tým, čo sa dá ľahko merať, skončíte s menej užitočnými SLO. V dôsledku toho sme niekedy zistili, že počiatočná identifikácia želaných cieľov a potom práca s konkrétnymi ukazovateľmi funguje lepšie ako výber ukazovateľov a následné dosiahnutie cieľov.
Definujte ciele
Pre maximálnu jasnosť by sa malo definovať, ako sa merajú SLO a podmienky, za ktorých sú platné. Mohli by sme napríklad povedať nasledovné (druhý riadok je rovnaký ako prvý, ale používa predvolené hodnoty SLI):
- 99 % (v priemere za 1 minútu) hovorov Get RPC sa dokončí za menej ako 100 ms (merané na všetkých backendových serveroch).
- 99 % hovorov Get RPC sa dokončí za menej ako 100 ms.
Ak je tvar kriviek výkonnosti dôležitý, môžete zadať viacero SLO:
- 90 % hovorov Get RPC sa dokončí za menej ako 1 ms.
- 99 % hovorov Get RPC sa dokončí za menej ako 10 ms.
- 99.9 % hovorov Get RPC sa dokončí za menej ako 100 ms.
Ak vaši používatelia generujú heterogénne pracovné zaťaženia: hromadné spracovanie (pre ktoré je dôležitá priepustnosť) a interaktívne spracovanie (pre ktoré je dôležitá latencia), môže byť užitočné definovať samostatné ciele pre každú triedu zaťaženia:
- 95 % požiadaviek zákazníkov vyžaduje priepustnosť. Nastavte počet vykonaných RPC hovorov <1 s.
- 99% klientov sa stará o latenciu. Nastavte počet RPC hovorov s prevádzkou <1 KB a behu <10 ms.
Je nereálne a nežiaduce trvať na tom, že SLO budú splnené na 100 % času: môže to znížiť tempo zavádzania nových funkcií a nasadenia a vyžadovať drahé riešenia. Namiesto toho je lepšie povoliť chybový rozpočet – percento povoleného výpadku systému – a sledovať túto hodnotu denne alebo týždenne. Vrcholový manažment môže chcieť mesačné alebo štvrťročné hodnotenia. (Chybový rozpočet je jednoducho SLO na porovnanie s iným SLO.)
Percento porušení SLO možno porovnať s rozpočtom chýb (pozri kapitolu 3 a oddiel ), pričom hodnota rozdielu sa použije ako vstup do procesu, ktorý rozhoduje o nasadení nových vydaní.
Výber cieľových hodnôt
Výber plánovacích hodnôt (SLO) nie je čisto technickou činnosťou z dôvodu produktov a obchodných záujmov, ktoré sa musia odraziť vo vybraných SLI, SLO (a prípadne SLA). Podobne môže byť potrebné vymieňať si informácie o otázkach týkajúcich sa personálneho obsadenia, času uvedenia na trh, dostupnosti vybavenia a financovania. SRE by mala byť súčasťou tohto rozhovoru a mala by pomôcť pochopiť riziká a životaschopnosť rôznych možností. Prišli sme s niekoľkými otázkami, ktoré by mohli pomôcť zabezpečiť produktívnejšiu diskusiu:
Nevyberajte si cieľ podľa aktuálneho výkonu.
Zatiaľ čo pochopenie silných stránok a limitov systému je dôležité, prispôsobenie metrík bez uvažovania vám môže brániť v udržiavaní systému: bude to vyžadovať hrdinské úsilie na dosiahnutie cieľov, ktoré nemožno dosiahnuť bez výraznej zmeny dizajnu.
Nech je to jednoduché
Komplexné výpočty SLI môžu skryť zmeny vo výkone systému a sťažiť nájdenie príčiny problému.
Vyhnite sa absolútnym
Hoci je lákavé mať systém, ktorý dokáže zvládnuť nekonečne rastúcu záťaž bez zvýšenia latencie, táto požiadavka je nereálna. Systém, ktorý sa približuje k takýmto ideálom, bude pravdepodobne vyžadovať veľa času na návrh a zostavenie, bude nákladný na prevádzku a bude príliš dobrý pre očakávania používateľov, ktorí si vystačia s čímkoľvek menej.
Používajte čo najmenej SLO
Vyberte dostatočný počet SLO, aby ste zabezpečili dobré pokrytie systémových atribútov. Chráňte SLO, ktoré si vyberiete: Ak nikdy nemôžete vyhrať hádku o prioritách špecifikovaním konkrétneho SLO, pravdepodobne nestojí za zváženie tohto SLO. Nie všetky systémové atribúty sú však prístupné pre SLO: je ťažké vypočítať úroveň potešenia používateľa pomocou SLO.
Nenaháňajte sa za dokonalosťou
Definície a ciele SLO môžete vždy spresniť, keď sa dozviete viac o správaní systému pri zaťažení. Je lepšie začať s plávajúcim cieľom, ktorý budete časom spresňovať, ako si zvoliť príliš prísny cieľ, ktorý musíte uvoľniť, keď zistíte, že je nedosiahnuteľný.
SLO môžu a mali by byť kľúčovou hnacou silou pri uprednostňovaní práce pre SRE a vývojárov produktov, pretože odrážajú obavy používateľov. Dobrá SLO je užitočným nástrojom presadzovania pre vývojový tím. Ale zle navrhnuté SLO môže viesť k plytvaniu prácou, ak tím vynaloží hrdinské úsilie na dosiahnutie príliš agresívneho SLO, alebo zlého produktu, ak je SLO príliš nízke. SLO je silná páka, používajte ju rozumne.
Ovládajte svoje merania
SLI a SLO sú kľúčové prvky používané na správu systémov:
- Monitorujte a merajte SLI systémy.
- Porovnajte SLI a SLO a rozhodnite sa, či je potrebná akcia.
- Ak je potrebná akcia, zistite, čo sa musí stať, aby ste dosiahli cieľ.
- Dokončite túto akciu.
Ak napríklad krok 2 ukazuje, že časový limit požiadavky uplynie a ak sa nič neurobí, preruší SLO do niekoľkých hodín, krok 3 môže zahŕňať testovanie hypotézy, že servery sú viazané na procesor a pridanie ďalších serverov rozloží záťaž. Bez SLO by ste nevedeli, či (alebo kedy) máte konať.
Nastaviť SLO – potom sa nastavia očakávania používateľov
Publikovanie SLO stanovuje očakávania používateľov na správanie systému. Používatelia (a potenciálni používatelia) často chcú vedieť, čo môžu od služby očakávať, aby pochopili, či je vhodná na použitie. Napríklad ľudia, ktorí chcú používať webovú stránku na zdieľanie fotografií, sa možno budú chcieť vyhnúť používaniu služby, ktorá sľubuje dlhú životnosť a nízke náklady výmenou za o niečo menšiu dostupnosť, aj keď rovnaká služba môže byť ideálna pre systém správy archívnych záznamov.
Ak chcete svojim používateľom nastaviť realistické očakávania, použite jednu alebo obe z nasledujúcich taktík:
- Udržujte určitú mieru bezpečnosti. Používajte prísnejšie interné SLO, než aké sa inzeruje používateľom. To vám dá príležitosť reagovať na problémy skôr, ako sa stanú viditeľnými navonok. Vyrovnávacia pamäť SLO vám tiež umožňuje mať bezpečnostnú rezervu pri inštalácii verzií, ktoré ovplyvňujú výkon systému a zaisťujú jednoduchú údržbu systému bez toho, aby ste museli frustrovať používateľov prestojmi.
- Neprekračujte očakávania používateľov. Používatelia vychádzajú z toho, čo ponúkate, nie z toho, čo hovoríte. Ak je skutočný výkon vašej služby oveľa lepší ako uvedený SLO, používatelia sa budú spoliehať na aktuálny výkon. Prílišnej závislosti sa môžete vyhnúť zámerným vypnutím systému alebo obmedzením výkonu pri nízkej záťaži.
Pochopenie toho, ako dobre systém spĺňa očakávania, pomáha pri rozhodovaní, či investovať do zrýchlenia systému a jeho väčšej dostupnosti a odolnosti. Prípadne, ak služba funguje príliš dobre, určitý čas personálu by sa mal venovať iným prioritám, ako je splatenie technického dlhu, pridávanie nových funkcií alebo zavádzanie nových produktov.
Dohody v praxi
Vytvorenie zmluvy SLA vyžaduje, aby obchodné a právne tímy definovali dôsledky a sankcie za jej porušenie. Úlohou SRE je pomôcť im pochopiť pravdepodobné výzvy pri plnení SLO obsiahnutých v SLA. Väčšina odporúčaní na vytváranie SLO platí aj pre SLA. Je múdre byť konzervatívny v tom, čo sľubujete používateľom, pretože čím viac ich máte, tým ťažšie je zmeniť alebo odstrániť SLA, ktoré sa zdajú byť nerozumné alebo ťažko splniteľné.
Ďakujem, že ste si preklad prečítali až do konca. Prihláste sa na odber môjho telegramového kanála o monitorovaní и .
Zdroj: hab.com