SRE inženir - pripravnik
Najprej naj se predstavim. JAZ - , front-end inženir v skupini GitLab. Prejšnji teden sem imel čast stažirati pri enem od naših dežurnih SRE inženirjev. Cilj je bil opazovati, kako se dežurni vsakodnevno odziva na dogodke, in pridobiti resnične izkušnje na delovnem mestu. Želimo, da naši inženirji bolje razumejo potrebe uporabnikov Monitor::Zdravje.
En teden sem moral slediti inženirju SRE povsod. Se pravi, bil sem prisoten pri primopredaji, spremljal iste kanale obveščanja in se odzival na incidente, če in ko so se zgodili.
Incidenti
V enem tednu sta se zgodila 2 incidenta.
1. Cryptominer
GitLab.com je v sredo opazil skokovit porast uporabe 'a, ki ga povzročajo poskusi uporabe tekačevih minut za rudarjenje kriptovalute. Incident smo obravnavali z našim lastnim orodjem za nevtralizacijo kršitev, ki ustavi izvajalčeva opravila ter izbriše projekt in račun, povezan z njim.
Če tega dogodka ne bi opazili, bi ga samodejno orodje ujelo, vendar je v tem primeru inženir SRE prvi opazil kršitev. Naloga incidenta je bila ustvarjena, vendar so informacije o njej zaprte.
2. Poslabšanje zmogljivosti aplikacij Canary in Main
Incident je povzročila upočasnitev in povečana pogostost napak v kanarčku in glavnih spletnih aplikacijah na Gitlab.com. Več vrednosti Apdex je bilo kršenih.
Odpri nalogo incidenta:
Ključne ugotovitve
Tukaj je nekaj stvari, ki sem se jih naučil med tednom v službi.
1. Opozorila so najbolj uporabna pri zaznavanju odstopanj od norme.
Opozorila lahko razdelimo na več vrst:
- Opozorila na podlagi določene mejne vrednosti, na primer »pojavilo se je 10 napak 5xx na sekundo«.
- Opozorila, pri katerih je prag odstotna vrednost, kot je »pogostost 5xx napak na 10 % skupnega obsega zahtev v določenem času«.
- Opozorila na podlagi zgodovinskega povprečja, kot je "5xx napak pri 90. percentilu".
Na splošno sta tipa 2 in 3 uporabnejša za SRE v službi, saj razkrivata odstopanja od norme v procesu.
2. Veliko opozoril nikoli ne preraste v incidente.
Inženirji SR se ukvarjajo s stalnim tokom opozoril, od katerih mnoga dejansko niso kritična.
Zakaj torej ne bi svojih opozoril omejili le na res pomembna? S tem pristopom pa morda ne boste prepoznali zgodnjih simptomov tega, kar se bo spremenilo v pravo težavo, ki grozi z veliko škodo.
Naloga dežurnega SRE je ugotoviti, katera opozorila dejansko kažejo na nekaj resnega in ali jih je treba eskalirati in obravnavati. Sumim, da je to tudi posledica neprilagodljivosti opozoril: bolje bi bilo, če bi obstajalo več ravni ali »pametnih« načinov za konfiguracijo opozoril v skladu z zgoraj opisano situacijo.
Predlog funkcije:
3. Naši dežurni SRE uporabljajo veliko orodij.
Notranji:
- Infra projekt GitLab: runbooks v živo tukaj, izmenske/tedenske naloge, naloge odzivanja na incidente.
- Težave GitLab: Preiskave, pregledi in vzdrževanje se prav tako spremljajo v težavah.
- Oznake GitLab: Naloge za avtomatizacijo se zaženejo z uporabo posebnih oznak, ki jih roboti uporabljajo za sledenje dejavnosti opravil.
Zunanje:
- PagerDuty: Opozorila
- Slack: sem gre tok sporočil PagerDuty/AlertManager. Integracija z ukazi za poševnico za izvajanje različnih nalog, kot je zapiranje opozorila ali stopnjevanje do incidenta.
- Grafana: vizualizacija metrik s poudarkom na dolgoročnih trendih.
- Kibana: Omogoča vizualizacijo/iskanje po dnevniku, možnost globljega poglabljanja v določene dogodke.
- Zoom: v Zoomu je stalno delujoča »breakout room«. To inženirjem SRE omogoča hitro razpravo o dogodkih, ne da bi zapravljali dragoceni čas za ustvarjanje sobe in povezovanje udeležencev.
In mnogi drugi.
4. Spremljanje GitLab.com z GitLabom je ena sama točka napake
Če na GitLab.com pride do večjega izpada storitve, ne želimo, da bi to vplivalo na našo sposobnost reševanja težave. Lahko ga ustavite tako, da zaženete drugi primerek GitLab za upravljanje GitLab.com. Pravzaprav to že deluje pri nas: .
5. Nekaj funkcij, ki jih je treba dodati v GitLab
- , podobno kot Google Dokumenti. To bi pomagalo pri nalogah glede incidentov med dogodkom, pa tudi pri nalogah pri poročanju. V obeh primerih bo morda moralo več udeležencev dodati nekaj v realnem času.
- Več webhookov za opravila. Zmožnost izvajanja različnih korakov delovnega toka GitLab od znotraj bo pomagala zmanjšati vašo odvisnost od integracij Slack. Na primer, možnost dovolitve opozorila v PagerDuty prek ukaza s poševnico v težavi GitLab.
Zaključek
Inženirji SRE imajo težave z veliko zapletenostjo. Bilo bi super, če bi več izdelkov GitLab obravnavalo ta vprašanja. Delamo že na nekaterih dodatkih k izdelku, ki bodo olajšali zgoraj omenjene poteke dela. Podrobnosti so na voljo na .
Leta 2020 bomo razširili ekipo, da bi združili vse te odlične funkcije. Če vas zanima, preverite , s kakršnimi koli vprašanji pa se lahko obrnete na kogar koli iz naše ekipe.
Vir: www.habr.com