SRE inžinierius – praktikantas
Pirmiausia leiskite prisistatyti. aš - , grupės front-end inžinierius GitLab. Praėjusią savaitę man teko garbė stažuotis pas vieną iš mūsų budinčių SRE inžinierių. Tikslas buvo stebėti, kaip budintis pareigūnas kasdien reagavo į incidentus ir įgyti realios darbo patirties. Norėtume, kad mūsų inžinieriai geriau suprastų vartotojų poreikius Monitorius::Sveikata.
Savaitę turėjau visur sekti SRE inžinierių. Tai yra, aš dalyvavau perdavimo metu, stebėjau tuos pačius įspėjimo kanalus ir reagavau į incidentus, jei jie įvyko.
Incidentai
Per savaitę įvyko 2 incidentai.
1. Kriptomineris
GitLab.com trečiadienį pastebėjo šuolį „a, kurią sukėlė bandymai panaudoti bėgiko minutes kriptovaliutai iškasti. Įvykis buvo išspręstas naudojant mūsų pačių pažeidimų neutralizavimo įrankį, kuris sustabdo bėgiko užduotis ir ištrina su juo susietą projektą bei paskyrą.
Jei šis įvykis nebūtų pastebėtas, jį būtų užfiksavęs automatinis įrankis, tačiau šiuo atveju pažeidimą pirmiausia pastebėjo SRE inžinierius. Buvo sukurta incidento užduotis, bet informacija apie ją uždaryta.
2. Kanarų ir pagrindinių programų veikimo pablogėjimas
Incidentas įvyko dėl sulėtėjimo ir padažnėjusių klaidų Gitlab.com kanalo ir pagrindinėse žiniatinklio programose. Buvo pažeistos kelios Apdex vertės.
Atidaryti incidento užduotį:
Pagrindinės išvados
Štai keletas dalykų, kuriuos sužinojau per savo darbo savaitę.
1. Perspėjimai naudingiausi aptikus nukrypimus nuo normos.
Įspėjimai gali būti suskirstyti į keletą tipų:
- Įspėjimai, pagrįsti tam tikra slenksčio verte, pvz., „Per sekundę įvyko 10 5xx klaidų“.
- Įspėjimai, kuriuose slenkstis yra procentinė vertė, pvz., „5xx klaidų dažnis 10 % bendros užklausų apimties tam tikru metu“.
- Įspėjimai, pagrįsti istoriniu vidurkiu, pvz., „5xx klaidos ties 90 procentiliu“.
Paprastai tariant, 2 ir 3 tipai yra naudingesni budintiems SRE, nes atskleidžia nukrypimus nuo normos procese.
2. Daugelis įspėjimų niekada neperauga į incidentus.
SR inžinieriai susiduria su nuolatiniu įspėjimų srautu, kurių daugelis iš tikrųjų nėra svarbūs.
Taigi kodėl gi neapribojus įspėjimų tik tikrai svarbiais? Tačiau taikydami šį metodą galite neatpažinti ankstyvų simptomų, kurie pavers sniego gniūžtėmis tikra problema, gresiančia didele žala.
Budinčio SRE užduotis yra nustatyti, kurie įspėjimai iš tikrųjų rodo kažką rimto ir ar juos reikia eskaluoti ir su jais elgtis. Įtariu, kad taip yra ir dėl įspėjimų nelankstumo: būtų geriau, jei būtų keli lygiai arba „protingi“ įspėjimų konfigūravimo būdai pagal aukščiau aprašytą situaciją.
Funkcijos pasiūlymas:
3. Mūsų budintys SRE naudoja daug įrankių.
Vidinis:
- GitLab infrastruktūros projektas: čia veikia runbooks, pamainos / savaitės užduotys, reagavimo į incidentus užduotys.
- „GitLab“ problemos: taip pat stebimi tyrimai, peržiūros ir priežiūra.
- „GitLab“ etiketės: automatizavimo užduotys paleidžiamos naudojant konkrečias etiketes, kurias robotai naudoja užduočių veiklai stebėti.
Išorinis:
- PagerDuty: įspėjimai
- Slack: PagerDuty/AlertManager pranešimų srautas vyksta čia. Integracija su pasvirojo brūkšnio komandomis, kad būtų galima atlikti įvairias užduotis, tokias kaip įspėjimo uždarymas arba incidento eskalavimas.
- Grafana: metrikos vizualizacija, sutelkiant dėmesį į ilgalaikes tendencijas.
- Kibana: suteikia vizualizavimo / žurnalo paiešką, galimybę gilintis į konkrečius įvykius.
- Mastelio keitimas: „Mastelio keitimo“ programoje nuolat veikia „išsilaužimo kambarys“. Tai leidžia SRE inžinieriams greitai aptarti įvykius negaištant brangaus laiko kuriant kambarį ir susiejant dalyvius.
Ir daugelis daugelio kitų.
4. Stebėti GitLab.com naudojant GitLab yra vienas nesėkmės taškas
Jei GitLab.com nutrūksta paslauga, nenorime, kad tai paveiktų mūsų galimybes išspręsti problemą. Jį galima sustabdyti paleidus antrąjį „GitLab“ egzempliorių, skirtą „GitLab.com“ valdyti. Tiesą sakant, tai jau veikia mums: .
5. Keletas funkcijų, kurias vertėtų pridėti prie „GitLab“.
- , panašus į „Google“ dokumentus. Tai padėtų atlikti užduotis, susijusias su incidentais renginio metu, taip pat užduotis, susijusias su informavimu. Abiem atvejais keliems dalyviams gali tekti ką nors pridėti realiuoju laiku.
- Daugiau užduočių žiniatinklio kabliukų. Galimybė vykdyti skirtingus „GitLab“ darbo eigos veiksmus iš vidaus padės sumažinti jūsų priklausomybę nuo „Slack“ integracijų. Pavyzdžiui, galimybė leisti „PagerDuty“ įspėjimą naudojant pasvirojo brūkšnio komandą „GitLab“ problemos atveju.
išvada
SRE inžinieriams sunku susidoroti su daugybe sudėtingų dalykų. Būtų puiku pamatyti daugiau „GitLab“ produktų, sprendžiančių šias problemas. Jau dirbame su kai kuriais produkto papildymais, kurie palengvins aukščiau minėtas darbo eigas. Išsamią informaciją rasite adresu .
2020 m. plečiame komandą, kad sujungtume visas šias puikias funkcijas. Jei domina, prašome patikrinti , ir susisiekite su bet kuriuo mūsų komandos nariu, jei turite klausimų.
Šaltinis: www.habr.com