PagerDuty կամ ինչու օպերացիոն վարչությունը չի կարող գիշերը քնել

Որքան բարդ է համակարգը, այնքան ավելի շատ է այն գերաճում բոլոր տեսակի ահազանգերով: Եվ այս նույն ահազանգերին արձագանքելու, դրանք համախմբելու և պատկերացնելու անհրաժեշտություն կա: Կարծում եմ՝ սա շատերին նյարդայնանալու աստիճան ծանոթ իրավիճակ է։

Լուծումը, որը կքննարկվի, ամենաանսպասելի չէ, բայց որոնումը չի վերադարձնում այս թեմայի վերաբերյալ լիարժեք հոդված:

Հետևաբար, ես որոշեցի կիսվել FunCorp-ի փորձով և խոսել այն մասին, թե ինչպես է կառուցված հերթապահության գործընթացը, ով է զանգում, ինչու և ինչպես կարող եք նայել այդ ամենին:

Ի՞նչ է PagerDuty-ն:

Այսպիսով, այս բոլոր խնդիրները լուծելու համար մենք սկսեցինք հարմար գործիք փնտրել։ Որոշ որոնումներից հետո մենք ընտրեցինք PagerDuty-ն: PD-ն մեզ թվում էր բավականին ամբողջական և հակիրճ լուծում՝ մեծ թվով ինտեգրումներով և կարգավորումներով: Ինչպիսի՞ն է նա:

Կարճ ասած, PagerDuty-ն միջադեպերի մշակման հարթակ է, որը կարող է մշակել մուտքային միջադեպերը տարբեր ինտեգրացիաների միջոցով, սահմանել հերթապահության պատվերներ և այնուհետև զգուշացնել հերթապահ ինժեներին՝ կախված միջադեպի մակարդակից (բարձր մակարդակում՝ զանգ, ցածր մակարդակով. մղում հավելվածից / SMS-ից):

Ո՞վ է հերթապահը.

Սա, հավանաբար, առաջին տեղն է, որտեղ սկսվում է PD-ի տեղադրումը:

FunCorp-ում, ինչպես մյուս ընկերությունները, կա հերթապահի պատվավոր պաշտոն։ Այն ինժեներից ինժեներ է փոխանցվում օրը մեկ անգամ։ PagerDuty-ի ահազանգին կա այսպես կոչված արձագանքման առաջին և երկրորդ տող: Ենթադրենք, գալիս է բարձր առաջնահերթ ահազանգ, և եթե առաջին գծից հերթապահ ինժեներին կանչելուց 10 րոպե անց դրան արձագանք չի լինում (այսինքն՝ այն չի փոխանցվում ճանաչման կամ լուծված կարգավիճակի), զանգը գնում է երկրորդին։ հերթապահ ինժեներ. Սա կազմաձևված է հենց PagerDuty-ում Էսկալացիոն քաղաքականության միջոցով:

Եթե ​​երկրորդ հերթապահը չի արձագանքում, ծանուցումը վերադառնում է հիմնականը հերթապահին.

Այսպիսով, ցանկացած մուտքային բարձր առաջնահերթ ահազանգ չի կարող չմշակված մնալ: 

Հիմա տեսնենք, թե որտեղից կարող են առաջանալ միջադեպեր։

Ի՞նչ ինտեգրացիաներ ենք մենք օգտագործում:

PD-ն բազմաթիվ տարբեր միջադեպեր է ստանում տարբեր ծառայություններից: Ներկայումս մենք ունենք մոտ 25 նման ծառայություններ, և դրանք մշակելու համար օգտագործում ենք մի քանի պատրաստի ինտեգրում։

• Պրոմեթեւս

Չափումների հավաքագրման հիմնական համակարգը Պրոմեթևսն է: 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: Դուք կարող եք ավելին տեսնել նրանց հետ կատարվածի մասին այստեղ.

Visualization

Միջադեպերի հաղորդման հիմնական համակարգը Slack-ն է: PD-ին եկող բոլոր միջադեպերը գրվում են հատուկ չաթում, և եթե դրանց կարգավիճակը փոխվում է, դա նույնպես ցուցադրվում է չաթում:

Երբ առաստաղից կախված մոնիտորների էկրաններին օգտակար տվյալներ ցուցադրելու հնարավորություն ստեղծվեց, մենք հանկարծ հասկացանք, որ մենք (դևոպս բաժնում) դրանց վրա ցուցադրելու ոչինչ չունենք։ Կա հիանալի Grafana, բայց այն չի ներառում ամեն ինչ, և աշխատակիցները արձագանքում են ահազանգերին, ոչ թե գծապատկերներին:

GitHub-ում PD-ի հակիրճ և տեղեկատվական «տախտակի» մանրակրկիտ, բայց անհաջող որոնումից հետո մենք որոշեցինք գրել մերը` միայն այն, ինչ մեզ անհրաժեշտ էր: Թեև սկզբում գաղափար կար ցուցադրել PD ինտերֆեյսը, այն էլ ավելի անհարմար էր թվում:

Այն գրելու համար անհրաժեշտ է ընդամենը ստանալ բանալի PD-ից միայն կարդալու իրավունքներով:
Եվ սա այն է, ինչ մենք ստացանք.

Էկրանին ցուցադրվում են ընթացիկ բաց միջադեպերը, ընտրված ժամանակացույցից գործող հերթապահ ինժեների անունը և առանց բարձր առաջնահերթ միջադեպի ժամանակը (բարձր առաջնահերթ միջադեպով վահանակը ընդգծված կլինի կարմիրով):

Այս իրականացման աղբյուրները տես այստեղ.

Արդյունքում մենք ստացանք հարմար վահանակ մեր բոլոր միջադեպերը դիտելու համար: Ուրախ կլինեմ, եթե ձեզնից ոմանց մեր փորձը օգտակար համարի:

Source: www.habr.com