Ingegnere SRE - tirocinante
Per prima cosa, lascia che mi presenti. IO - , ingegnere front-end del gruppo GitLab. La settimana scorsa ho avuto l'onore di fare uno stage con uno dei nostri ingegneri SRE di guardia. L'obiettivo era osservare come l'ufficiale in servizio rispondeva quotidianamente agli incidenti e acquisire un'esperienza di vita reale sul lavoro. Vorremmo che i nostri ingegneri comprendessero meglio le esigenze degli utenti Monitorare::Salute.
Ho dovuto seguire l'ingegnere SRE ovunque per una settimana. Cioè, ero presente al passaggio di consegne, monitoravo gli stessi canali di allerta e rispondevo agli incidenti se e quando si verificavano.
incidenti
Ci sono stati 2 incidenti in una settimana.
1. Minatore di criptovalute
Mercoledì GitLab.com ha registrato un aumento nell'utilizzo 'a, causato dai tentativi di utilizzare i minuti del corridore per estrarre criptovaluta. L’incidente è stato gestito utilizzando il nostro strumento di neutralizzazione delle violazioni, che interrompe le attività del corridore ed elimina il progetto e l’account ad esso associato.
Se questo evento non fosse stato notato, uno strumento automatizzato lo avrebbe rilevato, ma in questo caso l'ingegnere SRE ha notato per primo la violazione. È stata creata un'attività incidente, ma le informazioni su di essa sono chiuse.
2. Degrado delle prestazioni delle applicazioni Canary e Main
L'incidente è stato causato da rallentamenti e da una maggiore frequenza di errori nel canary e nelle principali applicazioni web su Gitlab.com. Sono stati violati diversi valori Apdex.
Apri attività incidente:
Risultati chiave
Ecco alcune cose che ho imparato durante la mia settimana di servizio.
1. Gli avvisi sono particolarmente utili quando si rilevano deviazioni dalla norma.
Gli avvisi possono essere suddivisi in diversi tipi:
- Avvisi basati su un determinato valore di soglia, ad esempio "Si sono verificati 10 errori 5xx al secondo".
- Avvisi in cui la soglia è un valore percentuale come "frequenza di errori 5xx per il 10% del volume totale di richieste in un dato momento".
- Avvisi basati sulla media storica come "errori 5xx al 90° percentile".
In generale, i tipi 2 e 3 sono più utili per gli SRE in servizio, poiché rivelano deviazioni dalla norma nel processo.
2. Molti avvisi non si trasformano mai in incidenti.
Gli ingegneri SR si occupano di un flusso costante di avvisi, molti dei quali non sono realmente critici.
Allora perché non limitare i tuoi avvisi solo a quelli veramente importanti? Con questo approccio, tuttavia, potresti non riconoscere i primi sintomi di ciò che si trasformerà in un problema reale che minaccia gravi danni.
Il compito dell'SRE di guardia è determinare quali avvisi indicano effettivamente qualcosa di serio e se devono essere intensificati e gestiti. Ho il sospetto che ciò sia dovuto anche alla rigidità degli alert: sarebbe meglio se esistessero più livelli o modi “intelligenti” per configurare gli alert in base alla situazione sopra descritta.
Suggerimento sulle funzionalità:
3. I nostri SRE in servizio utilizzano molti strumenti.
Interno:
- Progetto infra GitLab: runbook pubblicati qui, assegnazioni di turni/settimane, attività di risposta agli incidenti.
- Problemi GitLab: anche le indagini, le revisioni e la manutenzione vengono tracciate nei problemi.
- Etichette GitLab: le attività di automazione vengono avviate utilizzando etichette specifiche, che i bot utilizzano per tenere traccia dell'attività delle attività.
Esterno:
- PagerDuty: avvisi
- Slack: il flusso dei messaggi PagerDuty/AlertManager va qui. Integrazione con comandi barra per eseguire una varietà di attività, come chiudere un avviso o passare a un incidente.
- Grafana: visualizzazione di metriche con focus sui trend a lungo termine.
- Kibana: offre visualizzazione/ricerca nei registri, capacità di scavare più a fondo in eventi specifici.
- Zoom: in Zoom è presente una "sala riunioni" costantemente attiva. Ciò consente agli ingegneri SRE di discutere rapidamente gli eventi senza perdere tempo prezioso creando una stanza e collegando i partecipanti.
E molto, molto di più.
4. Il monitoraggio di GitLab.com con GitLab è un singolo punto di errore
Se GitLab.com dovesse subire una grave interruzione del servizio, non vogliamo che ciò influisca sulla nostra capacità di risolvere il problema. Può essere interrotto avviando una seconda istanza GitLab per gestire GitLab.com. In effetti, questo funziona già per noi: .
5. Alcune funzionalità da considerare di aggiungere a GitLab
- , simile a Google Docs. Ciò aiuterebbe con le attività sugli incidenti durante un evento, nonché con 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 eseguire diversi passaggi del flusso di lavoro GitLab dall'interno ti aiuterà a ridurre la tua dipendenza dalle integrazioni Slack. Ad esempio, la possibilità di consentire un avviso in PagerDuty tramite un comando slash in un problema di GitLab.
conclusione
Gli ingegneri SRE hanno difficoltà a causa di molte complessità. Sarebbe bello vedere più prodotti GitLab che affrontano questi problemi. Stiamo già lavorando su alcune aggiunte al prodotto che renderanno più semplici i flussi di lavoro sopra menzionati. Dettagli disponibili su .
Stiamo espandendo il team nel 2020 per riunire tutte queste fantastiche funzionalità. Se interessati, controlla e non esitate a contattare chiunque nel nostro team per qualsiasi domanda.
Fonte: habr.com