Hoe meer kompleks die stelsel is, hoe meer word dit toegegroei met allerhande waarskuwings. En daar is 'n behoefte om op dieselfde waarskuwings te reageer, dit saam te voeg en te visualiseer. Ek dink dit is 'n situasie wat tot die punt van senuweeagtigheid vir baie bekend is.
Die oplossing wat bespreek sal word, is nie die mees onverwagte nie, maar die soektog lewer nie 'n volwaardige artikel oor hierdie onderwerp op nie.
Daarom het ek besluit om FunCorp se ervaring te deel en te praat oor hoe die diensproses gestruktureer is, wie bel, hoekom en hoe jy daarna kan kyk.
Wat is PagerDuty?
Dus, om al hierdie probleme op te los, het ons begin soek na 'n gerieflike hulpmiddel. Na 'n bietjie soektog het ons PagerDuty gekies. PD het vir ons gelyk na 'n redelik volledige en bondige oplossing met 'n groot aantal integrasies en instellings. Hoe is sy?
Kortom, PagerDuty is 'n insidentverwerkingsplatform wat inkomende voorvalle deur verskeie integrasies kan verwerk, diensbevele kan opstel en dan die ingenieur aan diens waarsku, afhangende van die vlak van die voorval (op 'n hoë vlak - 'n oproep, op 'n lae vlak - 'n druk van die toepassing / SMS) .
Wie is die diensbeampte?
Dit is waarskynlik die eerste plek om PD te begin opstel.
By FunCorp, soos ander maatskappye, is daar 'n erepos van diensbeampte. Dit word een keer per dag van ingenieur na ingenieur oorgedra. Daar is 'n sogenaamde eerste en tweede lyn van reaksie op 'n waarskuwing van PagerDuty. Gestel 'n hoë-prioriteit waarskuwing arriveer, en as daar 10 minute na die oproep na die diensbeampte vanaf die eerste lyn geen reaksie daarop is nie (d.w.s. dit word nie na die erken- of opgelos-status oorgedra nie), gaan die oproep na die tweede diens ingenieur. Dit word in PagerDuty self gekonfigureer deur eskalasiebeleide.
As die tweede diensbeampte nie reageer nie, keer die kennisgewing terug na hoof aan die diensbeampte.
Dus, enige inkomende hoë prioriteit waarskuwing kan nie onverwerk bly nie.
Kom ons kyk nou waar insidente vandaan kan kom.
Watter integrasies gebruik ons?
PD ontvang baie verskillende voorvalle van verskeie dienste. Ons het tans ongeveer 25 sulke dienste, en om dit te verwerk gebruik ons 'n paar klaargemaakte integrasies.
- Prometheus
Die belangrikste metrieke insamelingstelsel is Prometheus. Daar is reeds baie daaroor op Habré geskryf, ek sal net sê dat ons verskeie van hulle vir verskillende omgewings het: een versamel statistieke van virtuele masjiene en dockers, 'n ander van Amazon-dienste, die derde van hardewaremasjiene. Telegraf word hoofsaaklik as 'n metrieke uitvoerder gebruik.
- E-posadres
Ook hier, dink ek, is alles duidelik uit die titel. Hierdie integrasie word gebruik om kennisgewings te stuur vanaf sommige skrifte wat deur cron uitgevoer word. PD gee vir jou 'n sekere adres waarheen jy briewe stuur. Wanneer u 'n diens met so 'n integrasie skep, kan u prioriteite stel, in watter volgorde inkomende voorvalle verwerk sal word, hoe presies om 'n waarskuwing te skep (vir elke inkomende brief, vir 'n inkomende brief + 'n sekere reël, ens.).
- Slack
Na my mening 'n baie interessante integrasie. Daar is tye wanneer iets gebeur, maar nie deur insidente gedek word nie. Daarom het ons integrasie van Slack bygevoeg om 'n voorval te skep. Dit wil sê, jy kan aan korporatiewe Slack skryf /callofduty alles is stadig en sal binnekort breek en die PD sal dit verwerk en die voorval aan die diensingenieur stuur.
Ons doen:
Ons sien:
- API
HTTP-integrasie. Trouens, hier is niks besonders interessant nie, net 'n POST-versoek met 'n liggaam in JSON-formaat. Byvoorbeeld, iets interessants: ons gebruik dit vir eksterne monitering met behulp van . Hierdie diens kontroleer die toeganklikheid van ons werwe van verskillende wêrelddele. In die geval wanneer ons 'n onaanvaarbare reaksiekode (byvoorbeeld 502) ontvang, word 'n voorval geskep en dan volg alles die ketting wat hierbo beskryf is. StatusCake self het die vermoë om interne URL's, SSL-sertifikaat of domeinverval te monitor.
- LibreNMS
Dit is nog 'n moniteringstelsel, jy kan meer daaroor lees op hul webwerf . Met sy hulp monitor ons netwerkkoppelvlakke en iDRAC vanaf bedieners.
Daar was ook integrasies soos Datadog, CloudWatch. Jy kan meer sien oor wat met hulle gebeur het .
Visualisering
Die hoofvoorvalrapporteringstelsel is Slack. Alle voorvalle wat na PD kom, word na 'n spesiale klets geskryf, en as hul status verander, word dit ook in die klets vertoon.
Toe die geleentheid opduik om bruikbare data te vertoon op die skerms van monitors wat van die plafon af hang, het ons skielik besef dat ons (in die devops-afdeling) niks het om daarop te vertoon nie. Daar is 'n wonderlike Grafana, maar dit dek nie alles nie, en werknemers reageer op waarskuwings, nie kaarte nie.
Na 'n deeglike maar onsuksesvolle soektog op GitHub vir 'n bondige en insiggewende "bord" vir PD, het ons besluit om ons eie te skryf - net met wat ons nodig het. Alhoewel daar aanvanklik 'n idee was om die PD-koppelvlak self te vertoon, het dit selfs meer ongerieflik gelyk.
Om dit te skryf, hoef jy net 'n sleutel van 'n PD met leesalleenregte te kry.
En dit is wat ons gekry het:
Die skerm vertoon die huidige oop voorvalle, die naam van die huidige ingenieur aan diens vanaf die geselekteerde skedule, en die tyd sonder 'n hoë prioriteit voorval (die paneel met 'n hoë prioriteit voorval sal in rooi uitgelig word).
.
Gevolglik het ons 'n gerieflike kontroleskerm ontvang om al ons voorvalle te bekyk. Ek sal bly wees as sommige van julle ons ervaring nuttig vind.
Bron: will.com