Andreas Grabner, Performance Advocate, Dynatrace e Brett Hofer, Senior Solution Architect Dynatrace analizzano i possibili scenari futuri in un mondo senza war room. Nella “war room” tradizionale, centro operativo nevralgico dell’azienda, operano molte persone di alto livello trascorrono ore nella stanza tutti i giorni ad analizzare i file di log. Invece di ideare nuove funzionalità, sistemano problemi vecchi e lavorano in uno stato di “debito tecnico”. Sfortunatamente, questo scenario è fin troppo comune: il compito che assorbe maggiormente un tipico team di sviluppatori è fissare i bug e non sviluppare nuove caratteristiche. Correggere i bug in produzione, infatti, è incredibilmente costoso: 50 volte in più rispetto a farlo all’inizio del ciclo di vita di sviluppo di un software.
Ma è possibile ideare un mondo senza war room? Forse non si potranno eliminare del tutto, ma certo si può pensare di eliminare la maggior parte degli scenari delle war room. Basandoci sulla nostra esperienza, l’80% delle criticità che vengono affrontate in produzione è causata da solo il 20% di problemi di natura diversa. Per questo motivo è possibile ridurre drasticamente gli scenari delle war room 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.
Nella war room troviamo coinvolte molte persone che spesso non sanno nemmeno se saranno in grado di risolvere il problema o se questo sia una loro responsabilità. Il monitoraggio dei dati dei file di log dell’infrastruttura, le denunce degli utenti, e altri elementi di allarme, mostrano tutti gli effetti del problema ma nessuno di essi rivela la causa. Vengono raccolte una moltitudine di informazioni sui log e i dati ad alto livello, senza fornire però le risposte alle domande che davvero contano.
Ecco le domande che è necessario porsi per allontanarsi dallo scenario war room: • Abbiamo a che fare con la lamentela di un singolo utente o con un problema che si ripercuote anche su altri? Sapere la misura del problema è fondamentale per poter definire delle priorità; • Il problema coinvolge la catena di distribuzione (per es. terze parti, ISP, Cloud Provider, servizi di hosting)? Conoscere il ruolo di ciascuna parte coinvolta nella catena di distribuzione permette di capire dove andare a cercare la responsabilità; • È coinvolta una transazione critica? E’ necessario monitorare sempre le prestazioni delle transazioni critiche; • Si tratta di un problema applicativo?Le applicazioni sono complesse, se il problema è al loro interno deve essere isolato e segnalato rapidamente agli architetti e agli sviluppatori; • C’è un codice mal-funzionante? Se il tempo di risposta dell’applicazione è lungo, la causa potrebbe essere 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? I problemi di performance possono riguardare le macchine virtuali o i container (come Docker), quando non sono correttamente dimensionati o le risorse tra le VM e nel singolo server virtuale non sono ben orchestrate. Se conoscete l’impatto della virtualizzazione delle applicazioni sulle prestazioni, per risolvere il problema dovrete rivolgervi ai vostri esperti nelle macchine virtuali e non agli sviluppatori delle applicazioni; • L’infrastruttura causa problemi? E se il problema non fosse l’applicazione ma la sua lentezza fosse dovuta alle risorse legate all’infrastruttura? Che cosa succede se la CPU necessaria 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 (thread, connessioni al database etc.), dimensioni, impostazioni di sicurezza o opzioni di log possono ripercuotersi sulle performance. Se l’AppServer è il problema, è necessario contattare un esperto IBM, Oracle o Microsoft.
Con questa visione ben in mente una war room affollata da 20 persone si potrà ridurre a 3 specialisti: uno sviluppatore, un responsabile di test e una risorsa operativa, che valutano insieme in modo approfondito i dettagli sulle performance e coinvolgono, di volta in volta, gli esperti di cui c’è realmente bisogno. Ponendosi queste domande è possibile eliminare la war room, identificare la fonte dei problemi con maggiore rapidità, individuare le priorità e trovare le soluzioni.
DevOps 2.0: è tempo di elevare il livello delle competenze Quando le pratiche DevOps non sono allineate, gli sviluppatori, i responsabili dei test e delle operation elaborano tutti visioni diverse e utilizzano metriche differenti per misurare le prestazioni. I loro obiettivi sono diversi! Mentre gli sviluppatori puntano a elaborare nuove funzionalità e avere più story point possibili per ciascuna delle storie completate durante gli sprint, chi si occupa dei test punta a trovare gli errori e rispedire agli sviluppatori l’app e i responsabili delle operation mirano a mantenere la stabilità a discapito del deployment di nuove applicazioni.
Se però tutti si pongono scopi diversi, come faranno a lavorare insieme per sostenere gli obiettivi di delivery continua all’interno dell’organizzazione? Agiranno in maniera indipendente uno dall’altro e, quando emergerà un problema, lo affronteranno con uno scarico di responsabilità reciproco. Per raggiungere gli obiettivi dell’azienda a livello applicativo è necessario rompere gli schemi di un pensiero “a silos” e far sì che tutti collaborino in un unico team: una squadra il cui principale obiettivo sia creare un software di qualità elevata.
Invece di trovare 10 difetti al giorno, chi si occupa dei test dovrebbe educare gli sviluppatori rispetto agli errori più comuni in modo che possano essere evitati sin dall’inizio. In questo modo potranno concentrare i loro test su attività maggiormente critiche — come la convalida o le prestazioni in larga scala. È tempo di elevare il livello delle competenze del team IT. Ognuno deve capire la portata delle sfide degli altri. Il DevOps di successo, è la capacità di garantire che tutti lavorino e condividano un insieme di strumenti e indicatori, concordando sulla definizione di ciascun indicatore e sul suo metodo di misurazione.
Gli strumenti di applicazioni performance monitoring — che si sono evoluti da puri strumenti di monitoraggio ad analisi della qualità rispetto a tutta la catena di distribuzione dell’applicazione — permettono di condividere una lingua comune. Offrono una visione unica e automatizzata delle performance, personalizzata per le esigenze di ciascun membro del team e diverso ruolo. Il team trasversale può sistemare un problema senza dover ricorrere a una war room!
Una vera evoluzione nella delivery continua delle applicazioni è ottenibile solo se chi si occupa dei test, gli sviluppatori e le operation assumono insieme la responsabilità di fornire all’utente finale software più veloci, senza comprometterne la qualità. In questo processo, gli strumenti tecnologici svolgono un ruolo di sostegno fondamentale: aiutano le aziende a diventare più efficienti, automatizzando le attività su tutta la pipeline. Per una delivery continua è necessaria, infatti, una qualità costante che può essere supportata dagli strumenti di monitoraggio delle performance durante l’interno ciclo di vita dello sviluppo — iniziando ancor prima che il codice sia controllato, sulla postazione di lavoro degli sviluppatori.
DevOps 1.0 ha rappresentato un ottimo percorso che ha applicato i principi abbracciati negli anni 80’ dal lean manufacturing al mondo del software. Ora è il momento di affrontare l’evoluzione verso i DevOps 2.0, accrescendo le competenze di tutte le persone coinvolte nell’organizzazione e che devono assumersi la responsabilità del prodotto finale. Le war room tradizionali dovranno rappresentare in futuro un’eccezione, non la regola! Mentre tutti noi faremo un passo in avanti dal punto di vista della qualità, da fornire in modo automatizzato, rispetto a tutto ciò che facciamo — requisiti, engineering, testing e deployment.
