Kuidas ma nädal aega olin SRE-inseneri praktikant. Vahetuse tavadega tarkvarainseneri silmade läbi

SRE-insener - praktikant

Alustuseks laske mul end tutvustada. Mina olen @tristan.read, esifront-end insener grupis Monitor::Health GitLab'is. Eelmisel nädalal sain võimaluse olla praktikant meie vahetuses olevate SRE-inseneride seas. Eesmärk oli iga päev jälgida, kuidas vahetuse insener reageerib intsidentidele ning koguda reaalsest töökogemust. Soovime, et meie insenerid mõistaksid paremini kasutajate vajadusi funktsioonide Monitor::Health.

Pidin nädal aega järgima SRE-inseneri. See tähendab, et olin kohal vahetuse üleandmisel, jälgisin samu teatekanaleid ja reageerisin intsidentidele, kui neid ette tuli.

Intsidentide

Nädala jooksul toimus 2 intsident.

1. Krüptomüntide kaevandus

Kolmapäeval registreeriti GitLab.com'is hüppeline kasv kasutuses GitLab Runner'ikrüptomündide kaevandamiseks runner'i minutite hälbimise tõttu. Intsidendiga tegeleti meie enda rikkumiste neutraliseerimise tööriista abil, mis peatab runner'i ülesanded ja eemaldab sellega seotud projekti ja konto.

Kui seda sündmust ei oleks märgatud, oleks automaatne tööriist selle üles leidnud, kuid antud juhul märkas rikkumist esimesena SRE-insener. Intsidendi kohta loodi ülesanne, kuid selle teave on suletud.

2. Rakenduste Canary ja Main jõudluse langus

Intsident tekitas viivitusi ja tõusnud veaarvu frekventsia canary ja main veebirakendustes GitLab.com. Rikkumisi toimus mitmes Apdexi väärtuses.

Avatud ülesanne intsidenti kohta: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Olulised järeldused

Siin on mõned punktid, mida ma nägin nädalase vahetuse ajal.

1. Teavitused on kõige kasulikud, kui nad kinni püüavad normidest kõrvalekaldeid.

Teavitused saab jagada mitmeks tüübiks:

• Teavitused, mis põhinevad kindlal lävendi väärtusel, nagu "toimus 10 5xx viga sekundis".
• Teavitused, kus lävi on protsentuaalne väärtus, nagu "5xx vigade sagedus 10% üldisest päringute mahust määratud ajavahemikus".
• Teavitused, mis põhinevad ajaloolisel keskmisel väärtusel, nagu "5xx vead 90. protsendilisest".

Üldiselt on 2. ja 3. tüüpi teavitused vahetuste SRE-de jaoks kasulikumad, kuna need avavad protsessis normidest kõrvalekaldeid.

2. Paljusid teavitusi ei edastata intsidentidena

SRE-insenerid tegelevad pideva teavituste vooga, millest paljusid ei ole tegelikult kriitilised.

Miks mitte piirduda teavitustega, mis on tõeliselt olulised? Sellise lähenemisega võib siiski jääda tuvastamata varased sümptomid, mis võivad lumehelbena kasvades muutuda tõeliseks probleemiks, mis toob kaasa suuri kahjusid.

SRE dežuurimise ülesanne on määrata, millised teavitused räägivad tõeliselt millestki tõsisest ja kas neid tuleks eskaleerida ning hakkama saama. Kahtlustan, et see tuleneb ka teavituste jäikusest: oleks parem, kui sisse viidaks mitmeid tasemeid või 'nutikaid' viise teavituste seadistamiseks vastavalt ülaltoodud olukorrale.

Funktsioonide pakkumine: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Meie dežuurivad SRE-d kasutavad palju tööriistu

Sisemised:

• GitLab infra projekt: siin elavad Runbook’id, dežuurimise vahetused nädalaks, ülesanded intsidendi vastamiseks.
• GitHubi probleemid: uurimine, arutelu ja hooldus jälgitakse samuti ülesannetes.
• GitLab’i sildid: automatiseerimise ülesanded käivituvad teatud silte järgi, mille alusel robotid jälgivad ülesannete aktiivsust.

Välised:

• PagerDuty: teavitused
• Slack: siia suunatakse PagerDuty / AlertManager sõnumite voog. Integreerimine slashes-käskudega, et täita mitmesuguseid ülesandeid, näiteks: sulgeda teavitus või eskaleerida intsidendiks.
• Grafana: metrikate visualiseerimine keskendudes pikaajalistele trendidele.
• Kibana: annab visualiseerimise / otsingu logis, võimaluse süveneda konkreetsetesse sündmustesse.
• Zoom: on pidevalt töötav 'arutelu tuba' Zoomis. See võimaldab SRE-inseneridel kiiresti arutada sündmusi, raiskamata väärtuslikku aega ruumi ja osalejate linkide loomisele.

Ja palju, palju muud.

4. GitLab.com jälgimine GitLab'i abil on ühtne tõrke punkt

Kui GitLab.com-il esineb suur teenuste tõrge, ei tahaks, et see mõjutaks meie võimet probleemi lahendada. Seda saab leevendada, käivitades teise GitLabi instantsi GitLab.com-i haldamiseks. Tegelikult töötab see meil juba: https://ops.gitlab.net/.

5. Mitmeid funktsioone, mida võiks kaaluda GitLabi lisamiseks

• Mitme kasutajaga ülesannete redigeerimine, sarnane Google Docs’ile. See aitaks intsidentide ülesannete puhul sündmuse käigus ning ka arutelude ülesannete puhul. Mõlemas olukorras võib mitmel osalejal olla vajadus lisada midagi reaalajas.
• Rohkem veebihukke ülesannete jaoks. Erinevate GitLabi töövoo samme seesmine käivitamine aitab vähendada sõltuvust Slacki integratsioonidest. Näiteks võimalus häired PagerDuty-s lubada läbi GitLabi ülesande slashi käsu.
  Kokkuvõte

SRE-inseneridel on palju väljakutseid. Oleks tore näha rohkem GitLabi tooteid nende probleemide lahendamiseks. Meie töötame juba mõnede tootetäienduste kallal, mis lihtsustavad ülalnimetatud töövooge. Üksikasjad on saadaval Ops Product Vision jaotises.

Aastal 2020 laiendame meeskonda, et koguda kõik need suurepärased funktsioonid. Kui olete huvitatud, tutvuge palun tööpakkumistega, ja ärge kartke ühendust võtta kellegagi meie meeskonnast mistahes küsimustes.

Allikas: habr.com