Kuidas ma olin nädal aega SRE inseneri praktikant. Kohustus tarkvarainseneri pilgu läbi

Kuidas ma olin nädal aega SRE inseneri praktikant. Kohustus tarkvarainseneri pilgu läbi

SRE insener – praktikant

Esiteks lubage mul end tutvustada. mina - @tristan.loe, grupi esiotsa insener Monitor::Tervis GitLab. Eelmisel nädalal oli mul au stažeerida ühe meie SRE valveinseneri juures. Eesmärgiks oli jälgida, kuidas valveametnik igapäevaselt intsidentidele reageeris ning saada töökohal reaalseid kogemusi. Soovime, et meie insenerid mõistaksid paremini kasutajate vajadusi funktsioonid Monitor::Tervis.

Pidin nädal aega igal pool SRE inseneri järgi minema. See tähendab, et olin üleandmisel kohal, jälgisin samu häirekanaleid ja reageerisin intsidentidele, kui ja millal need aset leidsid.

Juhtumid

Nädala jooksul oli 2 juhtumit.

1. Krüptokaevandaja

GitLab.com nägi kolmapäeval kasutuse hüppelist kasvu GitLabi jooksja‘a, mille põhjuseks on katsed kasutada jooksja minuteid krüptovaluuta kaevandamiseks. Juhtumi lahendamiseks kasutati meie enda rikkumiste neutraliseerimise tööriista, mis peatab jooksja ülesanded ning kustutab sellega seotud projekti ja konto.

Kui seda sündmust poleks märgatud, oleks automaattööriist selle kinni püüdnud, kuid antud juhul märkas rikkumist esimesena SRE insener. Juhtumiülesanne loodi, kuid teave selle kohta on suletud.

2. Canary ja peamiste rakenduste jõudluse halvenemine

Juhtumi põhjustasid aeglustumised ja vigade sagenemine Gitlab.com-i kanaari ja peamistes veebirakendustes. Mitmeid Apdexi väärtusi rikuti.

Avage intsidendi ülesanne: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Peamised järeldused

Siin on mõned asjad, mida ma oma nädala jooksul valves olles õppisin.

1. Hoiatused on kõige kasulikumad normist kõrvalekallete tuvastamisel.

Hoiatused võib jagada mitmeks tüübiks:

  • Teatud läviväärtusel põhinevad märguanded, näiteks „10 5xx viga sekundis”.
  • Märguanded, mille lävi on protsentuaalne väärtus, näiteks „5xx vigade sagedus 10% päringute kogumahust antud ajahetkel”.
  • Hoiatused, mis põhinevad ajaloolisel keskmisel, näiteks "5xx vead 90. protsentiili juures".

Üldiselt on tüübid 2 ja 3 kasulikumad valves olevate SRE-de jaoks, kuna need näitavad protsessi käigus kõrvalekaldeid normist.

2. Paljud hoiatused ei laiene kunagi vahejuhtumiteks.

SR-i insenerid tegelevad pideva hoiatustevooga, millest paljud ei ole tegelikult kriitilised.

Miks mitte piirata oma hoiatusi ainult tõeliselt oluliste hoiatustega? Selle lähenemisviisi puhul ei pruugi te aga ära tunda varaseid sümptomeid, mis võivad lumepallist saada tõeliseks probleemiks, mis ähvardab suurt kahju.

Valve SRE ülesanne on kindlaks teha, millised hoiatused tegelikult viitavad millelegi tõsisele ning kas neid on vaja eskaleerida ja nendega tegeleda. Kahtlustan, et selle põhjuseks on ka hoiatuste paindumatus: parem oleks, kui hoiatuste konfigureerimiseks vastavalt ülalkirjeldatud olukorrale oleks mitu taset või “nutikaid” viise.

Funktsiooni soovitus: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Meie valves olevad SRE-d kasutavad palju tööriistu.

Sisemine:

  • GitLabi infraprojekt: siin asuvad käsiraamatud, vahetuste/nädalaste ülesanded, intsidentidele reageerimise ülesanded.
  • GitLabi probleemid: probleemides jälgitakse ka uurimisi, ülevaatusi ja hooldust.
  • GitLabi sildid: automatiseerimistoimingud käivitatakse konkreetsete siltide abil, mida robotid kasutavad ülesannete tegevuse jälgimiseks.

Väline:

  • PagerDuty: hoiatused
  • Slack: PagerDuty/AlertManageri sõnumivoog läheb siia. Integreerimine kaldkriipsu käskudega mitmesuguste toimingute tegemiseks, nagu hoiatuse sulgemine või intsidendini eskaleerimine.
  • Grafana: mõõdikute visualiseerimine, keskendudes pikaajalistele trendidele.
  • Kibana: annab visualiseerimise/logiotsingu, võime süveneda konkreetsetesse sündmustesse.
  • Suum: Suumis on pidevalt töötav "lahutusruum". See võimaldab SRE inseneridel sündmusi kiiresti arutada, raiskamata väärtuslikku aega ruumi loomisele ja osalejate ühendamisele.

Ja paljud paljud teised.

4. GitLab.com jälgimine GitLabiga on üksainus tõrkepunkt

Kui veebisaidil GitLab.com tekib suur teenusekatkestus, ei taha me, et see mõjutaks meie võimet probleemi lahendada. Selle saab peatada, käivitades GitLab.com-i haldamiseks teise GitLabi eksemplari. Tegelikult see meie jaoks juba töötab: https://ops.gitlab.net/.

5. Mõned funktsioonid, mida GitLabi lisada

  • Mitme kasutaja ülesannete redigeerimine, mis sarnaneb Google Docsiga. See aitaks täita ülesandeid, mis on seotud sündmuse ajal juhtunud juhtumitega, samuti ülesandeid, mis on seotud ülevaatega. Mõlemal juhul võib mitmel osalejal olla vaja midagi reaalajas lisada.
  • Rohkem veebihaake ülesannete jaoks. Võimalus käitada erinevaid GitLabi töövoo samme seestpoolt aitab vähendada teie sõltuvust Slacki integratsioonidest. Näiteks võimalus lubada PagerDuty märguannet kaldkriipsuga käsuga GitLabi probleemis.
    Järeldus

SRE inseneridel on palju keerulisi probleeme. Oleks tore näha rohkem GitLabi tooteid, mis neid probleeme lahendaks. Töötame juba mõne toote täienduse kallal, mis muudavad ülalmainitud töövood lihtsamaks. Üksikasjad saadaval aadressil Opsi tootevisioon.

2020. aastal laiendame meeskonda, et viia kõik need suurepärased funktsioonid kokku. Huvi korral palun vaadake vabu kohtija küsimuste korral võtke julgelt ühendust kõigi meie meeskonnaliikmetega.

Allikas: www.habr.com

Lisa kommentaar