Stiamo davvero assistendo a un passaggio da MLOps a AIOps? Secondo IDC, entro un orizzonte di medio-termine, quasi il 60% delle grandi global organization che hanno tradotto il Machine learning in processi operativi scalabili e industriali cominceranno a implementare sistematicamente i nuovi algoritmi nella gestione delle infrastrutture aziendali. Obiettivo: sopravvivere al caos gestionale di infrastrutture aziendali diventate troppo complesse, che espongono in misura considerevole le imprese a rischi sempre più gravi in termini di vulnerabilità di sicurezza, sostenibilità della tecnologia, costi di gestione. È bastato un decennio di tumultuosa innovazione e razionalizzazione dei costi per ritrovarsi con piattaforme tecnologiche nuove di zecca e dipartimenti IT destrutturati e ridotti all’osso, mentre gli continuano a chiedere efficienza, efficienza e ancora efficienza: ovvio che in un contesto del genere le persone dell’IT non riescono più a starci dentro, dovendosi mettere all’inseguimento di patch, configurazioni e requisiti impossibili. Nel lungo termine, diventa necessario ridurre di almeno il 70% l’operatività a basso valore aggiunto impiegando al meglio tutto ciò che l’automazione ci può dare.
Fin qui, tutto bene, ma sappiamo davvero come l’automazione ci può aiutare? Cosa vuol dire MLOps e AIOps? Forse ci siamo persi l’ultima puntata della storia e conviene fare un brevissimo riassunto delle puntate precedenti.
MLOps, come applicarlo al lavoro di data scientist e data engineer
Cominciamo da MLOps, ovvero, come trasformare la Data science da misteriosa bottega artigianale in un processo industriale standard, ovvero ancora, come abbiamo sentito raccontare di recente durante un convegno, “come prendere il DevOps e applicarlo al lavoro di Data scientist e Data engineer”. Facile a dirsi che a farsi, ma in realtà basta avere il “foglio del come” (come diceva Crozza nella sua interpretazione di Montezemolo). Una nuova rivisitazione di una vecchia storia: da Osterwald in avanti, vanno di moda i Canvas, lo sappiamo bene. Sebbene nessun framework possa davvero sistematizzare e razionalizzare l’animal spirit di un imprenditore o di un manager, tuttavia quando si affrontano questioni più o meno complesse avere uno strumento per gestire il processo creativo è assolutamente utile, quantomeno per stabilire un terreno comune di discussione con i propri partner e i propri colleghi.
L’ultima interessante rivisitazione di questo modus operandi è il Cross-Industry Standard Process for the development of Machine Learning applications with Quality assurance methodology (in breve, CRISP-ML(Q)). Da almeno due-tre anni si sente parlare di MLOps, ed effettivamente ci confrontiamo con un problema caratterizzato da una sua complessità sistemica, esattamente come il ridisegno di un modello di business. E quando si tratta di portare il Machine learning in produzione, considerato il grande numero di soluzioni, piattaforme e tecnologie esistenti oggi, disporre di una piccola guida per razionalizzare l’approccio e guidare l’organizzazione aziendale è un aiuto prezioso.
AIOps, usare il Machine learning per gestire le infrastrutture tecnologiche
Bene, se abbiamo una idea generale di cosa significa fare MLOps, adesso possiamo approfondire la nostra intuizione su cosa significa fare AIOps, ovvero, usare il Machine Learning per gestire in modo proattivo le infrastrutture e le piattaforme tecnologiche della nostra azienda.
A questo punto, di solito arriva la prima domanda, a metà strada tra il pragmatico e il provocatorio: “Ma è davvero così diverso dagli script che abbiamo sempre usato per automatizzare i processi IT?” La risposta in questo caso è a metà strada tra un sì e un no, perché se è certamente vero che da più di un decennio si usano RPA (ed euristiche varie) per gestire al meglio certi passaggi noiosamente lunghi e ripetitivi delle attività di configurazione delle infrastrutture, e altrettanto vero che la modernizzazione delle piattaforme, dai microservizi al serverless, ha portato l’IT aziendale a confrontarsi con architetture abbastanza nuove, abbastanza astratte e (forse) persino abbastanza intelligenti da interpretare meglio l’intento dei tecnici, anticipando bisogni e problemi di chi le infrastrutture le deve gestire.
Il passaggio ulteriore, che porta a un indiscutibile superamento del passato, è dato dalla possibilità di disegnare comportamenti molto più complessi usando piattaforme low-code/ no-code: AIOps vuol dire una telemetria molto più raffinata e granulare per avere una visibilità completa di cosa sta succedendo nelle nostre reti (con la produzione di una quantità enorme di dati su cui addestrare il Machine learning), AIOps vuol dire fare rilevazione delle anomalie, correlazione degli eventi per identificare nessi causali, anticipare tendenze nel consumo di servizi, dati, applicazioni, gestione automatica degli incidenti e delle azioni di ripristino, e così via.
Dunque, se state cercando di disegnare una intelligent enterprise (aka Cognitive Enterprise, o Data-Driven Company, o Autonomous Enterprise), ma il vostro dipartimento IT sta ancora litigando con l’assembler per gestire l’AS/400, cominciate a chiedervi se il legacy sia soltanto una questione di tecnologia, oppure un problema nel modo di pensare.
