SRE yngenieur - trainee
Om te begjinnen, lit my mysels foarstelle. ik - , front-end yngenieur yn 'e groep GitLab. Ferline wike hie ik it foarrjocht om in stazjêre te wêzen by ien fan ús SRE-yngenieurs op plicht. It doel wie om deistich te observearjen hoe't de tsjinstoffisier reagearret op ynsidinten en echte wurkûnderfining op te dwaan. Wy wolle graach dat ús yngenieurs de behoeften fan brûkers better begripe Monitor :: Health.
Ik moast de SRE in wike folgje. Dat is, ik wie oanwêzich by de oerdracht fan plicht, observearre deselde warskôgingskanalen en reagearre op ynsidinten, as en wannear se barde.
Ynsidinten
Der wiene 2 ynsidinten yn in wike.
1. Kryptominer
GitLab.com registrearre woansdei in sprong yn gebrûk 'a, feroarsake troch besykjen om runner's minuten te brûken foar mynbou fan cryptocurrency. It ynsidint waard oplost mei in proprietêr mitigaasje-ark dat de taken fan 'e runner stopet en it projekt en it akkount wisket dat dermei ferbûn is.
As dit barren net opmurken wie, soe in automatisearre ark it hawwe fongen, mar yn dit gefal hat de SRE-yngenieur de oertreding earst opmurken. In ynsidint taak is makke, mar de ynformaasje oer it is sluten.
2. Prestaasje degradaasje fan Kanaryske en Main applikaasjes
It ynsidint waard oandreaun troch fertragingen en ferhege flatersifers yn 'e kanaryske en haadwebapplikaasjes op Gitlab.com. Ferskate Apdex-wearden waarden skeind.
Iepen taak per ynsidint:
Key Findings
Hjir binne in pear punten dy't ik learde yn 'e wike fan plicht.
1. Alerts binne meast brûkber by it opspoaren fan ôfwikingen fan 'e noarm.
Notifikaasjes kinne wurde ferdield yn ferskate soarten:
- Alerts basearre op in bepaalde drompel, lykas "10 5xx flaters barde per sekonde."
- Alerts wêrby't de drompel in persintaazjewearde is lykas "5xx flaterrate per 10% fan totale oanfragen op in opjûne tiid".
- Alerts basearre op in histoarysk gemiddelde lykas "5xx flaters yn it 90e percentile".
Yn 't algemien binne typen 2 en 3 brûkber foar SRE's yn tsjinst, om't se abnormaliteiten yn it proses litte sjen.
2. In protte warskôgings eskalearje nea ta ynsidinten
SR-yngenieurs omgean mei in konstante stream fan warskôgings, wêrfan in protte net echt kritysk binne.
Dus wêrom warskôgings net beheine ta allinich de echt wichtigen? Mei dizze oanpak, lykwols, iere symptomen fan wat sil sniebal yn in echte probleem dat driget grutte skea meie wurde oersjoen.
De taak fan de SRE yn tsjinst is om te bepalen hokker warskôgings echt wat serieus betsjutte, en oft se moatte wurde eskalearre en begon te sortearjen. Ik tink dat dit ek komt troch de ûnfleksibiliteit fan warskôgings: it soe better wêze as se ferskate nivo's of "tûke" manieren ynfiere om warskôgingen oan te passen neffens de hjirboppe beskreaune situaasje.
Feature suggestje:
3. Us SRE's brûke in protte ark
Ynterne:
- GitLab infra projekt: Runbooks wenje hjir, shift / wike oerdracht, ynsidint antwurd taken.
- GitLab-problemen: Undersyk, debriefing, en ûnderhâld wurde ek folge yn problemen.
- GitLab-labels: Automatisearringstaken wurde trigger troch spesifike labels dy't bots brûke om taakaktiviteit te folgjen.
Ekstern:
- PagerDuty Alerts
- Slack: Dit is wêr't de PagerDuty/AlertManager-berjochtstream giet. Yntegraasje mei slash-kommando's om in ferskaat oan taken út te fieren, lykas in warskôging slute of eskalearje nei in ynsidint.
- Grafana: fisualisaasje fan metriken mei in fokus op lange termyn trends.
- Kibana: jout fisualisaasje / log sykje, de mooglikheid om te graven djipper yn bepaalde eveneminten.
- Zoom: D'r is in permaninte "breakout room" yn Zoom. Hjirmei kinne SRE's eveneminten fluch besprekke sûnder kostbere tiid te fergrieme oan it meitsjen fan in keamer en leden te keppeljen.
En in protte oaren.
4. Kontrolearje GitLab.com mei GitLab is in inkeld punt fan mislearring
As GitLab.com in grutte tsjinstferliening ûnderfynt, wolle wy net dat it ús fermogen beynfloedet om it probleem op te lossen. It kin stoppe wurde troch in twadde GitLab-eksimplaar út te fieren om GitLab.com te behearjen. Eins wurket dit al foar ús: .
5. In pear funksjes te beskôgje tafoegjen oan GitLab
- , fergelykber mei Google Docs. Dit soe helpe by ynsidinttaken tidens it evenemint, lykas by debriefingtaken. Yn beide gefallen moatte ferskate dielnimmers miskien wat yn realtime tagelyk tafoegje.
- Mear webhooks foar taken. De mooglikheid om ferskate GitLab-workflowstappen fan binnen út te fieren sil helpe om jo ôfhinklikens fan Slack-yntegraasjes te ferminderjen. Bygelyks de mooglikheid om in warskôging yn PagerDuty yn te skeakeljen fia in slash-kommando yn in GitLab-kwestje.
konklúzje
SRE-yngenieurs hawwe in hurde tiid mei in protte kompleksiteiten. It soe geweldich wêze om te sjen dat mear GitLab-produkten dizze problemen oanpakke. Wy wurkje al oan guon tafoegings oan it produkt dy't de hjirboppe neamde workflows makliker meitsje. Dielen binne beskikber yn .
Yn 2020 wreidzje wy it team út om al dizze geweldige funksjes byinoar te bringen. As jo ynteressearre binne, kontrolearje dan asjebleaft , en fiel frij om kontakt op mei immen fan ús team mei alle fragen.
Boarne: www.habr.com