PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Što je sustav složeniji, to je više obrastao raznim vrstama upozorenja. I na te iste dojave treba reagirati, agregirati ih i vizualizirati. Mislim da je to situacija koja je mnogima poznata do nervoze.

Rješenje o kojem će se raspravljati nije najneočekivanije, ali pretraživanje ne vraća cjeloviti članak o ovoj temi.

Stoga sam odlučio podijeliti iskustvo FunCorpa i govoriti o tome kako je strukturiran proces dežurstva, tko zove, zašto i kako na sve to možete gledati.

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Što je PagerDuty?

Dakle, kako bismo riješili sve te probleme, počeli smo tražiti prikladan alat. Nakon malo traženja, odabrali smo PagerDuty. PD nam se činio prilično cjelovitim i konciznim rješenjem s velikim brojem integracija i postavki. Kakva je ona?

Ukratko, PagerDuty je platforma za obradu incidenata koja može obraditi dolazne incidente kroz razne integracije, postaviti dežurne naloge i zatim upozoriti dežurnog inženjera ovisno o razini incidenta (na visokoj razini - poziv, na niskoj razini - push iz aplikacije / SMS) .

Tko je dežurni?

Ovo je vjerojatno prvo mjesto za početak postavljanja PD-a.

U FunCorpu, kao i u drugim tvrtkama, postoji počasna pozicija dežurnog časnika. Prenosi se od inženjera do inženjera jednom dnevno. Postoji takozvani prvi i drugi redak odgovora na upozorenje od PagerDuty. Pretpostavimo da stigne dojava visokog prioriteta i ako 10 minuta nakon poziva dežurnom s prve linije nema reakcije na nju (tj. ne prelazi u status potvrde ili riješeno), poziv ide na drugu dežurni inženjer. Ovo je konfigurirano u samom PagerDutyju putem Pravila eskalacije.

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Ako drugi dežurni ne odgovori, obavijest se vraća na glavni dežurnom.

Stoga svako 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 usluga, a za njihovu obradu koristimo neke gotove integracije.

  • Prometej

Glavni sustav 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 s virtualnih strojeva i dockera, drugi s Amazonovih servisa, treći s hardverskih strojeva. Telegraf se uglavnom koristi kao izvoznik metrike.

  • E-mail

I ovdje je, mislim, sve jasno iz naslova. Ova se integracija koristi za slanje obavijesti iz nekih skripti koje izvršava cron. PD vam daje određenu adresu na koju šaljete pisma. Prilikom kreiranja usluge s takvom integracijom možete postaviti prioritete, kojim redoslijedom će se obrađivati ​​dolazni incidenti, kako točno kreirati upozorenje (za svako dolazno pismo, za dolazno pismo + određeno pravilo itd.).

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

  • Zatišje

Po meni vrlo zanimljiva integracija. Postoje trenuci kada se nešto dogodi, ali nije pokriveno incidentima. Stoga smo dodali integraciju iz Slacka za stvaranje incidenta. Odnosno, možete pisati korporativnom Slacku /callofduty sve je sporo i uskoro će se pokvariti a PU će to obraditi i incident poslati dežurnom inženjeru.

Radimo:

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Mi vidimo:

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

  • API

HTTP integracija. Zapravo, ovdje nema ništa posebno zanimljivo, samo POST zahtjev s tijelom u JSON formatu. Na primjer, nešto zanimljivo: koristimo ga za vanjski nadzor https://www.statuscake.com/. Ova usluga provjerava dostupnost naših stranica iz različitih dijelova svijeta. U slučaju kada dobijemo neprihvatljiv kod odgovora (npr. 502), stvara se incident i dalje sve ide gore opisanim lancem. Sam StatusCake ima mogućnost praćenja internih URL-ova, SSL certifikata ili isteka domene.

  • LibreNMS

Ovo je još jedan sustav nadzora, više o njemu možete pročitati na njihovoj web stranici https://www.librenms.org/. Uz njegovu pomoć nadziremo mrežna sučelja i iDRAC s poslužitelja.

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Bilo je i integracija poput Datadoga, CloudWatcha. Možete vidjeti više o tome što im se dogodilo ovdje.

Vizualizacija

Glavni sustav za prijavu incidenata 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.

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Kad se ukazala prilika da korisne podatke prikažemo na ekranima monitora koji vise sa stropa, odjednom smo shvatili da mi (u devops odjelu) nemamo što prikazati na njima. Postoji divna Grafana, ali ne pokriva sve, a zaposlenici reagiraju na dojave, a ne na grafikone.

Nakon temeljite, ali neuspješne potrage na GitHubu za sažetom i informativnom "pločom" za PD, odlučili smo napisati vlastitu - samo s onim što nam je potrebno. Iako je u početku postojala ideja da se prikaže samo PD sučelje, izgledalo je još nezgodnije.

Da biste ga napisali, sve što trebate učiniti je nabaviti ključ od PD-a s pravima samo za čitanje.
I evo što smo dobili:

PagerDuty, ili zašto Odjel za operacije ne može spavati noću

Na ekranu se prikazuju trenutno otvoreni incidenti, ime trenutnog dežurnog inženjera iz odabranog rasporeda i vrijeme bez incidenta visokog prioriteta (ploča s incidentom visokog prioriteta bit će označena crvenom bojom).

Ovdje pogledajte izvore ove implementacije.

Kao rezultat toga, dobili smo praktičnu nadzornu ploču za pregled svih naših incidenata. Bit će mi drago ako nekome od vas naše iskustvo bude od koristi.

Izvor: www.habr.com

Dodajte komentar