Collaborazione e Automazione fattori essenziali di ... · Piano d’azione per CIO 1. individua e...
33
[email protected] Collaborazione e Automazione fattori essenziali di business continuity del software custom AIEA - 28/10/2015 - Roma
-
Upload
nguyenkhuong -
Category
Documents
-
view
217 -
download
0
Transcript of Collaborazione e Automazione fattori essenziali di ... · Piano d’azione per CIO 1. individua e...
Collaborazione e Automazione fattori essenziali di business continuity
del software custom
AIEA - 28/10/2015 - Roma
lean software development and coaching-o-
continuous delivery | high availability | performancesecurity sensitive and high uncertainty domains
Lean thinking
■ Gestire al meglio il rischio di business attraverso l’applicazione di alcuni principi che mirano a produrre valore in modo sostenibile con il minimo sforzo e spreco.
■ Tre dimensioni● massimizzare il valore● ridurre il flow time● investire sulle persone
DevOps
■ Applicazione pratica dei principi lean
■ Approccio end-to-end allo sviluppo software, dall’ideazione all’esercizio, che enfatizza:● comunicazione● collaborazione● competenza● miglioramento continuo
■ Coinvolge e riunisce sviluppatori, QA, IT operations, security, management.
DevOps
■ Sviluppatori, QA, sistemisti coinvolti assieme nella progettazione e nello sviluppo● build for testability, operability & security (NFR)● allineamento degli obiettivi● feedback immediato
■ Sviluppatori, QA, sistemisti coinvolti in operations● accesso diretto alle informazioni necessarie● eliminazione degli handover● “You build it, you run it.” - Werner Vogels, Amazon CTO
■ Responsabilità condivisa
DevOps & Continuous Delivery
■ Automazione dei test
■ Automazione dell’infrastruttura di deployment● delivery pipeline, dal codice sorgente alla produzione● semplificazione del processo e degli step manuali● riproducibilità, consistenza e tracciabilità
■ Rilasci incrementali e frequenti, in produzione● anche molte volte al giorno, automaticamente● green/blue, feedback rapido, roll-forward
■ Monitoraggio continuo● visibilità in produzione● realtime, affidabile, significativo, comprensibile, contestuale
Esplorazione, feedback, apprendimento
■ Scambio di conoscenze e apprendimento mutuo
■ Cicli di feedback molto stretti
■ Creazione di un ambiente sicuro dove sperimentare
Benefici diretti per la Business Continuity
■ Frequenza degli incidenti / Qualità● feedback tempestivo dal QA durante lo sviluppo● maggiore copertura dei test, grazie ad un design mirato● maggiore consapevolezza del rischio tecnologico
■ Gravità dell’impatto● graceful degradation● threat modeling e mitigazione sono parte del processo
■ Tempi di rientro● monitor everything● disponibilità immediata delle competenze● accesso diretto alle informazioni ● processo rapido automatico di rilascio
Trend di adozione
■ Google, Amazon, Netflix, Etsy, Spotify, Twitter, Facebook, …■ Dynatrace, CSC, IBM, CA, SAP, HP, Microsoft, Red Hat, …■ GE Capital, Nationwide, BNP Paribas, BNY Mellon, ...
■ World Bank, Paychex, Intuit, …■ The Gap, Nordstrom, Macy’s, Williams-Sonoma, Target, …■ General Motors, Raytheon, LEGO, Bosch, …■ UK Government, US Department of Homeland Security, …
2014: 24% adottato, 64% in adozione a 2 e 5 anni
Vanson Bourne DevOps Report for CA, 2014
DevOps team sono altamente produttivi
30xfrequenza di
rilascio
8.000xdeploy lead time
più brevi
State of DevOps 2014 - 9,200 people from 110 countries
DevOps team sono altamente produttivi
2xprob. di successo
dei change
12xMTTR
più brevi
State of DevOps 2014 - 9,200 people from 110 countries
Organizzazioni ad alte prestazioni
2xprob. di superare obiettivi business
50%maggiore crescita
di valore di mercato su 3 anni
State of DevOps 2014 - 9,200 people from 110 countries, 355 S&P500 3Ys companies
5xprob. di essere
high perf, 12+ m
Le grandi aziende possono essere HiPerf?
State of DevOps 2014 - 9,200 people from 110 countries, 355 S&P500 3Ys companies
sì, anche se…>10k hanno il 40% in meno di prob rispetto a <500
Problemi?
■ “DevOps e continuous delivery introducono problemi per le attività di auditing, perchè le modalità di lavoro sono completamente diverse da quelle del tradizionale SDLC”
■ “Agile era già problematico (no acceptance testing alla fine, no raccolta requisiti all’inizio, meno documentazione) ma questo DevOps è ancora più radicale: ● decine/centinaia di rilasci al giorno!● no approvazioni!● no separation of duty!”
■ “Gli auditor devono lavorare su ambienti maturi e stabili”
■ “Nessun accordo condiviso su come debbano essere i requisiti di controllo di DevOps”
Paradosso Agilità - Stabilità
Goal: Ensure that standardized methods and
procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently to improve the day-to-day operations of the organization.
Paradosso Agilità - Stabilità
Goal: Ensure that standardized methods and
procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently to improve the day-to-day operations of the organization.
da “ITIL Change Management”- http://itlibrary.org/index.php?page=Change_Management
Un matrimonio possibile
■ Nessuna inconsistenza insormontabile
■ I metodi agili aggiungono flessibilità per● tenere conto della variabilità● migliorare la qualità● aumentare la velocità del ciclo
■ DevOps fornisce un grado di automazione superiore e maggiori controlli di monitoraggio rispetto agli ambienti tradizionali, con meno punti di errore
■ Maggiore visibilità è coerente con controlli migliori
Risultati delle Organizzazioni HiPerf /1
4xmeno rilievi ripetuti
da audit
3xmeno effort di
preparazione pre-audit
5xpiù prob di
identificare sec issue con controlli automatici
5xmeno prob che
incidente sia evento con danno
14xpiù change
autorizzati e implementati
50%meno prob che il
change fallisca
IT Process Institute
Risultati delle Organizzazioni HiPerf /2
10xmigliore MTTR su
incidenti Sev1
1/3di lavoro non
pianificato
8xnumero di progetti
completati con successo
6xnumero di
applicazioni gestite
IT Process Institute
Convergenze
■ Non sono gli auditor a dover “imparare” DevOps
■ Serve invece collaborazione tra dev, ops e auditor
■ Conoscendo le necessità di audit è possibile colmare il gap in modo naturale
Esempio di ambiente di controllo efficace con approccio DevOps /1
Rischi di business (BR) per Acme S.p.A.
■ BR1: down dei servizi online, con impossibilità di generare ricavi (disponibilità)■ BR2: dati e account degli utenti compromessi o resi pubblici (confidenzialità, sicurezza)■ BR3: transazioni online non corrette o compromesse (integrità)
Strategie di controllo (CS)
Rischio Control Strategy
R1. Vulnerabilità nel codice introdotta da sviluppatore (BR3, BR2)
CS1. Tutto il codice è validato prima di andare in produzione per prevenire comportamenti malevoli o incapacità
R2. Codice rilasciato in produzione produce una interruzione, degrado del servizio o errore sui dati (BR1, BR3)
CS2. Tutto il codice è validato prima di andare in produzione per assicurarsi che il servizio funzioni correttamente e che eventuali interruzioni possano essere risolte velocemente
R3. Accesso non autorizzato agli ambienti di produzione o pre-produzione con installazione di codice malevolo, modifiche o furto di dati (BR2)
CS3. Gli elementi dell’ambiente di produzione su cui il servizio gira sono configurati e gestiti in modo da prevenire accessi non autorizzati e/o identificarli e correggerli velocemente
Esempio di ambiente di controllo efficace con approccio DevOps /2
CS1: Tutto il codice è validato prima di andare in produzione per prevenire comportamenti malevoli o incapacità (inserimento di vulnerabilità e back-door)
a. tutto il codice è soggetto a peer review, in ottica di correttezza e aderenza agli standard di sviluppo aziendali. ● in base all’area di rischio associata alla specifica parte di codice, il codice proposto e i
relativi test automatici devono essere rivisti da almeno un altro sviluppatore. Per aree di rischio Elevate, è necessaria la review di un “esperto” designato dell’argomento
● le review sono tracciate dal sistema di source control● gli standard di sviluppo aziendali sono disponibili e basati su standard riconosciuti● le review includono la valutazione della bontà dei test automatici, rispetto agli standard
aziendali documentati per i test automatici● la procedura di change descrive quali aree del codice e dell’ambiente sono a rischio
Elevato. La procedura è disponibile a tutti.● ogni change richiesto dalla review prima del rilascio è tracciato nel backlog e assegnato● ogni altro change richiesto a valle del rilascio è tracciato come debito tecnico
Esempio di ambiente di controllo efficace con approccio DevOps /3
b. per assicurare l’esecuzione delle review e che i revisori siano “qualificati” è definito il seguente processo di review:● ogni check-in è assegnato dal sistema di source control a 3 sviluppatori a caso● i responsabili devono fare periodicamente review delle statistiche di review per essere
consapevoli dei tassi di accettazione e rifiuto● gli sviluppatori che fanno review frequentano corsi di secure coding e di peer reviewing
c. i Test automatici di sicurezza su codice e ambienti sono eseguiti all’interno delle pipeline di deployment (CS2)
d. i deployment in produzione sono associati ad un numero identificativo riportato nel sistema di ticketing. Il numero deve essere sempre utilizzato dagli sviluppatori all’interno delle pipeline di deployment
e. i deployment in produzione sono soggetti a log: azioni automatiche e manuali della pipeline, ticket corrispondenti, risultati di tutti i test automatici e manuali, note di rilascio, eventuali incident report, risultati delle peer review, autorizzazioni, …
f. il sistema di deployment richiede l’autenticazione e la verifica delle autorizzazioni prima di effettuare il deployment, con tracciamento che permetta di risalire alla persona che lo ha effettuato, con possibilità di double sign-off ove necessario.
g. ...
Piano d’azione per CIO
1. individua e risolvi i gap di competenza IT
2. definisci una roadmap3. investi in approcci al SW management, strumenti
tecnici, infrastrutture4. automatizza5. rimuovi le barriere6. integra e rinnova i sistemi legacy
beyond IT: the CIO as agility leader for the business“”
Keep CALMS and deploy
Culture
Automation
Lean
Measurement
Sharing
@damonedwards, @jezhumble, @botchagalupe
Referenze
■ Thoughtworks & Puppet Labs - 2014 State of DevOps Report
■ IT Process Institute - www.itpi.org
■ Vanson Bourne for CA, 2014 - DevOps: The Worst-Kept Secret to Winning in the Application Economy
■ Zend - The Transition to Continuous Delivery
■ Scott Hollis - Aligning Operations: IT – Business – Security
■ May Xu - When Enterprise Meets DEVOPS
■ PWC Technology Forecast, 2013 issue 2
■ Brian Fitzgerald, Klaas-Jan Stol - Continuous Software Engineering and Beyond: Trends and Challenges
■ Gene Kim - Keeping the auditor away
■ Bjarte Bogsnes - Beyond Budgeting - a management model for new business and people realities
