PagerDuty, или зошто Одделот за операции не може да спие ноќе

Колку е покомплексен системот, толку повеќе станува обраснат со сите видови предупредувања. И има потреба да се реагира на истите овие предупредувања, да се соберат и да се визуелизираат. Мислам дека ова е ситуација која на многумина им е позната до нервоза.

Решението за кое ќе се дискутира не е најнеочекуваното, но пребарувањето не враќа полноправна статија на оваа тема.

Затоа, решив да го споделам искуството на FunCorp и да зборувам за тоа како е структуриран процесот на должност, кој се јавува, зошто и како можете да го погледнете сето тоа.

Што е PagerDuty?

Така, за да ги решиме сите овие проблеми, почнавме да бараме пригодна алатка. По некое пребарување, избравме PagerDuty. ПД ни се чинеше како прилично комплетно и концизно решение со голем број интеграции и поставувања. Како изгледа таа?

Накратко, PagerDuty е платформа за обработка на инциденти која може да обработи дојдовни инциденти преку различни интеграции, да постави налози за должност и потоа да го предупреди дежурниот инженер во зависност од нивото на инцидентот (на високо ниво - повик, на ниско ниво - притискање од апликацијата / СМС) .

Кој е дежурниот?

Ова е веројатно првото место за започнување со поставување на ПД.

Во FunCorp, како и другите компании, постои почесна позиција на дежурен офицер. Се пренесува од инженер на инженер еднаш дневно. Постои таканаречена прва и втора линија на одговор на предупредување од PagerDuty. Да претпоставиме дека пристигнува предупредување со висок приоритет и ако 10 минути по повикот до дежурниот од првата линија нема реакција на тоа (т.е. не е префрлено во статусот потврден или решен), повикот оди на вториот дежурен инженер. Ова е конфигурирано во самиот PagerDuty преку Политиките за ескалација.

Ако вториот дежурен не одговори, известувањето се враќа на главен на дежурниот.

Така, секое дојдовно предупредување со висок приоритет не може да остане необработено. 

Сега да видиме од каде можат да дојдат инцидентите.

Какви интеграции користиме?

ПД добива многу различни инциденти од различни служби. Моментално располагаме со околу 25 такви сервиси, а за нивна обработка користиме некои готови интеграции.

• Прометеј

Главниот систем за собирање метрика е Прометеј. Веќе е многу напишано за тоа на Хабре, само ќе кажам дека имаме неколку од нив за различни средини: една собира метрика од виртуелни машини и докери, друга од услугите на Амазон, третата од хардверски машини. Телеграф главно се користи како извозник на метрика.

• Е-пошта

И тука мислам дека се е јасно од насловот. Оваа интеграција се користи за испраќање известувања од некои скрипти извршени од cron. ПД ви дава одредена адреса на која испраќате писма. Кога креирате услуга со таква интеграција, можете да поставите приоритети, по кој редослед ќе се обработуваат дојдовните инциденти, како точно да креирате предупредување (за секое дојдовно писмо, за дојдовно писмо + одредено правило итн.).

• Гасена

Според мене, многу интересна интеграција. Има моменти кога нешто се случува, но не е покриено со инциденти. Затоа, додадовме интеграција од Slack за да создадеме инцидент. Тоа е, можете да пишете на корпоративниот Slack /callofduty се е бавно и наскоро ќе пукне а ПД ќе го обработи и инцидентот ќе го испрати до дежурниот инженер.

Ние правиме:

Ние гледаме:

• API

HTTP интеграција. Всушност, тука нема ништо особено интересно, само барање POST со тело во JSON формат. На пример, нешто интересно: го користиме за надворешно следење со користење https://www.statuscake.com/. Оваа услуга ја проверува пристапноста на нашите страници од различни делови на светот. Во случај кога ќе добиеме неприфатлив код за одговор (на пример, 502), се создава инцидент и потоа сè го следи синџирот опишан погоре. Самиот StatusCake има можност да ги следи внатрешните URL-адреси, SSL сертификатот или истекувањето на доменот.

• LibreNMS

Ова е уште еден систем за следење, можете да прочитате повеќе за него на нивната веб-страница https://www.librenms.org/. Со негова помош, ги следиме мрежните интерфејси и iDRAC од серверите.

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

Визуелизација

Главниот систем за известување за инциденти е Slack. Сите инциденти кои доаѓаат во ПД се запишуваат на посебен разговор, а доколку се промени нивниот статус, тоа се прикажува и во разговорот.

Кога се појави можност да прикажеме корисни податоци на екраните на мониторите кои висат од таванот, одеднаш сфативме дека ние (во одделот за развој) немаме што да прикажуваме на нив. Има прекрасна Графана, но не покрива сè, а вработените реагираат на предупредувања, а не на графикони.

По темелно, но неуспешно пребарување на GitHub за концизна и информативна „табла“ за PD, решивме да напишеме своја - само со она што ни требаше. Иако на почетокот имаше идеја да се прикаже самиот PD интерфејс, тој изгледаше уште понезгодно.

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

На екранот се прикажуваат тековните отворени инциденти, името на тековниот дежурен инженер од избраниот распоред и времето без инцидент со висок приоритет (таблата со инцидент со висок приоритет ќе биде означена со црвено).

Видете ги изворите на оваа имплементација овде.

Како резултат на тоа, добивме удобна контролна табла за прегледување на сите наши инциденти. Ќе ми биде драго ако на некои од вас им е корисно нашето искуство.

Извор: www.habr.com