Mida keerulisem on süsteem, seda rohkem see kogub erinevaid häireid. Ja tekib vajadus nende häiretega reageerida, neid koguda ja visualiseerida. Arvan, et see on paljudele tuttav olukord, mis tekitab närvilisust.
Lahendus, millest juttu tuleb, ei ole kõige ootamatum, kuid täisartiklit selle teema kohta ei leia.
Seetõttu otsustasin jagada FunCorpi kogemusi ja rääkida, kuidas on korraldatud vahetuste protsess, kes helistab, miks ning kuidas selle kõik üle vaadata.
Mis on PagerDuty?
Nii et, et kõiki neid ülesandeid lahendada, hakkasime otsima mugavat tööriista. Pärast lühikest otsimist valisime PagerDuty. PD tundus olevat piisavalt täis ja selge lahendus paljude integratsioonide ja seadistustega. Mis see endast kujutab?
Lühidalt öeldes on PagerDuty platvorm, mis käsitleb intsidente ning suudab töödelda sisenevaid intsidendi teateid erinevate integratsioonide kaudu, seadistada vahetuste järjekorra ja teavitada vahetuses olevat inseneri vastavalt intsidendi tasemele (kõrge taseme korral toimub helistamine, madala taseme korral teavitamine rakenduse kaudu/smsiga).
Kes on vahetuses olev insener?
Tõenäoliselt on see esimene asi, millega peaks PagerDuty seadistamist alustama.
FunCorpis, nagu ka teistes ettevõtetes, on austusväärne vahetuses oleva inseneri ametikoht. See vahetatakse insenerilt insenerile iga päev. On olemas esimene ja teine reageerimisliin PagerDuty häiretele. Oletame, et saabub kõrge prioriteediga häire, ja kui 10 minuti jooksul pärast helistamist ei reageeri esimese liini vahetuses olev insener (st seda ei muudetud staatuseks 'tunnustatud' või 'lahendatud'), läheb helistamine teisele vahetuses olevale insenerile. See on seadistatav PagerDuty-s Escalation Policies kaudu.
Kui ka teine vahetuses olev insener ei vasta, naaseb teavitus tagasi peamisele vahetuses olevale insenerile.
Nii et ükski kõrge prioriteediga sissetulev häire ei jää töötlemata.
Nüüd vaatame, kust võivad intsidentide teated tulla.
Milliseid integratsioone kasutame?
PD-sse tuleb palju erinevaid intsidendeid erinevatelt teenustelt. Meil on praegu umbes 25 sellist teenust ning nende töötlemiseks kasutame mõned valmis integratsioonid.
- Prometheus
Peamine mõõtmete kogumise süsteem on Prometheus. Selle kohta on Hübriidi lehtedel juba palju kirjutatud, kuid ma ütlen vaid, et meil on neid mitu erinevate keskkondade jaoks: üks kogub mõõtmeid virtuaalmasinatelt ja konteineritelt, teine Amazonist teenustelt ning kolmas füüsilistelt seadmetelt. Peamiselt kasutatakse mõõtmete eksportimiseks Telegrafi.
- E-post
Siin on ka kõik selge pealkirjast. See integratsioon on mõeldud teatiste saatmiseks teatud skriptidelt, mis töötavad akna järgi. PD annab teile mingi aadressi, kuhu te saadate kirjad. Teenuse loomisel sellise integratsiooniga saate seadistada prioriteedid, millises järjekorras tulevad sissetulevad intsidentid töötlemiseks ja kuidas täpselt genereerida teate (iga sissetulev kiri, sissetulev kiri + mingi reegel jne.).
- Slack
Minu arvates on see väga huvitav integratsioon. On juhtumeid, kui midagi juhtub, kuid see ei kata intsidente. Seetõttu oleme lisanud Slacki integratsiooni intsidentide loomiseks. St. saab ettevõtte Slackis kirjutada /callofduty все тормозит и скоро сломается ja PD töötleb seda ning saadab intsident kohusetäitjale insenerile.
Teeme:
Näeme:
- API
HTTP integratsioon. Siin pole tegelikult suurt midagi huvitavat, lihtsalt POST-päring JSON-formaadis. Näiteks huvitav on see, et kasutame seda välise jälgimise jaoks . See teenus kontrollib meie veebisaitide kättesaadavust erinevatest maailma nurkadest. Kui saame vastuvõetamatuid vastuse koode (nt 502), siis luuakse intsident ja kõik läheb edasi ülaltoodud kirjeldatud ahelas. StatusCake'is on ka võimalus jälgida sisemisi URL-e, SSL-sertifikaadi või domeeni kehtivuse lõppu.
- LibreNMS
See on veel üks jälgimisse süsteem, millest saab lähemalt lugeda nende veebilehelt . Selle abil teostame võrgu liideste ja iDRAC-i jälgimist serveritest.
Oli veel selliseid integratsioone nagu Datadog, CloudWatch. Rohkem teavet selle kohta, mis nendega juhtus, saab vaadata .
Visualiseerimine
Peamine intsidentide teavitamise süsteem on Slack. Eraklassi vestlusesse kirjutatakse kõik PD-sse saabuvad intsidentid ja kui nende staatus muutub, kuvatakse see samuti vestluses.
Kui tekkis võimalus kuvada kasulikku teavet lae alla riputatud monitoridel, mõistsime äkki, et meie (devops-osakonnas) pole seal midagi kuvada. Grafana on suurepärane, kuid see ei kata kõike, ja töötajad reageerivad hädadele, mitte diagrammidele.
P pärast põhjalikku, kuid tulutuks osutunud otsimist GitHubis lühikese ja informatiivse PD «bordi» jaoks, otsustasime kirjutada oma — ainult sellega, mida vajame. Alguses oli idee kuvada PD kasutajaliides ekraanile, kuid see tundus veelgi ebamugavam.
Selle kirjutamiseks on vaid vaja saada PD lugemisõigustega võti.
Ja siin on, mis me kokku panime:
Ekraanil kuvatakse aktuaalsed avatud juhtumid, valitud graafikust hetkeööraarhitekti nimi ja aeg ilma kõrge prioriteediga juhtumita (kõrge prioriteediga juhtumi paneel on esile tõstetud punase värviga).
.
Lõpuks saime mugava juhtpaneeli kõigi meie juhtumite vaatamiseks. Olen rõõmus, kui meie kogemus kellegile abi toob.
Allikas: habr.com
