Maggiore è la complessità del sistema, più esso genera diversi allerta. Nasce così l'esigenza di rispondere a questi allerta, aggregarli e visualizzarli. Una situazione che credo conna molti fino al nervosismo.
La soluzione di cui parleremo non è delle più sorprendenti, ma non riesco a trovare articoli completi sull'argomento.
Perciò ho deciso di condividere l'esperienza di FunCorp e raccontare come è strutturato il processo di reperibilità, chi chiama, perché e come possiamo monitorare tutto questo.
Che cos'è PagerDuty?
Quindi, per affrontare tutte queste sfide, abbiamo iniziato a cercare uno strumento efficace. Dopo una breve ricerca, abbiamo scelto PagerDuty. PD ci è sembrato una soluzione abbastanza completa e concisa, con molte integrazioni e opzioni di configurazione. Cosa rappresenta?
In breve, PagerDuty è una piattaforma per la gestione degli incidenti, capace di elaborare segnalazioni in arrivo tramite diverse integrazioni, impostare il turno dei datori di lavoro e successivamente attivare un avviso al tecnico di guardia in base al livello dell'incidente (per livelli elevati — chiamata, per livelli bassi — notifiche push dall'app/SMS).
Chi è il tecnico di guardia?
Probabilmente, è il primo passo per impostare PD.
In FunCorp, come in altre aziende, esiste la posizione onorevole di tecnico di guardia. Questa posizione viene trasferita da un ingegnere all’altro una volta al giorno. Esistono una prima e una seconda linea di risposta agli avvisi di PagerDuty. Supponiamo che arrivi un avviso di alta priorità e, se dopo 10 minuti dalla chiamata al tecnico di guardia della prima linea non c'è risposta (cioè non è stato cambiato in stato di riconoscimento o risolto), la chiamata passa al secondo tecnico di guardia. Questo viene impostato direttamente in PagerDuty attraverso le Politiche di Escalation.
Se anche il secondo tecnico di guardia non risponde, l'avviso torna indietro al tecnico di guardia principale.
In questo modo, qualsiasi avviso di alta priorità in arrivo non può rimanere senza risposta.
Ora vediamo da dove possono arrivare gli incidenti.
Quali integrazioni utilizziamo?
In PD si verificano molti incidenti diversi provenienti da vari servizi. Attualmente abbiamo circa 25 di questi servizi e per gestirli utilizziamo alcune integrazioni pronte.
- Prometheus
Il sistema principale di raccolta delle metriche è Prometheus. Di questo si è già scritto molto su Habra, posso solo dire che ne abbiamo diversi per ambienti diversi: uno raccoglie metriche dalle macchine virtuali e dai container, un altro da servizi Amazon, un terzo da macchine fisiche. In generale, Telegraf è utilizzato come esportatore di metriche.
Qui credo che sia tutto chiaro dal nome. Questa integrazione è utilizzata per inviare notifiche da alcuni script eseguiti tramite cron. PD ti fornisce un indirizzo al quale invii le email. Quando crei un servizio con questa integrazione, puoi impostare le priorità riguardo l'ordine in cui saranno elaborati gli incidenti in arrivo, e come creare l'alert (per ogni email in arrivo, per l'email in arrivo + una certa regola, ecc.).
- Slack
A mio parere, si tratta di un'integrazione piuttosto interessante. Ci sono casi in cui accade qualcosa, ma non vengono generati incidenti. Pertanto, abbiamo aggiunto un'integrazione da Slack per la creazione di incidenti. Vale a dire, nel Slack aziendale è possibile 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: la utilizziamo per il monitoraggio esterno tramite . Questo servizio verifica la disponibilità dei nostri siti da vari punti del mondo. Nel caso in cui riceviamo un codice di risposta inaccettabile (ad esempio, 502), viene creato un incidente e poi tutto prosegue secondo la catena descritta sopra. Nel 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 essa monitoriamo le interfacce di rete e l'iDRAC dei server.
Ci sono state anche integrazioni come Datadog, CloudWatch. Puoi vedere ulteriori dettagli su cosa è successo con loro. .
Visualizzazione
Il sistema principale per la segnalazione degli incidenti è Slack. In una chat dedicata vengono registrati tutti gli incidenti che arrivano in PD e qualsiasi cambio di stato viene anche visualizzato nella chat.
Quando abbiamo avuto l'opportunità di mostrare dati utili sugli schermi appesi al soffitto, ci siamo resi conto che noi (nel dipartimento devops) non avevamo nulla da mostrare. C'è una fantastica Grafana, ma non può coprire tutto, e i dipendenti reagiscono agli allerta, non ai grafici.
Dopo una ricerca attenta, ma infruttuosa su GitHub di una 'board' concisa e informativa per PD, abbiamo deciso di crearne una nostra — solo con ciò che ci serve. Inizialmente, avevamo l'idea di visualizzare l'interfaccia di PD, ma sembrava ancora più scomodo.
Per scriverla, basta ottenere una chiave da PD con diritti di sola lettura.
Ecco il risultato finale:
Sullo schermo vengono visualizzati gli incidenti aperti attuali, il nome dell'ingegnere di turno dall'orario selezionato e il tempo trascorso senza un incidente di alta priorità (il pannello con l'incidente di alta priorità verrà evidenziato in rosso).
.
Alla fine abbiamo ottenuto un dashboard pratico per visualizzare tutti i nostri incidenti. Spero che la nostra esperienza possa essere utile a qualcuno di voi.
Fonte: habr.com
