SRE (Site Reliability Engineering) on tapa tehdä verkkoprojekteista saavutettavia. Sitä pidetään DevOpsin viitekehyksenä ja se kertoo kuinka onnistua DevOps-käytäntöjen soveltamisessa. Tämä artikkeli käännetään kirjat Googlelta. Tein tämän käännöksen itse ja luotin omaan kokemukseeni seurantaprosessien ymmärtämisessä. Telegram-kanavalla и Lähetin myös linkin käännökseen saman kirjan palvelutason tavoitteita käsittelevästä luvusta 4.
Käännös kissalta. Nauti lukemisesta!
Googlen SRE-tiimeillä on perusperiaatteet ja parhaat käytännöt onnistuneiden seuranta- ja ilmoitusjärjestelmien rakentamiseen. Tämä luku sisältää suosituksia siitä, mitä ongelmia verkkosivun vierailija voi kohdata ja kuinka ratkaista ongelmia, jotka vaikeuttavat verkkosivujen näyttämistä.
määritellä
Valvontaan liittyvistä aiheista ei käytetä yhtä sanastoa. Edes Googlessa alla olevat termit eivät ole yleisessä käytössä, mutta listaamme yleisimmät tulkinnat.
seuranta
Kerätään, käsitellään, yhdistetään ja näytetään reaaliaikaisia määrällisiä tietoja järjestelmästä: pyyntöjen määrä ja pyyntötyypit, virheiden määrä ja virhetyypit, pyyntöjen käsittelyaika ja palvelimen käyttöaika.
Valkoisen laatikon valvonta
Valvonta perustuu järjestelmän sisäisten osien näyttämiin mittareihin, mukaan lukien lokit, JVM- tai HTTP-käsittelijän profilointimittaukset, jotka luovat sisäisiä tilastoja.
Mustan laatikon valvonta
Sovelluksen toiminnan testaaminen käyttäjän näkökulmasta.
Kojelauta (hallintapaneelit)
Käyttöliittymä (yleensä verkkokäyttöliittymä), joka tarjoaa yleiskatsauksen palveluiden keskeisistä terveysindikaattoreista. Kojelaudassa voi olla suodattimia, mahdollisuus valita näytettävät mittarit jne. Käyttöliittymä on suunniteltu tunnistamaan tärkeimmät mittarit käyttäjille. Kojelauta voi myös näyttää tietoja tekniselle tukihenkilöstölle: pyyntöjono, luettelo tärkeimmistä virheistä, määrätty insinööri tietylle vastuualueelle.
Varoitus (ilmoitus)
Ilmoitukset, jotka on tarkoitettu henkilölle sähköpostitse tai muutoin vastaanotettaviksi ja jotka voivat laueta virheiden tai pyyntöjonon kasvun seurauksena. Ilmoitukset luokitellaan seuraavasti: liput, sähköposti-ilmoitukset ja messenger-viestit.
Perimmäinen syy (perussyy)
Ohjelmistovirhe tai inhimillinen virhe, jonka ei pitäisi toistua korjattuna. Ongelmalla voi olla useita pääsyitä: riittämätön prosessiautomaatio, ohjelmistovika, riittämätön sovelluslogiikan tutkiminen. Jokainen näistä tekijöistä voi olla perimmäinen syy, ja jokainen niistä on poistettava.
Solmu ja kone (solmu ja kone)
Vaihdettavat termit viittaavat yksittäiseen esiintymään käynnissä olevasta sovelluksesta fyysisessä palvelimessa, virtuaalikoneessa tai säilössä. Yhdellä koneella voi olla useita palveluita. Palvelut voivat olla:
- liittyvät toisiinsa: esimerkiksi välimuistipalvelin ja verkkopalvelin;
- toisiinsa liittymättömät palvelut samassa laitteistossa: esimerkiksi koodivarasto ja konfigurointijärjestelmän ohjattu toiminto, kuten tai .
Työnnä
Kaikki muutokset ohjelmiston kokoonpanoon.
Miksi seurantaa tarvitaan
On useita syitä, miksi sovelluksia tulisi valvoa:
Pitkän aikavälin trendien analyysi
Kuinka suuri tietokanta on ja kuinka nopeasti se kasvaa? Miten päivittäinen käyttäjämäärä muuttuu?
Suorituskyvyn vertailu
Ovatko kyselyt nopeampia Acme Bucket of Bytes 2.72:ssa kuin Ajax DB 3.14:ssä? Kuinka paljon paremmin pyynnöt tallennetaan välimuistiin lisäsolmun ilmestymisen jälkeen? Onko sivusto hitaampi kuin viime viikolla?
Hälytys (ilmoitukset)
Jotain on rikki ja jonkun on korjattava se. Tai jokin hajoaa pian ja jonkun on tarkistettava se pian.
Hallintapaneelien luominen
Hallintapaneelien tulee vastata peruskysymyksiin ja sisältää jotain aiheesta - viiveet (latenssi), liikenne (liikenne), virheet (virheet) ja kuormitusarvo (kylläisyys).
Retrospektiivisen analyysin tekeminen (virheenkorjaus)
Pyynnön käsittelyviive kasvoi, mitä muuta tapahtui samaan aikaan?
Valvontajärjestelmät ovat hyödyllisiä tietolähteenä business intelligence -järjestelmille ja helpottavat tietoturvahäiriöiden analysointia. Koska tämä kirja keskittyy suunnittelualueisiin, joilla SRE:llä on asiantuntemusta, emme käsittele valvontatekniikoita tässä.
Valvonta ja hälytykset antavat järjestelmän kertoa, milloin se on rikki tai rikkoutumassa. Kun järjestelmä ei pysty korjaamaan itseään automaattisesti, haluamme ihmisen analysoivan hälytyksen, määrittävän, onko ongelma edelleen olemassa, korjaavan sen ja määrittävän sen perimmäisen syyn. Jos et tarkasta järjestelmän osia, et koskaan saa hälytystä vain siksi, että "jokin näyttää hieman oudolta".
Ihmishälytysten lataaminen on melko kallista työntekijän ajankäyttöä. Jos työntekijä on töissä, hälytys keskeyttää työnkulun. Jos työntekijä on kotona, hälytys keskeyttää henkilökohtaisen ajan ja mahdollisesti nukkumisen. Kun hälytyksiä esiintyy liian usein, työntekijät luiskaavat, viivyttävät tai jättävät huomioimatta saapuvat hälytykset. Ajoittain he jättävät huomiotta todellisen hälytyksen, joka on melutapahtumien peitossa. Palvelukatkot voivat kestää pitkään, koska melutapahtumat estävät ongelmien nopean diagnosoinnin ja ratkaisun. Tehokkailla yleisäänentoistojärjestelmillä on hyvä signaali-kohinasuhde.
Järkevien odotusten määrittäminen seurantajärjestelmästä
Monimutkaisen sovelluksen valvonnan määrittäminen on sinänsä monimutkainen suunnittelutehtävä. Vaikka keräys-, näyttö- ja hälytystyökalujen infrastruktuuri on merkittävä, Googlen 10–12 jäsenen SRE-tiimiin kuuluu yleensä yksi tai kaksi henkilöä, joiden päätarkoituksena on rakentaa ja ylläpitää valvontajärjestelmiä. Tämä määrä on pienentynyt ajan myötä, kun yleistämme ja keskitämme valvontainfrastruktuuria, mutta jokaisessa SRE-tiimissä on yleensä vähintään yksi vain tarkkaileva työntekijä. On sanottava, että vaikka on varsin mielenkiintoista seurata valvontajärjestelmän kojetauluja, SRE-tiimit välttävät huolellisesti tilanteita, joissa jonkun on katsottava näyttöä ongelmien seuraamiseksi.
Yleisesti ottaen Google on siirtynyt yksinkertaisiin ja nopeisiin seurantajärjestelmiin, joissa on optimaaliset jälkianalyysityökalut. Vältämme "maagisia" järjestelmiä, jotka yrittävät ennustaa kynnysarvoja tai löytää automaattisesti perimmäisen syyn. Anturit, jotka havaitsevat ei-toivotun sisällön loppukäyttäjien pyynnöissä, ovat ainoa vastaesimerkki; niin kauan kuin nämä anturit pysyvät yksinkertaisina, ne voivat nopeasti havaita vakavien poikkeamien syyt. Muut seurantatietojen käyttömuodot, kuten kapasiteetin suunnittelu tai liikenneennusteet, ovat haastavampia. Havainto erittäin pitkän ajan (kuukausien tai vuosien) aikana pienellä näytteenottotaajuudella (tunteja tai päiviä) paljastaa pitkän aikavälin trendin.
Googlen SRE-tiimi on käsitellyt monimutkaisia riippuvuushierarkioita vaihtelevalla menestyksellä. Käytämme harvoin sääntöjä, kuten "jos huomaan, että tietokanta on hidastunut, saan tietokannan hidastumisesta varoituksen, muuten saan hitaan sivuston varoituksen." Riippuvuusperusteiset säännöt viittaavat yleensä järjestelmämme muuttumattomiin osiin, kuten järjestelmään, joka suodattaa käyttäjäliikennettä datakeskukseen. Esimerkiksi "jos palvelinkeskuksen liikenteen suodatus on määritetty, älä ilmoita minulle käyttäjien pyyntöjen käsittelyn viivästyksistä" on yksi palvelinkeskuksen hälytysten yleinen sääntö. Muutamat Googlen tiimit tukevat monimutkaisia riippuvuushierarkioita, koska infrastruktuurimme muuttuu jatkuvasti uudelleen.
Jotkut tässä luvussa esitetyistä ajatuksista pitävät edelleen paikkansa: aina on tapa edetä nopeammin oireista perimmäisyyteen, erityisesti jatkuvasti muuttuvissa järjestelmissä. Tästä syystä, vaikka tässä luvussa hahmotellaan joitain valvontajärjestelmien tavoitteita ja kuinka ne saavutetaan, on tärkeää, että valvontajärjestelmät ovat yksinkertaisia ja ymmärrettäviä kaikille tiimin jäsenille.
Samoin, jotta kohinataso pysyy alhaisena ja signaalitaso korkeana, lähestymistapojen hälyttävien kohteiden valvontaan on oltava hyvin yksinkertaisia ja luotettavia. Sääntöjen, jotka tuottavat varoituksia ihmisille, tulee olla helposti ymmärrettäviä ja niiden tulee olla selvä ongelma.
Oireet vs. syyt
Valvontajärjestelmäsi pitäisi vastata kahteen kysymykseen: "mikä on rikki" ja "miksi se on rikki".
"Mikä meni rikki" viittaa oireeseen ja "miksi meni" viittaa syytä. Alla olevassa taulukossa on esimerkkejä tällaisista linkeistä.
oire
syy
Vastaanotetaan HTTP-virhe 500 tai 404
Tietokantapalvelimet kieltäytyvät muodostamasta yhteyksiä
Hitaat palvelimen vastaukset
Korkea suorittimen käyttöaste tai vaurioitunut Ethernet-kaapeli
Etelämantereen käyttäjät eivät saa kissan GIF-kuvia
CDN-verkkosi vihaa tiedemiehiä ja kissaeläimiä, joten jotkin IP-osoitteet ovat mustalla listalla
Yksityinen sisältö on saatavilla kaikkialla
Uuden ohjelmistojulkaisun julkaiseminen sai palomuurin unohtamaan kaikki ACL:t ja päästämään kaikki sisään
"Mitä" ja "miksi" ovat yksi tärkeimmistä rakennuspalikoista hyvän valvontajärjestelmän luomisessa maksimaalisella signaalilla ja minimikohinalla.
Black-box vs. White-box
Yhdistämme laajan white-box-valvonnan vaatimattomaan black-box-valvontaan kriittisiä mittareita varten. Helpoin tapa verrata Black-boxia White-boxiin on se, että Black-box on oirekeskeinen ja reaktiivinen pikemminkin kuin ennakoiva valvonta: "järjestelmä ei toimi kunnolla juuri nyt." White-box riippuu järjestelmien sisäisistä tarkistusominaisuuksista: tapahtumalokeista tai verkkopalvelimista. Siten White-boxin avulla voit havaita tulevat ongelmat, toimintahäiriöt, jotka näyttävät pyynnön uudelleenlähetyksestä jne.
Huomaa, että monikerroksisessa järjestelmässä yhden insinöörin vastuualueella oleva oire on oire toisen insinöörin vastuualueella. Esimerkiksi tietokannan suorituskyky on heikentynyt. Hidas tietokannan luku on oire tietokannan SRE:stä, joka havaitsee ne. Kuitenkin etupään SRE:lle, joka katselee hidasta verkkosivustoa, syy saman hitaan tietokannan lukemiseen on tietokannan hidas. Siksi valkoisen laatikon seuranta keskittyy joskus oireisiin ja joskus syihin riippuen sen laajuudesta.
Kun telemetriaa kerätään virheenkorjausta varten, White-box-valvonta vaaditaan. Jos verkkopalvelimet reagoivat hitaasti tietokantakyselyihin, sinun on tiedettävä, kuinka nopeasti verkkopalvelin kommunikoi tietokannan kanssa ja kuinka nopeasti se vastaa. Muuten et pysty erottamaan hitaan tietokantapalvelimen ja verkko-ongelman välillä verkkopalvelimen ja tietokannan välillä.
Mustan laatikon valvonnalla on keskeinen etu hälytyksiä lähetettäessä: käynnistät ilmoituksen vastaanottajalle, kun ongelma on jo aiheuttanut todellisia oireita. Toisaalta vielä esiintulemattomalle, mutta tulevalle Black-box-ongelmalle seuranta on turhaa.
Neljä kultaista merkkiä
Neljä kultaista valvontasignaalia ovat latenssi, liikenne, virheet ja kylläisyys. Jos pystyt mittaamaan vain neljää käyttäjän järjestelmämittaria, keskity näihin neljään.
viive
Pyynnön käsittelyyn tarvittava aika. On tärkeää erottaa onnistuneiden ja epäonnistuneiden pyyntöjen latenssi. Esimerkiksi HTTP 500 -virhe, joka johtuu yhteyden katkeamisesta tietokantaan tai toiseen taustajärjestelmään, voidaan diagnosoida hyvin nopeasti, mutta HTTP 500 -virhe voi viitata epäonnistuneeseen pyyntöön. 500-virheen vaikutuksen löytäminen kokonaislatenssiin voi johtaa virheellisiin johtopäätöksiin. Toisaalta hidas virhe on jopa nopea virhe! Siksi on tärkeää seurata virheiden latenssia sen sijaan, että vain suodatatttaisiin virheet pois.
liikenne
Järjestelmällesi lähetettyjen pyyntöjen määrä korkean tason järjestelmämittareilla mitattuna. Verkkopalvelussa tämä mittaus edustaa tyypillisesti HTTP-pyyntöjen määrää sekunnissa jaettuna pyyntöjen luonteella (esimerkiksi staattinen tai dynaaminen sisältö). Äänen suoratoistojärjestelmässä tämä mittaus voi olla keskitetty verkon I/O-nopeuteen tai samanaikaisten istuntojen lukumäärään. Avainarvojen tallennusjärjestelmässä tämä mittaus voi olla tapahtumia tai hakuja sekunnissa.
Virheitä
Tämä on epäonnistuneiden pyyntöjen määrä joko eksplisiittisesti (esimerkiksi HTTP 500), epäsuorasti (esimerkiksi HTTP 200, mutta yhdistettynä huonoon sisältöön) tai käytännön mukaan (esimerkiksi "Jos sieppaat vastauksen sekunnissa, yksi sekunti on virhe"). Jos HTTP-vastauskoodeja ei ole tarpeeksi ilmaisemaan kaikkia vikatilanteita, toissijaisia (sisäisiä) protokollia voidaan tarvita osittaisen epäonnistumisen havaitsemiseksi. Kaikkien tällaisten virheellisten pyyntöjen valvonta voi olla epätietoista, kun taas päästä päähän -järjestelmätestit voivat auttaa sinua havaitsemaan, että käsittelet väärää sisältöä.
Kylläisyys
Mittari näyttää kuinka paljon palveluasi käytetään. Tämä on järjestelmän valvontatoimenpide, joka tunnistaa rajallisimmat resurssit (esimerkiksi järjestelmässä, jossa on rajoitettu muisti, näyttää muistin, järjestelmässä, jossa on rajoitettu I / O, näyttää I / O:n määrän). Huomaa, että monet järjestelmät heikkenevät ennen kuin ne saavuttavat 100 %:n käytön, joten käyttötavoitteen määrittäminen on välttämätöntä.
Monimutkaisissa järjestelmissä kylläisyyttä voidaan täydentää korkeamman tason kuormitusmittauksella: pystyykö palvelusi käsittelemään kaksinkertaista liikennettä kunnolla, käsittelemään vain 10 % enemmän liikennettä vai käsittelemään jopa vähemmän liikennettä kuin tällä hetkellä? Yksinkertaisille palveluille, joissa ei ole parametreja, jotka muuttavat pyynnön monimutkaisuutta (esim. "Älä anna minulle mitään" tai "Haluan yksilöllisen monotonisen kokonaisluvun"), jotka harvoin muuttavat konfiguraatiota, staattinen kuormitustesti voi olla riittävä. Kuten edellisessä kappaleessa mainittiin, useimpien palveluiden tulisi käyttää epäsuoria signaaleja, kuten suorittimen käyttöastetta tai verkon kaistanleveyttä, joilla on tiedossa oleva yläraja. Nouseva latenssi on usein kyllästymisen tärkein indikaattori. 99. prosenttipisteen vasteajan mittaaminen pienessä ikkunassa (esim. minuutti) voi antaa hyvin varhaisen kyllästyssignaalin.
Lopuksi kylläisyys liittyy myös ennusteisiin tulevasta kyllästymisestä, kuten: "Näyttää siltä, että tietokanta täyttää kiintolevysi 4 tunnissa."
Jos mittaat kaikki neljä kultaista signaalia ja kun jossakin mittarissa on ongelma (tai kyllästyessä melkein ongelma), ilmoitat asiasta henkilölle, palvelusi jää enemmän tai vähemmän valvonnan piiriin.
Huoli hännästä (tai instrumentaatiosta ja suorituskyvystä)
Kun valvontajärjestelmää rakennetaan tyhjästä, on houkuttelevaa kehittää järjestelmä, joka perustuu keskiarvoihin: keskimääräinen latenssi, keskimääräinen solmun suorittimen käyttöaste tai tietokannan keskimääräinen käyttöaste. Kahden viimeisen esimerkin vaara on ilmeinen: prosessorit ja tietokannat hävitetään hyvin arvaamattomalla tavalla. Sama koskee viivästyksiä. Jos käytät verkkopalvelua, jonka keskimääräinen latenssi on 100 ms ja 1000 pyyntöä sekunnissa, 1 % pyynnöistä voi kestää 5 sekuntia. Jos käyttäjät ovat riippuvaisia useista tällaisista verkkopalveluista, yksittäisen taustajärjestelmän 99. prosenttipiste voi helposti tulla käyttöliittymän mediaanivasteajan.
Yksinkertaisin tapa erottaa pyyntöjen hidas keskiarvo ja erittäin hidas pyrstö on kerätä tilastoissa ilmaistujen pyyntöjen mittaukset (histogrammit ovat sopiva työkalu näyttämiseen) todellisten viiveiden sijaan: kuinka monta pyyntöä vastaanottanut palvelu palveli. 0 ms - 10 ms, 10 ms - 30 ms, 30 ms - 100 ms, 100 ms - 300 ms jne. Histogrammin rajojen laajentaminen noin eksponentiaalisesti (kertoimella noin 3) on usein helppo tapa visualisoida pyyntöjen jakautuminen.
Oikean tarkkuuden valitseminen mittauksiin
Järjestelmän eri elementit tulee mitata eri tarkkuudella. Esimerkiksi:
- Prosessorin käytön katsominen tietyn ajanjakson aikana ei näytä pitkiä piikkejä, jotka johtavat korkeisiin viiveisiin.
- Toisaalta verkkopalvelussa, joka kohdistuu enintään 9 tunnin käyttökatkoihin vuodessa (99,9 % vuotuinen käyttöaika), HTTP 200 -vastauksen tarkistaminen useammin kuin kerran tai kahdesti minuutissa olisi todennäköisesti tarpeettoman usein.
- Vastaavasti kiintolevyn vapaan tilan tarkistaminen 99,9 %:n saatavuuden varmistamiseksi useammin kuin kerran 1-2 minuutin välein on luultavasti tarpeetonta.
Huolehdi siitä, miten rakennat mittojen tarkkuuden. Prosessorin käyttöaste 1 sekunnissa voi tarjota mielenkiintoisia tietoja, mutta tällaiset toistuvat mittaukset voivat olla erittäin kalliita kerätä, tallentaa ja analysoida. Jos seurantatavoitteesi edellyttää suurta tarkkuutta eikä suurta reagointikykyä, voit vähentää näitä kustannuksia määrittämällä mittarien keräämisen palvelimelle ja määrittämällä sitten ulkoisen järjestelmän keräämään ja kokoamaan nämä tiedot. Voisitko:
- Mittaa suorittimen käyttöä joka sekunti.
- Vähennä yksityiskohtia 5 prosenttiin.
- Kootut tiedot minuutin välein.
Tämän strategian avulla voit kerätä erittäin tarkkoja tietoja ilman suuria analyysi- ja tallennuskustannuksia.
Mahdollisimman yksinkertaista, mutta ei helpompaa
Erilaisten vaatimusten pinoaminen päällekkäin voi johtaa erittäin monimutkaiseen valvontajärjestelmään. Esimerkiksi järjestelmässäsi voi olla seuraavat monimutkaiset elementit:
- Hälytykset pyyntöjen viiveen eri kynnysten mukaan, eri prosenttipisteissä, kaikenlaisissa eri mittareissa.
- Lisäkoodin kirjoittaminen mahdollisten syiden havaitsemiseksi ja tunnistamiseksi.
- Luo aiheeseen liittyviä kojetauluja jokaiselle mahdolliselle ongelmien syille.
Mahdollisten komplikaatioiden lähteet eivät lopu koskaan. Kuten kaikki ohjelmistojärjestelmät, valvonnasta voi tulla niin monimutkaista, että se on hauras, vaikea muuttaa ja ylläpitää.
Suunnittele siksi valvontajärjestelmäsi mahdollisimman yksinkertaiseksi. Kun valitset, mitä seurata, pidä mielessä seuraavat asiat:
- Sääntöjen, jotka useimmiten havaitsevat todellisia tapauksia, tulee olla mahdollisimman yksinkertaisia, ennustettavia ja luotettavia.
- Harvemmin (esimerkiksi harvemmin kuin neljännesvuosittain joidenkin SRE-tiimien osalta) suoritettavat tiedonkeruun, yhdistämisen ja hälytykset on poistettava.
- Tiedot, jotka on kerätty, mutta joita ei näytetä missään esikatselupaneelissa tai joita ei käytetä minkään ilmoituksen yhteydessä, voidaan poistaa.
Googlella perustietojen kerääminen ja yhdistäminen yhdistettynä hälytyksiin ja kojetauluihin toimii hyvin suhteellisen itsenäisenä järjestelmänä (Googlen valvontajärjestelmä on itse asiassa jaettu useisiin alijärjestelmiin, mutta yleensä ihmiset ovat tietoisia näiden alijärjestelmien kaikista näkökohdista). Voi olla houkuttelevaa yhdistää valvonta muihin monimutkaisten järjestelmien testausmenetelmiin: yksityiskohtainen järjestelmän profilointi, prosessin virheenkorjaus, poikkeus- tai vikatietojen seuranta, kuormitustestaus, lokien kerääminen ja analysointi tai liikennetarkastus. Vaikka useimmilla näistä asioista on yhteistä perusvalvonnan kanssa, niiden sekoittaminen johtaa liian moniin tuloksiin ja luo monimutkaisen ja hauraan järjestelmän. Kuten monissa muissakin ohjelmistokehityksen näkökohdissa, eri järjestelmien tukeminen selkeillä, yksinkertaisilla, löyhästi kytketyillä integraatiopisteillä on paras strategia (esimerkiksi web-sovellusliittymän avulla tiivistelmätietojen hakeminen muodossa, joka voi pysyä vakiona pitkän ajan kuluessa ).
Periaatteiden yhdistäminen
Tässä luvussa käsitellyt periaatteet voidaan yhdistää seuranta- ja varoitusfilosofiaksi, jota Googlen SRE-tiimit tukevat ja noudattavat. Tämän seurantafilosofian noudattaminen on toivottavaa, se on hyvä lähtökohta hälytysmetodologian luomiselle tai tarkistamiselle ja voi auttaa sinua esittämään toiminnalle oikeat kysymykset organisaatiosi koosta tai palvelun tai järjestelmän monimutkaisuudesta riippumatta.
Kun luot seuranta- ja hälytyssääntöjä, seuraavien kysymysten esittäminen voi auttaa sinua välttämään vääriä positiivisia tuloksia ja tarpeettomia hälytyksiä:
- Tunnistaako tämä sääntö muutoin havaitsemattoman järjestelmätilan, joka on kiireellinen, toimintakehottaa ja vaikuttaa väistämättä käyttäjään?
- Voinko jättää tämän varoituksen huomioimatta tietäen, että se on hyvänlaatuinen? Milloin ja miksi voin jättää tämän varoituksen huomioimatta ja miten voin välttää tämän skenaarion?
- Tarkoittaako tämä hälytys, että se vaikuttaa käyttäjiin? Onko olemassa tilanteita, joissa käyttäjiä ei vaikuteta negatiivisesti esimerkiksi liikenteen suodatuksen vuoksi tai testijärjestelmiä käytettäessä, joiden hälytykset tulisi suodattaa?
- Voinko ryhtyä toimiin vastauksena tähän hälytykseen? Ovatko nämä toimenpiteet kiireellisiä vai voivatko ne odottaa aamuun asti? Onko toiminnon automatisointi turvallista? Onko tämä toimenpide pitkän aikavälin ratkaisu vai lyhytaikainen ratkaisu?
- Jotkut ihmiset saavat useita hälytyksiä tästä ongelmasta, joten onko mahdollista vähentää määrää?
Nämä kysymykset kuvastavat hälytysten ja hälytysjärjestelmien perusfilosofiaa:
- Joka kerta kun hälytys tulee, minun on reagoitava kiireellisesti. Voin kiirehtiä useita kertoja päivässä ennen kuin väsyn.
- Jokaisen hälytyksen on oltava ajan tasalla.
- Jokaisen hälytyksen vastauksen on vaadittava ihmisen väliintuloa. Jos ilmoitus voidaan käsitellä automaattisesti, sen ei pitäisi tulla.
- Hälytysten tulee koskea uutta ongelmaa tai tapahtumaa, jota ei ole tapahtunut aiemmin.
Tämä lähestymistapa hämärtää tiettyjä eroja: jos hälytys täyttää neljä edellistä ehtoa, sillä ei ole väliä, lähetetäänkö hälytys White-box-valvontajärjestelmästä vai Black-Boxista. Tämä lähestymistapa vahvistaa myös tiettyjä eroja: on parempi käyttää paljon enemmän vaivaa oireiden tunnistamiseen kuin syihin; kun on kyse syistä, sinun tarvitsee vain huolehtia väistämättömistä syistä.
Pitkäaikainen seuranta
Nykypäivän tuotantoympäristöissä valvontajärjestelmät valvovat jatkuvasti kehittyvää tuotantojärjestelmää, jossa ohjelmistoarkkitehtuuri, kuormitusominaisuudet ja suorituskykytavoitteet muuttuvat. Hälytyksistä, joita on tällä hetkellä vaikea automatisoida, voi tulla yleisiä ja ehkä jopa huomion arvoisia. Tässä vaiheessa jonkun on löydettävä ja korjattava ongelman perimmäiset syyt; jos tällainen ratkaisu ei ole mahdollista, reaktio hälytykseen vaatii täyden automatisoinnin.
On tärkeää, että seurantapäätökset tehdään pitkän aikavälin tavoitteita silmällä pitäen. Jokainen tänään käynnissä oleva hälytys vie ihmisen pois parantamasta järjestelmää huomenna, joten tuottavan järjestelmän käytettävyys tai suorituskyky heikkenee usein ajaksi, joka kuluu valvontajärjestelmän parantamiseen pitkällä aikavälillä. Katsotaanpa kahta esimerkkiä, jotka kuvaavat tätä ilmiötä.
Bigtable SRE: Tarina ylivalvoisuudesta
Googlen sisäinen infrastruktuuri tarjotaan ja mitataan yleensä palvelutasolla (SLO). Vuosia sitten Bigtable-palvelun SLO perustui käynnissä olevaa asiakasta simuloivan synteettisen tapahtuman keskimääräiseen suorituskykyyn. Bigtable-ongelmien ja tallennuspinon alempien tasojen vuoksi keskimääräistä suorituskykyä ohjasi "iso" häntä: huonoimmat 5 % kyselyistä olivat usein huomattavasti hitaampia kuin muut.
Sähköposti-ilmoituksia lähetettiin, kun SLO-kynnystä lähestyttiin, ja messenger-hälytyksiä lähetettiin, kun SLO-arvo ylittyi. Molempia hälytyksiä lähetettiin melko usein, mikä vei kohtuuttoman paljon suunnitteluaikaa: tiimi käytti huomattavan määrän aikaa hälytusten jäsentämiseen löytääkseen muutamia todella tärkeitä. Jäimme usein huomaamatta ongelman, joka todella vaikutti käyttäjiin, koska vain muutamat hälytyksistä koskivat kyseistä ongelmaa. Monet hälytyksistä olivat ei-kiireellisiä ymmärrettävien infrastruktuuriongelmien vuoksi, ja niitä käsiteltiin normaalisti tai niitä ei käsitelty ollenkaan.
Tilanteen korjaamiseksi tiimi käytti kolmiosaista lähestymistapaa: työskennellessämme kovasti Bigtablen suorituskyvyn parantamiseksi asetimme tilapäisesti 75. prosenttipisteen kyselyn vastausviiveelle SLO-tavoitteeksemme. Sammutimme myös sähköpostihälytykset, koska niitä oli niin paljon, että niiden diagnosointiin oli mahdotonta tuhlata aikaa.
Tämä strategia antoi meille mahdollisuuden aloittaa pitkän aikavälin ongelmien korjaaminen Bigtablessa ja tallennuspinon alemmissa kerroksissa sen sijaan, että olisimme jatkuvasti korjaaneet taktisia ongelmia. Insinöörit pystyivät todella saamaan työnsä valmiiksi, kun heitä ei pommitettu koko ajan hälytyksellä. Loppujen lopuksi hälytysten käsittelyn väliaikainen viive antoi meille mahdollisuuden parantaa palvelun laatua.
Gmail: ennakoitavat, algoritmiset ihmisten vastaukset
Gmail rakennettiin alussa modifioidulle Workqueue-prosessinhallintajärjestelmälle, joka luotiin eräprosessien hakuindeksikappaleita varten. Workqueue mukautettiin pitkäikäisiin prosesseihin ja sovellettiin myöhemmin Gmailiin, mutta joitain läpinäkymättömän ajoituskoodin virheitä osoittautui erittäin vaikeaksi korjata.
Tuolloin Gmail-seuranta oli rakennettu niin, että hälytykset käynnistyivät, kun yksittäisiä tehtäviä peruutettiin Workqueuen avulla. Tämä lähestymistapa ei ollut ihanteellinen, koska Gmail suoritti jo tuolloin tuhansia tehtäviä, joista jokainen annettiin prosenttiosille käyttäjistämme. Huolehdimme siitä, että Gmail-käyttäjillä on hyvä käyttökokemus, mutta useiden ilmoitusten käsittely ei tullut kysymykseen.
Tämän ongelman ratkaisemiseksi Gmail SRE loi työkalun, joka auttaa ajoittimen virheenkorjauksessa mahdollisimman hyvin minimoimaan vaikutukset käyttäjiin. Ryhmä keskusteli useaan otteeseen siitä, pitäisikö yksinkertaisesti automatisoida koko sykli ongelman löytämisestä sen korjaamiseen, kunnes pitkän aikavälin ratkaisu löydettiin, mutta jotkut olivat huolissaan siitä, että tällainen ratkaisu viivästyisi ongelman varsinaista korjaamista.
Tällainen jännitys oli yleinen tiimissä ja heijasteli usein itsekuria kohtaan tuntemattoman itseluottamuksen puutetta: vaikka jotkut tiimin jäsenet haluavat antaa aikaa kunnolliselle korjaukselle, toiset pelkäävät, että lopullinen korjaus unohtuu ja väliaikainen korjaus kestää ikuisuuden. Tämä ongelma ansaitsee huomiota, sillä on liian helppoa korjata ongelmat väliaikaisesti pysyvän korjauksen sijaan. Johtajilla ja teknisellä henkilökunnalla on keskeinen rooli pitkäaikaisten korjausten toteuttamisessa tukemalla ja priorisoimalla mahdollisesti pitkäaikaisia pitkäaikaisia korjauksia silloinkin, kun alkukipu hellittää.
Säännöllisten toistuvien hälytysten ja algoritmisten reaktioiden tulee olla punainen lippu. Tiimisi haluttomuus automatisoida näitä hälytyksiä tarkoittaa, että tiimillä ei ole luottamusta siihen, että he voivat luottaa algoritmeihin. Tämä on vakava ongelma, johon on puututtava.
Pitkäaikainen
Yleinen teema yhdistää Bigtable- ja Gmail-esimerkit: kilpailu lyhyen ja pitkän aikavälin saatavuuden välillä. Usein voimakas ponnistelu voi auttaa herkkää järjestelmää saavuttamaan korkean käytettävyyden, mutta tämä polku on yleensä lyhytaikainen, täynnä joukkueen loppuunpalamista ja riippuvuutta pienestä määrästä saman sankarillisen tiimin jäseniä.
Hallittu, lyhytaikainen saatavuuden heikkeneminen on usein tuskallista, mutta strategisesti tärkeää järjestelmän pitkän aikavälin vakauden kannalta. On tärkeää, ettei kutakin hälytystä harkita erikseen, vaan pohditaan, johtaako hälytysten kokonaismäärä terveeseen, asianmukaisesti saavutettavaan järjestelmään, jossa on toimiva tiimi ja suotuisa ennuste. Analysoimme hälytystiheystilastot (yleensä ilmaistuna tapauksina vuoroa kohden, jossa tapaus voi koostua useista toisiinsa liittyvistä tapauksista) neljännesvuosittaisissa raporteissa johdon kanssa, jolloin päätöksentekijät voivat jatkuvasti esittää hälytysjärjestelmän kuormituksen ja tiimin yleisen kunnon.
Johtopäätös
Tie terveelliseen seurantaan ja hälytyksiin on yksinkertainen ja suoraviivainen. Se keskittyy ongelman oireisiin, joista varoituksia luodaan, ja syyn seuranta toimii apuna virheenkorjausongelmissa. Oireiden seuranta on sitä helpompaa, mitä korkeammalla olet hallitsemassasi pinossa, vaikka tietokannan kuormituksen ja suorituskyvyn valvonta tulisi tehdä suoraan tietokannassa. Sähköposti-ilmoituksia käytetään hyvin rajoitetusti ja ne kasvavat helposti meluksi. sen sijaan sinun tulisi käyttää kojelautaa, joka valvoo kaikkia ajankohtaisia ongelmia, joista ilmoitetaan sähköpostitse. Kojelauta voidaan myös yhdistää tapahtumalokiin historiallisten korrelaatioiden analysoimiseksi.
Pitkällä aikavälillä on saavutettava onnistunut vuorottelu oireilmoitusten ja välittömien todellisten ongelmien välillä ja mukautettava tavoitteita sen varmistamiseksi, että seuranta tukee nopeaa diagnoosia.
Kiitos, että luit käännöksen loppuun. Tilaa telegram-kanavani valvonnasta и .
Lähde: will.com