Stiamo annunciando il primo corso pratico sulla SRE in Russia: .
Durante l'intensivo passeremo tre giorni a costruire, rompere, riparare e migliorare un sito web aggregatore per la vendita di biglietti per il cinema.
Abbiamo scelto un aggregatore di biglietti perché presenta molti scenari di fallimento: un afflusso di visitatori e attacchi DDoS, il fallimento di uno dei tanti microservizi critici (autorizzazione, prenotazioni, elaborazione dei pagamenti), l'indisponibilità di uno dei tanti cinema (scambio di dati circa posti disponibili e prenotazioni) e più in basso nell'elenco.
Formuleremo il concetto di affidabilità per il nostro sito aggregatore, che svilupperemo ulteriormente in Ingegneria, analizzeremo la progettazione dal punto di vista SRE, selezioneremo le metriche, imposteremo il loro monitoraggio, elimineremo gli incidenti emergenti, condurremo la formazione per il lavoro di squadra con gli incidenti in condizioni prossime al combattimento, organizzare un debriefing.
Il programma è gestito dai dipendenti di Booking.com e Google.
Questa volta non ci sarà partecipazione a distanza: il corso si basa sull'interazione personale e sul lavoro di squadra.
Dettagli sotto il taglio
пикеры
Ivan Kruglov
Sviluppatore principale presso Booking.com (Paesi Bassi)
Da quando è entrato in Booking.com nel 2013, ha lavorato su progetti infrastrutturali come la consegna e l'elaborazione distribuita dei messaggi, BigData e web-stack, ricerca.
Attualmente sto lavorando su problemi relativi alla creazione di un cloud interno e di Service Mesh.
Ben Tyler
Sviluppatore principale presso Booking.com (USA)
Impegnato nello sviluppo interno della piattaforma Booking.com.
Specializzato in service mesh/service discovery, pianificazione di lavori batch, risposta agli incidenti e processo post-mortem.
Parla e insegna in russo.
Evgeniy Varavva
Sviluppatore generale presso Google (San Francisco).
Esperienza da progetti web ad alto carico alla ricerca nella visione artificiale e nella robotica.
Dal 2011 è stato coinvolto nella creazione e gestione dei sistemi distribuiti presso Google, partecipando all'intero ciclo di vita del progetto: concettualizzazione, design e architettura, lancio, piegatura e tutte le fasi intermedie.
Eduard Medvedev
CTO presso Tungsten Labs (Germania)
Ha lavorato come ingegnere presso StackStorm, responsabile della funzionalità ChatOps della piattaforma. ChatOps sviluppato e implementato per l'automazione dei data center. Relatore a convegni russi e internazionali.
Programma
Il programma è in fase di sviluppo attivo. Ora sembra così, entro febbraio potrebbe migliorare ed espandersi.
Argomento n. 1: Principi e metodi di base della SRE
- Cosa serve per diventare SRE?
- DevOps contro SRE
- Perché gli sviluppatori apprezzano SRE e sono molto tristi quando non partecipano al progetto
- SLI, SLO e SLA
- Budget degli errori e suo ruolo nell'SRE
Argomento n.2: Progettazione di sistemi distribuiti
- Architettura e funzionalità dell'applicazione
- Progettazione di sistemi di grandi dimensioni non astratti
- Operabilità/Progettazione per il guasto
- gRPC o REST
- Versioni e compatibilità con le versioni precedenti
Argomento n.3: Come viene accettato un progetto SRE
- Migliori pratiche da SRE
- Lista di controllo per l'accettazione del progetto
- Registrazione, metriche, tracciamento
- Prendere CI/CD nelle nostre mani
Argomento n. 4: Progettazione e lancio di un sistema distribuito
- Reverse engineering: come funziona il sistema?
- Siamo d'accordo su SLI e SLO
- Pratica la pianificazione delle capacità
- Avviando il traffico verso l'applicazione, i nostri utenti iniziano a "usarla".
- Lancio Prometeo, Grafana, Elastico
Argomento n. 5: monitoraggio, osservabilità e avvisi
- Monitoraggio vs. Osservabilità
- Configurazione del monitoraggio e degli avvisi con Prometheus
- Monitoraggio pratico di SLI e SLO
- Sintomi contro Cause
- Scatola nera vs. Monitoraggio della scatola bianca
- Monitoraggio distribuito della disponibilità di applicazioni e server
- 4 segnali dorati (rilevamento anomalie)
Argomento n. 6: Pratica per testare l'affidabilità del sistema
- Lavorare sotto pressione
- Iniezione fallita
- Scimmia del caos
Argomento n. 7: pratica di risposta agli incidenti
- Algoritmo di gestione dello stress
- Interazione tra i partecipanti all'incidente
- Postumortem
- Condivisione della conoscenza
- Plasmare la cultura
- Monitoraggio dei guasti
- Condurre un debriefing irreprensibile
Argomento n. 8: pratiche di gestione del carico
- Bilancio del carico
- Tolleranza agli errori dell'applicazione: nuovo tentativo, timeout, inserimento di errori, interruttore automatico
- DDoS (creazione di carico) + Errori a cascata
Argomento n. 9: Risposta agli incidenti
- debriefing
- Pratica a chiamata
- Vari tipi di incidenti (test, modifiche alla configurazione, guasti hardware)
- Protocolli di gestione degli incidenti
Argomento n. 10: Diagnosi e risoluzione dei problemi
- Registrazione
- debug
- Esercitati nell'analisi e nel debug sulla nostra applicazione
Argomento n. 11: test di affidabilità del sistema
- Prove di stress
- Test di configurazione
- Test delle prestazioni
- Rilascio Canarie
Argomento n. 12: Lavoro indipendente e revisione
Raccomandazioni e requisiti per i partecipanti
SRE è un lavoro di squadra. Consigliamo vivamente di frequentare il corso in gruppo. Ecco perché offriamo grandi sconti per le squadre già pronte.
Il prezzo del corso è di 60 ₽ a persona.
Se un'azienda invia un gruppo di 5+ persone - 40 ₽.
Il corso è costruito su Kubernetes. Per passare è necessario conoscere Kubernetes a livello base. Se non lavori con lui, puoi seguire Slurm Basic ( o ).
Inoltre, devi essere esperto in Linux e conoscere Gitlab e Prometheus.
Se hai un'idea complessa per la partecipazione, ad esempio, che il CEO, il CTO e un team di sviluppatori vengano al corso e facciano uno stage tenendo conto del verticale del management, scrivimi in un messaggio personale.
Fonte: habr.com