SRE ingegnere - tirocinante
Per cominciare, permettetemi di presentarmi. Sono , ingegnere frontend nel gruppo di GitLab. La scorsa settimana ho avuto il privilegio di essere tirocinante presso uno dei nostri ingegneri SRE di turno. L'obiettivo era osservare quotidianamente come il turno reagisce agli incidenti e acquisire esperienza pratica. Ci piacerebbe che i nostri ingegneri comprendessero meglio le esigenze degli utenti Monitor::Health.
Ho dovuto seguire l'ingegnere SRE ovunque per una settimana. Ciò significa che ero presente al cambio di turno, osservavo gli stessi canali di notifiche e reagivo agli incidenti, se e quando si verificavano.
Incidenti
Durante la settimana si sono verificati 2 incidenti.
1. Criptominer
Mercoledì su GitLab.com si è registrato un picco nell'uso del runner, causato dai tentativi di utilizzare i minuti del runner per minare criptovalute. L'incidente è stato gestito utilizzando il nostro strumento di mitigazione delle violazioni, che ferma i job del runner e rimuove il progetto e l'account associati.
Se questo evento non fosse stato notato, sarebbe stato catturato da uno strumento automatizzato, ma in questo caso l'ingegnere SRE ha notato la violazione per primo. È stata creata una task per l'incidente, ma le informazioni al riguardo sono riservate.
2. Degradação delle prestazioni delle applicazioni Canary e Main
L'incidente è stato provocato da rallentamenti e un incremento della frequenza degli errori nelle applicazioni web canary e main su Gitlab.com. Sono state violate diverse metriche Apdex.
Task aperta per l'incidente:
Conclusioni chiave
Ecco alcuni punti che ho compreso durante la settimana di turno.
1. Le notifiche sono più utili quando catturano deviazioni dalla norma.
Le notifiche possono essere suddivise in diversi tipi:
- Notifiche basate su un valore soglia, come "si sono verificati 10 errori 5xx al secondo".
- Notifiche in cui la soglia è una percentuale, come "frequenza di errori 5xx al 10% del volume totale delle richieste in un tempo definito".
- Notifiche basate sulla media storica, come "errori 5xx nel 90° percentile".
In generale, il secondo e il terzo tipo sono più utili per gli SRE di turno, poiché rivelano deviazioni dalla norma nel processo.
2. Molte notifiche non vengono mai elevate a incidenti
Gli ingegneri SRE si confrontano con un flusso costante di notifiche, molte delle quali in realtà non sono critiche.
Perché non limitare le notifiche solo a quelle realmente importanti? Tuttavia, con questo approccio, è possibile non riconoscere i primi sintomi che possono svilupparsi, come una palla di neve, in un vero problema che potrebbe causare ingenti danni.
Il compito del SRE di guardia è proprio quello di determinare quali notifiche parlano davvero di qualcosa di serio e se è necessario scalarle e iniziare a indagare. Sospetto che questo sia anche causato dalla rigidità delle notifiche: sarebbe meglio se venissero introdotti diversi livelli o modi 'intelligenti' per configurare le notifiche in base alla situazione sopra descritta.
Proposta di funzionalità:
3. I nostri SRE di guardia utilizzano molti strumenti
Interni:
- Progetto infrastruttura GitLab: qui vivono i Runbook, i passaggi di guardia per turni/settimane e le attività di risposta agli incidenti.
- Problemi di GitLab: le indagini, le analisi e la manutenzione sono monitorate anche alle attività.
- Etichette di GitLab: le attività di automazione vengono avviate secondo determinate etichette, che i bot utilizzano per monitorare l'attività delle attività.
Esterni:
- PagerDuty: notifiche
- Slack: qui viene diretto il flusso di messaggi da PagerDuty/AlertManager. Integrazione con comandi slash per eseguire vari compiti, come chiudere una notifica o scalarla a incidente.
- Grafana: visualizzazione delle metriche con focus sulle tendenze a lungo termine.
- Kibana: fornisce visualizzazione/cerca nei log, con la possibilità di approfondire eventi specifici.
- Zoom: c'è una 'sala di discussione' Zoom sempre attiva. Questo consente agli ingegneri SRE di discutere rapidamente eventi, senza perdere tempo prezioso per creare una stanza e inviare link ai partecipanti.
E molto, molto altro.
4. Monitorare GitLab.com tramite GitLab è un singolo punto di errore
Se dovesse verificarsi un grande guasto dei servizi su GitLab.com, non vorremmo che questo influisse sulla nostra capacità di risolvere il problema. Può essere contenuto avviando una seconda istanza di GitLab per gestire GitLab.com. In effetti, questo è già attivo per noi: .
5. Alcune funzionalità da considerare per l'aggiunta a GitLab
- , simile a Google Docs. Questo sarebbe utile per le attività sugli incidenti durante un evento, così come per le analisi. In entrambi i casi, più partecipanti potrebbero aver bisogno di aggiungere qualcosa in tempo reale.
- Maggiore numero di webhook per i task. La possibilità di avviare diversi passaggi del flusso di lavoro di GitLab dall'interno aiuterà a ridurre la dipendenza dalle integrazioni con Slack. Ad esempio, la possibilità di abilitare le notifiche in PagerDuty tramite un comando slash in un task di GitLab.
Conclusione
Gli ingegneri SRE affrontano molte sfide. Sarebbe fantastico vedere più prodotti GitLab che affrontano questi problemi. Stiamo già lavorando su alcuni miglioramenti al prodotto che faciliteranno i flussi di lavoro menzionati. I dettagli sono disponibili nella .
Nel 2020 stiamo ampliando il team per raccogliere tutte queste fantastiche funzionalità. Se sei interessato, dai un'occhiata per favore a , e non esitare a contattare qualcuno del nostro team per qualsiasi domanda.
Fonte: habr.com
