[Musica]
grazie mille per tutto
venendo e frequentando e conosco e il
fine dell’andare verso la fine del
fine conferenza del giorno quindi io
apprezzarlo Cercherò di renderlo un
un po ‘divertente e divertente per te
in modo tale che vale la pena il vostro tempo per mezzo di
sfondo e introduzione Io in realtà
mi sono tagliato i denti con questa ingegneria del caos
test di fallimento su amazon.com
circa dieci anni fa faceva parte del
squadra del sito web al dettaglio e quando amazon.com
va giù non fanno soldi loro
non è possibile raccogliere soldi è molto costoso
e abbiamo fatto un sacco di cose reattive
delle tue operazioni tradizionali ti si avvicina
Conoscere le recensioni degli incidenti abbiamo fatto bene
gestione degli incidenti sai abbiamo cercato di
sistemare le cose il più velocemente possibile ma per
gli obiettivi di disponibilità aggressivi che abbiamo avuto
dovevamo fare qualcosa di meglio noi
doveva essere proattivo e prevenire tutto
classi di interruzioni da verificarsi così io
avuto l’opportunità di costruire una piattaforma
per aver creato questo fallimento in un ambiente sicuro e
in modo sicuro e poi andare in giro e aiutare
i team di Amazon lo usano e lo fanno parte
di quello di cui parlerò oggi è questo
idea di una giornata di gioco in cui davvero il
la radice di quello viene da Jesse Robbins
facendo questo a mano su Amazon in
primi anni 2000 dopo il mio periodo in Amazon I
voluto andare più a fondo in questo spazio e
quindi sono andato a far parte di Netflix così mentre io
era ad Amazon che avevano inventato questo
idea di scimmia del caos quindi non ho scritto
Cass scimmia era lì prima che l’avessi mostrato
up, ma quando sono arrivato c’era in realtà
un’opportunità per migliorare le scimmie
erano un buon primo passaggio ma non lo erano
abbastanza buono per il tipo di approfondimento
test di produzione che dovevamo fare
così ho avuto l’ opportunità di costruire il
piattaforma di iniezione guasti di prossima generazione
era un nome in codice adatto a sorpresa
test di iniezione fallita e DAT
ci ha permesso di fare molto più precisi
Iniezione di difetti a grana fine e abbiamo usato
quello di testare da dev e stadiazione
attraverso il cento per cento in prod e noi
ha avuto buoni risultati da entrambi
aziende
quindi avendo visto che ho successo io
fondato il gremlin per prendere gli utensili
e la cultura e l’approccio e
portalo nel resto del mondo così
con quello lasciatemi iniziare un po ‘
di una definizione cos’è il caos
ingegneria e qui è dove sto andando
prendi un po ‘di più sulla scimmia del caos
di persone hanno sentito parlare di caos scimmia di
spettacolo di mani praticamente tutti sono
diventare abbastanza noto ma una cosa io
non sono d’accordo con sulla scimmia del caos è il
idea che questo tipo di test debba essere
fatto a caso c’è un tempo e un posto
per l’iniezione di guasti casuali, ma il modo
che ci pensiamo è un po ‘
diverso quindi una delle analogie che io
amo disegnare quando sono a casa per il
vacanze o sto parlando con la mia famiglia e
si chiedono che cosa è che si fa è quello di
il vaccino o il vaccino antinfluenzale sai se
siamo tornati indietro di 200 anni e abbiamo detto hey
Ti inietterò con questa malattia
è così forte che potresti aver avuto un misto
risultato ma sappiamo che ce ne sono alcuni
vantaggi di questo processo è chiamato
ormone con il quale un sistema o un
l’organismo si adatta al danno per
diventare più forte e così uguale
la tecnica si applica al nostro software
sistemi iniettando qualcosa di dannoso
siamo in grado di capire come funziona il sistema
si comporta che siamo in grado di trovare opportunità
per migliorare sia il nostro software che
noi stessi come organizzazione e come
persone e siamo in grado di indurire il nostro
risposte per diventare immuni alle classi di
fallimento quindi la mia definizione di caos
l’ingegneria è pensosa pianificata
esperimenti progettati per rivelare il
debolezza nel nostro sistema ed è
importante da fare a mio avviso premuroso
esperimenti programmati perché vogliamo
Misurali vogliamo capire il
impatto vogliamo trattare come il
metodo scientifico dove ne abbiamo alcuni
ipotesi sul nostro sistema e vogliamo
per verificare se lo sono o no
vero e in quel processo potremmo scoprire
nuove informazioni i nostri sistemi sono complessi
e c’è un sacco di profondità per loro e
spesso non scriviamo tutto il codice
quelli che girano ci sono le librerie che sono
servizi dipendenti e
quindi è difficile per nessuno di noi davvero
conoscere a fondo come si comporta il sistema
senza qualche sperimentazione e la chiave
qui e ho menzionato questo come me
introdotto nella mia introduzione è quello
questo ci consente di essere proattivi , a
approccio reattivo fondamentale a
operazioni che non ci porteranno mai
un certo grado di affidabilità, se lo siamo
sempre in attesa che le cose falliscano e
poi sistemandoli rapidamente e provando a
evitare che si verifichi di nuovo siamo
mai andare davanti alla curva e
quindi dobbiamo essere in grado di uscire di cui abbiamo bisogno
per farlo in modo proattivo dobbiamo farlo
durante il giorno dobbiamo essere in grado di
piano per questo tipo di fallimenti e
Preparati per loro uno di quelli del
le cose mi danno sempre un po ‘di pushback
con l’ingegneria del caos va bene così
non funzione lavoro e funzionalità lavoro è
ciò che ci rende denaro quindi non so se
possiamo passare del tempo su questo e davvero
le operazioni sono un costo che paghiamo quando
le cose ti spezzano che ti porta via tempo
dallo sviluppo di funzionalità ci vuole tempo
lontano da altri aspetti dell’azienda
e così da essere pensieroso a riguardo
possiamo pianificare il tempo da dedicare a questo
in realtà risparmiamo tempo e possiamo
budget migliore e prepararsi per i tipi
delle cose che accadono, quindi cos’è un bene
definizione senza anti-definizione
quello che non è il caos di ingegneria bene per me
non si tratta di essere un cowboy o un
cowgirl solo in esecuzione in produzione
pistole infuocano e sparano ai server
roba senza dire a nessuno che non lo è
non è un gioco lupo solitario questo è un
luogo dove vogliamo collaborare noi
voglio comunicare vogliamo fare il nostro
tutta l’azienda meglio che vogliamo testare il
confini di comunicazione dei nostri servizi
e i nostri team e quindi non è qualcosa
per essere nascosto non è qualcosa di essere
fatto in background è qualcosa da fare
essere fatto sai alla luce del giorno di essere
abbracciato e poter uscire e
e diffondere la buona parola in qualche modo per
aiutare i nostri team e le nostre aziende
capire l’errore si verifica spesso a
scala ed è prudente e saggio essere
pensandoci in anticipo e
preparando per questo
è divertente per me il modo in
quale il nome chaos engineering ha
tolto e ho pensato un po ‘
perché questo lo sai che il nome del caos
questo è dove le cose sono eccitanti
è malizioso, sai che questo lo dà
quel tipo di atteggiamento giocoso divertente ma
il lato ingegneristico sai che siamo
ancora ricevendo quella disciplinata
approccio rispettabile di applicare bene
disciplina ingegneristica per i nostri sistemi
In realtà penso a causa della scimmia del caos
e a causa della casualità implicita
che ha portato che questo nome è un po ‘
di un termine improprio non si tratta di maneggiare
caos per migliorare l’ingegnerizzazione dei nostri sistemi
Infatti penso che saremmo meglio serviti da
lanciando in giro quello che vogliamo fare è
vogliamo prendere la disciplina
rispettate le pratiche ingegneristiche che noi
avere e applicarli al caos che è
già inerente nei nostri ambienti noi
avere abbastanza caos ci sono abbastanza cose
che rompono e sbagliano che non lo facciamo
necessario possiamo usarlo come strumento ma
non abbiamo bisogno di un’altra domanda
che ho pensato un po ‘a te
sapere perché questo è diventato un argomento di
interesse di recente sai che ho fatto
ricerca in questo spazio e ci sono
parla e parla di questo sul fallimento
test che risalgono agli anni ’70 e al
Anni ’80 ci sono molti buoni post sul blog
dagli anni ’90 e dai primi anni 2000
descrivere questo stesso processo e lo stesso
metodologia quindi cosa è cambiato in
ultimi cinque o dieci anni che ha davvero
ha portato alla necessità di questo approccio
bene uno dei nostri sistemi usato per guardare a
un po ‘diverso questo è un po’ di un
semplificazione eccessiva ma tu conosci un po ‘
gli approcci della vecchia scuola ne avevamo alcuni
data center e potremmo reindirizzare
traffico tra di loro all’interno dei nostri dati
centri le nostre applicazioni erano un po ‘
un po ‘più semplice, lo sai
tendeva ad essere a tre livelli ne avevamo alcuni
front-end abbiamo avuto qualche logica aziendale noi
lasciare che il database gestisca molte delle
problemi di coerenza e molto del
pezzi appiccicosi ovviamente i nostri sistemi oggi
sembra un po ‘diverso questo è un
immagine di Amazon.com questo è in realtà
circa 2008
Ero nella squadra che ha generato questo
mestiere questo è solo amazon.com c’è
niente da Kindle o digitale c’è
niente da AWS sono il grafico
l’altro lato è Netflix questo è
in realtà mi precede anche questo è come
2010 2012 e tu sai cosa abbiamo io
chiamali palle della morte di micro-servizi
sai che è quasi come la Morte Nera
questo il grado di complessità all’interno del nostro
i sistemi ora sono troppo per nessuno
ingegnere o una squadra da mantenere
completamente nella loro testa sai che possiamo
non fare più affidamento su un architetto
capire tutte le modalità di errore e
proteggici da esso ce ne sono troppi
le cose che stanno succedendo lo rendono anche di più
difficile per noi andare in giro e testare
queste cose una domanda che ottengo sei tu
lo so bene, posso solo fare un po ‘di unità
testare e coprire molti di questi casi
ma in realtà li stiamo testando
confini tra microservizi e così via
sai se guardiamo qualcosa
ha anche un centinaio di microservices solo
testare tutte le combinazioni di errori
ci sono da 2 a 100 possibilità
se passiamo attraverso quello e un bruto
metodo di forza che il Sole brucerà
prima di finire quel percorso di prova e così via
abbiamo bisogno di qualcosa che sia più efficace
e più efficiente per essere in grado di
capire questo tipo di complessità e io
sarebbe postulare che l’ingegneria caos per me
ha dimostrato di essere uno strumento prezioso per
realizzare ciò alla fine predicendo
fallimenti un po ‘come predire
il tempo che sai che la teoria del caos dice
noi se lo avessimo se sapessimo tutto l’input
variabili se conoscessimo tutti i modi in
quali quelle variabili hanno interagito noi
potrebbe modellare correttamente il sistema
si comporterebbe e cosa accadrebbe ma
proprio come quando ma ma non lo facciamo
conoscere tutte le variabili che non possiamo
calcola tutte le possibili combinazioni
di cose che possono accadere c’è umano
fattori ci sono fattori tecnici
ci sono cose fuori dal nostro controllo
sai che molti di noi non possiedono i nostri
hardware più ci sono così tanti in movimento
pezzi che diventa molto difficile da
prevedere e quindi in un modo che stiamo modellando
e come otteniamo più informazioni siamo
regolando quel modello uno degli
le differenze tra le tue conoscenze sono prevedibili
uragani e previsioni di interruzioni e
software possiamo andare a simularli
tipi di eventi possiamo farlo in una cassaforte
modo in a
modo terribile ma possiamo effettivamente causare
questi fallimenti sai se potremmo
genera un uragano nell’Atlantico di a
di piccole dimensioni e poi lo abbandona quando noi
ce ne siamo andati se ci fossimo fermati
pulsante nel caso in cui le cose andassero male, forse
potremmo modellare meglio quelli e così io
penso che siamo un po ‘di un
vantaggio rispetto alla previsione e
modellazione e altri sistemi complessi quindi
voglio parlare un po ‘di cosa
entra nella pianificazione di un giorno di gioco
e come pensare a cosa può andare storto
e come pensare a come uscire e
efficacemente questo test e il
la prima domanda è proprio quello che potrebbe
sbagliare una delle cose che amo fare
quando lavoro con una nuova squadra o a
nuovo cliente è quello di ottenere un sacco di
ingegneri nella stanza e lavagna fuori
il loro servizio mi limita a disegnarmi
esempio di come appare mostrami
alcune delle interazioni questo è un
versione semplificata del API Netflix
e al suo interno abbiamo un po ‘di caching siamo
avere alcuni servizi dipendenti che noi
attraversa i confini della rete Netflix utilizza il
schema dell’interruttore nella storia come a
modo per aggiungere un po ‘di protezione in più
difetti che potrebbero verificarsi così proprio qui se
diciamo che cosa potrebbe andare storto c’è un
un sacco di cose che mi vengono fuori
prima di tutto ogni volta che vedo una rete
connessione Sono dubbioso che la rete sia
non affidabile e non è nostro amico
è spesso la causa del nostro dolore e
mal di testa e quindi vorremmo testare
cosa succede se non possiamo parlare al
servizio di playlist che vorremmo
parla vedi cosa succede se le valutazioni
il servizio all’improvviso diventa molto più lento
o i tempi di risposta raddoppiano cosa
succede se contiamo molto sulle nostre cache
essere in grado di gestire il flusso di
il nostro sistema e che la cache va via io
capovolto questa interruzione alcune volte
aumenti il servizio dipendente reale
veloce e spero di ottenere o sperare di risolvere
il cache e quindi ci sono molti di questi
punti potenziali che potrebbero fallire o che
potrebbe non funzionare correttamente così da questo
veniamo elencati un insieme di cose
potrebbe essere interessante per noi
esplorare o per capire meglio il
la seconda domanda che mi piace chiedere è una
aiutare con la definizione delle priorità
quanto è probabile che ciò accada e questo è
un questa è una spada a doppio taglio
nel modo in cui abbiamo posto questa domanda
da un lato se abbiamo avuto tre interruzioni
quest’anno e si sentono tutti molto simili
erano tutti legati a una disponibilità
zona in mancanza o erano tutti legati a
un servizio che scende, allora lo sappiamo
ci sono dei frutti a bassa percentuale
può andare e possiamo passare un po ‘di tempo
testare quei guasti e assicurare che
siamo resilienti a loro o ci occupiamo di noi
loro meglio il rovescio della medaglia c’è
idea dell’evento Black Swan l’evento
quello può essere estremamente raro ma può avere
un impatto catastrofico per la tua azienda
quando si verifica e ciò potrebbe non essere
qualcosa che succede spesso ma tu
voler preparare per questo, perché ci piace
avendo il nostro lavoro e le nostre aziende noi
non voglio che vadano necessariamente via
c’è un grande esempio in
mondo di trading ad alta frequenza di un bug
l’hanno trasformato in produzione che ha perso
300 milioni di dollari in un minuto o due
che era la fine di tale società come
vale la pena dedicare un po ‘di tempo extra e
tentativo di prevenire quei rari casi anche
anche se sono rari così da questo
pensiamo attraverso quello che potrebbe andare storto noi
pensa a quanto è probabile che si verifichi
lo diamo la priorità e da quello siamo
troverò una serie di esperimenti
una serie di ipotesi su come il nostro sistema
si comporta e come pensiamo il risultato
accadrà l’ultima domanda che mi piace
chiedi e penso che questo sia prezioso
specialmente come stiamo parlando al nostro
leadership o la nostra gestione sul
costa quale è il costo di essere sbagliato
il software è costoso da scrivere
costoso da mantenere e quindi abbiamo bisogno di
essere in grado di tagliare dobbiamo essere in grado di
giustificare il tempo e gli sforzi che spendiamo
questi tipi di interruzioni di approcci sono
costoso
quando s3 fallì due anni fa lo fu
stimati a costare a tutti quelli che non lo erano
Amazon centocinquanta milioni
dollari abbiamo avuto due principali compagnie aeree
interruzioni nell’ultimo anno British Airways
e Delta erano entrambi cento milioni
plus in entrate perse e un impatto in
gli Stati Uniti sono stimati a 700
miliardi persi a causa di interruzioni e tempi di fermo
come una buona metrica ma penso un po ‘
metrica datata che stima che nel
il mondo dei data center il costo del downtime
è 5.000
un minuto o $ 300.000 l’ora come pensiamo
su di esso sai venire dall’Amazzonia
mondo dell’e-commerce quando sei giù sei
perdere le entrate che c’è un diretto
linea di vista a quel denaro che si sta perdendo
in Netflix
è un sistema basato su abbonamento e così via
mentre i tempi di fermo non hanno un impatto diretto
entrate che incidono sul marchio e
fiducia dei clienti e se i vostri clienti
smesso di fidarti di te che possono decidere di farlo
andare a un servizio concorrente che possono
Decidi che non vale la pena pagarti o
continua e tutte queste metriche
tipo di ignorare quello che per me è l’iceberg
che si trova sotto l’acqua che è il
costo tecnico associato alle interruzioni
e tempi di inattività spesso pensiamo a un’interruzione
come sapete, spero un 15 a 20
Periodo di tempo di 30 minuti in cui tutte le mani
sono sul ponte per andare a sistemare tutto ciò che è sbagliato
ma non è la totalità del costo
di un’interruzione che ha vissuto anni
di loro lo sai
poi c’è il giorno o due di andare e
immersione in tutti i dati e il
le metriche che fanno l’analisi è a
capire i fattori che contribuiscono e
gli aspetti che hanno portato a quella interruzione
di solito c’è un incontro con una correzione
di errore o un post-mortem dove un grande
parte della compagnia è nella stanza per
parlare di questo fallimento del cliente
impatto e cosa succede da quello
di solito c’è tutta una serie di azioni
oggetti che devono uscire e essere riparati
per impedire questa interruzione da sempre
si ripresenta di nuovo e poi qualcuno lo ha
uscire e implementare quelli e
idealmente in realtà prova che proteggono
tu in realtà penso che sia una parte di
il ciclo che tende a mancare nel nostro
sistemi tendiamo a sistemare gli elementi di azione
e incrociamo le dita e benissimo se
succede di nuovo che sapremo se è così
risolto e proprio lì che è dove
l’ingegneria del caos in realtà stiamo andando
fuori e ricreare quell’incapacità di vedere
se aggiusti il sistema e ce l’hai fatta
più resistente è la chiave ma il
i tempi di progettazione e lo sforzo che va
in tutto questo processo è solo molto
costoso e così questi tre fattori
davvero aiutaci a capire perché il
il business dovrebbe essere interessato all’investimento
il tempo e lo sforzo in questo tipo
di approccio quindi ora voglio dirti a
un po ‘ su come io
i giorni di gioco in corso e quello che penso
è un modo efficace per affrontare questo la
primo passo è che abbiamo bisogno di
comunicare come ho detto questo non lo è
conosci una così solitaria attività da lupo
voglio essere in grado di avere la compagnia
consapevole che stiamo facendo questo tipo di
attività che in genere vogliamo avere
qualche centro di comando dove le persone possono
check in forse lo faremo a
una in una stanza lasco forse stiamo andando
avere un ponte per le conferenze, forse è così
sarò alla scrivania di qualcuno ma in un posto
che le persone che sono interessate possono venire
e capire cosa sta succedendo e come
la sua comportandosi questo ci dà un posto per
condividi le metriche per condividere gli avvisi che vogliamo
vogliamo oltre comunicare che siamo
eseguendo questi esperimenti potremmo volerlo
avere una presenza di successo o consapevole del cliente
possono essere in grado di provare dolore al cliente
e vedere i problemi prima che siamo in grado di
rilevarli e questo è fondamentale che vogliamo
per garantire che abbiamo il nostro upstream e
i nostri sistemi a valle ti presentano
se potessimo potenzialmente avere un impatto
loro o potrebbero avere un impatto su di noi allora
dovrebbero essere consapevoli che questo tipo di
l’esercizio si sta verificando e una cosa
questo è fondamentale per l’ esecuzione di questi giochi
giorni è che vogliamo evitare il cliente
dolore l’obiettivo di questi esperimenti il
obiettivo di questo giorno di gioco è quello di prevenire
interruzioni è per prevenire i tempi di fermo e così via
non vogliamo causare accidentalmente
tempi di inattività come parte di eseguirli
esperimenti e così con quello che voglio
spiegare questo concetto del raggio di esplosione
ogni volta che eseguiamo un esperimento
c’è il rischio che sia in dev o
messa in scena o in produzione che potremmo
rompere colleghi ingegneri che potremmo
rompere i clienti che potremmo causare dolore
e una perdita di efficacia e quindi cosa
vogliamo fare è quando eseguiamo un
esperimento vogliamo eseguire il più piccolo
esperimento che ci insegnerà qualcosa
se possiamo eseguirlo su un singolo utente a
una singola serie di richieste per un singolo dispositivo
forse è un singolo contenitore o un
host singolo ma vogliamo eseguire il
il più piccolo esperimento che funzionerà e
poi ad ogni passo che stiamo andando
cresci quel raggio di esplosione che ci trasferiremo
per eseguire un esperimento più ampio perché
abbiamo costruito una certa fiducia e fiducia in
il sistema
o troveremo un bug e lo siamo
sarò in grado di andare a sistemare quell’errore e
abbiamo vinto perché l’obiettivo è trovare
insetti prima che ci causino dolore
e così qui abbiamo un’ipotesi
quindi abbiamo enumerato le cose
potrei sbagliare, lo faremo
esperimento che misureremo il
risultato di quell’esperimento spesso noi
voglio sapere che il nostro impegno funziona
correttamente riceviamo il paging quando le cose
pausa sono i nostri allarmi sintonizzati correttamente
sappiamo abbastanza presto o i nostri cruscotti
utile se qualcosa è rotto fa il nostro
la dashboard ci aiuta a trovare la causa o lo fa
si intromette e da ciò siamo
avrò una serie di criteri di successo a
insieme di criteri di fallimento e alcuni abortire
condizioni ancora non vogliamo mai causare
dolore del cliente reale e quindi se lo siamo
abortiremo l’esperimento perchè
ciò significa che abbiamo trovato qualcosa che
non dovrebbe accadere ad Amazon questo
erano ordini al minuto se vedevamo un
impatto per gli ordini al minuto vorremmo
fermare l’esperimento avremmo pulirlo
e Netflix era in grado di far scorrere le persone
e se ciò fallisse, se vedessimo un calo
che avremmo automaticamente fermato il
sperimentare e lo faremmo anche se fosse così
non è stata colpa nostra anche se fosse successo
che un’altra interruzione stava avvenendo al
allo stesso tempo non vogliamo infangare il
acqua e non vogliamo causare
confusione in questo processo e poi noi
eseguire l’esperimento e il sistema
si comporta come ci aspettiamo con grazia
degrada il cliente non può il cliente
non vede l’impatto di quel fallimento
o qualcosa rompe qualcosa no
funziona come ci aspettiamo e se questo è
Nel caso in cui abbiamo finito abbiamo trovato un bug noi
puoi andare a prenderlo offline che possiamo capire
perché si verifica possiamo fare il cliente
migliore esperienza e possiamo tornare
e testarlo in un secondo momento quindi un
esempio di come misurare l’errore
questo è un grafico rubato da Netflix il
la linea nera che attraversa la cima è
se le persone possono streaming il verde è
questo è un comando di storia il verde è
esecuzioni di successo e il rosso è un
esecuzione fallita e cosa puoi vedere
ecco che iniziamo questo esperimento
e stiamo iniettando una piccola quantità di
fallimento sai 10 o 20% del
traffico generale
c’è un po ‘di accumulo qui
con tentativi e simili ma sospendere
incredulità , quindi dopo che abbiamo corso
questo esperimento per venti minuti noi
vedere che i clienti non sono interessati
sono ancora in grado di streaming e cose
stanno funzionando come previsto così ora ci rampa
su quell’esperimento vanno a circa il 50%
circa l’80% e poi fino al cento percento
e ad ogni passo vediamo fallimenti
si verifica nel sistema questo servizio è
non funziona restituisce errori
ma l’esperienza del cliente è essere
ha funzionato ancora correttamente
e le persone sono ancora in grado di trasmettere e
alla fine di questo esperimento possono farlo
puliscilo e loro possono rotolarlo indietro
e quello che abbiamo imparato è se questo
il servizio non riesce per un periodo di tempo
il cliente non noterà questo richiede
qualcosa che potrebbe essere un’alta severità
sette sette Siddhant nel mezzo di
la notte e lo trasforma in qualcosa
che potremmo guardare il giorno dopo
durante le ore lavorative in cui i clienti
non saprò dove ovviamente fornisce
un certo valore vogliamo che funzioni, ma quando
è rotto non causa molto
il dolore del prossimo suggerimento è che abbiamo bisogno di noi
ho bisogno di esercitarmi, sai che mi piacerebbe
per disegnare sull’esercitazione antincendio
sapere quando ci sono situazioni di emergenza
quando ci sono cose urgenti ad alto stress
che si verificano la gente ha bisogno l’opportunità di
pratica in anticipo che vogliamo costruire
quella memoria muscolare che vogliamo essere in grado di
gestire questo tipo di situazione in modo pulito
e modo efficiente
non vogliamo andare nel panico che vogliamo essere
premuroso e quindi come tale numero uno
dovrebbe essere pratica dovremmo essere
eseguendo questi in anticipo scherzo che il
addestramento a chiamata L’ho ottenuto quasi
ogni azienda è qui il tuo cercapersone buono
fortuna ci potrebbe essere una corsa prenotata è
laggiù
nessuno di essa ha esaminato nel mentre una figura
è fuori sei intelligente e sai immaginare
un mondo invece dove la prima volta
stai chiamando il tuo team viene da te
e dicono che sappiamo che sei di guardia
questa settimana avrai una pagina ma
non ti preoccupare
è un esercizio di simulazione che controlliamo noi
avere una rete di sicurezza ma noi vogliamo che tu
trattalo come un vero evento che ti vogliamo
a
controlliamo vogliamo che fidanzarsi vogliamo
tu a guardare i tuoi allarmi ti vogliamo
per guardare i cruscotti che vogliamo che tu faccia
scavare nel sistema per capire come
succede ma piuttosto durante a
evento stressante nel mezzo del
notte dove hai, forse sai
leadership sui clienti di chiamata
preoccupato per la diffusione di Twitter di Netflix
le persone sono infelici lì non è un
ottimo momento per fare domande che conosci
è difficile e tu vuoi creare
un’opportunità per le persone di imparare e
per fare domande sul loro servizio così
che possono acquisire quella familiarità e
conforto prima che siano chiamati a fare
è vero James Hamilton, sono un po ‘
un suo fan è un distinto
ingegnere VP presso AWS prima di essere a
Microsoft Research ha scritto un articolo
sono passati 10 o 15 anni ma per me
è quasi come l’ops Bibbia che ha così
molta saggezza applicabile convenzionale in
è su progettazione e distribuzione
servizi di scala internet e all’interno di questo
ha parlato diverse volte di questo
concetto qui che se non vogliamo
prova in produzione ci dice qualcosa
su quanto siamo fiduciosi nella nostra
sistemi se siamo così preoccupati che tu
sapere perdere un host o qualcosa da ottenere
più lento è qualcosa che siamo solo
riluttanti a sperimentare poi il nostro
sistema non è in un buon posto siamo
correndo troppo vicino al bordo o noi
non ho abbastanza informazioni e
capire di essere a proprio agio e poi
si va avanti a parlare di se abbiamo
questi meccanismi di recupero così forse
siamo in grado di evacuare le regioni nel
caso di un fallimento forse abbiamo un
backup del database archiviato fuori sede
abbiamo mai recuperato quel database
sappiamo che il recupero di quel database è
andando a lavorare correttamente
abbiamo mai evacuato una regione per davvero
o ne abbiamo appena parlato Adrian
Cockcroft parla di questo come
disponibilità teatro cose che noi
pensare sono gonna lavorare, ma in realtà può
non e ho visto esattamente questo esatto
problema in azione se sei nel
al centro di una interruzione e tu vai a risolvere
quella interruzione con quest’altra ripresa
meccanismo e quel meccanismo di recupero
fallisce ora hai davvero una terza interruzione
hai due interruzioni in corso al
stesso tempo
e invece di salvarti e fare
la tua vita migliore è effettivamente fatta tua
la vita più complicata e più dolorosa
e parlerò un po ‘di
come abbiamo fatto questo a Netflix in modo che noi
sono stati preparati quando è arrivato il momento, quindi cosa?
conosci grandi storie ma parliamo
su alcuni esempi del mondo reale, facciamolo
cammina attraverso alcuni posti dove abbiamo
visto questo in azione il primo è questo
esempio di evacuazione della regione così in
Dicembre del 2013
Netflix è rimasto inattivo per circa un giorno
un fallimento in noi East One e Netflix
era solo in noi due est e così
hanno deciso che era importante per
loro per andare a gestire essendo regione trasversale e
essere in grado di evacuare le regioni questo è
esattamente questo tipo di evento Black Swan a
molte persone potrebbero dire bene che sono
faranno bene che lo faranno
un buon lavoro che stiamo andando a sapere questi
tipo di guasti su larga scala che sono
semplicemente improbabile e mentre potrebbe essere
è vero che potrebbero essere improbabili che lo siano ancora
eseguire sistemi complessi che sono
difficile da gestire e da gestire e
quindi gli stessi tipi di cose che siamo
suscettibili a loro sono e quindi abbiamo bisogno
prepararsi per questo tipo di evento a
Netflix dopo aver inserito questo processo
luogo hanno iniziato a gestire queste regioni
evacuazioni ogni due o tre settimane in
l’inizio di questa regione di evacuazione
ci sono voluti 45 minuti in più
squadre e aveva un sacco di manuale
Interazione coinvolta oggi penso a me
leggere un post sul blog qualche mese fa
hanno verso il basso per essere meno di cinque minuti
ad essere fondamentalmente interamente
automatizzato e sono in grado di farlo a
l’avviso di un momento la chiave qui è quella
continuano a eseguire questo processo hanno
non ho detto oh, abbastanza bene, abbiamo finito ora
ogni due o tre settimane evacuano a
regione per reale e perché è questo
importante perché ogni altra corsa o così
c’è qualche nuovo bug che emerge forse
c’è un nuovo servizio che ha un ridimensionamento
confine quando la situazione è che il flusso che
quel traffico di rete extra forse c’è
un bug nel nostro codice proxy che non lo è
ci permettono di reindirizzare il traffico nel modo
che ci aspettiamo
qualunque sia il caso per regolare
esercitando questo trovano e risolvono questi
problemi quando arrivano così quando
le cose vanno male è lì
sarà affidabile funzionerà quando
è chiamato e negli ultimi sei
mesi a Netflix ho avuto questo
messo a punto due volte
abbiamo avuto un sabato o una domenica mattina
dove non siamo riusciti a ottenere nuovi ospiti in noi
Quello orientale e lo sapevamo come traffico
impennato per il giorno che stavamo andando
essere sotto capacità e questo è stato un giorno
quando Reddit e Twitter erano in fiamme con
conosci gente che brucia e a
molto dolore ma perché questo era un
Evento regolarmente praticato
secondario
il mio principale ha appena scoperto quello che il
problema era che vide che era un
problema con AWS abbiamo avuto una chat
conversazione e abbiamo iniziato a cambiare
il traffico prima di dover davvero dover
bisogno di coinvolgere il resto della compagnia
sai che abbiamo ancora fatto la conferenza
ponte abbiamo coinvolto tutti, ma è così
era fondamentalmente un non-evento per noi perché
era ben praticato perché lo era
ben capito e questo è esattamente il
tipo di posizione vogliamo essere in noi
voglio essere preparato in modo che quando questi
gli eventi si verificano sembrano non eventi
sembrano come si comportano come noi
li voglio ad un altro esempio
chissà cosa è critico nei loro
sistema e cosa non lo è per certo sì
abbiamo avuto questo problema su Amazon qui
dei modi in cui sei diventato un livello uno
il servizio su Amazon è stato causato a
cliente in disservizio e se tu
non erano nella lista in cui eri ora
lista e persone in quella lista sono state tenute
a uno standard più elevato che dovevano fare
più preparazione avevano bisogno di essere loro
sono stati cercati in qualsiasi incidente su larga scala
c’è stato un sacco di lavoro extra che è andato
in essere un servizio di primo livello su Netflix
siamo venuti su un modo migliore per scoprire
questo abbiamo preso alcuni dei nostri flussi di lavoro principali
sai per prendere Xbox prendere un
PlayStation prende un iPhone e ti segue
conosci l’ accesso al polmone del sale sfoglia una ricerca a
film e gioca quel film fa così
quel flusso di lavoro principale funziona e quindi cosa noi
è stato automatizzato con alcuni
test di fallimento
abbiamo autorizzato ciò che pensavamo fosse il
servizi critici e abbiamo fallito il traffico
a tutti i servizi non critici ora
ogni volta che quell’esperimento automatico è stato eseguito
se ciò fallisse , sapevamo che era nuovo
il servizio critico era stato introdotto e
potremmo decidere se
volevamo che fosse un servizio critico
o no, andremmo in quelle squadre e noi
direbbe hey sai che sei di livello
uno ora e loro andrebbero quello che no è
ok, lo sapremo solo noi
voglio solo che tu sia impaginato in ogni
grave incidente e fare un sacco di prontezza
e preparazione prima di fare una distribuzione o voi
potrebbe trovare un modo per farlo con grazia
degradare e togliersi di mezzo e nove
volte su dieci erano come oh no
può solo servirti una riserva di cache e
possiamo andare avanti e abbiamo pensato che fosse
grande
sai che il servizio meno critico è
minore è la complessità, più facile è
capire quando le cose vanno male e così io
davvero mi è davvero piaciuto che abbiamo trovato un
modo migliore per affrontare questo problema
e poi la domanda va come se noi
aspettiamo cinque anni potremmo essere in a
posizione in cui solo qualcun altro ha fatto
tutto questo test per me e mi ha detto cosa
andrebbe male e così ho avuto il
opportunità di lavorare con Peter Alvaro
è un dottore di Berkley ora all’UC Santa
Cruz ha avuto questa idea chiamata lignaggio
iniezione guasta diretta e senza andare
troppo profondamente in quello essenzialmente invece
di guardare tutte le cose che potrebbero
andare male guardiamo cosa è andato bene
e iniziare a rimuovere le cose è come
come se blocchi Jenga se togliamo qualcosa
critico che cadrà
se togliamo qualcosa che non lo è
critico che potremmo fare a meno di usare così tanto
la piattaforma che ho costruito su Netflix
sono stati in grado di prendere questo durante l’estate
e costruisci una dimostrazione del concetto dove
lo sfondo sulla produzione reale
traffico penso che sia stato punto zero zero
zero l’uno percento del traffico di produzione
numero molto basso di richieste che eravamo
in grado di eseguire questo tipo di esperimenti noi
sono stati in grado di vedere come una chiamata di servizio
lavorato o un grafico ha lavorato siamo riusciti a
rimuovere automaticamente le cose da esso e
quindi rivedi quella richiesta o trovane un’altra
richiesta che era simile a quella da vedere
come non è riuscito a vedere se siamo stati in grado di farlo
cavarsela senza quei servizi
e ciò che è interessante di questo io
ho parlato prima facendo una forza bruta
analisi di un grafico microservizio se tu
avere cento micro-servizi è due
alle 100 esecuzioni avendo una migliore
cerca lo spazio limitandolo ed essendo
più riflessivo su come lo esplori
siamo stati in grado di farlo in circa a
cento esecuzioni penso che sia stato un
cento a duecento molto meno
complessità nel tempo impiegato
cerca questo spazio e lo abbiamo trovato reale
bug di produzione in Netflix
alcuni dei quali erano punti singoli di
fallimento singoli servizi o singoli team
alcuni dei quali erano profondi fallimenti
richiesto due o tre cose fallendo a
nello stesso tempo e se mai hai corso
sistemi di produzione di produzione su vasta scala
sai che mi piacerebbe se solo le cose
fallito uno alla volta, ma la maggior parte dei
interruzioni interessanti sono due o tre
cose che falliscono allo stesso tempo e così
cosa stiamo andando qui intendo il
risultato è che c’è un sacco di fatica in
operazioni c’è molto burnout
c’è molta fatica da cercapersone se andiamo
attraverso e prendiamo un po ‘di più
approccio proattivo e lo esploriamo
e ci mettiamo a nostro agio con ciò non lo farà
sentiamo tanto quanto noi possiamo essere un lavoro
un po ‘ più felice e speriamo di esserlo
pagati meno speriamo di no
essere svegliato alle 2:00 del mattino
questo in generale ci aiuterà ad aumentare il
affidabilità dei nostri servizi che è di
Naturalmente, perché le cose falliranno
ed è un po ‘folle
sperare che le cose non falliscano
è meglio abbracciare quella strategia e
tuffarsi in esso e così con quello di
le cose che sono eccitanti è questa è una
nuovo spazio è up-and-coming ma noi
non ho capito tutto, c’è molto
di spazio per l’innovazione e per
crescita e quindi voglio invitare tutti
qui a venire unire l’ingegneria del caos
comunità vieni e partecipi abbiamo un
il problema pubblico non riguarda Gremlin
è solo lì per le persone a condividere la loro
esperienze e loro apprendimenti
le loro interruzioni penso che siamo appena sotto un
mille membri quindi se ti sei iscritto oggi
potresti ottenere che io penso il
il millesimo membro che faremo
qualcosa di divertente o speciale su e
c’è un sacco di meetup o
il mondo che puoi andare e puoi
parla delle tue esperienze che puoi
condividi i tuoi insegnamenti o puoi imparare
da altre persone come te e se
non c’è un incontro quindi è fantastico
possibilità di andare a prendere uno per andare a prendere
quello che hai imparato o prendere ciò che è
là fuori su internet e puoi
impara e condividi con le persone
intorno a te e con quello darò un
breve appuntamento per la nostra conferenza questo autunno
a settembre a San Francisco che è
sarò concentrato interamente sul caos
ingegneria con Adriene Cockcroft da
AWS
X Netflix keynoting e Jessie
Frisell di cui parlerò
fallimento in contenitori data la sua profondità di
Esperienza lì così con quella ne ho uno
ultima maglietta perché apparentemente le persone
come le nostre magliette e così chiunque voglia
per chiedere la prima domanda che darò
l’ultima t-shirt gremlin rimasta per
e con questo vi ringrazio molto per
il tuo tempo
prima domanda per la maglietta
andiamo ora, scopro che ho messo troppo
stressarlo se non vuoi il
t-shirt non devi prenderlo è
okay mi stavo chiedendo uno dei
critiche che hai avuto sulla scimmia del caos
la cosa era che era troppo casuale se io
non potrei parafrasarlo così, ma io
posso immaginare che potrebbero esserci dei fallimenti
che non puoi pensare prima e
loro possono accadere quindi non ti senti
che c’è un po ‘di spazio per quello o
dovrebbero essere bene, quindi per prima cosa vorrei dire
che i fallimenti che il caos scimmia
fornisce un riavvio degli host, quindi non lo siamo
andando a imparare necessariamente qualcosa di nuovo
che non potevamo fare semplicemente riavviando
ospita noi stessi lo sai in un certo senso
ci costringe ad avere un apolide
applicazione che è parte del perché tu lo sai
come Netflix si sta muovendo verso il cloud è stato
hey Amazon potrebbe farlo in qualsiasi momento
devi prepararti per questo devi essere
pronto così in questo modo è un buon forzante
Funzionilo architettonico II forzato
ingegneri di Netflix per pensare a cosa
accadrebbe quando il loro ospite si riavvierà
ma come si misura il risultato di
quell’esperimento se le cose sono casuali
rompere a volte casuali forse solo
contribuisce a questo background di basso livello
rumore di errore quando sono in esecuzione
esperimenti voglio vedere un grafico chiaro
che mi dice come le cose stanno comportando I
voglio qualcosa che sia perseguibile come un
risultato voglio capire davvero
dove il punto di svolta è per il mio
servizio se sto facendo qualcosa di simile
ottimizzazione dei pool di thread o dei timeout di ottimizzazione
e c’è una certa soglia dove
tutto quello che sai è quel gomito come
se io se iniettassi casualmente quantità casuali
di latenza come farò a sapere dove
quel gomito è e come sto andando
impara da quello, quindi non è per quello
test di guasti casuali non ha a
tempo e un luogo, ma trovo che sia
più facile da capire e molto altro
più facile ottenere informazioni utilizzabili da
facendo l’ approccio non casuale fai tu
voglio la maglietta che prenderò grazie
per la tua domanda altre domande
Ho adesivi ma io non più magliette
scusarsi come si ottiene la gestione
per vedere la pena di uccidere l’ingegneria che è
una grande domanda perché la maggior parte delle persone lo è
un po ‘di difesa quando glielo chiedi
spendere tempo o denaro per un nuovo approccio
e per me è per questo che ho parlato del
costo del downtime se puoi tradurlo
in perdita di entrate ha perso l’ingegneria
sforzo e puoi davvero quantificarlo
dolore che senti che stai per
passare molto più tempo a convincere la tua
gestione se posso andare e dire che perdiamo
ogni interruzione che dura 30 minuti o
più ne perdiamo centocinquanta
mille euro proprio lì il nostro
la direzione dirà bene che io
potrebbe probabilmente pop potrei probabilmente pagare
un ingegnere per lavorare su qualcosa per a
anno per quello e all’improvviso ora
possono quantificarlo
se diventa hey ci piacerebbe ottenere
queste nuove funzionalità sono state fatte, ma tutti abbiamo capito
paginato alle 3:00 del mattino e poi
trascorso tre giorni a scavare in questo
interruzione e abbiamo ancora un po ‘di lavoro
per fare bene ora hai a che fare
con il tempo perso e questo è il momento
non sono cose spese per le funzionalità che non lo sono
speso per migliorare il sistema è
sentendo che il dolore reattivo così
quantificando che quel costo è veramente
quello che penso è la via per
successo lì buono che ho messo in discussione
che ci sono dati disponibili su come
a quanti piace quanta parte di questa fatica e
la cosa è effettivamente ridotta, quindi lo dirò
tu la mia esperienza personale che puoi
prendi come un aneddoto ma come è un nuovo spazio
Non so molto di quanto pubblicato
studi o informazioni so che tu
sappi che DynamoDB usa questo approccio per testare
come hanno gestito il data center e la rete
partizioni e problemi trovati e risolti
prima che andassero a vivere abbiamo visto un mercato
aumento del nostro nella nostra disponibilità a
Amazon e Netflix come risultato diretto
di questo in particolare il mio team in Netflix
posseduto il procs il gateway di bordo il
proxy e il gateway API e quando io
arrivati siamo stati pagati spesso e
era un servizio di medio livello che avrebbe fallito
la storia era in realtà nata da questo dolore
ma anche la configurazione delle storie
difficile che è parte di ciò che ha portato a
questo andando fuori e in modo proattivo
fallimento testando la perdita di quelli a metà
servizi di livello siamo passati da tre nove
di uptime a quattro nove di uptime e il mio
la squadra è stata paginata
cinque percento in meno ogni anno quindi sono un
credente ma so che è su di me come a
proprietario della società per andare a trovare le metriche migliori
che supporta questa idealmente vorrei
per trovare aziende che non sono Amazon e
Netflix Vorrei sentire dal
resto del mondo le loro esperienze
i loro risultati come hanno misurarono
e il valore che ottengono la nostra priorità
Un allarme si attiva solo quando il cliente
è in procinto di essere colpito quindi come si fa
si prova coloro che in modo sicuro senza colpire
il cliente così di nuovo quello è il
raggio di esplosione sai che puoi farti
costruire un esperimento che potrebbe causare
una piccola quantità di dolore del cliente ma non
una grande quantità così in realtà il modo in cui
l’abbiamo fatto su Netflix, potremmo farlo
dì quale percentuale di traffico volevamo
impatto e quando avremmo prima eseguito un
esperimento avremmo iniziare test di prova
ci assicureremmo quel tipo di nostro
felice che le nostre aspettative al massimo
livello raggiunto quando ci siamo trasferiti
la produzione del primo esperimento sarebbe
come punto zero zero un percento di
traffico per un periodo più breve, come ci sono voluti
ed erano tutti gli occhi sui grafici
metriche gli errori dei clienti e se noi
visto fallire se potessimo rilevare l’errore
non abbiamo avuto bisogno di eseguire più esperimenti
potremmo andare e potremmo andare a capire
da dove viene e aggiustalo se noi
non riuscivo a scoprire che il fallimento eravamo noi
sicuro di spostarlo di una tacca
quindi punto zero zero per cento per cento ora
andremo all’uno percento dell’uno percento
il modo è un buon controllo di sanità mentale ora possiamo andare
al 10 percento il 10 percento si comporta bene 50
cento e una cosa che ho dimenticato
menzionare sei proprio tu che stai provando
per cose diverse su scala diversa
quando sei in quella scala molto piccola
è gestire le eccezioni che gestisco
Null ho un buon ripiego
degrado con grazia quando sei a
Il 50% o il cento per cento lo fa io
proteggimi come un servizio che ho versato
il traffico è molto buono per me
marcia indietro quando quando c’è molto da
riposa nel sistema in scala o nella mia discussione
le piscine sono sintonizzate sui miei timeout
in modo appropriato in modo che io possa continuare a
lavorarci senza travolgere
qualcun altro grazie grazie
qualsiasi altro online ti amo , lo adoro
quindi in molti casi la procedura di test
stesso causa il più grande problema come in
reattori nucleari come te ne occupi
la procedura di prova fallita chiama nel
quindi è di non seguire le migliori pratiche
non seguendo la procedura che puoi causare
facciamo in modo RISPONDO correttamente
quindi quando si inietta un errore si inietta
le uccisioni e poi quello che porta al massiccio
insuccesso quindi di nuovo penso che questo si incastri
bene con la domanda sul raggio di esplosione
perché se iniettando un fallimento e
come un contenitore o un host porta
giù l’intero sistema si dovrebbe
probabilmente lo so perché è carino
facile da fare
conosci di nuovo te che vuoi praticare
sia i tuoi modi tecnici che i tuoi modi sociali
di affrontare questi fallimenti e quindi se
non hai avuto l’opportunità di correre
attraverso questo non vuoi essere
sorpreso che qualcosa potrebbe causare a
fallimento catastrofico e così in un modo
sapere se non siamo se non sappiamo
allora il nostro sistema è in quello stato
allora siamo nei guai perché lo sarà
un brutto giorno quando succede e lo farei
piuttosto so ora o preferirei sapere quando
Ho il controllo e io ho conosciuto il mio
tutta la squadra di ops che esamina il problema
al contrario di oh sorpresa tutto è
fatto altre domande
è principalmente mirato alla ricerca
fallimenti ma nella tua esperienza hai fatto
imbattersi in corruzioni di dati
incongruenze introdotte di conseguenza
questa è una buona domanda che posso diventare appiccicosa
hai corrotto alcuni dati come parte di
un esperimento o nel mondo reale e
puoi essere difficile eseguirne il debug e
per farlo siamo stati davvero premuroso su
il potenziale impatto dei dati del
esperimenti che abbiamo corso tendiamo a farli a
confini del servizio su cose che sono
idempotente o cose che potrebbero gestire
Insuccesso nel mondo reale intendo il lancio
il lato è se a se un evento naturale
l’errore può causare il danneggiamento dei dati in
il tuo servizio è ancora un problema
avere a che fare con e se non lo sei
consapevole di ciò e tu non sai come
attenualo di cui potresti aver bisogno ma se
fai un esperimento che corrompe un
un sacco di dati e provoca un sacco di dolore
è simile a quel raggio di esplosione
dove non vuoi rompere
tutto e tu vuoi capire
l’ impatto ma ma dirò solo
questo è un caos di ingegneria
201 o 301 è un po ‘di più
avanzato vuoi fare il manuale
l’esplorazione poi si vuole automatizzare
poi vai dopo che i dati ci sono alcuni
soglia in termini di dimensioni del sistema o
dimensione della società quando ha senso al
ingegneria del caos, penso che tu pensi
sul costo del downtime ti aiuta
quantificare quanto sia importante per te se
si fa il costo del calcolo dei tempi di fermo
se un’interruzione sai se sei piccolo
start-up e poi vai giù e nessuno
nota poi forse è forse non lo è
è importante per te passare il tempo che sono
in realtà in quel mondo e se andiamo giù
non progettiamo per questo, ma per il nostro
i clienti non sarebbero felici che ci sia un
grande impatto su un marchio o sulla fiducia e così è
davvero una domanda di cui non so
valore Sono una persona di grande valore, se puoi
trascorri due ore e risparmia te stesso dieci
ore quindi passa due ore se puoi
passare due ore per risparmiare due ore forse
non ne vale la pena
più domande nell’ultimo dicono
stai usando l’ ingegneria del caos all’interno del tuo
propria compagnia assolutamente
noi cibo per cani o suo zio Jeff da
Amazon ha detto che beviamo il nostro champagne
noi falliamo regolarmente il venerdì
rompere il nostro servizio in realtà abbiamo bloggato
riguardo un paio di cose ne abbiamo avute alcune
quelli imbarazzanti all’inizio avevamo un disco
fill-up che ha causato un host che non era log
ruotarlo non stava pulendo quello
ha causato alcuni tempi di inattività
usiamo dynamodb indovina cosa succede quando
introduci la latenza come la tua chiave
archivio dati le cose possono andare rapidamente di lato
così ho ho pratica quello che predico in quel
riguardo bene grazie mille per tutto
il tuo tempo e per le tue domande, se tu
avere altre domande che siete i benvenuti
per venire a parlare con me in linea fuori della mia squadra
lì per una cabina prendi un adesivo
speriamo di vedervi nella comunità
o in occasione di eventi, ma se non altro ho
apprezzare il tuo tempo e attenzione
tu
grazie mille per tutto
venendo e frequentando e conosco e il
fine dell’andare verso la fine del
fine conferenza del giorno quindi io
apprezzarlo Cercherò di renderlo un
un po ‘divertente e divertente per te
in modo tale che vale la pena il vostro tempo per mezzo di
sfondo e introduzione Io in realtà
mi sono tagliato i denti con questa ingegneria del caos
test di fallimento su amazon.com
circa dieci anni fa faceva parte del
squadra del sito web al dettaglio e quando amazon.com
va giù non fanno soldi loro
non è possibile raccogliere soldi è molto costoso
e abbiamo fatto un sacco di cose reattive
delle tue operazioni tradizionali ti si avvicina
Conoscere le recensioni degli incidenti abbiamo fatto bene
gestione degli incidenti sai abbiamo cercato di
sistemare le cose il più velocemente possibile ma per
gli obiettivi di disponibilità aggressivi che abbiamo avuto
dovevamo fare qualcosa di meglio noi
doveva essere proattivo e prevenire tutto
classi di interruzioni da verificarsi così io
avuto l’opportunità di costruire una piattaforma
per aver creato questo fallimento in un ambiente sicuro e
in modo sicuro e poi andare in giro e aiutare
i team di Amazon lo usano e lo fanno parte
di quello di cui parlerò oggi è questo
idea di una giornata di gioco in cui davvero il
la radice di quello viene da Jesse Robbins
facendo questo a mano su Amazon in
primi anni 2000 dopo il mio periodo in Amazon I
voluto andare più a fondo in questo spazio e
quindi sono andato a far parte di Netflix così mentre io
era ad Amazon che avevano inventato questo
idea di scimmia del caos quindi non ho scritto
Cass scimmia era lì prima che l’avessi mostrato
up, ma quando sono arrivato c’era in realtà
un’opportunità per migliorare le scimmie
erano un buon primo passaggio ma non lo erano
abbastanza buono per il tipo di approfondimento
test di produzione che dovevamo fare
così ho avuto l’ opportunità di costruire il
piattaforma di iniezione guasti di prossima generazione
era un nome in codice adatto a sorpresa
test di iniezione fallita e DAT
ci ha permesso di fare molto più precisi
Iniezione di difetti a grana fine e abbiamo usato
quello di testare da dev e stadiazione
attraverso il cento per cento in prod e noi
ha avuto buoni risultati da entrambi
aziende
quindi avendo visto che ho successo io
fondato il gremlin per prendere gli utensili
e la cultura e l’approccio e
portalo nel resto del mondo così
con quello lasciatemi iniziare un po ‘
di una definizione cos’è il caos
ingegneria e qui è dove sto andando
prendi un po ‘di più sulla scimmia del caos
di persone hanno sentito parlare di caos scimmia di
spettacolo di mani praticamente tutti sono
diventare abbastanza noto ma una cosa io
non sono d’accordo con sulla scimmia del caos è il
idea che questo tipo di test debba essere
fatto a caso c’è un tempo e un posto
per l’iniezione di guasti casuali, ma il modo
che ci pensiamo è un po ‘
diverso quindi una delle analogie che io
amo disegnare quando sono a casa per il
vacanze o sto parlando con la mia famiglia e
si chiedono che cosa è che si fa è quello di
il vaccino o il vaccino antinfluenzale sai se
siamo tornati indietro di 200 anni e abbiamo detto hey
Ti inietterò con questa malattia
è così forte che potresti aver avuto un misto
risultato ma sappiamo che ce ne sono alcuni
vantaggi di questo processo è chiamato
ormone con il quale un sistema o un
l’organismo si adatta al danno per
diventare più forte e così uguale
la tecnica si applica al nostro software
sistemi iniettando qualcosa di dannoso
siamo in grado di capire come funziona il sistema
si comporta che siamo in grado di trovare opportunità
per migliorare sia il nostro software che
noi stessi come organizzazione e come
persone e siamo in grado di indurire il nostro
risposte per diventare immuni alle classi di
fallimento quindi la mia definizione di caos
l’ingegneria è pensosa pianificata
esperimenti progettati per rivelare il
debolezza nel nostro sistema ed è
importante da fare a mio avviso premuroso
esperimenti programmati perché vogliamo
Misurali vogliamo capire il
impatto vogliamo trattare come il
metodo scientifico dove ne abbiamo alcuni
ipotesi sul nostro sistema e vogliamo
per verificare se lo sono o no
vero e in quel processo potremmo scoprire
nuove informazioni i nostri sistemi sono complessi
e c’è un sacco di profondità per loro e
spesso non scriviamo tutto il codice
quelli che girano ci sono le librerie che sono
servizi dipendenti e
quindi è difficile per nessuno di noi davvero
conoscere a fondo come si comporta il sistema
senza qualche sperimentazione e la chiave
qui e ho menzionato questo come me
introdotto nella mia introduzione è quello
questo ci consente di essere proattivi , a
approccio reattivo fondamentale a
operazioni che non ci porteranno mai
un certo grado di affidabilità, se lo siamo
sempre in attesa che le cose falliscano e
poi sistemandoli rapidamente e provando a
evitare che si verifichi di nuovo siamo
mai andare davanti alla curva e
quindi dobbiamo essere in grado di uscire di cui abbiamo bisogno
per farlo in modo proattivo dobbiamo farlo
durante il giorno dobbiamo essere in grado di
piano per questo tipo di fallimenti e
Preparati per loro uno di quelli del
le cose mi danno sempre un po ‘di pushback
con l’ingegneria del caos va bene così
non funzione lavoro e funzionalità lavoro è
ciò che ci rende denaro quindi non so se
possiamo passare del tempo su questo e davvero
le operazioni sono un costo che paghiamo quando
le cose ti spezzano che ti porta via tempo
dallo sviluppo di funzionalità ci vuole tempo
lontano da altri aspetti dell’azienda
e così da essere pensieroso a riguardo
possiamo pianificare il tempo da dedicare a questo
in realtà risparmiamo tempo e possiamo
budget migliore e prepararsi per i tipi
delle cose che accadono, quindi cos’è un bene
definizione senza anti-definizione
quello che non è il caos di ingegneria bene per me
non si tratta di essere un cowboy o un
cowgirl solo in esecuzione in produzione
pistole infuocano e sparano ai server
roba senza dire a nessuno che non lo è
non è un gioco lupo solitario questo è un
luogo dove vogliamo collaborare noi
voglio comunicare vogliamo fare il nostro
tutta l’azienda meglio che vogliamo testare il
confini di comunicazione dei nostri servizi
e i nostri team e quindi non è qualcosa
per essere nascosto non è qualcosa di essere
fatto in background è qualcosa da fare
essere fatto sai alla luce del giorno di essere
abbracciato e poter uscire e
e diffondere la buona parola in qualche modo per
aiutare i nostri team e le nostre aziende
capire l’errore si verifica spesso a
scala ed è prudente e saggio essere
pensandoci in anticipo e
preparando per questo
è divertente per me il modo in
quale il nome chaos engineering ha
tolto e ho pensato un po ‘
perché questo lo sai che il nome del caos
questo è dove le cose sono eccitanti
è malizioso, sai che questo lo dà
quel tipo di atteggiamento giocoso divertente ma
il lato ingegneristico sai che siamo
ancora ricevendo quella disciplinata
approccio rispettabile di applicare bene
disciplina ingegneristica per i nostri sistemi
In realtà penso a causa della scimmia del caos
e a causa della casualità implicita
che ha portato che questo nome è un po ‘
di un termine improprio non si tratta di maneggiare
caos per migliorare l’ingegnerizzazione dei nostri sistemi
Infatti penso che saremmo meglio serviti da
lanciando in giro quello che vogliamo fare è
vogliamo prendere la disciplina
rispettate le pratiche ingegneristiche che noi
avere e applicarli al caos che è
già inerente nei nostri ambienti noi
avere abbastanza caos ci sono abbastanza cose
che rompono e sbagliano che non lo facciamo
necessario possiamo usarlo come strumento ma
non abbiamo bisogno di un’altra domanda
che ho pensato un po ‘a te
sapere perché questo è diventato un argomento di
interesse di recente sai che ho fatto
ricerca in questo spazio e ci sono
parla e parla di questo sul fallimento
test che risalgono agli anni ’70 e al
Anni ’80 ci sono molti buoni post sul blog
dagli anni ’90 e dai primi anni 2000
descrivere questo stesso processo e lo stesso
metodologia quindi cosa è cambiato in
ultimi cinque o dieci anni che ha davvero
ha portato alla necessità di questo approccio
bene uno dei nostri sistemi usato per guardare a
un po ‘diverso questo è un po’ di un
semplificazione eccessiva ma tu conosci un po ‘
gli approcci della vecchia scuola ne avevamo alcuni
data center e potremmo reindirizzare
traffico tra di loro all’interno dei nostri dati
centri le nostre applicazioni erano un po ‘
un po ‘più semplice, lo sai
tendeva ad essere a tre livelli ne avevamo alcuni
front-end abbiamo avuto qualche logica aziendale noi
lasciare che il database gestisca molte delle
problemi di coerenza e molto del
pezzi appiccicosi ovviamente i nostri sistemi oggi
sembra un po ‘diverso questo è un
immagine di Amazon.com questo è in realtà
circa 2008
Ero nella squadra che ha generato questo
mestiere questo è solo amazon.com c’è
niente da Kindle o digitale c’è
niente da AWS sono il grafico
l’altro lato è Netflix questo è
in realtà mi precede anche questo è come
2010 2012 e tu sai cosa abbiamo io
chiamali palle della morte di micro-servizi
sai che è quasi come la Morte Nera
questo il grado di complessità all’interno del nostro
i sistemi ora sono troppo per nessuno
ingegnere o una squadra da mantenere
completamente nella loro testa sai che possiamo
non fare più affidamento su un architetto
capire tutte le modalità di errore e
proteggici da esso ce ne sono troppi
le cose che stanno succedendo lo rendono anche di più
difficile per noi andare in giro e testare
queste cose una domanda che ottengo sei tu
lo so bene, posso solo fare un po ‘di unità
testare e coprire molti di questi casi
ma in realtà li stiamo testando
confini tra microservizi e così via
sai se guardiamo qualcosa
ha anche un centinaio di microservices solo
testare tutte le combinazioni di errori
ci sono da 2 a 100 possibilità
se passiamo attraverso quello e un bruto
metodo di forza che il Sole brucerà
prima di finire quel percorso di prova e così via
abbiamo bisogno di qualcosa che sia più efficace
e più efficiente per essere in grado di
capire questo tipo di complessità e io
sarebbe postulare che l’ingegneria caos per me
ha dimostrato di essere uno strumento prezioso per
realizzare ciò alla fine predicendo
fallimenti un po ‘come predire
il tempo che sai che la teoria del caos dice
noi se lo avessimo se sapessimo tutto l’input
variabili se conoscessimo tutti i modi in
quali quelle variabili hanno interagito noi
potrebbe modellare correttamente il sistema
si comporterebbe e cosa accadrebbe ma
proprio come quando ma ma non lo facciamo
conoscere tutte le variabili che non possiamo
calcola tutte le possibili combinazioni
di cose che possono accadere c’è umano
fattori ci sono fattori tecnici
ci sono cose fuori dal nostro controllo
sai che molti di noi non possiedono i nostri
hardware più ci sono così tanti in movimento
pezzi che diventa molto difficile da
prevedere e quindi in un modo che stiamo modellando
e come otteniamo più informazioni siamo
regolando quel modello uno degli
le differenze tra le tue conoscenze sono prevedibili
uragani e previsioni di interruzioni e
software possiamo andare a simularli
tipi di eventi possiamo farlo in una cassaforte
modo in a
modo terribile ma possiamo effettivamente causare
questi fallimenti sai se potremmo
genera un uragano nell’Atlantico di a
di piccole dimensioni e poi lo abbandona quando noi
ce ne siamo andati se ci fossimo fermati
pulsante nel caso in cui le cose andassero male, forse
potremmo modellare meglio quelli e così io
penso che siamo un po ‘di un
vantaggio rispetto alla previsione e
modellazione e altri sistemi complessi quindi
voglio parlare un po ‘di cosa
entra nella pianificazione di un giorno di gioco
e come pensare a cosa può andare storto
e come pensare a come uscire e
efficacemente questo test e il
la prima domanda è proprio quello che potrebbe
sbagliare una delle cose che amo fare
quando lavoro con una nuova squadra o a
nuovo cliente è quello di ottenere un sacco di
ingegneri nella stanza e lavagna fuori
il loro servizio mi limita a disegnarmi
esempio di come appare mostrami
alcune delle interazioni questo è un
versione semplificata del API Netflix
e al suo interno abbiamo un po ‘di caching siamo
avere alcuni servizi dipendenti che noi
attraversa i confini della rete Netflix utilizza il
schema dell’interruttore nella storia come a
modo per aggiungere un po ‘di protezione in più
difetti che potrebbero verificarsi così proprio qui se
diciamo che cosa potrebbe andare storto c’è un
un sacco di cose che mi vengono fuori
prima di tutto ogni volta che vedo una rete
connessione Sono dubbioso che la rete sia
non affidabile e non è nostro amico
è spesso la causa del nostro dolore e
mal di testa e quindi vorremmo testare
cosa succede se non possiamo parlare al
servizio di playlist che vorremmo
parla vedi cosa succede se le valutazioni
il servizio all’improvviso diventa molto più lento
o i tempi di risposta raddoppiano cosa
succede se contiamo molto sulle nostre cache
essere in grado di gestire il flusso di
il nostro sistema e che la cache va via io
capovolto questa interruzione alcune volte
aumenti il servizio dipendente reale
veloce e spero di ottenere o sperare di risolvere
il cache e quindi ci sono molti di questi
punti potenziali che potrebbero fallire o che
potrebbe non funzionare correttamente così da questo
veniamo elencati un insieme di cose
potrebbe essere interessante per noi
esplorare o per capire meglio il
la seconda domanda che mi piace chiedere è una
aiutare con la definizione delle priorità
quanto è probabile che ciò accada e questo è
un questa è una spada a doppio taglio
nel modo in cui abbiamo posto questa domanda
da un lato se abbiamo avuto tre interruzioni
quest’anno e si sentono tutti molto simili
erano tutti legati a una disponibilità
zona in mancanza o erano tutti legati a
un servizio che scende, allora lo sappiamo
ci sono dei frutti a bassa percentuale
può andare e possiamo passare un po ‘di tempo
testare quei guasti e assicurare che
siamo resilienti a loro o ci occupiamo di noi
loro meglio il rovescio della medaglia c’è
idea dell’evento Black Swan l’evento
quello può essere estremamente raro ma può avere
un impatto catastrofico per la tua azienda
quando si verifica e ciò potrebbe non essere
qualcosa che succede spesso ma tu
voler preparare per questo, perché ci piace
avendo il nostro lavoro e le nostre aziende noi
non voglio che vadano necessariamente via
c’è un grande esempio in
mondo di trading ad alta frequenza di un bug
l’hanno trasformato in produzione che ha perso
300 milioni di dollari in un minuto o due
che era la fine di tale società come
vale la pena dedicare un po ‘di tempo extra e
tentativo di prevenire quei rari casi anche
anche se sono rari così da questo
pensiamo attraverso quello che potrebbe andare storto noi
pensa a quanto è probabile che si verifichi
lo diamo la priorità e da quello siamo
troverò una serie di esperimenti
una serie di ipotesi su come il nostro sistema
si comporta e come pensiamo il risultato
accadrà l’ultima domanda che mi piace
chiedi e penso che questo sia prezioso
specialmente come stiamo parlando al nostro
leadership o la nostra gestione sul
costa quale è il costo di essere sbagliato
il software è costoso da scrivere
costoso da mantenere e quindi abbiamo bisogno di
essere in grado di tagliare dobbiamo essere in grado di
giustificare il tempo e gli sforzi che spendiamo
questi tipi di interruzioni di approcci sono
costoso
quando s3 fallì due anni fa lo fu
stimati a costare a tutti quelli che non lo erano
Amazon centocinquanta milioni
dollari abbiamo avuto due principali compagnie aeree
interruzioni nell’ultimo anno British Airways
e Delta erano entrambi cento milioni
plus in entrate perse e un impatto in
gli Stati Uniti sono stimati a 700
miliardi persi a causa di interruzioni e tempi di fermo
come una buona metrica ma penso un po ‘
metrica datata che stima che nel
il mondo dei data center il costo del downtime
è 5.000
un minuto o $ 300.000 l’ora come pensiamo
su di esso sai venire dall’Amazzonia
mondo dell’e-commerce quando sei giù sei
perdere le entrate che c’è un diretto
linea di vista a quel denaro che si sta perdendo
in Netflix
è un sistema basato su abbonamento e così via
mentre i tempi di fermo non hanno un impatto diretto
entrate che incidono sul marchio e
fiducia dei clienti e se i vostri clienti
smesso di fidarti di te che possono decidere di farlo
andare a un servizio concorrente che possono
Decidi che non vale la pena pagarti o
continua e tutte queste metriche
tipo di ignorare quello che per me è l’iceberg
che si trova sotto l’acqua che è il
costo tecnico associato alle interruzioni
e tempi di inattività spesso pensiamo a un’interruzione
come sapete, spero un 15 a 20
Periodo di tempo di 30 minuti in cui tutte le mani
sono sul ponte per andare a sistemare tutto ciò che è sbagliato
ma non è la totalità del costo
di un’interruzione che ha vissuto anni
di loro lo sai
poi c’è il giorno o due di andare e
immersione in tutti i dati e il
le metriche che fanno l’analisi è a
capire i fattori che contribuiscono e
gli aspetti che hanno portato a quella interruzione
di solito c’è un incontro con una correzione
di errore o un post-mortem dove un grande
parte della compagnia è nella stanza per
parlare di questo fallimento del cliente
impatto e cosa succede da quello
di solito c’è tutta una serie di azioni
oggetti che devono uscire e essere riparati
per impedire questa interruzione da sempre
si ripresenta di nuovo e poi qualcuno lo ha
uscire e implementare quelli e
idealmente in realtà prova che proteggono
tu in realtà penso che sia una parte di
il ciclo che tende a mancare nel nostro
sistemi tendiamo a sistemare gli elementi di azione
e incrociamo le dita e benissimo se
succede di nuovo che sapremo se è così
risolto e proprio lì che è dove
l’ingegneria del caos in realtà stiamo andando
fuori e ricreare quell’incapacità di vedere
se aggiusti il sistema e ce l’hai fatta
più resistente è la chiave ma il
i tempi di progettazione e lo sforzo che va
in tutto questo processo è solo molto
costoso e così questi tre fattori
davvero aiutaci a capire perché il
il business dovrebbe essere interessato all’investimento
il tempo e lo sforzo in questo tipo
di approccio quindi ora voglio dirti a
un po ‘ su come io
i giorni di gioco in corso e quello che penso
è un modo efficace per affrontare questo la
primo passo è che abbiamo bisogno di
comunicare come ho detto questo non lo è
conosci una così solitaria attività da lupo
voglio essere in grado di avere la compagnia
consapevole che stiamo facendo questo tipo di
attività che in genere vogliamo avere
qualche centro di comando dove le persone possono
check in forse lo faremo a
una in una stanza lasco forse stiamo andando
avere un ponte per le conferenze, forse è così
sarò alla scrivania di qualcuno ma in un posto
che le persone che sono interessate possono venire
e capire cosa sta succedendo e come
la sua comportandosi questo ci dà un posto per
condividi le metriche per condividere gli avvisi che vogliamo
vogliamo oltre comunicare che siamo
eseguendo questi esperimenti potremmo volerlo
avere una presenza di successo o consapevole del cliente
possono essere in grado di provare dolore al cliente
e vedere i problemi prima che siamo in grado di
rilevarli e questo è fondamentale che vogliamo
per garantire che abbiamo il nostro upstream e
i nostri sistemi a valle ti presentano
se potessimo potenzialmente avere un impatto
loro o potrebbero avere un impatto su di noi allora
dovrebbero essere consapevoli che questo tipo di
l’esercizio si sta verificando e una cosa
questo è fondamentale per l’ esecuzione di questi giochi
giorni è che vogliamo evitare il cliente
dolore l’obiettivo di questi esperimenti il
obiettivo di questo giorno di gioco è quello di prevenire
interruzioni è per prevenire i tempi di fermo e così via
non vogliamo causare accidentalmente
tempi di inattività come parte di eseguirli
esperimenti e così con quello che voglio
spiegare questo concetto del raggio di esplosione
ogni volta che eseguiamo un esperimento
c’è il rischio che sia in dev o
messa in scena o in produzione che potremmo
rompere colleghi ingegneri che potremmo
rompere i clienti che potremmo causare dolore
e una perdita di efficacia e quindi cosa
vogliamo fare è quando eseguiamo un
esperimento vogliamo eseguire il più piccolo
esperimento che ci insegnerà qualcosa
se possiamo eseguirlo su un singolo utente a
una singola serie di richieste per un singolo dispositivo
forse è un singolo contenitore o un
host singolo ma vogliamo eseguire il
il più piccolo esperimento che funzionerà e
poi ad ogni passo che stiamo andando
cresci quel raggio di esplosione che ci trasferiremo
per eseguire un esperimento più ampio perché
abbiamo costruito una certa fiducia e fiducia in
il sistema
o troveremo un bug e lo siamo
sarò in grado di andare a sistemare quell’errore e
abbiamo vinto perché l’obiettivo è trovare
insetti prima che ci causino dolore
e così qui abbiamo un’ipotesi
quindi abbiamo enumerato le cose
potrei sbagliare, lo faremo
esperimento che misureremo il
risultato di quell’esperimento spesso noi
voglio sapere che il nostro impegno funziona
correttamente riceviamo il paging quando le cose
pausa sono i nostri allarmi sintonizzati correttamente
sappiamo abbastanza presto o i nostri cruscotti
utile se qualcosa è rotto fa il nostro
la dashboard ci aiuta a trovare la causa o lo fa
si intromette e da ciò siamo
avrò una serie di criteri di successo a
insieme di criteri di fallimento e alcuni abortire
condizioni ancora non vogliamo mai causare
dolore del cliente reale e quindi se lo siamo
abortiremo l’esperimento perchè
ciò significa che abbiamo trovato qualcosa che
non dovrebbe accadere ad Amazon questo
erano ordini al minuto se vedevamo un
impatto per gli ordini al minuto vorremmo
fermare l’esperimento avremmo pulirlo
e Netflix era in grado di far scorrere le persone
e se ciò fallisse, se vedessimo un calo
che avremmo automaticamente fermato il
sperimentare e lo faremmo anche se fosse così
non è stata colpa nostra anche se fosse successo
che un’altra interruzione stava avvenendo al
allo stesso tempo non vogliamo infangare il
acqua e non vogliamo causare
confusione in questo processo e poi noi
eseguire l’esperimento e il sistema
si comporta come ci aspettiamo con grazia
degrada il cliente non può il cliente
non vede l’impatto di quel fallimento
o qualcosa rompe qualcosa no
funziona come ci aspettiamo e se questo è
Nel caso in cui abbiamo finito abbiamo trovato un bug noi
puoi andare a prenderlo offline che possiamo capire
perché si verifica possiamo fare il cliente
migliore esperienza e possiamo tornare
e testarlo in un secondo momento quindi un
esempio di come misurare l’errore
questo è un grafico rubato da Netflix il
la linea nera che attraversa la cima è
se le persone possono streaming il verde è
questo è un comando di storia il verde è
esecuzioni di successo e il rosso è un
esecuzione fallita e cosa puoi vedere
ecco che iniziamo questo esperimento
e stiamo iniettando una piccola quantità di
fallimento sai 10 o 20% del
traffico generale
c’è un po ‘di accumulo qui
con tentativi e simili ma sospendere
incredulità , quindi dopo che abbiamo corso
questo esperimento per venti minuti noi
vedere che i clienti non sono interessati
sono ancora in grado di streaming e cose
stanno funzionando come previsto così ora ci rampa
su quell’esperimento vanno a circa il 50%
circa l’80% e poi fino al cento percento
e ad ogni passo vediamo fallimenti
si verifica nel sistema questo servizio è
non funziona restituisce errori
ma l’esperienza del cliente è essere
ha funzionato ancora correttamente
e le persone sono ancora in grado di trasmettere e
alla fine di questo esperimento possono farlo
puliscilo e loro possono rotolarlo indietro
e quello che abbiamo imparato è se questo
il servizio non riesce per un periodo di tempo
il cliente non noterà questo richiede
qualcosa che potrebbe essere un’alta severità
sette sette Siddhant nel mezzo di
la notte e lo trasforma in qualcosa
che potremmo guardare il giorno dopo
durante le ore lavorative in cui i clienti
non saprò dove ovviamente fornisce
un certo valore vogliamo che funzioni, ma quando
è rotto non causa molto
il dolore del prossimo suggerimento è che abbiamo bisogno di noi
ho bisogno di esercitarmi, sai che mi piacerebbe
per disegnare sull’esercitazione antincendio
sapere quando ci sono situazioni di emergenza
quando ci sono cose urgenti ad alto stress
che si verificano la gente ha bisogno l’opportunità di
pratica in anticipo che vogliamo costruire
quella memoria muscolare che vogliamo essere in grado di
gestire questo tipo di situazione in modo pulito
e modo efficiente
non vogliamo andare nel panico che vogliamo essere
premuroso e quindi come tale numero uno
dovrebbe essere pratica dovremmo essere
eseguendo questi in anticipo scherzo che il
addestramento a chiamata L’ho ottenuto quasi
ogni azienda è qui il tuo cercapersone buono
fortuna ci potrebbe essere una corsa prenotata è
laggiù
nessuno di essa ha esaminato nel mentre una figura
è fuori sei intelligente e sai immaginare
un mondo invece dove la prima volta
stai chiamando il tuo team viene da te
e dicono che sappiamo che sei di guardia
questa settimana avrai una pagina ma
non ti preoccupare
è un esercizio di simulazione che controlliamo noi
avere una rete di sicurezza ma noi vogliamo che tu
trattalo come un vero evento che ti vogliamo
a
controlliamo vogliamo che fidanzarsi vogliamo
tu a guardare i tuoi allarmi ti vogliamo
per guardare i cruscotti che vogliamo che tu faccia
scavare nel sistema per capire come
succede ma piuttosto durante a
evento stressante nel mezzo del
notte dove hai, forse sai
leadership sui clienti di chiamata
preoccupato per la diffusione di Twitter di Netflix
le persone sono infelici lì non è un
ottimo momento per fare domande che conosci
è difficile e tu vuoi creare
un’opportunità per le persone di imparare e
per fare domande sul loro servizio così
che possono acquisire quella familiarità e
conforto prima che siano chiamati a fare
è vero James Hamilton, sono un po ‘
un suo fan è un distinto
ingegnere VP presso AWS prima di essere a
Microsoft Research ha scritto un articolo
sono passati 10 o 15 anni ma per me
è quasi come l’ops Bibbia che ha così
molta saggezza applicabile convenzionale in
è su progettazione e distribuzione
servizi di scala internet e all’interno di questo
ha parlato diverse volte di questo
concetto qui che se non vogliamo
prova in produzione ci dice qualcosa
su quanto siamo fiduciosi nella nostra
sistemi se siamo così preoccupati che tu
sapere perdere un host o qualcosa da ottenere
più lento è qualcosa che siamo solo
riluttanti a sperimentare poi il nostro
sistema non è in un buon posto siamo
correndo troppo vicino al bordo o noi
non ho abbastanza informazioni e
capire di essere a proprio agio e poi
si va avanti a parlare di se abbiamo
questi meccanismi di recupero così forse
siamo in grado di evacuare le regioni nel
caso di un fallimento forse abbiamo un
backup del database archiviato fuori sede
abbiamo mai recuperato quel database
sappiamo che il recupero di quel database è
andando a lavorare correttamente
abbiamo mai evacuato una regione per davvero
o ne abbiamo appena parlato Adrian
Cockcroft parla di questo come
disponibilità teatro cose che noi
pensare sono gonna lavorare, ma in realtà può
non e ho visto esattamente questo esatto
problema in azione se sei nel
al centro di una interruzione e tu vai a risolvere
quella interruzione con quest’altra ripresa
meccanismo e quel meccanismo di recupero
fallisce ora hai davvero una terza interruzione
hai due interruzioni in corso al
stesso tempo
e invece di salvarti e fare
la tua vita migliore è effettivamente fatta tua
la vita più complicata e più dolorosa
e parlerò un po ‘di
come abbiamo fatto questo a Netflix in modo che noi
sono stati preparati quando è arrivato il momento, quindi cosa?
conosci grandi storie ma parliamo
su alcuni esempi del mondo reale, facciamolo
cammina attraverso alcuni posti dove abbiamo
visto questo in azione il primo è questo
esempio di evacuazione della regione così in
Dicembre del 2013
Netflix è rimasto inattivo per circa un giorno
un fallimento in noi East One e Netflix
era solo in noi due est e così
hanno deciso che era importante per
loro per andare a gestire essendo regione trasversale e
essere in grado di evacuare le regioni questo è
esattamente questo tipo di evento Black Swan a
molte persone potrebbero dire bene che sono
faranno bene che lo faranno
un buon lavoro che stiamo andando a sapere questi
tipo di guasti su larga scala che sono
semplicemente improbabile e mentre potrebbe essere
è vero che potrebbero essere improbabili che lo siano ancora
eseguire sistemi complessi che sono
difficile da gestire e da gestire e
quindi gli stessi tipi di cose che siamo
suscettibili a loro sono e quindi abbiamo bisogno
prepararsi per questo tipo di evento a
Netflix dopo aver inserito questo processo
luogo hanno iniziato a gestire queste regioni
evacuazioni ogni due o tre settimane in
l’inizio di questa regione di evacuazione
ci sono voluti 45 minuti in più
squadre e aveva un sacco di manuale
Interazione coinvolta oggi penso a me
leggere un post sul blog qualche mese fa
hanno verso il basso per essere meno di cinque minuti
ad essere fondamentalmente interamente
automatizzato e sono in grado di farlo a
l’avviso di un momento la chiave qui è quella
continuano a eseguire questo processo hanno
non ho detto oh, abbastanza bene, abbiamo finito ora
ogni due o tre settimane evacuano a
regione per reale e perché è questo
importante perché ogni altra corsa o così
c’è qualche nuovo bug che emerge forse
c’è un nuovo servizio che ha un ridimensionamento
confine quando la situazione è che il flusso che
quel traffico di rete extra forse c’è
un bug nel nostro codice proxy che non lo è
ci permettono di reindirizzare il traffico nel modo
che ci aspettiamo
qualunque sia il caso per regolare
esercitando questo trovano e risolvono questi
problemi quando arrivano così quando
le cose vanno male è lì
sarà affidabile funzionerà quando
è chiamato e negli ultimi sei
mesi a Netflix ho avuto questo
messo a punto due volte
abbiamo avuto un sabato o una domenica mattina
dove non siamo riusciti a ottenere nuovi ospiti in noi
Quello orientale e lo sapevamo come traffico
impennato per il giorno che stavamo andando
essere sotto capacità e questo è stato un giorno
quando Reddit e Twitter erano in fiamme con
conosci gente che brucia e a
molto dolore ma perché questo era un
Evento regolarmente praticato
secondario
il mio principale ha appena scoperto quello che il
problema era che vide che era un
problema con AWS abbiamo avuto una chat
conversazione e abbiamo iniziato a cambiare
il traffico prima di dover davvero dover
bisogno di coinvolgere il resto della compagnia
sai che abbiamo ancora fatto la conferenza
ponte abbiamo coinvolto tutti, ma è così
era fondamentalmente un non-evento per noi perché
era ben praticato perché lo era
ben capito e questo è esattamente il
tipo di posizione vogliamo essere in noi
voglio essere preparato in modo che quando questi
gli eventi si verificano sembrano non eventi
sembrano come si comportano come noi
li voglio ad un altro esempio
chissà cosa è critico nei loro
sistema e cosa non lo è per certo sì
abbiamo avuto questo problema su Amazon qui
dei modi in cui sei diventato un livello uno
il servizio su Amazon è stato causato a
cliente in disservizio e se tu
non erano nella lista in cui eri ora
lista e persone in quella lista sono state tenute
a uno standard più elevato che dovevano fare
più preparazione avevano bisogno di essere loro
sono stati cercati in qualsiasi incidente su larga scala
c’è stato un sacco di lavoro extra che è andato
in essere un servizio di primo livello su Netflix
siamo venuti su un modo migliore per scoprire
questo abbiamo preso alcuni dei nostri flussi di lavoro principali
sai per prendere Xbox prendere un
PlayStation prende un iPhone e ti segue
conosci l’ accesso al polmone del sale sfoglia una ricerca a
film e gioca quel film fa così
quel flusso di lavoro principale funziona e quindi cosa noi
è stato automatizzato con alcuni
test di fallimento
abbiamo autorizzato ciò che pensavamo fosse il
servizi critici e abbiamo fallito il traffico
a tutti i servizi non critici ora
ogni volta che quell’esperimento automatico è stato eseguito
se ciò fallisse , sapevamo che era nuovo
il servizio critico era stato introdotto e
potremmo decidere se
volevamo che fosse un servizio critico
o no, andremmo in quelle squadre e noi
direbbe hey sai che sei di livello
uno ora e loro andrebbero quello che no è
ok, lo sapremo solo noi
voglio solo che tu sia impaginato in ogni
grave incidente e fare un sacco di prontezza
e preparazione prima di fare una distribuzione o voi
potrebbe trovare un modo per farlo con grazia
degradare e togliersi di mezzo e nove
volte su dieci erano come oh no
può solo servirti una riserva di cache e
possiamo andare avanti e abbiamo pensato che fosse
grande
sai che il servizio meno critico è
minore è la complessità, più facile è
capire quando le cose vanno male e così io
davvero mi è davvero piaciuto che abbiamo trovato un
modo migliore per affrontare questo problema
e poi la domanda va come se noi
aspettiamo cinque anni potremmo essere in a
posizione in cui solo qualcun altro ha fatto
tutto questo test per me e mi ha detto cosa
andrebbe male e così ho avuto il
opportunità di lavorare con Peter Alvaro
è un dottore di Berkley ora all’UC Santa
Cruz ha avuto questa idea chiamata lignaggio
iniezione guasta diretta e senza andare
troppo profondamente in quello essenzialmente invece
di guardare tutte le cose che potrebbero
andare male guardiamo cosa è andato bene
e iniziare a rimuovere le cose è come
come se blocchi Jenga se togliamo qualcosa
critico che cadrà
se togliamo qualcosa che non lo è
critico che potremmo fare a meno di usare così tanto
la piattaforma che ho costruito su Netflix
sono stati in grado di prendere questo durante l’estate
e costruisci una dimostrazione del concetto dove
lo sfondo sulla produzione reale
traffico penso che sia stato punto zero zero
zero l’uno percento del traffico di produzione
numero molto basso di richieste che eravamo
in grado di eseguire questo tipo di esperimenti noi
sono stati in grado di vedere come una chiamata di servizio
lavorato o un grafico ha lavorato siamo riusciti a
rimuovere automaticamente le cose da esso e
quindi rivedi quella richiesta o trovane un’altra
richiesta che era simile a quella da vedere
come non è riuscito a vedere se siamo stati in grado di farlo
cavarsela senza quei servizi
e ciò che è interessante di questo io
ho parlato prima facendo una forza bruta
analisi di un grafico microservizio se tu
avere cento micro-servizi è due
alle 100 esecuzioni avendo una migliore
cerca lo spazio limitandolo ed essendo
più riflessivo su come lo esplori
siamo stati in grado di farlo in circa a
cento esecuzioni penso che sia stato un
cento a duecento molto meno
complessità nel tempo impiegato
cerca questo spazio e lo abbiamo trovato reale
bug di produzione in Netflix
alcuni dei quali erano punti singoli di
fallimento singoli servizi o singoli team
alcuni dei quali erano profondi fallimenti
richiesto due o tre cose fallendo a
nello stesso tempo e se mai hai corso
sistemi di produzione di produzione su vasta scala
sai che mi piacerebbe se solo le cose
fallito uno alla volta, ma la maggior parte dei
interruzioni interessanti sono due o tre
cose che falliscono allo stesso tempo e così
cosa stiamo andando qui intendo il
risultato è che c’è un sacco di fatica in
operazioni c’è molto burnout
c’è molta fatica da cercapersone se andiamo
attraverso e prendiamo un po ‘di più
approccio proattivo e lo esploriamo
e ci mettiamo a nostro agio con ciò non lo farà
sentiamo tanto quanto noi possiamo essere un lavoro
un po ‘ più felice e speriamo di esserlo
pagati meno speriamo di no
essere svegliato alle 2:00 del mattino
questo in generale ci aiuterà ad aumentare il
affidabilità dei nostri servizi che è di
Naturalmente, perché le cose falliranno
ed è un po ‘folle
sperare che le cose non falliscano
è meglio abbracciare quella strategia e
tuffarsi in esso e così con quello di
le cose che sono eccitanti è questa è una
nuovo spazio è up-and-coming ma noi
non ho capito tutto, c’è molto
di spazio per l’innovazione e per
crescita e quindi voglio invitare tutti
qui a venire unire l’ingegneria del caos
comunità vieni e partecipi abbiamo un
il problema pubblico non riguarda Gremlin
è solo lì per le persone a condividere la loro
esperienze e loro apprendimenti
le loro interruzioni penso che siamo appena sotto un
mille membri quindi se ti sei iscritto oggi
potresti ottenere che io penso il
il millesimo membro che faremo
qualcosa di divertente o speciale su e
c’è un sacco di meetup o
il mondo che puoi andare e puoi
parla delle tue esperienze che puoi
condividi i tuoi insegnamenti o puoi imparare
da altre persone come te e se
non c’è un incontro quindi è fantastico
possibilità di andare a prendere uno per andare a prendere
quello che hai imparato o prendere ciò che è
là fuori su internet e puoi
impara e condividi con le persone
intorno a te e con quello darò un
breve appuntamento per la nostra conferenza questo autunno
a settembre a San Francisco che è
sarò concentrato interamente sul caos
ingegneria con Adriene Cockcroft da
AWS
X Netflix keynoting e Jessie
Frisell di cui parlerò
fallimento in contenitori data la sua profondità di
Esperienza lì così con quella ne ho uno
ultima maglietta perché apparentemente le persone
come le nostre magliette e così chiunque voglia
per chiedere la prima domanda che darò
l’ultima t-shirt gremlin rimasta per
e con questo vi ringrazio molto per
il tuo tempo
prima domanda per la maglietta
andiamo ora, scopro che ho messo troppo
stressarlo se non vuoi il
t-shirt non devi prenderlo è
okay mi stavo chiedendo uno dei
critiche che hai avuto sulla scimmia del caos
la cosa era che era troppo casuale se io
non potrei parafrasarlo così, ma io
posso immaginare che potrebbero esserci dei fallimenti
che non puoi pensare prima e
loro possono accadere quindi non ti senti
che c’è un po ‘di spazio per quello o
dovrebbero essere bene, quindi per prima cosa vorrei dire
che i fallimenti che il caos scimmia
fornisce un riavvio degli host, quindi non lo siamo
andando a imparare necessariamente qualcosa di nuovo
che non potevamo fare semplicemente riavviando
ospita noi stessi lo sai in un certo senso
ci costringe ad avere un apolide
applicazione che è parte del perché tu lo sai
come Netflix si sta muovendo verso il cloud è stato
hey Amazon potrebbe farlo in qualsiasi momento
devi prepararti per questo devi essere
pronto così in questo modo è un buon forzante
Funzionilo architettonico II forzato
ingegneri di Netflix per pensare a cosa
accadrebbe quando il loro ospite si riavvierà
ma come si misura il risultato di
quell’esperimento se le cose sono casuali
rompere a volte casuali forse solo
contribuisce a questo background di basso livello
rumore di errore quando sono in esecuzione
esperimenti voglio vedere un grafico chiaro
che mi dice come le cose stanno comportando I
voglio qualcosa che sia perseguibile come un
risultato voglio capire davvero
dove il punto di svolta è per il mio
servizio se sto facendo qualcosa di simile
ottimizzazione dei pool di thread o dei timeout di ottimizzazione
e c’è una certa soglia dove
tutto quello che sai è quel gomito come
se io se iniettassi casualmente quantità casuali
di latenza come farò a sapere dove
quel gomito è e come sto andando
impara da quello, quindi non è per quello
test di guasti casuali non ha a
tempo e un luogo, ma trovo che sia
più facile da capire e molto altro
più facile ottenere informazioni utilizzabili da
facendo l’ approccio non casuale fai tu
voglio la maglietta che prenderò grazie
per la tua domanda altre domande
Ho adesivi ma io non più magliette
scusarsi come si ottiene la gestione
per vedere la pena di uccidere l’ingegneria che è
una grande domanda perché la maggior parte delle persone lo è
un po ‘di difesa quando glielo chiedi
spendere tempo o denaro per un nuovo approccio
e per me è per questo che ho parlato del
costo del downtime se puoi tradurlo
in perdita di entrate ha perso l’ingegneria
sforzo e puoi davvero quantificarlo
dolore che senti che stai per
passare molto più tempo a convincere la tua
gestione se posso andare e dire che perdiamo
ogni interruzione che dura 30 minuti o
più ne perdiamo centocinquanta
mille euro proprio lì il nostro
la direzione dirà bene che io
potrebbe probabilmente pop potrei probabilmente pagare
un ingegnere per lavorare su qualcosa per a
anno per quello e all’improvviso ora
possono quantificarlo
se diventa hey ci piacerebbe ottenere
queste nuove funzionalità sono state fatte, ma tutti abbiamo capito
paginato alle 3:00 del mattino e poi
trascorso tre giorni a scavare in questo
interruzione e abbiamo ancora un po ‘di lavoro
per fare bene ora hai a che fare
con il tempo perso e questo è il momento
non sono cose spese per le funzionalità che non lo sono
speso per migliorare il sistema è
sentendo che il dolore reattivo così
quantificando che quel costo è veramente
quello che penso è la via per
successo lì buono che ho messo in discussione
che ci sono dati disponibili su come
a quanti piace quanta parte di questa fatica e
la cosa è effettivamente ridotta, quindi lo dirò
tu la mia esperienza personale che puoi
prendi come un aneddoto ma come è un nuovo spazio
Non so molto di quanto pubblicato
studi o informazioni so che tu
sappi che DynamoDB usa questo approccio per testare
come hanno gestito il data center e la rete
partizioni e problemi trovati e risolti
prima che andassero a vivere abbiamo visto un mercato
aumento del nostro nella nostra disponibilità a
Amazon e Netflix come risultato diretto
di questo in particolare il mio team in Netflix
posseduto il procs il gateway di bordo il
proxy e il gateway API e quando io
arrivati siamo stati pagati spesso e
era un servizio di medio livello che avrebbe fallito
la storia era in realtà nata da questo dolore
ma anche la configurazione delle storie
difficile che è parte di ciò che ha portato a
questo andando fuori e in modo proattivo
fallimento testando la perdita di quelli a metà
servizi di livello siamo passati da tre nove
di uptime a quattro nove di uptime e il mio
la squadra è stata paginata
cinque percento in meno ogni anno quindi sono un
credente ma so che è su di me come a
proprietario della società per andare a trovare le metriche migliori
che supporta questa idealmente vorrei
per trovare aziende che non sono Amazon e
Netflix Vorrei sentire dal
resto del mondo le loro esperienze
i loro risultati come hanno misurarono
e il valore che ottengono la nostra priorità
Un allarme si attiva solo quando il cliente
è in procinto di essere colpito quindi come si fa
si prova coloro che in modo sicuro senza colpire
il cliente così di nuovo quello è il
raggio di esplosione sai che puoi farti
costruire un esperimento che potrebbe causare
una piccola quantità di dolore del cliente ma non
una grande quantità così in realtà il modo in cui
l’abbiamo fatto su Netflix, potremmo farlo
dì quale percentuale di traffico volevamo
impatto e quando avremmo prima eseguito un
esperimento avremmo iniziare test di prova
ci assicureremmo quel tipo di nostro
felice che le nostre aspettative al massimo
livello raggiunto quando ci siamo trasferiti
la produzione del primo esperimento sarebbe
come punto zero zero un percento di
traffico per un periodo più breve, come ci sono voluti
ed erano tutti gli occhi sui grafici
metriche gli errori dei clienti e se noi
visto fallire se potessimo rilevare l’errore
non abbiamo avuto bisogno di eseguire più esperimenti
potremmo andare e potremmo andare a capire
da dove viene e aggiustalo se noi
non riuscivo a scoprire che il fallimento eravamo noi
sicuro di spostarlo di una tacca
quindi punto zero zero per cento per cento ora
andremo all’uno percento dell’uno percento
il modo è un buon controllo di sanità mentale ora possiamo andare
al 10 percento il 10 percento si comporta bene 50
cento e una cosa che ho dimenticato
menzionare sei proprio tu che stai provando
per cose diverse su scala diversa
quando sei in quella scala molto piccola
è gestire le eccezioni che gestisco
Null ho un buon ripiego
degrado con grazia quando sei a
Il 50% o il cento per cento lo fa io
proteggimi come un servizio che ho versato
il traffico è molto buono per me
marcia indietro quando quando c’è molto da
riposa nel sistema in scala o nella mia discussione
le piscine sono sintonizzate sui miei timeout
in modo appropriato in modo che io possa continuare a
lavorarci senza travolgere
qualcun altro grazie grazie
qualsiasi altro online ti amo , lo adoro
quindi in molti casi la procedura di test
stesso causa il più grande problema come in
reattori nucleari come te ne occupi
la procedura di prova fallita chiama nel
quindi è di non seguire le migliori pratiche
non seguendo la procedura che puoi causare
facciamo in modo RISPONDO correttamente
quindi quando si inietta un errore si inietta
le uccisioni e poi quello che porta al massiccio
insuccesso quindi di nuovo penso che questo si incastri
bene con la domanda sul raggio di esplosione
perché se iniettando un fallimento e
come un contenitore o un host porta
giù l’intero sistema si dovrebbe
probabilmente lo so perché è carino
facile da fare
conosci di nuovo te che vuoi praticare
sia i tuoi modi tecnici che i tuoi modi sociali
di affrontare questi fallimenti e quindi se
non hai avuto l’opportunità di correre
attraverso questo non vuoi essere
sorpreso che qualcosa potrebbe causare a
fallimento catastrofico e così in un modo
sapere se non siamo se non sappiamo
allora il nostro sistema è in quello stato
allora siamo nei guai perché lo sarà
un brutto giorno quando succede e lo farei
piuttosto so ora o preferirei sapere quando
Ho il controllo e io ho conosciuto il mio
tutta la squadra di ops che esamina il problema
al contrario di oh sorpresa tutto è
fatto altre domande
è principalmente mirato alla ricerca
fallimenti ma nella tua esperienza hai fatto
imbattersi in corruzioni di dati
incongruenze introdotte di conseguenza
questa è una buona domanda che posso diventare appiccicosa
hai corrotto alcuni dati come parte di
un esperimento o nel mondo reale e
puoi essere difficile eseguirne il debug e
per farlo siamo stati davvero premuroso su
il potenziale impatto dei dati del
esperimenti che abbiamo corso tendiamo a farli a
confini del servizio su cose che sono
idempotente o cose che potrebbero gestire
Insuccesso nel mondo reale intendo il lancio
il lato è se a se un evento naturale
l’errore può causare il danneggiamento dei dati in
il tuo servizio è ancora un problema
avere a che fare con e se non lo sei
consapevole di ciò e tu non sai come
attenualo di cui potresti aver bisogno ma se
fai un esperimento che corrompe un
un sacco di dati e provoca un sacco di dolore
è simile a quel raggio di esplosione
dove non vuoi rompere
tutto e tu vuoi capire
l’ impatto ma ma dirò solo
questo è un caos di ingegneria
201 o 301 è un po ‘di più
avanzato vuoi fare il manuale
l’esplorazione poi si vuole automatizzare
poi vai dopo che i dati ci sono alcuni
soglia in termini di dimensioni del sistema o
dimensione della società quando ha senso al
ingegneria del caos, penso che tu pensi
sul costo del downtime ti aiuta
quantificare quanto sia importante per te se
si fa il costo del calcolo dei tempi di fermo
se un’interruzione sai se sei piccolo
start-up e poi vai giù e nessuno
nota poi forse è forse non lo è
è importante per te passare il tempo che sono
in realtà in quel mondo e se andiamo giù
non progettiamo per questo, ma per il nostro
i clienti non sarebbero felici che ci sia un
grande impatto su un marchio o sulla fiducia e così è
davvero una domanda di cui non so
valore Sono una persona di grande valore, se puoi
trascorri due ore e risparmia te stesso dieci
ore quindi passa due ore se puoi
passare due ore per risparmiare due ore forse
non ne vale la pena
più domande nell’ultimo dicono
stai usando l’ ingegneria del caos all’interno del tuo
propria compagnia assolutamente
noi cibo per cani o suo zio Jeff da
Amazon ha detto che beviamo il nostro champagne
noi falliamo regolarmente il venerdì
rompere il nostro servizio in realtà abbiamo bloggato
riguardo un paio di cose ne abbiamo avute alcune
quelli imbarazzanti all’inizio avevamo un disco
fill-up che ha causato un host che non era log
ruotarlo non stava pulendo quello
ha causato alcuni tempi di inattività
usiamo dynamodb indovina cosa succede quando
introduci la latenza come la tua chiave
archivio dati le cose possono andare rapidamente di lato
così ho ho pratica quello che predico in quel
riguardo bene grazie mille per tutto
il tuo tempo e per le tue domande, se tu
avere altre domande che siete i benvenuti
per venire a parlare con me in linea fuori della mia squadra
lì per una cabina prendi un adesivo
speriamo di vedervi nella comunità
o in occasione di eventi, ma se non altro ho
apprezzare il tuo tempo e attenzione
tu
Please follow and like us: