SRE (Site Reliability Engineering) yra būdas padaryti žiniatinklio projektus prieinamus. Tai laikoma „DevOps“ sistema ir nurodo, kaip sėkmingai taikyti „DevOps“ praktiką. Šis straipsnis verčiamas knygos iš Google. Šį vertimą rengiau pati ir, suprasdama stebėjimo procesus, rėmiausi savo patirtimi. Telegramos kanale и Taip pat paskelbiau nuorodą į tos pačios knygos apie paslaugų lygio tikslus 4 skyriaus vertimą.
Katės vertimas. Mėgaukitės skaitymu!
„Google“ SRE komandos turi pagrindinius sėkmingos stebėjimo ir pranešimų sistemų kūrimo principus ir geriausią praktiką. Šiame skyriuje pateikiamos rekomendacijos, su kokiomis problemomis gali susidurti tinklalapio lankytojas ir kaip išspręsti problemas, dėl kurių sunku rodyti tinklalapius.
Apibrėžimai
Nėra vieno žodyno, naudojamo aptarti su stebėjimu susijusias temas. Netgi „Google“ toliau pateikiami terminai nėra plačiai naudojami, tačiau išvardinsime dažniausiai pasitaikančias interpretacijas.
Stebėjimas
Realaus laiko kiekybinių duomenų apie sistemą rinkimas, apdorojimas, kaupimas ir atvaizdavimas: užklausų skaičius ir užklausų tipai, klaidų skaičius ir jų tipai, užklausų apdorojimo laikas ir serverio veikimo laikas.
Baltos dėžės stebėjimas
Stebėjimas, pagrįstas sistemos vidinių elementų rodoma metrika, įskaitant žurnalus, JVM arba HTTP tvarkyklės profiliavimo metriką, kuri generuoja vidinę statistiką.
Juodosios dėžės stebėjimas
Programos veikimo patikrinimas vartotojo požiūriu.
Prietaisų skydelis (prietaisų skydeliai)
Sąsaja (dažniausiai žiniatinklio sąsaja), kurioje pateikiama pagrindinių paslaugų sveikatos rodiklių apžvalga. Prietaisų skydelyje gali būti filtrai, galimybė pasirinkti, kurią metriką rodyti ir tt Sąsaja sukurta taip, kad identifikuotų vartotojams svarbiausias metrikas. Prietaisų skydelyje taip pat gali būti rodoma informacija techninės pagalbos personalui: užklausų eilė, didelio prioriteto klaidų sąrašas, priskirtas inžinierius tam tikrai atsakomybės sričiai.
Įspėjimas (pranešimas)
Pranešimai, skirti asmeniui gauti elektroniniu paštu ar kitu būdu, kurie gali suveikti dėl klaidų ar užklausų eilės padidėjimo. Pranešimai skirstomi į šias kategorijas: bilietai, įspėjimai el. paštu ir žinutės.
Pagrindinė priežastis (pagrindinė priežastis)
Programinės įrangos defektas arba žmogiškoji klaida, kuri, ištaisius, neturėtų pasikartoti. Problema gali turėti keletą pagrindinių priežasčių: nepakankamas procesų automatizavimas, programinės įrangos defektas, nepakankamas programų logikos tyrimas. Kiekvienas iš šių veiksnių gali būti pagrindinė priežastis, ir kiekvienas iš jų turi būti pašalintas.
Mazgas ir mašina (mazgas ir mašina)
Keičiami terminai, nurodantys vieną fiziniame serveryje, virtualioje mašinoje ar konteineryje veikiančios programos egzempliorių. Viename įrenginyje gali būti kelios paslaugos. Paslaugos gali būti:
- susiję vienas su kitu: pavyzdžiui, talpyklos serveris ir žiniatinklio serveris;
- nesusijusios paslaugos toje pačioje aparatinėje įrangoje: pavyzdžiui, kodų saugykla ir konfigūracijos sistemos vedlys, pvz. arba .
Stumti
Bet koks programinės įrangos konfigūracijos pakeitimas.
Kodėl reikalingas stebėjimas
Yra keletas priežasčių, kodėl reikia stebėti programas:
Ilgalaikių tendencijų analizė
Kokio dydžio yra duomenų bazė ir kaip greitai ji auga? Kaip keičiasi kasdienis vartotojų skaičius?
Našumo palyginimas
Ar Acme Bucket of Bytes 2.72 užklausos yra greitesnės nei Ajax DB 3.14? Kiek geriau užklausos saugomos talpykloje atsiradus papildomam mazgui? Ar svetainė tapo lėtesnė nei praėjusią savaitę?
Įspėjimas (pranešimai)
Kažkas sugedo ir kažkas turi tai sutvarkyti. Arba greitai kažkas suges ir greitai kažkas turės tai patikrinti.
Prietaisų skydelių kūrimas
Prietaisų skydeliai turėtų atsakyti į pagrindinius klausimus ir įtraukti ką nors iš - vėlavimai (latencija), srautas (eismas), klaidos (klaidos) ir apkrovos vertė (sotumas).
Retrospektyvinės analizės (derinimo) atlikimas
Užklausos apdorojimo delsa padidėjo, kas dar nutiko maždaug tuo pačiu metu?
Stebėjimo sistemos yra naudingos kaip verslo žvalgybos sistemų duomenų šaltinis ir palengvina saugumo incidentų analizę. Kadangi šioje knygoje pagrindinis dėmesys skiriamas inžinerinėms sritims, kuriose SRE turi patirties, stebėjimo metodų čia nenagrinėsime.
Stebėjimas ir įspėjimai leidžia sistemai pasakyti, kada ji sugedo arba netrukus suges. Kai sistema negali automatiškai pasitaisyti, norime, kad žmogus analizuotų įspėjimą, nustatytų, ar problema vis dar egzistuoja, ją išspręstų ir pagrindinę priežastį. Jei neatliksite sistemos komponentų audito, niekada negausite įspėjimo vien dėl to, kad „kažkas atrodo šiek tiek keista“.
Žmonių įspėjimų įkėlimas yra gana brangus darbuotojo laiko panaudojimas. Jei darbuotojas dirba, perspėjimas nutraukia darbo eigą. Jei darbuotojas yra namuose, perspėjimas nutraukia asmeninį laiką ir galbūt miegą. Kai įspėjimai atsiranda per dažnai, darbuotojai nuskaito, delsia arba ignoruoja gaunamus įspėjimus. Kartkartėmis jie nepaiso tikrojo perspėjimo, kurį užmaskuoja triukšmo įvykiai. Paslaugos trikdžiai gali trukti ilgai, nes triukšmo įvykiai neleidžia greitai diagnozuoti ir išspręsti problemos. Veiksmingos viešojo informavimo sistemos turi gerą signalo ir triukšmo santykį.
Pagrįstų lūkesčių iš stebėjimo sistemos nustatymas
Sudėtingos programos stebėjimo nustatymas yra sudėtinga inžinerinė užduotis. Net ir turint didelę rinkimo, rodymo ir įspėjimo įrankių infrastruktūrą, 10–12 narių „Google SRE“ komandą paprastai sudaro vienas ar du žmonės, kurių pagrindinis tikslas yra kurti ir prižiūrėti stebėjimo sistemas. Šis skaičius laikui bėgant sumažėjo, kai apibendriname ir centralizuojame stebėjimo infrastruktūrą, tačiau kiekvienoje SRE komandoje paprastai yra bent vienas tik stebėjimo darbuotojas. Reikia pasakyti, kad nors stebėti stebėjimo sistemos prietaisų skydelius yra gana įdomu, SRE komandos atsargiai vengia situacijų, kai norint stebėti problemas reikia žiūrėti į ekraną.
Apskritai, „Google“ perėjo prie paprastų ir greitų stebėjimo sistemų su optimaliais po-faktų analizės įrankiais. Vengiame „stebuklingų“ sistemų, kurios bando numatyti slenksčius arba automatiškai atrasti pagrindinę priežastį. Vienintelis priešingas pavyzdys yra jutikliai, aptinkantys nenumatytą turinį galutinio vartotojo užklausose; Kol šie jutikliai išlieka paprasti, jie gali greitai nustatyti rimtų anomalijų priežastis. Kiti stebėjimo duomenų naudojimo formatai, tokie kaip pajėgumų planavimas ar eismo prognozavimas, yra sudėtingesni. Stebėjimas labai ilgą laiką (mėnesius ar metus) esant mažam atrankos dažniui (valandomis ar dienomis) parodys ilgalaikę tendenciją.
„Google“ SRE komanda įvairiai sėkmingai dirbo su sudėtingomis priklausomybės hierarchijomis. Retai naudojame tokias taisykles kaip „jei sužinau, kad duomenų bazė sulėtėjo, gaunu įspėjimą apie duomenų bazės sulėtėjimą, kitu atveju gaunu įspėjimą apie lėtą svetainę“. Priklausomybe pagrįstos taisyklės paprastai nurodo nesikeičiančias mūsų sistemos dalis, pvz., vartotojų srauto į duomenų centrą filtravimo sistemą. Pavyzdžiui, „jei duomenų centro srauto filtravimas sukonfigūruotas, neperspėti manęs apie delsą apdoroti vartotojų užklausas“ yra viena dažna duomenų centro įspėjimų taisyklė. Nedaug „Google“ komandų palaiko sudėtingas priklausomybės hierarchijas, nes mūsų infrastruktūroje yra pastovus nuolatinio pertvarkymo greitis.
Kai kurios šiame skyriuje išdėstytos idėjos vis dar galioja: visada yra būdas greičiau pereiti nuo simptomo iki pagrindinės priežasties, ypač nuolat besikeičiančiose sistemose. Todėl, nors šiame skyriuje aprašomi kai kurie stebėjimo sistemų tikslai ir kaip tuos tikslus pasiekti, svarbu, kad stebėjimo sistemos būtų paprastos ir suprantamos kiekvienam komandos nariui.
Taip pat, norint išlaikyti žemą triukšmo lygį ir aukštą signalo lygį, perspėjamų objektų stebėjimo metodai turi būti labai paprasti ir patikimi. Taisyklės, kurios įspėja žmones, turėtų būti lengvai suprantamos ir reikšti aiškią problemą.
Simptomai prieš priežastis
Jūsų stebėjimo sistema turėtų atsakyti į du klausimus: „kas sugedo“ ir „kodėl sugedo“.
„Kas sugedo“ reiškia simptomą, o „kodėl sugedo“ – priežastį. Žemiau esančioje lentelėje pateikiami tokių nuorodų pavyzdžiai.
Simptomas
Sukelti
Gaunama HTTP klaida 500 arba 404
Duomenų bazių serveriai atsisako užmegzti ryšius
Lėti serverio atsakymai
Didelis procesoriaus naudojimas arba pažeistas eterneto kabelis
Antarktidoje gyvenantys vartotojai negauna kačių GIF
Jūsų CDN nekenčia mokslininkų ir kačių, todėl kai kurie IP yra įtraukti į juodąjį sąrašą
Privatus turinys pasiekiamas visur
Išleidus naują programinės įrangos leidimą, ugniasienė pamiršo visus ACL ir įleido visus
„Kas“ ir „kodėl“ yra vienas iš svarbiausių elementų kuriant gerą stebėjimo sistemą su maksimaliu signalu ir minimaliu triukšmu.
Black-box vs White-box
Mes deriname platų baltos dėžės stebėjimą su kukliu juodosios dėžės stebėjimu, skirtu kritinėms metrikoms. Lengviausias būdas palyginti „Blackbox“ su „White-box“ yra tas, kad „Black-box“ yra orientuotas į simptomus ir yra reaktyvus, o ne aktyvus stebėjimas: „sistema šiuo metu neveikia tinkamai“. White-box priklauso nuo vidinių sistemų tikrinimo galimybių: įvykių žurnalų ar žiniatinklio serverių. Taigi „White-box“ leidžia aptikti artėjančias problemas, gedimus, kurie atrodo kaip užklausos pakartotinis siuntimas ir pan.
Atkreipkite dėmesį, kad daugiasluoksnėje sistemoje simptomas vieno inžinieriaus atsakomybės srityje yra simptomas kito inžinieriaus atsakomybės srityje. Pavyzdžiui, sumažėjo duomenų bazės našumas. Lėtas duomenų bazės nuskaitymas yra duomenų bazės SRE, kuri juos aptinka, simptomas. Tačiau priekiniam SRE, žiūrinčiam lėtą svetainę, tos pačios lėtos duomenų bazės skaitymo priežastis yra ta, kad duomenų bazė yra lėta. Todėl baltos dėžės stebėjimas kartais yra sutelktas į simptomus, o kartais į priežastis, atsižvelgiant į tai, koks jis yra.
Renkant telemetriją derinimui, reikalingas White-box stebėjimas. Jei žiniatinklio serveriai lėtai reaguoja į duomenų bazės užklausas, turite žinoti, kaip greitai žiniatinklio serveris bendrauja su duomenų baze ir kaip greitai jis reaguoja. Priešingu atveju negalėsite atskirti lėto duomenų bazės serverio ir tinklo problemos tarp žiniatinklio serverio ir duomenų bazės.
Juodosios dėžės stebėjimas turi pagrindinį pranašumą siunčiant įspėjimus: suaktyvinate pranešimą gavėjui, kai problema jau sukėlė tikrus simptomus. Kita vertus, dar neiškilusiai, bet artėjančiai Black-box problemai stebėjimas yra nenaudingas.
Keturi auksiniai signalai
Keturi auksiniai stebėjimo signalai yra delsa, srautas, klaidos ir prisotinimas. Jei galite išmatuoti tik keturias vartotojų sistemos metrikas, sutelkite dėmesį į šias keturias.
Atidėti
Laikas, reikalingas prašymui apdoroti. Svarbu atskirti sėkmingų ir nesėkmingų užklausų delsą. Pavyzdžiui, HTTP 500 klaida, kurią sukelia nutrūkęs ryšys su duomenų baze ar kita vidine sistema, gali būti diagnozuojama labai greitai, tačiau HTTP 500 klaida gali reikšti, kad užklausa nepavyko. Nustačius 500 klaidos poveikį bendrai delsai, gali būti padarytos klaidingos išvados. Kita vertus, lėta klaida yra netgi greita klaida! Todėl svarbu stebėti klaidų delsą, o ne tik filtruoti klaidas.
eismas
Jūsų sistemai pateiktų užklausų skaičius, matuojamas aukšto lygio sistemos metrika. Naudojant žiniatinklio paslaugą, šis matavimas paprastai parodo HTTP užklausų per sekundę skaičių, padalijus iš užklausų pobūdžio (pavyzdžiui, statinio ar dinaminio turinio). Garso srautinio perdavimo sistemoje šis matavimas gali būti sutelktas į tinklo I/O spartą arba vienu metu vykstančių seansų skaičių. Raktų vertės saugojimo sistemoje šis matavimas gali būti operacijos arba peržvalgos per sekundę.
Klaidos
Tai yra nepavykusių užklausų, tiesiogiai (pavyzdžiui, HTTP 500), netiesioginių (pvz., HTTP 200, bet kartu su netinkamu turiniu) arba politikos (pvz., „Jei atsakymą užfiksuosite per vieną sekundę, bet koks viena sekundė yra klaida“). Jei nėra pakankamai HTTP atsako kodų visoms gedimo sąlygoms išreikšti, daliniam gedimui aptikti gali prireikti antrinių (vidinių) protokolų. Visų tokių klaidingų užklausų stebėjimas gali būti neinformatyvus, o visapusiški sistemos testai gali padėti nustatyti, kad apdorojate netinkamą turinį.
Sodrumas
Metrika parodo, kaip intensyviai naudojama jūsų paslauga. Tai sistemos stebėjimo priemonė, identifikuojanti labiausiai ribotus išteklius (pavyzdžiui, sistemoje su ribota atmintimi rodo atmintį, sistemoje su ribotu I/O – rodo I/O skaičių). Atminkite, kad daugelis sistemų susilpnėja nepasiekdamos 100 % naudojimo, todėl būtina turėti naudojimo tikslą.
Sudėtingose sistemose prisotinimas gali būti papildytas aukštesnio lygio apkrovos matavimu: ar jūsų paslauga gali tinkamai valdyti dvigubą srautą, apdoroti tik 10 % daugiau srauto ar net mažiau srauto, nei gali šiuo metu? Paprastoms paslaugoms, kurios neturi parametrų, keičiančių užklausos sudėtingumą (pvz., „Nieko neduokite“ arba „Man reikia unikalaus vieno monotoniško sveikojo skaičiaus“), kurios retai keičia konfigūraciją, gali pakakti statinės apkrovos testo vertės. kaip aptarta ankstesnėje pastraipoje, dauguma paslaugų turėtų naudoti netiesioginius signalus, tokius kaip procesoriaus panaudojimas arba tinklo pralaidumas, kurių viršutinė riba yra žinoma. Didėjantis delsos laikas dažnai yra pagrindinis prisotinimo rodiklis. Išmatavus 99-osios procentilės atsako laiką mažame lange (pvz., vieną minutę), galima gauti labai ankstyvą prisotinimo signalą.
Galiausiai, prisotinimas taip pat siejamas su artėjančio prisotinimo prognozėmis, pvz.: „Panašu, kad jūsų duomenų bazė užpildys standųjį diską per 4 valandas“.
Jei išmatuosite visus keturis auksinius signalus ir iškilus problemai su viena iš metrikų (arba, esant prisotinimui, beveik problema), pranešate asmeniui, jūsų paslauga bus daugiau ar mažiau stebima.
Nerimas dėl uodegos (arba instrumentų ir našumo)
Kuriant stebėjimo sistemą nuo nulio, kyla pagunda sukurti sistemą, pagrįstą vidurkiais: vidutiniu delsos laiku, vidutiniu mazgo procesoriaus panaudojimu arba vidutiniu duomenų bazės užimtumu. Paskutinių dviejų pavyzdžių pavojus akivaizdus: procesoriai ir duomenų bazės sunaikinamos labai nenuspėjamai. Tas pats pasakytina ir apie vėlavimą. Jei naudojate žiniatinklio paslaugą, kurios vidutinė delsa yra 100 ms ir 1000 1 užklausų per sekundę, 5 % užklausų gali užtrukti 99 sekundes. Jei vartotojai priklauso nuo kelių tokių žiniatinklio paslaugų, vienos užpakalinės sistemos XNUMX procentilis gali lengvai tapti sąsajos atsako laiko mediana.
Paprasčiausias būdas atskirti lėtą užklausų vidurkį ir labai lėtą užklausų uodegą – rinkti užklausų, išreikštų statistikoje, matavimus (histogramos yra tinkama priemonė rodyti), o ne faktinius vėlavimus: kiek užklausų aptarnavo tarnyba, kuri paėmė. nuo 0 ms iki 10 ms, nuo 10 ms iki 30 ms, nuo 30 ms iki 100 ms, nuo 100 ms iki 300 ms ir tt Histogramos ribų išplėtimas maždaug eksponentiškai (apie 3 kartus) dažnai yra paprastas būdas vizualizuoti užklausų pasiskirstymą.
Tinkamo matavimų detalumo pasirinkimas
Skirtingi sistemos elementai turėtų būti matuojami skirtingais detalumo lygiais. Pavyzdžiui:
- Stebint procesoriaus panaudojimą per tam tikrą laikotarpį, nebus rodomi ilgi šuoliai, dėl kurių atsiranda didelė delsa.
- Kita vertus, žiniatinklio paslaugai, kuri skirta ne daugiau kaip 9 valandoms prastovos per metus (99,9 % metinio veikimo trukmės), HTTP 200 atsako tikrinimas dažniau nei vieną ar du kartus per minutę tikriausiai būtų be reikalo dažnai.
- Panašiai tikriausiai nereikia tikrinti, ar standžiajame diske yra laisvos vietos, kad jos pasiekiamumas būtų 99,9% daugiau nei kartą per 1–2 minutes.
Atkreipkite dėmesį į tai, kaip struktūrizuojate matmenų detalumą. CPU panaudojimo koeficientas 1 per sekundę gali pateikti įdomių duomenų, tačiau tokie dažni matavimai gali būti labai brangūs rinkti, saugoti ir analizuoti. Jei jūsų stebėjimo tikslas reikalauja didelio detalumo ir nereikalauja didelio reagavimo, galite sumažinti šias išlaidas serveryje nustatydami metrikos rinkimą ir sukonfigūruodami išorinę sistemą, kad ši metrika rinktų ir kauptų. Ar galėtum:
- Kas sekundę matuokite procesoriaus naudojimą.
- Sumažinkite detalumą iki 5%.
- Apibendrinkite metrikas kas minutę.
Ši strategija leis jums rinkti labai detalius duomenis nepatirdami didelių analizės ir saugojimo išlaidų.
Kiek įmanoma paprasčiau, bet ne lengviau
Skirtingų reikalavimų sudėjimas vienas ant kito gali sukelti labai sudėtingą stebėjimo sistemą. Pavyzdžiui, jūsų sistemoje gali būti šie sudėtingi elementai:
- Įspėjimai pagal skirtingus užklausos delsos slenksčius, skirtingais procentiliais, įvairiose skirtingose metrikose.
- Papildomo kodo rašymas galimoms priežastims aptikti ir nustatyti.
- Sukurkite susijusias informacijos suvestines apie kiekvieną galimą problemų priežastį.
Galimų komplikacijų šaltiniai niekada nesibaigia. Kaip ir visos programinės įrangos sistemos, stebėjimas gali tapti toks sudėtingas, kad tampa trapus, sunkiai keičiamas ir prižiūrimas.
Todėl kurkite savo stebėjimo sistemą taip, kad ją būtų kuo labiau supaprastinta. Rinkdamiesi, ką stebėti, atminkite šiuos dalykus:
- Taisyklės, kurios dažniausiai užfiksuoja tikrus incidentus, turėtų būti kuo paprastesnės, nuspėjamos ir patikimesnės.
- Duomenų rinkimo, kaupimo ir įspėjimų konfigūracija, kuri atliekama retai (pvz., kai kurioms SRE komandoms rečiau nei kas ketvirtį), turėtų būti pašalinta.
- Metrika, kuri yra renkama, bet nerodoma jokiame peržiūros skydelyje arba naudojama jokiuose įspėjimuose, gali būti ištrinta.
„Google“ pagrindinis metrikos rinkimas ir kaupimas kartu su įspėjimais ir prietaisų skydeliais puikiai veikia kaip gana savarankiška sistema (iš tikrųjų „Google“ stebėjimo sistema suskirstyta į keletą posistemių, tačiau paprastai žmonės žino visus šių posistemių aspektus). Gali kilti pagunda stebėjimą derinti su kitais sudėtingų sistemų testavimo metodais: detaliu sistemos profiliavimu, procesų derinimu, išimčių ar gedimų detalių sekimu, apkrovos testavimu, žurnalų rinkimu ir analize arba eismo tikrinimu. Nors dauguma šių dalykų turi bendrų bruožų su pagrindine stebėsena, juos sumaišius bus gauta per daug rezultatų ir sukuriama sudėtinga ir trapi sistema. Kaip ir daugelyje kitų programinės įrangos kūrimo aspektų, geriausia strategija yra palaikyti skirtingas sistemas aiškiais, paprastais, laisvai susietais integravimo taškais (pavyzdžiui, naudojant žiniatinklio API, kad būtų galima gauti suvestinės duomenis tokiu formatu, kuris ilgą laiką gali išlikti pastovus. ).
Principų susiejimas kartu
Šiame skyriuje aptariami principai gali būti sujungti į stebėjimo ir įspėjimo filosofiją, kurią palaiko ir laikosi „Google“ SRE komandos. Šios stebėjimo filosofijos laikymasis yra pageidautinas, tai yra geras atspirties taškas kuriant arba peržiūrint įspėjimų metodiką ir gali padėti užduoti teisingus klausimus operacijoms, nepaisant jūsų organizacijos dydžio ar paslaugos ar sistemos sudėtingumo.
Kuriant stebėjimo ir įspėjimo taisykles, užduodami toliau nurodyti klausimai gali padėti išvengti klaidingų teigiamų rezultatų ir nereikalingų įspėjimų:
- Ar ši taisyklė aptinka kitaip neaptinkamą sistemos būseną, kuri yra skubi, raginama veikti ir neišvengiamai veikia vartotoją?
- Ar galiu nepaisyti šio įspėjimo, žinodamas, kad jis gerybinis? Kada ir kodėl galiu nepaisyti šio įspėjimo ir kaip išvengti šio scenarijaus?
- Ar šis įspėjimas reiškia, kad naudotojams daromas neigiamas poveikis? Ar yra situacijų, kai naudotojai nėra neigiamai paveikti, pavyzdžiui, dėl srauto filtravimo arba naudojant bandomąsias sistemas, kurių įspėjimai turėtų būti filtruojami?
- Ar galiu imtis veiksmų reaguodamas į šį įspėjimą? Ar šios priemonės skubios, ar galima palaukti iki ryto? Ar saugu automatizuoti veiksmą? Ar šis veiksmas bus ilgalaikis sprendimas, ar trumpalaikis sprendimas?
- Kai kurie žmonės gauna kelis įspėjimus dėl šios problemos, todėl ar įmanoma sumažinti skaičių?
Šie klausimai atspindi pagrindinę įspėjimų ir įspėjimo sistemų filosofiją:
- Kiekvieną kartą, kai gaunamas įspėjimas, turiu skubiai reaguoti. Galiu skubėti kelis kartus per dieną, kol nepavargsiu.
- Kiekvienas įspėjimas turi būti atnaujintas.
- Kiekvienas atsakas į įspėjimą turi reikalauti žmogaus įsikišimo. Jei pranešimą galima apdoroti automatiškai, jis neturėtų ateiti.
- Įspėjimai turėtų būti apie naują problemą arba įvykį, kuris anksčiau nebuvo įvykęs.
Šis metodas panaikina tam tikrus skirtumus: jei įspėjimas atitinka keturias ankstesnes sąlygas, nesvarbu, ar įspėjimas siunčiamas iš baltosios dėžės stebėjimo sistemos, ar iš juodosios dėžės. Šis požiūris taip pat sustiprina tam tikrus skirtumus: geriau skirti daug daugiau pastangų simptomams, o ne priežastims nustatyti; Kalbant apie priežastis, reikia nerimauti tik dėl neišvengiamų priežasčių.
Ilgalaikis stebėjimas
Šiuolaikinėje gamybos aplinkoje stebėjimo sistemos stebi nuolat besikeičiančią gamybos sistemą su besikeičiančia programinės įrangos architektūra, apkrovos charakteristikomis ir našumo tikslais. Perspėjimai, kuriuos šiuo metu sunku automatizuoti, gali tapti įprasti, galbūt net nusipelno, kad į juos būtų atsižvelgta. Šiuo metu kažkas turi rasti ir pašalinti pagrindines problemos priežastis; jei toks sprendimas neįmanomas, reakcijai į perspėjimą reikia visiškai automatizuoti.
Svarbu, kad priežiūros sprendimai būtų priimami turint omenyje ilgalaikius tikslus. Kiekvienas perspėjimas, kuris veikia šiandien, atitolina asmenį nuo sistemos tobulinimo rytoj, todėl dažnai sumažėja produktyvios sistemos prieinamumas arba našumas tam laikui, kurio reikia stebėjimo sistemai patobulinti ilgainiui. Pažvelkime į du pavyzdžius, iliustruojančius šį reiškinį.
Bigtable SRE: istorija apie perdėtą budrumą
„Google“ vidinė infrastruktūra paprastai teikiama ir vertinama pagal paslaugų lygį (SLO). Prieš daugelį metų „Bigtable“ paslaugos SLO buvo pagrįstas vidutiniu sintetinės operacijos, imituojančios veikiantį klientą, našumu. Dėl „Bigtable“ problemų ir žemesnių saugyklos lygių vidutinį našumą lėmė „didelė“ uodega: 5 % blogiausių užklausų dažnai buvo gerokai lėtesnės nei likusios.
Priartėjus prie SLO slenksčio buvo siunčiami pranešimai el. paštu, o viršijus SLO siunčiami pranešimų siuntėjo įspėjimai. Abiejų tipų įspėjimai buvo siunčiami gana dažnai, o tai užtruko nepriimtinai daug inžinerinio laiko: komanda praleido daug laiko analizuodama įspėjimus, kad surastų kelis iš tikrųjų aktualius. Dažnai praleidome problemą, kuri iš tikrųjų paveikė naudotojus, nes tik keli įspėjimai buvo susiję su ta problema. Daugelis įspėjimų buvo neskubūs dėl suprantamų infrastruktūros problemų ir buvo tvarkomi standartiniu būdu arba iš viso neapdoroti.
Siekdama ištaisyti situaciją, komanda naudojo trijų krypčių metodą: sunkiai dirbdami, kad pagerintume Bigtable našumą, laikinai nustatėme 75 procentilį atsakymo į užklausą delsai kaip SLO tikslą. Taip pat išjungėme įspėjimus el. paštu, nes jų buvo tiek daug, kad buvo neįmanoma gaišti laiko diagnozuojant.
Ši strategija leido mums atsikvėpti ir pradėti taisyti ilgalaikes „Bigtable“ ir apatinių saugyklos sluoksnių problemas, o ne nuolat taisyti taktines problemas. Inžinieriai iš tikrųjų galėjo atlikti darbą, kai nebuvo nuolat bombarduojami įspėjimais. Galiausiai laikinas įspėjimų apdorojimo vėlavimas leido mums pagerinti paslaugų kokybę.
Gmail: Nuspėjami, algoritminiai žmogaus atsakymai
Pačioje pradžioje „Gmail“ buvo sukurta naudojant modifikuotą „Workqueue“ proceso valdymo sistemą, kuri buvo sukurta paketinio proceso paieškos indekso gabalams apdoroti. Darbo eilė buvo pritaikyta ilgai trunkantiems procesams ir vėliau pritaikyta „Gmail“, tačiau kai kurias neskaidraus planavimo priemonės kodo klaidas buvo labai sunku ištaisyti.
Tuo metu „Gmail“ stebėjimas buvo struktūrizuotas taip, kad įspėjimai būtų suaktyvinti, kai atskiros užduotys buvo atšauktos naudojant „Workqueue“. Toks požiūris nebuvo idealus, nes net tuo metu „Gmail“ atliko daugybę tūkstančių užduočių, kurių kiekviena buvo skirta procento mūsų vartotojų daliai. Labai stengėmės užtikrinti, kad „Gmail“ naudotojai turėtų gerą naudotojo patirtį, tačiau negalėjome tvarkyti daugelio įspėjimų.
Kad išspręstų šią problemą, „Gmail SRE“ sukūrė įrankį, padedantį kuo geriau derinti planavimo priemonę, kad būtų sumažintas poveikis vartotojams. Komanda keletą kartų diskutavo apie tai, ar tiesiog automatizuoti visą ciklą nuo problemos suradimo iki jos ištaisymo, kol bus rastas ilgalaikis sprendimas, tačiau kai kurie buvo susirūpinę, kad toks sprendimas užtruks faktinį problemos sprendimą.
Tokia įtampa buvo įprasta komandoje ir dažnai atspindėjo nepasitikėjimą savidisciplina: kai kurie komandos nariai nori skirti laiko tinkamam pataisymui, kiti nerimauja, kad galutinis sprendimas bus pamirštas ir laikinas taisymas užtruks amžinai. Ši problema nusipelno dėmesio, nes per lengva problemas laikinai išspręsti, o ne nuolat taisyti. Vadovai ir techninis personalas atlieka pagrindinį vaidmenį įgyvendinant ilgalaikius pataisymus, palaikydami galimai ilgalaikius ilgalaikius pataisymus ir teikdami jiems pirmenybę net tada, kai pradinis skausmas atslūgsta.
Reguliarūs pasikartojantys įspėjimai ir algoritminės reakcijos turėtų būti raudona vėliavėlė. Jūsų komandos nenoras automatizuoti šiuos įspėjimus reiškia, kad komanda nepasitiki, kad gali pasitikėti algoritmais. Tai rimta problema, kurią reikia spręsti.
Ilgas terminas
Bendra tema sieja „Bigtable“ ir „Gmail“ pavyzdžius: konkurencija tarp trumpalaikio ir ilgalaikio pasiekiamumo. Dažnai stiprios pastangos gali padėti trapiai sistemai pasiekti aukštą prieinamumą, tačiau šis kelias dažniausiai yra trumpalaikis, kupinas komandos perdegimo ir priklausomybės nuo nedidelio skaičiaus tos pačios herojiškos komandos narių.
Kontroliuojamas trumpalaikis prieinamumo sumažėjimas dažnai yra skausmingas, bet strategiškai svarbus ilgalaikiam sistemos stabilumui. Svarbu neatsižvelgti į kiekvieną įspėjimą atskirai, o apsvarstyti, ar bendras įspėjimų dažnis sukuria sveiką, tinkamai prieinamą sistemą su perspektyvia komanda ir palankia prognoze. Ketvirčio ataskaitose kartu su vadovybe analizuojame įspėjimų dažnio statistiką (dažniausiai išreiškiamą incidentais per pamainą, kai incidentą gali sudaryti keli susiję incidentai), todėl sprendimų priėmėjai gali nuolat pateikti įspėjimo sistemos apkrovą ir bendrą komandos būklę.
išvada
Kelias į sveiką stebėjimą ir įspėjimus yra paprastas ir nesudėtingas. Jame dėmesys sutelkiamas į problemos, dėl kurios generuojami įspėjimai, požymius, o priežasties stebėjimas yra pagalba sprendžiant problemas. Simptomų stebėjimas yra lengvesnis, kuo aukščiau esate valdomoje krūvoje, nors duomenų bazės įkėlimas ir našumo stebėjimas turėtų būti atliekami tiesiogiai pačioje duomenų bazėje. El. pašto pranešimų naudojimas yra labai ribotas ir paprastai virsta triukšmu; vietoj to turėtumėte naudoti prietaisų skydelį, kuris stebi visas esamas problemas, apie kurias pranešama el. paštu. Prietaisų skydelis taip pat gali būti susietas su įvykių žurnalu, kad būtų galima analizuoti istorines koreliacijas.
Ilgainiui reikia sėkmingai keisti įspėjimus apie simptomus ir gresiančias tikras problemas, o tikslus pritaikyti taip, kad stebėjimas padėtų greitai diagnozuoti.
Ačiū, kad perskaitėte vertimą iki galo. Prenumeruokite mano telegramos kanalą apie stebėjimą и .
Šaltinis: www.habr.com