I read The Phoenix Project and I loved it! | SLIDES

Hai letto The Phoenix
Project e lo hai adorato.
E adesso?
Matteo Emili
@MattVSTS
[email protected]
1
Sponsors & Organizers
getlatestversion.it
Chi sono?
• Visual Studio and Development Technologies MVP (VSALM)
• Professional Scrum Master 1
• Community enthusiast!
• DomusDotNet, GetLatestVersion.it in Italia
The Phoenix Project
• Un regalo di Natale 
• Narrativa, ma non proprio narrativa…
• Si legge in un weekend
• Linguaggio a volte tecnico, ma
concetti trasversali a diverse industrie
e settori
4
Di che parla?
• Bill Palmer e’ IT Manager di Parts Unlimited, un produttore di ricambi per automobile
• E’ promosso a VP di IT Operations
• Ci sono problemi enormi ai sistemi della sua azienda (roba seria – pagamento degli
stipendi, POS e sistemi di incasso dei punti vendita)
• C’e’ un progetto (in ritardo e oltre il budget da sempre) che deve essere rilasciato per
salvare l’azienda
• In caso di fallimento rischia l’outsourcing del dipartimento
Ha un eccellente finale…
• …di cui non faro’ spoiler 
• Dopo averlo finito Domenica sera, sentirete il bisogno di implementare le strategie di
Bill
•
•
•
•
So cosa ha fatto!
Conosco le sfide e gli ostacoli che ha affrontato!
Posso farcela!
DevOps qualunque cosa!
• Ma il Lunedi’ mattina tornate ai vostri deploy di Venerdi’
pomeriggio e ai porkaround per tenere tutto insieme…
Cosa potete fare adesso?
• Tutte le situazioni descritte nel libro sono realistiche
• Non si puo’ cambiare un’organizzazione (2+ persone) in un giorno
• Il libro ci introduce subito a tre problem critici nel 100% delle aziende
• Colli di bottiglia
• Mancanza di comunicazione
• Barriere
• Questi problemi si possono superare con un approccio
lontano dai riflettori
• Non pensate di mostrare qualcosa al team finche’ non ci sono certezze
Sotto coi colli di bottiglia!
I colli di bottiglia nel libro
• Brent e’ il guru del dipartimento IT e tutte le richieste sono dirette a lui, da tutti, su tutto!
• “…una roba semplice da massimo 30 minuti”
• E’ una enterprise – tanti team, gruppi, approvazioni, politica
• Non c’e’ virtualmente Change Management nonostante cio’
• Non c’e’ modo di implementare un piano di condivisione del know-how, nonostante ci siano delle
persone assunte per questo scopo
• Brent continua a rimbalzare da progetto a progetto e non riesce a spendere tempo su Phoenix
• Brent e’ il collo di bottiglia!
Automazione!
• Dove possibile si deve
automatizzare
• PowerShell, Bash, …
• L’automazione riduce gli errori
umani, e’ prevedibile e libera tempo
per altre attivita’
• Si rimane responsabili, ma se se il
compito non cambia automatizzare
e’ la scelta migliore
Quindi, come posso iniziare a sbrogliare
questa matassa?
• “Non si puo’ cambiare cio’ che non si puo’ misurare”
• In Build-Measure-Learn la fase di Measure e’ la piu’ importante
• Avere delle metriche ben definite e misurare sono l’unico modo imparziale di ottenere
evidenza di qualcosa da cambiare o migliorare
• Solo le metriche vi diranno se la direzione e’ giusta, quindi e’ fondamentale che siano
corrette
• ‘Perche?’
• Estendere il prodotto per includere quello che davvero conta
• Ridurre costi di manutenzione
• Comprendere ed essere proattivi su potenziali problemi
Belle chiacchiere…cosa posso
materialmente utilizzare?
• Log ovunque per avere una base di dati grezzi da studiare
• Insight personalizzati sulle nostre metriche
• Application Insights, Google Analytics, New Relic, Splunk, HockeyApp
• Utilizzarli per imparare rende la prioritizzazione piu’ semplice
• L’obiettivo e’ l’imparzialita’
• Solo questo puo’ portare ad un nuovo modo di approcciare il management (Evidencebased Management)
La chiave dell’utilizzazione delle risorse
• Non possiamo scaricare tutto su una sola persona
• Bill ha messo una Kanban Board intorno a Brent come soluzione di ripiego
• Funziona per un po’, ma poi arrivano altri problem
• Se una risorsa e’ vicina al 100% di utilizzazione (firefighting) e’ molto probabile che la
vostra richiesta aspettera’ un tempo indefinito
• Come posso ridurre l’attesa da indefinita a qualcosa di accettabile?
Comunicazione, cosa NON fare
• Non tirate fuori un nuovo Sistema di Change Management dal nulla
• Funziona nel libro? Si. Ma solo per questi motivi:
• Non avevano alcun Sistema di Change Management, credevano di averlo ma nessuno lo
utilizzava!
• Avevano una persona (Patty) a tempo pieno solo per questo
• Necessitavano di una infrastruttura per via della composizione aziendale
Piuttosto, meglio fare questo…
• Piccole vittorie e grossi ritorni, spesso fuori dal percorso principale
• Automatizzare porta eccellenti miglioramenti di qualita’ – condividiteli col team
• Se ogni membro del team lavora su cose differenti, regolari meeting di aggiornamento
del gruppo
•
•
•
•
Overhead minimale
Un minuto a testa
Ottimo modo di condividere esperienze e best practice
Incoraggia alla condivisione e al miglioramento personale
Suona troppo semplice?
• Il mio capo ha iniziato a farlo un anno fa
• Lavoriamo tutti in team differenti ed isolati, non ci sono interazioni regolari
• Sviluppo per prodotto A, B e C
• Supporto ed escalation per X, Y e Z
• Agile, ALM e DevOps (me )
• Call di aggiornamento ogni Giovedi’ alle 11, un minuto per area funzionale (prodotto)
• Dopo un periodo di assestamento sono iniziate le domande e i suggerimenti
spontanei fra colleghi che altrimenti non avrebbero avuto motivo di collaborare
Ancora troppo semplice?
• Io ed altri abbiamo iniziato ad automatizzare attivita’ tipicamente manuali
• Erano task che richedevano dati che nel 99% dei casi venivano solamente consultati
e non avevano alcun seguito (dieci minuti al giorno?)
• Ora ottengo un report via mail che posso condividere o su cui posso velocemente
reagire
• Dieci minuti al giorno e’ quasi un’ora a settimana – un’ora di qualita’!
• Ho speso meno di un’ora per creare gli script
DevOps e’ un cambiamento per l’intera
organizzazione
• Si inizia con piccoli cambiamenti out-of-band e si percepiscono dopo poco i
miglioramenti, sia in qualita’ che in approccio
• La collaborazione e la condivisione portano a migliori interazioni
• Le barrier iniziano a sbanire
• Si puo’ finalmente approcciare il lato di Delivery di DevOps
• Ricordiamo: le aziende valutano i cambiamenti sulla base del valore del ritorno
• Se non c’e’ aumento del ritorno ($$$, anche indirettamente) e’ la scelta sbagliata per l’azienda
La strada verso la Continuous Delivery
• Con l’abitudine ad automatizzare siamo gia’ a meta’ strada verso una mentalita’ di
Continuous Delivery
• Se state gestendo un qualche tipo di servizio un modo facile di proporla all’azienda e’
il seguente:
• Le manutenzioni manuali sono altamente prone ad errori umani
• I ripristini manuali sono molto costosi in termini di tempo
• Downtime = costi elevati
Pacchettizazione
• Pacchettizzare le applicazioni per il deploy resolve il problema di unire tutti i
componenti utilizzati
• MSDeploy sta avendo un nuovo boom in questi giorni
• File zip con binari e configurazione parametrizzata
• E’ uno dei tre modi di pubblicare applicazioni in Azure
• Funziona allo stesso modo on-premise
Non e’ cosi difficile…
Infrastructure as Code
• Infrastructure as Code e’ il primo passaggio nella giusta direzione di fondamenta
DevOps nella Delivery
• I sistemisti spendono un mucchio di tempo installando server, creando VM, reti, …
• Rendiamoci(…gli) la vita piu’ semplice ed adottiamo un approccio gia’ standard per il
cloud
• Azure ARM
• Amazon CloudFormations
• On-premise ci sono molte alternative
• Chef, Puppet, PowerShell DSC
• Una volta che il provisioning dell’infrastruttura e’
automatizzato siamo gia’ a meta’ del viaggio
Database
• I database sono spesso dimenticati introducendo DevOps
• Tipico silo da rimuovere e unire sia a Development che Operations
• Ci sono strumenti specifici per integrare il DLM nella pipeline di Release, ma tutti
richiedono che sappiate quello che state facendo 
• Introdurre i DBA al Version Control, lavorare incrementalmente e in modo
riproducibile, usare package (.dacpac?)…tutte cose che gia’ conosciamo!
E il testing?
• Se qualcosa deve fallire, deve fallire velocemente e comprensibilmente
• Perche’ e come
• Usare Test Suite (sia automatiche che manuali) come mezzo di validazione e veicolo
di feedback
• Siamo ancora responsabili di quello che testiamo, e i test sono parte critica del
prodotto
• L’automazione viene introdotta anche nella fase di rimediazione – “se si rompe cosa
succede?”
Recap
• Prima le persone, poi i
processi, e gli strumenti
seguono
• Automazione, automazione,
automazione!
• Non solo tecnologia
Rimuovere
Iniziamo
con
colli
di bottiglia
out-of-band
• Mescoliamo
lepoco,
competenze
in un
senza
barriere
• mondo
Facilitare
L’automazione
la comunicazione
e’ sicura e ripetibile
•• Pacchettizzazione
delle
Iniziamo con
Usiamola
come
poco,
base
costruiamo
per costruire
applicazioni
indipendentemente
• incrementalmente
Stiamo
risparmiando
tempo di
dal’ambiente
di destinazione
• qualita’!
Mostriamo evidenze e raccogliamo
• Automatizzare
grandi
deploy di
dati
obiettivi
ed
utilizzabili
• Tutto
puo’ essere integrato in
infrastruttura
future pipeline
• Sempre testare, sempre avere
un’idea degli scenari che si
possono aprire
32