quindi DevOps alle 5:00 sono circa le cinque
anni da quando è stato coniato il termine DevOps
e questo è un intervallo interessante di tempo
cinque anni sono circa la metà di un normale
ciclo di adozione quindi normalmente ne occorrono dieci
anni per qualcosa diventare una sorta di
completamente integrato nel modo in cui lavoriamo
e 20 anni per qualcosa da passare
e solo una sorta di presunto un previsto
modo di fare le cose cinque anni è anche
quando tendi a vedere grandi aziende
interessarsi alle idee e forse
diluirli quindi parlerò di a
numero di aspetti di DevOps e cosa
significa essere qui ora vi parlerò di come
siamo arrivati dove siamo ciò che è attuale
stato delle cose e alcune direzioni
guardare al futuro, quindi come abbiamo fatto noi
arrivare qui
DevOps come termine è stato creato nel 2009 a
Infatti è stato creato nel 2009 da un
particolare individuo di nome Patrick
Dubois, al fine di eseguire una conferenza lui
aveva bisogno di un grande nome per la conferenza
e ha deciso di chiamarlo giorni DevOps
e il nome veramente bloccato questa forza
sembra un po ‘ frivolo, ma ha un
lunga tradizione il termine software
l’ingegneria è stata creata per una US Air
Conferenza della forza nel 1968 e così nel suo complesso
il campo è stato inventato da tutto il tessuto
allora e quindi conosci la conferenza
lo sviluppo guidato è sicuramente una cosa
Sarò aperto a procurarmi un quadro
su quello più tardi oggi oggi in termini di
questa presentazione ho molti nomi
di individui a cui fare riferimento e questo
sta cercando di cavalcare l’ equilibrio
tra dare credito dove è il credito
Il nome giusto e sfacciato che sto facendo
prova a non fare così tanto del nome
cadere e davvero dare credito al
innovatori che ci hanno portato dove siamo noi
sono così abbiamo questo termine DevOps
Patrick l’ha creato per una conferenza ma
le idee non hanno iniziato lì le idee
erano tutti
pronto in aria quando ha creato questo
conferenza questi antecedenti si estendono
indietro un bel modo quindi ricordo in
metà degli anni 2000 stavamo parlando di questo
cosa chiamata infrastruttura agile che
è stato ovviamente modellato su un software agile
sviluppo ed era basato sul
idea di estendere il tipo di agilità
e flessibilità si ottiene nella base di codice
nell’infrastruttura stessa eravamo
anche parlando di infrastrutture come
codificare l’idea che lo stato del
le cose che stai costruendo non dovrebbero essere
descritto da un lungo documento che racconta
gli umani come eseguire le procedure perché
gli umani succhiano davvero l’ esecuzione
procedure se hai intenzione di scrivere
tutte le procedure le danno a una shell
script così infrastruttura come il codice era
rimbalzare e anche prima di
che avevamo un ragazzo che promuoveva l’idea di
infrastruttura 2.0 che dovresti prendere
tutte le macchine nella tua infrastruttura
tutto ciò di cui ti occupi e che tratti
è come una grande macchina virtuale che tu
non dovrebbe essere coinvolto nell’assegnazione
risorse per fare lavori che è il lavoro di
qualcosa come un sistema operativo e
quindi avevamo bisogno di questa nozione di
infrastruttura 2.0 che è come un
sistema operativo distribuito tranne che non
uno che Andy Tannenbaum riconoscerebbe
come un sistema operativo ma il
antecedenti vanno ancora più indietro io
in realtà doveva tornare in una sorta di
era pre documenti web per scavare questo
ma cfengine
da un ragazzo di nome Mark Burgess
in realtà creato nel 1993 questo era il
software di automazione originale ops prima
fantoccio prima di chef in realtà prima del
lingue che erano fantoccio e chef
scritto in sono stati creati cfengine era
intorno ed è ancora in giro ed è un
ottimo pezzo di software, quindi quello che sono
cercare di dire è che queste idee non sono venute
dal nulla sono stati in giro per un
molto tempo ma qualcosa li ha fatti gelificare
verso la fine del decennio scorso e ho
pensa la cosa che li ha davvero fatti
gel è stata l’ascesa della virtualizzazione e
la nuvola perché improvvisamente invece di
ottenere nuove macchine una volta ogni tre
anni ci sono stati affrontati con la prospettiva di
ottenere nuove macchine virtuali
una volta al giorno o una volta alla settimana o una volta
ogni sei settimane e quindi tutte le domande
di implementazione e configurazione e
comprendendo davvero la tua configurazione
è salito alla ribalta Mark Burgess colloqui
su questa nozione di rapporti critici
che molti modelli di comportamento sono
determinato quando un rapporto va da
maggiore di 1.0 a meno di 1.0 e in
questo caso il rapporto che siamo
interessato è quanto tempo ha una macchina
vivere contro quanto tempo ci vuole per impostare
così ai vecchi tempi una macchina potrebbe
Prenditi qualche giorno per creare un paio di settimane
procurarsi e vivrebbe per pochi
anni in cui le macchine vivranno per un
pochi anni puoi tollerarlo
livello di ritardo nell’ottenere esso istituito, ma
se inizi a guardare la compressione
quelle vite che ora inizi a ricevere
fino a un punto in cui la durata della vita di
la tua macchina virtuale si sta avvicinando al
stessa durata del tempo necessario per impostare
su e qualcosa esce di colpo
hai molta pressione quando tu
approcci quel valore 1.0 del critico
rapporto che la pressione si allevia nel nostro
mondo di solito sotto forma di più
software e quindi più software qui
improvvisamente abbandonato i tempi di provisioning
dall’ordine dei giorni all’ordine dei minuti
e ho lasciato perdere il tempo di approvvigionamento
ordine di settimane per ordine di minuti e
questo è quando DevOps ha davvero iniziato a farlo
importa quando attraversiamo quella soglia 1.0
sulla configurazione dell’infrastruttura e sulla consegna
ora così ora questo è il mondo che siamo
in un po ‘del mio viaggio e
perché sono qui a parlare con te oggi che ho
stato uno sviluppatore praticamente tutto il mio
carriera tranne che ho avuto questo soggiorno
finita in operazioni per un po ‘che ho avuto
indossare il cercapersone e ho avuto modo svegliati
non solo quando il mio software non ha avuto successo
non quando il software di altre persone non sono riuscito
ho dovuto ripararlo in effetti ero parte di un
società il cui intero piano aziendale era
garantendo la disponibilità di
software che non abbiamo scritto
credimi questo ha senso per VCS
da qualche parte quindi ho fatto quello che qualsiasi sviluppatore
ho scritto codice per rendere più facile il mio lavoro
avevamo un application server che ho scritto a
mazzo di codice in Perl, enorme Perl oo
moduli che potrebbero attirare ogni pezzo
di questi server applicativi e consegnarli
me metriche e apporti modifiche
Ho costruito la struttura del modulo di produzione
in modo che potessimo schierare facilmente e
frequentemente e mantenere le cose invariate
quello che doveva essere permesso permettere
gli sviluppatori di controllare alcune cose e
ops per controllare ciò di cui avevano bisogno
controllo e ho introdotto il controllo della versione
per i nostri configs al tempo questo era un
il controllo della versione idea davvero radicale è
qualcosa che gli sviluppatori usano è a
strumento di programmazione non è uno strumento di amministrazione
come può aiutare l’amministratore ora che ho
ho un altro server per eseguire la versione
server di controllo ma in effetti si scopre
essere piuttosto utile quando qualcosa va
dita dei piedi-up
e puoi guardare indietro e dire di sapere
cosa è successo o cron job è stato disabilitato
perché è stato disabilitato bene così e così è stato
in questo impegno in quel momento e lì
c’erano alcune altre cose che stavo facendo
come se sapessi di restituire segnalazioni di bug
sviluppo con il numero di riga dove
il problema era che stava causando il
perdita di risorse anche se non avevo
accesso al codice sorgente perché l’ ho avuto
accesso a un compilatore D e lo erano
lasciando tutti i simboli quando loro
cose compilate e così durante questo tempo
Ho avuto modo di vedere in prima persona quanto bene il nostro
il software era sopravvissuto in produzione e
Ero scoraggiato per vederlo
la risposta non è stata molto buona
la maggior parte del software che stavo arrivando
in contatto con il QA era passato ed era
sorta di progettato e scritto per passare QA
e così ho avuto questa idea che tu
sai che il QA non è l’obiettivo e noi
in realtà dovrebbe essere a pensare a come
le cose girano in produzione che alla fine di
il progetto di costruzione del software è il
inizio della vita del software
e quindi dovremmo essere in programma per la sua
vivi per un certo periodo di tempo e
costruendo di conseguenza le nostre organizzazioni
quindi l’ ho portato in questo libro
rilasciarlo Ho cercato di pacchetto che fino
e riportarlo nello sviluppo
mondo da dove vengo e quello è
perché sono qui a tenere discorsi come questi
prova e assicurati che tutti apprezziamo
il nostro software è solo molto interessante
in produzione e dovremmo ottenere
è lì meglio, più veloce e più
in modo affidabile, quindi è un po ‘di storia
dove questa roba DevOps è arrivata in giro
Nel 2009 abbiamo faticato a capire
come chiamare questa cosa abbiamo avuto un gruppo
parlando di operazioni web e loro
stavano avendo un piccolo problema
differenziandolo dall’IT tradizionale
operazioni sapevamo che era diverso ma
non riuscivamo a esprimere al
soddisfazione della base ITIL
responsabili delle operazioni abbiamo avuto termini come
alta velocità che viene lanciata dentro e a
conferenza chiamata velocità abbiamo avuto un
infrastrutture jalopies angel ‘ sai
stavamo cercando il giusto
nome c’era un tempo in cui non lo facevamo
avere il nome giusto per il software agile
sviluppo forse qualcuno di voi
ricordare questo momento stavamo parlando
metodi leggeri metodi leggeri
avuto un problema di marketing vai al tuo
manager e dire che questo è un
progetto mission-critical ci penso
dovrebbe usare metodi leggeri e cosa
quindi la parola giusta è la differenza
tra un fulmine e un fulmine
e quando abbiamo ricevuto la parola DevOps
tutti sono andati subito a dire una buona parola
due sillabe rotolano fuori dalla lingua
eccellente ma poi abbiamo dovuto iniziare
discutendo sulla definizione di cosa si tratta
cosa significa che sai se Patrick
aveva fornito una definizione insieme alla sua
agenda della conferenza che sarebbe stata
ottimo ma abbiamo subito iniziato a discutere
su ciò che è DevOps ciò che non lo è
DevOps sono i DevOps che potrebbero essere in questo momento
Non lo so, abbiamo chiamato questo tizio
John Willis che alcune persone sono
riferendosi al Deming di DevOps I
così perché lo fa davvero
a disagio ha condiviso con noi il suo
modello che ha chiamato cultura delle camme
condivisione delle misure di automazione e
sono in questo ordine per molto
motivo importante perché la cultura è il
cosa che dovete ottenere il diritto in primo luogo se
non ho il giusto tipo di cultura no
la quantità di automazione ti porterà davvero
in un
cornice che suona molto bene e molto
i consulenti possono arrivare e dire DevOps
è un cambiamento culturale, il problema è
è una sorta di dichiarazione facile da fare
tutto è cultura
cambia tu inizi a fare qualcosa
diverso hai cambiato la tua cultura
devo dire qual è la cultura di destinazione
che stiamo cercando di cambiare in ordine
per essere significativo e quindi voglio
aiutare ad articolare la cultura DevOps a
un po ‘i valori della cultura DevOps
feedback veloce
hai sentito parlare Adrienne stamattina
piuttosto che misurare le cose in pochi secondi
di minuti in modo da poter ottenere il tuo
applicazione ridistribuita 10 secondi dopo
lo rompi, piuttosto che i 10 minuti
tipo di feedback che abbiamo usato per ottenere circa
i sistemi di produzione sono stati misurati in settimane
sai che faccio un rilascio pubblicando
rilascia note al gruppo ops e
scrivendo un cambio biglietto e un certo numero
di settimane più tardi le cose vanno dentro
produzione e poi lo scopro
getta le eccezioni del puntatore nullo dappertutto
il luogo
DevOps sicuramente valorizza direttamente
connessioni tra collaborando
individui questa è l’antitesi di
il tipo di sistema di ordine di lavoro basato su cue
di solito ci saranno artefatti e
i documenti creati consentono di creare un Kanban
consiglio e stai facendo DevOps ma in realtà
la comunicazione è primaria e il
gli artefatti ci sono per il monitoraggio dopo
il fatto che facciamo un sacco di dati basati
comunicazione non è chi urla il
più forte o chi ha un’opinione su cosa
tecnologia di database da utilizzare o come
l’applicazione dovrebbe essere strutturata
quando possibile abbiamo effettivamente guardiamo
cose come tempi di inattività e tempi di risposta
distribuzioni e diciamo questo prodotto
e questo prodotto funziona grosso modo il
lo stesso possono entrambi soddisfare tutti i controlli di qualità
requisiti ma questo sta per
richiedono tempi di fermo ogni volta che facciamo
fare una versione del software e questo è
non questo richiederà
comunicazione centralizzata e
la governance centralizzata sta andando
per consentire il decentramento e quindi usiamo
come parte del processo decisionale
processo e c’è un interesse
escrescenza di quel tipo di dati basati
comunicazione che ha a che fare con
in coda e l’eliminazione delle code
così ogni volta che hai una comunicazione
modello che richiede centralizzato
controllo e un gatekeeper sei
introducendo ritardi nel tuo processo e
ci piacerebbe sbarazzarci di questo e così parte
dei dati di comunicazione basato è come
lungo ci sta portando da cui partire
check-in per vivere in produzione
collaborazione e lo cerimonia
sai che a tutti piace quello di nessuno
sto per dirti l’ inferno no, non voglio
avere bisogno di quella collaborazione ma a
aspetto davvero importante è questa idea di
abilitazione piuttosto che autoprotezione
Sono stato in un certo numero di operazioni
gruppi che hanno una visione molto debole di
gli sviluppatori che vedono gli sviluppatori e
lo sviluppatore cambia come la fonte di tutti
del loro dolore e così fanno quello che nessuno
avrebbero cercato di proteggersi
da quel dolore erigendo barriere e
assicurandosi che gli sviluppatori non possano ottenere
attraverso la barriera finché non lo dimostrano
che non causeranno dolore
L’ approccio DevOps è assolutamente invertito
da quello in due modi il primo modo
è invertito è quello invece di
building automation che mi permette di fare il mio
parte più veloce che ho intenzione di costruire
automazione che ti dà il potere di
fare quello che facevo e dove ero
andando ad applicare il giudizio e l’analisi e
guarda quello che stavi facendo, lo sono
cercherò di automatizzare quel giudizio
elaborare così ad esempio un punto tipico
di attrito è intorno sequel o schema
le modifiche in un nostro DBBA DBA non vogliono
gli sviluppatori di scrivere il proprio schema
cambia perché fanno cose come
dimentica di indicizzare il bersaglio di un estraneo
rapporto chiave bene puoi avere un DBA
controlla ogni cambio di schema che sta succedendo
attraverso il sistema o puoi avere un
programma che controlla ogni cambiamento dello schema
passare attraverso il sistema che preferirei avere
il programma lo fa perché non la volontà
il programma non dimenticherà qualcosa una sola volta
il problema è qualcosa
come il sequel è in realtà davvero difficile
analizzare in modo affidabile ed esaminare e guardare
per problemi quindi forse faccio qualcosa
come costruire un ambiente dove posso
istanzia automaticamente la corrente
database applica la modifica e quindi
ispezionare i risultati del cambiamento questo
è un tipo di lavoro che le organizzazioni
era riluttante a fare ma è
assolutamente fondamentale per l’idea di
abilitazione un altro modo per risolvere lo stesso
il problema è dire che non specificeremo il nostro
modifiche nel seguito in cui verranno specificate
qualcosa come la base o le rotaie liquide
migrazioni che sono più facili da analizzare e
più facile da ispezionare con strumenti automatici
qualunque sia la soluzione è l’ obiettivo
è lo stesso per far uscire l’umano
il ciclo usa l’umano per applicare
conoscenza e giudizio nella costruzione del
automazione non in esecuzione del processo
ogni giorno o ogni settimana dirò un posto
dove abbiamo un lavoro da fare è con
quello stesso tipo di trasformazione nel
area di sicurezza delle informazioni il nostro InfoSec
gli strumenti oggi sono ancora molto manuali
eseguire uno scanner contro un sistema che viene
torna con 800 pagine e una sicurezza
esperto quando è giù per i tre
problemi che contano davvero o se lo sono
il tuo primo go-around probabilmente il 30 o
40 problemi che contano davvero ma
essenzialmente ogni volta è lo stesso
lo strumento di elaborazione crea un esperto di output di grandi dimensioni
controlla la produzione e scopre cosa
che conta davvero abbiamo avuto modo di cambiare la situazione
al fine di ottenere InfoSec completamente integrato
in DevOps mentre stai guardando questi
punti elenco cultura sei probabilmente
pensando che suonino un po ‘ familiare
sembrano molto simili a questi valori di
semplicità di comunicazione
rispetta il coraggio che puoi riconoscere
come i valori XP originali che è
deliberare è la cultura DevOps
modellato deliberatamente su una cultura agile
e generalmente parlando ad alta velocità
alta cultura della fiducia ora ho menzionato
automazione come secondo punto di John
definizione
quando parliamo di nuovo dell’automazione
c’è un po ‘di diverso
prospettiva sull’automazione un aspetto
di esso è che stiamo andando a utilizzare più leggero
strumenti di peso quanti di voi hanno mai
stato
i soggetti e / o le vittime di qualcosa
come un lancio di HP openview okay
scuse se qualcuno di voi effettivamente funziona
per HP è molto doloroso è molto
costoso e ci vuole molto tempo quindi
cosa succede tre mesi lungo la strada
se dici che openview non è di grande aiuto
noi se hai dati che mostrano i nostri
i tempi di inattività non hanno cambiato la nostra risposta
la distribuzione del tempo è la stessa nostra
la soddisfazione del cliente è la stessa, ma noi
ha investito tutti questi soldi in una vista aperta
beh non puoi strapparlo perché allora
dovresti scriverlo sei gentile
di attaccarci e quindi tendiamo a favorire
strumenti più leggeri e in particolare
strumenti open source perché possiamo adottare
loro e li butta via come i bisogni di
il sistema impone che non siamo obbligati a farlo
il CFO e il reparto contabilità
per mantenere quel software in servizio
abbastanza a lungo da ammortizzarlo completamente
tipicamente automatizzando le cose per accorciare
il tempo del ciclo quindi un sacco di operazioni
automazione nel passato focalizzata sul
ultima parte della richiesta, in altre parole
dovresti presentare una richiesta di modifica e
entrerebbe nel sistema di bigliettazione e
avresti una riunione CR B che lo farebbe
approva o rifiuta la richiesta e dopo di essa
ma ho approvato una finestra cambiamento sarebbe
programmato e quindi l’amministratore si siederebbe
in basso e ci vogliono circa cinque minuti
il lavoro alla fine di due settimane
processo di automatizzazione degli ultimi cinque minuti
di quel processo non fa niente
aiutarti a ciò che vuoi fare è automatizzare
il processo di approvazione e automatizzare il
ritardare e quindi stiamo cercando di
automatizzare in modi che aumentano la velocità
di cambiamento e consentire modifiche più sicure
anche l’automazione nelle operazioni
abbraccia alcuni di questi strumenti di sviluppo
abbiamo degli amministratori
scrivendo codice Ruby anche tu lo sai bene Oh
La libreria Ruby è con test e
tutto ciò che è un bel cambiamento
Adam Jacobs ha parlato di come lo penso
era Adam forse
Jezz o Chris puoi correggermi se lo sono
la mancanza di citazioni ha parlato di come amministratori
effettivamente utilizzare un sacco di diverso
lingue per tutto il tempo che guardano a tutti
i file di configurazione nella directory di etsy
guarda tutti i file di configurazione di Apache
le cose sono lingue per la configurazione
i sistemi e gli amministratori si muovono molto fluidamente
attraverso molti di questi diversi
le lingue semplicemente non la pensano come
lingue così da imparare Rubino come un altro
linguaggio di configurazione in realtà no
quel duro mm-hmm si , non lo so
em per bene parleremo di che
così alla base di tutto questo c’è un cambiamento
enfasi nel gruppo operativo da
automazione per autoconservazione a
automazione per l’abilitazione di altro
persone invece di renderlo più facile
io per spingere il pulsante che ti darò
il pulsante e insieme a quello anche io
devo darti le conseguenze di
premendo il pulsante e questo è quando noi
vieni alla misurazione in modo da sapere se se
Sono quello che si sveglia e io sono il
uno che viene chiamato sul tappeto dal
CIO e mi hanno sgridato letteralmente
visto i manager delle Alpi farsi leganti
lanciato contro di loro attraverso una stanza da un CIO
Mi proteggerò da questo primo
di tutto vado a indossare una visiera
in tutti i miei incontri con il CIO e
Probabilmente lo farò anche io
che non puoi mettermi in quella posizione
beh, il modo più semplice per farlo è
in realtà solo per metterti al corrente
fornire di nuovo un software di qualità
è qualcosa di cui parlava Adrienne
stamattina sta chiudendo un feedback
loop che è stato rotto per più di 10
anni se riesci a creare un problema e
buttalo oltre il muro e io devo
subire le conseguenze di questo problema
due cose accadono prima di tutto
rendere il muro a noleggio e secondo non aver mai
imparare
per smettere di creare problemi ma se tu
crea il problema e tu sei l’unico
chi ottiene il feedback su di esso lo farai
impara come smettere di creare problemi così
quando misuriamo le cose che stiamo andando
allontanarsi da alcune delle idee che dicono
il sistema di misurazione che sai di avere
ne ho uno per gli amministratori e ne abbiamo un altro
uno per gli affari e un altro per
marketing e così via in realtà siamo solo
andando a misurare tutto insieme e
metteremo tutto in un unico sistema
dove puoi correlare qualsiasi cosa con
tutto ciò ha dei pericoli che puoi
facilmente ingannare te stesso con spuria
correlazioni ie8 utenti – riscaldamento globale
o qualcosa del genere c’è un intero
sito web dedicato allo spurio
le correlazioni ora sono cose molto divertenti ma
a volte ci sono interessanti
correlazioni che ti sono davvero utili
voglio abilitare misure ad hoc come
il numero di pizze ordinate da
le squadre di sviluppo perché è così interessante
Non è così il CFO può rendere più
pizza più economica ma si scopre quando si
avere un sacco di team di sviluppo che ordinano pizze
se è fuori orario probabilmente significa
stanno lavorando molto ed è un vantaggio
indicatore del fatturato in modo da trovare
intuizione in luoghi inaspettati quando si
misurare tutto e ho intenzione di venire
torna su questo argomento di informazioni e
l’informazione scorre un po ‘più tardi
la finale dei punti elenco di John era
condividere le informazioni sulla condivisione condividere le risorse
condividere conoscenze che vogliamo davvero ottenere
lontano dall’idea di informazione
accaparramento e cercare di dire alla gente tanto
come vogliono sapere o sono capaci
assimilare perché tutti fanno
decisioni migliori quando sono di più
informato il grande rischio in una crescita e
l’organizzazione complessa è locale
ottimizzazione, facilito il mio lavoro
spingendo il lavoro fuori dai confini dove
cade in crepe tra la mia scatola e
la scatola a monte in modo da sapere cosa
succede che un nuovo lavoro venga creato per essere gestito
cosa cade nelle crepe là e
ora ho tre scatole con due
handoff dove potremmo essere appena stati
parlando un po ‘di più
uno dei più importanti pensatori di sistemi di
il 20 ° secolo si chiamava Donella
Meadows ha scritto molti grandi libri ma
uno dei giornali che mi ha davvero colpito
molto difficile è chiamato punti di leva in a
sistema in cui scrive una gerarchia
di posti di intervenire in un sistema di
apportare modifiche ad esso e deliberare
cambiamenti e talvolta involontari
cambia il modo più debole di fare
le modifiche a un sistema sono con ciò che lei
chiama costanti e parametri questi sono
cose come le aliquote aumentano i bonus
incentivi che altereranno il comportamento ma
quelle modifiche possono facilmente essere
superato da altre cose che non sto andando
per passare attraverso tutti i 12 dei suoi punti
anche se è affascinante leggere quando
entriamo nei cambiamenti di maggiore intensità
o punti di forza di forza più alta noi
prendi alcune cose interessanti così forte
di circuiti di feedback negativi rispetto a
la dimensione dell’effetto che stanno cercando
controlla il guadagno attorno al feedback positivo
cicli relativi alla dimensione dell’effetto
i circuiti di feedback positivi conquistano sempre
loop di feedback negativi se ci stai provando
per guidare un comportamento fuori da un sistema te
può creare un ciclo di feedback negativo ma
stai molto meglio creando un
circuito di feedback positivo per guidare di più
comportamento desiderabile l’indesiderabile
comportamento sarà solo fade out dell’esistenza
quando il desiderabile prende il sopravvento ma
ora guarda questa struttura di
l’informazione scorre quella che trovo
affascinante perché ci occupiamo tutti
informazioni e quindi ne abbiamo molte
controllo su questa particolare leva
punto e se non mi credi metti un
costruisci il tuo monitor al di fuori del tuo ufficio CIO
e scommetto che il numero di falliti
le build vanno giù ora forse il numero di
il totale delle build scende e la dimensione di
i cambiamenti salgono quindi devi essere un
un po ‘ attento a ciò che sveli
ma semplicemente rendendo visibili le informazioni
ovunque farà sì che le persone provino a farlo
cambia queste informazioni per esempio put
un grafico
su un grande display visibile BVD come Alistair
Coburn lo chiama gente che muoverà il cielo
e terra per far risalire quel grafico e
a destra
se è quello che vuoi veramente o
non succederà così tanto
informazioni visibili e le persone agiranno
su di esso e non devi legarlo a
incentivi per gli stipendi di nessuno deve essere acceso
la linea di nessuno bonus non ci sono penalità
rendilo visibile è molto facile
fare questi in questi giorni ottenere un pannello piatto
mostra con un chromecast inserito
lo slot HDMI se non è possibile ottenere il budget
per questo chiedi uno sviluppo in tempo reale
piattaforma di analisi della qualità e andare a comprare a
display a schermo piatto con un chromecast
la stessa cosa sembra migliore con un budget
richiesta mentre stai rivelando questo
informazioni che può essere chiesto per
l’interpretazione di alcune operazioni che le persone non fanno
come dare un’interpretazione ho avuto un
gestore degli ops una volta chi è stato chiesto in a
mattina incontro perché uno del web
la CPU dei server era più alta di tutti
gli altri per il giorno precedente e lui
tap-ballò un po ‘ perché
davvero non ha voluto dire oh, ma che
era la risposta che non sapevamo di aver rimbalzato
Apache e è tornato alla normalità e
quello era buono come risultato di quello che era
necessario per segnalare la CPU media di
i server web ogni giorno alle 6 del mattino quindi
potrebbe andare sul quotidiano scritto a mano
rapporto di attività distribuito a tutti i
manager per due anni ha dovuto alzarsi
salire su una chiamata in conferenza ogni mattina
riporta un numero e poi torna a letto
bene i manager si sono fermati rapidamente
guardando questi numeri e le mie operazioni
manager lo sapeva e così ha fatto quello che chiunque
dicendo farebbe ha iniziato a fare in su
ha preso il numero del giorno precedente
lo aggiustò di qualche percento e lo diede
loro quel numero non era un
ingegneria primaria a scuola per quelli di
tu che ti credi all’idea di te
sapere falsificare i tuoi dati
non avrebbe avuto importanza letteralmente
stato molto meglio insegnare alle persone che il
I numeri di CPU non importavano quello che loro
davvero voluto guardare era il
distribuzione del tempo di risposta perché
questo è ciò che i clienti in realtà
esperto e avrebbe potuto essere riorientato
il focus dell’organizzazione attorno ad un
utile insieme di numeri che avrebbe
diventare una pietra di paragone per tutti da usare
e continua a riferirsi a e guardare
come abbiamo fatto cambiamenti come il marketing
gruppo utilizzando la gestione dei contenuti
sistema per caricare altri due megabyte di
video sulla home page per esempio
invece abbiamo avuto un inutile bit di
informazione che viene messa in un manoscritto
rapporto
quindi la mia massima è che non insegnerai mai
te stesso senza lavoro quando ne fai di più
informazioni visibili insegnano alle persone come reagire
ad esso allontanarsi da nozioni di
incentivi o domande come che proprio
insegnare alle persone questo è ciò che sembra normale
come questo è quello che sembra cattivo
com’è meglio così che tutti
è come muoversi nella stessa direzione
la prossima grande influenza devo parlare
circa è un ragazzo di nome John tutti SpA sorta
di un santo patrono delle operazioni
un individuo calmo, a testa bassa, vorrei
fidatevi di lui in qualsiasi tipo di crisi
situazione, ma ha fatto esplodere le nostre menti indietro
velocità 2009 con un discorso chiamato dieci
distribuisce al giorno su Flickr Flickr era grande
gli uomini è più grande ora e stanno parlando
sull’implementazione del codice dieci volte al giorno
era eretico era radicale quello
numeri aumentati di un ordine di grandezza
ma da allora in poi rifletterò questo
ha mostrato un’intuizione che è venuta dal
comunità agile che se qualcosa fa male
dovresti farlo più spesso
ora questo non è perché gli sviluppatori sono
masochisti ma se lo fai più spesso
tu
migliorando, troverai i modi per farlo
rendono male troverete modi per
automatizzare piuttosto che sorta di Shying
lontano dai medici del dolore lo sanno
molto bene se qualcuno di voi avesse qualche tipo di
chirurgia ti diranno di alzarti e muoverti
sai non sederti intorno andando tutto
ti fa male devi muoverlo per
recuperare è un tipo simile di cosa
con schieramenti se si evita di farlo
le tue implementazioni diventano più rischiose di più
probabile fallire più costoso tutto cattivo
le cose che John ha anche portato in questa idea di
le persone fanno parte del sistema e questo
c’è un aspetto dei fattori umani
le operazioni di psicologia conta c’è
una cosa come un fallimento che induce
sistema questo è uno che è altamente
accoppiati esibisce accoppiamento dinamico
quindi le cose che sono liberamente accoppiate possono
improvvisamente diventano strettamente accoppiati come
disco IO e Ram ti dà ambiguo
o segnali incerti nelle tue letture
e potrebbe avere operatori che non lo fanno
capisci pienamente il sistema che sono
operando tutti questi sono veri per il
tipi di sistemi con cui abbiamo a che fare
un altro importante contributo a questa linea
di pensare è l’umile Jezz di Jay che ci ha dato
questo fantastico libro chiamato continuo
consegna che penso sia un ottimo modo per
introdurre DevOps nella tua azienda è
sulla distribuzione ma si tratta di più
di implementazione è in realtà
integrando il flusso di valore fino in fondo
attraverso l’organizzazione e lo farà
ti porta a DevOps e anche se non lo fai
vai fino in fondo, stai ancora andando
per offrire più valore per unità
tempo di quello che erano prima in modo da avere
questa idea in sviluppo agile di
tipo di integrazione del front end del
stakeholder della linea di sviluppo Dev al QA noi
far lavorare una squadra in una stanza
insieme
DevOps estende tutto il resto
e quindi dovremmo avere un valore unificato
scorrere fino in fondo
e quelli di voi hanno avuto qualche allenamento
e magra riconoscerà questo come ciò che tu
fai in modo che ti concentri sul flusso di valore
fino in fondo e tu integri
quel flusso di valore così qui abbiamo il
fattori che si sono uniti o le idee
che si fondono e creano questo
l’idea di DevOps va bene è stata lunga
lezione di storia fatta con che parliamo
di dove siamo adesso, quindi siamo in cinque
anni e ne abbiamo fatti molti
progresso ma ci sono ancora alcune aree
ho bisogno di un lavoro serio, quindi lo darò
tu il mio tipo di scala di valutazione su a
mucchio di diverse aree e quanto bene
sono stati indirizzati così nel nel
regione di distribuzione che abbiamo fantastico
strumenti ora infatti abbiamo un
imbarazzo di ricchezze nello strumento
spazio abbiamo il venerabile cfengine
abbiamo del sale da cucina fantoccio da cuoco
in realtà ce ne sono di nuovi ogni settimana quindi
per favore non scrivere una nuova distribuzione
sistema ma c’è un posto che siamo
in questo settore manca tutto lo spiegamento
sistemi di tipo di considerare una macchina come il
obiettivo dello spiegamento, ma io sono
in realtà non è interessato a a
macchina più mi interessa a
intera topologia di macchine con parti
correre in posti diversi che tutti
doversi conoscere e connettersi
collaborare non abbiamo davvero molto
lo sta facendo ancora così è quello
perché è un a- invece di un A + quando
stiamo parlando di provisioning che siamo
davvero parlando di farti sapere
metallo nudo e ottenere fino al
punto in cui è pronto per un
dell’applicazione da installare è
in realtà un po ‘più debole di quanto dovrebbe
essere un sacco di grandi organizzazioni hanno
sviluppato il proprio altamente automatizzato
sistemi di approvvigionamento loro
idiosincrasie uno ssin nel modo in cui loro
lavoro che non possono necessariamente essere raccolti
e mettiti da qualche altra parte così abbiamo fatto
ha ancora un po ‘ del vecchio tipo di
standard hardware su pixie e TFTP
abbiamo alcuni strumenti come il ciabattino
seduto in cima
ma sul serio se hai mai provato
usa il ciabattino
non è il fuoco e non dimenticare di nessuno
significa che sii sul provisioning per fortuna
questo è in qualche modo mitigato dal fatto
che probabilmente stai tutti correndo nel
nuvola in ogni caso e in modo da non dover
occuparsi spesso del provisioning
la registrazione è uno dei posti che ha
ho fatto davvero tanti progressi
la registrazione era nel regno di
sicurezza e quindi l’idea è stata scritta una volta
leggi mai hai raccolto tutti i log in
un posto dove nessuno potrebbe mai guardare
a loro o lo sapevi puramente il
dominio degli strumenti commerciali ora abbiamo
sia commerciale che open source
alternative in modo che questo è ottenuto molto
un monitoraggio migliore è diventato molto
meglio così ora abbiamo strumenti fantastici
per una sorta di rappresentazione grafica delle cose dai log in
conosci una latenza di un secondo o di un minuto
la grafite ha ottenuto molta trazione
grande strumento non così grande sul front-end
quindi sono un front-end sostitutivo per
ma è un posto che sta lottando un po ‘
relativo al monitoraggio è conoscerti
so che le cose funzionano, quindi posso raccogliere
tutte le metriche ma ho ancora bisogno del
wetware umana di vedere le cose e mi dicono
è normale o non è normale e
Ti darò un paio di esempi di
dove il rilevamento delle anomalie è ancora un po ‘
non soddisfare davvero i nostri bisogni, quindi abbiamo
ha cose come l’elaborazione di eventi complessi
motori che possono sedersi lì e cercare
sai che l’ evento si verifica e poi l’evento B
o C deve avvenire all’interno di una certa unità di
tempo possono aggregare un mucchio di
eventi in modo da sapere se ogni singolo
il server delle applicazioni si lamenta di no
essere in grado di raggiungere il database
il problema è probabilmente il database non il
server delle applicazioni in modo tale che la parte sia a posto
ma uno dei miei clienti invia un sacco di
messaggi di posta elettronica ogni mattina voglio dire un sacco di
e -mail e in pochi minuti
inizia a vedere gli accessi da persone che fanno clic
nelle e-mail o almeno lo sono
supposto vedere gli accessi così che cosa abbiamo
ecco un modello giornaliero che sembra
abbastanza
niente nulla di enorme picco nulla
niente niente
tranne che dovrebbe essere un enorme picco
sai tra il 20 e il 30 percento di
il numero di e-mail che hanno inviato se
il picco non si verifica
questa è l’anomalia che non abbiamo davvero
strumenti in grado di farlo, ma non c’era
alcuni parlano al monitor AMA sul digitale
elaborazione del segnale e tipo di estrazione
modelli basati sul tempo non siamo ancora arrivati
Penso che i progressi in questo settore stiano andando
venire dall’uso di vecchi modelli da
cibernetica e sistemi di controllo come
qualcosa chiamato filtro Coleman
dove hai un modello fisico di cosa
il sistema dovrebbe fare e stai cercando
per discrepanze tra ciò che il
sistema dovrebbe fare dato un insieme di input
e ciò che effettivamente fa, naturalmente
richiede di costruire quel modello che
può essere un po ‘difficile tenersi aggiornati
con il ritmo del cambiamento nei nostri sistemi
quindi abbiamo ancora alcune sfide lì
e poi c’è quest’area che chiamo
comprensione del sistema o idea che
Dice che sai okay, quindi puoi dirmelo
che una macchina è giù, ma come fa quel
influire sui miei utenti o su come influenza il mio
entrate non abbiamo molto che si collega
attraverso tutti questi strati ancora c’è un
linguaggio di descrizione dell’architettura chiamato
il nostro cue mate che pretende di farlo
ma è come se fosse un profilo UML così tu
può ottenere stencil per la nostra stecca ma
non c’è nulla di eseguibile al riguardo
non può trasformarlo in un sistema di monitoraggio
quindi questo è un altro posto che abbiamo
alcuni progressi per fare uno dei migliori
le cose che stiamo facendo sono intorno a questo
idea di forzare la casualità sul
sistemi per migliorarli così risulta
se fai molte distribuzioni al
consumando servizi un sacco di dispiegamenti
sembra un sacco di fallimenti ogni
la distribuzione sembra un po ‘parziale
fallimento e se questo non è abbastanza abbiamo
ho questa idea della scimmia del caos
Netflix ci ha dato questo è il lancio
anche nei server AWS c’è
c’è anche la scimmia di latenza che può
iniettare una latenza casuale nel sistema
per vedere se sei sensibile alla latenza
hanno il gorilla del caos che lo farà
estrai un’intera regione, se lo sei
significato per essere equilibrato attraverso le regioni così
queste sono tutte buone idee e penso
c’è altro che possiamo fare intorno al
idea di sfruttare la casualità da fare
i nostri sistemi sono una delle grandi idee
è che lo sviluppo è produzione di
Vale a dire gli strumenti ei processi che
tu usi per sviluppare il codice sono come
importante per la funzione aziendale di
distribuire software come produzione
l’ambiente è al resto del tuo
funzioni aziendali quindi infrastruttura dev
dovrebbe essere considerato come mission-critical
stiamo anche vedendo un grado crescente
di sofisticazione statistica in giro
monitoraggio e analisi in particolare uno
dei grandi temi negli ultimi pochi
anni che la velocità è stata la media
sono fuorvianti nascondono la tua storia
in realtà bisogno di guardare i valori anomali
e la lunga coda di ogni distribuzione
perché quelli risultano per dominare il tuo
esperienza del cliente e il tuo sistema
capacità e quando parliamo
sperimenta e fa diversi
prove e confermando ipotesi che abbiamo
essere consapevoli di un paio di cose grandiose
post sul blog sulla sperimentazione web come
narrazione umana la parte che mi piace
riguardo a questo stava facendo un a / b
prova su un sistema 20 test diversi e
uno di questi ha mostrato la gamba B del test
un risultato misurabile con te conosci un T
punteggio di 0,05 e quindi sarebbe considerato
statisticamente significativo è il kicker
che il suo test A / B ha appena assegnato delle persone
in due diversi secchi e poi loro
sono stati esposti a esattamente lo stesso
esperienza non c’era differenza
tra l’una gamba e la gamba B, ma con
un livello di confidenza del 5% uno fuori
di venti test ti mostreranno a
risultato statisticamente significativo puramente
per caso
e così stiamo iniziando a diventare un po ‘
più consapevolezza su come interpretarli
numeri uno degli errori classici che
vedi che le persone fanno sta eseguendo un a / b
test pianificato per l’esecuzione di dire un mese
dopo una settimana i risultati sulla gamba B.
sono così importanti che loro
il business dice che fermare il test mette tutti
su B questo è in realtà un errore di
sperimentazione e chiunque abbia
loro conoscono la scienza e l’ingegneria
i gradi ti diranno che non puoi fare
un esperimento in quel modo perché è possibile
ottenere una fluttuazione temporanea da
il risultato della popolazione che lo farà
alla fine convergere su quello che ti aspetti
per vedere ma se ti fermi presto potresti essere
ottenere un risultato spuria e tu sei
adottando qualcosa che è in realtà
dannoso quindi alcune cose a cui prestare attenzione
nei prossimi giorni di DevOps fa chiunque
riconoscere questa particolare curva può
chiunque leggere questa curva particolare
funziona meglio in stampa questo è il
Ciclo di hype di Gartner a differenza di molte cose
da Gartner questo risulta essere davvero
utile questo sostanzialmente dice qualcosa
succede che fa una nuova possibilità in
il modo in cui lavoriamo le persone ne parlano a
parliamo di questo che otteniamo questo picco
di aspettative gonfiate dove sembra
come se tutti lo facessero ma è ancora
solo il capofila e poi la gente prova
per iniziare a metterlo in produzione e
molte persone non lo fanno così bene e così
dopo un paio di anni ottieni questo
attraverso la disillusione che ti dice
so che questo non può funzionare qui non è in
in questo contesto non siamo un unicorno speciale
ma alla fine sai se ti infili
con esso viene consegnato il valore reale
la cosa è tutto sulla percezione
non si tratta della realtà del valore
creazione o consegna valore penso che sia giusto
ora con DevOps siamo quasi vicini
questo picco di aspettative gonfiate
pazienza che significa che aspetto i DevOps
gioco ogni minuto ora
Mi aspetto di vedere storie su come DevOps
sta fallendo e come le aziende stanno sprecando
soldi e come hanno dovuto rollback
perché se sei un giornalista
specialmente questo è il più interessante
la narrativa ora non è interessante
avere un altro posto che ci riesce
fare qualcosa che altre persone hanno
già fatto quello che vuoi fare è trovare
la polemica e così è per questo che otteniamo
che ora l’altra cosa che succede
quando hai ragione al culmine lo è
sembra davvero prezioso come un mercato e così
ci sono un sacco di persone che cercano di incassare
sul mercato qualcuno può effettivamente
entra e vendi una nuova cultura no
ma possono sicuramente venderti molto
di strumenti e così ottieni questo cambiamento
effetto o cambiando l’enfasi sugli strumenti
piuttosto che cultura in misura in cui le persone
cercherò di venderti cultura che faranno
entrare con gli impegni di consulenza
cambiare i piani di gestione cambia
i consulenti cambiano gli agenti che nominate e
cercheranno di venderti DevOps
una casella se questo ha successo o meno
quasi niente a che fare con la gente
entrare e consultarsi con te
ha tutto interamente a che fare con
la tua squadra e la tua prontezza a muoversi
in questo modo e creare questo tipo di
collaborazione e per fare il reorg e
cambiare l’ allineamento del
organizzazione attenti alla fallacia di
emulando pratiche senza adottare il
cultura che puoi mettere nell’automazione
puoi sbarazzarti del CRB ma se le persone
sono ancora alla ricerca di momenti gotcha e
le persone continueranno a essere chiamate
il tappeto e viene incolpato e preso
leganti gettato su di loro non si è
cambierà davvero qualcosa
un’altra cosa a cui prestare attenzione è questa
tipo di errore di assumere una squadra DevOps
quindi spero sia chiaro ormai che cosa
Sto parlando di quando dico DevOps
in realtà un omicidio
e una collaborazione più stretta è a
sfocatura dell’interfaccia tra questi
gruppi che non sono realmente serviti se io
assumere un gruppo di nuovi ingegneri etichettarli
DevOps ingegneri e ora metterli in
tra sviluppo e operazioni che vedo
questo succede
purtroppo spesso di solito quello che
il gruppo in realtà è un gruppo di strumenti
stanno costruendo strumenti che stanno costruendo
automazione e va bene noleggiarli
chiamiamoli un gruppo di strumenti che effettivamente abbiamo
abbiamo fatto anche senza gruppi di strumenti
tempo dovremmo avere più di loro nella nostra
le aziende, ma chiamandole DevOps è
in realtà non è solo un termine improprio ma
è un disservizio quindi qualche altro problema
che dobbiamo ancora risolvere aree di
opportunità c’è qualcosa che io
piace pensare come il paradosso di
automazione che è più tu
automatizzare qualcosa che meno ti ha preparato
sono quando si rompe questo è vero per le auto
oggi contro lo sai coleotteri da
la gente del 1960 che ha guidato quelli che sono
molto più preparato per sistemarli di me
sono con il mio computer controllato
veicolo ad iniezione di carburante un esempio che amo
riguarda questo libro di testo la realizzazione di a
volare questo è probabilmente un ottimo
libro di testo ma non sono sicuro che valga la pena
ventitre virgola sette milioni di dollari
questo era un prezzo reale su Amazon un altro
il venditore si dirigeva solo molto
diciotto virgola sei milioni di dollari come
ottieni un libro che costa questo
molto bene per farti davvero impazzire
bisogno di un computer o in questo caso diversi
di loro c’era solo una copia del
libro disponibile ne avevamo due diversi
venditori con strategie automatizzate uno
venditore questo prof Neff la loro strategia era
arbitraggio dei prezzi hanno guardato il
prezzo più alto là fuori e prezzo
c’è 0,2 per cento di ebook di confine in meno
ha avuto un’ottima reputazione e così
erano arbitraggi sospesi sul
reputazione avrebbero trovato il prezzo più alto
e passa al 127 percento con l’intero
strategia che se qualcuno ha comprato da
loro andrebbero a comprare dall’altra
uno e poi spedirlo attraverso bene il
i robot hanno ripetuto questo gioco per un mese
prima che qualcuno pubblicasse un post sul blog
e poi istantaneamente il prezzo è stato ripristinato
a qualcosa che dice, ma questo è un caso
di due tipi di automazione che interagiscono
attraverso un ambiente condiviso e io uso
questo come esempio di ciò che accade
quando automatizziamo un sacco di cose tutte
targeting per lo stesso ambiente possibile
ottieni l’automazione che inizia ad avanzare
l’un l’ altro o sono in conflitto tra loro
e può accadere solo in rari
circostanze come quando ce n’è una sola
copia di un libro, quindi di cosa abbiamo bisogno
si rendono conto è che nessuno di noi stanno lavorando in
questa sorta di cibernetica di prim’ordine
la cibernetica del primo ordine dell’ambiente è
sai un termostato che abbiamo un
uscita desiderata applichiamo qualche controllo
con feedback per arrivare al desiderato
uscita ma molto tempo fa la gente parlava
cibernetica di secondo ordine dove noi
incorporato il costruttore del dispositivo
nel sistema e otteniamo anche
alla cibernetica del terzo ordine in cui abbiamo
un ambiente comune che tutti hanno
operare in e questo è dove otteniamo
duellare BOT e libri da 23 milioni di dollari
sulle mosche quindi dobbiamo tenerne conto
anche di questo genere di cose, quindi cosa c’è
avanti fai attenzione alla diluizione come me
parlato di essere un po ‘diffidente nei confronti di
consulenze cercando di venderti a
devops culture non è uno strumento, non a
squadra separata sai che può essere fatto
mantieni la fiducia che può scalare
diventare abbastanza grande e con le parole di Jesse
Robbins non combatte stupido fai di più
fantastico grazie
questo è tutto
tu
anni da quando è stato coniato il termine DevOps
e questo è un intervallo interessante di tempo
cinque anni sono circa la metà di un normale
ciclo di adozione quindi normalmente ne occorrono dieci
anni per qualcosa diventare una sorta di
completamente integrato nel modo in cui lavoriamo
e 20 anni per qualcosa da passare
e solo una sorta di presunto un previsto
modo di fare le cose cinque anni è anche
quando tendi a vedere grandi aziende
interessarsi alle idee e forse
diluirli quindi parlerò di a
numero di aspetti di DevOps e cosa
significa essere qui ora vi parlerò di come
siamo arrivati dove siamo ciò che è attuale
stato delle cose e alcune direzioni
guardare al futuro, quindi come abbiamo fatto noi
arrivare qui
DevOps come termine è stato creato nel 2009 a
Infatti è stato creato nel 2009 da un
particolare individuo di nome Patrick
Dubois, al fine di eseguire una conferenza lui
aveva bisogno di un grande nome per la conferenza
e ha deciso di chiamarlo giorni DevOps
e il nome veramente bloccato questa forza
sembra un po ‘ frivolo, ma ha un
lunga tradizione il termine software
l’ingegneria è stata creata per una US Air
Conferenza della forza nel 1968 e così nel suo complesso
il campo è stato inventato da tutto il tessuto
allora e quindi conosci la conferenza
lo sviluppo guidato è sicuramente una cosa
Sarò aperto a procurarmi un quadro
su quello più tardi oggi oggi in termini di
questa presentazione ho molti nomi
di individui a cui fare riferimento e questo
sta cercando di cavalcare l’ equilibrio
tra dare credito dove è il credito
Il nome giusto e sfacciato che sto facendo
prova a non fare così tanto del nome
cadere e davvero dare credito al
innovatori che ci hanno portato dove siamo noi
sono così abbiamo questo termine DevOps
Patrick l’ha creato per una conferenza ma
le idee non hanno iniziato lì le idee
erano tutti
pronto in aria quando ha creato questo
conferenza questi antecedenti si estendono
indietro un bel modo quindi ricordo in
metà degli anni 2000 stavamo parlando di questo
cosa chiamata infrastruttura agile che
è stato ovviamente modellato su un software agile
sviluppo ed era basato sul
idea di estendere il tipo di agilità
e flessibilità si ottiene nella base di codice
nell’infrastruttura stessa eravamo
anche parlando di infrastrutture come
codificare l’idea che lo stato del
le cose che stai costruendo non dovrebbero essere
descritto da un lungo documento che racconta
gli umani come eseguire le procedure perché
gli umani succhiano davvero l’ esecuzione
procedure se hai intenzione di scrivere
tutte le procedure le danno a una shell
script così infrastruttura come il codice era
rimbalzare e anche prima di
che avevamo un ragazzo che promuoveva l’idea di
infrastruttura 2.0 che dovresti prendere
tutte le macchine nella tua infrastruttura
tutto ciò di cui ti occupi e che tratti
è come una grande macchina virtuale che tu
non dovrebbe essere coinvolto nell’assegnazione
risorse per fare lavori che è il lavoro di
qualcosa come un sistema operativo e
quindi avevamo bisogno di questa nozione di
infrastruttura 2.0 che è come un
sistema operativo distribuito tranne che non
uno che Andy Tannenbaum riconoscerebbe
come un sistema operativo ma il
antecedenti vanno ancora più indietro io
in realtà doveva tornare in una sorta di
era pre documenti web per scavare questo
ma cfengine
da un ragazzo di nome Mark Burgess
in realtà creato nel 1993 questo era il
software di automazione originale ops prima
fantoccio prima di chef in realtà prima del
lingue che erano fantoccio e chef
scritto in sono stati creati cfengine era
intorno ed è ancora in giro ed è un
ottimo pezzo di software, quindi quello che sono
cercare di dire è che queste idee non sono venute
dal nulla sono stati in giro per un
molto tempo ma qualcosa li ha fatti gelificare
verso la fine del decennio scorso e ho
pensa la cosa che li ha davvero fatti
gel è stata l’ascesa della virtualizzazione e
la nuvola perché improvvisamente invece di
ottenere nuove macchine una volta ogni tre
anni ci sono stati affrontati con la prospettiva di
ottenere nuove macchine virtuali
una volta al giorno o una volta alla settimana o una volta
ogni sei settimane e quindi tutte le domande
di implementazione e configurazione e
comprendendo davvero la tua configurazione
è salito alla ribalta Mark Burgess colloqui
su questa nozione di rapporti critici
che molti modelli di comportamento sono
determinato quando un rapporto va da
maggiore di 1.0 a meno di 1.0 e in
questo caso il rapporto che siamo
interessato è quanto tempo ha una macchina
vivere contro quanto tempo ci vuole per impostare
così ai vecchi tempi una macchina potrebbe
Prenditi qualche giorno per creare un paio di settimane
procurarsi e vivrebbe per pochi
anni in cui le macchine vivranno per un
pochi anni puoi tollerarlo
livello di ritardo nell’ottenere esso istituito, ma
se inizi a guardare la compressione
quelle vite che ora inizi a ricevere
fino a un punto in cui la durata della vita di
la tua macchina virtuale si sta avvicinando al
stessa durata del tempo necessario per impostare
su e qualcosa esce di colpo
hai molta pressione quando tu
approcci quel valore 1.0 del critico
rapporto che la pressione si allevia nel nostro
mondo di solito sotto forma di più
software e quindi più software qui
improvvisamente abbandonato i tempi di provisioning
dall’ordine dei giorni all’ordine dei minuti
e ho lasciato perdere il tempo di approvvigionamento
ordine di settimane per ordine di minuti e
questo è quando DevOps ha davvero iniziato a farlo
importa quando attraversiamo quella soglia 1.0
sulla configurazione dell’infrastruttura e sulla consegna
ora così ora questo è il mondo che siamo
in un po ‘del mio viaggio e
perché sono qui a parlare con te oggi che ho
stato uno sviluppatore praticamente tutto il mio
carriera tranne che ho avuto questo soggiorno
finita in operazioni per un po ‘che ho avuto
indossare il cercapersone e ho avuto modo svegliati
non solo quando il mio software non ha avuto successo
non quando il software di altre persone non sono riuscito
ho dovuto ripararlo in effetti ero parte di un
società il cui intero piano aziendale era
garantendo la disponibilità di
software che non abbiamo scritto
credimi questo ha senso per VCS
da qualche parte quindi ho fatto quello che qualsiasi sviluppatore
ho scritto codice per rendere più facile il mio lavoro
avevamo un application server che ho scritto a
mazzo di codice in Perl, enorme Perl oo
moduli che potrebbero attirare ogni pezzo
di questi server applicativi e consegnarli
me metriche e apporti modifiche
Ho costruito la struttura del modulo di produzione
in modo che potessimo schierare facilmente e
frequentemente e mantenere le cose invariate
quello che doveva essere permesso permettere
gli sviluppatori di controllare alcune cose e
ops per controllare ciò di cui avevano bisogno
controllo e ho introdotto il controllo della versione
per i nostri configs al tempo questo era un
il controllo della versione idea davvero radicale è
qualcosa che gli sviluppatori usano è a
strumento di programmazione non è uno strumento di amministrazione
come può aiutare l’amministratore ora che ho
ho un altro server per eseguire la versione
server di controllo ma in effetti si scopre
essere piuttosto utile quando qualcosa va
dita dei piedi-up
e puoi guardare indietro e dire di sapere
cosa è successo o cron job è stato disabilitato
perché è stato disabilitato bene così e così è stato
in questo impegno in quel momento e lì
c’erano alcune altre cose che stavo facendo
come se sapessi di restituire segnalazioni di bug
sviluppo con il numero di riga dove
il problema era che stava causando il
perdita di risorse anche se non avevo
accesso al codice sorgente perché l’ ho avuto
accesso a un compilatore D e lo erano
lasciando tutti i simboli quando loro
cose compilate e così durante questo tempo
Ho avuto modo di vedere in prima persona quanto bene il nostro
il software era sopravvissuto in produzione e
Ero scoraggiato per vederlo
la risposta non è stata molto buona
la maggior parte del software che stavo arrivando
in contatto con il QA era passato ed era
sorta di progettato e scritto per passare QA
e così ho avuto questa idea che tu
sai che il QA non è l’obiettivo e noi
in realtà dovrebbe essere a pensare a come
le cose girano in produzione che alla fine di
il progetto di costruzione del software è il
inizio della vita del software
e quindi dovremmo essere in programma per la sua
vivi per un certo periodo di tempo e
costruendo di conseguenza le nostre organizzazioni
quindi l’ ho portato in questo libro
rilasciarlo Ho cercato di pacchetto che fino
e riportarlo nello sviluppo
mondo da dove vengo e quello è
perché sono qui a tenere discorsi come questi
prova e assicurati che tutti apprezziamo
il nostro software è solo molto interessante
in produzione e dovremmo ottenere
è lì meglio, più veloce e più
in modo affidabile, quindi è un po ‘di storia
dove questa roba DevOps è arrivata in giro
Nel 2009 abbiamo faticato a capire
come chiamare questa cosa abbiamo avuto un gruppo
parlando di operazioni web e loro
stavano avendo un piccolo problema
differenziandolo dall’IT tradizionale
operazioni sapevamo che era diverso ma
non riuscivamo a esprimere al
soddisfazione della base ITIL
responsabili delle operazioni abbiamo avuto termini come
alta velocità che viene lanciata dentro e a
conferenza chiamata velocità abbiamo avuto un
infrastrutture jalopies angel ‘ sai
stavamo cercando il giusto
nome c’era un tempo in cui non lo facevamo
avere il nome giusto per il software agile
sviluppo forse qualcuno di voi
ricordare questo momento stavamo parlando
metodi leggeri metodi leggeri
avuto un problema di marketing vai al tuo
manager e dire che questo è un
progetto mission-critical ci penso
dovrebbe usare metodi leggeri e cosa
quindi la parola giusta è la differenza
tra un fulmine e un fulmine
e quando abbiamo ricevuto la parola DevOps
tutti sono andati subito a dire una buona parola
due sillabe rotolano fuori dalla lingua
eccellente ma poi abbiamo dovuto iniziare
discutendo sulla definizione di cosa si tratta
cosa significa che sai se Patrick
aveva fornito una definizione insieme alla sua
agenda della conferenza che sarebbe stata
ottimo ma abbiamo subito iniziato a discutere
su ciò che è DevOps ciò che non lo è
DevOps sono i DevOps che potrebbero essere in questo momento
Non lo so, abbiamo chiamato questo tizio
John Willis che alcune persone sono
riferendosi al Deming di DevOps I
così perché lo fa davvero
a disagio ha condiviso con noi il suo
modello che ha chiamato cultura delle camme
condivisione delle misure di automazione e
sono in questo ordine per molto
motivo importante perché la cultura è il
cosa che dovete ottenere il diritto in primo luogo se
non ho il giusto tipo di cultura no
la quantità di automazione ti porterà davvero
in un
cornice che suona molto bene e molto
i consulenti possono arrivare e dire DevOps
è un cambiamento culturale, il problema è
è una sorta di dichiarazione facile da fare
tutto è cultura
cambia tu inizi a fare qualcosa
diverso hai cambiato la tua cultura
devo dire qual è la cultura di destinazione
che stiamo cercando di cambiare in ordine
per essere significativo e quindi voglio
aiutare ad articolare la cultura DevOps a
un po ‘i valori della cultura DevOps
feedback veloce
hai sentito parlare Adrienne stamattina
piuttosto che misurare le cose in pochi secondi
di minuti in modo da poter ottenere il tuo
applicazione ridistribuita 10 secondi dopo
lo rompi, piuttosto che i 10 minuti
tipo di feedback che abbiamo usato per ottenere circa
i sistemi di produzione sono stati misurati in settimane
sai che faccio un rilascio pubblicando
rilascia note al gruppo ops e
scrivendo un cambio biglietto e un certo numero
di settimane più tardi le cose vanno dentro
produzione e poi lo scopro
getta le eccezioni del puntatore nullo dappertutto
il luogo
DevOps sicuramente valorizza direttamente
connessioni tra collaborando
individui questa è l’antitesi di
il tipo di sistema di ordine di lavoro basato su cue
di solito ci saranno artefatti e
i documenti creati consentono di creare un Kanban
consiglio e stai facendo DevOps ma in realtà
la comunicazione è primaria e il
gli artefatti ci sono per il monitoraggio dopo
il fatto che facciamo un sacco di dati basati
comunicazione non è chi urla il
più forte o chi ha un’opinione su cosa
tecnologia di database da utilizzare o come
l’applicazione dovrebbe essere strutturata
quando possibile abbiamo effettivamente guardiamo
cose come tempi di inattività e tempi di risposta
distribuzioni e diciamo questo prodotto
e questo prodotto funziona grosso modo il
lo stesso possono entrambi soddisfare tutti i controlli di qualità
requisiti ma questo sta per
richiedono tempi di fermo ogni volta che facciamo
fare una versione del software e questo è
non questo richiederà
comunicazione centralizzata e
la governance centralizzata sta andando
per consentire il decentramento e quindi usiamo
come parte del processo decisionale
processo e c’è un interesse
escrescenza di quel tipo di dati basati
comunicazione che ha a che fare con
in coda e l’eliminazione delle code
così ogni volta che hai una comunicazione
modello che richiede centralizzato
controllo e un gatekeeper sei
introducendo ritardi nel tuo processo e
ci piacerebbe sbarazzarci di questo e così parte
dei dati di comunicazione basato è come
lungo ci sta portando da cui partire
check-in per vivere in produzione
collaborazione e lo cerimonia
sai che a tutti piace quello di nessuno
sto per dirti l’ inferno no, non voglio
avere bisogno di quella collaborazione ma a
aspetto davvero importante è questa idea di
abilitazione piuttosto che autoprotezione
Sono stato in un certo numero di operazioni
gruppi che hanno una visione molto debole di
gli sviluppatori che vedono gli sviluppatori e
lo sviluppatore cambia come la fonte di tutti
del loro dolore e così fanno quello che nessuno
avrebbero cercato di proteggersi
da quel dolore erigendo barriere e
assicurandosi che gli sviluppatori non possano ottenere
attraverso la barriera finché non lo dimostrano
che non causeranno dolore
L’ approccio DevOps è assolutamente invertito
da quello in due modi il primo modo
è invertito è quello invece di
building automation che mi permette di fare il mio
parte più veloce che ho intenzione di costruire
automazione che ti dà il potere di
fare quello che facevo e dove ero
andando ad applicare il giudizio e l’analisi e
guarda quello che stavi facendo, lo sono
cercherò di automatizzare quel giudizio
elaborare così ad esempio un punto tipico
di attrito è intorno sequel o schema
le modifiche in un nostro DBBA DBA non vogliono
gli sviluppatori di scrivere il proprio schema
cambia perché fanno cose come
dimentica di indicizzare il bersaglio di un estraneo
rapporto chiave bene puoi avere un DBA
controlla ogni cambio di schema che sta succedendo
attraverso il sistema o puoi avere un
programma che controlla ogni cambiamento dello schema
passare attraverso il sistema che preferirei avere
il programma lo fa perché non la volontà
il programma non dimenticherà qualcosa una sola volta
il problema è qualcosa
come il sequel è in realtà davvero difficile
analizzare in modo affidabile ed esaminare e guardare
per problemi quindi forse faccio qualcosa
come costruire un ambiente dove posso
istanzia automaticamente la corrente
database applica la modifica e quindi
ispezionare i risultati del cambiamento questo
è un tipo di lavoro che le organizzazioni
era riluttante a fare ma è
assolutamente fondamentale per l’idea di
abilitazione un altro modo per risolvere lo stesso
il problema è dire che non specificeremo il nostro
modifiche nel seguito in cui verranno specificate
qualcosa come la base o le rotaie liquide
migrazioni che sono più facili da analizzare e
più facile da ispezionare con strumenti automatici
qualunque sia la soluzione è l’ obiettivo
è lo stesso per far uscire l’umano
il ciclo usa l’umano per applicare
conoscenza e giudizio nella costruzione del
automazione non in esecuzione del processo
ogni giorno o ogni settimana dirò un posto
dove abbiamo un lavoro da fare è con
quello stesso tipo di trasformazione nel
area di sicurezza delle informazioni il nostro InfoSec
gli strumenti oggi sono ancora molto manuali
eseguire uno scanner contro un sistema che viene
torna con 800 pagine e una sicurezza
esperto quando è giù per i tre
problemi che contano davvero o se lo sono
il tuo primo go-around probabilmente il 30 o
40 problemi che contano davvero ma
essenzialmente ogni volta è lo stesso
lo strumento di elaborazione crea un esperto di output di grandi dimensioni
controlla la produzione e scopre cosa
che conta davvero abbiamo avuto modo di cambiare la situazione
al fine di ottenere InfoSec completamente integrato
in DevOps mentre stai guardando questi
punti elenco cultura sei probabilmente
pensando che suonino un po ‘ familiare
sembrano molto simili a questi valori di
semplicità di comunicazione
rispetta il coraggio che puoi riconoscere
come i valori XP originali che è
deliberare è la cultura DevOps
modellato deliberatamente su una cultura agile
e generalmente parlando ad alta velocità
alta cultura della fiducia ora ho menzionato
automazione come secondo punto di John
definizione
quando parliamo di nuovo dell’automazione
c’è un po ‘di diverso
prospettiva sull’automazione un aspetto
di esso è che stiamo andando a utilizzare più leggero
strumenti di peso quanti di voi hanno mai
stato
i soggetti e / o le vittime di qualcosa
come un lancio di HP openview okay
scuse se qualcuno di voi effettivamente funziona
per HP è molto doloroso è molto
costoso e ci vuole molto tempo quindi
cosa succede tre mesi lungo la strada
se dici che openview non è di grande aiuto
noi se hai dati che mostrano i nostri
i tempi di inattività non hanno cambiato la nostra risposta
la distribuzione del tempo è la stessa nostra
la soddisfazione del cliente è la stessa, ma noi
ha investito tutti questi soldi in una vista aperta
beh non puoi strapparlo perché allora
dovresti scriverlo sei gentile
di attaccarci e quindi tendiamo a favorire
strumenti più leggeri e in particolare
strumenti open source perché possiamo adottare
loro e li butta via come i bisogni di
il sistema impone che non siamo obbligati a farlo
il CFO e il reparto contabilità
per mantenere quel software in servizio
abbastanza a lungo da ammortizzarlo completamente
tipicamente automatizzando le cose per accorciare
il tempo del ciclo quindi un sacco di operazioni
automazione nel passato focalizzata sul
ultima parte della richiesta, in altre parole
dovresti presentare una richiesta di modifica e
entrerebbe nel sistema di bigliettazione e
avresti una riunione CR B che lo farebbe
approva o rifiuta la richiesta e dopo di essa
ma ho approvato una finestra cambiamento sarebbe
programmato e quindi l’amministratore si siederebbe
in basso e ci vogliono circa cinque minuti
il lavoro alla fine di due settimane
processo di automatizzazione degli ultimi cinque minuti
di quel processo non fa niente
aiutarti a ciò che vuoi fare è automatizzare
il processo di approvazione e automatizzare il
ritardare e quindi stiamo cercando di
automatizzare in modi che aumentano la velocità
di cambiamento e consentire modifiche più sicure
anche l’automazione nelle operazioni
abbraccia alcuni di questi strumenti di sviluppo
abbiamo degli amministratori
scrivendo codice Ruby anche tu lo sai bene Oh
La libreria Ruby è con test e
tutto ciò che è un bel cambiamento
Adam Jacobs ha parlato di come lo penso
era Adam forse
Jezz o Chris puoi correggermi se lo sono
la mancanza di citazioni ha parlato di come amministratori
effettivamente utilizzare un sacco di diverso
lingue per tutto il tempo che guardano a tutti
i file di configurazione nella directory di etsy
guarda tutti i file di configurazione di Apache
le cose sono lingue per la configurazione
i sistemi e gli amministratori si muovono molto fluidamente
attraverso molti di questi diversi
le lingue semplicemente non la pensano come
lingue così da imparare Rubino come un altro
linguaggio di configurazione in realtà no
quel duro mm-hmm si , non lo so
em per bene parleremo di che
così alla base di tutto questo c’è un cambiamento
enfasi nel gruppo operativo da
automazione per autoconservazione a
automazione per l’abilitazione di altro
persone invece di renderlo più facile
io per spingere il pulsante che ti darò
il pulsante e insieme a quello anche io
devo darti le conseguenze di
premendo il pulsante e questo è quando noi
vieni alla misurazione in modo da sapere se se
Sono quello che si sveglia e io sono il
uno che viene chiamato sul tappeto dal
CIO e mi hanno sgridato letteralmente
visto i manager delle Alpi farsi leganti
lanciato contro di loro attraverso una stanza da un CIO
Mi proteggerò da questo primo
di tutto vado a indossare una visiera
in tutti i miei incontri con il CIO e
Probabilmente lo farò anche io
che non puoi mettermi in quella posizione
beh, il modo più semplice per farlo è
in realtà solo per metterti al corrente
fornire di nuovo un software di qualità
è qualcosa di cui parlava Adrienne
stamattina sta chiudendo un feedback
loop che è stato rotto per più di 10
anni se riesci a creare un problema e
buttalo oltre il muro e io devo
subire le conseguenze di questo problema
due cose accadono prima di tutto
rendere il muro a noleggio e secondo non aver mai
imparare
per smettere di creare problemi ma se tu
crea il problema e tu sei l’unico
chi ottiene il feedback su di esso lo farai
impara come smettere di creare problemi così
quando misuriamo le cose che stiamo andando
allontanarsi da alcune delle idee che dicono
il sistema di misurazione che sai di avere
ne ho uno per gli amministratori e ne abbiamo un altro
uno per gli affari e un altro per
marketing e così via in realtà siamo solo
andando a misurare tutto insieme e
metteremo tutto in un unico sistema
dove puoi correlare qualsiasi cosa con
tutto ciò ha dei pericoli che puoi
facilmente ingannare te stesso con spuria
correlazioni ie8 utenti – riscaldamento globale
o qualcosa del genere c’è un intero
sito web dedicato allo spurio
le correlazioni ora sono cose molto divertenti ma
a volte ci sono interessanti
correlazioni che ti sono davvero utili
voglio abilitare misure ad hoc come
il numero di pizze ordinate da
le squadre di sviluppo perché è così interessante
Non è così il CFO può rendere più
pizza più economica ma si scopre quando si
avere un sacco di team di sviluppo che ordinano pizze
se è fuori orario probabilmente significa
stanno lavorando molto ed è un vantaggio
indicatore del fatturato in modo da trovare
intuizione in luoghi inaspettati quando si
misurare tutto e ho intenzione di venire
torna su questo argomento di informazioni e
l’informazione scorre un po ‘più tardi
la finale dei punti elenco di John era
condividere le informazioni sulla condivisione condividere le risorse
condividere conoscenze che vogliamo davvero ottenere
lontano dall’idea di informazione
accaparramento e cercare di dire alla gente tanto
come vogliono sapere o sono capaci
assimilare perché tutti fanno
decisioni migliori quando sono di più
informato il grande rischio in una crescita e
l’organizzazione complessa è locale
ottimizzazione, facilito il mio lavoro
spingendo il lavoro fuori dai confini dove
cade in crepe tra la mia scatola e
la scatola a monte in modo da sapere cosa
succede che un nuovo lavoro venga creato per essere gestito
cosa cade nelle crepe là e
ora ho tre scatole con due
handoff dove potremmo essere appena stati
parlando un po ‘di più
uno dei più importanti pensatori di sistemi di
il 20 ° secolo si chiamava Donella
Meadows ha scritto molti grandi libri ma
uno dei giornali che mi ha davvero colpito
molto difficile è chiamato punti di leva in a
sistema in cui scrive una gerarchia
di posti di intervenire in un sistema di
apportare modifiche ad esso e deliberare
cambiamenti e talvolta involontari
cambia il modo più debole di fare
le modifiche a un sistema sono con ciò che lei
chiama costanti e parametri questi sono
cose come le aliquote aumentano i bonus
incentivi che altereranno il comportamento ma
quelle modifiche possono facilmente essere
superato da altre cose che non sto andando
per passare attraverso tutti i 12 dei suoi punti
anche se è affascinante leggere quando
entriamo nei cambiamenti di maggiore intensità
o punti di forza di forza più alta noi
prendi alcune cose interessanti così forte
di circuiti di feedback negativi rispetto a
la dimensione dell’effetto che stanno cercando
controlla il guadagno attorno al feedback positivo
cicli relativi alla dimensione dell’effetto
i circuiti di feedback positivi conquistano sempre
loop di feedback negativi se ci stai provando
per guidare un comportamento fuori da un sistema te
può creare un ciclo di feedback negativo ma
stai molto meglio creando un
circuito di feedback positivo per guidare di più
comportamento desiderabile l’indesiderabile
comportamento sarà solo fade out dell’esistenza
quando il desiderabile prende il sopravvento ma
ora guarda questa struttura di
l’informazione scorre quella che trovo
affascinante perché ci occupiamo tutti
informazioni e quindi ne abbiamo molte
controllo su questa particolare leva
punto e se non mi credi metti un
costruisci il tuo monitor al di fuori del tuo ufficio CIO
e scommetto che il numero di falliti
le build vanno giù ora forse il numero di
il totale delle build scende e la dimensione di
i cambiamenti salgono quindi devi essere un
un po ‘ attento a ciò che sveli
ma semplicemente rendendo visibili le informazioni
ovunque farà sì che le persone provino a farlo
cambia queste informazioni per esempio put
un grafico
su un grande display visibile BVD come Alistair
Coburn lo chiama gente che muoverà il cielo
e terra per far risalire quel grafico e
a destra
se è quello che vuoi veramente o
non succederà così tanto
informazioni visibili e le persone agiranno
su di esso e non devi legarlo a
incentivi per gli stipendi di nessuno deve essere acceso
la linea di nessuno bonus non ci sono penalità
rendilo visibile è molto facile
fare questi in questi giorni ottenere un pannello piatto
mostra con un chromecast inserito
lo slot HDMI se non è possibile ottenere il budget
per questo chiedi uno sviluppo in tempo reale
piattaforma di analisi della qualità e andare a comprare a
display a schermo piatto con un chromecast
la stessa cosa sembra migliore con un budget
richiesta mentre stai rivelando questo
informazioni che può essere chiesto per
l’interpretazione di alcune operazioni che le persone non fanno
come dare un’interpretazione ho avuto un
gestore degli ops una volta chi è stato chiesto in a
mattina incontro perché uno del web
la CPU dei server era più alta di tutti
gli altri per il giorno precedente e lui
tap-ballò un po ‘ perché
davvero non ha voluto dire oh, ma che
era la risposta che non sapevamo di aver rimbalzato
Apache e è tornato alla normalità e
quello era buono come risultato di quello che era
necessario per segnalare la CPU media di
i server web ogni giorno alle 6 del mattino quindi
potrebbe andare sul quotidiano scritto a mano
rapporto di attività distribuito a tutti i
manager per due anni ha dovuto alzarsi
salire su una chiamata in conferenza ogni mattina
riporta un numero e poi torna a letto
bene i manager si sono fermati rapidamente
guardando questi numeri e le mie operazioni
manager lo sapeva e così ha fatto quello che chiunque
dicendo farebbe ha iniziato a fare in su
ha preso il numero del giorno precedente
lo aggiustò di qualche percento e lo diede
loro quel numero non era un
ingegneria primaria a scuola per quelli di
tu che ti credi all’idea di te
sapere falsificare i tuoi dati
non avrebbe avuto importanza letteralmente
stato molto meglio insegnare alle persone che il
I numeri di CPU non importavano quello che loro
davvero voluto guardare era il
distribuzione del tempo di risposta perché
questo è ciò che i clienti in realtà
esperto e avrebbe potuto essere riorientato
il focus dell’organizzazione attorno ad un
utile insieme di numeri che avrebbe
diventare una pietra di paragone per tutti da usare
e continua a riferirsi a e guardare
come abbiamo fatto cambiamenti come il marketing
gruppo utilizzando la gestione dei contenuti
sistema per caricare altri due megabyte di
video sulla home page per esempio
invece abbiamo avuto un inutile bit di
informazione che viene messa in un manoscritto
rapporto
quindi la mia massima è che non insegnerai mai
te stesso senza lavoro quando ne fai di più
informazioni visibili insegnano alle persone come reagire
ad esso allontanarsi da nozioni di
incentivi o domande come che proprio
insegnare alle persone questo è ciò che sembra normale
come questo è quello che sembra cattivo
com’è meglio così che tutti
è come muoversi nella stessa direzione
la prossima grande influenza devo parlare
circa è un ragazzo di nome John tutti SpA sorta
di un santo patrono delle operazioni
un individuo calmo, a testa bassa, vorrei
fidatevi di lui in qualsiasi tipo di crisi
situazione, ma ha fatto esplodere le nostre menti indietro
velocità 2009 con un discorso chiamato dieci
distribuisce al giorno su Flickr Flickr era grande
gli uomini è più grande ora e stanno parlando
sull’implementazione del codice dieci volte al giorno
era eretico era radicale quello
numeri aumentati di un ordine di grandezza
ma da allora in poi rifletterò questo
ha mostrato un’intuizione che è venuta dal
comunità agile che se qualcosa fa male
dovresti farlo più spesso
ora questo non è perché gli sviluppatori sono
masochisti ma se lo fai più spesso
tu
migliorando, troverai i modi per farlo
rendono male troverete modi per
automatizzare piuttosto che sorta di Shying
lontano dai medici del dolore lo sanno
molto bene se qualcuno di voi avesse qualche tipo di
chirurgia ti diranno di alzarti e muoverti
sai non sederti intorno andando tutto
ti fa male devi muoverlo per
recuperare è un tipo simile di cosa
con schieramenti se si evita di farlo
le tue implementazioni diventano più rischiose di più
probabile fallire più costoso tutto cattivo
le cose che John ha anche portato in questa idea di
le persone fanno parte del sistema e questo
c’è un aspetto dei fattori umani
le operazioni di psicologia conta c’è
una cosa come un fallimento che induce
sistema questo è uno che è altamente
accoppiati esibisce accoppiamento dinamico
quindi le cose che sono liberamente accoppiate possono
improvvisamente diventano strettamente accoppiati come
disco IO e Ram ti dà ambiguo
o segnali incerti nelle tue letture
e potrebbe avere operatori che non lo fanno
capisci pienamente il sistema che sono
operando tutti questi sono veri per il
tipi di sistemi con cui abbiamo a che fare
un altro importante contributo a questa linea
di pensare è l’umile Jezz di Jay che ci ha dato
questo fantastico libro chiamato continuo
consegna che penso sia un ottimo modo per
introdurre DevOps nella tua azienda è
sulla distribuzione ma si tratta di più
di implementazione è in realtà
integrando il flusso di valore fino in fondo
attraverso l’organizzazione e lo farà
ti porta a DevOps e anche se non lo fai
vai fino in fondo, stai ancora andando
per offrire più valore per unità
tempo di quello che erano prima in modo da avere
questa idea in sviluppo agile di
tipo di integrazione del front end del
stakeholder della linea di sviluppo Dev al QA noi
far lavorare una squadra in una stanza
insieme
DevOps estende tutto il resto
e quindi dovremmo avere un valore unificato
scorrere fino in fondo
e quelli di voi hanno avuto qualche allenamento
e magra riconoscerà questo come ciò che tu
fai in modo che ti concentri sul flusso di valore
fino in fondo e tu integri
quel flusso di valore così qui abbiamo il
fattori che si sono uniti o le idee
che si fondono e creano questo
l’idea di DevOps va bene è stata lunga
lezione di storia fatta con che parliamo
di dove siamo adesso, quindi siamo in cinque
anni e ne abbiamo fatti molti
progresso ma ci sono ancora alcune aree
ho bisogno di un lavoro serio, quindi lo darò
tu il mio tipo di scala di valutazione su a
mucchio di diverse aree e quanto bene
sono stati indirizzati così nel nel
regione di distribuzione che abbiamo fantastico
strumenti ora infatti abbiamo un
imbarazzo di ricchezze nello strumento
spazio abbiamo il venerabile cfengine
abbiamo del sale da cucina fantoccio da cuoco
in realtà ce ne sono di nuovi ogni settimana quindi
per favore non scrivere una nuova distribuzione
sistema ma c’è un posto che siamo
in questo settore manca tutto lo spiegamento
sistemi di tipo di considerare una macchina come il
obiettivo dello spiegamento, ma io sono
in realtà non è interessato a a
macchina più mi interessa a
intera topologia di macchine con parti
correre in posti diversi che tutti
doversi conoscere e connettersi
collaborare non abbiamo davvero molto
lo sta facendo ancora così è quello
perché è un a- invece di un A + quando
stiamo parlando di provisioning che siamo
davvero parlando di farti sapere
metallo nudo e ottenere fino al
punto in cui è pronto per un
dell’applicazione da installare è
in realtà un po ‘più debole di quanto dovrebbe
essere un sacco di grandi organizzazioni hanno
sviluppato il proprio altamente automatizzato
sistemi di approvvigionamento loro
idiosincrasie uno ssin nel modo in cui loro
lavoro che non possono necessariamente essere raccolti
e mettiti da qualche altra parte così abbiamo fatto
ha ancora un po ‘ del vecchio tipo di
standard hardware su pixie e TFTP
abbiamo alcuni strumenti come il ciabattino
seduto in cima
ma sul serio se hai mai provato
usa il ciabattino
non è il fuoco e non dimenticare di nessuno
significa che sii sul provisioning per fortuna
questo è in qualche modo mitigato dal fatto
che probabilmente stai tutti correndo nel
nuvola in ogni caso e in modo da non dover
occuparsi spesso del provisioning
la registrazione è uno dei posti che ha
ho fatto davvero tanti progressi
la registrazione era nel regno di
sicurezza e quindi l’idea è stata scritta una volta
leggi mai hai raccolto tutti i log in
un posto dove nessuno potrebbe mai guardare
a loro o lo sapevi puramente il
dominio degli strumenti commerciali ora abbiamo
sia commerciale che open source
alternative in modo che questo è ottenuto molto
un monitoraggio migliore è diventato molto
meglio così ora abbiamo strumenti fantastici
per una sorta di rappresentazione grafica delle cose dai log in
conosci una latenza di un secondo o di un minuto
la grafite ha ottenuto molta trazione
grande strumento non così grande sul front-end
quindi sono un front-end sostitutivo per
ma è un posto che sta lottando un po ‘
relativo al monitoraggio è conoscerti
so che le cose funzionano, quindi posso raccogliere
tutte le metriche ma ho ancora bisogno del
wetware umana di vedere le cose e mi dicono
è normale o non è normale e
Ti darò un paio di esempi di
dove il rilevamento delle anomalie è ancora un po ‘
non soddisfare davvero i nostri bisogni, quindi abbiamo
ha cose come l’elaborazione di eventi complessi
motori che possono sedersi lì e cercare
sai che l’ evento si verifica e poi l’evento B
o C deve avvenire all’interno di una certa unità di
tempo possono aggregare un mucchio di
eventi in modo da sapere se ogni singolo
il server delle applicazioni si lamenta di no
essere in grado di raggiungere il database
il problema è probabilmente il database non il
server delle applicazioni in modo tale che la parte sia a posto
ma uno dei miei clienti invia un sacco di
messaggi di posta elettronica ogni mattina voglio dire un sacco di
e -mail e in pochi minuti
inizia a vedere gli accessi da persone che fanno clic
nelle e-mail o almeno lo sono
supposto vedere gli accessi così che cosa abbiamo
ecco un modello giornaliero che sembra
abbastanza
niente nulla di enorme picco nulla
niente niente
tranne che dovrebbe essere un enorme picco
sai tra il 20 e il 30 percento di
il numero di e-mail che hanno inviato se
il picco non si verifica
questa è l’anomalia che non abbiamo davvero
strumenti in grado di farlo, ma non c’era
alcuni parlano al monitor AMA sul digitale
elaborazione del segnale e tipo di estrazione
modelli basati sul tempo non siamo ancora arrivati
Penso che i progressi in questo settore stiano andando
venire dall’uso di vecchi modelli da
cibernetica e sistemi di controllo come
qualcosa chiamato filtro Coleman
dove hai un modello fisico di cosa
il sistema dovrebbe fare e stai cercando
per discrepanze tra ciò che il
sistema dovrebbe fare dato un insieme di input
e ciò che effettivamente fa, naturalmente
richiede di costruire quel modello che
può essere un po ‘difficile tenersi aggiornati
con il ritmo del cambiamento nei nostri sistemi
quindi abbiamo ancora alcune sfide lì
e poi c’è quest’area che chiamo
comprensione del sistema o idea che
Dice che sai okay, quindi puoi dirmelo
che una macchina è giù, ma come fa quel
influire sui miei utenti o su come influenza il mio
entrate non abbiamo molto che si collega
attraverso tutti questi strati ancora c’è un
linguaggio di descrizione dell’architettura chiamato
il nostro cue mate che pretende di farlo
ma è come se fosse un profilo UML così tu
può ottenere stencil per la nostra stecca ma
non c’è nulla di eseguibile al riguardo
non può trasformarlo in un sistema di monitoraggio
quindi questo è un altro posto che abbiamo
alcuni progressi per fare uno dei migliori
le cose che stiamo facendo sono intorno a questo
idea di forzare la casualità sul
sistemi per migliorarli così risulta
se fai molte distribuzioni al
consumando servizi un sacco di dispiegamenti
sembra un sacco di fallimenti ogni
la distribuzione sembra un po ‘parziale
fallimento e se questo non è abbastanza abbiamo
ho questa idea della scimmia del caos
Netflix ci ha dato questo è il lancio
anche nei server AWS c’è
c’è anche la scimmia di latenza che può
iniettare una latenza casuale nel sistema
per vedere se sei sensibile alla latenza
hanno il gorilla del caos che lo farà
estrai un’intera regione, se lo sei
significato per essere equilibrato attraverso le regioni così
queste sono tutte buone idee e penso
c’è altro che possiamo fare intorno al
idea di sfruttare la casualità da fare
i nostri sistemi sono una delle grandi idee
è che lo sviluppo è produzione di
Vale a dire gli strumenti ei processi che
tu usi per sviluppare il codice sono come
importante per la funzione aziendale di
distribuire software come produzione
l’ambiente è al resto del tuo
funzioni aziendali quindi infrastruttura dev
dovrebbe essere considerato come mission-critical
stiamo anche vedendo un grado crescente
di sofisticazione statistica in giro
monitoraggio e analisi in particolare uno
dei grandi temi negli ultimi pochi
anni che la velocità è stata la media
sono fuorvianti nascondono la tua storia
in realtà bisogno di guardare i valori anomali
e la lunga coda di ogni distribuzione
perché quelli risultano per dominare il tuo
esperienza del cliente e il tuo sistema
capacità e quando parliamo
sperimenta e fa diversi
prove e confermando ipotesi che abbiamo
essere consapevoli di un paio di cose grandiose
post sul blog sulla sperimentazione web come
narrazione umana la parte che mi piace
riguardo a questo stava facendo un a / b
prova su un sistema 20 test diversi e
uno di questi ha mostrato la gamba B del test
un risultato misurabile con te conosci un T
punteggio di 0,05 e quindi sarebbe considerato
statisticamente significativo è il kicker
che il suo test A / B ha appena assegnato delle persone
in due diversi secchi e poi loro
sono stati esposti a esattamente lo stesso
esperienza non c’era differenza
tra l’una gamba e la gamba B, ma con
un livello di confidenza del 5% uno fuori
di venti test ti mostreranno a
risultato statisticamente significativo puramente
per caso
e così stiamo iniziando a diventare un po ‘
più consapevolezza su come interpretarli
numeri uno degli errori classici che
vedi che le persone fanno sta eseguendo un a / b
test pianificato per l’esecuzione di dire un mese
dopo una settimana i risultati sulla gamba B.
sono così importanti che loro
il business dice che fermare il test mette tutti
su B questo è in realtà un errore di
sperimentazione e chiunque abbia
loro conoscono la scienza e l’ingegneria
i gradi ti diranno che non puoi fare
un esperimento in quel modo perché è possibile
ottenere una fluttuazione temporanea da
il risultato della popolazione che lo farà
alla fine convergere su quello che ti aspetti
per vedere ma se ti fermi presto potresti essere
ottenere un risultato spuria e tu sei
adottando qualcosa che è in realtà
dannoso quindi alcune cose a cui prestare attenzione
nei prossimi giorni di DevOps fa chiunque
riconoscere questa particolare curva può
chiunque leggere questa curva particolare
funziona meglio in stampa questo è il
Ciclo di hype di Gartner a differenza di molte cose
da Gartner questo risulta essere davvero
utile questo sostanzialmente dice qualcosa
succede che fa una nuova possibilità in
il modo in cui lavoriamo le persone ne parlano a
parliamo di questo che otteniamo questo picco
di aspettative gonfiate dove sembra
come se tutti lo facessero ma è ancora
solo il capofila e poi la gente prova
per iniziare a metterlo in produzione e
molte persone non lo fanno così bene e così
dopo un paio di anni ottieni questo
attraverso la disillusione che ti dice
so che questo non può funzionare qui non è in
in questo contesto non siamo un unicorno speciale
ma alla fine sai se ti infili
con esso viene consegnato il valore reale
la cosa è tutto sulla percezione
non si tratta della realtà del valore
creazione o consegna valore penso che sia giusto
ora con DevOps siamo quasi vicini
questo picco di aspettative gonfiate
pazienza che significa che aspetto i DevOps
gioco ogni minuto ora
Mi aspetto di vedere storie su come DevOps
sta fallendo e come le aziende stanno sprecando
soldi e come hanno dovuto rollback
perché se sei un giornalista
specialmente questo è il più interessante
la narrativa ora non è interessante
avere un altro posto che ci riesce
fare qualcosa che altre persone hanno
già fatto quello che vuoi fare è trovare
la polemica e così è per questo che otteniamo
che ora l’altra cosa che succede
quando hai ragione al culmine lo è
sembra davvero prezioso come un mercato e così
ci sono un sacco di persone che cercano di incassare
sul mercato qualcuno può effettivamente
entra e vendi una nuova cultura no
ma possono sicuramente venderti molto
di strumenti e così ottieni questo cambiamento
effetto o cambiando l’enfasi sugli strumenti
piuttosto che cultura in misura in cui le persone
cercherò di venderti cultura che faranno
entrare con gli impegni di consulenza
cambiare i piani di gestione cambia
i consulenti cambiano gli agenti che nominate e
cercheranno di venderti DevOps
una casella se questo ha successo o meno
quasi niente a che fare con la gente
entrare e consultarsi con te
ha tutto interamente a che fare con
la tua squadra e la tua prontezza a muoversi
in questo modo e creare questo tipo di
collaborazione e per fare il reorg e
cambiare l’ allineamento del
organizzazione attenti alla fallacia di
emulando pratiche senza adottare il
cultura che puoi mettere nell’automazione
puoi sbarazzarti del CRB ma se le persone
sono ancora alla ricerca di momenti gotcha e
le persone continueranno a essere chiamate
il tappeto e viene incolpato e preso
leganti gettato su di loro non si è
cambierà davvero qualcosa
un’altra cosa a cui prestare attenzione è questa
tipo di errore di assumere una squadra DevOps
quindi spero sia chiaro ormai che cosa
Sto parlando di quando dico DevOps
in realtà un omicidio
e una collaborazione più stretta è a
sfocatura dell’interfaccia tra questi
gruppi che non sono realmente serviti se io
assumere un gruppo di nuovi ingegneri etichettarli
DevOps ingegneri e ora metterli in
tra sviluppo e operazioni che vedo
questo succede
purtroppo spesso di solito quello che
il gruppo in realtà è un gruppo di strumenti
stanno costruendo strumenti che stanno costruendo
automazione e va bene noleggiarli
chiamiamoli un gruppo di strumenti che effettivamente abbiamo
abbiamo fatto anche senza gruppi di strumenti
tempo dovremmo avere più di loro nella nostra
le aziende, ma chiamandole DevOps è
in realtà non è solo un termine improprio ma
è un disservizio quindi qualche altro problema
che dobbiamo ancora risolvere aree di
opportunità c’è qualcosa che io
piace pensare come il paradosso di
automazione che è più tu
automatizzare qualcosa che meno ti ha preparato
sono quando si rompe questo è vero per le auto
oggi contro lo sai coleotteri da
la gente del 1960 che ha guidato quelli che sono
molto più preparato per sistemarli di me
sono con il mio computer controllato
veicolo ad iniezione di carburante un esempio che amo
riguarda questo libro di testo la realizzazione di a
volare questo è probabilmente un ottimo
libro di testo ma non sono sicuro che valga la pena
ventitre virgola sette milioni di dollari
questo era un prezzo reale su Amazon un altro
il venditore si dirigeva solo molto
diciotto virgola sei milioni di dollari come
ottieni un libro che costa questo
molto bene per farti davvero impazzire
bisogno di un computer o in questo caso diversi
di loro c’era solo una copia del
libro disponibile ne avevamo due diversi
venditori con strategie automatizzate uno
venditore questo prof Neff la loro strategia era
arbitraggio dei prezzi hanno guardato il
prezzo più alto là fuori e prezzo
c’è 0,2 per cento di ebook di confine in meno
ha avuto un’ottima reputazione e così
erano arbitraggi sospesi sul
reputazione avrebbero trovato il prezzo più alto
e passa al 127 percento con l’intero
strategia che se qualcuno ha comprato da
loro andrebbero a comprare dall’altra
uno e poi spedirlo attraverso bene il
i robot hanno ripetuto questo gioco per un mese
prima che qualcuno pubblicasse un post sul blog
e poi istantaneamente il prezzo è stato ripristinato
a qualcosa che dice, ma questo è un caso
di due tipi di automazione che interagiscono
attraverso un ambiente condiviso e io uso
questo come esempio di ciò che accade
quando automatizziamo un sacco di cose tutte
targeting per lo stesso ambiente possibile
ottieni l’automazione che inizia ad avanzare
l’un l’ altro o sono in conflitto tra loro
e può accadere solo in rari
circostanze come quando ce n’è una sola
copia di un libro, quindi di cosa abbiamo bisogno
si rendono conto è che nessuno di noi stanno lavorando in
questa sorta di cibernetica di prim’ordine
la cibernetica del primo ordine dell’ambiente è
sai un termostato che abbiamo un
uscita desiderata applichiamo qualche controllo
con feedback per arrivare al desiderato
uscita ma molto tempo fa la gente parlava
cibernetica di secondo ordine dove noi
incorporato il costruttore del dispositivo
nel sistema e otteniamo anche
alla cibernetica del terzo ordine in cui abbiamo
un ambiente comune che tutti hanno
operare in e questo è dove otteniamo
duellare BOT e libri da 23 milioni di dollari
sulle mosche quindi dobbiamo tenerne conto
anche di questo genere di cose, quindi cosa c’è
avanti fai attenzione alla diluizione come me
parlato di essere un po ‘diffidente nei confronti di
consulenze cercando di venderti a
devops culture non è uno strumento, non a
squadra separata sai che può essere fatto
mantieni la fiducia che può scalare
diventare abbastanza grande e con le parole di Jesse
Robbins non combatte stupido fai di più
fantastico grazie
questo è tutto
tu
Please follow and like us: