Sa më e ndërlikuar është sistemi, aq më shumë ai mbushet me alerta të ndryshme. Dhe lind nevoja për të reaguar ndaj këtyre alerteve, për t'i agreguar ato dhe për t'i visualizuar. Mendoj se kjo situatë i është njohur shumëkujt deri në nervozizëm.
Zgjidhja që do të diskutojmë nuk është surprizuese, por kërkimi për një artikull të plotë mbi këtë temë nuk jep rezultate.
Prandaj vendosa të ndaj përvojën e FunCorp dhe të flas për mënyrën se si është ndërtuar procesi i shërbimeve, kush i telefono, pse dhe si mund të shikohet gjithë kjo.
Çfarë është PagerDuty?
Pra, për të zgjidhur të gjitha këto probleme, filluam të kërkojmë një mjet të përshtatshëm. Pas një kërkimi të shkurtër, e zgjodhëm PagerDuty. PD na duket si një zgjidhje e plotë dhe e thjeshtë, me një numër të madh integrimesh dhe konfigurimesh. Çfarë përfaqëson ajo?
Nëse përshkruhet shkurt, PagerDuty është një platformë për menaxhimin e incidenteve, e cila mund të trajtojë incidentet që vijnë përmes integrimeve të ndryshme, të organizojë rendin e shërbimeve dhe më pas të kryejë alarmin për inxhinierin e shërbimit në varësi të nivelit të incidentit (në nivel të lartë — telefonatë, në nivel të ulët — njoftim nga aplikacioni/sms).
Kush është shërbimi i natës?
Ndoshta, kjo është gjëja e parë që duhet të filloni me konfigurimin e PD.
Në FunCorp, ashtu si në kompanitë e tjera, ekziston një pozicion ndihmës që njihet si "rënda". Ajo kalon nga inxhinieri te inxhinieri çdo 24 orë. Ka një "linjë të parë" dhe një "linjë të dytë" për të reaguar ndaj alerteve nga PagerDuty. Supozoni se një alarm me prioritet të lartë arrin, dhe nëse pas 10 minutash nga telefonata me ndihmësin e linjës së parë nuk ka asnjë reagim (dmth. nuk është kaluar në statusin e pranuar ose të zgjidhur), telefonata kalon te inxhinieri ndihmës i dytë. Ky proces konfigurimi bëhet në vetë PagerDuty përmes politikave të eskalimit.
Nëse as ndihmësi i dytë nuk përgjigjet, atëherë njoftimi kthehet përsëri te ndihmësi kryesor. Kështu, çdo alarm me prioritet të lartë nuk mund të mbetet pa u trajtuar.
Tani le të shohim se nga mund të vijnë incidentet.
Cilat integrime përdorim?
Në PD, ndodhin shumë incidente të ndryshme nga shërbime të ndryshme. Aktualisht kemi rreth 25 shërbime dhe për t'i trajtuar ato ne përdorim disa integrime të gatshme.
Në PD ndodhin shumë incidente të ndryshme nga shërbime të ndryshme. Aktualisht kemi rreth 25 shërbime të tillë, dhe për t'i menaxhuar ato përdorim disa integrime të gatshme.
- Prometheus
Sistemi kryesor për mbledhjen e metrikave është Prometheus. Për të janë shkruar shumë artikuj në Habr, unë do të them vetëm se ne kemi disa për mjedise të ndryshme: një mbledh metrikat nga virtualizimet dhe Docker, një tjetër nga shërbimet e Amazonit, dhe e treta nga "makinat fizike". Kryesisht, si eksportues metrikash përdoret Telegraf.
Këtu gjithashtu, mendoj se gjithçka është e qartë nga emri. Kjo integrim përdoret për dërgimin e njoftimeve nga disa skripte që kryhen nga cron. PD ju jep një adresë, në të cilën dërgoni emailet. Kur krijoni një shërbim me një integrim të tillë, mund të përcaktoni prioritetet për rendin në të cilin do të përpunohen incidentet e ardhshme, si dhe si të krijoni alarme (për çdo email që vjen, për një email që vjen + një rregull të caktuar, etj.).
- Slack
Sipas mendimit tim, kjo është një integrim shumë interesant. Ndodhin raste kur ndodh diçka, por nuk mbulohet nga incidentet. Prandaj, ne shtuam integrimin nga Slack për krijimin e incidenteve. Pra, mund të shkruani në Slack-in korporativ /callofduty все тормозит и скоро сломается dhe PD do ta përpunojë këtë dhe do të dërgojë incidentin te inxhinieri përgjegjës.
Ne bëjmë:
Shohim:
- API
Integrimi përmes HTTP. Këtu, në të vërtetë, nuk ka asgjë të veçantë, thjesht është një kërkesë POST me trup në format JSON. Për shembull, nga të interesantet: ne e përdorim atë për monitorim të jashtëm përmes . Ky shërbim kontrollon disponueshmërinë e faqeve tona nga pika të ndryshme në botë. Në rast se marrim një kod përgjigje të papranueshëm (p.sh., 502) krijohet një incident dhe më pas gjithçka vazhdon sipas zinxhirit të përshkruar më sipër. Brenda StatusCake ka mundësinë e monitorimit të URL-ve të brendshme, skadimit të certifikatës SSL ose domainit.
- LibreNMS
Kjo është një tjetër sistem monitorimi, për të cilin mund të lexoni më shumë në faqen e tyre . Me të, ne monitorojmë ndërfaqet rrjetit dhe iDRAC nga serverët.
Ishin gjithashtu integrime të tilla si Datadog, CloudWatch. Më shumë rreth asaj që ndodhi me to mund të shihni .
Vizualizimi
Sistemi kryesor i informimit mbi incidentet është Slack. Në një bisedë të veçantë shkruhen të gjitha incidentet që arrijnë në PD, dhe nëse ndryshon statusi i tyre, kjo gjithashtu shfaqet në bisedë.
Kur u shfaq mundësia për të shfaqur të dhëna të dobishme në ekranet e monitorëve të varur nga tavani, ne papritmas kuptuam se ne (në departamentin e devops) nuk kishim asgjë për të treguar atje. Ka një Grafana të shkëlqyer, por nuk mund të mbulojë gjithçka, ndërsa punonjësit reagojnë ndaj alarmeve, jo ndaj grafikëve.
Pas një kërkimi të kujdesshëm, por të pasuksesshëm në GitHub për një "board" të qartë dhe informues për PD, vendosëm të shkruajmë tonën — vetëm me atë që na nevojitet. Megjithatë, fillimisht ishte ideja për të shfaqur dritaren e vet PD, por kjo dukej akoma më e komplikuar.
Për ta shkruar atë, mjafton të merrni një çelës nga PD me të drejta vetëm për lexim.
Dhe ja çfarë arritëm:
Në ekran shfaqen incidentet e hapura aktuale, emri i inxhinierit të kujdestar aktuak nga orari i përzgjedhur dhe koha pa incidente me prioritet të lartë (pjesa me incidentin e lartë prioritet do të theksohet me ngjyrë të kuqe).
.
Në fund, arritëm një panel të rehatshëm për të parë të gjithë incidentet tona. Do të doja, nëse ndokujt nga ju i nevojitet përvoja jonë.
Burimi: habr.com
