Az SRE (Site Reliability Engineering) egy megközelítés a webes projektek elérhetőségének biztosítására. Ez a DevOps keretrendszere, és arról beszél, hogyan érhet el sikereket a DevOps gyakorlatok alkalmazásában. Fordítás ebben a cikkben könyvek a Google-tól. Ezt a fordítást magam készítettem, és saját tapasztalataimra támaszkodtam a megfigyelési folyamatok megértésében. A távirati csatornán и Kiadtam ugyanennek a könyvnek a szolgáltatási szintű célokról szóló 6. fejezetének fordítását is.
Fordítás: cat. Élvezd az olvasást!
Lehetetlen egy szolgáltatást menedzselni, ha nem értjük, hogy valójában milyen mutatók számítanak, és hogyan mérjük és értékeljük azokat. Ennek érdekében meghatározunk és bizonyos szintű szolgáltatást nyújtunk felhasználóinknak, függetlenül attól, hogy valamelyik belső API-nkat vagy nyilvános terméket használnak.
Használjuk megérzéseinket, tapasztalatainkat és a felhasználók azon vágyának megértését, hogy megértsék a szolgáltatási szintjelzőket (SLI), a szolgáltatási szintű célkitűzéseket (SLO) és a szolgáltatási szint megállapodásokat (SLA). Ezek a dimenziók leírják azokat a főbb mérőszámokat, amelyeket ellenőrizni szeretnénk, és amelyekre reagálni fogunk, ha nem tudjuk az elvárt szolgáltatásminőséget nyújtani. Végső soron a megfelelő mérőszámok kiválasztása segít a megfelelő intézkedések megtételében, ha valami rosszul sül el, és az SRE csapatának bizalmat ad a szolgáltatás állapotában.
Ez a fejezet azt a megközelítést írja le, amelyet a metrikus modellezés, a metrikaválasztás és a metrikus elemzés problémáinak leküzdésére használunk. A magyarázat nagy része példa nélkül lesz, ezért a megvalósítási példájában leírt Shakespeare szolgáltatást (Shakespeare műveinek keresése) fogjuk használni a főbb szempontok illusztrálására.
Szolgáltatási szintű terminológia
Valószínűleg sok olvasó ismeri az SLA fogalmát, de az SLI és SLO kifejezések alapos definíciót érdemelnek, mivel az SLA kifejezés általában túlterhelt, és a kontextustól függően számos jelentéssel bír. Az érthetőség kedvéért ezeket az értékeket külön szeretnénk választani.
Mutatók
Az SLI a szolgáltatási szint mutatója – a nyújtott szolgáltatási szint egy aspektusának gondosan meghatározott mennyiségi mérőszáma.
A legtöbb szolgáltatás esetében a kulcs SLI-t a kérés késleltetésének tekintik – mennyi ideig tart a kérésre adott válasz visszaadása. Egyéb gyakori SLI-k közé tartozik a hibaarány, amelyet gyakran az összes fogadott kérés töredékében fejeznek ki, és a rendszer átviteli sebességét, amelyet általában másodpercenkénti kérésekben mérnek. A méréseket gyakran összesítik: először a nyers adatokat gyűjtik össze, majd alakítják át változási rátára, átlagra vagy százalékosra.
Ideális esetben az SLI közvetlenül méri az érdeklődésre számot tartó szolgáltatási szintet, de néha csak egy kapcsolódó mérőszám áll rendelkezésre a méréshez, mert az eredetit nehéz megszerezni vagy értelmezni. Például az ügyféloldali késleltetés gyakran megfelelőbb mérőszám, de vannak esetek, amikor a késleltetést csak a szerveren lehet mérni.
Az SLI-k másik típusa, amely fontos az SRE-k számára, a rendelkezésre állás, vagy az az idő, amely alatt egy szolgáltatás használható. Gyakran a sikeres kérelmek arányaként határozzák meg, néha hozamnak is nevezik. (Az élettartam – az adatok hosszabb ideig tartó megőrzésének valószínűsége – szintén fontos az adattároló rendszerek esetében.) Bár a 100%-os rendelkezésre állás nem lehetséges, a 100%-hoz közeli rendelkezésre állás gyakran elérhető; a rendelkezésre állási értékeket a következőképpen fejezzük ki: a "kilenc" » rendelkezésre állás százaléka. Például a 99%-os és a 99,999%-os rendelkezésre állást "2 kilences" és "5 kilences" címkével lehet ellátni. A Google Compute Engine jelenlegi rendelkezésre állási célja „három és fél kilenc”, azaz 99,95%.
célok
Az SLO egy szolgáltatási szint célkitűzés: egy szolgáltatási szint célértéke vagy értéktartománya, amelyet az SLI mér. Az SLO normál értéke „SLI ≤ cél” vagy „Alsó határ ≤ SLI ≤ felső határ”. Például dönthetünk úgy, hogy a Shakespeare-keresési eredményeket „gyorsan” adjuk vissza, ha az SLO-t 100 ezredmásodpercnél rövidebb átlagos keresési késleltetésre állítjuk be.
A megfelelő SLO kiválasztása összetett folyamat. Először is, nem mindig választhat egy konkrét értéket. A szolgáltatáshoz érkező külső HTTP-kérelmek esetén a Query Per Second (QPS) mérőszámot elsősorban az határozza meg, hogy a felhasználók szeretnék meglátogatni a szolgáltatást, és ehhez nem állíthat be SLO-t.
Másrészt elmondhatja, hogy azt szeretné, hogy az egyes kérések átlagos késleltetése 100 ezredmásodpercnél kevesebb legyen. Egy ilyen cél kitűzése arra kényszerítheti, hogy alacsony késleltetéssel írja meg a frontendet, vagy vásároljon olyan berendezést, amely ilyen késleltetést biztosít. (A 100 ezredmásodperc nyilvánvalóan tetszőleges szám, de jobb, ha a késleltetési idő még alacsonyabb. Bizonyítékok vannak arra, hogy a gyors sebesség jobb, mint a lassú, és hogy a felhasználói kérések feldolgozásának késleltetése bizonyos értékek felett valójában arra kényszeríti az embereket, hogy távol maradjanak az Ön szolgálatától.)
Ez ismét kétértelműbb, mint amilyennek első pillantásra tűnhet: nem szabad teljesen kizárni a QPS-t a számításból. A helyzet az, hogy a QPS és a késleltetés erősen összefügg egymással: a magasabb QPS gyakran magasabb késleltetésekhez vezet, és a szolgáltatások teljesítménye általában meredeken csökken, amikor elér egy bizonyos terhelési küszöböt.
Az SLO kiválasztása és közzététele meghatározza a felhasználók elvárásait a szolgáltatás működésével kapcsolatban. Ez a stratégia csökkentheti a szolgáltatás tulajdonosával szembeni megalapozatlan panaszokat, például a lassú teljesítményt. Kifejezett SLO nélkül a felhasználók gyakran saját elvárásaikat alakítják ki a kívánt teljesítménnyel kapcsolatban, aminek esetleg semmi köze a szolgáltatást tervező és irányító emberek véleményéhez. Ez a helyzet túlzott elvárásokhoz vezethet a szolgáltatással szemben, amikor a felhasználók tévesen azt hiszik, hogy a szolgáltatás elérhetőbb lesz, mint amilyen valójában, és bizalmatlanságot kelthet, ha a felhasználók azt hiszik, hogy a rendszer kevésbé megbízható, mint amilyen valójában.
Megállapodások
A szolgáltatási szint megállapodás egy kifejezett vagy implicit szerződés a felhasználókkal, amely magában foglalja a benne foglalt SLO-k teljesítésének (vagy nem teljesítésének) következményeit. A következményeket akkor lehet legkönnyebben felismerni, ha azok pénzügyiek – engedmény vagy bírság –, de más formákat is ölthetnek. Egy egyszerű módja annak, hogy beszéljünk az SLO-k és az SLA-k közötti különbségről, ha megkérdezzük: „Mi történik, ha az SLO-k nem teljesülnek?” Ha nincsenek egyértelmű következmények, akkor szinte biztos, hogy SLO-t nézel.
Az SRE általában nem vesz részt az SLA-k létrehozásában, mivel az SLA-k szorosan kapcsolódnak az üzleti és termékdöntésekhez. Az SRE azonban részt vesz a sikertelen SLO-k következményeinek enyhítésében. Segíthetnek az SLI meghatározásában is: Nyilvánvaló, hogy a megállapodásban objektív módon kell mérni az SLO-t, különben nézeteltérés lesz.
A Google Kereső egy példa egy fontos szolgáltatásra, amely nem rendelkezik nyilvános SLA-val: szeretnénk, ha mindenki a lehető leghatékonyabban használja a Keresést, de még nem kötöttünk szerződést a világgal. Ha azonban a keresés nem elérhető, akkor is vannak következményei – az elérhetetlenség hírnevünk romlásához és hirdetési bevételeink csökkenéséhez vezet. Sok más Google-szolgáltatás, például a Google for Work, kifejezetten szolgáltatási szintű megállapodást köt a felhasználókkal. Függetlenül attól, hogy egy adott szolgáltatás rendelkezik-e SLA-val, fontos meghatározni az SLI-t és az SLO-t, és ezeket használni a szolgáltatás kezeléséhez.
Ennyi elmélet - most tapasztalat.
Mutatók a gyakorlatban
Tekintettel arra, hogy arra a következtetésre jutottunk, hogy fontos a megfelelő mérőszámok kiválasztása a szolgáltatási szint mérésére, honnan tudja most, hogy melyik mérőszám számít egy szolgáltatás vagy rendszer szempontjából?
Mi érdekli Önt és felhasználóit?
Nem kell minden mérőszámot SLI-ként használnia, amelyet nyomon követhet egy megfigyelő rendszerben; Ha megérti, mit akarnak a felhasználók egy rendszertől, akkor több mérőszámot is kiválaszthat. Ha túl sok mutatót választ, megnehezíti a fontos mutatókra való összpontosítást, míg kis szám kiválasztása a rendszer nagy darabjait felügyelet nélkül hagyhatja. Általában több kulcsmutatót használunk a rendszer állapotának értékelésére és megértésére.
A szolgáltatások az SLI szempontjából általában több részre bonthatók, amelyek relevánsak:
- Egyedi front-end rendszerek, mint például a példánkból a Shakespeare szolgáltatás keresési felületei. Elérhetőnek kell lenniük, nem kell késleltetésük, és elegendő sávszélességgel kell rendelkezniük. Ennek megfelelően kérdéseket lehet feltenni: tudunk-e válaszolni a megkeresésre? Mennyi ideig tartott válaszolni a kérésre? Hány kérelmet lehet feldolgozni?
- Tárolórendszerek. Nagyra értékelik az alacsony válaszidőt, a rendelkezésre állást és a tartósságot. Kapcsolódó kérdések: Mennyi ideig tart az adatok olvasása vagy írása? Kérésre hozzáférhetünk az adatokhoz? Rendelkezésre állnak az adatok, amikor szükségünk van rá? A kérdések részletes megvitatásához lásd a 26. fejezetet: Adatok integritása: amit olvas, azt ír, amit ír.
- A nagy adatrendszerek, például az adatfeldolgozási folyamatok az átviteli sebességre és a lekérdezésfeldolgozási késleltetésre támaszkodnak. Kapcsolódó kérdések: Mennyi adatot dolgoznak fel? Mennyi időbe telik, amíg az adatok eljutnak a kérelem beérkezésétől a válaszadásig? (A rendszer egyes részein bizonyos szakaszokban késések is előfordulhatnak.)
Mutatók gyűjteménye
Sok szolgáltatási szint mutatót a legtermészetesebben a szerver oldalon gyűjtenek össze egy olyan megfigyelő rendszer segítségével, mint a Borgmon (lásd alább). ) vagy Prometheus, vagy egyszerűen csak időszakosan elemzi a naplókat, azonosítja az 500-as állapotú HTTP-válaszokat. Néhány rendszert azonban fel kell szerelni kliensoldali mérőszámok gyűjtésével, mivel a kliensoldali felügyelet hiánya számos olyan probléma hiányához vezethet, amelyek hatással vannak. felhasználók számára, de nem befolyásolják a szerveroldali mérőszámokat. Például, ha a Shakespeare keresőtesztalkalmazásunk backend válaszidejére fókuszálunk, akkor JavaScript-problémák miatt késést okozhat a felhasználói oldalon: ebben az esetben annak mérése, hogy a böngésző mennyi ideig tart az oldal feldolgozása, jobb mérőszám.
Összevonás
Az egyszerűség és a könnyebb használat érdekében gyakran összesítjük a nyers méréseket. Ezt óvatosan kell megtenni.
Egyes mérőszámok egyszerűnek tűnnek, például a kérések másodpercenként, de még ez a látszólag egyszerű mérés is implicit módon összesíti az adatokat az idő múlásával. Kifejezetten másodpercenként egyszer érkezik a mérés, vagy a mérést a percenkénti kérések száma alapján átlagolják? Az utóbbi lehetőség sokkal nagyobb pillanatnyi kéréseket rejthet el, amelyek csak néhány másodpercig tartanak. Tekintsünk egy olyan rendszert, amely másodpercenként 200 kérést szolgál ki páros számokkal, a fennmaradó időben pedig 0-t. A másodpercenkénti 100 kérés átlagos értéke és a pillanatnyi terhelés kétszerese nem ugyanaz. Hasonlóképpen vonzónak tűnhet a lekérdezési késések átlagolása is, de egy fontos részletet rejt magában: lehetséges, hogy a legtöbb lekérdezés gyors lesz, de sok lesz a lassú lekérdezés is.
A legtöbb mutatót inkább eloszlásnak kell tekinteni, mint átlagnak. Például az SLI késleltetése esetén egyes kérések gyorsan feldolgozásra kerülnek, míg mások mindig tovább tart, néha sokkal tovább. Egy egyszerű átlag elrejti ezeket a hosszú késéseket. Az ábra egy példát mutat: bár egy tipikus kérés kiszolgálása körülbelül 50 ms-t vesz igénybe, a kérések 5%-a 20-szor lassabb! A csak átlagos késleltetésen alapuló figyelés és riasztás nem mutat változást a viselkedésben a nap folyamán, holott egyes kérések feldolgozási idejében (legfelső sor) vannak észrevehető változások.
50, 85, 95 és 99 százalékos rendszerkésleltetés. Az Y tengely logaritmikus formátumú.
A százalékos indikátorok használata lehetővé teszi az eloszlás alakjának és jellemzőinek megtekintését: a magas percentilis szint, például 99 vagy 99,9 mutatja a legrosszabb értéket, míg az 50 százalékos (más néven medián) a leggyakrabban előforduló állapotot mutatja. a mérőszám. Minél nagyobb a válaszidő-szóródás, a hosszan futó kérések annál inkább befolyásolják a felhasználói élményt. A hatás fokozódik nagy terhelés mellett és sorok jelenlétében. A felhasználói tapasztalattal kapcsolatos kutatások kimutatták, hogy az emberek általában a lassabb rendszert részesítik előnyben, nagy válaszidő-szórással, ezért egyes SRE-csapatok csak a magas percentilis pontszámokra koncentrálnak, abból a feltételezésből, hogy ha egy mérőszám viselkedése a 99,9 százalékosnál jó, akkor a legtöbb felhasználó nem tapasztal problémát. .
Megjegyzés a statisztikai hibákhoz
Általában szívesebben dolgozunk százalékokkal, mint egy értékkészlet átlagával (számtani középértékével). Ez lehetővé teszi, hogy szórtabb értékeket vegyünk figyelembe, amelyek gyakran lényegesen eltérő (és érdekesebb) jellemzőkkel rendelkeznek az átlagtól. A számítástechnikai rendszerek mesterséges természete miatt a metrikus értékek gyakran torzulnak, például egy kérés sem kap választ 0 ms-nál rövidebb időn belül, és az 1000 ms-os időtúllépés azt jelenti, hogy nem lehet sikeres válaszokat nagyobb értékkel. mint az időtúllépés. Ebből kifolyólag nem tudjuk elfogadni, hogy az átlag és a medián megegyezzen vagy közel álljon egymáshoz!
Előzetes tesztelés nélkül, és hacsak bizonyos szabványos feltételezések és közelítések nem állnak fenn, ügyelünk arra, hogy ne következtessünk arra, hogy adataink normális eloszlásúak. Ha a terjesztés nem a várt módon történik, akkor a problémát kijavító automatizálási folyamat (például ha kiugró értékeket lát, újraindítja a szervert magas kérésfeldolgozási késleltetéssel) túl gyakran vagy nem elég gyakran csinálja ezt (mindkettő nem nagyon jó).
A mutatók szabványosítása
Javasoljuk, hogy szabványosítsa az SLI általános jellemzőit, hogy ne kelljen minden alkalommal találgatnia róluk. Minden olyan szolgáltatás, amely megfelel a szabványos mintáknak, kizárható az egyes SLI specifikációiból, például:
- Összesítési időközök: „átlagosan több mint 1 perc”
- Összesítési területek: „Minden feladat a fürtben”
- A mérések gyakorisága: „10 másodpercenként”
- Milyen kérések vannak engedélyezve: "HTTP GET from black box monitoring jobs"
- Az adatok beszerzésének módja: "A szerveren mért monitorozásunknak köszönhetően"
- Adathozzáférési késleltetés: „Az utolsó bájtig eltelt idő”
Az erőfeszítések megtakarítása érdekében hozzon létre újrafelhasználható SLI-sablonokat minden egyes általános mérőszámhoz; azt is megkönnyítik, hogy mindenki megértse, mit jelent egy bizonyos SLI.
Célok a gyakorlatban
Kezdje azzal, hogy azon gondolkodjon (vagy derítse ki!), hogy mi érdekli a felhasználókat, nem pedig azt, hogy mit mérhet. Gyakran nehéz vagy lehetetlen felmérni, hogy mi érdekli a felhasználókat, így végül közelebb kerül az igényeikhez. Ha azonban csak azzal kezdi, ami könnyen mérhető, akkor kevésbé hasznos SLO-kat fog kapni. Ennek eredményeként néha azt tapasztaltuk, hogy a kívánt célok kezdetben meghatározása, majd konkrét mutatókkal való munka jobban működik, mint az indikátorok kiválasztása, majd a célok elérése.
Határozza meg a célokat
A maximális átláthatóság érdekében meg kell határozni, hogyan mérik az SLO-kat, és milyen feltételek mellett érvényesek. Például a következőket mondhatjuk (a második sor megegyezik az elsővel, de az SLI alapértékeit használja):
- A Get RPC-hívások 99%-a (átlagosan több mint 1 perc) 100 ms-nál rövidebb idő alatt fejeződik be (az összes háttérkiszolgálón mérve).
- A Get RPC-hívások 99%-a kevesebb, mint 100 ms alatt befejeződik.
Ha a teljesítménygörbék alakja fontos, több SLO-t is megadhat:
- A Get RPC-hívások 90%-a kevesebb, mint 1 ms alatt befejeződik.
- A Get RPC-hívások 99%-a kevesebb, mint 10 ms alatt befejeződik.
- A Get RPC-hívások 99.9%-a kevesebb, mint 100 ms alatt befejeződik.
Ha a felhasználók heterogén munkaterheléseket generálnak: tömeges feldolgozást (amelyhez fontos az átviteli sebesség) és interaktív feldolgozást (amelyhez a késleltetés fontos), érdemes lehet külön célokat meghatározni minden egyes terhelési osztályhoz:
- Az ügyfelek kérésének 95%-a átviteli sebességet igényel. Állítsa be a végrehajtott RPC-hívások számát 1 s alatt.
- Az ügyfelek 99%-át érdekli a késleltetés. Állítsa be az 1 KB-nál kisebb forgalmú és 10 ms-nál kisebb RPC-hívások számát.
Irreális és nem kívánatos ragaszkodni ahhoz, hogy az SLO-k az esetek 100%-ában teljesüljenek: ez csökkentheti az új funkciók bevezetésének és telepítésének ütemét, és költséges megoldásokat igényel. Ehelyett jobb, ha engedélyez egy hibaköltséget – a rendszerleállás megengedett százalékát –, és ezt az értéket naponta vagy hetente figyeli. A felső vezetés havi vagy negyedéves értékelést kérhet. (A hibaköltségvetés egyszerűen SLO egy másik SLO-val való összehasonlításhoz.)
Az SLO-sértések százalékos aránya a hibaköltségvetéshez hasonlítható (lásd a 3. fejezetet és a részt ), a különbség értékével az új kiadások telepítésének időpontját meghatározó folyamat bemeneteként.
Célértékek kiválasztása
A tervezési értékek (SLO-k) kiválasztása nem pusztán technikai tevékenység a termék és az üzleti érdekek miatt, amelyeknek tükröződniük kell a kiválasztott SLI-kben, SLO-kban (és esetleg SLA-kban). Hasonlóképpen információcserére is szükség lehet a személyzettel, a piacra jutási idővel, a berendezések elérhetőségével és a finanszírozással kapcsolatos kérdésekről. Az SRE-nek részt kell vennie ebben a beszélgetésben, és segítenie kell megérteni a különböző lehetőségek kockázatait és életképességét. Feltettünk néhány kérdést, amelyek segíthetnek a produktívabb beszélgetésben:
Ne az aktuális teljesítmény alapján válasszon célt.
Bár fontos megérteni a rendszer erősségeit és korlátait, a mérőszámok érvelés nélküli adaptálása megakadályozhatja a rendszer fenntartását: hősies erőfeszítésekre lesz szükség olyan célok eléréséhez, amelyeket jelentős átalakítás nélkül nem lehet elérni.
Legyen egyszerű
Az összetett SLI-számítások elrejthetik a rendszer teljesítményében bekövetkezett változásokat, és megnehezíthetik a probléma okának megtalálását.
Kerülje az abszolútumokat
Bár csábító egy olyan rendszer, amely a késleltetés növelése nélkül képes kezelni a végtelenségig növekvő terhelést, ez a követelmény irreális. Az ilyen ideálokhoz közelítő rendszer valószínűleg sok időt vesz igénybe a tervezéshez és a felépítéshez, költséges lesz az üzemeltetése, és túlságosan megfelel azoknak a felhasználóknak, akik bármivel is megtennék.
Használjon minél kevesebb SLO-t
Válasszon elegendő számú SLO-t a rendszerattribútumok megfelelő lefedettségének biztosításához. Védje meg a választott SLO-kat: Ha soha nem nyerhet meg egy vitát a prioritásokról egy adott SLO megadásával, akkor valószínűleg nem érdemes ezt az SLO-t figyelembe venni. Azonban nem minden rendszerattribútum alkalmazható SLO-kra: nehéz kiszámítani a felhasználó örömének szintjét az SLO-k segítségével.
Ne hajszold a tökéletességet
Idővel bármikor finomíthatja az SLO-k definícióit és céljait, ahogy többet megtud a rendszer terhelés alatti viselkedéséről. Jobb egy lebegő céllal kezdeni, amelyet idővel finomítasz, mint egy túl szigorú célt választani, amelyet lazítani kell, ha elérhetetlennek találod.
Az SLO-k kulcsfontosságú hajtóerők lehetnek és kell is lenniük az SRE-k és a termékfejlesztők munkájának fontossági sorrendjében, mert a felhasználók aggodalmát tükrözik. A jó SLO hasznos végrehajtási eszköz a fejlesztőcsapat számára. De egy rosszul megtervezett SLO pazarló munkához vezethet, ha a csapat hősies erőfeszítéseket tesz egy túl agresszív SLO elérése érdekében, vagy rossz termék, ha az SLO túl alacsony. Az SLO egy erős kar, használja okosan.
Irányítsd a méréseidet
Az SLI és az SLO a rendszerek kezelésének kulcselemei:
- SLI rendszerek figyelése és mérése.
- Hasonlítsa össze az SLI-t az SLO-val, és döntse el, hogy szükség van-e intézkedésre.
- Ha cselekvésre van szükség, találja ki, minek kell történnie a cél eléréséhez.
- Hajtsa végre ezt a műveletet.
Például, ha a 2. lépés azt mutatja, hogy a kérés időkorlátja van, és néhány órán belül megszakítja az SLO-t, ha nem történik semmi, a 3. lépés magában foglalhatja annak a hipotézisnek a tesztelését, hogy a kiszolgálók CPU-hoz vannak kötve, és további kiszolgálók hozzáadása elosztja a terhelést. SLO nélkül nem tudná, hogy kell-e (vagy mikor) tegyen lépéseket.
SLO beállítása – ekkor a felhasználói elvárások beállnak
Az SLO közzététele meghatározza a felhasználók elvárásait a rendszer viselkedésével kapcsolatban. A felhasználók (és a potenciális felhasználók) gyakran szeretnék tudni, mit várnak el egy szolgáltatástól, hogy megértsék, alkalmas-e a használatra. Például azok, akik fényképmegosztó webhelyet szeretnének használni, érdemes elkerülniük a hosszú élettartamot és alacsony költséget ígérő szolgáltatást, cserébe valamivel kevesebb elérhetőségért, még akkor is, ha ugyanaz a szolgáltatás ideális lehet egy archív iratkezelő rendszer számára.
Ha reális elvárásokat szeretne felállítani a felhasználókkal szemben, használja az alábbi taktikák egyikét vagy mindkettőt:
- Tartson fenn egy biztonsági határt. Használjon szigorúbb belső SLO-t, mint amit a felhasználóknak hirdetnek. Ez lehetőséget ad arra, hogy reagáljon a problémákra, mielőtt azok kívülről láthatóvá válnának. Az SLO puffer azt is lehetővé teszi, hogy biztonsági ráhagyással rendelkezzen olyan kiadások telepítésekor, amelyek befolyásolják a rendszer teljesítményét, és biztosítják, hogy a rendszer könnyen karbantartható legyen anélkül, hogy a felhasználókat leállással kelljen frusztrálnia.
- Ne lépje túl a felhasználói elvárásokat. A felhasználók az Ön által kínált dolgokon alapulnak, nem pedig azon, amit mond. Ha a szolgáltatás tényleges teljesítménye sokkal jobb, mint a megadott SLO, a felhasználók az aktuális teljesítményre hagyatkoznak. A túlzott függőséget elkerülheti a rendszer szándékos leállításával vagy a teljesítmény korlátozásával kis terhelés mellett.
Annak megértése, hogy egy rendszer mennyire felel meg az elvárásoknak, segít eldönteni, hogy érdemes-e beruházni a rendszer felgyorsításába, elérhetőbbé és rugalmasabbá tételébe. Alternatív megoldásként, ha egy szolgáltatás túl jól teljesít, a személyzet egy részét más prioritásokra kell fordítani, mint például a műszaki adósság törlesztésére, új funkciók hozzáadására vagy új termékek bevezetésére.
Megállapodások a gyakorlatban
Az SLA létrehozásához az üzleti és jogi csapatoknak meg kell határozniuk a megszegés következményeit és szankcióit. Az SRE szerepe az, hogy segítsen nekik megérteni az SLA-ban foglalt SLO-k teljesítése során várható kihívásokat. Az SLO-k létrehozására vonatkozó javaslatok többsége az SLA-kra is vonatkozik. Bölcs dolog konzervatívnak lenni abban, amit a felhasználóknak ígér, mert minél több van, annál nehezebb megváltoztatni vagy eltávolítani az ésszerűtlennek vagy nehezen teljesíthetőnek tűnő SLA-kat.
Köszönöm, hogy végig olvastad a fordítást. Iratkozz fel a távirati csatornámra a megfigyelésről и .
Forrás: will.com