Automazione del processo di remediation: soluzione automatica di anomalie frequenti su server in Intesa Sanpaolo Group Services S.c.p.A. = Remediation Process Automation: automatic solution for frequent server anomalies in Intesa Sanpaolo Group Services S.c.p.A.

Il presente elaborato mira a ripercorrere i passi principali del “Progetto Self-Remediation” condotto in Intesa Sanpaolo Group Services S.c.p.a. – Direzione Sistemi Informativi. La mission del progetto risulta l’introduzione della scoperta e della risoluzione automatica di anomalie frequenti su server la cui soluzione manuale risulta ripetitiva e a basso valore aggiunto. Nel Capitolo 1 vengono introdotti l’iniziativa di innovazione sponsor del progetto e l’ambiente di svolgimento dello stesso. Un vocabolario comune viene definito e viene presentata l’infrastruttura tecnologica base della Direzione Sistemi Informativi. Vengono poi definiti e contestualizzati gli obiettivi principali del progetto, tra cui la riduzione dei ticket manuali, l’ottimizzazione delle Operations e l’aumento di disponibilità dei servizi informatici. Il Capitolo 2 introduce la squadra di partecipanti al progetto, definisce inoltre i prerequisiti ed i vincoli. L’architettura di sistema dell’automazione viene spiegata nella sua suddivisione a quattro livelli sia dal punto di vista logico che tecnologico. Le componenti di Monitoraggio, Orchestrazione, Schedulazione ed Azione sono approfondite dal punto di vista delle attività che hanno in carico e della scelta tecnologica effettuata. Viene poi presentato un primo design del processo automatizzato finale. Il Capitolo 3 spiega l’analisi condotta sui ticket per estrarre le anomalie più frequenti e automatizzabili. Inizialmente viene definito il perimetro dei ticket analizzati e vengono spiegati i parametri valutati. I ticket vengono classificati, qualitativamente e quantitativamente analizzati rispettando i punti di attenzione definiti. Dall’analisi dei ticket le anomalie di Weblogic Server Down e Java application Out Of Memory risultano quelle più frequenti ed altamente ripetitive, con basso valore aggiunto. I Capitoli 4 e 5 presentano rispettivamente l’AS IS ed il TO BE del processo di soluzione delle anomalie, pendendo in considerazione tre principali punti di vista: tecnologico, sia hardware che software; organizzativo, con l’aiuto del Linear Responsibility Chart; funzionale, attraverso l’utilizzo di Class Diagram e BPMN. Il Capitolo 6 spiega l’implementazione delle quattro componenti principali, facendo riferimento alle scelte ed ai vincoli introdotti nel Capitolo 2, sfruttando le molteplici funzioni dei vari prodotti e sviluppando personalizzazioni. Partendo dal tuning del monitoraggio, passando attraverso la definizione dei flussi di orchestrazione ed il deploy dei job di schedulazione, fino all’invocazione dell’azione risolutiva. Essendo la componente di “Azione” interamente sviluppata, viene presentata la logica degli script realizzati ricalcando i passi svolti manualmente nell’AS IS del processo. Il capitolo si conclude con la spiegazione dell’interazione tra le componenti e delle loro strutture dati con riferimento all’Appendice per i dettagli sul codice e sulle strutture. Il Capitolo 7 valuta i risultati finali del “Progetto Self-Remediation” facendo inizialmente un confronto tra i tre punti di vista introdotti nel Capitolo 4, Capitolo 5 e poi definendo e valutando KPI Generali, di Efficienza, di Qualità e di Servizio. A questo punto una valutazione finale può essere fatta e supportata quantitativamente dal confronto dei KPI. Vengono infine evidenziati i punti di maggior successo del progetto. Il Capitolo 8 conclude l’elaborato spiegando come gli obiettivi inizialmente definiti siano stati raggiunti co