Kung mas kumplikado ang system, mas nagiging tinutubuan ito ng lahat ng uri ng mga alerto. At may pangangailangang tumugon sa parehong mga alertong ito, pagsama-samahin ang mga ito at tingnan ang mga ito. Sa tingin ko ito ay isang sitwasyon na pamilyar sa marami hanggang sa punto ng kaba.
Ang solusyon na tatalakayin ay hindi ang pinaka-hindi inaasahang, ngunit ang paghahanap ay hindi nagbabalik ng isang ganap na artikulo sa paksang ito.
Samakatuwid, napagpasyahan kong ibahagi ang karanasan ng FunCorp at pag-usapan kung paano nakaayos ang proseso ng tungkulin, sino ang tumatawag, bakit at paano mo makikita ang lahat ng ito.
Ano ang PagerDuty?
Kaya, upang malutas ang lahat ng mga problemang ito, nagsimula kaming maghanap ng isang maginhawang tool. Pagkatapos ng ilang paghahanap, pinili namin ang PagerDuty. Ang PD ay tila sa amin ay isang medyo kumpleto at maigsi na solusyon na may malaking bilang ng mga pagsasama at setting. Ano siya?
Sa madaling salita, ang PagerDuty ay isang platform sa pagpoproseso ng insidente na maaaring magproseso ng mga papasok na insidente sa pamamagitan ng iba't ibang integrasyon, mag-set up ng mga order sa tungkulin at pagkatapos ay alertuhan ang engineer na naka-duty depende sa antas ng insidente (sa mataas na antas - isang tawag, sa mababang antas - isang push mula sa application / SMS) .
Sino ang duty officer?
Ito marahil ang unang lugar upang simulan ang pag-set up ng PD.
Sa FunCorp, tulad ng ibang mga kumpanya, mayroong isang honorary position of duty officer. Ito ay ipinapadala mula sa inhinyero hanggang sa inhinyero isang beses sa isang araw. Mayroong tinatawag na una at pangalawang linya ng tugon sa isang alerto mula sa PagerDuty. Ipagpalagay na dumating ang isang alerto na may mataas na priyoridad, at kung 10 minuto pagkatapos ng tawag sa opisyal ng tungkulin mula sa unang linya ay walang reaksyon dito (ibig sabihin, hindi ito inilipat sa kinikilala o nalutas na katayuan), ang tawag ay mapupunta sa pangalawa. tungkuling inhinyero. Ito ay na-configure sa PagerDuty mismo sa pamamagitan ng Mga Patakaran sa Pagtaas.
Kung hindi tumugon ang pangalawang opisyal ng tungkulin, ibabalik ang abiso sa pangunahing sa duty officer.
Kaya, ang anumang papasok na mataas na priyoridad na alerto ay hindi maaaring manatiling hindi naproseso.
Ngayon tingnan natin kung saan nanggagaling ang mga insidente.
Anong mga integrasyon ang ginagamit natin?
Nakatanggap ang PD ng maraming iba't ibang insidente mula sa iba't ibang serbisyo. Kasalukuyan kaming may humigit-kumulang 25 na ganoong mga serbisyo, at para iproseso ang mga ito ay gumagamit kami ng ilang handa na pagsasama.
- Promiteyus
Ang pangunahing sistema ng pagkolekta ng sukatan ay Prometheus. Marami nang naisulat tungkol dito sa HabrΓ©, sasabihin ko lang na mayroon kaming ilan sa mga ito para sa iba't ibang kapaligiran: ang isa ay nangongolekta ng mga sukatan mula sa mga virtual machine at docker, isa pa mula sa mga serbisyo ng Amazon, ang pangatlo mula sa mga hardware machine. Pangunahing ginagamit ang Telegraf bilang tagaluwas ng sukatan.
Dito rin, sa tingin ko, malinaw ang lahat sa pamagat. Ang integration na ito ay ginagamit upang magpadala ng mga notification mula sa ilang script na isinagawa ng cron. Binibigyan ka ng PD ng isang tiyak na address kung saan ka magpadala ng mga liham. Kapag lumilikha ng isang serbisyo na may ganitong pagsasama, maaari kang magtakda ng mga priyoridad, sa anong pagkakasunud-sunod ng mga papasok na insidente ay ipoproseso, kung paano eksaktong lumikha ng isang alerto (para sa bawat papasok na liham, para sa isang papasok na liham + isang tiyak na panuntunan, atbp.).
- Walang ingat
Sa aking opinyon, isang napaka-kagiliw-giliw na pagsasama. May mga pagkakataong may nangyayari ngunit hindi saklaw ng mga pangyayari. Samakatuwid, nagdagdag kami ng pagsasama mula sa Slack upang lumikha ng isang insidente. Ibig sabihin, maaari kang sumulat sa corporate Slack /callofduty lahat ay mabagal at malapit nang masira at ipoproseso ito ng PD at ipapadala ang insidente sa duty engineer.
ginagawa namin:
Nakikita namin:
- API
Pagsasama ng HTTP. Sa katunayan, walang partikular na kawili-wili dito, isang kahilingan lamang sa POST na may katawan sa JSON na format. Halimbawa, isang bagay na kawili-wili: ginagamit namin ito para sa panlabas na pagsubaybay gamit . Sinusuri ng serbisyong ito ang accessibility ng aming mga site mula sa iba't ibang bahagi ng mundo. Sa kaso kapag nakatanggap kami ng hindi katanggap-tanggap na code ng pagtugon (halimbawa, 502), isang insidente ay nilikha at pagkatapos ay ang lahat ay sumusunod sa chain na inilarawan sa itaas. Ang StatusCake mismo ay may kakayahang subaybayan ang mga panloob na URL, SSL certificate o domain expiration.
- LibreNMS
Ito ay isa pang sistema ng pagsubaybay, maaari mong basahin ang higit pa tungkol dito sa kanilang website . Sa tulong nito, sinusubaybayan namin ang mga interface ng network at iDRAC mula sa mga server.
Nagkaroon din ng mga integrasyon tulad ng Datadog, CloudWatch. Maaari mong makita ang higit pa tungkol sa kung ano ang nangyari sa kanila .
Pagpapakita
Ang pangunahing sistema ng pag-uulat ng insidente ay Slack. Ang lahat ng mga insidente na dumarating sa PD ay isinulat sa isang espesyal na chat, at kung magbago ang kanilang katayuan, ito ay ipinapakita din sa chat.
Nang magkaroon ng pagkakataon na magpakita ng kapaki-pakinabang na data sa mga screen ng mga monitor na nakasabit sa kisame, bigla naming napagtanto na kami (sa departamento ng devops) ay walang maipakita sa kanila. Mayroong isang kahanga-hangang Grafana, ngunit hindi nito saklaw ang lahat, at ang mga empleyado ay tumutugon sa mga alerto, hindi sa mga tsart.
Pagkatapos ng masinsinan ngunit hindi matagumpay na paghahanap sa GitHub para sa isang maikli at nagbibigay-kaalaman na "board" para sa PD, nagpasya kaming magsulat ng sarili namin - kung ano lang ang kailangan namin. Bagama't noong una ay may ideya na ipakita ang mismong interface ng PD, mukhang mas hindi ito maginhawa.
Para maisulat ito, ang kailangan mo lang gawin ay kumuha ng susi mula sa isang PD na may mga read-only na karapatan.
At ito ang nakuha namin:
Ipinapakita ng screen ang kasalukuyang mga bukas na insidente, ang pangalan ng kasalukuyang engineer na naka-duty mula sa napiling iskedyul, at ang oras na walang mataas na priyoridad na insidente (ang panel na may mataas na priyoridad na insidente ay iha-highlight sa pula).
.
Bilang resulta, nakatanggap kami ng maginhawang dashboard para sa pagtingin sa lahat ng aming mga insidente. Ako ay natutuwa kung ang ilan sa inyo ay makitang kapaki-pakinabang ang aming karanasan.
Pinagmulan: www.habr.com