SRE-inxhinier â praktikant
Le tĂ« fillojmĂ« me prezantimin tim. UnĂ« jam , inxhinier frontend nĂ« grupin tĂ« GitLab. JavĂ«n e kaluar kam pasur nderin tĂ« jem praktikant tek njĂ« nga SRE-inxhinierĂ«t tanĂ« tĂ« deĆŸur. QĂ«llimi ishte mbikĂ«qyrja e pĂ«rditshme mbi se si deĆŸuri reagon ndaj incidenteve dhe tĂ« fitoj pĂ«rvojĂ« praktike. DĂ«shirojmĂ« qĂ« inxhinierĂ«t tanĂ« tĂ« kuptojnĂ« mĂ« mirĂ« nevojat e pĂ«rdoruesve Monitor::Health.
Më është dashur të ndjek SRE-inxhinierin për një javë. Kjo do të thotë se isha prezent në kalimin e rojeve, kam vëzhguar të njëjtat kanale alarmesh dhe kam reaguar ndaj incidenteve, nëse dhe kur ato ndodhnin.
Incidentet
Gjatë javës ndodhën 2 incidente.
1. Minerët e kriptomonedhave
të mërkurën në GitLab.com u regjistrua një rritje në përdorim e 'runner'-it, e cila u shkaktua nga përpjekjet për të përdorur minutat e runner-it për minimin e kriptomonedhave. Incidents u menaxhua përmes mjetit tonë të neutralizimit të shkeljeve, i cili ndalon detyrat e runner-it dhe eliminon projektet dhe llogaritë e lidhura.
Nëse ky ngjarje nuk do të kishte dëgjuar, do të ishte kapur nga një mjet automatizimi, por në këtë rast SRE-inxhinieri e vuri re shkeljen i pari. U krijua një detyrë për incidentin, mirëpo informacioni rreth saj është i mbyllur.
2. Dëmtimi i performancës së aplikacioneve Canary dhe Main
Incidenti u shkaktua nga ngadalësimi dhe rritja e frekuencës së gabimeve në aplikacionet canary dhe main në Gitlab.com. Disa vlera Apdex u shkelën.
Detyrë e hapur për incidentin:
Pikat kryesore
Ja disa pika qĂ« kam nxjerrĂ« gjatĂ« javĂ«s sĂ« deĆŸurĂ«s.
1. Alarmet janë më të dobishme kur kapin devijimet nga norma.
Alarmet mund të ndahen në disa lloje:
- Alarmet qĂ« bazohen nĂ« njĂ« prag tĂ« caktuar, si âkanĂ« ndodhur 10 gabime 5xx nĂ« sekondĂ«â.
- Alarmet ku pragu Ă«shtĂ« njĂ« pĂ«rqindje, si âfrekuenca e gabimeve 5xx Ă«shtĂ« 10% e pĂ«rgjithshme e kĂ«rkesave nĂ« njĂ« kohĂ« tĂ« caktuarâ.
- Alarmet qĂ« bazohen nĂ« mesataren historike, si âgabimet 5xx nĂ« 90-tin percentileâ.
NĂ« pĂ«rgjithĂ«si, tipet e dytĂ« dhe tĂ« tretĂ« janĂ« mĂ« tĂ« dobishme pĂ«r SRE-inxhinierĂ«t deĆŸur, pasi ndihmojnĂ« nĂ« zbulojmĂ« devijimet nga norma nĂ« proces.
2. Shumë alarme nuk eskalohen në incidente
SRE-inxhinierët përballen me një fluks të vazhdueshëm alarmesh, shumë prej të cilave në të vërtetë nuk janë kritike.
Pra, pse të mos kufizojmë alarmet vetëm në ato që janë me të vërtetë të rëndësishme? Me këtë qasje, megjithatë, mund të mos njohësh simptomat e hershme që do të rriten, si një top bore, në një problem real që kërcënon dëme të mëdha.
Detyra e SRE-inxhinierit deĆŸur Ă«shtĂ« tĂ« pĂ«rcaktojĂ« se cilat alarme flasin vĂ«rtet pĂ«r diçka serioze dhe nĂ«se duhet t'i eskalohen dhe tĂ« fillohet hetimi. Dyshoj se kjo Ă«shtĂ« shkaktuar gjithashtu nga mungesa e fleksibilitetit tĂ« alarmit: do tĂ« ishte mĂ« mirĂ« nĂ«se do tĂ« kishim disa nivele ose âmençuriâ nĂ« konfigurimin e alarmĂ«ve sipas situatĂ«s sĂ« pĂ«rshkruar mĂ« sipĂ«r.
Propozim për funksionalitet:
3. SRE-inxhinierĂ«t tanĂ« tĂ« deĆŸur pĂ«rdorin shumĂ« mjete
TĂ« brendshme:
- Projekti GitLab infra: këtu jetojnë Runbook-et, kalimet e rojeve për ndryshim/javë, detyrat për përgjigje ndaj incidenteve.
- GitLab issues: hetimet, analizat dhe shërbimi ndoqen gjithashtu në detyra.
- Etiketat GitLab: detyrat e automatizimit aktivizohen nga etiketa të caktuara, të cilat robotët ndjekin aktivitetin e detyrave.
TĂ« jashtme:
- PagerDuty: alarmet
- Slack: këtu dërgohet fluksi i mesazheve nga PagerDuty/AlertManager. Integrimi me komandat slash për të kryer detyra të ndryshme, si mbyllja e alarmit ose eskalimi në një incident.
- Grafana: vizualizimi i metrikeve me fokus në trende afatgjata.
- Kibana: ofron vizualizim/faqe në log, mundësinë për t'u zhytur thellë në ngjarje të caktuara.
- Zoom: ka njĂ« âdhomĂ« diskutimiâ tĂ« qĂ«ndrueshme nĂ« Zoom. Kjo u mundĂ«son SRE-inxhinierĂ«ve tĂ« diskutojnĂ« ngjarje shpejt, pa humbur kohĂ« nĂ« krijimin e dhomave dhe dĂ«rgimin e lidhjeve pĂ«r pjesĂ«marrĂ«sit.
Dhe shumë, shumë më tepër.
4. Monitorimi i GitLab.com përmes GitLab është një pikë e vetme dështimi
Nëse ndodh një dështim i madh shërbimesh në GitLab.com, nuk do të dëshironim që kjo të ndikojë në aftësinë tonë për të zgjidhur problemin. Mund të menaxhohet nëse aktivizojmë një instancë të dytë të GitLab për menaxhimin e GitLab.com. Në të vërtetë, kjo tashmë funksionon për ne: .
5. Disa funksione që duhet të merren në konsideratë për t'u shtuar në GitLab
- , e ngjashme me Google Docs. Kjo do të ndihmonte në detyrat për incidente gjatë ngjarjeve, si dhe në detyrat për analizat. Në të dy rastet, disa pjesëmarrës mund të duhet të shtojnë diçka në kohë reale.
- Më shumë webhooks për detyra. Mundësia për të nisur hapa të ndryshëm të procesit të punës në GitLab nga brenda do të ndihmojë në uljen e varësisë nga integrimet e Slack. Për shembull, mundësia për të lejuar njoftimin në PagerDuty përmes komandës me slash në detyrën GitLab.
PĂ«rfundimi
Inxhinierët SRE përballen me shumë sfida. Do të ishte e shkëlqyer të shihnim më shumë produkte GitLab që adresojnë këto probleme. Ne tashmë po punojmë në disa shtesa të produktit që do të lehtësojnë proceset e punës të përmendura më sipër. Detajet janë të disponueshme në .
Në vitin 2020, ne po zgjeroni ekipin për të mbledhur të gjitha këto funksione të mrekullueshme. Nëse jeni të interesuar, ju lutemi shihni , dhe mos hezitoni të kontaktoni ndonjë nga anëtarët e ekipit tonë për çdo pyetje.
Burimi: habr.com
