[Musica]
solo per iniziare con un po ‘di
gestione delle aspettative, voglio dire che c’è
alcuni altri grandi discorsi in giro e no io
non voglio liberarti di te
sicuramente non sono felice che tu sia tutto
qui voglio solo assicurarmi che tu
ottenere il massimo da esso e così giusto
brevemente parlando di quello che devi
aspettati nei prossimi 45 minuti che tu
posso decidere bene è quello che mi aspettavo
o è qualcos’altro e io piuttosto
vai e non ho intenzione di parlare così tu
non vedrò alcun codice qui e io no
parlerò molto del design
schemi e tutte quelle cose che ho avuto io
ha fatto altre presentazioni su questo
Sto parlando di oggi è quando ci provi
implementare un ingegnere resiliente
design del software resiliente nel tuo
compagnia quali sono le più tipiche
ostacoli che dovrai affrontare
e solo parzialmente sono correlati
davvero alle attività di progettazione o
implementando il codice la maggior parte delle sfide
affronterai al di fuori di ciò che è
sorprendente e non sorprendente al
nello stesso tempo è quello che sto per parlare
circa oggi così ho messo in bundle sette di questi
sfide fondamentalmente e discuteremo
ognuno di loro brevemente se ora senti
come bene non è esattamente quello che io
previsto
sentiti libero ora è la tua occasione va bene
detto questo è il più noioso
fai scorrere il codice bla bla bla bla bla
centric blah blah blah Devo menzionare
codice centrico perché altrimenti non lo faccio
pagato ma per il resto forse l’unico
cosa interessante giù c’è il
diapositiva Condividi link quindi è la mia SlideShare
conto che è possibile scaricare le diapositive
nel caso in cui sei interessato a loro
e sì, questo sarebbe abbastanza
e se avete un dubbio su questo
chiedimi e lasciami un messaggio a
Twitter o qualsiasi altra cosa va bene , iniziamo
con l’argomento era un piccolo software
design giusto che l’ hai raccolto
da qualche parte e tu dici sì, è fantastico
cosa ha molto senso andiamo
implementalo nella nostra azienda e vai
torna a casa alla tua macchina
coniglio e dì sì, devo ricominciare tutto
e naturalmente perché è così
ovvio che è necessario che ti aspetti
quello di essere un lavoro facile
così come stare seduti alla spiaggia con la brezza fresca
bevi nella tua mano musica soft e
tutto dovrebbe andare bene
Voglio dire, è così ovvio che ne abbiamo bisogno
ma in qualche modo wow è un vento freddo non a
brezza fresca e ci sono nuvole che arrivano
e che diavolo sta succedendo lì
ed è improvvisamente ti senti come nel
al centro di un temporale ancora con il tuo
bere nella tua mano scuote che diamine
stava succedendo, diamine no
parolacce oggi quindi cosa è andato storto e
non hai idea e bene non posso dire
esattamente cosa è andato storto nel tuo
situazione lì un sacco di cose che possono
andare male e ma cosa da quello che ho
appreso in circa dello scorso anno
implementazione di progetti software resilienti
ci sono molte cose che possono andare
sbagliato e abbastanza spesso saremo catturati
di sorpresa quando lo facciamo
perché sono le sfide che si presentano
dove non ci aspettiamo abbastanza spesso
e quello che ho raccolto qui in questo
la presentazione è di alcuni dei sette
tipiche insidie che io personalmente
con esperienza ora voglio condividerli
naturalmente con te le ho chiamate missioni
perché sfida questo di più
i gestori parlano e i suoni sono abbastanza
sembra più bello, non è così
continuiamo con le ricerche e io
inizia con la prima ricerca che è sì
capire il business case perché
Sì, agli ingegneri non ci piacciono gli affari
casi, non intendiamo davvero quello
cosa fanno le altre persone di solito e
sfortunatamente questo può ucciderci prima di noi
anche fare il primo passo e quindi dobbiamo
guarda brevemente quello che intendo tu vai
il tuo manager e dì sì, voglio farlo
progettazione del software di resilienza e poi il tuo
il manager torna con la domanda
bene , sembra un’idea interessante
voglio dire molto soldi ci guadagneremo con quello
e tu stai lì come wow e tu sei
morto prima ancora di fare il primo passo
Voglio dire, c’è una ragione per cui i manager chiedono
che si tratta di una sorta di cartina di tornasole
sono seri ma anche la loro risposta
assicurandoti che il tuo stipendio diventi
pagato alla fine del mese, così è
okay se stanno pensando a soldi tu
troverà anche questo in incognito se tu
vai al proprietario del tuo prodotto un prodotto
manager e tu dirai di sì
implementalo e chiedono lo farà
migliorare la nostra velocità che sta chiedendo
il caso aziendale sotto mentite spoglie
qualcosa di simile a ciò che è ancora una volta va bene
ma è la domanda sbagliata in questo
situazione e prepararsi per questo
devi capire che la resilienza non lo è
riguardo al fare soldi si tratta di non perdere
denaro che è completamente diverso
storia e quindi il ragionamento quindi se tu
mai ottenere è una discussione del genere
il ragionamento è qui è il mio suggerimento
come iniziare quella discussione se tu
non farlo, dovrai affrontare una riduzione
disponibilità del sistema e la ragione per
questo è il comportamento non deterministico
sistema distribuito non provarci mai
spiegare i sistemi distribuiti a qualcuno
fuori da RT è impossibile, quindi è così
l’unico posto in cui devi dire
credimi è così che è provato
c’è letteratura che puoi leggere
così almeno che gli effetti di quello e
questo accadrà parlerò che
in un minuto più in dettaglio e se il
il sistema non è disponibile, gli utenti non possono
fare ciò che intendono fare quale nel
prima da una parte hai un
subito perso entrate in modo da perdere
soldi perché non sono in grado di fare
qualunque cosa tu voglia fare qual è il
ovvio uno e l’altro è un
un po ‘più sottile ma a volte
ancora più scoraggiante i suoi utenti si annoiano
se ciò accade più e più volte e
lasceranno la vostra compagnia a cui rivolgersi
il tuo concorrente che il tasso di abbandono aumenta
nel discorso di marketing e così è
costo di entrate perse in ritardo e così via
ogni volta che hai una discussione su
business case un software resiliente
design
lui ha per lo più la trama che non posso
ti garantisco di convincere il tuo
manager è ancora molta discussione
e sapendo come parlare con loro e così
su e forse stanno solo dritta e
dì pure che è tutto molto carino
il momento di un problema diverso e
speriamo che tutto andrà bene
così e così questa strategia di struzzo e così
ma è una storia diversa almeno
hai fatto del tuo meglio e spero che sia il
la moglie è il primo passo per quello che è
il tuo budget di resilienza come questi numeri
puoi farlo con il numero prendi il tuo
monitoraggio aziendale non ce l’hai
implementato sì di solito la maggior parte delle aziende
non avere un monitoraggio aziendale
implementato che puoi ragionare facilmente
guarda i numeri delle entrate e cose simili
che se non si dispone di che iniziano con
alcune stime prudenti e provare a
ottenere il buy-in dall’altro lato mi
significa tutte le discussioni sui casi aziendali
Ho visto che non sono mai stati decisi qui
sono stati sempre decisi i loro affari
il business case che ho deciso nell’intestino
alla fine quindi questa cosa di cui abbiamo bisogno
che è una cosa strana per la nostra
ingegneri del software perché di solito
prova a decidere con il nostro cervello ma
di solito tutte queste decisioni sono prese da
l’intestino così pretende di rivolgersi al cervello
il cervello ma in realtà indirizzato a Dio
quindi cerca di ottenere la coppia e trova il
numeri in cui dicono che sì bene
ha senso per me uh sì no, lo siamo
parlando bene
abbastanza su quello che era dopo
il tuo primo passo e potresti affrontare il tuo
seconda ricerca e questo è distribuito
sistemi dal modo in cui è uno dei
le missioni più difficili quindi tutto te
fondamentalmente bisogno di sapere su distribuito
sistemi in poche parole
Virna per Bitcoin riassunto in uno in
una frase che è quella che sei tu
bisogno di sapere sui sistemi distribuiti
fondamentalmente II ed è molto, molto difficile
far fronte a quello così da quello che ho visto
e l’idea era di simulare sistemi per
25 anni e penso di iniziare
capirli a metà strada così è davvero
difficile da afferrare davvero e ottenere questi
idee nel cervello e rispondere a questo
e da quello che ho visto più del 99% di
tutto il personale IT non lo ha capito
davvero così pensano di fare per il
ciambella perché
non lo capiscono davvero e
perché non lo sono così spesso?
affrontando il sistema più stupido nel
in realtà nel modo sbagliato penso che debba
fai molto con la nostra educazione e @he e
il modo in cui il nostro cervello è cablato sì, quello che io
significa con quello che abbiamo imparato ora IKEA
ucation
in pratica è come se fosse X allora
Y comportamento deterministico se faccio questo
questo avverrà periodo garantito al 100%
e tutto ciò che apprendiamo in IT e
tutto ciò che costruisci è costruito sopra
di quel comportamento deterministico così è
quello che chiamo dentro il processo pensa tutto
la nostra educazione ITT è basata su questo
ragionamento sul deterministico
comportamento è complicato
sistema la cosa buona è che il nostro cervello è
cablato in quel modo in modo che possiamo facilmente ragionare
a questo proposito è bello ragionare
pascoli deterministici questo sarà
la garanzia è garantita il problema
era un sistema realistico è un po ‘
un po ‘diverso se X poi forse Y così
questa è una probabilità qui e noi tutti
odio una statistica non ce l’abbiamo fatta eccezione
le persone che apprendono a macchina ma io no
certo se a loro piacciono davvero le statistiche o
i laser fingono di avere statistiche da ottenere
sbarazzarsi di noi non l’ho mai capito ma
Beh, è così difficile da ottenere la testa
avvolto intorno a questo e questo in realtà
termini di design che cambiano tutto
quindi questo è un processo trasversale che pensa come
Lo chiamo e questo non è deterministico
comportamento perché quello è probabilità
e spesso succede ma qualcosa
non ha sempre solo parzialmente
succede o è terribile e devi
ragionare su questo e cerca di ottenere un
design giusto che lo tenga in considerazione
e il nostro cervello non è collegato per quello
siamo veramente poveri a quel II ancora
perché usiamo troppo per pensare
in questo modo usiamo il lato sinistro del pensiero
design per progettare o risolvere problemi su
il lato destro e il pozzo che porta a
effetti strani
Va bene, quindi quello che vedo è così tranquillo
effetti strani e vediamo che tutto il
tempo perché quando attraversiamo il
storia del sistema distribuito e
le strutture del sistema fognario DCE cob nostro
SOA EJB decom e tutte quelle cose sempre
sono stati progettati in un modo che dice bene sì
c’è un sistema distribuito là fuori
ma lo copriremo dietro le interfacce
e puoi e puoi pensare al
sistemi nel modo in cui e là
sempre portato a sistemi fragili che non abbiamo fatto
scala e tutto come quell’uomo
produzione di catastrofi così così nel
piccola scala, sì, ha funzionato
la scala più grande e non ha mai funzionato
perché hai sistemi distribuiti
modalità di errore che non vedi in
sistemi locali questi sono i fallimenti
le modalità quindi non rispondono affatto
a volte rispondere a qualcosa non lo fa
Rispondere rispondere lento l’arco nemico di
sistemi distribuiti latenza davvero difficile
ti dà la risposta sbagliata pensa
consistenza finale e tutto il resto
ordini di roba e tutte quelle cose a
ordinamento e presentatore di messaggi e
fallimento quindi sì, il sistema è tornato indietro così
non hai idea di cosa verrà dopo e
così via e questo porta a molti effetti
un sacco di carte ci sono nel computer
scienza che spesso cerchiamo di ignorare
che esistono perché è davvero difficile
accettare tutte quelle cose che tutte le cose
che sono no-brainers in un sistema locale
un sacco di cose che non hanno cervello a
sistema locale che diamo per scontato
diventare davvero difficile o addirittura impossibile in
sistemi distribuiti intendo uno dei miei
i documenti preferiti qui sono di un
Sfidato vede anche la L nel FLP
risultato impossibile se hai mai sentito
su quello che è lei e anche lei
a prova di ciò il teorema del cappuccio in realtà è così
stava solo sentendo da Brewer e il
le insuline lo dimostrarono quattro anni dopo
che è vero e ha portato un foglio a
cento prove di impossibilità per
distribuito il calcolo di un centinaio di cose
non ci sono brainers nei sistemi locali
che non funzionano in sistemi distribuiti
e dobbiamo davvero cogliere queste idee
prendili e accettali
e trattare con loro così la mia raccomandazione
è abbracciare questo tipo di pensiero questo
tipo di pensiero non garantisce solo
promette verosimiglianze e tutta quella roba
quindi questo non determina il comportamento istic
per quanto riguarda la completezza dell’esecuzione
quindi se mai avrai una risposta quando tu
ottenere una risposta se si ottiene un parziale
risposta o distorto arciere tutto questo
le cose stanno per accadere è il
messaggio resistente che ordina molto
importante quindi sì, prima di ottenere il
soldi i soldi sono ritirati hmm è il tuo
sistema in grado di gestire questa situazione
perché solo un ordine di messaggio è stato capovolto
e tutti questi tipi di situazioni e
la comunicazione è la tempistica che pensavo
già parliamo di latenza in tutti questi
modalità di fallimento, ma per essere onesti non lo farai
essere in grado di prepararsi a tutto ciò
il tuo design farà solo il tuo cervello
esplodere e questo è terribile da parte tua
guardare a esplorare il cervello così tu
solo dover accettare ti colpirà a
il livello di applicazione a un certo
laurea e non aspettarti il tuo
infrastruttura per nascondere tutti questi effetti
da te ci sono pezzi decenti di
infrastrutture là fuori che ti aiutano
per ottenerlo un po ‘più facile, anche se
si utilizza uno STO o qualcosa di simile
ma la vecchia infrastruttura non può che dare
una sorta di risposta generica
comportamento a determinate situazioni ma il
le applicazioni a volte significano questo tipo
di comportamento ea volte questo comportamento
quindi ancora ti influenzerà nel
livello di applicazione che devi affrontare
quello e il minimo che dovresti fare è avere
un piano per rilevare se qualcosa è andato storto
e riprenditi da quello , se vuoi
capire dopo otto settimane oops my
database è andato incoerente perché io
mancata modalità fallimento ha un piano come
riportare il database in a
modalità coerente che è il minimo di te
dovrebbe farlo a volte salva davvero
la tua schiena bassa in produzione ma come me
ha detto che è un sistema distribuito difficile
sono difficili sono davvero difficili, intendo
Io da quello che ho visto in 35 anni di
e sono solo due campi rigidi nell’IT
e l’altro è sicurezza nell’altro
è un sistema distribuito tutto il resto
rispetto a quello è noccioline da cosa
Ho imparato e questo è già abbastanza
cose difficili al di fuori della sicurezza in
sistemi distribuiti ma sono davvero
difficile ma ok forse troppo difficile per il
momento per sopravvivere, facciamo quella ricerca
lascia questa ricerca da parte, sì, sì, arriviamo
torna subito dopo, ma forse il solutore è più facile
ricerca per primo che è il 100% disponibile
trappola vediamo che tutto il tempo sì peggio
uno del 100% attende una trappola, quindi è così
relativo ai sistemi distribuiti
principi ma è la versione più piccola
la ricerca più facile quindi qui vai a
responsabile del prodotto o
chiunque e dite bene come dovrebbe
che come risposta rispondere se a
fallimento tecnico se questo tipo di
Il fallimento di Technol succederà se io
non posso raggiungere il mio database se qualcosa è fuori
lì se l’altro sistema è giù se io
non ottenere la risposta giusta in tempo e
tutta quella roba e poi il business
il proprietario torna da te e dì sì
bene questo non deve accadere è tuo
responsabilità di assicurarsi che questo
non accadrà mai bene, sì, per cui sei caduto
la trappola disponibile al 100% ma non lo è
solo il lato business come anche l’IT
gente questa è una situazione da una realtà
progetto in cui sono stato e dove sono
rivedi un po ‘ il design e
poi ho trovato un servizio rivolto al cliente
parlando con un servizio non rivolto ai clienti
ora basta chiedere loro di sviluppare per noi così sì
bene come gestisci quella situazione se
quel servizio clienti che deve affrontare il servizio
è giù e come rispondi a questo
da quel cliente che affronta così perché tu
voglio dare e rispondere al
cliente così o se è abbastanza tardi
roba del genere e poi bene prima
sviluppare il nostro detto no che non abbiamo implementato
qualsiasi cosa in più perché quel non cliente
affrontare la porzione è così importante se è così
giù così com’è così importante e
quindi deve sempre essere al 100%
trappola disponibile questa ipotesi che
tutto al di fuori del tuo
l’area di implementazione è sempre lì
che l’intero ambiente è sempre attivo
e sviluppare il nostro per modificare in realtà sì
beh, se quel servizio non funziona, non lo siamo
in grado di dare una risposta comunque utile
quindi sì, non ci importava, quindi abbiamo bisogno di questo
di essere all’altezza perché altrimenti non siamo
in grado di fare qualsiasi cosa dal modo in cui vengo
di nuovo a quello con la ricerca numero cinque
perché questo è un altro problema ma solo a
assicurati di capire se hai chiesto se
il fallimento accadrà è sbagliato
domanda la domanda giusta è solo per
chiedi quando accadrà un errore
tutto ciò che ti circonda ha disponibilità
disponibilità inferiore a quella che fa
il che significa che non è la domanda se
accadrà se falliranno loro
fallirà garantita l’unica domanda
è quando e solitamente questo è il tuo
venerdì nero personale in compagnia
quando guadagni i soldi della tua vita e
quando tutti i clienti stanno comprando come
l’inferno che di solito quando ti succede
può decidere di gestirlo in anticipo o
quindi mi raccomando di gestirlo in anticipo
a proposito e solo per capire a
un po ‘ meglio soprattutto nei giorni
di micro servizi e tutto ciò che è
la cosa bella ma ha un prezzo
come tutte le cose presuppongono che uno dei tuoi
i tuoi servizi hanno abbastanza tempo per
99,5 per cento compresi i tempi di fermo impianto
in un centro dati on-premise nessuno
ti dà un tale numero nel loro SaaS
Sì, alcuni sviluppatori host e dicono di sì
ti diamo novantanove virgola sette sau
bene mentre stai facendo soldi extra
verso la nostra app e sono a partire dalle 7:00
al mattino alle 8:00 di sera
si, quindi la tua disponibilità in realtà
è del 55% bene è facile da garantire
novantanove virgola sette se ne hai uno
finestra di manutenzione di undici ore ma
va bene e se dieci server sono deformati e
data una risposta a richieste esterne
tutta la disponibilità è ridotta al 95% e se
50 servizi sono coinvolti sei giù a
circa il 75% quindi ogni transazione forzata
la media fallirà quindi la disponibilità al 100%
di tutto ciò che circonda non iniziare
che o altrimenti sarà colpito da
questi numeri ma di nuovo è più facile
comunicare molto più facilmente per sopravvivere
ricerca quindi la ricerca del sistema torretta ma
okay , gestiamo quello in cui siamo sopravvissuti a
caso d’affari, sì, abbiamo avuto a che fare con
i sistemi a torretta e il 100%
trappola disponibile per il prossimo
cosa che siamo corno per i ops è
il loro ciclo di feedback I ho deliberatamente
non ha scritto DevOps perché quel termine
sfortunato rotto irreparabilmente
perché andare in una stanza con dieci persone
si ottiene una quindicina di opinioni che cosa
Di solito non diciotto di loro hanno torto
e così bene, quindi l’ho trasformato
Intorno a cosa intendo con quello che tu
vedo ancora molte aziende è così grande
così a volte la guerra tra la morte e le operazioni
fino alla gestione del livello del mare o
qualcosa del genere non ti è permesso
parlare, ma anche attraverso il muro
se c’è la finestra non ti è permesso di
aprire quella comunicazione dovrebbe andare come
va bene se hai un candy bar
qualcosa del genere potresti aprire il
finestra e attenersi alla scivolata che è vero
e così via non non non sono in
modo ufficiale sì e questa divisione di
approccio lavorativo che vediamo lì che ha
Si ha qualche bene se solo tu
pensare efficienza dei costi, ma si tratta
ad un prezzo
di nuovo e il prezzo lo farai soprattutto
vedere in questo dominio se è davvero necessario
vai veloce se hai davvero bisogno di creare
sistema di sistema distribuito che tu
di solito hanno questi giorni il problema è
il super ambiente yeah bene te
non può gestire la disponibilità solo su
livello di infrastruttura intendo in passato
sono stati gli sviluppatori a cui tieni al nuovo
personale
oops ti preoccupi di assicurarti che
tutto è attivo e funzionante e per tanto tempo
poiché il sistema funziona solo localmente e
non ha alcuna connessione con il
all’esterno tranne per connessioni batch
va bene così, perché allora il vostro singolo
il problema più importante è se il
l’infrastruttura è ancora viva se la tua
il server è attivo se il tuo raccolto non lo è
rotto e così via e tu te ne importa qualcosa
su tutte quelle cose solo su
livello di infrastruttura , ma come ho detto
prima in un panorama di sistema distribuito
tutti questi effetti ti colpiranno al
livello di applicazione questo non deterministico
comportamento dei sistemi distribuiti e così via
è necessario affrontare con che almeno
parzialmente sul livello di sviluppo
il livello di applicazione e così di solito
quello che stai cercando di fare è provare a
implementare un ciclo di miglioramento continuo
che è come abbiamo alcuni problemi che
abbiamo visto qui in ops con il tuo
applicazione oh caro non ho qui è a
ecco una figura e tu sai bene si
oh questo è interessante, non ho pensato
su quello sì, andiamo
attuare un qualche tipo di risposta a questo
una sorta di design elastico nel nostro
applicazione ed ecco cosa ho costruito per
renderlo migliore e poi lo eseguono e
ti restituiscono bene i numeri
ho lavorato solo parzialmente oh, mi sono perso
quella parte miglioriamo quella e così
ed è un miglioramento continuo
ciclo il problema con il muro è
ciclo ovvio è rotto Intendo sì, noi
implementare le misure ed ecco dove
hanno effetto comunque puoi vedere come
beh, hanno funzionato, il muro è nel mezzo
nessun ciclo di feedback è rotto quindi sì e
anche peggio, anche se lo sei davvero
ingegnere software motivato che tu
ovviamente stai sparando al
buio
non hai idea se le cose che tu
appena implementato funziona o no perché
non si ottiene il feedback in modo sostanziale
l’osservazione chiave qui è se tu
vuole davvero implementare resiliente
progettazione del software e la vostra azienda voi
necessità di avere un ciclo di feedback funzionante
altrimenti non è necessario iniziare
Voglio dire che è bello se si implementa a
interruttore qui o là o
qualcosa di simile
o qualche gestione di timeout o alcuni
cache e così via ma non lo farai mai
capire se aveva senso o lo era
solo complessità aggiuntiva nel codice
di cui a nessuno importa
a proposito, è abbastanza demotivante
e se poi sei anche solo
incentivato per il completamento di più
caratteristiche per unità di tempo perché hai
per migliorare la tua velocità perché lo sei
agile dal modo in cui non deve fare
qualsiasi cosa con un Gillette è solo un costo
efficienza nel travestimento che fa
qualcosa di diverso allora si, bene e
lo fermerà abbastanza presto
così unitivo ha stabilito un ciclo di feedback
fondamentalmente DevOps DevOps è una cosa interessante
ma ancora una volta i veri DevOps reali sono enormi
cosa così andrà nel
organizzazione nei processi nel
il modo in cui crei software fornisce software
il modo in cui progetti tutto il software
che interesserà tutto il modo in cui si
operare tale fine e fine e quindi
a volte è un po ‘troppo
da alcune organizzazioni in modo che preferisco
piace adottare le idee da Google il
idee di ingegneria dell’affidabilità del sito che
è un po ‘ più piccolo con questo per
causa del bilanciamento della velocità di innovazione
rispetto alla disponibilità di produzione
robustezza che è una cosa carina o se
hai un modo migliore per implementarlo
in questo modo, ma implementare quel feedback
ciclo okay
controllo del ciclo di feedback implementato così dopo
la ricerca numero cinque che è di nuovo
scoraggiante un design funzionale padronanza
Intendo, sì, stiamo discutendo di questo
argomento per più di 450 anni e noi
ancora sono davvero cattivi, non siamo noi
e nello stupido sistema da sparpagliare
twist extra il mio reclamo è senza un vero e proprio
design funzionale nient’altro conta
così
puoi implementare la migliore capacità di recupero
misure che siete a conoscenza del sul
livello tecnico se il design funzionale
non va bene finirai con a
fragile sistema di paesaggio che lo farà
essere sempre un po ‘squilibrato e così via
e non scalerà bene e tutto il resto
roba perché è sì, se ci pensiamo
il software di resilienza progetta l’idea centrale
le versioni di dimissioni sono l’isolamento
l’isolamento significa fondamentalmente il sistema deve
non mancherà nel suo complesso e per assicurarsi
che non fallisca nel suo complesso divido
in parti e io isolare queste parti
contro l’altro che un fallimento qui
non precipita in altre parti del
sistema e in questo modo creo di più
sistema robusto quindi anche se un parkour
cade giù gli altri sono ancora
vivo tutti dicono che sì fa un
molto senso, sì , facciamolo
e il modello di cappello nero è quindi di solito
quello che vedi per implementarlo e sì
ma l’ultima riga qui è un po ‘
strano giù dicendo quello che stai dicendo
quello che modella le teste di una bella corteccia per quello che è
estremamente difficile voglio dire che potresti dire bene
Lo faccio sempre
Voglio dire che sto tagliando e tagliando
funzionalità sempre nei metodi in
classi attraverso metodi attraverso classi
attraverso i moduli attraverso i servizi o
qualunque pacchetto e così via, quindi perché
dovrebbe essere difficile dirò bene come si fa
tu eviti questa situazione supponiamo che io
indovina una richiesta esterna che colpisce
servizio a e servizio a per adempiere a questo
richiesta richiede una risposta per il servizio B
questo è ciò che questa risposta dall’altra
sviluppatore dal secondo sviluppatore e
la terza missione era così ho bisogno del servizio B
essere disponibile per completare la mia richiesta
e restituire una risposta che hai visto
che non hai si, bene, non sono così
e a causa del modo in cui la funzionalità è
distribuito tra questi due servizi
l’isolamento è rotto di default perché
puoi averne un milione di circuiti
interruttori qui
se questo è giù interruttori automatici
ti dirò solo che sei morto male
fortuna
quindi l’isolamento è rotto bene come stai
evita che quello qui sia un esterno
richiesta con qualche tipo di funzionalità
wow non è più un micro-servizio
piuttosto un servizio macro o anche peggio
perché c’è un sacco di funzionalità
lì dentro dividiamo un po ‘questo
un po ‘e sono ancora un po’
grande quindi cerchiamo di scissione che più in alto e
così via e sì sì sì , è un po ‘strano
d’ accordo e all’improvviso lo trovi
te stesso con un’attivazione piuttosto lunga
percorso così un sacco di richieste interne voi
bisogno e ti ricordi questa disponibilità
cosa che ti ho appena mostrato
quindi la disponibilità scende con
numero di servizi coinvolti
sì, un comportamento sincrono in alcuni
le situazioni vanno bene, ma solo se non lo fai
devo fare una risposta online così
storia diversa, quindi vedi tutto molto
spesso e poi tu lotti con quello
roba in produzione e dite bene
non funziona così bene, quindi andiamo
di nuovo a quello e sì dividendo
funzionalità in diversi pezzi a
implementare bene l’isolamento è rotto
quello che dici ora nananana non è così facile
rallentare quindi applichiamo il nostro
pratiche ben note abbiamo imparato come
facciamo che prendiamo l’ informatica 101
qui dividiamo e conquistiamo il funzionale
decomposizione sappiamo come farlo o
siamo tutti i mestieri artigiani artigiani
donna quindi applichiamo asciutto non ripetere
te lo abbiamo imparato per molti anni
abbiamo fatto tanti rifugi in cui ci siamo ritirati
addestrato che roba siamo davvero grandi
a quello che è designer cool o siamo noi
Piuttosto più come un architetto, quindi usiamo
più termini di fantasia come architetti oh sì
desideriamo una fruibilità è un santo
graal in architettura lo sai e tutto
sono design che è un altro santo
Graal per gli ultimi 20 anni o qualcosa del genere
così o potresti dire no no I am
Più intelligente di così applico qualcosa del genere
progettazione basata su test o qualcosa di simile
architettura emergente e così
e dire che stai bene, questi sono fantastici
tecniche in un certo contesto ma in
Alla fine applichi implicitamente ciò che tu
conosci esplicitamente così non finirai
un design completamente diverso è solo
una procedura diversa come veniamo lì
ma userete di nuovo le stesse idee
il problema con tutte queste idee è questo
è progettato per la riutilizzabilità e asciutto
questo è un servizio riutilizzabile e
riusabilità pur avendo molto valore
in questo contesto mostra la sua brutta testa e
il lato brutto della riusabilità è quello
è l’accoppiamento più stretto possibile così
questi sono totalmente accoppiati questi due
servizi non appena questo è giù questo
uno se n’è andato e naturalmente è così
design funzionale del livello di decomposizione
e sì, mentre cercavi di aggiustare il
manca coesione qui finiamo con
che spesso di nuovo e benvenuto a
salute distribuita tutto ciò che apprendiamo
sul design di solito in educazione IT e
nella nostra pratica è grande dentro a
limite del processo ma attraverso il processo
confini con quello non deterministico
il comportamento dei sistemi distribuiti no
aiutaci un po ‘e poi dì sì, io
hanno ancora delle cache che risolveranno
tutto così sì, basta implementare a
cache in qui e se è giù posso
ottengono ancora la loro risposta dal cache
e questa non è una cattiva idea in sostanza, ma
anche le cache hanno un prezzo così buono
il punto è che se non lo fai
cura del tuo design funzionale e
prova a sistemare ogni cosa con schizzi
finirà con un sacco di cache infernali
e devi riempire questo caso che hai
per trasferire i dati che devi rispondere
al fatto che saranno più stantii
del tempo in modo che essi saranno
obsoleto, dovrai affrontare diversi tipi di
incongruenze che devi affrontare
con e così via in modo da finire semplicemente
in un diverso tipo di inferno se tu
basta affidarsi alle cache di nuovo ci sono le cache
bella cosa in alcuni posti ma loro
non sono il cerotto per una rottura
design funzionale quindi fondamentalmente mio
imparando finora è necessario reimparare
come fare il design giusto per distribuito
sistemi e abbiamo solo 45 minuti
qui ho alcune idee che potrebbero essere
completamente fuori dal campo di applicazione
sessione se sei interessato ad alcuni di
le idee che ho tenuto a parlare a Kandinsky a
poche settimane fa qua e là è
registrazione che verrà poi rilasciata
e così Kandinsky 2018 e loro lo sono
discusso alcune delle idee e il
risultati che ho su quell’argomento
l’unica cosa che la parola breve non è argento
proiettili ancora esauriti quindi è tutto
sarà un argomento difficile ma dobbiamo
concentrarsi su come ottenere il funzionale
design giusto perché altrimenti sì noi
abbiamo qualche tipo di problemi nel fare
questi sistemi robusti in realtà non lo faremo
essere in grado di renderli robusti se il
il design funzionale è sbagliato, okay
un altro scoraggiante , quindi cerchiamo
un’altra più facile, così siamo sopravvissuti tutti
in questi passaggi, supponiamo che anche noi
era sopravvissuto per lo più a quello funzionale
design e ora sì , finalmente siamo
permesso di implementare il codice che è bello
non intendo tutte queste cose fino a
finalmente ci è permesso di toccare davvero
la tastiera
e poi arrivano i modelli brasiliani
giocare e c’è anche qualche pericolo
coinvolto che ho visto così davvero
comprendendo la tua cassetta degli attrezzi intendo questo
è un’immagine del modello di resilienza che
Io uso nei miei seminari a volte ed è così
mancano modelli incompleti e anti
e roba molto più piccola e così via, ma
vedi che c’è molto da queste parti così
quali scegliere e quanti di loro
e come combinarli e così via io
ha iniziato a lavorare su un linguaggio di pattern
ma come i giorni purtroppo ne hanno solo 24
ore e ho un sacco di altre cose
per farlo è ancora work-in-progress o no
soluzione dal mio lato e non ho visto
tutto fuori ancora e sì è abbastanza
travolgente e ha qualcosa di strano
effetti a volte se vedi persone
raccogliendo quella roba così qui alcuni
raccomandazioni sull’utilizzo di questi
i modelli prima di tutto i più importanti
cosa dal mio punto di vista è modelli
sono opzioni non obbligazioni che non
bisogno di un modello solo perché lo sai
sanno che voglio dire si potrebbe a volte
ho visto questi programmi da persone che
ho appena imparato un linguaggio di programmazione
che ha cercato di implementare ogni funzionalità di
la lingua in quell’unico programma
succhiato non hanno questi programmi che vedo
quello che Perl è un tocco in più
perché in Perl puoi scrivere completamente
era di nuovo negli anni ’90 e tu puoi scrivere
case completamente reddito comprensibili
programmi programmi che l’autore
l’autore non capisce più
ora o dopo che l’ha scritto o lei lo ha scritto
Ne ho visti alcuni e anche in altri
lingue ha lo stesso modo se si mette
troppo in quello diventa duro e
è ancora peggio qui perché ciascuno
il modello che implementa aumenta il
complessità del tuo sistema e complessità
è il nemico della robustezza quindi se tu
voglio davvero creare qualcosa di solido
deve essere semplice in qualche modo deve essere
facile da capire facile da ragionare
circa e tutto ciò
dobbiamo trovare un punto d’incontro tra noi
bisogno di alcuni modelli ma ogni modello
aumenta la complessità, quindi dobbiamo
bilancia che così nessun modello è una cattiva idea
tutti i modelli sono migliori o così noi
devi bilanciare attentamente questo e anche
costa denaro ogni modello costa denaro
in dev e ops di solito spesso
licenziamenti coinvolti in questi modelli
il che significa hardware aggiuntivo in esecuzione a
tempo di esecuzione e così via e abbiamo un limite
budget come abbiamo visto così alla fine tu
prova a trovare un insieme di complementari
schemi che ne affrontano alcuni
situazioni di solito solo per darti un
breve idea di come altre persone l’hanno fatto
qui Erlang fondamentalmente stanno lavorando
con modello attore e messaggistica e cosa
usano è usato per avere questo
modello di scontro guidato che il
combinazione di escalation del monitor
riavvio è cosa supervisore lavoratore che
trovi anche nella biblioteca di Accra che
fondamentalmente la reimplementazione della tua
principi in JVM è così
ha iniziato il pony yonas era solo un po ‘
infelice che il suo datore di lavoro in quel momento
non gli ha permesso di usare Erlang e così via
si, se non posso usare il nostro Langdon
re-implementarlo
questo è per eka fondamentalmente iniziato e
hanno un cuore che batte per vedere attraverso
tutte le nostre macchine virtuali, se lo sono
ancora vivo e hanno diplomi caldi
che è abbastanza bello che ovviamente tu
non sapere i tempi morti se ti schieri
il tuo codice e questo è fondamentalmente così
questi sono i modelli che hanno implementato
e sono stati in grado di implementare su urlan
gli interruttori di telefonia era una disponibilità
di nove nove novantanove virgola nove
sette nove percento quindi pochi tempi di fermo
millisecondi all’anno contro voi pochi
modelli alla base quindi non è necessario
venti o cinquanta o se andiamo a Netflix
per esempio hanno un servizio basato
i progettisti richiedono una risposta in base a HTTP
in realtà la maggior parte del tempo e a causa del
richiesta di risposta hanno bisogno di più genitori
per capire se ottengono la latenza così
hanno tempo tutti gli interruttori automatici e
riprova la logica che possiedi
usando alcune cose del genere e ricadendo
è tutto cotto nella biblioteca storica
che potresti aver visto e poi tu
hanno anche ridondanza di più volte
soprattutto per il ridimensionamento in modo da caricare
condividendo hanno un pony molto decente
touring hanno zero dispiegamenti loro
non hanno persone braccia caldo perché
c’è JVM la maggior parte della maggior parte delle loro cose
ma l’ azienda conserviera rilascia a
implementali e loro hanno il famoso
esercito simian attraverso l’iniezione di errori
renderlo sostenibile in questi giorni tendiamo
chiamare quell’ingegneria del caos ma
questa è fondamentalmente l’idea che sta dietro
e così anche alcuni altri modelli a
caso d’uso diverso ma anche abbastanza
roba limitata e bene hanno un
tempo di operatività decente non loro
quindi sono abbastanza affidabili, specialmente se
hai preso in considerazione che è
a volte hanno circa trenta un terzo
del traffico completo a valle di
gli Stati Uniti all’interno degli Stati Uniti, quindi sono abbastanza
sono in esecuzione su oltre 100.000
macchine nelle ore di punta e poi il
la disponibilità è abbastanza impressionante, penso
ok ora abbiamo implementato tutto questo noi
supporta tutte queste missioni qual è il
l’ultimo uno sta conservando cosa
abbiamo appena imparato e questo è un comune
modello che non è specifico di
progettazione del software di resilienza che per lo più
mi preoccupa in tutto il nostro insieme
dominio intendo quello che vedo fondamentalmente io
proverei a trasformarlo nel flauto
lezione costante in questi cinque anni e
questa è la mia osservazione personale che vedo
discussioni ogni cinque anni
alcuni argomenti partono da zero come se
non c’erano discussioni precedenti
lì penso che l’anno scorso ho curato
davvero bella la non-conferenza ma ho deciso
quindi solo per ascoltare che spesso è un
buona idea dal modo ma a volte può
essere devastato ho detto bene quali sono
parlando di stanno parlando c’è un
sessione sulla riusabilità, siediti
Là
e ascolta che forse c’è
qualcosa di interessante che posso imparare
e mi sono seduto lì e ho ascoltato per loro
cinque minuti a dieci minuti e ho detto
cosa sta succedendo qui che sembra
1968 67 qualcosa di simile
quindi niente se nessuno mai avrebbe avuto
ha detto qualcosa sulla riusabilità
completamente da zero no no
conoscenza no conoscenza precedente niente di niente
Voglio dire tutto ciò che devi sapere
riutilizzabilità è stato fissato nel 1970 solo
leggi il catrame di Fred Brooks
ci sono due pagine e in fondo puoi
ottieni tutto ciò che devi sapere
riusabilità in questo singolo documento
singolo saggio e ce ne sono alcuni altri
le cose lì intorno niente e
cosa sta succedendo lì e non ne sono sicuro
Non sono perfetto, ma penso che parte
la storia è il modo in cui creiamo intuizioni
e come ci comportiamo così normalmente
nel tempo in cui lavoriamo, cresciamo le nostre conoscenze
significa sì, conosciamo anche le persone che lo sono
così o forse anche così ma
supponiamo che la maggior parte di noi lo sia
imparare costantemente cose nuove tutto il
tempo c’è una differenza ma come il
differenza tra approfondimenti quindi conoscenza
quello è oh sì, sono la prova di
tempo e questo richiede un po ‘più tempo perché
ti ci vuole un po ‘di tempo prima che tu veda
alcuni schemi ripetuti e così via e
dì sì, questo ha molto senso
per tenerlo a mente e questo sì
meglio dimenticare quella roba e così via e
quindi questo cresce su un tasso diverso e
questo in realtà non è niente di speciale per l’IT
è qualcosa che vediamo in tutto
industrie ma soprattutto in IT che abbiamo
un modo molto specifico per gestirlo
altre industrie se qualcuno è abbastanza
nuovo nel dominio e ha un problema a
nuovo problema quindi cosa tendono a fare
cercano di guardare nel corpo di
la conoscenza che esiste per quello
disciplina ingegneristica o qualsiasi altra cosa
disciplina è che abbiamo un diverso
strategia cerchiamo sempre il prossimo
pallottola d’argento
all’orizzonte ho avuto un problema
qui forse ci sono alcuni Savala
microservizio Kafka resiliente sicuro s
qualunque soluzione là fuori che posso
adottare si potrebbe mai cercare una lampada
impilare anche se risolverebbe perfettamente
il tuo problema
no no, quella è roba vecchia che è quella che deve essere
beh, certo , no , è vecchio
schema non possiamo usare quello che intendo di nuovo
ci sono molte cose che non voglio
ricorda più che sono felice di poterlo fare
lascialo alle spalle, ma c’è anche molto
di un bel po ‘di saggezza senza tempo nel nostro
dominio che tendiamo anche a dimenticare con
questo tipo di uso di loro così abbiamo anche
questo tipo di tecnologia usa ‘m che è
molto in pratica quello che ho visto è noi
dobbiamo riscoprire le nostre intuizioni ogni
5 anni intendo che c’è una ragione per cui
Martin Fowler ha scritto una nuova versione del suo
refactoring di libri e iniziato fondamentalmente
da zero perché nessuno davvero
ci sono così tante persone che non lo fanno
ricorda che il vecchio libro sì loro
è iniziato con JavaScript, quindi lo faranno
mai letto che altri libri, quindi facciamolo
scrivi un’edizione JavaScript con questo sì
quindi tutti per usarlo in un modo diverso noi
festeggiamo noi stessi per dimenticare
tutto ciò che abbiamo imparato, aspetta
un po ‘difficile e il mio problema con
quello che mi preoccupa è che non sono sicuro se
inquietante come possiamo davvero migliorare
con quello di cui non ho un’idea perfetta
quella o nessuna soluzione se ne hai una buona
idea per favore condividilo perché il mio
impressione è che non stiamo andando a
diventare una disciplina ingegneristica e
vera disciplina ingegneristica e chi noi
ho risolto questo problema ed è anche un
rilevante per la progettazione del software resiliente
perché tutto ciò di cui ho parlato e
tutto ciò che so della resilienza
di questo non è nulla di nuovo, qualcosa del genere
roba è già lì da 40 anni o
più a lungo quindi lo dimentichiamo e
ancora e ancora avvolgendo sette
missioni che potresti incontrare nel tuo
società se si tenta di attuare tale
cose
sono difficili da fare e il
la cosa interessante è la maggior parte di quelli sono
solo in modo interattivo correlato a resiliente
software progettato per fare quel design
e parte di implementazione che è
sorprendente e non sorprendente al
allo stesso tempo perché è spesso figura
dopo un po ‘ci sono nuove idee
nuovi concetti il più difficile
probabilmente raccogliendo sistemi distribuiti
ma questo è un sacco di tempo e il prossimo
il più difficile è probabilmente quello di padroneggiare il
design funzionale dove come dominio noi
sono ancora abbastanza cattivi e distribuiti
sistemi come ho detto aggiungono un tocco in più per
quello solo il pannello è abbastanza facile e
noi sì è la domanda che non posso
rispondere in realtà bene è quello che ho avuto
per te e così prima di tutto molto
per il tuo tempo e ora sono pronto per
rispondere alle domande
[Applausi]
solo per iniziare con un po ‘di
gestione delle aspettative, voglio dire che c’è
alcuni altri grandi discorsi in giro e no io
non voglio liberarti di te
sicuramente non sono felice che tu sia tutto
qui voglio solo assicurarmi che tu
ottenere il massimo da esso e così giusto
brevemente parlando di quello che devi
aspettati nei prossimi 45 minuti che tu
posso decidere bene è quello che mi aspettavo
o è qualcos’altro e io piuttosto
vai e non ho intenzione di parlare così tu
non vedrò alcun codice qui e io no
parlerò molto del design
schemi e tutte quelle cose che ho avuto io
ha fatto altre presentazioni su questo
Sto parlando di oggi è quando ci provi
implementare un ingegnere resiliente
design del software resiliente nel tuo
compagnia quali sono le più tipiche
ostacoli che dovrai affrontare
e solo parzialmente sono correlati
davvero alle attività di progettazione o
implementando il codice la maggior parte delle sfide
affronterai al di fuori di ciò che è
sorprendente e non sorprendente al
nello stesso tempo è quello che sto per parlare
circa oggi così ho messo in bundle sette di questi
sfide fondamentalmente e discuteremo
ognuno di loro brevemente se ora senti
come bene non è esattamente quello che io
previsto
sentiti libero ora è la tua occasione va bene
detto questo è il più noioso
fai scorrere il codice bla bla bla bla bla
centric blah blah blah Devo menzionare
codice centrico perché altrimenti non lo faccio
pagato ma per il resto forse l’unico
cosa interessante giù c’è il
diapositiva Condividi link quindi è la mia SlideShare
conto che è possibile scaricare le diapositive
nel caso in cui sei interessato a loro
e sì, questo sarebbe abbastanza
e se avete un dubbio su questo
chiedimi e lasciami un messaggio a
Twitter o qualsiasi altra cosa va bene , iniziamo
con l’argomento era un piccolo software
design giusto che l’ hai raccolto
da qualche parte e tu dici sì, è fantastico
cosa ha molto senso andiamo
implementalo nella nostra azienda e vai
torna a casa alla tua macchina
coniglio e dì sì, devo ricominciare tutto
e naturalmente perché è così
ovvio che è necessario che ti aspetti
quello di essere un lavoro facile
così come stare seduti alla spiaggia con la brezza fresca
bevi nella tua mano musica soft e
tutto dovrebbe andare bene
Voglio dire, è così ovvio che ne abbiamo bisogno
ma in qualche modo wow è un vento freddo non a
brezza fresca e ci sono nuvole che arrivano
e che diavolo sta succedendo lì
ed è improvvisamente ti senti come nel
al centro di un temporale ancora con il tuo
bere nella tua mano scuote che diamine
stava succedendo, diamine no
parolacce oggi quindi cosa è andato storto e
non hai idea e bene non posso dire
esattamente cosa è andato storto nel tuo
situazione lì un sacco di cose che possono
andare male e ma cosa da quello che ho
appreso in circa dello scorso anno
implementazione di progetti software resilienti
ci sono molte cose che possono andare
sbagliato e abbastanza spesso saremo catturati
di sorpresa quando lo facciamo
perché sono le sfide che si presentano
dove non ci aspettiamo abbastanza spesso
e quello che ho raccolto qui in questo
la presentazione è di alcuni dei sette
tipiche insidie che io personalmente
con esperienza ora voglio condividerli
naturalmente con te le ho chiamate missioni
perché sfida questo di più
i gestori parlano e i suoni sono abbastanza
sembra più bello, non è così
continuiamo con le ricerche e io
inizia con la prima ricerca che è sì
capire il business case perché
Sì, agli ingegneri non ci piacciono gli affari
casi, non intendiamo davvero quello
cosa fanno le altre persone di solito e
sfortunatamente questo può ucciderci prima di noi
anche fare il primo passo e quindi dobbiamo
guarda brevemente quello che intendo tu vai
il tuo manager e dì sì, voglio farlo
progettazione del software di resilienza e poi il tuo
il manager torna con la domanda
bene , sembra un’idea interessante
voglio dire molto soldi ci guadagneremo con quello
e tu stai lì come wow e tu sei
morto prima ancora di fare il primo passo
Voglio dire, c’è una ragione per cui i manager chiedono
che si tratta di una sorta di cartina di tornasole
sono seri ma anche la loro risposta
assicurandoti che il tuo stipendio diventi
pagato alla fine del mese, così è
okay se stanno pensando a soldi tu
troverà anche questo in incognito se tu
vai al proprietario del tuo prodotto un prodotto
manager e tu dirai di sì
implementalo e chiedono lo farà
migliorare la nostra velocità che sta chiedendo
il caso aziendale sotto mentite spoglie
qualcosa di simile a ciò che è ancora una volta va bene
ma è la domanda sbagliata in questo
situazione e prepararsi per questo
devi capire che la resilienza non lo è
riguardo al fare soldi si tratta di non perdere
denaro che è completamente diverso
storia e quindi il ragionamento quindi se tu
mai ottenere è una discussione del genere
il ragionamento è qui è il mio suggerimento
come iniziare quella discussione se tu
non farlo, dovrai affrontare una riduzione
disponibilità del sistema e la ragione per
questo è il comportamento non deterministico
sistema distribuito non provarci mai
spiegare i sistemi distribuiti a qualcuno
fuori da RT è impossibile, quindi è così
l’unico posto in cui devi dire
credimi è così che è provato
c’è letteratura che puoi leggere
così almeno che gli effetti di quello e
questo accadrà parlerò che
in un minuto più in dettaglio e se il
il sistema non è disponibile, gli utenti non possono
fare ciò che intendono fare quale nel
prima da una parte hai un
subito perso entrate in modo da perdere
soldi perché non sono in grado di fare
qualunque cosa tu voglia fare qual è il
ovvio uno e l’altro è un
un po ‘più sottile ma a volte
ancora più scoraggiante i suoi utenti si annoiano
se ciò accade più e più volte e
lasceranno la vostra compagnia a cui rivolgersi
il tuo concorrente che il tasso di abbandono aumenta
nel discorso di marketing e così è
costo di entrate perse in ritardo e così via
ogni volta che hai una discussione su
business case un software resiliente
design
lui ha per lo più la trama che non posso
ti garantisco di convincere il tuo
manager è ancora molta discussione
e sapendo come parlare con loro e così
su e forse stanno solo dritta e
dì pure che è tutto molto carino
il momento di un problema diverso e
speriamo che tutto andrà bene
così e così questa strategia di struzzo e così
ma è una storia diversa almeno
hai fatto del tuo meglio e spero che sia il
la moglie è il primo passo per quello che è
il tuo budget di resilienza come questi numeri
puoi farlo con il numero prendi il tuo
monitoraggio aziendale non ce l’hai
implementato sì di solito la maggior parte delle aziende
non avere un monitoraggio aziendale
implementato che puoi ragionare facilmente
guarda i numeri delle entrate e cose simili
che se non si dispone di che iniziano con
alcune stime prudenti e provare a
ottenere il buy-in dall’altro lato mi
significa tutte le discussioni sui casi aziendali
Ho visto che non sono mai stati decisi qui
sono stati sempre decisi i loro affari
il business case che ho deciso nell’intestino
alla fine quindi questa cosa di cui abbiamo bisogno
che è una cosa strana per la nostra
ingegneri del software perché di solito
prova a decidere con il nostro cervello ma
di solito tutte queste decisioni sono prese da
l’intestino così pretende di rivolgersi al cervello
il cervello ma in realtà indirizzato a Dio
quindi cerca di ottenere la coppia e trova il
numeri in cui dicono che sì bene
ha senso per me uh sì no, lo siamo
parlando bene
abbastanza su quello che era dopo
il tuo primo passo e potresti affrontare il tuo
seconda ricerca e questo è distribuito
sistemi dal modo in cui è uno dei
le missioni più difficili quindi tutto te
fondamentalmente bisogno di sapere su distribuito
sistemi in poche parole
Virna per Bitcoin riassunto in uno in
una frase che è quella che sei tu
bisogno di sapere sui sistemi distribuiti
fondamentalmente II ed è molto, molto difficile
far fronte a quello così da quello che ho visto
e l’idea era di simulare sistemi per
25 anni e penso di iniziare
capirli a metà strada così è davvero
difficile da afferrare davvero e ottenere questi
idee nel cervello e rispondere a questo
e da quello che ho visto più del 99% di
tutto il personale IT non lo ha capito
davvero così pensano di fare per il
ciambella perché
non lo capiscono davvero e
perché non lo sono così spesso?
affrontando il sistema più stupido nel
in realtà nel modo sbagliato penso che debba
fai molto con la nostra educazione e @he e
il modo in cui il nostro cervello è cablato sì, quello che io
significa con quello che abbiamo imparato ora IKEA
ucation
in pratica è come se fosse X allora
Y comportamento deterministico se faccio questo
questo avverrà periodo garantito al 100%
e tutto ciò che apprendiamo in IT e
tutto ciò che costruisci è costruito sopra
di quel comportamento deterministico così è
quello che chiamo dentro il processo pensa tutto
la nostra educazione ITT è basata su questo
ragionamento sul deterministico
comportamento è complicato
sistema la cosa buona è che il nostro cervello è
cablato in quel modo in modo che possiamo facilmente ragionare
a questo proposito è bello ragionare
pascoli deterministici questo sarà
la garanzia è garantita il problema
era un sistema realistico è un po ‘
un po ‘diverso se X poi forse Y così
questa è una probabilità qui e noi tutti
odio una statistica non ce l’abbiamo fatta eccezione
le persone che apprendono a macchina ma io no
certo se a loro piacciono davvero le statistiche o
i laser fingono di avere statistiche da ottenere
sbarazzarsi di noi non l’ho mai capito ma
Beh, è così difficile da ottenere la testa
avvolto intorno a questo e questo in realtà
termini di design che cambiano tutto
quindi questo è un processo trasversale che pensa come
Lo chiamo e questo non è deterministico
comportamento perché quello è probabilità
e spesso succede ma qualcosa
non ha sempre solo parzialmente
succede o è terribile e devi
ragionare su questo e cerca di ottenere un
design giusto che lo tenga in considerazione
e il nostro cervello non è collegato per quello
siamo veramente poveri a quel II ancora
perché usiamo troppo per pensare
in questo modo usiamo il lato sinistro del pensiero
design per progettare o risolvere problemi su
il lato destro e il pozzo che porta a
effetti strani
Va bene, quindi quello che vedo è così tranquillo
effetti strani e vediamo che tutto il
tempo perché quando attraversiamo il
storia del sistema distribuito e
le strutture del sistema fognario DCE cob nostro
SOA EJB decom e tutte quelle cose sempre
sono stati progettati in un modo che dice bene sì
c’è un sistema distribuito là fuori
ma lo copriremo dietro le interfacce
e puoi e puoi pensare al
sistemi nel modo in cui e là
sempre portato a sistemi fragili che non abbiamo fatto
scala e tutto come quell’uomo
produzione di catastrofi così così nel
piccola scala, sì, ha funzionato
la scala più grande e non ha mai funzionato
perché hai sistemi distribuiti
modalità di errore che non vedi in
sistemi locali questi sono i fallimenti
le modalità quindi non rispondono affatto
a volte rispondere a qualcosa non lo fa
Rispondere rispondere lento l’arco nemico di
sistemi distribuiti latenza davvero difficile
ti dà la risposta sbagliata pensa
consistenza finale e tutto il resto
ordini di roba e tutte quelle cose a
ordinamento e presentatore di messaggi e
fallimento quindi sì, il sistema è tornato indietro così
non hai idea di cosa verrà dopo e
così via e questo porta a molti effetti
un sacco di carte ci sono nel computer
scienza che spesso cerchiamo di ignorare
che esistono perché è davvero difficile
accettare tutte quelle cose che tutte le cose
che sono no-brainers in un sistema locale
un sacco di cose che non hanno cervello a
sistema locale che diamo per scontato
diventare davvero difficile o addirittura impossibile in
sistemi distribuiti intendo uno dei miei
i documenti preferiti qui sono di un
Sfidato vede anche la L nel FLP
risultato impossibile se hai mai sentito
su quello che è lei e anche lei
a prova di ciò il teorema del cappuccio in realtà è così
stava solo sentendo da Brewer e il
le insuline lo dimostrarono quattro anni dopo
che è vero e ha portato un foglio a
cento prove di impossibilità per
distribuito il calcolo di un centinaio di cose
non ci sono brainers nei sistemi locali
che non funzionano in sistemi distribuiti
e dobbiamo davvero cogliere queste idee
prendili e accettali
e trattare con loro così la mia raccomandazione
è abbracciare questo tipo di pensiero questo
tipo di pensiero non garantisce solo
promette verosimiglianze e tutta quella roba
quindi questo non determina il comportamento istic
per quanto riguarda la completezza dell’esecuzione
quindi se mai avrai una risposta quando tu
ottenere una risposta se si ottiene un parziale
risposta o distorto arciere tutto questo
le cose stanno per accadere è il
messaggio resistente che ordina molto
importante quindi sì, prima di ottenere il
soldi i soldi sono ritirati hmm è il tuo
sistema in grado di gestire questa situazione
perché solo un ordine di messaggio è stato capovolto
e tutti questi tipi di situazioni e
la comunicazione è la tempistica che pensavo
già parliamo di latenza in tutti questi
modalità di fallimento, ma per essere onesti non lo farai
essere in grado di prepararsi a tutto ciò
il tuo design farà solo il tuo cervello
esplodere e questo è terribile da parte tua
guardare a esplorare il cervello così tu
solo dover accettare ti colpirà a
il livello di applicazione a un certo
laurea e non aspettarti il tuo
infrastruttura per nascondere tutti questi effetti
da te ci sono pezzi decenti di
infrastrutture là fuori che ti aiutano
per ottenerlo un po ‘più facile, anche se
si utilizza uno STO o qualcosa di simile
ma la vecchia infrastruttura non può che dare
una sorta di risposta generica
comportamento a determinate situazioni ma il
le applicazioni a volte significano questo tipo
di comportamento ea volte questo comportamento
quindi ancora ti influenzerà nel
livello di applicazione che devi affrontare
quello e il minimo che dovresti fare è avere
un piano per rilevare se qualcosa è andato storto
e riprenditi da quello , se vuoi
capire dopo otto settimane oops my
database è andato incoerente perché io
mancata modalità fallimento ha un piano come
riportare il database in a
modalità coerente che è il minimo di te
dovrebbe farlo a volte salva davvero
la tua schiena bassa in produzione ma come me
ha detto che è un sistema distribuito difficile
sono difficili sono davvero difficili, intendo
Io da quello che ho visto in 35 anni di
e sono solo due campi rigidi nell’IT
e l’altro è sicurezza nell’altro
è un sistema distribuito tutto il resto
rispetto a quello è noccioline da cosa
Ho imparato e questo è già abbastanza
cose difficili al di fuori della sicurezza in
sistemi distribuiti ma sono davvero
difficile ma ok forse troppo difficile per il
momento per sopravvivere, facciamo quella ricerca
lascia questa ricerca da parte, sì, sì, arriviamo
torna subito dopo, ma forse il solutore è più facile
ricerca per primo che è il 100% disponibile
trappola vediamo che tutto il tempo sì peggio
uno del 100% attende una trappola, quindi è così
relativo ai sistemi distribuiti
principi ma è la versione più piccola
la ricerca più facile quindi qui vai a
responsabile del prodotto o
chiunque e dite bene come dovrebbe
che come risposta rispondere se a
fallimento tecnico se questo tipo di
Il fallimento di Technol succederà se io
non posso raggiungere il mio database se qualcosa è fuori
lì se l’altro sistema è giù se io
non ottenere la risposta giusta in tempo e
tutta quella roba e poi il business
il proprietario torna da te e dì sì
bene questo non deve accadere è tuo
responsabilità di assicurarsi che questo
non accadrà mai bene, sì, per cui sei caduto
la trappola disponibile al 100% ma non lo è
solo il lato business come anche l’IT
gente questa è una situazione da una realtà
progetto in cui sono stato e dove sono
rivedi un po ‘ il design e
poi ho trovato un servizio rivolto al cliente
parlando con un servizio non rivolto ai clienti
ora basta chiedere loro di sviluppare per noi così sì
bene come gestisci quella situazione se
quel servizio clienti che deve affrontare il servizio
è giù e come rispondi a questo
da quel cliente che affronta così perché tu
voglio dare e rispondere al
cliente così o se è abbastanza tardi
roba del genere e poi bene prima
sviluppare il nostro detto no che non abbiamo implementato
qualsiasi cosa in più perché quel non cliente
affrontare la porzione è così importante se è così
giù così com’è così importante e
quindi deve sempre essere al 100%
trappola disponibile questa ipotesi che
tutto al di fuori del tuo
l’area di implementazione è sempre lì
che l’intero ambiente è sempre attivo
e sviluppare il nostro per modificare in realtà sì
beh, se quel servizio non funziona, non lo siamo
in grado di dare una risposta comunque utile
quindi sì, non ci importava, quindi abbiamo bisogno di questo
di essere all’altezza perché altrimenti non siamo
in grado di fare qualsiasi cosa dal modo in cui vengo
di nuovo a quello con la ricerca numero cinque
perché questo è un altro problema ma solo a
assicurati di capire se hai chiesto se
il fallimento accadrà è sbagliato
domanda la domanda giusta è solo per
chiedi quando accadrà un errore
tutto ciò che ti circonda ha disponibilità
disponibilità inferiore a quella che fa
il che significa che non è la domanda se
accadrà se falliranno loro
fallirà garantita l’unica domanda
è quando e solitamente questo è il tuo
venerdì nero personale in compagnia
quando guadagni i soldi della tua vita e
quando tutti i clienti stanno comprando come
l’inferno che di solito quando ti succede
può decidere di gestirlo in anticipo o
quindi mi raccomando di gestirlo in anticipo
a proposito e solo per capire a
un po ‘ meglio soprattutto nei giorni
di micro servizi e tutto ciò che è
la cosa bella ma ha un prezzo
come tutte le cose presuppongono che uno dei tuoi
i tuoi servizi hanno abbastanza tempo per
99,5 per cento compresi i tempi di fermo impianto
in un centro dati on-premise nessuno
ti dà un tale numero nel loro SaaS
Sì, alcuni sviluppatori host e dicono di sì
ti diamo novantanove virgola sette sau
bene mentre stai facendo soldi extra
verso la nostra app e sono a partire dalle 7:00
al mattino alle 8:00 di sera
si, quindi la tua disponibilità in realtà
è del 55% bene è facile da garantire
novantanove virgola sette se ne hai uno
finestra di manutenzione di undici ore ma
va bene e se dieci server sono deformati e
data una risposta a richieste esterne
tutta la disponibilità è ridotta al 95% e se
50 servizi sono coinvolti sei giù a
circa il 75% quindi ogni transazione forzata
la media fallirà quindi la disponibilità al 100%
di tutto ciò che circonda non iniziare
che o altrimenti sarà colpito da
questi numeri ma di nuovo è più facile
comunicare molto più facilmente per sopravvivere
ricerca quindi la ricerca del sistema torretta ma
okay , gestiamo quello in cui siamo sopravvissuti a
caso d’affari, sì, abbiamo avuto a che fare con
i sistemi a torretta e il 100%
trappola disponibile per il prossimo
cosa che siamo corno per i ops è
il loro ciclo di feedback I ho deliberatamente
non ha scritto DevOps perché quel termine
sfortunato rotto irreparabilmente
perché andare in una stanza con dieci persone
si ottiene una quindicina di opinioni che cosa
Di solito non diciotto di loro hanno torto
e così bene, quindi l’ho trasformato
Intorno a cosa intendo con quello che tu
vedo ancora molte aziende è così grande
così a volte la guerra tra la morte e le operazioni
fino alla gestione del livello del mare o
qualcosa del genere non ti è permesso
parlare, ma anche attraverso il muro
se c’è la finestra non ti è permesso di
aprire quella comunicazione dovrebbe andare come
va bene se hai un candy bar
qualcosa del genere potresti aprire il
finestra e attenersi alla scivolata che è vero
e così via non non non sono in
modo ufficiale sì e questa divisione di
approccio lavorativo che vediamo lì che ha
Si ha qualche bene se solo tu
pensare efficienza dei costi, ma si tratta
ad un prezzo
di nuovo e il prezzo lo farai soprattutto
vedere in questo dominio se è davvero necessario
vai veloce se hai davvero bisogno di creare
sistema di sistema distribuito che tu
di solito hanno questi giorni il problema è
il super ambiente yeah bene te
non può gestire la disponibilità solo su
livello di infrastruttura intendo in passato
sono stati gli sviluppatori a cui tieni al nuovo
personale
oops ti preoccupi di assicurarti che
tutto è attivo e funzionante e per tanto tempo
poiché il sistema funziona solo localmente e
non ha alcuna connessione con il
all’esterno tranne per connessioni batch
va bene così, perché allora il vostro singolo
il problema più importante è se il
l’infrastruttura è ancora viva se la tua
il server è attivo se il tuo raccolto non lo è
rotto e così via e tu te ne importa qualcosa
su tutte quelle cose solo su
livello di infrastruttura , ma come ho detto
prima in un panorama di sistema distribuito
tutti questi effetti ti colpiranno al
livello di applicazione questo non deterministico
comportamento dei sistemi distribuiti e così via
è necessario affrontare con che almeno
parzialmente sul livello di sviluppo
il livello di applicazione e così di solito
quello che stai cercando di fare è provare a
implementare un ciclo di miglioramento continuo
che è come abbiamo alcuni problemi che
abbiamo visto qui in ops con il tuo
applicazione oh caro non ho qui è a
ecco una figura e tu sai bene si
oh questo è interessante, non ho pensato
su quello sì, andiamo
attuare un qualche tipo di risposta a questo
una sorta di design elastico nel nostro
applicazione ed ecco cosa ho costruito per
renderlo migliore e poi lo eseguono e
ti restituiscono bene i numeri
ho lavorato solo parzialmente oh, mi sono perso
quella parte miglioriamo quella e così
ed è un miglioramento continuo
ciclo il problema con il muro è
ciclo ovvio è rotto Intendo sì, noi
implementare le misure ed ecco dove
hanno effetto comunque puoi vedere come
beh, hanno funzionato, il muro è nel mezzo
nessun ciclo di feedback è rotto quindi sì e
anche peggio, anche se lo sei davvero
ingegnere software motivato che tu
ovviamente stai sparando al
buio
non hai idea se le cose che tu
appena implementato funziona o no perché
non si ottiene il feedback in modo sostanziale
l’osservazione chiave qui è se tu
vuole davvero implementare resiliente
progettazione del software e la vostra azienda voi
necessità di avere un ciclo di feedback funzionante
altrimenti non è necessario iniziare
Voglio dire che è bello se si implementa a
interruttore qui o là o
qualcosa di simile
o qualche gestione di timeout o alcuni
cache e così via ma non lo farai mai
capire se aveva senso o lo era
solo complessità aggiuntiva nel codice
di cui a nessuno importa
a proposito, è abbastanza demotivante
e se poi sei anche solo
incentivato per il completamento di più
caratteristiche per unità di tempo perché hai
per migliorare la tua velocità perché lo sei
agile dal modo in cui non deve fare
qualsiasi cosa con un Gillette è solo un costo
efficienza nel travestimento che fa
qualcosa di diverso allora si, bene e
lo fermerà abbastanza presto
così unitivo ha stabilito un ciclo di feedback
fondamentalmente DevOps DevOps è una cosa interessante
ma ancora una volta i veri DevOps reali sono enormi
cosa così andrà nel
organizzazione nei processi nel
il modo in cui crei software fornisce software
il modo in cui progetti tutto il software
che interesserà tutto il modo in cui si
operare tale fine e fine e quindi
a volte è un po ‘troppo
da alcune organizzazioni in modo che preferisco
piace adottare le idee da Google il
idee di ingegneria dell’affidabilità del sito che
è un po ‘ più piccolo con questo per
causa del bilanciamento della velocità di innovazione
rispetto alla disponibilità di produzione
robustezza che è una cosa carina o se
hai un modo migliore per implementarlo
in questo modo, ma implementare quel feedback
ciclo okay
controllo del ciclo di feedback implementato così dopo
la ricerca numero cinque che è di nuovo
scoraggiante un design funzionale padronanza
Intendo, sì, stiamo discutendo di questo
argomento per più di 450 anni e noi
ancora sono davvero cattivi, non siamo noi
e nello stupido sistema da sparpagliare
twist extra il mio reclamo è senza un vero e proprio
design funzionale nient’altro conta
così
puoi implementare la migliore capacità di recupero
misure che siete a conoscenza del sul
livello tecnico se il design funzionale
non va bene finirai con a
fragile sistema di paesaggio che lo farà
essere sempre un po ‘squilibrato e così via
e non scalerà bene e tutto il resto
roba perché è sì, se ci pensiamo
il software di resilienza progetta l’idea centrale
le versioni di dimissioni sono l’isolamento
l’isolamento significa fondamentalmente il sistema deve
non mancherà nel suo complesso e per assicurarsi
che non fallisca nel suo complesso divido
in parti e io isolare queste parti
contro l’altro che un fallimento qui
non precipita in altre parti del
sistema e in questo modo creo di più
sistema robusto quindi anche se un parkour
cade giù gli altri sono ancora
vivo tutti dicono che sì fa un
molto senso, sì , facciamolo
e il modello di cappello nero è quindi di solito
quello che vedi per implementarlo e sì
ma l’ultima riga qui è un po ‘
strano giù dicendo quello che stai dicendo
quello che modella le teste di una bella corteccia per quello che è
estremamente difficile voglio dire che potresti dire bene
Lo faccio sempre
Voglio dire che sto tagliando e tagliando
funzionalità sempre nei metodi in
classi attraverso metodi attraverso classi
attraverso i moduli attraverso i servizi o
qualunque pacchetto e così via, quindi perché
dovrebbe essere difficile dirò bene come si fa
tu eviti questa situazione supponiamo che io
indovina una richiesta esterna che colpisce
servizio a e servizio a per adempiere a questo
richiesta richiede una risposta per il servizio B
questo è ciò che questa risposta dall’altra
sviluppatore dal secondo sviluppatore e
la terza missione era così ho bisogno del servizio B
essere disponibile per completare la mia richiesta
e restituire una risposta che hai visto
che non hai si, bene, non sono così
e a causa del modo in cui la funzionalità è
distribuito tra questi due servizi
l’isolamento è rotto di default perché
puoi averne un milione di circuiti
interruttori qui
se questo è giù interruttori automatici
ti dirò solo che sei morto male
fortuna
quindi l’isolamento è rotto bene come stai
evita che quello qui sia un esterno
richiesta con qualche tipo di funzionalità
wow non è più un micro-servizio
piuttosto un servizio macro o anche peggio
perché c’è un sacco di funzionalità
lì dentro dividiamo un po ‘questo
un po ‘e sono ancora un po’
grande quindi cerchiamo di scissione che più in alto e
così via e sì sì sì , è un po ‘strano
d’ accordo e all’improvviso lo trovi
te stesso con un’attivazione piuttosto lunga
percorso così un sacco di richieste interne voi
bisogno e ti ricordi questa disponibilità
cosa che ti ho appena mostrato
quindi la disponibilità scende con
numero di servizi coinvolti
sì, un comportamento sincrono in alcuni
le situazioni vanno bene, ma solo se non lo fai
devo fare una risposta online così
storia diversa, quindi vedi tutto molto
spesso e poi tu lotti con quello
roba in produzione e dite bene
non funziona così bene, quindi andiamo
di nuovo a quello e sì dividendo
funzionalità in diversi pezzi a
implementare bene l’isolamento è rotto
quello che dici ora nananana non è così facile
rallentare quindi applichiamo il nostro
pratiche ben note abbiamo imparato come
facciamo che prendiamo l’ informatica 101
qui dividiamo e conquistiamo il funzionale
decomposizione sappiamo come farlo o
siamo tutti i mestieri artigiani artigiani
donna quindi applichiamo asciutto non ripetere
te lo abbiamo imparato per molti anni
abbiamo fatto tanti rifugi in cui ci siamo ritirati
addestrato che roba siamo davvero grandi
a quello che è designer cool o siamo noi
Piuttosto più come un architetto, quindi usiamo
più termini di fantasia come architetti oh sì
desideriamo una fruibilità è un santo
graal in architettura lo sai e tutto
sono design che è un altro santo
Graal per gli ultimi 20 anni o qualcosa del genere
così o potresti dire no no I am
Più intelligente di così applico qualcosa del genere
progettazione basata su test o qualcosa di simile
architettura emergente e così
e dire che stai bene, questi sono fantastici
tecniche in un certo contesto ma in
Alla fine applichi implicitamente ciò che tu
conosci esplicitamente così non finirai
un design completamente diverso è solo
una procedura diversa come veniamo lì
ma userete di nuovo le stesse idee
il problema con tutte queste idee è questo
è progettato per la riutilizzabilità e asciutto
questo è un servizio riutilizzabile e
riusabilità pur avendo molto valore
in questo contesto mostra la sua brutta testa e
il lato brutto della riusabilità è quello
è l’accoppiamento più stretto possibile così
questi sono totalmente accoppiati questi due
servizi non appena questo è giù questo
uno se n’è andato e naturalmente è così
design funzionale del livello di decomposizione
e sì, mentre cercavi di aggiustare il
manca coesione qui finiamo con
che spesso di nuovo e benvenuto a
salute distribuita tutto ciò che apprendiamo
sul design di solito in educazione IT e
nella nostra pratica è grande dentro a
limite del processo ma attraverso il processo
confini con quello non deterministico
il comportamento dei sistemi distribuiti no
aiutaci un po ‘e poi dì sì, io
hanno ancora delle cache che risolveranno
tutto così sì, basta implementare a
cache in qui e se è giù posso
ottengono ancora la loro risposta dal cache
e questa non è una cattiva idea in sostanza, ma
anche le cache hanno un prezzo così buono
il punto è che se non lo fai
cura del tuo design funzionale e
prova a sistemare ogni cosa con schizzi
finirà con un sacco di cache infernali
e devi riempire questo caso che hai
per trasferire i dati che devi rispondere
al fatto che saranno più stantii
del tempo in modo che essi saranno
obsoleto, dovrai affrontare diversi tipi di
incongruenze che devi affrontare
con e così via in modo da finire semplicemente
in un diverso tipo di inferno se tu
basta affidarsi alle cache di nuovo ci sono le cache
bella cosa in alcuni posti ma loro
non sono il cerotto per una rottura
design funzionale quindi fondamentalmente mio
imparando finora è necessario reimparare
come fare il design giusto per distribuito
sistemi e abbiamo solo 45 minuti
qui ho alcune idee che potrebbero essere
completamente fuori dal campo di applicazione
sessione se sei interessato ad alcuni di
le idee che ho tenuto a parlare a Kandinsky a
poche settimane fa qua e là è
registrazione che verrà poi rilasciata
e così Kandinsky 2018 e loro lo sono
discusso alcune delle idee e il
risultati che ho su quell’argomento
l’unica cosa che la parola breve non è argento
proiettili ancora esauriti quindi è tutto
sarà un argomento difficile ma dobbiamo
concentrarsi su come ottenere il funzionale
design giusto perché altrimenti sì noi
abbiamo qualche tipo di problemi nel fare
questi sistemi robusti in realtà non lo faremo
essere in grado di renderli robusti se il
il design funzionale è sbagliato, okay
un altro scoraggiante , quindi cerchiamo
un’altra più facile, così siamo sopravvissuti tutti
in questi passaggi, supponiamo che anche noi
era sopravvissuto per lo più a quello funzionale
design e ora sì , finalmente siamo
permesso di implementare il codice che è bello
non intendo tutte queste cose fino a
finalmente ci è permesso di toccare davvero
la tastiera
e poi arrivano i modelli brasiliani
giocare e c’è anche qualche pericolo
coinvolto che ho visto così davvero
comprendendo la tua cassetta degli attrezzi intendo questo
è un’immagine del modello di resilienza che
Io uso nei miei seminari a volte ed è così
mancano modelli incompleti e anti
e roba molto più piccola e così via, ma
vedi che c’è molto da queste parti così
quali scegliere e quanti di loro
e come combinarli e così via io
ha iniziato a lavorare su un linguaggio di pattern
ma come i giorni purtroppo ne hanno solo 24
ore e ho un sacco di altre cose
per farlo è ancora work-in-progress o no
soluzione dal mio lato e non ho visto
tutto fuori ancora e sì è abbastanza
travolgente e ha qualcosa di strano
effetti a volte se vedi persone
raccogliendo quella roba così qui alcuni
raccomandazioni sull’utilizzo di questi
i modelli prima di tutto i più importanti
cosa dal mio punto di vista è modelli
sono opzioni non obbligazioni che non
bisogno di un modello solo perché lo sai
sanno che voglio dire si potrebbe a volte
ho visto questi programmi da persone che
ho appena imparato un linguaggio di programmazione
che ha cercato di implementare ogni funzionalità di
la lingua in quell’unico programma
succhiato non hanno questi programmi che vedo
quello che Perl è un tocco in più
perché in Perl puoi scrivere completamente
era di nuovo negli anni ’90 e tu puoi scrivere
case completamente reddito comprensibili
programmi programmi che l’autore
l’autore non capisce più
ora o dopo che l’ha scritto o lei lo ha scritto
Ne ho visti alcuni e anche in altri
lingue ha lo stesso modo se si mette
troppo in quello diventa duro e
è ancora peggio qui perché ciascuno
il modello che implementa aumenta il
complessità del tuo sistema e complessità
è il nemico della robustezza quindi se tu
voglio davvero creare qualcosa di solido
deve essere semplice in qualche modo deve essere
facile da capire facile da ragionare
circa e tutto ciò
dobbiamo trovare un punto d’incontro tra noi
bisogno di alcuni modelli ma ogni modello
aumenta la complessità, quindi dobbiamo
bilancia che così nessun modello è una cattiva idea
tutti i modelli sono migliori o così noi
devi bilanciare attentamente questo e anche
costa denaro ogni modello costa denaro
in dev e ops di solito spesso
licenziamenti coinvolti in questi modelli
il che significa hardware aggiuntivo in esecuzione a
tempo di esecuzione e così via e abbiamo un limite
budget come abbiamo visto così alla fine tu
prova a trovare un insieme di complementari
schemi che ne affrontano alcuni
situazioni di solito solo per darti un
breve idea di come altre persone l’hanno fatto
qui Erlang fondamentalmente stanno lavorando
con modello attore e messaggistica e cosa
usano è usato per avere questo
modello di scontro guidato che il
combinazione di escalation del monitor
riavvio è cosa supervisore lavoratore che
trovi anche nella biblioteca di Accra che
fondamentalmente la reimplementazione della tua
principi in JVM è così
ha iniziato il pony yonas era solo un po ‘
infelice che il suo datore di lavoro in quel momento
non gli ha permesso di usare Erlang e così via
si, se non posso usare il nostro Langdon
re-implementarlo
questo è per eka fondamentalmente iniziato e
hanno un cuore che batte per vedere attraverso
tutte le nostre macchine virtuali, se lo sono
ancora vivo e hanno diplomi caldi
che è abbastanza bello che ovviamente tu
non sapere i tempi morti se ti schieri
il tuo codice e questo è fondamentalmente così
questi sono i modelli che hanno implementato
e sono stati in grado di implementare su urlan
gli interruttori di telefonia era una disponibilità
di nove nove novantanove virgola nove
sette nove percento quindi pochi tempi di fermo
millisecondi all’anno contro voi pochi
modelli alla base quindi non è necessario
venti o cinquanta o se andiamo a Netflix
per esempio hanno un servizio basato
i progettisti richiedono una risposta in base a HTTP
in realtà la maggior parte del tempo e a causa del
richiesta di risposta hanno bisogno di più genitori
per capire se ottengono la latenza così
hanno tempo tutti gli interruttori automatici e
riprova la logica che possiedi
usando alcune cose del genere e ricadendo
è tutto cotto nella biblioteca storica
che potresti aver visto e poi tu
hanno anche ridondanza di più volte
soprattutto per il ridimensionamento in modo da caricare
condividendo hanno un pony molto decente
touring hanno zero dispiegamenti loro
non hanno persone braccia caldo perché
c’è JVM la maggior parte della maggior parte delle loro cose
ma l’ azienda conserviera rilascia a
implementali e loro hanno il famoso
esercito simian attraverso l’iniezione di errori
renderlo sostenibile in questi giorni tendiamo
chiamare quell’ingegneria del caos ma
questa è fondamentalmente l’idea che sta dietro
e così anche alcuni altri modelli a
caso d’uso diverso ma anche abbastanza
roba limitata e bene hanno un
tempo di operatività decente non loro
quindi sono abbastanza affidabili, specialmente se
hai preso in considerazione che è
a volte hanno circa trenta un terzo
del traffico completo a valle di
gli Stati Uniti all’interno degli Stati Uniti, quindi sono abbastanza
sono in esecuzione su oltre 100.000
macchine nelle ore di punta e poi il
la disponibilità è abbastanza impressionante, penso
ok ora abbiamo implementato tutto questo noi
supporta tutte queste missioni qual è il
l’ultimo uno sta conservando cosa
abbiamo appena imparato e questo è un comune
modello che non è specifico di
progettazione del software di resilienza che per lo più
mi preoccupa in tutto il nostro insieme
dominio intendo quello che vedo fondamentalmente io
proverei a trasformarlo nel flauto
lezione costante in questi cinque anni e
questa è la mia osservazione personale che vedo
discussioni ogni cinque anni
alcuni argomenti partono da zero come se
non c’erano discussioni precedenti
lì penso che l’anno scorso ho curato
davvero bella la non-conferenza ma ho deciso
quindi solo per ascoltare che spesso è un
buona idea dal modo ma a volte può
essere devastato ho detto bene quali sono
parlando di stanno parlando c’è un
sessione sulla riusabilità, siediti
Là
e ascolta che forse c’è
qualcosa di interessante che posso imparare
e mi sono seduto lì e ho ascoltato per loro
cinque minuti a dieci minuti e ho detto
cosa sta succedendo qui che sembra
1968 67 qualcosa di simile
quindi niente se nessuno mai avrebbe avuto
ha detto qualcosa sulla riusabilità
completamente da zero no no
conoscenza no conoscenza precedente niente di niente
Voglio dire tutto ciò che devi sapere
riutilizzabilità è stato fissato nel 1970 solo
leggi il catrame di Fred Brooks
ci sono due pagine e in fondo puoi
ottieni tutto ciò che devi sapere
riusabilità in questo singolo documento
singolo saggio e ce ne sono alcuni altri
le cose lì intorno niente e
cosa sta succedendo lì e non ne sono sicuro
Non sono perfetto, ma penso che parte
la storia è il modo in cui creiamo intuizioni
e come ci comportiamo così normalmente
nel tempo in cui lavoriamo, cresciamo le nostre conoscenze
significa sì, conosciamo anche le persone che lo sono
così o forse anche così ma
supponiamo che la maggior parte di noi lo sia
imparare costantemente cose nuove tutto il
tempo c’è una differenza ma come il
differenza tra approfondimenti quindi conoscenza
quello è oh sì, sono la prova di
tempo e questo richiede un po ‘più tempo perché
ti ci vuole un po ‘di tempo prima che tu veda
alcuni schemi ripetuti e così via e
dì sì, questo ha molto senso
per tenerlo a mente e questo sì
meglio dimenticare quella roba e così via e
quindi questo cresce su un tasso diverso e
questo in realtà non è niente di speciale per l’IT
è qualcosa che vediamo in tutto
industrie ma soprattutto in IT che abbiamo
un modo molto specifico per gestirlo
altre industrie se qualcuno è abbastanza
nuovo nel dominio e ha un problema a
nuovo problema quindi cosa tendono a fare
cercano di guardare nel corpo di
la conoscenza che esiste per quello
disciplina ingegneristica o qualsiasi altra cosa
disciplina è che abbiamo un diverso
strategia cerchiamo sempre il prossimo
pallottola d’argento
all’orizzonte ho avuto un problema
qui forse ci sono alcuni Savala
microservizio Kafka resiliente sicuro s
qualunque soluzione là fuori che posso
adottare si potrebbe mai cercare una lampada
impilare anche se risolverebbe perfettamente
il tuo problema
no no, quella è roba vecchia che è quella che deve essere
beh, certo , no , è vecchio
schema non possiamo usare quello che intendo di nuovo
ci sono molte cose che non voglio
ricorda più che sono felice di poterlo fare
lascialo alle spalle, ma c’è anche molto
di un bel po ‘di saggezza senza tempo nel nostro
dominio che tendiamo anche a dimenticare con
questo tipo di uso di loro così abbiamo anche
questo tipo di tecnologia usa ‘m che è
molto in pratica quello che ho visto è noi
dobbiamo riscoprire le nostre intuizioni ogni
5 anni intendo che c’è una ragione per cui
Martin Fowler ha scritto una nuova versione del suo
refactoring di libri e iniziato fondamentalmente
da zero perché nessuno davvero
ci sono così tante persone che non lo fanno
ricorda che il vecchio libro sì loro
è iniziato con JavaScript, quindi lo faranno
mai letto che altri libri, quindi facciamolo
scrivi un’edizione JavaScript con questo sì
quindi tutti per usarlo in un modo diverso noi
festeggiamo noi stessi per dimenticare
tutto ciò che abbiamo imparato, aspetta
un po ‘difficile e il mio problema con
quello che mi preoccupa è che non sono sicuro se
inquietante come possiamo davvero migliorare
con quello di cui non ho un’idea perfetta
quella o nessuna soluzione se ne hai una buona
idea per favore condividilo perché il mio
impressione è che non stiamo andando a
diventare una disciplina ingegneristica e
vera disciplina ingegneristica e chi noi
ho risolto questo problema ed è anche un
rilevante per la progettazione del software resiliente
perché tutto ciò di cui ho parlato e
tutto ciò che so della resilienza
di questo non è nulla di nuovo, qualcosa del genere
roba è già lì da 40 anni o
più a lungo quindi lo dimentichiamo e
ancora e ancora avvolgendo sette
missioni che potresti incontrare nel tuo
società se si tenta di attuare tale
cose
sono difficili da fare e il
la cosa interessante è la maggior parte di quelli sono
solo in modo interattivo correlato a resiliente
software progettato per fare quel design
e parte di implementazione che è
sorprendente e non sorprendente al
allo stesso tempo perché è spesso figura
dopo un po ‘ci sono nuove idee
nuovi concetti il più difficile
probabilmente raccogliendo sistemi distribuiti
ma questo è un sacco di tempo e il prossimo
il più difficile è probabilmente quello di padroneggiare il
design funzionale dove come dominio noi
sono ancora abbastanza cattivi e distribuiti
sistemi come ho detto aggiungono un tocco in più per
quello solo il pannello è abbastanza facile e
noi sì è la domanda che non posso
rispondere in realtà bene è quello che ho avuto
per te e così prima di tutto molto
per il tuo tempo e ora sono pronto per
rispondere alle domande
[Applausi]
Please follow and like us: