[section_title title=Addio War Room, benvenuti DevOps 2.0! – Parte 1]
A cura di Andreas Grabner, Performance Advocate, Dynatrace e Brett Hofer, Senior Solution Architect Dynatrace
Un mondo senza war room
Nella “war room” tradizionale, centro operativo nevralgico dell’azienda, 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.
Allontanarsi dalla war room grazie alle domande giuste
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.
Scopri l’universo delle pratiche DevOps 2.0 alla pagina seguente
