Il nostro team ama gli esperimenti. Ogni Slerm non è una ripetizione statica del precedente, ma una riflessione sull'esperienza e un passaggio dal buono al migliore. Ma con abbiamo deciso di applicare un formato completamente nuovo: fornire ai partecipanti condizioni il più simili possibili a quelle "di combattimento".
Per fare un breve riassunto di ciò che abbiamo fatto durante l’intensivo: "Costruiamo, rompiamo, ripariamo,
studiamo". SRE non vale molto in teoria pura: solo pratica, soluzioni reali, problemi reali.
I partecipanti sono stati divisi in squadre, affinché l'allegra competizione non lasciasse spazio a nessuno per addormentarsi o avviare "Angry Birds" sull'iPhone come esempio di Dmitrij Anatol'evič.
I problemi, i bug, le difficoltà e le attività sono stati a disposizione dei partecipanti grazie a quattro mentori. Ivan Kruglov, Principal Developer in Booking.com (Paesi Bassi). Ben Tyler, Principal Developer in Booking.com (USA). Eduard Medvedev, CTO in Tungsten Labs (Germania). Evgenij Varavva, sviluppatore polivalente in Google (San Francisco).
E i partecipanti sono divisi in squadre, competendo tra di loro. Interessante?
Ivan, Ben, Eduard ed Evgenij guardano i poveri partecipanti dello Slerm SRE con un amorevole sorriso alla Lenin prima dell'inizio della competizione.
Quindi la sfida:
Noi costruiremo il nostro, un nuovo mondo...
C'è un sito aggregatore di biglietti per il cinema. Gli incidenti sono creati dai mentori in uno script prestabilito (anche se nessuno esclude una raffinata e insidiosa improvvisazione), la funzionalità del sito è descritta da varie metriche. I problemi possono essere i più diversi: i biglietti per il teatro "Moulin Rouge" non vengono caricati nel database; i poster di film e spettacoli vengono caricati nel database in più di 10 secondi; la descrizione di un film specifico si blocca; il 0,1% degli ordini va su posti già riservati; periodicamente il sistema di elaborazione dei pagamenti si ferma per un minuto o due. E tante, tante, tante cose spiacevoli che possono capitare a un partecipante dello Slerm SRE nel suo lavoro reale.
Siamo pronti ad affrontare tutto... e tutti.
Il nostro sito tanto sofferto è composto da diversi microservizi. Il suo scopo è l'aggregazione dei dati su proiezioni, prezzi e posti disponibili di tutti i cinema, mostra i trailer dei film, consente di scegliere il cinema, la proiezione, la sala e il posto, e di prenotare e pagare i biglietti. Insomma, tutto ciò di cui lo spettatore può solo sognare. Solo che l'utente non sospetta nemmeno quale titanica lotta per la stabilità e la disponibilità del sito si svolga al suo interno.
Per il sito dell'intensivo abbiamo definito i parametri SLO, SLI, SLA, sviluppato l'architettura e l'infrastruttura, deployato il sito, configurato il monitoraggio e l'alerting. E si è cominciato.
SLO, SLI, SLA
SLI è l'indicatore del livello di servizio. SLO sono gli obiettivi del livello di servizio. SLA sono gli accordi sul livello di servizio.
L'SLA è un termine della metodologia ITIL che designa un contratto formale tra il cliente del servizio e il suo fornitore, contenente una descrizione del servizio, diritti e doveri delle parti e, soprattutto, il livello di qualità concordato per la fornitura di questo servizio.
Lo SLO è l'obiettivo del livello di servizio: un valore target o un intervallo di valori per il livello di servizio, misurato dall'SLI. Un valore normale per l'SLO è 'SLI ≤ valore target' o 'limite inferiore ≤ SLI ≤ limite superiore'.
L'SLI è un indicatore del livello di servizio: una misura quantitativa rigorosamente definita di uno degli aspetti del livello di servizio fornito. Per la maggior parte dei servizi, l'SLI chiave è il ritardo nella richiesta - quanto tempo ci vuole per restituire una risposta a una richiesta. Altri SLI comuni includono la frequenza degli errori, spesso espressa come una percentuale di tutte le richieste ricevute, e la capacità del sistema, di solito misurata in richieste al secondo.
Per prima cosa rompiamo gli aerei, e poi le ragazze... le ragazze le vediamo dopo...
Fattori interni ed esterni hanno iniziato a 'rovinarci' l'SLO sin dai primi minuti. Gli amministratori sono stati sopraffatti da tutto - dagli errori dei programmatori, dai guasti dell'infrastruttura, dall'afflusso di visitatori e dagli attacchi DDoS. Tutto ciò che compromette l'SLO.
"- Cari partecipanti, sono felice di informarvi che, prima di tutto, avete un crollo... tutto!"
Nel corso degli interventi, i relatori hanno trattato la resilienza, il budget per errori, la pratica dei test, la gestione delle interruzioni e il carico operativo.
Non siamo scalda-fiamme, non siamo falegnami...
Qui i partecipanti hanno iniziato a riparare: la cosa principale è capire da cosa partire per prima.
«- Oh Dio, non ho mai visto una cosa del genere rompersi in questo modo e in questa posizione!»
E così, si è verificato un guasto. Il servizio di elaborazione dei pagamenti è andato in crash. Come procedere per ripristinare la funzionalità nel più breve tempo possibile?
Gli esperti osservando gentilmente i partecipanti preparano un'altra insidia.
Ogni squadra organizza il lavoro del gruppo per risolvere l'emergenza: coinvolge i colleghi, informa gli stakeholder. Inoltre, vengono definiti i priorità. Così i partecipanti si allenano a lavorare sotto pressione in condizioni di tempo estremamente limitato.
«- Che orrore è questo?!»
Hanno tirato un sospiro di sollievo... e hanno concluso l'esercizio.
Insieme ai relatori, dopo ogni problema risolto e il sito temporaneamente stabilizzato, le squadre hanno studiato gli incidenti dal punto di vista SRE. Hanno analizzato in dettaglio i problemi: cause di insorgenza, processo di risoluzione. Successivamente, sia a livello di squadra che collettivamente, hanno preso decisioni su come prevenire futuri problemi: come migliorare il monitoraggio, come modificare correttamente l'architettura, come correggere l'approccio allo sviluppo e all'operatività, come rivedere i regolamenti. I relatori hanno dimostrato la pratica di condurre un post-mortem.
«- Chi altro vuole soffrire! — Io!»
Sullo schermo elettronico i successi delle squadre venivano fissati in modo chiaro e preciso.
Per i primi posti — un premio dagli stakeholder.
Fonte: habr.com
