Ingegnere SRE - tirocinante
Innanzitutto, lasciatemi presentare me stesso. Sono , ingegnere frontend nel gruppo GitLab. La scorsa settimana ho avuto il privilegio di fare uno stage per uno dei nostri ingegneri SRE di turno. L'obiettivo era osservare come l'ingegnere di turno risponde quotidianamente agli incidenti e acquisire esperienza pratica. Vogliamo che i nostri ingegneri comprendano meglio le esigenze degli utenti. Monitor::Salute.
Avrei dovuto affiancare l'ingegnere SRE per una settimana, il che significava che avrei partecipato ai passaggi di consegne, monitorato gli stessi canali di allerta e risposto agli incidenti se e quando si verificavano.
incidenti
Ci sono stati 2 incidenti durante la settimana.
1. Cryptominer
GitLab.com ha registrato un picco di utilizzo mercoledì 'a, causato dai tentativi di utilizzare i minuti di esecuzione per estrarre criptovalute. L'incidente è stato gestito utilizzando uno strumento di mitigazione proprietario che blocca le attività di esecuzione ed elimina il progetto e l'account ad esso associato.
Se questo evento non fosse stato notato, sarebbe stato rilevato da uno strumento automatico, ma in questo caso è stato il tecnico SRE a notare la violazione per primo. È stata creata un'attività per l'incidente, ma le informazioni relative sono chiuse.
2. Degrado delle prestazioni delle applicazioni Canary e Main
L'incidente è stato causato da rallentamenti e dall'aumento dei tassi di errore nelle applicazioni web canary e main su Gitlab.com. Sono stati violati diversi valori Apdex.
Apri attività per incidente:
Risultati chiave
Ecco alcune cose che ho imparato durante la mia settimana di servizio.
1. Gli avvisi sono più utili quando rilevano deviazioni dalla norma.
Le notifiche possono essere suddivise in diversi tipi:
- Avvisi basati su una determinata soglia, ad esempio "Si sono verificati 10 5xx errori al secondo".
- Avvisi in cui la soglia è un valore percentuale, ad esempio "tasso di errori 5xx per il 10% del volume totale delle richieste in un dato momento".
- Avvisi basati su medie storiche come "errori 5xx nel 90° percentile".
In generale, i tipi 2 e 3 sono più utili per gli SRE di turno perché evidenziano le deviazioni dalla norma nel processo.
2. Molti avvisi non si trasformano mai in incidenti
Gli ingegneri SR devono gestire un flusso costante di avvisi, molti dei quali non sono effettivamente critici.
Perché non limitare gli avvisi a quelli veramente importanti? Tuttavia, questo approccio rischia di non cogliere i segnali premonitori di ciò che potrebbe trasformarsi in un problema reale, con conseguenti danni ingenti.
Il compito dell'SRE in servizio è determinare quali avvisi siano realmente gravi e se sia necessario un'escalation e un'indagine. Sospetto che ciò sia dovuto anche alla rigidità degli avvisi: sarebbe meglio se ci fossero più livelli o modi "intelligenti" per configurare gli avvisi in base alla situazione descritta sopra.
Suggerimento per le funzionalità:
3. I nostri SRE di guardia utilizzano molti strumenti
Interno:
- Progetto infrastrutturale GitLab: sede di Runbook, passaggi di consegne di turni/settimane e attività di risposta agli incidenti.
- Problemi di GitLab: indagini, revisioni e manutenzione vengono anch'essi monitorati nelle attività.
- Etichette GitLab: le attività di automazione vengono attivate da etichette specifiche, che i bot utilizzano per tracciare l'attività delle attività.
Esterno:
- PagerDuty: Avvisi
- Slack: qui è dove va il flusso di messaggi di PagerDuty/AlertManager. Si integra con i comandi slash per eseguire varie attività, come la chiusura di un avviso o l'escalation di un incidente.
- Grafana: visualizzazione delle metriche con particolare attenzione alle tendenze a lungo termine.
- Kibana: consente la visualizzazione/ricerca dei registri, la possibilità di approfondire eventi specifici.
- Zoom: Zoom offre una "breakout room" permanente. Questo consente agli SRE di discutere rapidamente gli eventi senza dover perdere tempo prezioso a creare una stanza e a condividere il link con i partecipanti.
E molto, molto di più.
4. Il monitoraggio di GitLab.com con GitLab è un singolo punto di errore
Se GitLab.com subisce un'interruzione importante, non vogliamo che ciò influisca sulla nostra capacità di risolvere il problema. Possiamo mitigare il problema eseguendo una seconda istanza di GitLab per gestire GitLab.com. In effetti, abbiamo già questa funzionalità: .
5. Alcune funzionalità da considerare per l'aggiunta a GitLab
- , simile a Google Docs. Questo potrebbe essere utile per le attività di gestione degli incidenti durante un evento, così come per le attività di debriefing. In entrambi i casi, più partecipanti potrebbero dover aggiungere qualcosa in tempo reale.
- Più webhook per le attività. La possibilità di attivare dall'interno diverse fasi di un flusso di lavoro GitLab contribuirà a ridurre la dipendenza dalle integrazioni con Slack. Ad esempio, la possibilità di abilitare le notifiche a PagerDuty tramite un comando slash in un'attività GitLab.
conclusione
Gli ingegneri SRE hanno difficoltà a gestire molte complessità. Sarebbe fantastico vedere più prodotti GitLab che affrontino queste problematiche. Stiamo già lavorando ad alcune aggiunte di prodotto che semplificheranno i flussi di lavoro sopra menzionati. I dettagli sono disponibili all'indirizzo .
Stiamo ampliando il nostro team nel 2020 per riunire tutte queste fantastiche funzionalità. Se sei interessato, dai un'occhiata a e non esitate a contattare un membro del nostro team per qualsiasi domanda.
Fonte: habr.com
