Più complesso è il sistema, più esso si arricchisce di vari allerta. Ne deriva la necessità di rispondere a questi alert, aggregarli e visualizzarli. Penso sia una situazione familiare a molti, tanto da creare nervosismo.
La soluzione di cui parleremo non è delle più inaspettate, ma non ho trovato un articolo completo su questo tema.
Quindi ho deciso di condividere l'esperienza di FunCorp e raccontare come è strutturato il processo di turni, chi chiama, perché e come si può gestire il tutto.
Cos'è PagerDuty?
Dunque, per risolvere tutte queste problematiche, abbiamo iniziato a cercare uno strumento comodo. Dopo una breve ricerca, abbiamo scelto PagerDuty. Ci è sembrato una soluzione sufficientemente completa e concisa, con molte integrazioni e personalizzazioni. Cosa rappresenta?
In breve, PagerDuty è una piattaforma per la gestione degli incidenti, in grado di elaborare incidenti in arrivo tramite varie integrazioni, configurare l'ordine dei turni e notificare l'ingegnere di turno in base al livello dell'incidente (in caso di livello alto - chiamata, in caso di livello basso - notifica push dall'app/sms).
Chi è l'ingegnere di turno?
Probabilmente, questo è il primo aspetto da considerare nella configurazione di PD.
In FunCorp, come in altre aziende, esiste l'onorevole posizione di ingegnere di turno. Questa viene trasferita da un ingegnere all'altro ogni 24 ore. Ci sono una prima e una seconda linea di risposta all'alert di PagerDuty. Supponiamo che arrivi un alert di alta priorità e se dopo 10 minuti dalla chiamata al primo ingegnere di turno non c'è risposta (ossia non è stato cambiato lo stato in riconosciuto o risolto), la chiamata passa al secondo ingegnere di turno. Questo viene impostato su PagerDuty tramite le Politiche di Escalation.
Se anche il secondo ingegnere di turno non risponde, la notifica torna al principale ingegnere di turno.
In questo modo, qualsiasi alert di alta priorità in arrivo non può rimanere senza trattamento.
Ora vediamo da dove possono arrivare gli incidenti.
Quali integrazioni usiamo?
In PD arrivano molteplici incidenti da vari servizi. Attualmente, ne abbiamo circa 25, e per gestirli utilizziamo alcune integrazioni pronte.
- Prometheus
Il sistema principale di raccolta delle metriche è Prometheus. Di lui si è già scritto molto su Habré, dirò solo che ne abbiamo diversi per ambienti differenti: uno raccoglie metriche da macchine virtuali e Docker, un altro dai servizi di Amazon, un terzo da "macchine fisiche". Principalmente come esportatore di metriche usiamo Telegraf.
Qui, penso, sia tutto chiaro dal nome. Questa integrazione è utilizzata per inviare notifiche da alcuni script eseguiti via cron. PD ti fornisce un indirizzo a cui inviare le email. Quando crei un servizio con questa integrazione, puoi impostare le priorità sull'ordine in cui verranno elaborati gli incidenti in arrivo, come creare l'alert (su ogni email ricevuta, su email ricevuta + una certa regola, ecc.).
- Slack
A mio avviso, è un'integrazione piuttosto interessante. Ci sono casi in cui accade qualcosa che non viene coperto da incidenti. Per questo abbiamo aggiunto un'integrazione da Slack per creare un incidente. Cioè, nel Slack aziendale puoi scrivere /callofduty все тормозит и скоро сломается e PD lo elaborerà e invierà l'incidente all'ingegnere di turno.
Facciamo:
Vediamo:
- API
Integrazione tramite HTTP. Qui, in realtà, non c'è nulla di particolarmente interessante, solo una richiesta POST con un corpo in formato JSON. Ad esempio, tra le cose interessanti: lo usiamo per il monitoraggio esterno tramite . Questo servizio verifica la disponibilità dei nostri siti da diversi punti del mondo. Nel caso in cui riceviamo un codice di risposta inaccettabile (ad esempio, 502) viene creato un incidente e il processo continua secondo la catena descritta sopra. All'interno di StatusCake c'è anche la possibilità di monitorare URL interni, la scadenza del certificato SSL o del dominio.
- LibreNMS
Questa è un'altra sistema di monitoraggio, di cui puoi leggere di più sul loro sito . Con esso monitoriamo le interfacce di rete e l'iDRAC dei server.
Ci sono state anche integrazioni come Datadog, CloudWatch. Puoi scoprire di più su cosa è successo con loro .
Visualizzazione
Il principale sistema di informazione sugli incidenti è Slack. Tutti gli incidenti in arrivo in PD vengono scritti in una chat apposita, e se il loro stato cambia, questo viene altresì visualizzato in chat.
Quando è emersa l'opportunità di visualizzare dati utili sugli schermi dei monitor appesi al soffitto, abbiamo improvvisamente capito che a noi (nel dipartimento devops) non rimaneva niente da mostrare. C'è una fantastica Grafana, ma non può coprire tutto, e in più i dipendenti reagiscono agli alert, non ai grafici.
Dopo una ricerca accurata, ma infruttuosa, su GitHub di una "board" concisa e informativa per il PD, abbiamo deciso di scriverne una nostra — solo con ciò che ci serve. Anche se inizialmente avevamo pensato di visualizzare sullo schermo l'interfaccia del PD, ma sembrava ancora più scomodo.
Per scriverla, basta ottenere la chiave dal PD con diritti in sola lettura.
Ecco cosa abbiamo ottenuto:
Sullo schermo vengono visualizzati gli incidenti aperti attuali, il nome dell'ingegnere di turno corrente dal programma selezionato e il tempo senza un incidente di alta priorità (il pannello con l'incidente di alta priorità sarà evidenziato in rosso).
.
Alla fine abbiamo ottenuto una dashboard conveniente per visualizzare tutti i nostri incidenti. Sarò felice se la nostra esperienza sarà utile a qualcuno di voi.
Fonte: habr.com
