Ju pli kompleksa la sistemo, des pli ĝi fariĝas superkreskita per ĉiaj atentigoj. Kaj necesas reagi al ĉi tiuj samaj atentigoj, kunigi ilin kaj bildigi ilin. Mi pensas, ke ĉi tio estas situacio, kiu estas konata al multaj ĝis nervozeco.
La solvo priparolata ne estas la plej neatendita, sed la serĉo ne resendas plenrajtan artikolon pri ĉi tiu temo.
Tial mi decidis kunhavigi la sperton de FunCorp kaj paroli pri kiel la devoprocezo estas strukturita, kiu vokas, kial kaj kiel vi povas rigardi ĉion.
Kio estas PagerDuty?
Do, por solvi ĉiujn ĉi tiujn problemojn, ni komencis serĉi oportunan ilon. Post iom da serĉado, ni elektis PagerDuty. PD ŝajnis al ni sufiĉe kompleta kaj konciza solvo kun granda nombro da integriĝoj kaj agordoj. Kia ŝi estas?
Resume, PagerDuty estas okazaĵa prilabora platformo, kiu povas prilabori envenantajn okazaĵojn per diversaj integriĝoj, agordi devomendojn kaj poste atentigi la deĵorantan inĝenieron depende de la nivelo de la okazaĵo (ĉe alta nivelo - alvoko, je malalta nivelo - puŝo de la aplikaĵo/SMS).
Kiu estas la deĵoroficiro?
Ĉi tio verŝajne estas la unua loko por komenci agordi PD.
Ĉe FunCorp, kiel aliaj kompanioj, ekzistas honora pozicio de deĵoroficiro. Ĝi estas transdonita de inĝeniero al inĝeniero unufoje tage. Estas tiel nomata unua kaj dua linio de respondo al atentigo de PagerDuty. Supozu altprioritata alarmo alvenas, kaj se 10 minutojn post la voko al la deĵoroficiro de la unua linio ekzistas neniu reago al ĝi (t.e., ĝi ne estas transdonita al la agnosko aŭ solvita statuso), la voko iras al la dua. deĵora inĝeniero. Ĉi tio estas agordita en PagerDuty mem per Escalada Politikoj.
Se la dua oficoficiro ne respondas, la sciigo revenas al ĉefa al la deĵora oficiro.
Tiel, ajna alvenanta altprioritata alarmo ne povas resti neprilaborita.
Nun ni vidu de kie povas veni incidentoj.
Kiajn integriĝojn ni uzas?
PD ricevas multajn malsamajn okazaĵojn de diversaj servoj. Ni nuntempe havas ĉirkaŭ 25 tiajn servojn, kaj por prilabori ilin ni uzas kelkajn pretajn integraĵojn.
- Prometeo
La ĉefa metra kolektosistemo estas Prometeo. Oni jam skribis multon pri tio ĉe Habré, mi nur diros, ke ni havas plurajn el ili por diversaj medioj: unu kolektas metrikojn de virtualaj maŝinoj kaj dockers, alia de Amazon-servoj, la tria de aparataro-maŝinoj. Telegraf estas plejparte uzata kiel metrika eksportisto.
- retpoŝto
Ankaŭ ĉi tie, mi pensas, ĉio estas klara el la titolo. Ĉi tiu integriĝo estas uzata por sendi sciigojn de iuj skriptoj efektivigitaj de cron. PD donas al vi certan adreson, al kiu vi sendas leterojn. Kiam vi kreas servon kun tia integriĝo, vi povas agordi prioritatojn, en kia ordo estos procesitaj envenantaj okazaĵoj, kiel ĝuste krei alarmon (por ĉiu envenanta letero, por envenanta letero + certa regulo, ktp.).
- slack
Laŭ mi, tre interesa integriĝo. Estas tempoj kiam io okazas sed ne estas kovrita de okazaĵoj. Tial ni aldonis integriĝon de Slack por krei okazaĵon. Tio estas, vi povas skribi al kompania Slack /callofduty ĉio estas malrapida kaj baldaŭ rompiĝos kaj la PD prilaboros ĝin kaj sendos la okazaĵon al la deĵoranta inĝeniero.
Ni faras:
Ni vidas:
- API
HTTP-integriĝo. Fakte, estas nenio aparte interesa ĉi tie, nur POST-peto kun korpo en JSON-formato. Ekzemple, io interesa: ni uzas ĝin por ekstera viglado uzante . Ĉi tiu servo kontrolas la alireblecon de niaj retejoj el diversaj partoj de la mondo. En la kazo kiam ni ricevas neakcepteblan respondkodon (ekzemple, 502), okazaĵo estas kreita kaj tiam ĉio sekvas la ĉenon priskribitan supre. StatusCake mem havas la kapablon kontroli internajn URL-ojn, SSL-atestilon aŭ domajnan eksvalidiĝon.
- LibreNMS
Ĉi tio estas alia monitora sistemo, vi povas legi pli pri ĝi en ilia retejo . Kun ĝia helpo, ni monitoras retajn interfacojn kaj iDRAC de serviloj.
Ekzistis ankaŭ integriĝoj kiel Datadog, CloudWatch. Vi povas vidi pli pri tio, kio okazis al ili .
Bildigo
La ĉefa raporta sistemo de incidentoj estas Slack. Ĉiuj okazaĵoj venantaj al PD estas skribitaj al speciala babilejo, kaj se ilia statuso ŝanĝiĝas, tio ankaŭ estas montrata en la babilejo.
Kiam aperis la okazo montri utilajn datumojn sur la ekranoj de ekranoj pendantaj de la plafono, ni subite rimarkis, ke ni (en la fako devops) havas nenion por montri sur ili. Estas mirinda Grafana, sed ĝi ne kovras ĉion, kaj dungitoj reagas al atentigoj, ne leteroj.
Post ĝisfunda sed malsukcesa serĉo en GitHub por konciza kaj informa "tabulo" por PD, ni decidis skribi nian propran - nur kun tio, kion ni bezonis. Kvankam komence estis ideo montri la PD-interfacon mem, ĝi aspektis eĉ pli maloportuna.
Por skribi ĝin, vi bezonas nur akiri ŝlosilon de PD kun nurlegeblaj rajtoj.
Kaj jen kion ni ricevis:
La ekrano montras la aktualajn malfermitajn okazaĵojn, la nomon de la nuna inĝeniero deĵoranta de la elektita horaro, kaj la tempon sen alta prioritata okazaĵo (la panelo kun alta prioritata okazaĵo estos elstarigita en ruĝa).
.
Kiel rezulto, ni ricevis oportunan panelon por vidi ĉiujn niajn okazaĵojn. Mi ĝojos, se iuj el vi trovos nian sperton utila.
fonto: www.habr.com