PagerDuty, или защо оперативният отдел не може да спи през нощта

Колкото по-сложна е системата, толкова повече тя обраства с всякакви сигнали. И има нужда да се реагира на същите тези сигнали, да се обобщят и визуализират. Мисля, че това е ситуация, която е позната на мнозина до степен на нервност.

Решението, което ще бъде обсъдено, не е най-неочакваното, но търсенето не връща пълноценна статия по тази тема.

Затова реших да споделя опита на FunCorp и да говоря за това как е структуриран процесът на дежурство, кой се обажда, защо и как можете да погледнете всичко това.

Какво е PagerDuty?

И така, за да разрешим всички тези проблеми, започнахме да търсим удобен инструмент. След известно търсене избрахме PagerDuty. PD ни се стори доста пълно и сбито решение с голям брой интеграции и настройки. Каква е тя?

Накратко, PagerDuty е платформа за обработка на инциденти, която може да обработва входящи инциденти чрез различни интеграции, да задава дежурни поръчки и след това да предупреждава дежурния инженер в зависимост от нивото на инцидента (на високо ниво - обаждане, на ниско ниво - натискане от приложението / SMS) .

Кой е дежурният?

Това е може би първото място, където да започнете да настройвате PD.

Във FunCorp, подобно на други компании, има почетна длъжност на дежурен офицер. Предава се от инженер на инженер веднъж на ден. Има така наречената първа и втора линия за отговор на предупреждение от PagerDuty. Да предположим, че пристигне предупреждение с висок приоритет и ако 10 минути след обаждането до дежурния от първата линия няма реакция към него (т.е. не се прехвърля в състояние на потвърждение или разрешено), обаждането отива на втория дежурен инженер. Това е конфигурирано в самия PagerDuty чрез правила за ескалация.

Ако вторият дежурен служител не отговори, известието се връща обратно към главен на дежурния.

По този начин всяко входящо предупреждение с висок приоритет не може да остане необработено. 

Сега да видим откъде могат да дойдат инциденти.

Какви интеграции използваме?

PD получава много различни инциденти от различни служби. В момента имаме около 25 такива услуги и за обработката им използваме няколко готови интеграции.

• Прометей

Основната система за събиране на метрики е Prometheus. Вече е писано много за това на Habré, ще кажа само, че имаме няколко от тях за различни среди: един събира метрики от виртуални машини и докери, друг от услуги на Amazon, трети от хардуерни машини. Telegraf се използва основно като износител на показатели.

• Имейл

Тук също мисля, че всичко е ясно от заглавието. Тази интеграция се използва за изпращане на известия от някои скриптове, изпълнявани от cron. PD ви дава определен адрес, на който изпращате писма. Когато създавате услуга с такава интеграция, можете да зададете приоритети, в какъв ред да се обработват входящи инциденти, как точно да се създаде предупреждение (за всяко входящо писмо, за входящо писмо + определено правило и т.н.).

• Застой

Според мен много интересна интеграция. Има моменти, когато нещо се случва, но не е обхванато от инциденти. Затова добавихме интеграция от Slack, за да създадем инцидент. Тоест можете да пишете на корпоративния Slack /callofduty всичко е бавно и скоро ще се повреди и PD ще го обработи и ще изпрати инцидента на дежурния инженер.

Ние правим:

Виждаме:

• API

HTTP интеграция. Всъщност тук няма нищо особено интересно, само POST заявка с тяло във формат JSON. Например нещо интересно: използваме го за външен мониторинг https://www.statuscake.com/. Тази услуга проверява достъпността на нашите сайтове от различни части на света. В случай, че получим неприемлив код за отговор (например 502), се създава инцидент и след това всичко следва веригата, описана по-горе. Самият StatusCake има способността да наблюдава вътрешни URL адреси, SSL сертификат или изтичане на домейна.

• LibreNMS

Това е друга система за наблюдение, можете да прочетете повече за нея на техния уебсайт https://www.librenms.org/. С негова помощ наблюдаваме мрежови интерфейси и iDRAC от сървъри.

Имаше и интеграции като Datadog, CloudWatch. Можете да видите повече за случилото се с тях тук.

Визуализация

Основната система за докладване на инциденти е Slack. Всички инциденти, идващи в PD, се записват в специален чат и ако състоянието им се промени, това също се показва в чата.

Когато се появи възможността да покажем полезни данни на екраните на мониторите, висящи от тавана, изведнъж осъзнахме, че ние (в отдела за devops) нямаме какво да покажем на тях. Има прекрасна Grafana, но тя не покрива всичко и служителите реагират на сигнали, а не на графики.

След задълбочено, но неуспешно търсене в GitHub на стегната и информативна „дъска“ за PD, решихме да напишем наша собствена – само с това, от което се нуждаехме. Въпреки че първоначално имаше идея да се покаже самият PD интерфейс, изглеждаше още по-неудобно.

За да го напишете, всичко, което трябва да направите, е да получите ключ от PD с права само за четене.
И ето какво получихме:

Екранът показва текущите отворени инциденти, името на текущия дежурен инженер от избрания график и времето без инцидент с висок приоритет (панелът с инцидент с висок приоритет ще бъде маркиран в червено).

Вижте източниците на тази реализация тук.

В резултат на това получихме удобно табло за преглед на всички наши инциденти. Ще се радвам, ако някой от вас намери нашия опит за полезен.

Източник: www.habr.com