Što je sistem složeniji, to više postaje obrastao svim vrstama upozorenja. I postoji potreba da se reaguje na ista ova upozorenja, agregira ih i vizualizuje. Mislim da je to situacija koja je mnogima poznata do granice nervoze.
Rješenje o kojem će se raspravljati nije najneočekivanije, ali pretraga ne vraća punopravni članak na ovu temu.
Stoga sam odlučio podijeliti iskustvo FunCorp-a i pričati o tome kako je strukturiran proces dežurstva, ko zove, zašto i kako na sve to možete gledati.
Šta je PagerDuty?
Dakle, da bismo riješili sve ove probleme, počeli smo tražiti pogodan alat. Nakon dužeg traženja, odabrali smo PagerDuty. PD nam se činio kao prilično kompletno i koncizno rješenje sa velikim brojem integracija i postavki. Kakva je ona?
Ukratko, PagerDuty je platforma za obradu incidenata koja može obraditi dolazne incidente kroz različite integracije, postaviti dežurne naloge i zatim upozoriti dežurnog inženjera u zavisnosti od nivoa incidenta (na visokom nivou - poziv, na niskom nivou - pritisak iz aplikacije / SMS).
Ko je dežurni?
Ovo je vjerovatno prvo mjesto za početak postavljanja PD-a.
U FunCorp-u, kao iu drugim kompanijama, postoji počasni položaj dežurnog. Prenosi se od inženjera do inženjera jednom dnevno. Postoji takozvani prvi i drugi red odgovora na upozorenje od PagerDuty. Pretpostavimo da stigne upozorenje visokog prioriteta, a ako 10 minuta nakon poziva dežurnom sa prve linije nema reakcije na njega (tj. nije prebačeno u status potvrde ili riješeno), poziv ide na drugi dežurni inženjer. Ovo se konfiguriše u samom PagerDuty-u kroz eskalacijske politike.
Ako drugi dežurni ne odgovori, obavještenje se vraća na main dežurnom.
Stoga, bilo koje dolazno upozorenje visokog prioriteta ne može ostati neobrađeno.
Sada da vidimo odakle incidenti mogu doći.
Koje integracije koristimo?
PD prima mnogo različitih incidenata od raznih službi. Trenutno imamo oko 25 takvih servisa, a za njihovu obradu koristimo neke gotove integracije.
- Prometej
Glavni sistem prikupljanja metrike je Prometheus. O tome je već dosta napisano na Habréu, samo ću reći da ih imamo nekoliko za različita okruženja: jedan prikuplja metriku sa virtuelnih mašina i docker-a, drugi sa Amazon servisa, treći sa hardverskih mašina. Telegraf se uglavnom koristi kao izvoznik metrike.
I ovdje je, mislim, sve jasno iz naslova. Ova integracija se koristi za slanje obavijesti iz nekih skripti koje izvršava cron. PD vam daje određenu adresu na koju šaljete pisma. Prilikom kreiranja servisa sa takvom integracijom možete postaviti prioritete, kojim redoslijedom će se dolazni incidenti obrađivati, kako točno kreirati upozorenje (za svako dolazno pismo, za dolazno pismo + određeno pravilo itd.).
- zatišje
Po mom mišljenju, vrlo zanimljiva integracija. Postoje trenuci kada se nešto dogodi, ali nije pokriveno incidentima. Stoga smo dodali integraciju sa Slack-a da stvorimo incident. To jest, možete pisati korporativnom Slacku /callofduty sve je sporo i uskoro će se pokvariti a PD će to obraditi i poslati incident dežurnom inženjeru.
Mi radimo:
Vidimo:
- API
HTTP integracija. Zapravo, ovdje nema ničeg posebno zanimljivog, samo POST zahtjev sa tijelom u JSON formatu. Na primjer, nešto zanimljivo: koristimo ga za korištenje vanjskog nadzora . Ova usluga provjerava dostupnost naših stranica iz različitih dijelova svijeta. U slučaju kada dobijemo neprihvatljiv kod odgovora (na primjer, 502), nastaje incident i onda sve slijedi gore opisani lanac. Sam StatusCake ima mogućnost nadgledanja internih URL-ova, SSL certifikata ili isteka domene.
- LibreNMS
Ovo je još jedan sistem za praćenje, više o tome možete pročitati na njihovoj web stranici . Uz njegovu pomoć pratimo mrežna sučelja i iDRAC sa servera.
Postojale su i integracije kao što su Datadog, CloudWatch. Možete vidjeti više o tome šta im se dogodilo .
Vizualizacija
Glavni sistem izvještavanja o incidentima je Slack. Svi incidenti koji dolaze u PD zapisuju se u poseban chat, a ako se njihov status promijeni, to se također prikazuje u chatu.
Kada se ukazala prilika da se korisni podaci prikazuju na ekranima monitora koji vise sa plafona, odjednom smo shvatili da mi (u devops odeljenju) nemamo šta da prikažemo na njima. Postoji divna Grafana, ali ne pokriva sve, a zaposleni reaguju na upozorenja, a ne na grafikone.
Nakon temeljite, ali neuspješne potrage na GitHubu za sažetom i informativnom „pločom“ za PD, odlučili smo da napišemo svoju – samo sa onim što nam je potrebno. Iako je u početku postojala ideja da se prikaže sam PD interfejs, izgledalo je još nezgodnije.
Da biste ga napisali, sve što treba da uradite je da dobijete ključ od PD sa pravima samo za čitanje.
I evo šta smo dobili:
Na ekranu se prikazuju trenutni otvoreni incidenti, ime trenutnog dežurnog inženjera iz odabranog rasporeda i vrijeme bez incidenta visokog prioriteta (panel sa incidentom visokog prioriteta će biti istaknut crvenom bojom).
.
Kao rezultat toga, dobili smo zgodnu kontrolnu tablu za pregled svih naših incidenata. Bit će mi drago ako nekome od vas naše iskustvo bude korisno.
izvor: www.habr.com