 Io sono Matteo Combi e sono un solution architect presso sia. Con me c'è Nicola Nicolotti che ha affrontato con me e con altre persone un percorso di introduzione della piattaforma OpenShift presto la nostra azienda. Noi oggi siamo qua non tanto per raccontare delle particolarità tecniche e soluzioni particolari che abbiamo scelto di implementare nei nostri progetti ma perché abbiamo pensato fosse importante in un evento come questo dove la condivisione di esperienza dovrebbe essere una delle cose principali che affrontiamo quella che è stata la nostra esperienza è quello che è stato necessario modificare a livello di processi aziendali a livello di organizzazione perché sia per chi non la conosce non è propriamente una startup, è un'azienda consolidata è un'azienda che ha dei processi ben definiti, dei valori in cui si riconosce e quindi per provare a derogare in modo diverso dei servizi è stato necessario intervenire non soltanto dal punto di vista tecnologico ma anche dal punto di vista più umano, più di processo, più di organizzazione Molto brevemente i progetti che siamo andati a scegliere per essere erogati su questa piattaforma sono stati due verso la fine del 2017 emersa un po' questa necessità da più parti di dover erogare in un modo diverso da quello tradizionale a cui eravamo abituati due progetti un primo in ambito PSD2 per prepararsi a quello che sarebbe stato l'entrata in vigore della PSD2 che è andata in onda pochi giorni fa quindi con necessità di riduzione del time to market, aumento della flessibilità mentre un altro progetto che ho seguito più direttamente ha riguardato il refacto di un ghetto di pagamenti con necessità di elevata scalabilità e stabilità del sistema Per PSD2 per introdurre un attimino il progetto molto ad alto livello le caratteristiche sono state quelle di avere la necessità di esporre facilmente i propri servizi l'integrazione con servizi di terze parti accelerare lo sviluppo anche di questi servizi e degli ambienti dove fosse possibile sperimentare e pensare con la collaborazione di più soggetti delle API quindi provare a vedere cosa succede, se la soluzione va bene si va avanti, se no ci si ripensa Questo progetto è stato ad alto contenuto tecnologico e infrastrutturale perché è un progetto PCI compliant, ha visto l'introduzione di un API Gateway come Triscale c'è stato molto focus sulla sicurezza, sulle personalizzazioni a livello di rete come sulle F5 sulla gestione dei certificati Mentre l'altro progetto ha visto diverse complessità dal punto di vista software Abbiamo utilizzato un cluster H messo su OpenShift che non è stata un'operazione proprio semplice Abbiamo avuto una richiesta di scalabilità, di reggere a picchi di traffico, prestazioni elevate e la riduzione se non l'annullamento dei tempi di downtime in fase di rilascio Come obiettivi tecnici, quindi riassumendo l'implementazione di API Management da una parte cluster H dall'altra, mentre ci siamo dati anche degli obiettivi non tecnici ridurre i tempi di rilascio per tutti i progetti e favorire anche la collaborazione tra Dev e Operation che in un'organizzazione un po' più tradizionale sono sempre state due realtà abbastanza divise tra loro Questo abbiamo cercato di raggiungerlo creando automatizzazione delle procedure di rilascio e anche cercando di dare della standardizzazione su diverse procedure per rendere il lavoro più semplice Inizialmente per raffrontare questo percorso abbiamo mantenuto un approccio molto, come dire, soft nel senso che non è stato possibile anche per dei vincoli temporali di progetto effettuare un grande stravolgimento di ruoli, modalità di lavoro e di competenze Man mano che questa parte di progetto andava avanti però sono emersi le prime difficoltà e quindi affronte delle prime difficoltà emergono anche delle domande al di là poi di quello che si legge sui vari manuali, su come si affronta il DevOps, eccetera ci si chiede cosa stiamo sbagliando, come altri che hanno affrontato problemi analoghi nostri come le verranno risolti io ho avuto la fortuna di confrontarmi anche con diverse persone provenenti da realtà simile alla nostra e il fatto di aver riscontrato anche in altri gruppi, in altre aziende delle difficoltà un po' è stato come dire fonte di, cioè ha rincurato, ci ha dato un po' delle conferme perché comunque abbiamo capito che ci sono le teorie ma poi per applicare realmente un cambiamento a livello di processi, a livello di gestione dell'innovazione è necessario trovare qual è il proprio equilibrio, quindi cercare di calare queste best practices in quella che è la realtà aziendale nonostante ciò dopo alcuni mesi abbiamo iniziato, siamo riusciti a portare le prime funzionalità in produzione che funzionavano anche abbastanza bene, ma alcuni problemi sono comunque rimasti perché comunque una certa difficoltà nelle rogare i servizi legate alla scarsa conoscenza delle piattaforme c'era rimasta, avevamo problemi che rimanevano fermi nei corridoi nel senso che erano quei problemi magari legati a competenze cross quindi un team non aveva acquisito quella competenza in più che serve per erogare su una piattaforma come OpenShift l'altro nemmeno i problemi rimanevano lì senza avere una soluzione vera e propria c'era anche una certa mancanza di empatia magari nel gruppo perché appunto rimanendo su un'organizzazione molto suddivisa si nescano quelle dinamiche di conflitto tra i vari gruppi e legato al primo punto non c'erano comunque quelle competenze transversali che permettevano di gestire in modo tranquillo e sereno i servizi in un sistema realmente in produzione quindi verso settembre dell'anno scorso si è deciso che era necessario che questo approccio non bastava ma era necessario introdurre un cambiamento io ho cercato di rappresentare in una timeline questo cambiamento che è avvenuto a fine del 2018 questo per rappresentare il fatto che da quando abbiamo iniziato a gestire in modo diverso l'approccio ai progetti e alle orogazioni di questi sistemi sono state completate molte più attività con una conoscenza maggiore e siamo riusciti a traguardare l'ambiente di produzione per entrambi i progetti che ci eravamo prefissi di migrare sulla nuova piattaforma centrando le date di rilascio come l'abbiamo fatto ve lo spiega adesso Nicola a cui lascio la parola Grazie Matteo, buongiorno a tutti, io mi chiamo Nicola Nicola Ecolotti, lavoro in Sia e nella divisione IT operation quindi sono diciamo la rocazione rispetto praticamente a sviluppo Ora che cos'è l'ITim? è una nota serie televisiva, in realtà non lo è ITim non è altro che un gruppo Agile che nasce in Sia come risposta alle problematiche di integrazione dei due servizi quindi PSD2 e l'altro servizio di pagamenti che dovevano essere praticamente aspettati e erogati sulla piattaforma OpenShift. Uno dei motivi per cui l'azienda ha puntato su OpenShift è ed era quello di ravvicinare lo sviluppo all'erogazione, questo per rispondere al cambiamento che è un requisito diciamo molto spesso richiesto dallo sviluppo piuttosto che avere una piattaforma che fosse stabile e questo invece è un mandatore invece per l'erogazione in realtà l'adozione di OpenShift all'interno dell'ecosistema Sia quindi fatto di persone, strutture, valori piuttosto che di processi è stata come una cassa di risonanza, ha amplificato la distanza tra sviluppo e erogazione e ha messo soprattutto in luce tutti quelli che sono i limiti derivanti da un approccio waterfall dei progetti piuttosto come diceva bene il Prima Matteo, la mancanza di un nuovo condiviso. Molto spesso questa mancanza di nuovo condiviso che cosa porta? Porta le diverse area di competenza a occuparsi soltanto dei problemi di pertinenza e tutto ciò che è in mezzo molto spesso non viene preso in considerazione e l'està riparcheggiato come diceva Matteo nei corridoi. A questo punto nasce le team, le team quindi nasce come risposta dell'azienda principalmente per raggiungere un obiettivo di business, essere in produzione nelle date previste, senza nessuno sconto e quindi cosa eredita le team? Eredita appunto le date di go live, eredita lo sviluppo del software quasi ultimato quindi non era più possibile tornare banalmente indietro per apporre quelle correzioni necessarie eredita una infrastruttura open shift 3.9 perfettamente funzionante e poi una serie di problemi o presunti tali perché a questo punto bisogna capire se i problemi erano veri oppure non lo erano quindi le team parte da questa condizione e da questo contesto con l'aggravante di non avere persone dedicate. Ora i primi passi delle team, potete immaginare quella che era la situazione insia è stato più su un modello di una task force piuttosto che come un team agile questo ci ha permesso al nord del vero di risolvere alcuni problemi come per esempio la perdita di log su open shift piuttosto che alcuni problemi di performance il problema qual era che il gruppo veniva ingaggiato e le persone ingaggiate erano tutte committate alle risoluzioni del problema e non veniva preso in considerazione invece quello che era il raggiungimento dell'obiettivo di business andare in produzione. Il cambiamento ci è stato quando il team per un momento ha sospiso di attività e ha cominciato a mappare le attività piuttosto che le problematiche utilizzando come il valore di business che è la risoluzione di quel problema che il portare a termine un'attività avrebbe avuto considerando anche i rischi ragionando con questa nuova scala di valore che cos'è successo è successo che la prima cosa, un atto di discontinuità la prima cosa che lei team ha deciso di fare era quello di fare un upgrade della piattaforma tecnologica di open shift da 3.9 una piattaforma funzionante dove erano già cominciati i primi passi di integrazione alla 3.11. Questo per un motivo molto semplice la release 3.9 era in scadenza di supporto abbiamo deciso di fare un passo in avanti e muovere da poter sfruttare a pieno quello che era il supporto dell'ingegneria di Red Hat accanto a questi momenti, diciamo, tecnici sono stati momenti più formali e in questo caso deve essere sincero anche supportati dall'ufficio del personale uno di questi è stata la dichiarazione del nostro manifest in cui il team ha deciso di dichiarare in maniera diciamo formale quelli che erano i suoi obiettivi e questo l'ha fatto principalmente perché si voleva essere visibili non come un gruppo che si muove in maniera a pattuglie che praticamente interviene in quelle che sono le attività degli uffici volevamo essere anche trasparenti e misurabili per far questo il team ha cominciato a darsi dei ruoli quindi abbiamo il team leader, un product owner piuttosto anche il team di sviluppo e ha supporto anche i project manager che sono diciamo a servizio oppure il vecchio modello di gestire i progetti in questo caso una grande importanza è stato appunto il ruolo del product owner a queste figure è stato assegnato il compito di praticamente definire le attività e soprattutto trasmettere agli altri componenti del team il valore che quell'attività avrebbe avuto nel contesto diciamo ai fini quindi il raggiungimento e i obiettivi di business inoltre le team si è dato anche degli strumenti e degli eventi ha deciso di riunirsi su base settimanale e la pianificazione delle attività era su base settimanale ha deciso di utilizzare confluence e gira come quindi strumenti per la documentazione e il task management e infine all'interno dell'act of directorie aziendale è stato scelto, è stato fatto, è stato creato un gruppo devop teams banalmente che dava, che dà l'opportunità a tutti i membri del gruppo di poter accelere banalmente ai sistemi di altri uffici in questo modo ad esempio un DBA poteva accedere ai log di sistema di open shift piuttosto che ai log dell'applicazione quindi gli obiettivi che volevamo raggiungere erano quei della visibilità trasparenza e essere soprattutto misurabili ora come abbiamo promosso le pratiche agile insia i modelli diciamo possono essere tanti o Kanban e Scram sono diciamo quelli di riferimento il tema ha deciso di utilizzare prevalentemente modello Kanban questo perché è un modello meno restrittivo da meno avvincoli e diciamo permette in modo graduale di cambiare le cose e permette anche alla gente di lavorare in maniera diciamo quasi più naturale rispetto a quello che era il modo di lavorare insia questa qui diciamo che è una slide che mostra la nostra Kanban board e poi abbiamo un'altra che la Scram board in realtà ci siamo anche sperimentati in quello che nello Scram è definito come sprint questo l'abbiamo fatto in pochi momenti ci siamo quindi sperimentati in questo e l'abbiamo fatto quando la funzionalità o l'incremento che le volevamo rilasciare era tale da richiedere uno sforzo corale da parte di tutto il tema questa slide invece è diciamo che rappresenta un certo senso il grado di maturità che a un certo punto il tema è riuscito ad avere ovvero a un certo punto la pass Openshift è stata sua volta considerata come un prodotto e lasciato in passare il termine è successo che alcuni componenti del team sono stati promossi a product owner di Openshift a questi è dato il compito di aumentare le funzionalità di Openshift in modo da aggiungere servizi al servizio dei servizi erogati immagino per esempio un sistema di vault per mettere in sicurezza le credenziali piuttosto che la possibilità di utilizzare degli operator la seconda cosa che fa queste due persone è quella di intercettare le necessità di tutti gli altri team che richiedono Openshift è vedere se il loro bisogno viene realmente soddisfatto dall'utilizzo quindi della piattaforma Openshift ora i KPI è chiaro che gira al suo interno tantissimi indicatori e diciamo oggi ne presento tre quelli che per me sono più unificativi questo qua è il team workload questo dimostra come le attività hanno avuto impatto o su diverse area organizzative quindi sono stati impattate lo sviluppo chi gestisceavesse Triscale piuttosto che il testing e il monitoraggio il rosso invece c'è una voce product backlog che invece non afferisceй a nessun ufficio in product backlog vengono raccolti l'effort che i product owner hanno dovuto le attività legate al product owner nella generazione e popolamento del product backlog e il suo continuo raffinamento questo per dire che la metodologia Agile non consiste solo in eseguire attività ma consiste in sapere le spiegare e dettagliare quest'altra slide indica come il prodotto avuto impatto sulle attività delle team quindi è questo il motivo per cui OpenShift a sua volta è considerato un prodotto perché le attività che dobbiamo fare su OpenShift sono state pare a quelle che dobbiamo fare sul servizio per portare in erogazione questa slide per me è la più significativa perché mostra l'evoluzione e stati che il team ha attraversato il primo è la fase appunto di popolamento del backlog quando il team si è fermato e ha deciso che cosa voleva fare la seconda parte è quella di studio in questa seconda fase il team si è sperimentato, si è formato e ha cominciato a creare le sue dinamiche la terza parte è quando il team ha cominciato a performare quindi a produrre valore una cosa importante sono state segnate le due date di go live questa dimostrazione del fatto che nonostante ci fossero quindi degli appuntamenti ben precisi il team non ha subito sostanziali, l'attività del team non ha subito sostanziali cambiamenti è andata a regolare come se non la fosse assorbito in pratica le date di produzione che molto spesso sono quei momenti in cui si genera più confusione oppure più frenesia il DevOps, nel manifest si è fatto riferimento al DevOps il DevOps è quello dove l'errogazione tende in particolare dotarsi di strumenti che permettono diciamo un delivery più veloce più sicuro e anche più frequente al momento stiamo lavorando per portare in pista in erogazione questa soluzione in cui abbiamo un Jenkins interno OpenShift per la Continuous Integration mentre una pipeline Jenkins esterna che ci permette di deployare le configurazioni piuttosto che le immagini sulle diverse piattaforme OpenShift di test piuttosto che di produzione ora, ritornando a quello che diceva prima Matteo OpenShift per noi è stata la possibilità di erogare quindi su una piattaforma diciamo che permette di avvicinare lo sviluppo al erogazione OpenShift per noi è stato anche i theme e i theme poi all'interno delle organizzazioni sia si è tradotta in sia Agile il personale per dire ha cominciato una serie di attività e questa è la loro roadmap che ha attraverso il quale quindi promuovere all'interno della nostra organizzazione quelle che sono le metodologie e gli approcci Agile Ho finito, vi ringrazio per l'attenzione