Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com

Il nostro team ama sperimentare. Ogni Slёrm non è una ripetizione statica della precedente, ma una riflessione sull'esperienza e un passaggio dal buono al migliore. Ma con Slёrm SRE abbiamo deciso di applicare un formato completamente nuovo: creare condizioni per i partecipanti il più vicine possibile a quelle 'di battaglia'.

In breve, ecco cosa abbiamo fatto durante il workshop: 'Costruiamo, rompiamo, ripariamo,
studiamo'. L'SRE non vale molto nella pura teoria — solo la pratica, soluzioni reali, problemi reali.

I partecipanti sono stati divisi in squadre, affinché lo spirito competitivo non permettesse a nessuno di addormentarsi o di avviare 'Angry Birds' sul proprio iPhone, seguendo l'esempio di Dmitry Anatol'evich.

Problemi, glitch, bug e compiti sono stati forniti a quattro mentor. Ivan Kruglov, Principal Developer in Booking.com (Paesi Bassi). Ben Tyler, Principal Developer in Booking.com (Stati Uniti). Eduard Medvedev, CTO in Tungsten Labs (Germania). Evgeny Varavva, sviluppatore di ampie competenze in Google (San Francisco).

Inoltre, i partecipanti sono divisi in squadre e si sfidano tra loro. Interessante?

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
Ivan, Ben, Eduard ed Evgeny guardano i poveri partecipanti di Slёrm SRE con un sorriso benevolo prima dell'inizio della competizione.

Quindi, il compito è:

Noi siamo, costruiremo un nuovo mondo…

C'è un sito aggregatore di biglietti per il cinema. Gli incidenti sono ideati dai mentori in uno scenario ben definito (anche se nessuno esclude un'improvvisazione particolarmente elaborata e astuta), e la funzionalità del sito è descritta attraverso varie metriche. I problemi possono essere i più diversi: i biglietti per il teatro 'Moulin Rouge' non vengono caricati nel database; i manifesti di film e spettacoli vengono caricati nel database in più di 10 secondi; la descrizione di un film si blocca; lo 0,1% degli ordini cade già su posti riservati; periodicamente, il sistema di elaborazione dei pagamenti si ferma per un minuto o due. E molte, molte altre cose sgradevoli che possono colpire un partecipante di Slurm SRE nel suo lavoro reale.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
Siamo pronti a affrontare tutto… e tutti.

Il nostro sito, tanto travagliato, è composto da diversi microservizi. La sua funzione è aggregare dati su proiezioni, prezzi e posti disponibili in tutte le sale cinematografiche, mostrando le anteprime dei film e consentendo di scegliere cinema, orari, sala e posto, prenotare e pagare i biglietti. Insomma, tutto ciò di cui un spettatore potrebbe sognare. Tuttavia, l'utente non sospetta nemmeno la titanica lotta per la stabilità e la disponibilità del sito che avviene al suo interno.

Per il sito dell'intensivo, abbiamo definito metriche SLO, SLI, SLA, sviluppato architettura e infrastruttura, implementato il sito, configurato il monitoraggio e l'allerta. E così è iniziato.

SLO, SLI, SLA

SLI — indicatori di livello di servizio. SLO — obiettivi di livello di servizio. SLA — accordi di livello di servizio.

SLA — termine della metodologia ITIL, che indica un contratto formale tra il cliente del servizio e il suo fornitore, contenente una descrizione del servizio, i diritti e doveri delle parti e, soprattutto, il livello di qualità concordato per la fornitura di tale servizio.

SLO — è l'obiettivo del livello di servizio: un valore target o un intervallo di valori per il livello di servizio, misurato dallo SLI. Il valore normale per un SLO è «SLI ≤ valore target» o «limite inferiore ≤ SLI ≤ limite superiore».

SLI è l'indicatore del livello di servizio — una misura quantitativa ben definita di uno degli aspetti del livello di servizio fornito. Per la maggior parte dei servizi, il principale SLI è il tempo di risposta della richiesta — quanto tempo ci vuole per restituire una risposta alla richiesta. Altri SLI comuni includono il tasso di errore, spesso espresso come quota di tutte le richieste ricevute, e la larghezza di banda del sistema, di solito misurata in richieste al secondo.

Prima di tutto rompiamo gli aerei, e poi... le ragazze, le ragazze dopo...

Fattori interni ed esterni hanno iniziato a «rovinare» gli SLO fin dai primi momenti. Gli amministratori si sono trovati sopraffatti — errori degli sviluppatori, guasti dell'infrastruttura, afflusso di visitatori e attacchi DDoS. Tutto ciò che compromette gli SLO.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
«- Cari partecipanti, sono felice di annunciarvi, prima di tutto il vostro sistema si arresta... tutto!»

Nel corso dell'incontro, i relatori hanno discusso la resilienza, il budget degli errori, la pratica del testing, la gestione delle interruzioni e del carico operativo.

Non siamo né fornai, né falegnami...

Qui i partecipanti hanno cominciato a riparare: è fondamentale capire da che cosa iniziare.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
«- Santo cielo, non ho mai visto qualcosa di simile rompersi in questo modo e in questa posizione!»

Dunque, si è verificato un guasto. Il servizio di elaborazione pagamenti è crollato. Come comportarsi per ripristinare la funzionalità nel minor tempo possibile?

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
Gli esperti, lanciando occhiate affettuose ai partecipanti, preparano un altro imprevisto.

Ogni squadra organizza il lavoro del gruppo per risolvere l'emergenza: coinvolge i colleghi, informa gli interessati (stakeholders). Nel frattempo, vengono stabiliti i priorità. Così i partecipanti si sono esercitati a lavorare sotto pressione in condizioni di tempo estremamente limitato.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
«- Che orrore è mai questo?!»

Hanno respirato… e hanno concluso l'esercizio.

Insieme ai relatori, dopo ogni problema risolto e il sito temporaneamente stabilizzato, il team ha esaminato gli incidenti dal punto di vista SRE. Sono state analizzate in dettaglio le problematiche — le cause, il processo di risoluzione. Successivamente, sia a livello di squadra che collettivamente, sono state prese decisioni su come prevenire incidenti futuri: come migliorare il monitoraggio, come modificare correttamente l'architettura, come rivedere l'approccio allo sviluppo e all'operatività, come apportare correzioni ai regolamenti. I relatori hanno dimostrato la pratica del post-mortem.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com
«- Chi altro vuole soffrire? — Io!»

Sullo schermo elettronico venivano registrati in modo chiaro e preciso i successi dei team.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com

I quest informatici sono uno strumento straordinario per imparare parole in inglese.

Slurm SRE. Un esperimento continuo con esperti di Booking.com e Google.com

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster