SRE-inĝeniero - staĝanto
Por komenci, mi prezentu min. mi - , fronta inĝeniero en la grupo GitLab. La pasintan semajnon, mi havis la privilegion esti staĝanto kun unu el niaj deĵorantaj SRE-inĝenieroj. La celo estis observi ĉiutage kiel la deĵoroficiro respondas al okazaĵoj kaj akiri realan laborsperton. Ni ŝatus, ke niaj inĝenieroj pli bone komprenu la bezonojn de uzantoj Monitoro::Sano.
Mi devis sekvi la SRE dum semajno. Tio estas, mi ĉeestis ĉe la translokigo de devo, observis la samajn atentajn kanalojn kaj respondis al okazaĵoj, se kaj kiam ili okazis.
Okazaĵoj
Okazis 2 okazaĵoj en semajno.
1. Cryptominer
GitLab.com registris salton en uzado merkrede 'a, kaŭzita de provoj uzi la minutojn de kuristo por minado de kripta monero. La okazaĵo estis ordigita per kutima mildiga ilo, kiu ĉesigas la taskojn de la kuristo kaj forigas la projekton kaj konton asociitan kun ĝi.
Se ĉi tiu evento ne estus rimarkita, aŭtomatigita ilo kaptintus ĝin, sed en ĉi tiu kazo, la SRE-inĝeniero unue rimarkis la malobservon. Okazaĵtasko estis kreita, sed la informoj pri ĝi estas fermitaj.
2. Efikeco-degenero de Kanariaj kaj Ĉefaj aplikoj
La okazaĵo estis nutrita de malrapidiĝoj kaj pliigitaj erarprocentoj en la kanariaj kaj ĉefaj TTT-aplikoj en Gitlab.com. Pluraj Apdex-valoroj estis malobservitaj.
Malfermu taskon laŭ okazaĵo:
Ŝlosilaj Trovoj
Jen kelkaj punktoj, kiujn mi lernis dum la semajno de devo.
1. Atentigoj estas plej utilaj kiam oni detektas deviojn de la normo.
Sciigoj povas esti dividitaj en plurajn tipojn:
- Atentigoj bazitaj sur certa sojlo, kiel "10 5xx-eraroj okazis je sekundo."
- Atentigoj kie la sojlo estas procenta valoro kiel ekzemple "5xx-eraroprocento per 10% de totalaj petoj en difinita tempo".
- Atentigoj bazitaj sur historia mezumo kiel ekzemple "5xx-eraroj en la 90-a procento".
Ĝenerale parolante, tipoj 2 kaj 3 estas pli utilaj por SREoj deĵorantaj, ĉar ili rivelas anomaliojn en la procezo.
2. Multaj atentigoj neniam eskaladas al incidentoj
SR-inĝenieroj traktas konstantan fluon de alarmoj, multaj el kiuj ne estas vere kritikaj.
Do kial ne limigi atentigojn nur al la vere gravaj? Kun ĉi tiu aliro, tamen, fruaj simptomoj de kio neĝbulos en realan problemon, kiu minacas gravan damaĝon, povas esti preteratentitaj.
La tasko de la deĵoranta SRE estas determini, kiuj atentigoj vere signifas ion seriozan, kaj ĉu ili devas esti pliigitaj kaj komencitaj esti ordigitaj. Mi suspektas, ke tio ankaŭ estas pro la malfleksebleco de atentigoj: estus pli bone, se ili enkondukus plurajn nivelojn aŭ "inteligentajn" manierojn personecigi atentigojn laŭ la situacio priskribita supre.
Karakterizaĵa sugesto:
3. Niaj SREoj uzas multajn ilojn
Interna:
- GitLab infraprojekto: Runbooks vivas ĉi tie, deĵor-/semajnaj transdonoj, okazaĵaj respondaj taskoj.
- Problemoj de GitLab: Enketo, informado kaj prizorgado ankaŭ estas spuritaj en temoj.
- Etikedoj de GitLab: Aŭtomatigaj taskoj estas ekigitaj de specifaj etikedoj, kiujn bots uzas por spuri taskan agadon.
Ekstera:
- PagerDuty Atentigoj
- Slack: Ĉi tie iras la mesaĝofluo de PagerDuty/AlertManager. Integriĝo kun oblikvaj komandoj por plenumi diversajn taskojn, kiel fermi alarmon aŭ eskaladi al okazaĵo.
- Grafana: bildigo de metrikoj kun fokuso sur longperspektivaj tendencoj.
- Kibana: donas bildigon/programserĉon, la kapablon fosi pli profunde en certajn eventojn.
- Zomo: Estas konstanta "komerca ĉambro" en Zoom. Ĉi tio permesas al SRE-oj rapide diskuti eventojn sen perdi altvaloran tempon kreante ĉambron kaj ligi membrojn.
Kaj multaj multaj aliaj.
4. Monitorado de GitLab.com kun GitLab estas ununura punkto de fiasko
Se GitLab.com spertas gravan servadon, ni ne volas, ke ĝi influu nian kapablon solvi la problemon. Ĝi povas esti haltigita rulante duan GitLab-instancon por administri GitLab.com. Fakte, ĉi tio jam funkcias por ni: .
5. Kelkaj funkcioj por konsideri aldoni al GitLab
- , simila al Google Docs. Ĉi tio helpus en okazaĵaj taskoj dum la evento, same kiel en informtaskoj. En ambaŭ kazoj, pluraj partoprenantoj eble bezonos aldoni ion en reala tempo samtempe.
- Pli da rethokoj por taskoj. La kapablo ruli diversajn laborfluajn paŝojn de GitLab de interne helpos redukti vian dependecon de Slack-integriĝoj. Ekzemple, la kapablo ebligi atentigon en PagerDuty per oblikva komando en afero de GitLab.
konkludo
SRE-inĝenieroj havas malfacilan tempon kun multaj kompleksaĵoj. Estus bone vidi pli da GitLab-produktoj trakti ĉi tiujn problemojn. Ni jam laboras pri kelkaj aldonoj al la produkto, kiuj plifaciligos la supre menciitajn laborfluojn. Partoj haveblas en .
En 2020, ni vastigas la teamon por kunigi ĉiujn ĉi tiujn bonegajn funkciojn. Se interesiĝas, bonvolu kontroli , kaj bonvolu kontakti iun el nia teamo kun ajnaj demandoj.
fonto: www.habr.com