addio war room, benvenuto devops 2€¦ · che abbiamo imparato dalla produzione snella negli anni...

Addio war room, benvenuto DevOps 2.0 6 modi per migliorare la qualità e la velocità nel deploy delle applicazioni

6 modi per migliorare la qualità e la velocità nel deploy delle applicazioni© 2015 Dynatrace


2

Sommario

Pagina PaginaCapitolo Capitolo

3 Autori 9 Quali SONO le tue priorità?Mostrami il denaro

5 Dì addio alla war room Fissari I bug in produzione è follemente caro 11 Automatizza, automatizza, automatizza

Troppi dati e troppo poco tempo

4 Sintesi 10 “Passa la palla” alla postazione dei tuoi sviluppatori Per una delivery continua è necessaria una qualità costante

6 Fai le giuste domande E ottieni le risposte 12 Il tuoi compiti a casa

8 E’ tempo di alzare il livello delle competenzeMetriche differenti + strumenti differenti = differente visione globale


3

Best practices raccontate da due ragazzi che mangiano, bevono e respirano DevOps

Andreas Grabner ha esperienza di oltre 15 anni come architetto e sviluppatore nello spazio Java e .NET, ed è un sostenitore delle applicazioni altamente performanti. Frequenta assiduamente le maggiori communities di performance fornendo il suo utile contributo ed è spesso speaker nelle conferenze legate alla tecnologia. tecnologia.

Brett Hofer è appassionato di DevOps ed è specializzato in software complessi e “mission critical”. Con più di venti anni di esperienza — dal product designer all’architect solution al senior management — ha una visione dell’IT unica e a 360°

Andreas GrabnerPerformance Advocate, Dynatrace

Blog: blog.dynatrace.com Twitter: @grabnerandi

Brett HoferSenior Solution Architect Dynatrace

Blog: blog.dynatrace.com Twitter: @brett_solarch

Torna al menù principale

http://blog.dynatrace.com

https://twitter.com/grabnerandi

http://blog.dynatrace.com

https://twitter.com/brett_solarch

Sia che si chiami DevOps o in altra maniera, abbiamo visto molte aziende che cercano di seguire “il libro” per trasformare il modo in cui viene sviluppato, testato e implementato il software. Aziende come Facebook, Flickr, Etsy, Twitter, e Amazon hanno aperto la strada, e sono visti come gli Unicorni del DevOps”, ma molti falliscono perché non hanno la giusta organizzazione, cultura aziendale, e gli strumenti adatti.

La chiave per l’intero team — i tester, gli sviluppatori e le operations — sta nell’assumere la responsabilità di fornire software più veloci per l’utente finale, senza comprometterne la qualità. Gli strumenti svolgono un ruolo fondamentale di sostegno in questo: aiutano le aziende a diventare più efficienti, automatizzando le attività su tutta la pipeline.

DevOps 1.0 è stato un ottima strada per permettere alle persone di pensare alla trasformazione necessaria che abbiamo imparato dalla produzione snella negli

anni ‘80. Ora è il momento di evolvere a DevOps 2.0, aumentando le competenze di tutte le persone coinvolte nell’organizzazione e che devono prendere la responsabilità del prodotto finale.

Le war rooms possono essere l’eccezione, non la regola. E tutti noi dovremmo fare “shift left” quando si tratta di qualità. La qualità deve essere costruita in tutto ciò che facciamo — requisiti, engineering, testing e deployment — e il più possibile dovrebbe essere automatizzata.

In questo eBook, metteremo in luce quello di cui hai bisogno per continuare la trasformazione:

> Fare le domande giuste e ottenere le risposte corrette per comportarsi con efficienza quando c’è un problema

> Innalzare il livello delle competenze di sviluppo, test e operations per otterene qualità sin dall’inizio

> Definire un set di metriche comuni basate su obiettivi comuni e condivisi per fare ciò che i team bravi ed efficienti fanno bene: collaborare

> Identificare le priorità per il tuo business affinchè il team possa sapere con esattezza su cosa focalizzarsi e cosa è più importante

> Integrare continuamente le metriche di qualità come “gate” sulla pipeline, riducendo il debito tecnico e il lavoro non pianificato

> Automatizzare l’architettura, la scalabilità e le analisi sulle performance invece di restare immobilizzati con pile di file di log da spulciare.


4

Sintesi



5

Dì addio alla war roomFissare i bug in produzione è follemente caro

Mmm…. Mi chiedo come fosse il ritmo di deployment per questo ragazzo…

Ogni 2 settimane? Ogni 4 settimane? Trimestralmente?

Con un deployment in produzione ogni due settimane, i dati che aveva diventavano obsoleti al momento della sua “illuminazione”!

Sappiamo tutti che correggere i bug in produzione è incredibilmente costoso: 50 volte in più rispetto a farlo all’inizio del ciclo di vita di sviluppo.1 Pensate alla vostra war room tipica: un sacco di persone molto importanti e costose che siedono tutte in una stanza per giorni per analizzare file di log. Invece che lavorare in nuove funzionalità per il domain, stanno sistemando i problemi di ieri e lavorano creando un debito tecnico.

Sfortunatamante questo scenario è fin troppo comune: la maggior parte dello sforzo di un team dev tipo è passare il tempo a fissure bug invece che

sviluppare nuove caratteristiche, con pessimi software che costano oltre 60 miliardi di dollari all’anno.2

Un mondo senza war rooms? Non per essere esageratamente drastici, ma è possibile eliminare la maggior parte degli scenari delle war rooms.

Basandoci sulla nostra esperienza, l’80% dei problemi che vengono trattati in produzione, sono causati da solo il 20% di tipologie di problemi differenti. È possibile ridurre drasticamente gli scenari delle war rooms utilizzando i principi DevOps e monitorando attivamente ogni ambiente in tutto il processo di produzione utilizzando i corretti strumenti che individuano con precisione i problemi.

“Ho confuso gli stessi file di log a volte per settimane per estrapolare la relazione tra i diversi sistemi (…) prima di avere “l’illuminazione.” - RecklessKelly (Operatore)

in reddit

1. Barry Boehm, 2007 Equity Keynote Address

2. NIST (National Institute of Standards and Technology) http://www.computerworld.com/article/2575560/it-management/study--buggy-software-costs-users--vendors-nearly--60b-annually.html



6

Fai le giuste domandeE ottieni le risposte!

Ci sono molte persone convocate nalla war room che spesso non hanno idea se sono in grado di risolvere i problemi o se ne sono loro i responsabili. La “prova” (monitoraggio dei dati dei file di log dell’infrastruttura, le denunce degli utenti, etc) mostra i sintomi, ma non mostra nulla sulla causa del problema. Avere soltanto un sacco di informazioni sui log e i dati di alto livello, non ti dà le risposte alle domande che davvero contano.

Per allontanarsi da questo scenario, quale dovrebbe essere la “prova”? Quali domande dovresti porti?

E’ impattato il solo utente che si sta lamentando o lo sono tutti gli utenti?

E’ “solo” il CEO che si lamenta di un problema perché un report non funziona sul suo vecchio IE10? O è “solo” un utente finale dall’altro capo del mondo con una connessione remota? Sapere se il problema sussiste per piccoli gruppi o per un gran numero di utenti tutti in Cina, per esempio, è fondamentale per prioritizzare.

C’è un problema nella catena di distribuzione (per es. sui CDN, terze parti, ISP, Cloud Provider, servizi di hosting, network mobile)?

Le moderne applicazioni web rilasciano su una lunga lista di servizi attravero la catena di distribuzione. Conoscere l’impatto di ciascuna ti dice se devi andare a ricercare nel tuo data center o se devi invece chiamare Akamai o Facebook.

Un numero significativo di utenti in Cina

NON E’ SODDISFATTO

E’ impattata una transazione critica?

Quando il tasso di errore aumenta, si tratta di una transazione critica come ad esempio la ricerca? O non c’è importante perché è un BOT causato da errori mentre esegue la scansione di pagine che non esistono più? E’ necessario monitorare le performance su transazioni critiche.

Il problema è nell’applicazione?

Le applicazioni sono complesse. Se sai che il problema è all’interno dell’applicazione, devi isolare il luogo esatto in modo da poterlo girare velocemente ai giusti sviluppatori e architetti.



7

PerchèCome Cosa

Chi

Il problema è causato da un codice malfunzionante?

Se il tempo di risposta dell’applicazione è lento, una prima domanda dovrebbe essere se ciò è dovuto a un problema di codice. Si deve analizzare l’hotspot della performance a livello di codice per scoprire se la causa sono algoritmi inefficienti o una mancanza di best practice di codice e architettura.

Il problema è nella macchina virtuale?

Ci possono essere problemi di performance se le macchine virtuali (es. VMware, EC2, Azure) o i tuoi container (come Docker) non sono correttamente dimensionati o fanno la lotta per le risorse con un’altra macchina virtuale sullo stesso server virtuale. Se si conosce l’impatto sulle prestazioni della virtualizzazione delle applicazioni, saprete chiamare gli esperti VM, e non gli

sviluppatori di applicazioni, per risolvere un problema.

L’infrastrattura causa problemi?

E se non è l’applicazione stessa il problema, ma la lentezza dell’applicazione dovuta alle risorse legate all’infrastruttura? Che cosa succede se la CPU necessaria per eseguire il Garbage Collector non è disponibile perché la macchina è sovra-utilizzata? Allora è il momento di pensare a distribuire le applicazioni in modo diverso o a scalare l’infrastruttura.

Il problema è l’AppServer?

L’AppServer potrebbe essere la causa di problemi di perfomance dovuti a configurazioni scorrette o a un deployment corrotto. Parametri di risorse corretti (threads, connessini al database etc), dimensioni, impostazioni di sicurezza od opzioni di log possono

impattare sulle performance. Se venisse fuori che l’AppServer è il problema, sai che devi contattare il tuo specialista IBM, Oracle o Microsoft.

Con le risposte a queste domande, puoi eliminare la war room e identificare la fonte dei problemi rapidamente, individuare le priorità e trovare la

soluzione. Quindi, invece di una war room di 20 persone, avrai solo 3 persone — uno sviluppatore, un tester e un ragazzo delle operations — che valutano approfonditamente i dettagli sulle performance e che coinvolgono gli esperti di cui c’è bisogno. Interessante, no?

Fai le giuste domandeE ottieni le risposte!



8

E’ tempo di alzare il livello delle competenzeMetriche differenti + strumenti differenti = differente visione globale

Quando le vostre pratiche di DevOps non sono allineate, gli sviluppatori, i tester e quelli delle operations avranno ognuno una visione differente, e le loro performance saranno misurate da metriche differenti.

> Per gli sviluppatori: elaborare nuove funzionalità e completare quante più story point per sprint possibile

> Per i tester: trovare defezioni e rispedirle agli sviluppatori

> Operations: mantenere la stabilità piuttosto che fare deploy di nuove applicazioni

Se i loro obiettivi non sono gli stessi, come potranno mai lavorare insieme per sostenere gli obiettivi di erogazione continua della vostra organizzazione? Agiranno in maniera indipendente uno dall’altro e quando emerge un problema ci saranno molte dita puntate.

To reach your continuous delivery goals, you have to break down those team silos and get everyone on the same team: a team whose primary goal is to create great high quality software. It does no good to be throwing things over the wall with a constant cycle of: code, test, break.

E’ tempo di alzare il livello delle competenze del tuo team di ingegneri. Tutte le parti devono iniziare a capire le sfide degli altri. Un DevOps di successo, è la capacità di garantire che tutti lavorino e condividano un insieme di strumenti e indicatori, pur concordando sulla definizione di ciascun indicatore e come questo si misuri.

Gli strumenti di applicazioni performance monitoring — che sono evoluti da strumenti di puri sistemi di monitoraggio a strumenti che ora monitorano la qualità end-to su tutta la catena di distribuzione dell’applicazione — permettono a tutti di parlare la stessa lingua. Offrono una visione unica, automatizzata delle performance che è personalizzata per le esigenze di ciascun membro del team e ruolo. Quando qualcosa va storto, il team trasversale può sistemarlo insieme senza dover ricorrere a una war room.

I tester invece che trovare 10 difetti al giorno, devono educare gli sviluppatori su errori comuni in modo che siano evitati sin dall’inizio. Così possono quindi concentrarsi sulle attività più critiche — test di convalida e test delle prestazioni in larga scala.



9

Quali SONO le tue priorità?Mostrami il denaro

Sappiamo che questo ti è successo perché è successo anche a noi: il tuo team di ingegneri PENSA che ci sia un problema e brucia un sacco di soldi e tempo per sistemarlo MA...poi è venuto fuori che il business era preoccupato per un problema completamente differente. A volte tutto ciò che vedi è rosso. Ci sono più di 250 problemi ma come fare a analizzarli tutti e individuare il più importante?

Stabilisci le priorità dei problemi Gli strumenti per monitorare la user experience e le perfomance delle applicazioni possono essere utili per aggregare una grande quantità di dati su tutti i tuoi utenti attraverso la catena di distribuzione dell’applicazione. Essi forniscono analisi intelligenti che consentono di approfondire la causa dei problemi. Inoltre ti evitano anche di vedere tutti quegli indicatori rossi, individuando in anticipo i tipi di problemi che potrebbero portare a un problema di produzione grave, dalla prima linea fino alla catena di distribuzione.

Stabilisci le priorità delle implementazioni Gli strumenti di monitoraggio delle performance ti possono aiutare a stabilire le priorità delle implementazioni nella end user experience:

> I tuoi utenti seguono il percorso che ti aspettavi nella tua applicazione?

> Usano tutte le funzionalità?

Questi strumenti possono fornire una visibilità approfondita sul comportamento degli utenti, mettendo in evidenza le opportunità per migliorare il flusso di lavoro dell’utente e anche rimuovere il codice in modo da non dover costruire nuove funzionalità oltre

alla funzionalità che nessuno usa.

Grazie alla combinazione di tutti questi dati con le informazioni aziendali sulle transazioni, applicazioni e gruppi di utenti critici, il tuo team di progettazione sarà in grado di concentrarsi sulle cose essenziali, cioè sui problemi che costano di più in termini di vendite, immagine e la soddisfazione degli utenti.



10

“Passa la palla” alla postazione dei tuoi sviluppatoriPer una delivery continua è necessaria una qualità costante

Il rilascio continuo funziona (vedi ad esempio Amazon). Ma non può essere fatto a metà. Ricordi dal Capitolo 1 che il costo per sistemare i bug in produzione può essere fino a 150 volte superiore che se il bug viene scoperto prima nel ciclo di vita dello sviluppo.3

Per avere successo in una delivery continuativa, utilizza il monitoraggio delle performance per supportare una qualità costante attraverso il ciclo di vita dello sviluppo — iniziando ancor prima che il codice sia controllato, sulla stazione di lavoro degli sviluppatori.

Testo unico

1x

80%

100%

Testo unico

10x

80%

40%

Test di accettazione

25x

50%

20%

Test sulle performance

50x

40%

10%

Release

150x

40%

5%

% di Bug nel Software

Costo relativo per fissare un bugNumeri rettificati da A.Grabner

3. Barry Boehm, 2007 Equity Keynote Address

4. Amazon, 2012 Velocity Presentation

Amazon: una frequenza di deployment impressionante > Ogni 11.6 secondi con 23,000 deployment al giorno

> Hanno avuto il 75% di interruzioni in meno dal 2006, il 90% di interruzioni in meno al minuto

> Solo lo 0,001% dei deployment causa un problema4

Il costo per sistemare i bug aumenta esponenzialmente



11

Automatizza, automatizza, automatizzaTroppi dati e troppo poco tempo

A questo punto hai così tanti dati in entrata che probabilmente sei preoccupato di avere il tempo e le competenze di analizzarli tutti. Il bello dell’applicazioni performance management è che non hai bisogno di addestrare nessuno.

Una volta che hai lavorato con i team di business per determinare le priorità, identificate le metriche tecniche chiave e impostato i tuoi KPI, puoi automatizzare il monitoraggio delle performance. Per costruire una qualità costante nella catena di erogazione continua, è necessario determinare gli indicatori di qualità in ogni fase del processo. Questo approccio aiuta a rafforzare la sicurezza della rete, aiutando il tuo team a gestire le specifiche di cambiamento e individuare gli errori precedenti. E questo è un gran vantaggio.

Test di monitoraggio Analisi dei risultati Visibilità della qualità nel vostro strumento di compilazione

Testo unico Test di accettazione

Test sulle performance Release

Ti stai chiedendo quale genere di cose puoi automatizzare? > Mandare richieste di cambiamenti direttamente agli sviluppatori dopo un test di carico

> Rimandare indietro agli sviluppatori i problemi durante un test di integrazione

> Impostare degli alert quando i KPI o le SLA sono testate e violate


6 modi per migliorare la qualità e la velocità nel deploy delle application© 2015 Dynatrace

12

I vostri compiti

È ora di fare buon uso di queste best practice nella vostra ricerca per DevOps 2.0. Andate oltre: fat in modo che la war room sia un’eccezione e non lesinate sulla qualità! Automatizzare il più possibile e cercate di fare meglio, più velocemente!

Gli strumenti DevOps che amiamo

Ecco una serie di strumenti che favoriscono la collaborazione tra Product Management, Development, IT Operations e team di supporto tecnico.

> Change Controls — JIRA > Development — Eclipse > Source Control — GitHub > Build Automation — Ant and Maven > Configuration Management — Ansible, Chef and Puppet > Test Automation — LoadRunner and Selenium > Virtual Machines — Vagrant, Packer and VeeWee

Webinar replays

> 5 Key Metrics to Release Better Software Faster > DevOps: From Adoption to Performance

The blogroll

> IT Revolution’s DevOps > The Art of DevOps series > Software Quality Metrics for Continuous Delivery Part 1-3 > Dynatrace APM on DevOps > DevOps reactions – Enjoy some DevOps humor!

Recommended reading

> The Phoenix Project by co-author Gene Kim > The Speed of Trust by Steven Covey > Release It by Mike Nygard > Continuous Delivery by Jez Humble and David Farley > The Other Side of Innovation by Vijay Govindarajan


http://ow.ly/MXS8y

http://ow.ly/LABC5

http://itrevolution.com/devops-blog/

http://apmblog.dynatrace.com/2015/02/19/art-devops-introduction-landscape/

http://apmblog.dynatrace.com/?s=Software+Quality+Metrics

http://apmblog.dynatrace.com/?s=devops

http://devopsreactions.tumblr.com/

Learn more at dynatrace.com

Dynatrace è leader e innovatore della Digital Performance Platform e rende le informazioni sulle prestazioni digitali visibili e sfruttabili in tempo reale da chiunque in azienda e nell’organizzazione IT. La nostra passione: aiutare i clienti di tutte le dimensioni a vedere le proprie applicazioni e i canali digitali dal punto di vista dell’utente finale. Più di 7.500 aziende usano questo approccio per ridurre la complessità, migliorare l’agilità operativa e incrementare il fatturato offrendo una esperienza utente senza precedenti.

8.17.15 384_SS_ITA_jw

http://dynatrace.com

addio war room, benvenuto devops 2€¦ · che abbiamo imparato dalla produzione snella negli anni...

Documents