Più il sistema è complesso, più diventa invaso da tutti i tipi di avvisi. E c’è bisogno di reagire a questi stessi avvisi, aggregarli e visualizzarli. Penso che questa sia una situazione familiare a molti fino al nervosismo.
La soluzione che verrà discussa non è delle più inaspettate, ma la ricerca non restituisce un articolo completo su questo argomento.
Pertanto, ho deciso di condividere l'esperienza di FunCorp e parlare di come è strutturato il processo di servizio, chi chiama, perché e come puoi guardare il tutto.
Cos'è PagerDuty?
Quindi, per risolvere tutti questi problemi, abbiamo iniziato a cercare uno strumento conveniente. Dopo alcune ricerche, abbiamo scelto PagerDuty. PD ci è sembrata una soluzione abbastanza completa e concisa con un gran numero di integrazioni e impostazioni. Com'è lei?
In breve, PagerDuty è una piattaforma di elaborazione degli incidenti in grado di elaborare gli incidenti in arrivo attraverso varie integrazioni, impostare ordini di servizio e quindi avvisare l'ingegnere di turno a seconda del livello dell'incidente (ad alto livello - una chiamata, a basso livello - un push dall'applicazione/SMS).
Chi è l'ufficiale di turno?
Questo è probabilmente il primo posto da cui iniziare a creare PD.
Alla FunCorp, come ad altre società, esiste una posizione onoraria di ufficiale di servizio. Viene trasmesso da ingegnere a ingegnere una volta al giorno. Esiste una cosiddetta prima e seconda linea di risposta a un avviso di PagerDuty. Supponiamo che arrivi un avviso ad alta priorità e se 10 minuti dopo la chiamata al tecnico di turno dalla prima linea non vi è alcuna reazione (cioè non viene trasferito allo stato di riconoscimento o risolto), la chiamata passa alla seconda ingegnere di turno. Questo è configurato nello stesso PagerDuty tramite le politiche di escalation.
Se il secondo ufficiale di turno non risponde, la notifica ritorna a il principale all'ufficiale di servizio.
Pertanto, qualsiasi avviso ad alta priorità in arrivo non può rimanere non elaborato.
Ora vediamo da dove possono arrivare gli incidenti.
Quali integrazioni utilizziamo?
Il PD riceve molti incidenti diversi da vari servizi. Al momento disponiamo di circa 25 servizi di questo tipo e per elaborarli utilizziamo alcune integrazioni già pronte.
- Prometeo
Il principale sistema di raccolta delle metriche è Prometheus. Su Habré è già stato scritto molto a riguardo, dico solo che ne abbiamo diversi per ambienti diversi: uno raccoglie metriche da macchine virtuali e docker, un altro dai servizi Amazon, il terzo da macchine hardware. Telegraf è utilizzato principalmente come esportatore di metriche.
Anche qui, credo, tutto sia chiaro fin dal titolo. Questa integrazione viene utilizzata per inviare notifiche da alcuni script eseguiti da cron. PD ti fornisce un determinato indirizzo a cui inviare le lettere. Quando si crea un servizio con tale integrazione, è possibile impostare le priorità, in quale ordine verranno elaborati gli incidenti in arrivo, come creare esattamente un avviso (per ogni lettera in arrivo, per una lettera in arrivo + una determinata regola, ecc.).
- Slack
A mio parere, un'integrazione molto interessante. Ci sono momenti in cui succede qualcosa ma non è coperto da incidenti. Pertanto, abbiamo aggiunto l'integrazione da Slack per creare un incidente. Cioè, puoi scrivere a Slack aziendale /callofduty tutto è lento e si romperà presto e il PD lo elaborerà e invierà l'incidente all'ingegnere di turno.
Facciamo:
Vediamo:
- API
Integrazione HTTP. In effetti qui non c'è nulla di particolarmente interessante, solo una richiesta POST con un corpo in formato JSON. Ad esempio, qualcosa di interessante: lo usiamo per il monitoraggio esterno utilizzando . Questo servizio verifica l'accessibilità dei nostri siti da diverse parti del mondo. Nel caso in cui riceviamo un codice di risposta inaccettabile (ad esempio 502), viene creato un incidente e quindi tutto segue la catena sopra descritta. StatusCake stesso ha la capacità di monitorare URL interni, certificato SSL o scadenza del dominio.
- FreeNMS
Questo è un altro sistema di monitoraggio, puoi leggere di più sul loro sito web . Con il suo aiuto, monitoriamo le interfacce di rete e iDRAC dai server.
C'erano anche integrazioni come Datadog, CloudWatch. Puoi vedere di più su cosa è successo loro .
Visualizzazione
Il principale sistema di segnalazione degli incidenti è Slack. Tutti gli incidenti che arrivano al PD vengono scritti in una chat speciale e, se il loro stato cambia, anche questo viene visualizzato nella chat.
Quando si è presentata l'opportunità di visualizzare dati utili sugli schermi dei monitor appesi al soffitto, ci siamo improvvisamente resi conto che noi (del reparto devops) non avevamo nulla da visualizzare su di essi. Esiste un meraviglioso Grafana, ma non copre tutto e i dipendenti reagiscono agli avvisi, non ai grafici.
Dopo una ricerca approfondita ma infruttuosa su GitHub per una "scheda" concisa e informativa per PD, abbiamo deciso di scriverne una nostra, solo con ciò di cui avevamo bisogno. Sebbene all'inizio ci fosse l'idea di visualizzare l'interfaccia PD stessa, sembrava ancora più scomoda.
Per scriverlo è sufficiente ottenere una chiave da un PD con diritti di sola lettura.
E questo è ciò che abbiamo ottenuto:
La schermata visualizza gli incidenti attualmente aperti, il nome del tecnico attualmente in servizio dal programma selezionato e il tempo in cui non si è verificato un incidente ad alta priorità (il pannello con un incidente ad alta priorità sarà evidenziato in rosso).
.
Di conseguenza, abbiamo ricevuto una comoda dashboard per visualizzare tutti i nostri incidenti. Sarò felice se qualcuno di voi troverà utile la nostra esperienza.
Fonte: habr.com