CASE STUDY / 02
Vocalbot AI per il customer care di un operatore di telecomunicazioni
Sviluppo backend, affidabilità e ottimizzazione dei database per il customer care di un operatore telco su scala nazionale.
- Ruolo
- Sviluppatore backend · Amministratore database
- Contesto
- Telecomunicazioni · Customer care
- Periodo
- 2021 — 2024
Un’esperienza professionale descritta attraverso il mio contributo. Codice e documentazione del cliente non sono pubblicati in questa pagina.
Il mio contributo, in breve
- Sviluppo backend e amministrazione database per un vocalbot AI di customer care basato su IBM watsonx presso uno dei maggiori operatori di telecomunicazioni italiani
- Responsabile di una migrazione di 3 mesi dal database operativo dei flussi a un database Analytics federato, con routine PL/SQL per trasferire e rimodellare i dati a supporto di compatibilità e prestazioni delle dashboard
- Individuazione e risoluzione di un memory leak critico prima di un’interruzione in produzione; introduzione di circuit breaker Resilience4j, riducendo il tasso di errore della piattaforma da circa il 12% a meno del 3%
- Responsabile del refactoring del database durante la migrazione cloud (indici su tabelle di audit con oltre 500 milioni di record, connection pooling e partizionamento), riducendo i tempi di esecuzione delle query dell’85% e l’utilizzo CPU del database del 60%
La notte in cui un memory leak ha quasi fermato il servizio clienti.
Per tre anni e mezzo ho lavorato come sviluppatore backend e amministratore database su un vocalbot AI per il customer care, basato su IBM watsonx, per uno dei maggiori operatori di telecomunicazioni italiani.
Il cliente al centro del servizio
Un vocalbot di customer care è il primo punto di contatto tra il cliente e l’operatore telefonico: raccoglie la richiesta, la gestisce in conversazione e si appoggia ai sistemi aziendali per dare una risposta concreta. Per questo ogni scelta tecnica andava letta dal lato di chi chiama: un errore o un’attesa troppo lunga significano una richiesta non risolta e un cliente costretto a ripetere o a passare a un operatore. Ho lavorato sulla parte che il cliente non vede ma che ne determina l’esperienza: backend, tenuta sotto carico, tabelle di audit con oltre 500 milioni di record e database Analytics che alimenta le dashboard di analisi del servizio.
Un problema individuato prima del blocco
Durante il monitoraggio ordinario ho notato un andamento anomalo: consumo di RAM crescente, picchi di CPU nelle ore di punta e query sempre più lente. La causa era un modulo che apriva connessioni al database senza chiuderle correttamente, rischiando di bloccare il sistema da cui dipendevano le interazioni vocali con i clienti. Ho coordinato l’arresto controllato del servizio interessato, corretto il ciclo di vita delle connessioni e aggiunto soglie di timeout per inattività, senza fermare la piattaforma. In seguito ho promosso il monitoraggio continuo dei pool di connessioni come pratica ordinaria e introdotto circuit breaker con Resilience4j, portando il tasso di errore complessivo da circa il 12% a meno del 3%.
Migrare sul cloud ha richiesto di rivedere le ipotesi di partenza
Nel passaggio dall’infrastruttura on-premise a IBM Cloud sono emerse inefficienze negli accessi al database che prima non erano visibili. Le alternative erano tre: lift-and-shift, refactoring dello schema o riscrittura del livello di orchestrazione. Ho sostenuto il refactoring sulla base dei dati reali di esecuzione: query oltre gli 8 secondi diventavano colli di bottiglia sistematici e connessioni inefficienti rischiavano di aumentare significativamente i costi infrastrutturali. Il lavoro su indici mirati per tabelle di audit con oltre 500 milioni di record, connection pooling, partizionamento e riscrittura delle query ha ridotto i tempi di esecuzione dell’85% e l’utilizzo CPU del database del 60%.
Un’altra migrazione, una sfida diversa
In tre mesi ho guidato la migrazione dal database operativo dei flussi a un database Analytics federato, sviluppando routine PL/SQL per trasferire e rimodellare i dati, garantendo compatibilità ed efficienza per le dashboard a valle.