SRE-ingegnere - tirocinante
Per cominciare, lasciate che mi presenti. Io sono , ingegnere front-end nel team di GitLab. La scorsa settimana ho avuto il privilegio di essere un tirocinante presso uno dei nostri ingegneri SRE in turno. L'obiettivo era monitorare quotidianamente come l'ingegnere in turno reagisse agli incidenti, acquisendo così esperienza pratica. Volevamo che i nostri ingegneri comprendessero meglio le esigenze degli utenti Monitor::Health.
Per una settimana ho seguito l'ingegnere SRE ovunque. Cioè, ero presente durante il passaggio del turno, osservando gli stessi canali di notifica e reagendo agli incidenti, se e quando si presentavano.
Incidenti
Durante la settimana ci sono stati 2 incidenti.
1. Minatore di criptovalute
Mercoledì su GitLab.com è stato registrato un aumento nell'uso del runner, causato da tentativi di utilizzare le ore del runner per il mining di criptovalute. L'incidente è stato risolto utilizzando il nostro strumento interno di neutralizzazione 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 intercettato da uno strumento automatico, ma in questo caso l'ingegnere SRE ha notato prima la violazione. È stato creato un ticket per l'incidente, tuttavia le informazioni a riguardo sono riservate.
2. Degradazione delle performance delle applicazioni Canary e Main
L'incidente è stato provocato da rallentamenti e un'aumentata frequenza di errori nelle applicazioni web canary e main su Gitlab.com. Sono stati compromessi diversi valori Apdex.
Ticket aperto per l'incidente:
Conclusioni chiave
Ecco alcuni punti che ho appreso durante la settimana di guardia.
1. Le notifiche sono più utili quando rilevano deviazioni dalla norma.
Le notifiche possono essere suddivise in diversi tipi:
- Notifiche basate su una soglia fissa, tipo 'si sono verificati 10 errori 5xx al secondo'.
- Notifiche in cui la soglia è una percentuale, tipo 'frequenza di errori 5xx al 10% del volume totale delle richieste in un determinato tempo'.
- Notifiche basate sulla media storica, tipo 'errori 5xx nel 90° percentile'.
In generale, il secondo e il terzo tipo sono più utili per gli SRE in turno, poiché rivelano deviazioni dalla norma nel processo.
2. Molti avvisi non vengono mai escalati a incidenti
Gli ingegneri SR si occupano di un flusso costante di avvisi, molti dei quali non sono effettivamente critici.
Perché non limitare gli avvisi solo a quelli realmente importanti? Tuttavia, con questo approccio, potresti non riconoscere i primi segnali di qualcosa che si trasformerà in un vero problema, con conseguenze gravi.
Il compito del SRE in servizio è determinare quali avvisi segnalano davvero qualcosa di serio, e se devono essere escalati e approfonditi. Sospetto che ciò sia causato anche dalla rigidità degli avvisi: sarebbe meglio avere diversi livelli o modalità "intelligenti" per configurare gli avvisi in base alla situazione descritta.
Proposta di funzionalità:
3. I nostri SRE in servizio utilizzano molti strumenti
Interni:
- Progetto infrastruttura GitLab: qui vivono i Runbook, i passaggi di turno per il cambio/settimana, e le attività di gestione degli incidenti.
- Problemi GitLab: le indagini, gli approfondimenti e la manutenzione vengono tracciati anche attraverso i problemi.
- Le etichette di GitLab: le attività di automazione partono da etichette specifiche, che i bot utilizzano per monitorare l'attività delle attività.
Esterni:
- PagerDuty: notifiche
- Slack: qui viene inviato il flusso di messaggi da PagerDuty/AlertManager. Integrazione con comandi slash per eseguire diverse attività, come chiudere una notifica o escalare a un incidente.
- Grafana: visualizzazione delle metriche focalizzandosi su tendenze a lungo termine.
- Kibana: fornisce visualizzazione/ricerca nei log, con la possibilità di approfondire specifici eventi.
- Zoom: c'è una "sala di discussione" sempre attiva su Zoom. Questo consente agli ingegneri SRE di discutere rapidamente degli eventi, senza sprecare tempo prezioso per creare una sala e inviare il link ai partecipanti.
E molto, molto altro.
4. Monitoraggio di GitLab.com tramite GitLab — è un unico punto di fallimento
Se si verifica 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 realtà, questo è già in funzione da parte nostra: .
5. Diverse funzionalità da considerare per l'aggiunta a GitLab
- , simile a Google Docs. Questo aiuterebbe nelle attività legate agli incidenti durante l'evento, nonché nelle attività di analisi. In entrambi i casi, più partecipanti potrebbero aver bisogno di aggiungere qualcosa in tempo reale.
- Maggiore supporto per i webhook nelle attività. La possibilità di attivare vari passaggi del flusso di lavoro di GitLab dall'interno aiuterà a ridurre la dipendenza dalle integrazioni di Slack. Ad esempio, la possibilità di inviare notifiche a PagerDuty tramite un comando slash nell'attività di GitLab.
Conclusione
Gli ingegneri SRE affrontano molte sfide. Sarebbe fantastico vedere più prodotti GitLab per risolvere questi problemi. Stiamo già lavorando a alcuni miglioramenti del prodotto che faciliteranno i flussi di lavoro menzionati sopra. I dettagli sono disponibili nella .
Nel 2020 stiamo ampliando il team per raccogliere tutte queste fantastiche funzionalità. Se sei interessato, ti invitiamo a dare un'occhiata a , e non esitare a contattare qualcuno del nostro team per qualsiasi domanda.
Fonte: habr.com
