SRE inženieris - praktikants
Pirmkārt, ļaujiet man iepazīstināt ar sevi. es - , priekšgala inženieris grupā GitLab. Pagājušajā nedēļā man bija tas gods stažēties pie viena no mūsu dežūras SRE inženieriem. Mērķis bija novērot, kā dežurants ikdienā reaģēja uz incidentiem, un iegūt reālu pieredzi darbā. Mēs vēlamies, lai mūsu inženieri labāk izprastu lietotāju vajadzības Monitors::Veselība.
Man nedēļu vajadzēja visur sekot SRE inženierim. Tas ir, es biju klāt nodošanas brīdī, novēroju tos pašus brīdinājuma kanālus un reaģēju uz incidentiem, ja un kad tie notika.
Starpgadījumi
Nedēļas laikā bija 2 negadījumi.
1. Cryptominer
Trešdien vietnē GitLab.com tika novērots lietošanas pieaugums 'a, ko izraisa mēģinājumi izmantot skrējēja minūtes kriptovalūtas ieguvei. Incidents tika risināts, izmantojot mūsu pašu pārkāpumu neitralizēšanas rīku, kas aptur skrējēja uzdevumus un dzēš ar to saistīto projektu un kontu.
Ja šis notikums nebūtu pamanīts, to būtu pieķēris automatizēts rīks, taču šajā gadījumā SRE inženieris pārkāpumu pamanīja pirmais. Tika izveidots incidenta uzdevums, taču informācija par to ir slēgta.
2. Kanāriju un galveno lietojumu veiktspējas pasliktināšanās
Incidentu izraisīja palēninājums un palielināts kļūdu biežums kanārijas un galvenajās tīmekļa lietojumprogrammās vietnē Gitlab.com. Tika pārkāptas vairākas Apdex vērtības.
Atvērt incidenta uzdevumu:
Galvenie secinājumi
Šeit ir dažas lietas, ko uzzināju dežūras nedēļas laikā.
1. Brīdinājumi ir visnoderīgākie, atklājot novirzes no normas.
Brīdinājumus var iedalīt vairākos veidos:
- Brīdinājumi, kuru pamatā ir noteikta sliekšņa vērtība, piemēram, “10 5xx kļūdas sekundē”.
- Brīdinājumi, kuros slieksnis ir procentuālā vērtība, piemēram, “5xx kļūdu biežums uz 10% no kopējā pieprasījumu apjoma noteiktā laikā”.
- Brīdinājumi, kuru pamatā ir vēsturiskais vidējais rādītājs, piemēram, "5xx kļūdas pie 90. procentiles".
Vispārīgi runājot, 2. un 3. tips ir noderīgāks dežūrdaļām, jo tie atklāj novirzes no normas procesā.
2. Daudzi brīdinājumi nekad nepārvēršas par incidentiem.
SR inženieri nodarbojas ar pastāvīgu brīdinājumu plūsmu, no kuriem daudzi faktiski nav kritiski.
Tātad, kāpēc gan neierobežot savus brīdinājumus, iekļaujot tikai patiešām svarīgos? Tomēr, izmantojot šo pieeju, jūs, iespējams, neatpazīstat agrīnos simptomus, kas pārvēršas par reālu problēmu, kas apdraud lielu kaitējumu.
Dežūras SRE uzdevums ir noteikt, kuri brīdinājumi patiesībā norāda uz kaut ko nopietnu un vai tie ir jāpaplašina un jārisina. Man ir aizdomas, ka tas ir saistīts arī ar brīdinājumu neelastību: būtu labāk, ja būtu vairāki līmeņi vai “gudri” veidi, kā konfigurēt brīdinājumus atbilstoši iepriekš aprakstītajai situācijai.
Funkcijas ieteikums:
3. Mūsu dežurējošie SRE izmanto daudz rīku.
Iekšējā:
- GitLab infra projekts: šeit darbojas runbooks, maiņu/nedēļu uzdevumi, incidentu reaģēšanas uzdevumi.
- GitLab problēmas. Problēmas tiek izsekotas arī izmeklēšanai, pārskatiem un uzturēšanai.
- GitLab etiķetes: automatizācijas uzdevumi tiek palaisti, izmantojot īpašas etiķetes, kuras robotprogrammatūra izmanto, lai izsekotu uzdevumu aktivitātēm.
Ārējais:
- PagerDuty: brīdinājumi
- Slack: PagerDuty/AlertManager ziņojumu plūsma notiek šeit. Integrācija ar slīpsvītras komandām, lai veiktu dažādus uzdevumus, piemēram, aizvērt brīdinājumu vai eskalēt līdz incidentam.
- Grafana: metrikas vizualizācija, koncentrējoties uz ilgtermiņa tendencēm.
- Kibana: sniedz vizualizāciju/žurnālu meklēšanu, iespēju iedziļināties konkrētos notikumos.
- Tālummaiņa: Tālummaiņā pastāvīgi darbojas “izdalīšanās telpa”. Tas ļauj SRE inženieriem ātri apspriest notikumus, netērējot vērtīgo laiku telpas izveidei un dalībnieku saistīšanai.
Un daudzi daudzi citi.
4. Vietnes GitLab.com uzraudzība, izmantojot GitLab, ir viens neveiksmes punkts
Ja vietnē GitLab.com rodas liels pakalpojuma pārtraukums, mēs nevēlamies, lai tas ietekmētu mūsu spēju atrisināt problēmu. To var apturēt, palaižot otru GitLab gadījumu, lai pārvaldītu GitLab.com. Patiesībā tas mums jau darbojas: .
5. Dažas funkcijas, kas jāapsver pievienot GitLab
- , līdzīgi kā Google dokumenti. Tas palīdzētu veikt uzdevumus par incidentiem pasākuma laikā, kā arī uzdevumus saistībā ar pārskatu sagatavošanu. Abos gadījumos vairākiem dalībniekiem var būt nepieciešams kaut ko pievienot reāllaikā.
- Vairāk tīmekļa aizķeru uzdevumiem. Iespēja palaist dažādas GitLab darbplūsmas darbības no iekšpuses palīdzēs samazināt jūsu paļaušanos uz Slack integrācijām. Piemēram, iespēja atļaut brīdinājumu programmā PagerDuty, izmantojot slīpsvītras komandu GitLab problēmas gadījumā.
Secinājums
SRE inženieriem ir grūti ar daudzām sarežģītībām. Būtu lieliski redzēt vairāk GitLab produktu, kas risina šīs problēmas. Mēs jau strādājam pie dažiem produkta papildinājumiem, kas atvieglos iepriekš minētās darbplūsmas. Sīkāka informācija pieejama vietnē .
2020. gadā mēs paplašinām komandu, lai apvienotu visas šīs lieliskās funkcijas. Ja interesē, lūdzu, pārbaudiet , un droši sazinieties ar jebkuru mūsu komandas darbinieku, ja jums ir kādi jautājumi.
Avots: www.habr.com