PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Čím je systém složitější, tím více zarůstá nejrůznějšími upozorněními. A na tyto stejné výstrahy je potřeba reagovat, agregovat je a vizualizovat. Myslím, že to je situace, která je mnohým známá až k nervozitě.

Řešení, o kterém se bude diskutovat, není nejneočekávanější, ale hledání nevrací plnohodnotný článek na toto téma.

Proto jsem se rozhodl podělit se o zkušenosti FunCorp a pohovořit o tom, jak je strukturovaný celní proces, kdo volá, proč a jak se na to všechno můžete dívat.

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Co je PagerDuty?

Abychom vyřešili všechny tyto problémy, začali jsme hledat vhodný nástroj. Po chvíli hledání jsme zvolili PagerDuty. PD se nám zdálo jako vcelku kompletní a výstižné řešení s velkým množstvím integrací a nastavení. Jaká je?

Stručně řečeno, PagerDuty je platforma pro zpracování incidentů, která dokáže zpracovat příchozí incidenty prostřednictvím různých integrací, nastavit pracovní příkazy a poté upozornit technika ve službě v závislosti na úrovni incidentu (na vysoké úrovni - hovor, na nízké úrovni - push z aplikace / SMS).

Kdo je služební důstojník?

Toto je pravděpodobně první místo, kde začít s nastavením PD.

Ve FunCorp, stejně jako v jiných společnostech, existuje čestná funkce důstojníka. Přenáší se od inženýra k inženýrovi jednou denně. Na upozornění od PagerDuty existuje tzv. první a druhá linie reakce. Předpokládejme, že přijde upozornění s vysokou prioritou, a pokud 10 minut po zavolání strážníkovi z první linky na něj nezareaguje (tj. nepřejde do stavu potvrzení nebo vyřešeno), hovor přejde na druhý služební inženýr. To se konfiguruje v samotné PagerDuty prostřednictvím zásad eskalace.

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Pokud druhý služebník nereaguje, oznámení se vrátí zpět hlavní na služebního důstojníka.

Žádná příchozí výstraha s vysokou prioritou tedy nemůže zůstat nezpracovaná. 

Nyní se podívejme, odkud mohou incidenty pocházet.

Jaké integrace používáme?

PD přijímá mnoho různých incidentů z různých služeb. V současnosti máme asi 25 takových služeb ak jejich zpracování využíváme některé hotové integrace.

  • Prometheus

Hlavním systémem sběru metrik je Prometheus. Na Habré už o tom bylo napsáno hodně, řeknu jen, že jich máme několik pro různá prostředí: jeden sbírá metriky z virtuálních strojů a dockerů, další ze služeb Amazonu, třetí z hardwarových strojů. Telegraf se používá hlavně jako exportér metrik.

  • email

I zde je myslím vše jasné z názvu. Tato integrace se používá k odesílání upozornění z některých skriptů prováděných cronem. PD vám dá určitou adresu, na kterou posíláte dopisy. Při vytváření služby s takovou integrací můžete nastavit priority, v jakém pořadí budou zpracovány příchozí incidenty, jak přesně vytvořit upozornění (pro každý příchozí dopis, pro příchozí dopis + určité pravidlo atd.).

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

  • Volný

Dle mého názoru velmi zajímavá integrace. Jsou chvíle, kdy se něco stane, ale není to pokryto incidenty. Proto jsme přidali integraci ze Slacku, abychom vytvořili incident. To znamená, že můžete napsat na firemní Slack /callofduty všechno je pomalé a brzy se zlomí a PD to zpracuje a odešle incident servisnímu technikovi.

My ano:

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Vidíme:

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

  • API

Integrace HTTP. Ve skutečnosti zde není nic zvlášť zajímavého, pouze požadavek POST s tělem ve formátu JSON. Například něco zajímavého: používáme to pro externí monitorování pomocí https://www.statuscake.com/. Tato služba kontroluje dostupnost našich stránek z různých částí světa. V případě, že obdržíme nepřijatelný kód odezvy (například 502), dojde k vytvoření incidentu a vše se pak řídí výše popsaným řetězcem. Samotný StatusCake má možnost sledovat interní URL, SSL certifikát nebo expiraci domény.

  • LibreNMS

Jedná se o další monitorovací systém, více se o něm dočtete na jejich webu https://www.librenms.org/. S jeho pomocí monitorujeme síťová rozhraní a iDRAC ze serverů.

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Došlo i na integrace jako Datadog, CloudWatch. Můžete vidět více o tom, co se s nimi stalo zde.

Vizualizace

Hlavním systémem hlášení incidentů je Slack. Všechny incidenty přicházející do PD se zapisují do speciálního chatu a pokud se jejich stav změní, zobrazí se to i v chatu.

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Když se naskytla příležitost zobrazovat užitečná data na obrazovkách monitorů zavěšených u stropu, najednou jsme zjistili, že na nich (v oddělení devops) nemáme co zobrazovat. Existuje nádherná Grafana, ale nepokrývá vše a zaměstnanci reagují na upozornění, ne na grafy.

Po důkladném, ale neúspěšném hledání na GitHubu stručné a informativní „nástěnky“ pro PD, jsme se rozhodli napsat vlastní – pouze s tím, co jsme potřebovali. I když zpočátku existoval nápad na zobrazení samotného rozhraní PD, vypadalo to ještě nepohodlněji.

Chcete-li jej zapsat, vše, co musíte udělat, je získat klíč od PD s právy pouze pro čtení.
A tady je to, co jsme dostali:

PagerDuty aneb Proč provozní oddělení nemůže v noci spát

Na obrazovce se zobrazí aktuální otevřené incidenty, jméno aktuálního technika ve službě ze zvoleného plánu a čas bez incidentu s vysokou prioritou (panel s incidentem s vysokou prioritou bude zvýrazněn červeně).

Zdroje této implementace naleznete zde.

V důsledku toho jsme obdrželi pohodlný řídicí panel pro zobrazení všech našich incidentů. Budu rád, když někomu z vás budou naše zkušenosti užitečné.

Zdroj: www.habr.com

Přidat komentář