il mio nome è Michael Nygaard Sono un CTO di
rilevanza e autore della pubblicazione del libro
e ti parlerò questo
pomeriggio sull’esercito implementazione e
perché dovremmo sbarazzarci di loro quello che io
significa che un esercito di dispiegamento è qualcosa
come questo questa è una foto che a
inviato un mio amico da un ex cliente
ora quello che vedi qui è una conferenza
stanza con circa 40 persone nel
sala conferenze alcuni di loro sono dietro
la fotocamera da qualche parte di fronte al
fotocamera oltre alle persone nel
sala conferenze
c’è un telefono Polycom aperto a
ponte delle conferenze con circa un uguale
numero di persone al telefono come lì
sono nella stanza a cui è iniziato questo spiegamento
4:00 nel pomeriggio
in realtà è iniziato un po ‘ prima
che quando hanno mandato via alcune delle loro persone
casa a fare il pisolino in modo che potessero prendere il
spostamento in ritardo perché questo schieramento funzionerà
continuare fino alle 4:00 del mattino alcuni
dei passi notevoli durante questo
l’implementazione prevede il test del fumo da parte di
utenti aziendali alle 1:00 del mattino
dove hanno script di istruzioni
che dovrebbero fare clic intorno
il sito e assicurati che sia tutto
funziona bene e ovviamente puoi farlo
immagina che alle 1:00 del mattino no
tutti sono alla loro massima attenzione e
quindi alcune delle persone che eseguono alcuni di
gli script riportano errori casuali
non sono in realtà errori ma i nostri conosciuti
condizioni da anni fa alcune persone
fare clic in modo errato e segnalare errori
sono i propri errori non l’applicazione
gli errori si tratta di un processo molto rumoroso
coinvolge un sacco di persone in effetti loro
avere così tante persone che hanno dei passaggi
nel piano per chi inviare per ottenere
cibo in vari punti nella notte e
hanno aggiunto passaggi nel piano come tempo
è passato per assicurarsi che qualcuno
svuota i bidoni della spazzatura da tutto il
contenitori dal cibo che portano
questo è per nutrire tutte queste persone
l’ esercito di dispiegamento è notevolmente
struttura persistente è anche un
anti-modello si sviluppa a causa di questo
credono questa profezia che si autoavvera
la profezia che si autoavvera dice
abbiamo il rischio creato da questi grandi
rilasci poco frequenti di una certa quantità di
codice o inventario sconosciuto che è in corso
schierato e questo rischio produce
situazioni minacciose che minacciano di
il business e minacciando di
individui che vengono incolpati se le cose
non andare bene durante la distribuzione
hanno una radicata risposta a questo
ambiente ambiguo o incerto è quello di
applicare le persone ad esso e così hanno questo
credenza che l’ esercito di dispiegamento sia il
il modo migliore per reagire a situazioni sconosciute
ora è una profezia che si autoavvera
perché gli umani sono bravi a reagire
situazioni sconosciute o nuove molto meglio
di automazione o script in realtà ma
perché questo esercito di dispiegamento è lì
è un processo molto costoso che puoi
immagina se abbiamo circa 80 anni
le persone trascorrono quasi un periodo di 24 ore
facendo questi schieramenti quando entro
e dire che dovresti fare
schieramenti una volta alla settimana invece di una volta
ogni trimestre mi guardano
come se fossi pazzo perché dato loro
contesto sarebbe pazzo dirti
dovrebbe farlo ogni settimana, ma così in alto
il costo di implementazione si rafforza effettivamente
questo intero ciclo l’alto costo di
spiegamento significa che fai meno frequente
rilascia e meno frequente il
il rilascio è il più grande sarà
e quindi il più rischioso e altro ancora
minacciando sta andando a creare
più bisogno di più umani in modo da poter vedere
come questa spirale funziona alla fine è
produce la paralisi se fai questo
loop abbastanza spesso si raggiunge un punto
dove non si può aggiungere qualsiasi più la gente si
sviluppare un libro di esercizi che conosci un
Foglio di calcolo Excel stampato così spesso
alla fine hai appena colpito il punto in cui
è impossibile aggiungere più a questo
processo e ti senti come non si può prendere
niente lontano da questo processo e poi
sei bloccato ho intenzione di parlare di
cosa possiamo fare al riguardo, non sono tutto te stesso
conosciamo il pessimismo e l’ oscurità e condanniamo noi
ci sono alcune soluzioni ma prima io
voglio vedere perché questa situazione arriva
in primo luogo perché persiste
e perché le persone percepiscono un conflitto ora
Sono un credente nella Teoria di
Vincoli e nella teoria di
Vincoli c’è questo strumento chiamato il
evaporando nuvola è un grande nome
i tuoi problemi semplicemente evaporano l’idea
è che si tenta di identificare la radice
causa di un conflitto basato su conflitti
ipotesi piuttosto che reali conflittuali
imperativi e così il conflitto che siamo
andando a guardare qui sta raggiungendo
successo finanziario nella vostra compagnia
un ramo di questa nuvola abbiamo un’idea
che vogliamo i benefici di essere agili
e vogliamo l’integrazione continua tutto
la strada verso la produzione che è
di cosa siamo qui per parlare di questo
ciò erogazione continua è tutto
quello è il cheerleading che abbiamo fatto
e ne abbiamo sentito parlare per un bel po ‘
il tempo e quel ramo sembra qualcosa
come questo
il successo finanziario è prodotto dall’alto
velocità e cicli brevi che significa noi
bisogno di fare più spiegazioni ma c’è
un altro ramo di questa nuvola che dice
il successo finanziario è raggiunto da
evitando perdite da bug di downtime
problemi con il marchio di conformità legale
perdita della reputazione del marchio e così via e
lungo quel ramo della finanziaria
percorso di successo
vediamo abbiamo bisogno di ridurre il rischio che
significa che dovremmo fare di meno
schieramenti bene quando mettiamo questi due
rami insieme vediamo il conflitto che
sembra che abbiamo due cose che noi
sia bisogno o che abbiamo bisogno di tutti e due
per produrre successo finanziario, sostengo
che questo non è in realtà un inerente
conflitto non abbiamo bisogno di entrambi
implementazioni e meno dispiegamenti noi
bisogno di guardare queste ipotesi su
basso rischio e alto rischio e così siamo
andando a farlo quando parliamo di rischio
alcune persone usano una ruota molto cappa
definizione del rischio di rischio significa che c’è un
possibilità che qualcosa di brutto sta andando
capita il rischio significa che mi sento nervoso o
il rischio scomodo può anche essere solo un
parola spaventa che si butta in a
conversazione il modo in cui alcuni
politici
piace buttarlo in conversazioni
etichetta qualcosa di uno schema rischioso quando tu
solo non voglio che accada ma non hanno
altro argomento contro di esso stiamo andando a
utilizzare una definizione di rischio più sfumata
stiamo andando diciamo rischio è l’atteso
perdite da eventi indesiderati e I
significa perdite previste nelle statistiche
senso se faccio questo processo abbastanza volte
può mediare le volte che va
male e perdo qualcosa e le volte
che non va male e io no
perdere qualcosa, così raggiungiamo questa nozione di
perdite attese e possiamo vederlo
come la nostra esposizione al rischio di esposizione al rischio è
spesso espresso in termini di annuale
aspettativa di perdita o perdita annuale
l’aspettativa è utilizzata nei mercati attuariali
come l’assicurazione sulla vita e l’assicurazione sanitaria
è usato nella gestione della sicurezza per
Sicurezza IT e arrivare al
aspettativa di perdita abbiamo fondamentalmente eseguito un piccolo
equazione che dice che abbiamo un numero di
eventi in cui una perdita potrebbe verificarsi noi
avere una probabilità di uno di quelli
gli eventi sono errati e quindi producono
la perdita e abbiamo un costo ogni volta
uno di quegli eventi si verifica così il
numero di eventi moltiplicato per la probabilità
volte il costo che ci dà il nostro
perdite attese questo è utile
definizione del rischio perché se lo abbiamo
perdite previste in qualche tipo di economia
termini quindi possiamo decidere prima di tutto
come possiamo minimizzarlo e in modo più cruciale
è la perdita in realtà più grande del
guadagni che potremmo ottenere facendo
qualcos’altro in cui gli umani sono molto cattivi
processo decisionale economico su un intuitivo
base e abbiamo studiato dopo lo studio
questo mostra ciò che tendiamo ad essere
la perdita è contraria se chiedi a qualcuno se
scommetteranno una possibilità di 50/50 di
vincere un milione di dollari o aggrapparsi a
centomila dollari che terrò
su quello che hanno ottenuto piuttosto che
cogliere l’ occasione anche se
matematicamente dovrebbero prendere il
opportunità
quindi se presentate semplicemente le persone in perdita
cercherà di evitare ogni volta la perdita
ma se presenti la perdita e tu
presenta il guadagno disponibile allora hai
una possibilità di prendere una decisione razionale
dopo un sacco di incontri e un sacco di
argomenti e prove da altri luoghi
e così via facciamo un esempio di questo
tipo di un calcolo dell’esposizione facciamo
Supponiamo che io gestisca un sito di vendita al dettaglio e io
ho una specie di bug nel mio checkout
processo ho un sacco di checkout per
anno qualcosa come sapete 10 alla
Dal 6 all’8 non riesco a leggere
più 10 all’8 quindi abbiamo molto
di cassa in corso all’anno ma è così
non è un bug molto comune è qualcosa
ciò accade solo una volta tanto e così
le probabilità che si verifichi sono piccole
abbiamo un gran numero di eventi e il
il costo di ciascuno di quegli eventi è
praticamente qualunque cosa sia nel carrello e noi
posso dire che c’è un valore medio di a
il carrello lo chiama forse 25 euro
e posso moltiplicare tutti questi insieme
e dire quanto dovrei essere disposto a
pagare per risolvere questo bug quanto sto andando
perdere su questo particolare bug all’anno
Funziona a circa cento e
trentuno euro all’anno, quindi quanto
dovrei essere disposto a pagare per risolvere questo problema
bug bene se il sistema sta per vivere
per un anno dovrei essere disposto a pagare
solo fino a centotrenta euro
per correggere il bug
altrimenti pagherò di più per correggere il bug
di quanto sto perdendo dal bug se il mio
sistema ha una vita di design di cinque anni
dovrebbe essere disposto a pagare circa 650 euro
per correggere l’errore perché lo salverò
molto oltre i cinque anni del sistema
e se ho una vita di 10 anni e così via
su di te puoi calcolare le perdite attese
da questo insetto nel tempo e poi equilibrio
contro quello che costa compensarlo
quindi questo è un esempio di come trattare con a
piccolo e relativamente frequente
evento che si verifica in modo tale questi checkout
capita tutto il tempo il costo di ciascuno
è relativamente piccolo
ci sono metodi simili per trattare
con gli scenari orribili davvero grandi
quindi ci sono persone che passano le loro
tempo a pensare a cose meravigliose
come se costasse un asteroide
colpire la terra mi piace leggere questi su
la spiaggia durante il periodo estivo
il libro che posso raccomandare è chiamato
quantificare e controllare catastrofici
rischia che il metodo non sia dissimile
la parte difficile è ottenere dati perché noi
non hanno molti impatti di asteroidi per
anno per misurare e misurare il costo di
loro e ci aspettiamo che quando lo fanno
succederà che sarà molto costoso
l’autore di questo quando John Garrick
ha fatto anche una meravigliosa analisi sul
impatto attuariale della guerra nucleare quindi forse
lo vorrai per la tua estate
trattare quando parliamo di rischio e
perdita possiamo iniziare a raggruppare il rischio in
un paio di categorie è una di queste
rischio di conformità quindi questo dice che c’è
qualche regolamento o qualche legge o alcuni
ente del settore e se non sono conforme
con esso possono imporre multe contro di me
l’altro tipo è il rischio tecnico
più come l’insetto e controlla dove
Sto producendo le perdite da solo
il rischio di conformità è difficile da gestire
con
tende ad essere specifico del settore e se
sei in una di queste industrie con a
molto regolamento sei probabilmente
trattare con organismi di approvazione di terze parti
agenzie di prova e simili e
ci sono alcune cose che puoi fare
consegnare in un ambiente di certificazione
e tu puoi consegnare continuamente in a
ambiente di certificazione e quindi ottenere
certificato una volta l’anno o qualsiasi altra cosa
frequenza che l’agenzia di certificazione
ti consente di assicurarti di passare
sulla tua prima volta attraverso il
certificazione ma probabilmente è su
tutto quello che posso dire sul rischio di conformità
è semplicemente un attrito nel tuo processo
che devi affrontare posso dire a
molto di più sul rischio tecnico
perché questo è molto di più sotto il nostro
controllo e così è dove sto andando
passare il resto della sessione
messa a fuoco
quando gestiamo il nostro rischio tecnico
siamo particolarmente legati alla consegna
penserò alla nostra equazione di Ellie e
guarda come ognuna di queste variabili è
influenzato da fare la consegna continua così
il numero di eventi sta andando a
aumentare è un dato di fatto
quello che faremo in realtà ciò che noi
voglio raggiungere vogliamo il numero di
eventi per salire in modo che possiamo lavorare su
diminuendo la probabilità di un errore
e diminuendo il costo in caso di errore
si verifica e questo è dove dobbiamo
attenzione quindi ho un piccolo confronto
grafico che torneremo a e
rivisitare un paio di volte vogliamo essere sicuri
che la diminuzione della probabilità di
errore e il costo di un errore è grande
abbastanza per compensare l’aumento del
numero di eventi che stiamo per essere
facendo e quindi diamo un’occhiata a dove il
le probabilità di errori vengono da e
vediamo cosa possiamo fare con ciò certamente
i difetti nel codice sono uno di loro ma
non è l’unico posto che puoi ottenere
errori perché il codice può essere tutto a posto
e i tuoi test unitari possono passare, ma poi
quando metti tutto insieme e tu
spingerlo fuori nell’ambiente
forse le cose non funzionano là fuori così
sarebbe un errore nel montaggio di te
lasciato le tue configurazioni di sviluppo nel
pacchetto che hai messo in produzione e
quindi stai provando a connetterti a un
database di sviluppo che non lo è
accessibile dalla produzione
ambiente che sarebbe un assemblaggio o
errore di confezionamento si può anche solo avere
un errore nell’esecuzione della modifica e
questo era quando stavo facendo operazioni IT
il tipo più comune di errore che
si è verificato che avessimo qualcosa come 50
per cento di tutte le nostre interruzioni
subito dopo una modifica a
produzione ora
i nostri cambiamenti erano come lo spiegamento
esercito quando tutto era eseguito manualmente
era un amministratore che copiava i comandi
fuori da un playbook e incollandoli dentro
un terminale che è in realtà un bene
pratica la copia e incolla lo sai
a tutti lo stile prendi qualcosa di intelligente
citazioni da Microsoft Word ma la maggior parte di
il tempo di copia e incolla è relativamente
sicuro perché non puoi digitare qualcosa
non si può mettere per sbaglio accidentalmente
nome host appena fuori dall’abitudine della memoria delle dita
i difetti nel codice sono uno di quelli
cose che si accumula nel tempo la
più a lungo vai tra gli schieramenti
più a lungo costruisci l’inventario più
opportunità ci sono per i difetti
codice più testato che hai e possiamo
guarda questo con qualcosa come un
diagramma di flusso continuo a continuo
il diagramma di flusso viene dalla magra
scuola di controllo dei processi e fondamentalmente
che guarda le cose che entrano in un processo
e cose che escono da un processo ma invece
di contare sorta di numero di cose
in corso e avendo la linea ondulata
del genere è sufficiente aggiungere su di una riga
ogni volta che qualcosa entra e tu aggiungi
su un’altra linea ogni volta qualcosa
lascia che assomigli a qualcosa di simile
possiamo vedere qui è la linea rossa
che rappresenta il codice che è stato archiviato
sei stato a conoscenza dell’unità testata e
funzionalità completa ed è fatta per il tuo
la definizione della squadra di fatto aumenta
monotonicamente non ne sottraiamo mai
è un flusso continuo, quindi continuiamo a salire
quello che abbiamo sulla linea nera è
schieramenti quindi niente niente niente
e poi tutto in una volta c’è un grande
implementazione con una battuta di codice che
esce e poi niente niente
niente ancora per un po ‘e poi
un altro colpo di codice si spegne e il
bella cosa di un flusso continuo
diagramma è che si può solo guardare il
distanza verticale tra le due linee
e dire che è il mio inventario accumulato
questo è quanto lavoro in corso ho fatto
costruito che non è ancora uscito e io
credo che l’ inventario accumulato in
codice più o meno linearmente uguale
rischio accumulato nel codice quindi questo è un
diagramma di una distribuzione di gruppo o a
spiegamento puntinato se prendo esattamente
lo stesso flusso di funzioni, quindi il rosso
la linea rimarrà la stessa
ma mi sono appena spostato in una distribuzione quotidiana
dopo un giorno dopo il codice è
controllato nel CFD assomiglia a qualcosa
questo te se sei nella schiena che potresti
nemmeno essere in grado di vedere la quantità di
rischio accumulato tra queste due linee
Non ho fatto nient’altro che cambiare il mio
schierare
frequenza in modo che corrisponda più strettamente al
frequenza di controllare le cose, ma ho
drasticamente ridotto la quantità di
rischio accumulato che è incorporato nel mio
pipeline in qualsiasi momento
il tipo di cosa che otteniamo
aziende come Etsy e Flickr e
SoundCloud e così via che stanno facendo
consegna continua e ottenere il loro
codice là fuori e convalidato in
produzione il più rapidamente possibile
perché la produzione è davvero l’ unica
posto puoi convalidare tutto il tuo codice
un modo per ottenere questo è con il
costruisci un’idea della pipeline che alcuni di voi hanno
probabilmente visto prima se hai letto
il libro di jezza lo hai sicuramente visto
prima che la nozione di una pipeline costruita sia
essenzialmente stai estendendo il tuo
flusso di integrazione continua che è
questo e lo stai facendo raggiungere
fino al tuo ambiente di QA e
alla fine alla tua produzione
ambiente di distribuzione come andate e
applicare test per cose come
requisiti non funzionali in un
la moda automatizzata mentre vai e
hai taggato il tuo albero e accedi e
Misuri ad ogni passo lungo la strada
così quando si fallisce si può dire dove si
fallito e perché e tornare indietro e entrambi
fissare la pipeline in circa la metà dei casi
o correggi il tuo codice in circa la metà dei casi
ora questa è una build abbastanza lunga
pipeline e sembra molto simile
lo faresti manualmente è un buon posto
per iniziare prendendo ciò che il tuo manuale
gli schieramenti sarebbero e solo
traducendoli in una build automatizzata
conduttura mentre migliorate in questo voi
può aggiungere alcune fasi o è possibile rimuovere
alcune fasi si può cambiare il modo in cui
stai assemblando possiamo guardare
riducendo i nostri errori di montaggio costruzione da
applicando alcune pratiche noi
certamente vogliamo test rapidi così otteniamo
feedback subito un’ottima pratica
per ridurre gli errori di costruzione è il
costruire server puliti da una definizione
nel controllo della versione così usando qualcosa
come lo chef burattino o cfengine, così tu
può impegnare tutto il tuo server
definizioni per il controllo della versione e mantenere
quelli in sincronia con i tuoi bisogni
applicazione
sicuramente costruendo l’ applicazione da
controllo della versione invece di costruire da
conosci le buone pratiche del box di sviluppo inquinato
Spero che tutti lo facciano già se
Non che sia un facile primo passo per cominciare io
ancora occasionalmente vedono ambienti
dove le persone stanno promuovendo fonti e
costruire su ciascun ambiente di destinazione questo
introduce un vettore per il cambiamento in questo
l’ambiente di destinazione può avere un
insieme di dipendenze diverso dal tuo
ambiente di produzione o quella
ambienti precedenti in cui le cose hanno
presumibilmente ha funzionato e quindi non lo fai
vuole davvero diverse versioni di
librerie striscianti in differenti
istantanee di file jar e così via
tipo di cosa che si insinua in questo modo
binari una volta e poi promuovendo il
i binari sono una buona pratica e
certamente schierando allo stesso modo
ovunque aiuta ho visto molto
situazioni in cui gli sviluppatori non fanno a
sono schierati sulla propria macchina
semplicemente eseguendo direttamente dal
directory che stanno costruendo
dentro e poi usano qualcosa di simile
Capistrano da schierare in scena
macchina e quindi usano un virtuale
snapshot e implementazione della macchina da raggiungere
produzione e quindi ne stiamo usando tre
diversi meccanismi in tre diversi
ambienti che più o meno massimizzano
l’opportunità di errori di montaggio a
insinuarsi così non vogliamo farlo noi
voglio costruire allo stesso modo e distribuire
allo stesso modo ovunque io lo sappia già
detti test rapidi sono test veloci
abbastanza importante qui, quindi credo veloce
i test sono una pratica essenziale alcuni
i negozi continuano a fare lavori mentre
la costruzione è rotta non difendo
che mi piace avere una testa pulita di
maestro e se è se il capo del maestro
non sta costruendo correttamente non dovresti
essere commettendo nuova funzione che si opera
dovrebbe prima tornare a una build verde
e poi continua il lavoro sulle caratteristiche che puoi
commettere funzionalità di lavoro sui rami ma
la prima priorità sul master è la correzione
maestro come si diventa più avanzato con
le tue build puoi osservare l’applicazione
alcune delle tue linee guida di architettura o
standard nel processo di costruzione stesso così
una cosa che stiamo aumentando
guardare è la gestione delle dipendenze e il
le cose che stiamo tirando dentro sono state
abbastanza comune per noi avere uno sviluppatore
tira dentro un file jar in modo che possa usarne uno
funzione da una classe ma poi quella
file jar porta in tutti i suoi amici su
l’autobus quindi finiamo con uno stack di 40
barattoli a volte includendo l’intero altro
lingue solo perché abbiamo bisogno di uno
cosa per esempio sto lavorando in
chiusura e ho scoperto JRuby nel suo
interezza esisteva in uno dei nostri progetti
perché includeva una dipendenza transitiva
JRuby per la sua shell interattiva alcuni
le organizzazioni sono molto attente
quali licenze permetteranno e così via
è un altro posto dove puoi far rispettare
restrizioni di licenza se si dispone di un
sviluppo e operazioni separati
gruppo è davvero importante da ottenere
operazioni coinvolte nella creazione del
script di implementazione in modo che la stessa società
che ti ho mostrato la foto di al
all’inizio ho trascorso qualcosa come un milione
e mezzo dollari di creazione automatizzata
script di implementazione del gruppo di sviluppo
consegnato la distribuzione automatizzata
sceneggiature che il gruppo operativo ha detto bene
è grandioso ma non ci piace quello strumento
e quindi prenderemo quei copioni
e usarli come specifiche e poi
andremo a scrivere i nostri script
nello strumento che ci piace così questo è un
enorme spreco di denaro e le probabilità di
quelle due cose le due serie di
gli script che fanno esattamente la stessa cosa sono
abbastanza piccolo questo potrebbe essere stato
evitato se avessero ottenuto più buy-in da
ops all’inizio dello sforzo e
ha funzionato direttamente nello strumento che Ops era
alla fine andando a sostenere e di
Certo se non hai ottenuto il
messaggio sulla distribuzione da capo di
il tronco che si estende dalla testa del tronco è a
approccio davvero buono , preferisco la funzionalità
rami come rami di breve durata ma
quindi reintegrare contro il tronco alcuni di
potresti aver visto questo articolo
che parla di avere uno sviluppo
filiale e fusione da master in
sviluppo e distribuzione al di fuori di
lo sviluppo II lo trovò
crea troppe opportunità di errore
le persone fonderanno le cose in
sviluppo perché pensano che sia giusto
sviluppo ma se hai una cultura
quello dice che il padrone è schierabile tutti
otterrà quello per fare questi là
sono alcune cose che dovrai fare
installazione nel tuo ambiente Io sicuramente
pensi di aver bisogno di un repository di pacchetti tu
hai bisogno di un posto dove puoi mettere il tuo
binari che possono essere sicuri che possono
essere checksum possono avere francobolli di versione
non ti mancheranno
bisogno di registrazione per assicurarsi che ne hai bisogno per
buone operazioni comunque e tu ne hai bisogno
metriche per sapere se un cambiamento che tu
fare è dannoso e sapere come rapidamente
possibile se è dannoso e lo sarò
rivisitare l’argomento delle metriche in a
poco tempo
quindi sono errori di imballaggio e di assemblaggio
il prossimo tipo di errore che aumenta
la nostra probabilità di errori è la distribuzione
stesso e quindi guardiamo un po ‘
modi per rendere sicuro il deployment avendo 40
persone che lavorano su un playbook dove
c’è un passo che dice che sai che siamo
andando a chiamare il DBA e dire al DBA
per chiudere e poi faremo
chiama questa altra persona e diglielo
fai quella cosa che è una specie di
l’opposto di rendere le distribuzioni sicure
tipo di PlayBook si evolve perché qualcuno
vuole davvero essere come la NASA e la Missione
Controlla in realtà il miglior tipo di
la distribuzione è quella in cui non è necessario un
stanza piena di persone che riferiscono a ciascuno
altro tutto il tempo
il dispiegamento in realtà dovrebbe essere gentile
di invisibile come nessuno dovrebbe essere
in grado di dire quando succede tranne che da
guardando un grafico quindi ce ne sono alcuni
modelli che hai sentito menzionato
oggi e che forse hai visto
altrove uno di questi è questa nozione di
canarino rilasciando così in questo modello tu
prendi parte della tua capacità e tu
rendilo il pool di test o la piscina sporca
e distribuisci il tuo nuovo software
lì e vedere come si chiama
un canarino dalla vecchia storia di
portando un canarino è minatore di carbone
portando un canarino nel carbone
mio perché se ci fosse un accumulo di
carbonio monossido
canarino sarebbe morto prima dei minatori
quindi l’idea qui è se qualcosa non va
il canarino lo mostra prima e il
utenti che stanno colpendo il pool di canary
prima ho sperimentato il problema, quindi questo è
riducendo il numero di persone esposte a
un problema ma in realtà non lo è
eliminare il problema che devi fare
supponiamo che un certo numero di errori
stanno ancora andando a finire qui così
stiamo parlando di ridurre il
Probabilità di errore ma non possiamo fare
Zero un altro approccio è qualcosa
quel jezz ha scritto di chiamata
Distribuzioni Bluegreen questo è dove tu
hai due piscine di capacità yeah tu
dividerli in nomi arbitrari
piscine blu e verdi per distribuire il tuo nuovo
codice in uno degli ambienti voi
convalidarlo è possibile eseguire alcuni test del fumo
vuoi un po ‘di monitoraggio e misura
su entrambi e poi ad un certo punto tu
passa a usare quello che preferisco
strumento per l’utilizzo è davvero fantastico
nome high-tech e risoluzione delle dipendenze
servizio chiamato DNS a questo punto Verde
diventa il tuo nuovo ambiente di staging e
è l’obiettivo della tua prossima implementazione
se sei in una nuvola questo è ovviamente
molto facile da fare se non sei in alcun
è un tipo di ambiente virtualizzato
sarà un po ‘più duro perché
devi avere una capacità inutilizzata
posa attorno a un altro stile di realizzazione
le distribuzioni sicure utilizzano un virtuale
implementazione basata su computer, quindi in questo caso
hai un server non una macchina di sviluppo a
dev workstation ma un server che è il tuo
dev environment e ad un certo punto te
dì sì questo è buono, lo benedico e tu
creare una macchina virtuale basata su questo
immagine e poi la usi virtuale
macchina da distribuire nel tuo più alto
ambienti il vantaggio chiave qui è
ci sono davvero poche opportunità per
errori da insinuarsi durante la distribuzione
perché non stai cambiando il
macchina essenziale
mentre ti muovi attraverso gli ambienti il
prossimo approccio che puoi usare per fare
implementazioni molto sicuro e prevedibile è
gestione della configurazione basata
schieramenti così in questo scenario che ho
dividere la mia capacità nel controllo
aereo che gestisce l’infrastruttura
e il piano di servizio che in realtà
il lavoro non è molto impegnativo
per finire ancora in questa immagine ma a
un certo punto ho un’immagine di base nel
slide precedente ti stavo mostrando a pieno
applicazione configurata in quella virtuale
macchina in questa diapositiva ho solo il
sistema operativo più una configurazione
client di gestione sa come parlare
a quel server di configurazione e questo è circa
in modo che la macchina di base ottiene
istanziato nel piano di servizio e
la prima cosa che fa è parlare con
il server di configurazione e chiede Chi sono questo
è così che lo chef e il burattino lavorano con il cfengine
funziona anche in questo modo, quindi la macchina chiede
Chi sono io, qual è il mio ruolo, quali sono i miei
configurazioni che scarica quelle
configurazioni estrae i pacchetti dal tuo
repository del pacchetto o dalla config
server e inizia a installare le cose su
se tutto ciò che succede ha successo
segnalando le sue metriche al tuo
server di metriche e ad un certo punto anche questo
ha bisogno di segnalare le sue versioni di
tutto torna al server di configurazione e
è molto importante chiudere il ciclo
qui perché tipo di un fallimento comune
la modalità è una delle tue macchine non ottiene
aggiornato e quindi è effettivamente in esecuzione vecchio
versioni di roba questo è davvero strano
problema da rilevare in produzione e così via
è bene costruire una pagina in ognuno di essi
le tue app che riportano la versione
è in esecuzione e poi raccoglie tutto
quelli sul tuo server di configurazione in modo che tu possa
guardare un semplice report e subito
identifica chiunque stia gestendo un vecchio
versione del software e poi tu
spegnere la macchina e avviare a
nuovo al suo posto
ora per fare una di queste cose
di cui ho appena parlato, tu hai
mettere in atto una sorta di zero
meccanismo di distribuzione dei tempi di inattività perché a
qualche punto nel tempo che avrai
la nuova versione del tuo sistema e il
vecchia versione del tuo sistema vivo
insieme quindi è importante farlo in
un modo strutturato in modo che tu possa gestire
cose come migrazioni di database e te
può dividere le migrazioni del database
in una sequenza di passaggi sicuri in modo che
stai facendo prima operazioni additive
ottieni tutto il tuo codice e
allora fai la sottrattiva o
operazioni restrittive quindi per prima cosa aggiungi
tabelle e aggiungi colonne con una
piccolo cambiamento quindi spingere fuori il codice
con un altro piccolo cambiamento e poi una volta
sei soddisfatto che tutto sia
lavoro
spinga fuori un altro cambiamento che lascia
il codice da solo ma scende tabelle che tu
non servono altre colonne di gocce
non ti serve più
aggiunge eventuali vincoli non nulli che tu
potrebbe voler applicare a quel punto e così via
li fai in fasi mentre lo fai
è molto importante a cui pensi
come le diverse applicazioni e
i servizi si conosceranno a vicenda
protocolli e quindi forse tu solo
costruire tutte le applicazioni per sempre
parla ogni versione di ogni protocollo
hanno mai parlato che potresti farlo
potrebbe essere un approccio costoso
può costruire protocolli che sono in avanti
compatibile in modo da ignorare qualsiasi imprevisto
elementi questo è un buon approccio e tu
può farlo negoziando esplicitamente cosa
versioni di protocollo che accetterete
pensare a qualcosa come HTTP
negoziazione dei contenuti in cui ti trovi
tipi di media personalizzati che rappresentano
con versione
formati delle vostre rappresentazioni e poi
puoi dire che accetto la versione 1 e 1
uno e uno due e poi il server dice
Sono felice di darti anche io, ma lo sono
non ti darò uno o uno I
non farlo più
un altro problema molto importante con zero
le distribuzioni dei tempi di fermo sono disaccoppiate
architettura ho intenzione di parlare di
questo più un po ‘dopo, quindi io
contenditi se facciamo queste cose tu sai
scegli un meccanismo di distribuzione sicuro scegli a
meccanismo di assemblaggio sicuro creare un costruito
gasdotto che ti dà una visibilità
può effettivamente ridurre la probabilità di
errore a qualcosa di abbastanza basso, ma ciò che noi
cosa possiamo fare per il costo di un
evento per evento intendo che ne conosci qualcuno
tipo di downtime o crash o cattivo utente
esperienza questo è dove diventa un po ‘
interessante quando parli con persone che
non avere un tipo di rischio quantitativo
approccio perché iniziano a parlare
su tutti i tipi di scenari e vedi
questa strana specie di gioia nei loro occhi
stanno parlando di come sai
sulla prima pagina del giornale e
essere chiamato di fronte al tuo
corpo legislativo a testimoniare sul perché
hanno fatto trapelare la carta di credito di tutti
numeri o informazioni sulla salute o questo
tipo di cosa e hanno questo
sorta di voi sa la gioia apocalittica come
stanno parlando di queste cose che ho avuto
un capo in un lavoro passato a cui si riferiva
questo come non sarebbe orribile se
scenari con il Whydah è gente
amo parlare di se è nel
allo stesso modo amano parlare di film
le minacce di trama, naturalmente, non è un
approccio razionale se ti stai impegnando
wiggies quindi il costo di ogni evento è
diritto illimitato perché non puoi
immagina un limite a quanto potrebbero fare le cose cattive
ottenere e, naturalmente, se il costo di un
l’evento è illimitato quindi le cose voi
dovrebbe fare per evitare che sia essenzialmente
senza limiti e finirai per finire
con 80 persone nella sala conferenze
e al telefono facendo distribuzioni per
24 ore il vero costo di un evento è questo
è limitato è limitato da cui si aggiunge
diversi fattori hai perdite dirette
quindi entrate e costi sostenuti durante il
evento avete un po ‘indiretto
perdite perdita di reputazione del marchio è un
perdita indiretta il costo del lavoro delle persone
mentre stanno rispondendo all’evento
invece di costruire la prossima grande cosa
questa è una perdita ma possiamo aggiungere tutto questo
possiamo misurarli e possiamo lavorare
per minimizzarli , diamo un’occhiata a come
farlo il primo miglior modo fine a
minimizzare il costo di un evento è solo per
minimizzare il tempo per rilevarlo in modo M T TD
MT TD è il tempo medio per rilevare il
evento ed è incredibilmente alto in molti
casi quindi ho visto sistemi in cui le persone
stanno facendo transazioni sintetiche così
hai qualche servizio che hai firmato
con quello corre carico contro il tuo sito
ed eseguono una transazione una volta ogni 5
minuti ma quella transazione sono
la corsa passa attraverso un sistema di bilanciamento del carico e
viene indirizzato a una delle n macchine
che hai così la prima volta
supponi di aver messo fuori un server cattivo
fuori da una piscina la prima volta
transazione sintetica potrebbe accadere
non ha colpito il server cattivo e in realtà una volta
alla fine colpiscono il server cattivo
di solito riprovano un paio di volte
prima che dica si, è un vero problema
non solo un problema di rete transitoria o
mancata risoluzione del DNS o qualcosa del genere
questo e così con il monitoraggio sintetico
il tuo tempo medio per rilevare è di solito attivo
l’ ordine di 15 minuti o più che è
tipo di sistemi lunghi con cui ho a che fare
se stai usando qualcosa come utente reale
monitorare dove stai guardando il traffico
venendo da fuori e tu sei
guardando gli effetti di quel traffico tu
di solito può vedere l’ evento in un minuto o
meno così il vero monitoraggio degli utenti ti dà
tempo medio migliore per rilevare
possiamo parlare di test diversi
metodi e vedere che cosa frattempo
rilevare un problema con il diverso
metodi di prova è così faccio test unitari
Penso che sia un grande progresso nel nostro
professione ma devo dire che non capisco
molta fiducia nella validità di
il mio sistema solo sulla base di unità di test è
mi dice una certa quantità ma non è così
dimmi che in realtà funzionerà
produzione quindi ho relativamente basso
fiducia nella sua validità ma è molto
veloce per rilevare le cose così hanno i test unitari
alcuni test di integrazione di utilità
posso correre un bel po ‘ più a lungo
di solito esegue test unitari in una questione di
secondi i miei test di integrazione ne richiedono alcuni
minuti a mezz’ora o qualcosa del genere
così mi danno di più
fiducia nel risultato a volte noi
fare questo test di accettazione utente dove noi
in realtà mettere il sistema di fronte ad alcuni
degli sponsor o degli stakeholder e
si suppone di essere l’ultimo passo
approvazione per assicurarsi che funzioni effettivamente
questo richiede molto tempo e io no
penso che in realtà aggiunge molta fiducia
quello che normalmente vedo nell’accettazione dell’utente
il test è un tipo molto superficiale di te
conoscere
fare clic su un’occhiata a poche pagine sì
va bene, non ti vedo vero
test approfonditi approfonditi di un metodo
quello che dà risultati piuttosto buoni è
questo monitoraggio utente reale e così io
sicuramente difendere la misurazione di tutto
i tuoi utenti lo stanno creando e
trova i grafici che contano per te
ambiente nel tuo business Mike
Brittain farà un discorso a
Poco dopo viene da un’azienda
chiamato Etsy che ha scritto sul blog
culto dei grafici e quindi ho preso in prestito
attribuire alcuni dei loro grafici di esempio
quindi questo è un grafico che mostra tecniche
metriche e solo a colpo d’occhio si può vedere
è successo qualcosa di molto strano
immediatamente dopo la distribuzione del codice e il
il numero di avvertimenti PHP è aumentato
un altro rilascio di codice è uscito e il
gli avvertimenti sono tornati indietro
questo è un grande esempio di rilevamento di a
problema e correggerlo abbastanza rapidamente
quindi vorrei scommettere che il tempo
per rilevare era dell’ordine di cinque a
dieci minuti e il tempo di correggere era
da cinque a dieci minuti questo grafico mostrerà
hai problemi prima di qualcuno in una chiamata
il centro riceverà una chiamata e in realtà modo
prima del monitoraggio sintetico delle transazioni
ti mostrerà un problema, eccone un altro
grafico che hanno questo mostra
alcune metriche che sono forse più di
interessi sul lato business, nonché
e di nuovo puoi vedere molto chiaramente
qualcosa di strano sta succedendo nel mezzo di
la notte lì e quindi questo tipo di
la visibilità mostra errori più velocemente di
qualsiasi altra cosa è molto facile da configurare
tracciare e tracciare tutto ciò che prendi
il tuo server con la tua pila di roba te
aggiungere alcuni software open-source come le statistiche
D fai un po ‘ di interno
monitorando invii tutto in grafite
e poi puoi uscire dai tuoi cruscotti
e grafici e radiatori di informazione su
il muro e tutto comincia guardando
quelle cose
c’è una cautela che è la prima
tempo che rendi visibile qualcosa lo farà
probabilmente sembra orribile perché se tu
Non ho guardato prima
cose strane si sono insinuate e questo
probabilmente significa che i tuoi superiori
stanno andando a guardare e andare che
sembra davvero strano spiegare che
a me e quindi ti verrà chiesto di spiegare
un sacco di cose che vanno via velocemente
non lasciarti spaventare dal fare
questo si può fondere in esterno
monitoraggio con questo e alimentarlo in
lo stesso sistema e tutto ciò che ho
rappresentato qui è approssimativamente a
vale la pena lavorare giorno per giorno, è davvero facile
per andare avanti con questa roba il prossimo
passo nel minimizzare il costo di un evento
sta riducendo il tempo per correggerlo o
il tempo medio di recupero
se stai guardando il momento medio per
il recupero viene da pochi posti
prima devi capire cosa c’è
succedendo a volte questo è il più veloce
parte lo guardi e tu istantaneamente
sai cosa sta succedendo non conosci ordini
vengono posizionati a volte ci vuole un
mentre più tempo ho avuto il tempo di determinare
il problema misurato in settimane in alcuni
casi ma per fortuna che era molto
problema intermittente non era un enorme
problema di crisi che sicuramente risolve il problema
problema e la distribuzione di una correzione sono parti di
nel frattempo anche per riprendersi
in grado di apportare rapidamente il cambiamento e ottenere
il cambiamento implementato rapidamente ti aiuterà
ridurre il costo della manifestazione penso che un
area che non guardiamo abbastanza è come
per ridurre lo scopo di un evento ora tu
ricorda quando ho parlato del canarino
pool ho detto che gli utenti che hai
colpire il pool di canarino sono quelli
sperimentando bene il problema è così
una piccola parte dei tuoi utenti così tu
può considerarlo come una specie della portata di
quell’evento se succede qualcosa di brutto
così possiamo chiedere quanti utenti ci sono
andando a vedere l’errore split testing
come il canarino o solo un essere
le funzionalità di test sono un modo per ridurre
lo scopo dell’errore possiamo anche
ridurre l’ambito dell’errore con a
lancio scuro dove sono le uniche persone
esposti al problema sono una specie di nostro
possedere persone, amici e familiari e
persone all’interno della nostra cerchia di fiducia
Immagino che le feature flag siano un modo per farlo
ridurre anche l’ambito dell’errore
è possibile attivarla su un numero limitato
di macchine e se qualcosa sta andando
sbagliato puoi spegnerlo sullo stesso
macchine molto rapidamente mi piace sempre
avere una specie di telecomando
meccanismo integrato nei miei sistemi, io no
voglio avere un gruppo di amministratori
scrambling a SSH in 20 o 30
scatole diverse e cerca di fare lo stesso
cambio esatto in 20 o 30 scatole diverse
perché si sbagliano almeno
uno di questi e ci vuole solo tempo che
non è che la prima casella verrà corretta?
abbastanza
rapidamente nel momento in cui arriva a 30
casella 5 o 10 o 15 minuti sono passati da I
come qualcosa invece dove posso cadere
un messaggio in coda e canticchia tutto
applicazioni nella mia infrastruttura leggendo da
la fila e facendo la cosa
loro stessi che il messaggio dice loro
fare se sta girando una bandiera e
fuori se sta accettando il carico o
spegnendo e spargendo carica un altro
aspetto del campo di applicazione è quanto lontano è il
errore andare così se ho un errore è
limitato a una singola funzione o è
interessando tutte le mie funzionalità
contemporaneamente è qui che veniamo
torna alla nozione di disaccoppiamento
architettura possiamo usare le paratie per
separare diversi pool di server così
se ho una specie di distribuito
bug che sta causando il blocco di macchine a ciascuno
altro posso avere gruppi diversi
che sono incapaci di chiudersi a vicenda
e posso usare gli interruttori automatici su
evitare che gli errori saltino spazi vuoti nel
sistema su livelli verticali e
propagandosi verso l’esterno da
fornitore di servizi per chiamare il chiamante così a
un paio di esempi di ciò
sarebbe l’ architettura disaccoppiata
questo deriva da un vero progetto client
essenzialmente avevano una grande app lì
c’erano più squadre che lavoravano su
componenti indipendenti ciascuno dei team
controllerebbe il loro codice in e ciascuno di
il codice della squadra era in fase di costruzione in a
modulo ma poi i moduli erano tutti
essere riuniti in un unico grande
file jar in realtà penso che sia stato un orecchio
file ma efficacemente è un barattolo pieno di
vasi e poi quello stesso file era in corso
distribuito su ogni server delle app in parallelo
e sarebbero tutti riavviati bene
questo è l’opposto di un disaccoppiamento
l’architettura possiamo farcela un po ‘
meglio facendo liberare il canarino e
dicendo che ho un po ‘del mio
capacità che ora è il mio pool di canarino e
Sono ancora un po ‘di assemblare le cose le
allo stesso modo, ma in questo caso proprio al
meno che posso
ridurre la portata di chi è interessato
da questo e quindi questo è meglio che sia ancora
non eccezionale ma questo è un passaggio facile
fai e così se sei ancora in quel tipo
di monolitico conosci lo scenario condannato
fai questo passo e poi vai al
il prossimo passo che assomiglia a questo
ora abbiamo preso i moduli in disparte, in
gruppi di strutture correlate e sono
ognuno è schierato nel proprio pool di
i server a questo punto ne posso avere
tipo di bug peloso nella mia
gestione degli account Posso avere questa cosa
chiamare attraverso un sistema di back-end
che esaurisce il suo pool di thread e mai
risponde di nuovo e il peggio che succede
è che io perdo quella gestione dell’account
caratteristiche ma non lo faccio anche contemporaneamente
perdere tutti i thread che rispondono
tutte le altre funzionalità ora un’altra
vantaggio di farlo in questo modo dal
modo come ritraggo qui a destra
è ora che la comunicazione non è
direttamente dall’utente a ciascuno di questi
strutture posso anche iniziare a dire
le singole strutture hanno le proprie
canarino e posso convalidare quelli e
accenderli per una frazione così ho
può fare più versioni di questi
i servizi coesistono per un numero limitato
tempo o per un tempo prolungato se voglio
fare il controllo delle versioni del protocollo in modo semplice
ora una delle cose interessanti è
quando parliamo di disaccoppiati
architetture un particolare gruppo di
Gli sviluppatori diventa molto alti segni sul
architettura disaccoppiata che non tendiamo
dare voti altissimi in qualsiasi altro posto
e questo è lo sviluppatore PHP perché
il loro codice è così concentrato sull’interfaccia utente
non tende ad essere impacchettato
questi artefatti all’interno di artefatti all’interno
artefatti d’arte con questa pila di
dipendenze è relativamente facile da
Spingi solo alcuni file con pochi
linee di cambiamento non c’è un problema di
riavvio di interi server delle app con te
conosco i file jar da 25 megabyte, quindi penso
dobbiamo tagliare gli sviluppatori PHP
rilassare o dare
un po ‘di credito sul disaccoppiamento
architettura area quindi se abbiamo fatto questi
cose che sostengo che abbiamo ridotto
il costo di un evento e ce l’abbiamo fatta
abbastanza basso e credo quando ridurremo
la probabilità dell’errore e noi
ridurre il costo della manifestazione abbiamo una
al quadrato effetto in corso e quindi siamo
aumentando ed eventi in modo lineare ma siamo
riducendo la probabilità e il costo di
un effetto quadrato e quindi dovrebbe vincere
il che significa se facciamo queste cose allora
il poliziotto corre il rischio di continuare
la consegna è inferiore al rischio di fare
consegna in lotti quindi questa è la motivazione
dietro molte delle pratiche che abbiamo
ho parlato di prima oggi
parleremo attraverso il resto di
oggi e di cui abbiamo parlato in
le iterazioni precedenti di questa traccia lì
sono alcuni problemi irrisolti che farò
menzionare molto brevemente queste sono aree
dove stiamo cercando i contributi
stiamo cercando persone da capire
l’innovazione che risolverà questi
i problemi uno dei più grandi è la biblioteca
dipendenze quindi se ne stai usando
una specie di strumento di costruzione che entra in gioco
librerie da luoghi casuali intorno al
al netto di Maven centrale hai un rischio
esposizione a tutto ciò che accade con
Maven centrale lavoro in chiusura ed è
comune a utilizzare questo servizio chiamato
chiusure per chiusure di tappi di chiusura ha
nessuna autenticazione che tu sia in realtà
il proprietario di un progetto ne puoi rivendicare
progetto che ti piace e inizia a caricare
codice questo per me sembra piuttosto rischioso così noi
non voglio semplicemente dipendere da tutto il
biblioteche casuali là fuori probabilmente
voglio gestire i nostri repository con
le librerie di cui ci fidiamo ma ora di
Certo che dobbiamo gestirlo
repository di librerie e continuate così
ad oggi
quindi considero questo un problema irrisolto
dipendenze di servizio e protocollo che abbiamo
ottenuto alcune risposte nessuna delle risposte sono
perfetto quindi ancora di più da fare lì
e se qualcuno è in un’organizzazione dove
hai a che fare con i processi ITIL
non c’è niente nella definizione di
iTel che è incompatibile con continuo
consegna ma l’implementazione di ITIL
in molte organizzazioni è incompatibile
con consegna continua quindi anche questo è
un problema irrisolto se sei in tale
un’organizzazione che mi piacerebbe parlare con te
ad un certo punto più tardi oggi così con
che ti lascerò con qualche domanda
pensare a
chiediti come faresti le cose
diversamente se tu potessi ricostruire il tuo
ambienti in questo modo se non siete
facendo questo già ti ho dato molti
diversi piccoli passi che puoi fare e
alcuni grandi obiettivi su cui puntare
il più piccolo cambiamento che potresti fare
che avrebbe preso un passo del cammino
lì e poi pensare una seconda volta
perché di solito quando proviamo a pensare
il più piccolo cambiamento che realmente pensiamo
qualcosa di molto più grande del più piccolo
possibile cambio e se ci sono manuali
le cose che stai facendo ne trovano solo una
cosa che puoi automatizzare e spostare
in quella direzione sono sicuro che ci sia almeno
una cosa che potresti automatizzare
non hai fatto finora e
saranno le barriere organizzative
Lì abbiamo sentito parlare di Josh
le persone cambiano e la cultura cambia
quindi pensa ai modi in cui puoi iniziare
per iniziare alcuni di questi cambiamenti e questo
di solito non inizia dicendo a qualcuno
altro che hanno bisogno di cambiare
questo è un anti-modello, quindi alla fine ho solo
voglio dire che non dobbiamo sostenere
o consentire che questo tipo di cosa accada
più se hai un esercito di dispiegamento in
la tua compagnia in qualche posto manda queste persone
casa è una perdita di tempo è uno spreco
delle risorse è uno spreco di umanità per
fare qualcosa che i computer potrebbero fare noi
può fare meglio di questo e quindi cerchiamo di
lasciamo che queste persone dormano
perché sembra che sia circa 1:00 in
la mattina lì ti ringrazio
tu
rilevanza e autore della pubblicazione del libro
e ti parlerò questo
pomeriggio sull’esercito implementazione e
perché dovremmo sbarazzarci di loro quello che io
significa che un esercito di dispiegamento è qualcosa
come questo questa è una foto che a
inviato un mio amico da un ex cliente
ora quello che vedi qui è una conferenza
stanza con circa 40 persone nel
sala conferenze alcuni di loro sono dietro
la fotocamera da qualche parte di fronte al
fotocamera oltre alle persone nel
sala conferenze
c’è un telefono Polycom aperto a
ponte delle conferenze con circa un uguale
numero di persone al telefono come lì
sono nella stanza a cui è iniziato questo spiegamento
4:00 nel pomeriggio
in realtà è iniziato un po ‘ prima
che quando hanno mandato via alcune delle loro persone
casa a fare il pisolino in modo che potessero prendere il
spostamento in ritardo perché questo schieramento funzionerà
continuare fino alle 4:00 del mattino alcuni
dei passi notevoli durante questo
l’implementazione prevede il test del fumo da parte di
utenti aziendali alle 1:00 del mattino
dove hanno script di istruzioni
che dovrebbero fare clic intorno
il sito e assicurati che sia tutto
funziona bene e ovviamente puoi farlo
immagina che alle 1:00 del mattino no
tutti sono alla loro massima attenzione e
quindi alcune delle persone che eseguono alcuni di
gli script riportano errori casuali
non sono in realtà errori ma i nostri conosciuti
condizioni da anni fa alcune persone
fare clic in modo errato e segnalare errori
sono i propri errori non l’applicazione
gli errori si tratta di un processo molto rumoroso
coinvolge un sacco di persone in effetti loro
avere così tante persone che hanno dei passaggi
nel piano per chi inviare per ottenere
cibo in vari punti nella notte e
hanno aggiunto passaggi nel piano come tempo
è passato per assicurarsi che qualcuno
svuota i bidoni della spazzatura da tutto il
contenitori dal cibo che portano
questo è per nutrire tutte queste persone
l’ esercito di dispiegamento è notevolmente
struttura persistente è anche un
anti-modello si sviluppa a causa di questo
credono questa profezia che si autoavvera
la profezia che si autoavvera dice
abbiamo il rischio creato da questi grandi
rilasci poco frequenti di una certa quantità di
codice o inventario sconosciuto che è in corso
schierato e questo rischio produce
situazioni minacciose che minacciano di
il business e minacciando di
individui che vengono incolpati se le cose
non andare bene durante la distribuzione
hanno una radicata risposta a questo
ambiente ambiguo o incerto è quello di
applicare le persone ad esso e così hanno questo
credenza che l’ esercito di dispiegamento sia il
il modo migliore per reagire a situazioni sconosciute
ora è una profezia che si autoavvera
perché gli umani sono bravi a reagire
situazioni sconosciute o nuove molto meglio
di automazione o script in realtà ma
perché questo esercito di dispiegamento è lì
è un processo molto costoso che puoi
immagina se abbiamo circa 80 anni
le persone trascorrono quasi un periodo di 24 ore
facendo questi schieramenti quando entro
e dire che dovresti fare
schieramenti una volta alla settimana invece di una volta
ogni trimestre mi guardano
come se fossi pazzo perché dato loro
contesto sarebbe pazzo dirti
dovrebbe farlo ogni settimana, ma così in alto
il costo di implementazione si rafforza effettivamente
questo intero ciclo l’alto costo di
spiegamento significa che fai meno frequente
rilascia e meno frequente il
il rilascio è il più grande sarà
e quindi il più rischioso e altro ancora
minacciando sta andando a creare
più bisogno di più umani in modo da poter vedere
come questa spirale funziona alla fine è
produce la paralisi se fai questo
loop abbastanza spesso si raggiunge un punto
dove non si può aggiungere qualsiasi più la gente si
sviluppare un libro di esercizi che conosci un
Foglio di calcolo Excel stampato così spesso
alla fine hai appena colpito il punto in cui
è impossibile aggiungere più a questo
processo e ti senti come non si può prendere
niente lontano da questo processo e poi
sei bloccato ho intenzione di parlare di
cosa possiamo fare al riguardo, non sono tutto te stesso
conosciamo il pessimismo e l’ oscurità e condanniamo noi
ci sono alcune soluzioni ma prima io
voglio vedere perché questa situazione arriva
in primo luogo perché persiste
e perché le persone percepiscono un conflitto ora
Sono un credente nella Teoria di
Vincoli e nella teoria di
Vincoli c’è questo strumento chiamato il
evaporando nuvola è un grande nome
i tuoi problemi semplicemente evaporano l’idea
è che si tenta di identificare la radice
causa di un conflitto basato su conflitti
ipotesi piuttosto che reali conflittuali
imperativi e così il conflitto che siamo
andando a guardare qui sta raggiungendo
successo finanziario nella vostra compagnia
un ramo di questa nuvola abbiamo un’idea
che vogliamo i benefici di essere agili
e vogliamo l’integrazione continua tutto
la strada verso la produzione che è
di cosa siamo qui per parlare di questo
ciò erogazione continua è tutto
quello è il cheerleading che abbiamo fatto
e ne abbiamo sentito parlare per un bel po ‘
il tempo e quel ramo sembra qualcosa
come questo
il successo finanziario è prodotto dall’alto
velocità e cicli brevi che significa noi
bisogno di fare più spiegazioni ma c’è
un altro ramo di questa nuvola che dice
il successo finanziario è raggiunto da
evitando perdite da bug di downtime
problemi con il marchio di conformità legale
perdita della reputazione del marchio e così via e
lungo quel ramo della finanziaria
percorso di successo
vediamo abbiamo bisogno di ridurre il rischio che
significa che dovremmo fare di meno
schieramenti bene quando mettiamo questi due
rami insieme vediamo il conflitto che
sembra che abbiamo due cose che noi
sia bisogno o che abbiamo bisogno di tutti e due
per produrre successo finanziario, sostengo
che questo non è in realtà un inerente
conflitto non abbiamo bisogno di entrambi
implementazioni e meno dispiegamenti noi
bisogno di guardare queste ipotesi su
basso rischio e alto rischio e così siamo
andando a farlo quando parliamo di rischio
alcune persone usano una ruota molto cappa
definizione del rischio di rischio significa che c’è un
possibilità che qualcosa di brutto sta andando
capita il rischio significa che mi sento nervoso o
il rischio scomodo può anche essere solo un
parola spaventa che si butta in a
conversazione il modo in cui alcuni
politici
piace buttarlo in conversazioni
etichetta qualcosa di uno schema rischioso quando tu
solo non voglio che accada ma non hanno
altro argomento contro di esso stiamo andando a
utilizzare una definizione di rischio più sfumata
stiamo andando diciamo rischio è l’atteso
perdite da eventi indesiderati e I
significa perdite previste nelle statistiche
senso se faccio questo processo abbastanza volte
può mediare le volte che va
male e perdo qualcosa e le volte
che non va male e io no
perdere qualcosa, così raggiungiamo questa nozione di
perdite attese e possiamo vederlo
come la nostra esposizione al rischio di esposizione al rischio è
spesso espresso in termini di annuale
aspettativa di perdita o perdita annuale
l’aspettativa è utilizzata nei mercati attuariali
come l’assicurazione sulla vita e l’assicurazione sanitaria
è usato nella gestione della sicurezza per
Sicurezza IT e arrivare al
aspettativa di perdita abbiamo fondamentalmente eseguito un piccolo
equazione che dice che abbiamo un numero di
eventi in cui una perdita potrebbe verificarsi noi
avere una probabilità di uno di quelli
gli eventi sono errati e quindi producono
la perdita e abbiamo un costo ogni volta
uno di quegli eventi si verifica così il
numero di eventi moltiplicato per la probabilità
volte il costo che ci dà il nostro
perdite attese questo è utile
definizione del rischio perché se lo abbiamo
perdite previste in qualche tipo di economia
termini quindi possiamo decidere prima di tutto
come possiamo minimizzarlo e in modo più cruciale
è la perdita in realtà più grande del
guadagni che potremmo ottenere facendo
qualcos’altro in cui gli umani sono molto cattivi
processo decisionale economico su un intuitivo
base e abbiamo studiato dopo lo studio
questo mostra ciò che tendiamo ad essere
la perdita è contraria se chiedi a qualcuno se
scommetteranno una possibilità di 50/50 di
vincere un milione di dollari o aggrapparsi a
centomila dollari che terrò
su quello che hanno ottenuto piuttosto che
cogliere l’ occasione anche se
matematicamente dovrebbero prendere il
opportunità
quindi se presentate semplicemente le persone in perdita
cercherà di evitare ogni volta la perdita
ma se presenti la perdita e tu
presenta il guadagno disponibile allora hai
una possibilità di prendere una decisione razionale
dopo un sacco di incontri e un sacco di
argomenti e prove da altri luoghi
e così via facciamo un esempio di questo
tipo di un calcolo dell’esposizione facciamo
Supponiamo che io gestisca un sito di vendita al dettaglio e io
ho una specie di bug nel mio checkout
processo ho un sacco di checkout per
anno qualcosa come sapete 10 alla
Dal 6 all’8 non riesco a leggere
più 10 all’8 quindi abbiamo molto
di cassa in corso all’anno ma è così
non è un bug molto comune è qualcosa
ciò accade solo una volta tanto e così
le probabilità che si verifichi sono piccole
abbiamo un gran numero di eventi e il
il costo di ciascuno di quegli eventi è
praticamente qualunque cosa sia nel carrello e noi
posso dire che c’è un valore medio di a
il carrello lo chiama forse 25 euro
e posso moltiplicare tutti questi insieme
e dire quanto dovrei essere disposto a
pagare per risolvere questo bug quanto sto andando
perdere su questo particolare bug all’anno
Funziona a circa cento e
trentuno euro all’anno, quindi quanto
dovrei essere disposto a pagare per risolvere questo problema
bug bene se il sistema sta per vivere
per un anno dovrei essere disposto a pagare
solo fino a centotrenta euro
per correggere il bug
altrimenti pagherò di più per correggere il bug
di quanto sto perdendo dal bug se il mio
sistema ha una vita di design di cinque anni
dovrebbe essere disposto a pagare circa 650 euro
per correggere l’errore perché lo salverò
molto oltre i cinque anni del sistema
e se ho una vita di 10 anni e così via
su di te puoi calcolare le perdite attese
da questo insetto nel tempo e poi equilibrio
contro quello che costa compensarlo
quindi questo è un esempio di come trattare con a
piccolo e relativamente frequente
evento che si verifica in modo tale questi checkout
capita tutto il tempo il costo di ciascuno
è relativamente piccolo
ci sono metodi simili per trattare
con gli scenari orribili davvero grandi
quindi ci sono persone che passano le loro
tempo a pensare a cose meravigliose
come se costasse un asteroide
colpire la terra mi piace leggere questi su
la spiaggia durante il periodo estivo
il libro che posso raccomandare è chiamato
quantificare e controllare catastrofici
rischia che il metodo non sia dissimile
la parte difficile è ottenere dati perché noi
non hanno molti impatti di asteroidi per
anno per misurare e misurare il costo di
loro e ci aspettiamo che quando lo fanno
succederà che sarà molto costoso
l’autore di questo quando John Garrick
ha fatto anche una meravigliosa analisi sul
impatto attuariale della guerra nucleare quindi forse
lo vorrai per la tua estate
trattare quando parliamo di rischio e
perdita possiamo iniziare a raggruppare il rischio in
un paio di categorie è una di queste
rischio di conformità quindi questo dice che c’è
qualche regolamento o qualche legge o alcuni
ente del settore e se non sono conforme
con esso possono imporre multe contro di me
l’altro tipo è il rischio tecnico
più come l’insetto e controlla dove
Sto producendo le perdite da solo
il rischio di conformità è difficile da gestire
con
tende ad essere specifico del settore e se
sei in una di queste industrie con a
molto regolamento sei probabilmente
trattare con organismi di approvazione di terze parti
agenzie di prova e simili e
ci sono alcune cose che puoi fare
consegnare in un ambiente di certificazione
e tu puoi consegnare continuamente in a
ambiente di certificazione e quindi ottenere
certificato una volta l’anno o qualsiasi altra cosa
frequenza che l’agenzia di certificazione
ti consente di assicurarti di passare
sulla tua prima volta attraverso il
certificazione ma probabilmente è su
tutto quello che posso dire sul rischio di conformità
è semplicemente un attrito nel tuo processo
che devi affrontare posso dire a
molto di più sul rischio tecnico
perché questo è molto di più sotto il nostro
controllo e così è dove sto andando
passare il resto della sessione
messa a fuoco
quando gestiamo il nostro rischio tecnico
siamo particolarmente legati alla consegna
penserò alla nostra equazione di Ellie e
guarda come ognuna di queste variabili è
influenzato da fare la consegna continua così
il numero di eventi sta andando a
aumentare è un dato di fatto
quello che faremo in realtà ciò che noi
voglio raggiungere vogliamo il numero di
eventi per salire in modo che possiamo lavorare su
diminuendo la probabilità di un errore
e diminuendo il costo in caso di errore
si verifica e questo è dove dobbiamo
attenzione quindi ho un piccolo confronto
grafico che torneremo a e
rivisitare un paio di volte vogliamo essere sicuri
che la diminuzione della probabilità di
errore e il costo di un errore è grande
abbastanza per compensare l’aumento del
numero di eventi che stiamo per essere
facendo e quindi diamo un’occhiata a dove il
le probabilità di errori vengono da e
vediamo cosa possiamo fare con ciò certamente
i difetti nel codice sono uno di loro ma
non è l’unico posto che puoi ottenere
errori perché il codice può essere tutto a posto
e i tuoi test unitari possono passare, ma poi
quando metti tutto insieme e tu
spingerlo fuori nell’ambiente
forse le cose non funzionano là fuori così
sarebbe un errore nel montaggio di te
lasciato le tue configurazioni di sviluppo nel
pacchetto che hai messo in produzione e
quindi stai provando a connetterti a un
database di sviluppo che non lo è
accessibile dalla produzione
ambiente che sarebbe un assemblaggio o
errore di confezionamento si può anche solo avere
un errore nell’esecuzione della modifica e
questo era quando stavo facendo operazioni IT
il tipo più comune di errore che
si è verificato che avessimo qualcosa come 50
per cento di tutte le nostre interruzioni
subito dopo una modifica a
produzione ora
i nostri cambiamenti erano come lo spiegamento
esercito quando tutto era eseguito manualmente
era un amministratore che copiava i comandi
fuori da un playbook e incollandoli dentro
un terminale che è in realtà un bene
pratica la copia e incolla lo sai
a tutti lo stile prendi qualcosa di intelligente
citazioni da Microsoft Word ma la maggior parte di
il tempo di copia e incolla è relativamente
sicuro perché non puoi digitare qualcosa
non si può mettere per sbaglio accidentalmente
nome host appena fuori dall’abitudine della memoria delle dita
i difetti nel codice sono uno di quelli
cose che si accumula nel tempo la
più a lungo vai tra gli schieramenti
più a lungo costruisci l’inventario più
opportunità ci sono per i difetti
codice più testato che hai e possiamo
guarda questo con qualcosa come un
diagramma di flusso continuo a continuo
il diagramma di flusso viene dalla magra
scuola di controllo dei processi e fondamentalmente
che guarda le cose che entrano in un processo
e cose che escono da un processo ma invece
di contare sorta di numero di cose
in corso e avendo la linea ondulata
del genere è sufficiente aggiungere su di una riga
ogni volta che qualcosa entra e tu aggiungi
su un’altra linea ogni volta qualcosa
lascia che assomigli a qualcosa di simile
possiamo vedere qui è la linea rossa
che rappresenta il codice che è stato archiviato
sei stato a conoscenza dell’unità testata e
funzionalità completa ed è fatta per il tuo
la definizione della squadra di fatto aumenta
monotonicamente non ne sottraiamo mai
è un flusso continuo, quindi continuiamo a salire
quello che abbiamo sulla linea nera è
schieramenti quindi niente niente niente
e poi tutto in una volta c’è un grande
implementazione con una battuta di codice che
esce e poi niente niente
niente ancora per un po ‘e poi
un altro colpo di codice si spegne e il
bella cosa di un flusso continuo
diagramma è che si può solo guardare il
distanza verticale tra le due linee
e dire che è il mio inventario accumulato
questo è quanto lavoro in corso ho fatto
costruito che non è ancora uscito e io
credo che l’ inventario accumulato in
codice più o meno linearmente uguale
rischio accumulato nel codice quindi questo è un
diagramma di una distribuzione di gruppo o a
spiegamento puntinato se prendo esattamente
lo stesso flusso di funzioni, quindi il rosso
la linea rimarrà la stessa
ma mi sono appena spostato in una distribuzione quotidiana
dopo un giorno dopo il codice è
controllato nel CFD assomiglia a qualcosa
questo te se sei nella schiena che potresti
nemmeno essere in grado di vedere la quantità di
rischio accumulato tra queste due linee
Non ho fatto nient’altro che cambiare il mio
schierare
frequenza in modo che corrisponda più strettamente al
frequenza di controllare le cose, ma ho
drasticamente ridotto la quantità di
rischio accumulato che è incorporato nel mio
pipeline in qualsiasi momento
il tipo di cosa che otteniamo
aziende come Etsy e Flickr e
SoundCloud e così via che stanno facendo
consegna continua e ottenere il loro
codice là fuori e convalidato in
produzione il più rapidamente possibile
perché la produzione è davvero l’ unica
posto puoi convalidare tutto il tuo codice
un modo per ottenere questo è con il
costruisci un’idea della pipeline che alcuni di voi hanno
probabilmente visto prima se hai letto
il libro di jezza lo hai sicuramente visto
prima che la nozione di una pipeline costruita sia
essenzialmente stai estendendo il tuo
flusso di integrazione continua che è
questo e lo stai facendo raggiungere
fino al tuo ambiente di QA e
alla fine alla tua produzione
ambiente di distribuzione come andate e
applicare test per cose come
requisiti non funzionali in un
la moda automatizzata mentre vai e
hai taggato il tuo albero e accedi e
Misuri ad ogni passo lungo la strada
così quando si fallisce si può dire dove si
fallito e perché e tornare indietro e entrambi
fissare la pipeline in circa la metà dei casi
o correggi il tuo codice in circa la metà dei casi
ora questa è una build abbastanza lunga
pipeline e sembra molto simile
lo faresti manualmente è un buon posto
per iniziare prendendo ciò che il tuo manuale
gli schieramenti sarebbero e solo
traducendoli in una build automatizzata
conduttura mentre migliorate in questo voi
può aggiungere alcune fasi o è possibile rimuovere
alcune fasi si può cambiare il modo in cui
stai assemblando possiamo guardare
riducendo i nostri errori di montaggio costruzione da
applicando alcune pratiche noi
certamente vogliamo test rapidi così otteniamo
feedback subito un’ottima pratica
per ridurre gli errori di costruzione è il
costruire server puliti da una definizione
nel controllo della versione così usando qualcosa
come lo chef burattino o cfengine, così tu
può impegnare tutto il tuo server
definizioni per il controllo della versione e mantenere
quelli in sincronia con i tuoi bisogni
applicazione
sicuramente costruendo l’ applicazione da
controllo della versione invece di costruire da
conosci le buone pratiche del box di sviluppo inquinato
Spero che tutti lo facciano già se
Non che sia un facile primo passo per cominciare io
ancora occasionalmente vedono ambienti
dove le persone stanno promuovendo fonti e
costruire su ciascun ambiente di destinazione questo
introduce un vettore per il cambiamento in questo
l’ambiente di destinazione può avere un
insieme di dipendenze diverso dal tuo
ambiente di produzione o quella
ambienti precedenti in cui le cose hanno
presumibilmente ha funzionato e quindi non lo fai
vuole davvero diverse versioni di
librerie striscianti in differenti
istantanee di file jar e così via
tipo di cosa che si insinua in questo modo
binari una volta e poi promuovendo il
i binari sono una buona pratica e
certamente schierando allo stesso modo
ovunque aiuta ho visto molto
situazioni in cui gli sviluppatori non fanno a
sono schierati sulla propria macchina
semplicemente eseguendo direttamente dal
directory che stanno costruendo
dentro e poi usano qualcosa di simile
Capistrano da schierare in scena
macchina e quindi usano un virtuale
snapshot e implementazione della macchina da raggiungere
produzione e quindi ne stiamo usando tre
diversi meccanismi in tre diversi
ambienti che più o meno massimizzano
l’opportunità di errori di montaggio a
insinuarsi così non vogliamo farlo noi
voglio costruire allo stesso modo e distribuire
allo stesso modo ovunque io lo sappia già
detti test rapidi sono test veloci
abbastanza importante qui, quindi credo veloce
i test sono una pratica essenziale alcuni
i negozi continuano a fare lavori mentre
la costruzione è rotta non difendo
che mi piace avere una testa pulita di
maestro e se è se il capo del maestro
non sta costruendo correttamente non dovresti
essere commettendo nuova funzione che si opera
dovrebbe prima tornare a una build verde
e poi continua il lavoro sulle caratteristiche che puoi
commettere funzionalità di lavoro sui rami ma
la prima priorità sul master è la correzione
maestro come si diventa più avanzato con
le tue build puoi osservare l’applicazione
alcune delle tue linee guida di architettura o
standard nel processo di costruzione stesso così
una cosa che stiamo aumentando
guardare è la gestione delle dipendenze e il
le cose che stiamo tirando dentro sono state
abbastanza comune per noi avere uno sviluppatore
tira dentro un file jar in modo che possa usarne uno
funzione da una classe ma poi quella
file jar porta in tutti i suoi amici su
l’autobus quindi finiamo con uno stack di 40
barattoli a volte includendo l’intero altro
lingue solo perché abbiamo bisogno di uno
cosa per esempio sto lavorando in
chiusura e ho scoperto JRuby nel suo
interezza esisteva in uno dei nostri progetti
perché includeva una dipendenza transitiva
JRuby per la sua shell interattiva alcuni
le organizzazioni sono molto attente
quali licenze permetteranno e così via
è un altro posto dove puoi far rispettare
restrizioni di licenza se si dispone di un
sviluppo e operazioni separati
gruppo è davvero importante da ottenere
operazioni coinvolte nella creazione del
script di implementazione in modo che la stessa società
che ti ho mostrato la foto di al
all’inizio ho trascorso qualcosa come un milione
e mezzo dollari di creazione automatizzata
script di implementazione del gruppo di sviluppo
consegnato la distribuzione automatizzata
sceneggiature che il gruppo operativo ha detto bene
è grandioso ma non ci piace quello strumento
e quindi prenderemo quei copioni
e usarli come specifiche e poi
andremo a scrivere i nostri script
nello strumento che ci piace così questo è un
enorme spreco di denaro e le probabilità di
quelle due cose le due serie di
gli script che fanno esattamente la stessa cosa sono
abbastanza piccolo questo potrebbe essere stato
evitato se avessero ottenuto più buy-in da
ops all’inizio dello sforzo e
ha funzionato direttamente nello strumento che Ops era
alla fine andando a sostenere e di
Certo se non hai ottenuto il
messaggio sulla distribuzione da capo di
il tronco che si estende dalla testa del tronco è a
approccio davvero buono , preferisco la funzionalità
rami come rami di breve durata ma
quindi reintegrare contro il tronco alcuni di
potresti aver visto questo articolo
che parla di avere uno sviluppo
filiale e fusione da master in
sviluppo e distribuzione al di fuori di
lo sviluppo II lo trovò
crea troppe opportunità di errore
le persone fonderanno le cose in
sviluppo perché pensano che sia giusto
sviluppo ma se hai una cultura
quello dice che il padrone è schierabile tutti
otterrà quello per fare questi là
sono alcune cose che dovrai fare
installazione nel tuo ambiente Io sicuramente
pensi di aver bisogno di un repository di pacchetti tu
hai bisogno di un posto dove puoi mettere il tuo
binari che possono essere sicuri che possono
essere checksum possono avere francobolli di versione
non ti mancheranno
bisogno di registrazione per assicurarsi che ne hai bisogno per
buone operazioni comunque e tu ne hai bisogno
metriche per sapere se un cambiamento che tu
fare è dannoso e sapere come rapidamente
possibile se è dannoso e lo sarò
rivisitare l’argomento delle metriche in a
poco tempo
quindi sono errori di imballaggio e di assemblaggio
il prossimo tipo di errore che aumenta
la nostra probabilità di errori è la distribuzione
stesso e quindi guardiamo un po ‘
modi per rendere sicuro il deployment avendo 40
persone che lavorano su un playbook dove
c’è un passo che dice che sai che siamo
andando a chiamare il DBA e dire al DBA
per chiudere e poi faremo
chiama questa altra persona e diglielo
fai quella cosa che è una specie di
l’opposto di rendere le distribuzioni sicure
tipo di PlayBook si evolve perché qualcuno
vuole davvero essere come la NASA e la Missione
Controlla in realtà il miglior tipo di
la distribuzione è quella in cui non è necessario un
stanza piena di persone che riferiscono a ciascuno
altro tutto il tempo
il dispiegamento in realtà dovrebbe essere gentile
di invisibile come nessuno dovrebbe essere
in grado di dire quando succede tranne che da
guardando un grafico quindi ce ne sono alcuni
modelli che hai sentito menzionato
oggi e che forse hai visto
altrove uno di questi è questa nozione di
canarino rilasciando così in questo modello tu
prendi parte della tua capacità e tu
rendilo il pool di test o la piscina sporca
e distribuisci il tuo nuovo software
lì e vedere come si chiama
un canarino dalla vecchia storia di
portando un canarino è minatore di carbone
portando un canarino nel carbone
mio perché se ci fosse un accumulo di
carbonio monossido
canarino sarebbe morto prima dei minatori
quindi l’idea qui è se qualcosa non va
il canarino lo mostra prima e il
utenti che stanno colpendo il pool di canary
prima ho sperimentato il problema, quindi questo è
riducendo il numero di persone esposte a
un problema ma in realtà non lo è
eliminare il problema che devi fare
supponiamo che un certo numero di errori
stanno ancora andando a finire qui così
stiamo parlando di ridurre il
Probabilità di errore ma non possiamo fare
Zero un altro approccio è qualcosa
quel jezz ha scritto di chiamata
Distribuzioni Bluegreen questo è dove tu
hai due piscine di capacità yeah tu
dividerli in nomi arbitrari
piscine blu e verdi per distribuire il tuo nuovo
codice in uno degli ambienti voi
convalidarlo è possibile eseguire alcuni test del fumo
vuoi un po ‘di monitoraggio e misura
su entrambi e poi ad un certo punto tu
passa a usare quello che preferisco
strumento per l’utilizzo è davvero fantastico
nome high-tech e risoluzione delle dipendenze
servizio chiamato DNS a questo punto Verde
diventa il tuo nuovo ambiente di staging e
è l’obiettivo della tua prossima implementazione
se sei in una nuvola questo è ovviamente
molto facile da fare se non sei in alcun
è un tipo di ambiente virtualizzato
sarà un po ‘più duro perché
devi avere una capacità inutilizzata
posa attorno a un altro stile di realizzazione
le distribuzioni sicure utilizzano un virtuale
implementazione basata su computer, quindi in questo caso
hai un server non una macchina di sviluppo a
dev workstation ma un server che è il tuo
dev environment e ad un certo punto te
dì sì questo è buono, lo benedico e tu
creare una macchina virtuale basata su questo
immagine e poi la usi virtuale
macchina da distribuire nel tuo più alto
ambienti il vantaggio chiave qui è
ci sono davvero poche opportunità per
errori da insinuarsi durante la distribuzione
perché non stai cambiando il
macchina essenziale
mentre ti muovi attraverso gli ambienti il
prossimo approccio che puoi usare per fare
implementazioni molto sicuro e prevedibile è
gestione della configurazione basata
schieramenti così in questo scenario che ho
dividere la mia capacità nel controllo
aereo che gestisce l’infrastruttura
e il piano di servizio che in realtà
il lavoro non è molto impegnativo
per finire ancora in questa immagine ma a
un certo punto ho un’immagine di base nel
slide precedente ti stavo mostrando a pieno
applicazione configurata in quella virtuale
macchina in questa diapositiva ho solo il
sistema operativo più una configurazione
client di gestione sa come parlare
a quel server di configurazione e questo è circa
in modo che la macchina di base ottiene
istanziato nel piano di servizio e
la prima cosa che fa è parlare con
il server di configurazione e chiede Chi sono questo
è così che lo chef e il burattino lavorano con il cfengine
funziona anche in questo modo, quindi la macchina chiede
Chi sono io, qual è il mio ruolo, quali sono i miei
configurazioni che scarica quelle
configurazioni estrae i pacchetti dal tuo
repository del pacchetto o dalla config
server e inizia a installare le cose su
se tutto ciò che succede ha successo
segnalando le sue metriche al tuo
server di metriche e ad un certo punto anche questo
ha bisogno di segnalare le sue versioni di
tutto torna al server di configurazione e
è molto importante chiudere il ciclo
qui perché tipo di un fallimento comune
la modalità è una delle tue macchine non ottiene
aggiornato e quindi è effettivamente in esecuzione vecchio
versioni di roba questo è davvero strano
problema da rilevare in produzione e così via
è bene costruire una pagina in ognuno di essi
le tue app che riportano la versione
è in esecuzione e poi raccoglie tutto
quelli sul tuo server di configurazione in modo che tu possa
guardare un semplice report e subito
identifica chiunque stia gestendo un vecchio
versione del software e poi tu
spegnere la macchina e avviare a
nuovo al suo posto
ora per fare una di queste cose
di cui ho appena parlato, tu hai
mettere in atto una sorta di zero
meccanismo di distribuzione dei tempi di inattività perché a
qualche punto nel tempo che avrai
la nuova versione del tuo sistema e il
vecchia versione del tuo sistema vivo
insieme quindi è importante farlo in
un modo strutturato in modo che tu possa gestire
cose come migrazioni di database e te
può dividere le migrazioni del database
in una sequenza di passaggi sicuri in modo che
stai facendo prima operazioni additive
ottieni tutto il tuo codice e
allora fai la sottrattiva o
operazioni restrittive quindi per prima cosa aggiungi
tabelle e aggiungi colonne con una
piccolo cambiamento quindi spingere fuori il codice
con un altro piccolo cambiamento e poi una volta
sei soddisfatto che tutto sia
lavoro
spinga fuori un altro cambiamento che lascia
il codice da solo ma scende tabelle che tu
non servono altre colonne di gocce
non ti serve più
aggiunge eventuali vincoli non nulli che tu
potrebbe voler applicare a quel punto e così via
li fai in fasi mentre lo fai
è molto importante a cui pensi
come le diverse applicazioni e
i servizi si conosceranno a vicenda
protocolli e quindi forse tu solo
costruire tutte le applicazioni per sempre
parla ogni versione di ogni protocollo
hanno mai parlato che potresti farlo
potrebbe essere un approccio costoso
può costruire protocolli che sono in avanti
compatibile in modo da ignorare qualsiasi imprevisto
elementi questo è un buon approccio e tu
può farlo negoziando esplicitamente cosa
versioni di protocollo che accetterete
pensare a qualcosa come HTTP
negoziazione dei contenuti in cui ti trovi
tipi di media personalizzati che rappresentano
con versione
formati delle vostre rappresentazioni e poi
puoi dire che accetto la versione 1 e 1
uno e uno due e poi il server dice
Sono felice di darti anche io, ma lo sono
non ti darò uno o uno I
non farlo più
un altro problema molto importante con zero
le distribuzioni dei tempi di fermo sono disaccoppiate
architettura ho intenzione di parlare di
questo più un po ‘dopo, quindi io
contenditi se facciamo queste cose tu sai
scegli un meccanismo di distribuzione sicuro scegli a
meccanismo di assemblaggio sicuro creare un costruito
gasdotto che ti dà una visibilità
può effettivamente ridurre la probabilità di
errore a qualcosa di abbastanza basso, ma ciò che noi
cosa possiamo fare per il costo di un
evento per evento intendo che ne conosci qualcuno
tipo di downtime o crash o cattivo utente
esperienza questo è dove diventa un po ‘
interessante quando parli con persone che
non avere un tipo di rischio quantitativo
approccio perché iniziano a parlare
su tutti i tipi di scenari e vedi
questa strana specie di gioia nei loro occhi
stanno parlando di come sai
sulla prima pagina del giornale e
essere chiamato di fronte al tuo
corpo legislativo a testimoniare sul perché
hanno fatto trapelare la carta di credito di tutti
numeri o informazioni sulla salute o questo
tipo di cosa e hanno questo
sorta di voi sa la gioia apocalittica come
stanno parlando di queste cose che ho avuto
un capo in un lavoro passato a cui si riferiva
questo come non sarebbe orribile se
scenari con il Whydah è gente
amo parlare di se è nel
allo stesso modo amano parlare di film
le minacce di trama, naturalmente, non è un
approccio razionale se ti stai impegnando
wiggies quindi il costo di ogni evento è
diritto illimitato perché non puoi
immagina un limite a quanto potrebbero fare le cose cattive
ottenere e, naturalmente, se il costo di un
l’evento è illimitato quindi le cose voi
dovrebbe fare per evitare che sia essenzialmente
senza limiti e finirai per finire
con 80 persone nella sala conferenze
e al telefono facendo distribuzioni per
24 ore il vero costo di un evento è questo
è limitato è limitato da cui si aggiunge
diversi fattori hai perdite dirette
quindi entrate e costi sostenuti durante il
evento avete un po ‘indiretto
perdite perdita di reputazione del marchio è un
perdita indiretta il costo del lavoro delle persone
mentre stanno rispondendo all’evento
invece di costruire la prossima grande cosa
questa è una perdita ma possiamo aggiungere tutto questo
possiamo misurarli e possiamo lavorare
per minimizzarli , diamo un’occhiata a come
farlo il primo miglior modo fine a
minimizzare il costo di un evento è solo per
minimizzare il tempo per rilevarlo in modo M T TD
MT TD è il tempo medio per rilevare il
evento ed è incredibilmente alto in molti
casi quindi ho visto sistemi in cui le persone
stanno facendo transazioni sintetiche così
hai qualche servizio che hai firmato
con quello corre carico contro il tuo sito
ed eseguono una transazione una volta ogni 5
minuti ma quella transazione sono
la corsa passa attraverso un sistema di bilanciamento del carico e
viene indirizzato a una delle n macchine
che hai così la prima volta
supponi di aver messo fuori un server cattivo
fuori da una piscina la prima volta
transazione sintetica potrebbe accadere
non ha colpito il server cattivo e in realtà una volta
alla fine colpiscono il server cattivo
di solito riprovano un paio di volte
prima che dica si, è un vero problema
non solo un problema di rete transitoria o
mancata risoluzione del DNS o qualcosa del genere
questo e così con il monitoraggio sintetico
il tuo tempo medio per rilevare è di solito attivo
l’ ordine di 15 minuti o più che è
tipo di sistemi lunghi con cui ho a che fare
se stai usando qualcosa come utente reale
monitorare dove stai guardando il traffico
venendo da fuori e tu sei
guardando gli effetti di quel traffico tu
di solito può vedere l’ evento in un minuto o
meno così il vero monitoraggio degli utenti ti dà
tempo medio migliore per rilevare
possiamo parlare di test diversi
metodi e vedere che cosa frattempo
rilevare un problema con il diverso
metodi di prova è così faccio test unitari
Penso che sia un grande progresso nel nostro
professione ma devo dire che non capisco
molta fiducia nella validità di
il mio sistema solo sulla base di unità di test è
mi dice una certa quantità ma non è così
dimmi che in realtà funzionerà
produzione quindi ho relativamente basso
fiducia nella sua validità ma è molto
veloce per rilevare le cose così hanno i test unitari
alcuni test di integrazione di utilità
posso correre un bel po ‘ più a lungo
di solito esegue test unitari in una questione di
secondi i miei test di integrazione ne richiedono alcuni
minuti a mezz’ora o qualcosa del genere
così mi danno di più
fiducia nel risultato a volte noi
fare questo test di accettazione utente dove noi
in realtà mettere il sistema di fronte ad alcuni
degli sponsor o degli stakeholder e
si suppone di essere l’ultimo passo
approvazione per assicurarsi che funzioni effettivamente
questo richiede molto tempo e io no
penso che in realtà aggiunge molta fiducia
quello che normalmente vedo nell’accettazione dell’utente
il test è un tipo molto superficiale di te
conoscere
fare clic su un’occhiata a poche pagine sì
va bene, non ti vedo vero
test approfonditi approfonditi di un metodo
quello che dà risultati piuttosto buoni è
questo monitoraggio utente reale e così io
sicuramente difendere la misurazione di tutto
i tuoi utenti lo stanno creando e
trova i grafici che contano per te
ambiente nel tuo business Mike
Brittain farà un discorso a
Poco dopo viene da un’azienda
chiamato Etsy che ha scritto sul blog
culto dei grafici e quindi ho preso in prestito
attribuire alcuni dei loro grafici di esempio
quindi questo è un grafico che mostra tecniche
metriche e solo a colpo d’occhio si può vedere
è successo qualcosa di molto strano
immediatamente dopo la distribuzione del codice e il
il numero di avvertimenti PHP è aumentato
un altro rilascio di codice è uscito e il
gli avvertimenti sono tornati indietro
questo è un grande esempio di rilevamento di a
problema e correggerlo abbastanza rapidamente
quindi vorrei scommettere che il tempo
per rilevare era dell’ordine di cinque a
dieci minuti e il tempo di correggere era
da cinque a dieci minuti questo grafico mostrerà
hai problemi prima di qualcuno in una chiamata
il centro riceverà una chiamata e in realtà modo
prima del monitoraggio sintetico delle transazioni
ti mostrerà un problema, eccone un altro
grafico che hanno questo mostra
alcune metriche che sono forse più di
interessi sul lato business, nonché
e di nuovo puoi vedere molto chiaramente
qualcosa di strano sta succedendo nel mezzo di
la notte lì e quindi questo tipo di
la visibilità mostra errori più velocemente di
qualsiasi altra cosa è molto facile da configurare
tracciare e tracciare tutto ciò che prendi
il tuo server con la tua pila di roba te
aggiungere alcuni software open-source come le statistiche
D fai un po ‘ di interno
monitorando invii tutto in grafite
e poi puoi uscire dai tuoi cruscotti
e grafici e radiatori di informazione su
il muro e tutto comincia guardando
quelle cose
c’è una cautela che è la prima
tempo che rendi visibile qualcosa lo farà
probabilmente sembra orribile perché se tu
Non ho guardato prima
cose strane si sono insinuate e questo
probabilmente significa che i tuoi superiori
stanno andando a guardare e andare che
sembra davvero strano spiegare che
a me e quindi ti verrà chiesto di spiegare
un sacco di cose che vanno via velocemente
non lasciarti spaventare dal fare
questo si può fondere in esterno
monitoraggio con questo e alimentarlo in
lo stesso sistema e tutto ciò che ho
rappresentato qui è approssimativamente a
vale la pena lavorare giorno per giorno, è davvero facile
per andare avanti con questa roba il prossimo
passo nel minimizzare il costo di un evento
sta riducendo il tempo per correggerlo o
il tempo medio di recupero
se stai guardando il momento medio per
il recupero viene da pochi posti
prima devi capire cosa c’è
succedendo a volte questo è il più veloce
parte lo guardi e tu istantaneamente
sai cosa sta succedendo non conosci ordini
vengono posizionati a volte ci vuole un
mentre più tempo ho avuto il tempo di determinare
il problema misurato in settimane in alcuni
casi ma per fortuna che era molto
problema intermittente non era un enorme
problema di crisi che sicuramente risolve il problema
problema e la distribuzione di una correzione sono parti di
nel frattempo anche per riprendersi
in grado di apportare rapidamente il cambiamento e ottenere
il cambiamento implementato rapidamente ti aiuterà
ridurre il costo della manifestazione penso che un
area che non guardiamo abbastanza è come
per ridurre lo scopo di un evento ora tu
ricorda quando ho parlato del canarino
pool ho detto che gli utenti che hai
colpire il pool di canarino sono quelli
sperimentando bene il problema è così
una piccola parte dei tuoi utenti così tu
può considerarlo come una specie della portata di
quell’evento se succede qualcosa di brutto
così possiamo chiedere quanti utenti ci sono
andando a vedere l’errore split testing
come il canarino o solo un essere
le funzionalità di test sono un modo per ridurre
lo scopo dell’errore possiamo anche
ridurre l’ambito dell’errore con a
lancio scuro dove sono le uniche persone
esposti al problema sono una specie di nostro
possedere persone, amici e familiari e
persone all’interno della nostra cerchia di fiducia
Immagino che le feature flag siano un modo per farlo
ridurre anche l’ambito dell’errore
è possibile attivarla su un numero limitato
di macchine e se qualcosa sta andando
sbagliato puoi spegnerlo sullo stesso
macchine molto rapidamente mi piace sempre
avere una specie di telecomando
meccanismo integrato nei miei sistemi, io no
voglio avere un gruppo di amministratori
scrambling a SSH in 20 o 30
scatole diverse e cerca di fare lo stesso
cambio esatto in 20 o 30 scatole diverse
perché si sbagliano almeno
uno di questi e ci vuole solo tempo che
non è che la prima casella verrà corretta?
abbastanza
rapidamente nel momento in cui arriva a 30
casella 5 o 10 o 15 minuti sono passati da I
come qualcosa invece dove posso cadere
un messaggio in coda e canticchia tutto
applicazioni nella mia infrastruttura leggendo da
la fila e facendo la cosa
loro stessi che il messaggio dice loro
fare se sta girando una bandiera e
fuori se sta accettando il carico o
spegnendo e spargendo carica un altro
aspetto del campo di applicazione è quanto lontano è il
errore andare così se ho un errore è
limitato a una singola funzione o è
interessando tutte le mie funzionalità
contemporaneamente è qui che veniamo
torna alla nozione di disaccoppiamento
architettura possiamo usare le paratie per
separare diversi pool di server così
se ho una specie di distribuito
bug che sta causando il blocco di macchine a ciascuno
altro posso avere gruppi diversi
che sono incapaci di chiudersi a vicenda
e posso usare gli interruttori automatici su
evitare che gli errori saltino spazi vuoti nel
sistema su livelli verticali e
propagandosi verso l’esterno da
fornitore di servizi per chiamare il chiamante così a
un paio di esempi di ciò
sarebbe l’ architettura disaccoppiata
questo deriva da un vero progetto client
essenzialmente avevano una grande app lì
c’erano più squadre che lavoravano su
componenti indipendenti ciascuno dei team
controllerebbe il loro codice in e ciascuno di
il codice della squadra era in fase di costruzione in a
modulo ma poi i moduli erano tutti
essere riuniti in un unico grande
file jar in realtà penso che sia stato un orecchio
file ma efficacemente è un barattolo pieno di
vasi e poi quello stesso file era in corso
distribuito su ogni server delle app in parallelo
e sarebbero tutti riavviati bene
questo è l’opposto di un disaccoppiamento
l’architettura possiamo farcela un po ‘
meglio facendo liberare il canarino e
dicendo che ho un po ‘del mio
capacità che ora è il mio pool di canarino e
Sono ancora un po ‘di assemblare le cose le
allo stesso modo, ma in questo caso proprio al
meno che posso
ridurre la portata di chi è interessato
da questo e quindi questo è meglio che sia ancora
non eccezionale ma questo è un passaggio facile
fai e così se sei ancora in quel tipo
di monolitico conosci lo scenario condannato
fai questo passo e poi vai al
il prossimo passo che assomiglia a questo
ora abbiamo preso i moduli in disparte, in
gruppi di strutture correlate e sono
ognuno è schierato nel proprio pool di
i server a questo punto ne posso avere
tipo di bug peloso nella mia
gestione degli account Posso avere questa cosa
chiamare attraverso un sistema di back-end
che esaurisce il suo pool di thread e mai
risponde di nuovo e il peggio che succede
è che io perdo quella gestione dell’account
caratteristiche ma non lo faccio anche contemporaneamente
perdere tutti i thread che rispondono
tutte le altre funzionalità ora un’altra
vantaggio di farlo in questo modo dal
modo come ritraggo qui a destra
è ora che la comunicazione non è
direttamente dall’utente a ciascuno di questi
strutture posso anche iniziare a dire
le singole strutture hanno le proprie
canarino e posso convalidare quelli e
accenderli per una frazione così ho
può fare più versioni di questi
i servizi coesistono per un numero limitato
tempo o per un tempo prolungato se voglio
fare il controllo delle versioni del protocollo in modo semplice
ora una delle cose interessanti è
quando parliamo di disaccoppiati
architetture un particolare gruppo di
Gli sviluppatori diventa molto alti segni sul
architettura disaccoppiata che non tendiamo
dare voti altissimi in qualsiasi altro posto
e questo è lo sviluppatore PHP perché
il loro codice è così concentrato sull’interfaccia utente
non tende ad essere impacchettato
questi artefatti all’interno di artefatti all’interno
artefatti d’arte con questa pila di
dipendenze è relativamente facile da
Spingi solo alcuni file con pochi
linee di cambiamento non c’è un problema di
riavvio di interi server delle app con te
conosco i file jar da 25 megabyte, quindi penso
dobbiamo tagliare gli sviluppatori PHP
rilassare o dare
un po ‘di credito sul disaccoppiamento
architettura area quindi se abbiamo fatto questi
cose che sostengo che abbiamo ridotto
il costo di un evento e ce l’abbiamo fatta
abbastanza basso e credo quando ridurremo
la probabilità dell’errore e noi
ridurre il costo della manifestazione abbiamo una
al quadrato effetto in corso e quindi siamo
aumentando ed eventi in modo lineare ma siamo
riducendo la probabilità e il costo di
un effetto quadrato e quindi dovrebbe vincere
il che significa se facciamo queste cose allora
il poliziotto corre il rischio di continuare
la consegna è inferiore al rischio di fare
consegna in lotti quindi questa è la motivazione
dietro molte delle pratiche che abbiamo
ho parlato di prima oggi
parleremo attraverso il resto di
oggi e di cui abbiamo parlato in
le iterazioni precedenti di questa traccia lì
sono alcuni problemi irrisolti che farò
menzionare molto brevemente queste sono aree
dove stiamo cercando i contributi
stiamo cercando persone da capire
l’innovazione che risolverà questi
i problemi uno dei più grandi è la biblioteca
dipendenze quindi se ne stai usando
una specie di strumento di costruzione che entra in gioco
librerie da luoghi casuali intorno al
al netto di Maven centrale hai un rischio
esposizione a tutto ciò che accade con
Maven centrale lavoro in chiusura ed è
comune a utilizzare questo servizio chiamato
chiusure per chiusure di tappi di chiusura ha
nessuna autenticazione che tu sia in realtà
il proprietario di un progetto ne puoi rivendicare
progetto che ti piace e inizia a caricare
codice questo per me sembra piuttosto rischioso così noi
non voglio semplicemente dipendere da tutto il
biblioteche casuali là fuori probabilmente
voglio gestire i nostri repository con
le librerie di cui ci fidiamo ma ora di
Certo che dobbiamo gestirlo
repository di librerie e continuate così
ad oggi
quindi considero questo un problema irrisolto
dipendenze di servizio e protocollo che abbiamo
ottenuto alcune risposte nessuna delle risposte sono
perfetto quindi ancora di più da fare lì
e se qualcuno è in un’organizzazione dove
hai a che fare con i processi ITIL
non c’è niente nella definizione di
iTel che è incompatibile con continuo
consegna ma l’implementazione di ITIL
in molte organizzazioni è incompatibile
con consegna continua quindi anche questo è
un problema irrisolto se sei in tale
un’organizzazione che mi piacerebbe parlare con te
ad un certo punto più tardi oggi così con
che ti lascerò con qualche domanda
pensare a
chiediti come faresti le cose
diversamente se tu potessi ricostruire il tuo
ambienti in questo modo se non siete
facendo questo già ti ho dato molti
diversi piccoli passi che puoi fare e
alcuni grandi obiettivi su cui puntare
il più piccolo cambiamento che potresti fare
che avrebbe preso un passo del cammino
lì e poi pensare una seconda volta
perché di solito quando proviamo a pensare
il più piccolo cambiamento che realmente pensiamo
qualcosa di molto più grande del più piccolo
possibile cambio e se ci sono manuali
le cose che stai facendo ne trovano solo una
cosa che puoi automatizzare e spostare
in quella direzione sono sicuro che ci sia almeno
una cosa che potresti automatizzare
non hai fatto finora e
saranno le barriere organizzative
Lì abbiamo sentito parlare di Josh
le persone cambiano e la cultura cambia
quindi pensa ai modi in cui puoi iniziare
per iniziare alcuni di questi cambiamenti e questo
di solito non inizia dicendo a qualcuno
altro che hanno bisogno di cambiare
questo è un anti-modello, quindi alla fine ho solo
voglio dire che non dobbiamo sostenere
o consentire che questo tipo di cosa accada
più se hai un esercito di dispiegamento in
la tua compagnia in qualche posto manda queste persone
casa è una perdita di tempo è uno spreco
delle risorse è uno spreco di umanità per
fare qualcosa che i computer potrebbero fare noi
può fare meglio di questo e quindi cerchiamo di
lasciamo che queste persone dormano
perché sembra che sia circa 1:00 in
la mattina lì ti ringrazio
tu
Please follow and like us: