SRE engineer - trainee
Una, hayaan mo akong magpakilala. ako - , front-end engineer sa grupo GitLab. Noong nakaraang linggo nagkaroon ako ng karangalan na mag-interning sa isa sa aming on-call na SRE engineer. Ang layunin ay upang obserbahan kung paano tumugon ang on-duty na opisyal sa mga insidente sa pang-araw-araw na batayan at makakuha ng karanasan sa totoong buhay sa trabaho. Nais naming mas maunawaan ng aming mga inhinyero ang mga pangangailangan ng user Monitor::Kalusugan.
Kinailangan kong sundan ang inhinyero ng SRE kahit saan sa loob ng isang linggo. Ibig sabihin, naroroon ako sa handover, sinusubaybayan ang parehong mga channel ng alerto at tumugon sa mga insidente kung at kailan nangyari ang mga ito.
Mga pangyayari
Mayroong 2 insidente sa loob ng isang linggo.
1. Cryptominer
Ang GitLab.com ay nakakita ng tumalon sa paggamit noong Miyerkules 'a, sanhi ng mga pagtatangka na gamitin ang mga minuto ng runner upang minahan ng cryptocurrency. Ang insidente ay hinarap gamit ang sarili naming tool sa neutralisasyon ng paglabag, na humihinto sa mga gawain ng runner at nagde-delete sa proyekto at account na nauugnay dito.
Kung hindi napansin ang kaganapang ito, isang automated na tool ang makakahuli nito, ngunit sa kasong ito, unang napansin ng inhinyero ng SRE ang paglabag. Nagawa ang isang gawain sa insidente, ngunit sarado ang impormasyon tungkol dito.
2. Pagbaba ng pagganap ng Canary at Main application
Ang insidente ay sanhi ng pagbagal at pagtaas ng dalas ng mga error sa canary at pangunahing mga web application sa Gitlab.com. Ilang mga halaga ng Apdex ang nilabag.
Buksan ang gawain ng insidente:
Mga Pangunahing Paghahanap
Narito ang ilang mga bagay na natutunan ko sa aking linggo sa duty.
1. Ang mga alerto ay pinaka-kapaki-pakinabang kapag nakakita ng mga paglihis mula sa pamantayan.
Ang mga alerto ay maaaring nahahati sa ilang uri:
- Mga alerto batay sa isang partikular na halaga ng threshold, gaya ng "10 5xx error ang naganap bawat segundo."
- Mga alerto kung saan ang threshold ay isang porsyento na halaga gaya ng "dalas ng 5xx na error sa bawat 10% ng kabuuang dami ng mga kahilingan sa isang partikular na oras."
- Mga alerto batay sa dating average gaya ng "5xx errors at 90th percentile."
Sa pangkalahatan, ang mga uri 2 at 3 ay mas kapaki-pakinabang para sa mga SRE na naka-duty, dahil nagpapakita sila ng mga paglihis mula sa pamantayan sa proseso.
2. Maraming mga alerto ang hindi kailanman nauuwi sa mga insidente.
Ang mga inhinyero ng SR ay nakikitungo sa patuloy na daloy ng mga alerto, na marami sa mga ito ay hindi aktwal na kritikal.
Kaya bakit hindi limitahan ang iyong mga alerto sa mga talagang mahalaga lang? Sa ganitong paraan, gayunpaman, maaaring hindi mo makilala ang mga unang sintomas ng kung ano ang magiging snowball sa isang tunay na problema na nagbabanta ng malaking pinsala.
Ang on-call na trabaho ng SRE ay upang matukoy kung aling mga alerto ang aktwal na nagpapahiwatig ng isang bagay na seryoso, at kung kailangan nilang palakihin at harapin. Inaasahan ko na ito ay dahil din sa kawalan ng kakayahang umangkop ng mga alerto: mas mabuti kung mayroong ilang mga antas o "matalinong" paraan upang i-configure ang mga alerto alinsunod sa sitwasyong inilarawan sa itaas.
Mungkahi sa Tampok:
3. Ang aming mga SRE na naka-duty ay gumagamit ng maraming kasangkapan.
Panloob:
- GitLab infra project: dito nakatira ang mga runbook, shift/week assignment, mga gawain sa pagtugon sa insidente.
- Mga isyu sa GitLab: Ang mga pagsisiyasat, pagsusuri, at pagpapanatili ay sinusubaybayan din sa mga isyu.
- Mga label ng GitLab: Ang mga gawain sa automation ay inilunsad gamit ang mga partikular na label, na ginagamit ng mga bot upang subaybayan ang aktibidad ng gawain.
Panlabas:
- PagerDuty: Mga Alerto
- Slack: Ang daloy ng mensahe ng PagerDuty/AlertManager ay napupunta dito. Pagsasama sa mga slash na utos upang magsagawa ng iba't ibang gawain, tulad ng pagsasara ng alerto o pagdami sa isang insidente.
- Grafana: visualization ng mga sukatan na may pagtuon sa mga pangmatagalang trend.
- Kibana: Nagbibigay ng visualization/log search, kakayahang maghukay ng mas malalim sa mga partikular na kaganapan.
- Zoom: Mayroong patuloy na tumatakbong "breakout room" sa Zoom. Nagbibigay-daan ito sa mga inhinyero ng SRE na mabilis na talakayin ang mga kaganapan nang hindi nag-aaksaya ng mahalagang oras sa paglikha ng silid at pag-uugnay ng mga kalahok.
At marami pang iba.
4. Ang pagsubaybay sa GitLab.com gamit ang GitLab ay isang punto ng pagkabigo
Kung ang GitLab.com ay nakakaranas ng isang malaking pagkawala ng serbisyo, hindi namin nais na maapektuhan nito ang aming kakayahang lutasin ang isyu. Maaari itong ihinto sa pamamagitan ng paglulunsad ng pangalawang pagkakataon sa GitLab upang pamahalaan ang GitLab.com. Sa katunayan, ito ay gumagana na para sa amin: .
5. Ilang feature na dapat isaalang-alang na idagdag sa GitLab
- , katulad ng Google Docs. Makakatulong ito sa mga gawain sa mga insidente sa panahon ng isang kaganapan, gayundin sa mga gawain sa debriefing. Sa parehong mga kaso, maaaring kailanganin ng ilang kalahok na magdagdag ng isang bagay sa real time.
- Higit pang mga webhook para sa mga gawain. Ang kakayahang magpatakbo ng iba't ibang mga hakbang sa daloy ng trabaho sa GitLab mula sa loob ay makakatulong na mabawasan ang iyong pag-asa sa mga pagsasama ng Slack. Halimbawa, ang kakayahang payagan ang isang alerto sa PagerDuty sa pamamagitan ng isang slash command sa isang isyu sa GitLab.
Konklusyon
Ang mga inhinyero ng SRE ay nahihirapan sa maraming kumplikado. Magiging mahusay na makakita ng higit pang mga produkto ng GitLab na tumutugon sa mga isyung ito. Gumagawa na kami ng ilang karagdagan sa produkto na magpapadali sa mga daloy ng trabaho na binanggit sa itaas. Available ang mga detalye sa .
Papalawakin namin ang team sa 2020 para pagsama-samahin ang lahat ng magagandang feature na ito. Kung interesado, mangyaring tingnan , at huwag mag-atubiling makipag-ugnayan sa sinuman sa aming koponan para sa anumang mga katanungan.
Pinagmulan: www.habr.com