PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Čím je systém zložitejší, tým viac je zarastený všetkými druhmi upozornení. A na tieto isté výstrahy je potrebné reagovať, agregovať ich a vizualizovať. Myslím, že toto je situácia, ktorá je mnohým známa až po nervozitu.

Riešenie, o ktorom sa bude diskutovať, nie je najneočakávanejšie, ale vyhľadávanie nevracia plnohodnotný článok na túto tému.

Preto som sa rozhodol podeliť sa o skúsenosti FunCorp a porozprávať sa o tom, ako je pracovný proces štruktúrovaný, kto volá, prečo a ako sa na to všetko dá pozerať.

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Čo je PagerDuty?

Aby sme vyriešili všetky tieto problémy, začali sme hľadať vhodný nástroj. Po nejakom hľadaní sme si vybrali PagerDuty. PD sa nám zdalo ako celkom kompletné a výstižné riešenie s veľkým množstvom integrácií a nastavení. Aká je?

Stručne povedané, PagerDuty je platforma na spracovanie incidentov, ktorá dokáže spracovať prichádzajúce incidenty prostredníctvom rôznych integrácií, nastaviť služobné príkazy a potom upozorniť technika v službe v závislosti od úrovne incidentu (na vysokej úrovni - hovor, na nízkej úrovni - push z aplikácie / SMS).

Kto je služobný dôstojník?

Toto je pravdepodobne prvé miesto, kde začať s nastavovaním PD.

Vo FunCorp, podobne ako v iných spoločnostiach, existuje čestná funkcia dôstojníka. Prenáša sa od inžiniera k inžinierovi raz denne. Na výstrahu od PagerDuty existuje takzvaný prvý a druhý riadok odozvy. Predpokladajme, že príde upozornenie s vysokou prioritou a ak 10 minút po zavolaní strážnikovi z prvého riadku naň nezareaguje (t. j. neprejde do stavu potvrdenia alebo vyriešenia), hovor prejde na druhý služobný inžinier. Toto sa konfiguruje v samotnej PagerDuty prostredníctvom zásad eskalácie.

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Ak druhý dôstojník neodpovie, oznámenie sa vráti späť na adresu Hlavná služobnému úradníkovi.

Žiadne prichádzajúce výstrahy s vysokou prioritou teda nemôžu zostať nespracované. 

Teraz sa pozrime, odkiaľ môžu pochádzať incidenty.

Aké integrácie používame?

PD prijíma mnoho rôznych incidentov z rôznych služieb. V súčasnosti máme asi 25 takýchto služieb a na ich spracovanie využívame niekoľko hotových integrácií.

  • Prometheus

Hlavným systémom zberu metrík je Prometheus. Na Habré sa o tom už popísalo veľa, poviem len, že ich máme niekoľko pre rôzne prostredia: jeden zbiera metriky z virtuálnych strojov a dockerov, ďalší zo služieb Amazonu, tretí z hardvérových strojov. Telegraf sa používa hlavne ako exportér metrík.

  • E-mail

Aj tu je myslím všetko jasné z názvu. Táto integrácia sa používa na odosielanie upozornení z niektorých skriptov vykonávaných cronom. PD vám dá určitú adresu, na ktorú posielate listy. Pri vytváraní služby s takouto integráciou si môžete nastaviť priority, v akom poradí sa budú spracovávať prichádzajúce incidenty, ako presne vytvoriť upozornenie (pre každý prichádzajúci list, pre prichádzajúci list + určité pravidlo atď.).

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

  • Voľný

Podľa mňa veľmi zaujímavá integrácia. Sú chvíle, keď sa niečo stane, ale nie je pokryté incidentmi. Preto sme pridali integráciu zo Slacku, aby sme vytvorili incident. To znamená, že môžete napísať na firemný Slack /callofduty všetko je pomalé a čoskoro sa pokazí a PD to spracuje a pošle incident služobnému inžinierovi.

Robíme:

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Vidíme:

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

  • API

Integrácia HTTP. V skutočnosti tu nie je nič mimoriadne zaujímavé, iba žiadosť POST s telom vo formáte JSON. Napríklad niečo zaujímavé: používame ho na externé monitorovanie https://www.statuscake.com/. Táto služba kontroluje dostupnosť našich stránok z rôznych častí sveta. V prípade, že dostaneme neprijateľný kód odpovede (napríklad 502), vytvorí sa incident a všetko sa potom riadi vyššie popísaným reťazcom. Samotný StatusCake má možnosť monitorovať interné URL adresy, SSL certifikát či expiráciu domény.

  • LibreNMS

Ide o ďalší monitorovací systém, viac sa o ňom dočítate na ich stránke https://www.librenms.org/. S jeho pomocou monitorujeme sieťové rozhrania a iDRAC zo serverov.

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Nechýbali ani integrácie ako Datadog, CloudWatch. Môžete vidieť viac o tom, čo sa im stalo tu.

Vizualizácia

Hlavným systémom hlásenia incidentov je Slack. Všetky incidenty prichádzajúce do PD sa zapisujú do špeciálneho chatu a ak sa ich stav zmení, zobrazí sa to aj v chate.

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Keď sa naskytla príležitosť zobraziť užitočné údaje na obrazovkách monitorov visiacich zo stropu, zrazu sme si uvedomili, že na nich (na oddelení devops) nemáme čo zobraziť. Existuje nádherná Grafana, ale nepokrýva všetko a zamestnanci reagujú na upozornenia, nie na grafy.

Po dôkladnom, ale neúspešnom hľadaní stručnej a informatívnej „nástenky“ pre PD na GitHub, sme sa rozhodli napísať vlastnú – len s tým, čo sme potrebovali. Aj keď spočiatku existoval nápad zobraziť samotné rozhranie PD, vyzeralo to ešte nepohodlnejšie.

Ak ho chcete napísať, všetko, čo musíte urobiť, je získať kľúč od PD s právami iba na čítanie.
A tu je to, čo sme dostali:

PagerDuty, alebo prečo prevádzkové oddelenie nemôže v noci spať

Na obrazovke sa zobrazia aktuálne otvorené incidenty, meno aktuálneho technika v službe zo zvoleného plánu a čas bez incidentu s vysokou prioritou (panel s incidentom s vysokou prioritou bude zvýraznený červenou farbou).

Zdroje tejto implementácie nájdete tu.

Výsledkom je, že sme dostali pohodlný informačný panel na prezeranie všetkých našich incidentov. Budem rád, ak niektorým z vás budú naše skúsenosti užitočné.

Zdroj: hab.com

Pridať komentár