PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Því flóknara sem kerfið er, því meira verður það gróið af alls kyns viðvörunum. Og það er þörf á að bregðast við þessum sömu viðvörunum, safna þeim saman og sjá þær fyrir sér. Ég held að þetta sé ástand sem margir kannast við upp á taugaveiklun.

Lausnin sem fjallað verður um er ekki sú óvæntasta, en leitin skilar ekki fullri grein um þetta efni.

Þess vegna ákvað ég að deila reynslu FunCorp og tala um hvernig vaktferlið er byggt upp, hver hringir, hvers vegna og hvernig hægt er að skoða þetta allt saman.

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Hvað er PagerDuty?

Svo, til að leysa öll þessi vandamál, byrjuðum við að leita að þægilegu tæki. Eftir smá leit völdum við PagerDuty. PD virtist okkur vera nokkuð heill og hnitmiðuð lausn með miklum fjölda samþættinga og stillinga. Hvernig er hún?

Í stuttu máli er PagerDuty vettvangur til vinnslu atvika sem getur afgreitt atvik sem berast með ýmsum samþættingum, sett upp vaktskipanir og síðan gert verkfræðingnum á vakt viðvart eftir því hversu mikið atvikið er (á háu stigi - símtali, á lágu stigi - ýtt frá forritinu / SMS).

Hver er vaktstjóri?

Þetta er líklega fyrsti staðurinn til að byrja að setja upp PD.

Hjá FunCorp, eins og öðrum fyrirtækjum, starfar heiðursstaða vaktstjóra. Það er sent frá verkfræðingi til verkfræðings einu sinni á dag. Það er svokölluð fyrsta og önnur viðbragðslína við viðvörun frá PagerDuty. Segjum sem svo að viðvörun með háum forgangi berist og ef 10 mínútum eftir símtalið til vaktstjóra frá fyrstu línu er engin viðbrögð við henni (þ.e. hún er ekki færð yfir í staðfestingu eða leyst stöðu), fer símtalið í þá seinni vakthafandi verkfræðingur. Þetta er stillt í PagerDuty sjálfu í gegnum stigmögnunarreglur.

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Ef annar vaktstjóri bregst ekki við, fer tilkynningin aftur til aðal til vaktstjóra.

Þannig getur ekki verið unnt að afgreiða hvaða viðvörun sem berast með miklum forgangi. 

Nú skulum við sjá hvaðan atvik geta komið.

Hvaða samþættingar notum við?

PD fær mörg mismunandi atvik frá ýmsum þjónustum. Núna erum við með um 25 slíkar þjónustur og til að vinna úr þeim notum við nokkrar tilbúnar samþættingar.

  • Prometheus

Helsta mæligildasöfnunarkerfið er Prometheus. Margt hefur þegar verið skrifað um það á Habré, ég segi bara að við höfum nokkra af þeim fyrir mismunandi umhverfi: einn safnar mælingum frá sýndarvélum og bryggjumönnum, annar frá Amazon þjónustu, sá þriðji frá vélbúnaðarvélum. Telegraf er aðallega notað sem útflytjandi mælikvarða.

  • Tölvupóstur

Hér held ég líka að allt sé ljóst af titlinum. Þessi samþætting er notuð til að senda tilkynningar frá sumum forskriftum keyrð af cron. PD gefur þér ákveðið heimilisfang sem þú sendir bréf til. Þegar þú býrð til þjónustu með slíkri samþættingu er hægt að setja forgangsröðun, í hvaða röð innkomin atvik verða unnin, hvernig nákvæmlega á að búa til viðvörun (fyrir hvert bréf sem kemur inn, fyrir bréf sem kemur inn + ákveðin regla o.s.frv.).

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

  • Slaki

Að mínu mati mjög áhugaverð samþætting. Það eru tímar þegar eitthvað gerist en er ekki fjallað um atvik. Þess vegna bættum við við samþættingu frá Slack til að búa til atvik. Það er, þú getur skrifað til fyrirtækja Slack /callofduty allt er hægt og mun brotna fljótlega og PD mun vinna úr því og senda atvikið til vakthafandi verkfræðings.

Við gerum:

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Við sjáum:

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

  • API

HTTP samþætting. Reyndar er ekkert sérstaklega áhugavert hér, bara POST beiðni með meginmáli á JSON sniði. Til dæmis, eitthvað áhugavert: við notum það fyrir ytri eftirlit með því að nota https://www.statuscake.com/. Þessi þjónusta athugar aðgengi vefsvæða okkar frá mismunandi heimshlutum. Ef við fáum óviðunandi svarkóða (til dæmis 502) myndast atvik og þá fylgir allt keðjunni sem lýst er hér að ofan. StatusCake sjálft hefur getu til að fylgjast með innri vefslóðum, SSL vottorði eða fyrningu léns.

  • LibreNMS

Þetta er annað eftirlitskerfi, þú getur lesið meira um það á heimasíðu þeirra https://www.librenms.org/. Með hjálp þess fylgjumst við með netviðmótum og iDRAC frá netþjónum.

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Það voru líka samþættingar eins og Datadog, CloudWatch. Þú getur séð meira um hvað varð um þá hér.

Sjónræn

Aðalatvikatilkynningarkerfið er Slack. Öll atvik sem koma til PD eru skrifuð á sérstakt spjall og ef staða þeirra breytist birtist það einnig í spjallinu.

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Þegar tækifæri gafst til að birta gagnleg gögn á skjáum skjáa sem héngu úr loftinu, áttuðum við okkur allt í einu á því að við (í devops-deildinni) höfðum ekkert að sýna á þeim. Það er dásamlegt Grafana, en það nær ekki yfir allt, og starfsmenn bregðast við tilkynningum, ekki töflum.

Eftir ítarlega en árangurslausa leit á GitHub að hnitmiðuðu og upplýsandi „borði“ fyrir PD ákváðum við að skrifa okkar eigin - aðeins með því sem við þurftum. Þó að í fyrstu hafi verið hugmynd um að sýna PD viðmótið sjálft, leit það enn óþægilegra út.

Til að skrifa það þarftu bara að fá lykil frá PD með skrifvarinn rétt.
Og þetta er það sem við fengum:

PagerDuty, eða hvers vegna rekstrardeildin getur ekki sofið á nóttunni

Skjárinn sýnir núverandi opna atvik, nafn núverandi verkfræðings á vakt úr völdu áætluninni og tímann án forgangsatviks (spjaldið með forgangsatvik verður auðkennt með rauðu).

Sjá heimildir um þessa framkvæmd hér.

Fyrir vikið fengum við þægilegt mælaborð til að skoða öll atvik okkar. Ég mun vera ánægður ef einhverjum ykkar finnst reynsla okkar gagnleg.

Heimild: www.habr.com

Bæta við athugasemd