SRE ingenieur - leerling
Om te begin, laat ek myself voorstel. ek - , front-end ingenieur in die groep GitLab. Verlede week het ek die voorreg gehad om 'n intern by een van ons aan diens SRE-ingenieurs te wees. Die doel was om daagliks waar te neem hoe die diensbeampte op insidente reageer en werklike werkservaring op te doen. Ons wil graag hê dat ons ingenieurs die behoeftes van gebruikers beter moet verstaan Monitor::Gesondheid.
Ek moes die SRE vir 'n week rond volg. Dit wil sê, ek was teenwoordig by die oordrag van diens, het dieselfde waarskuwingskanale waargeneem en op voorvalle gereageer, indien en wanneer dit plaasgevind het.
Voorvalle
Daar was 2 voorvalle in 'n week.
1. Cryptominer
GitLab.com het Woensdag 'n sprong in gebruik aangeteken 'a, veroorsaak deur pogings om hardloper se minute te gebruik vir kriptokurrency-ontginning. Die voorval is uitgesorteer met 'n pasgemaakte versagtingsinstrument wat die hardloper se take stop en die projek en rekening wat daarmee geassosieer word, uitvee.
As hierdie gebeurtenis nie opgemerk is nie, sou 'n outomatiese instrument dit gevang het, maar in hierdie geval het die SRE-ingenieur die oortreding eerste opgemerk. ’n Voorvaltaak is geskep, maar die inligting daarop is gesluit.
2. Prestasie-agteruitgang van Kanarie- en Hooftoepassings
Die voorval is aangevuur deur verlangsamings en verhoogde foutkoerse in die kanarie- en hoofwebtoepassings by Gitlab.com. Verskeie Apdex-waardes is oortree.
Oop taak volgens voorval:
Sleutelbevindinge
Hier is 'n paar punte wat ek tydens die week van diens geleer het.
1. Waarskuwings is die nuttigste wanneer afwykings van die norm opgespoor word.
Kennisgewings kan in verskeie tipes verdeel word:
- Waarskuwings gebaseer op 'n sekere drempel, soos "10 5xx-foute het per sekonde voorgekom."
- Waarskuwings waar die drempel 'n persentasiewaarde is, soos "5xx foutkoers per 10% van totale versoeke op 'n gegewe tyd".
- Waarskuwings gebaseer op 'n historiese gemiddelde soos "5xx foute in die 90ste persentiel".
Oor die algemeen is tipes 2 en 3 nuttiger vir SRE's aan diens, aangesien dit abnormaliteite in die proses openbaar.
2. Baie waarskuwings eskaleer nooit tot voorvalle nie
SR-ingenieurs hanteer 'n konstante stroom waarskuwings, waarvan baie nie regtig krities is nie.
Waarom dan nie waarskuwings beperk tot slegs die werklik belangrikes nie? Met hierdie benadering kan vroeë simptome egter oor die hoof gesien word van wat sal sneeubal in 'n werklike probleem wat groot skade dreig.
Die taak van die SRE aan diens is om te bepaal watter waarskuwings werklik iets ernstigs beteken, en of dit geëskaleer moet word en begin uitgesorteer moet word. Ek vermoed dit is ook te wyte aan die onbuigsaamheid van waarskuwings: dit sal beter wees as hulle verskeie vlakke of "slim" maniere instel om waarskuwings aan te pas volgens die situasie hierbo beskryf.
Kenmerkvoorstel:
3. Ons SRE's gebruik baie gereedskap
Intern:
- GitLab-infra-projek: Runbooks woon hier, skof/week-oorhandigings, insidentreaksietake.
- GitLab-kwessies: Ondersoek, ontlonting en instandhouding word ook in kwessies opgespoor.
- GitLab-etikette: Outomatiseringstake word geaktiveer deur spesifieke etikette wat bots gebruik om taakaktiwiteit op te spoor.
Ekstern:
- PagerDuty-waarskuwings
- Slack: Dit is waar die PagerDuty/AlertManager-boodskapvloei gaan. Integrasie met skuinsstreepbevele om 'n verskeidenheid take uit te voer, soos om 'n waarskuwing te sluit of te eskaleer na 'n voorval.
- Grafana: visualisering van metrieke met 'n fokus op langtermynneigings.
- Kibana: gee visualisering/logsoektog, die vermoë om dieper in sekere gebeurtenisse te delf.
- Zoom: Daar is 'n permanente "wegbreekkamer" in Zoom. Dit stel SRE's in staat om vinnig gebeure te bespreek sonder om kosbare tyd te mors om 'n kamer te skep en lede te koppel.
En baie baie ander.
4. Monitering van GitLab.com met GitLab is 'n enkele punt van mislukking
As GitLab.com 'n groot diensonderbreking ervaar, wil ons nie hê dit moet ons vermoë om die probleem op te los, beïnvloed nie. Dit kan gestop word deur 'n tweede GitLab-instansie uit te voer om GitLab.com te bestuur. Trouens, dit werk reeds vir ons: .
5. 'n Paar kenmerke om te oorweeg om by GitLab te voeg
- , soortgelyk aan Google Docs. Dit sal help met insidenttake tydens die geleentheid, sowel as in ontlontingstake. In beide gevalle sal verskeie deelnemers dalk iets intyds op een slag moet byvoeg.
- Meer webhooks vir take. Die vermoë om verskeie GitLab-werkvloeistappe van binne uit te voer, sal help om jou afhanklikheid van Slack-integrasies te verminder. Byvoorbeeld, die vermoë om 'n waarskuwing in PagerDuty te aktiveer via 'n skuinsstreep-opdrag in 'n GitLab-kwessie.
Gevolgtrekking
SRE-ingenieurs het 'n moeilike tyd met baie kompleksiteite. Dit sal wonderlik wees om te sien dat meer GitLab-produkte hierdie kwessies aanspreek. Ons werk reeds aan 'n paar toevoegings tot die produk wat die werkvloeie wat hierbo genoem word makliker sal maak. Onderdele is beskikbaar in .
In 2020 brei ons die span uit om al hierdie wonderlike kenmerke bymekaar te bring. Indien jy belangstel, kyk gerus , en kontak gerus iemand van ons span met enige vrae.
Bron: will.com