Premessa

La sigla IVR significa Intelligent Voice Responder. Sono quei simpatici sistemi che rispondono al telefono, rimbambendo il chiamante elencando una serie di opzioni in cascata, che si distinguono perché manca sempre quella che ti serve. E spesso sono così ben organizzati, da riuscire a nascondere intelligentemente come sia possibile parlare con un operatore umano.

Ma torniamo a noi. In effetti gli IVR che CITEC forniva a Vodafone erano bei prodotti. Basati sul software della Aspect Communications, una società nord americana, erano ingegnerizzati da CITEC piuttosto bene, dando luogo ad un oggetto veloce, affidabile, facilmente programmabile e con un costo relativamente contenuto.

Tutto bello, tutti soddisfatti. Finché Aspect decide di uscire con una nuova versione di software di base. Software che richiede il cambio del sistema operativo dei componenti il sistema. Si passa da una architettura omogenena basata su Unix System V, ad una architettura mista: server applicativo con Solaris e server telefonico con Microsoft Windows.

Ai responsabili tecnici di Vodafone si accappona la pelle: mai sentito di sistemi Windows installati in centrali telefoniche. E i tecnici CITEC non sono da meno: basti pensare allo sforzo necessario per la preparazione di personale di progettazione. Nonché quello per l'installazione e assistenza sul territorio nazionale.

Ma tant'è. Gli Americani, non brillano per flessibilità: "il software è questo: prendere o lasciare". CITEC decide di investire e si mette di buzzo buono a convincere il cliente. Io in particolare ho il mio da fare per far capire alla funzione Vodafone IT responsabile della sicurezza che non è assolutamente possibile pensare di fare l'aggiornamento dei sistemi operativi Windows installati sui server telefonici.

Già. Perché la sicurezza IT di Vodafone vedeva gli aggiornamenti di Windows come assolutamente indispensabili per contrastare le potenziali minacce.

Viceversa. Io, come progettista CITEC e responsabile per il fornitore del collaudo delle apparecchiature avevo ben chiaro un punto fondamentale. Collaudata una nuova versione del sistema nei laboratori Vodafone di sviluppo e di test, i successivi collaudi delle forniture nelle centrali dovevano essere qualcosa che non rimetteva in discussione il progetto, ma solo il go/no go delle componenti fornite. Da qui il principio: ciò che supera il collaudo in fase di test è sacro e assolutamente immodificabile sino alla prossima versione del prodotto.

Anche perché, vi assicuro, ve ne erano di dipendenza tra le diverse componenti del sistema. Ad esempio, se toccavi la release del software da caricare sulle schede telefoniche [1], dovevi ricominciare da capo tutti i test funzionali e di integrazione del sistema. Non era lavoro da poco. Oltretutto lavoro da fare prima in laboratorio CITEC a Roma, e successivamente nei due step dei laboratori Vodafone a Milano.

Insomma: alla fine ce la facciamo. Forti del fatto che i server telefonici sono schermati dalla rete geografica tramite i server applicativi Solaris. Nonché per la presenza nella nostra architettura di switch/firewall di rete opportunamente configurati. Alla fine i responsabili della sicurezza IT di Vodafone si convincono: i nostri server telefonici non saranno soggetti ad aggiornamenti del sistema operativo.

Com'è andata a finire?

Abbiamo installato i sistemi e portato a regime le nuove linee IVR.

Dopo circa un anno di indefesso servizio, un bel giorno il responsabile dei servizi in voce di Vodafone [2], con cui parlavo piuttosto spesso, mi rivolge un sorrisetto e mi fa: "Sai che ieri è penetrato un worm nella nostra rete IT? Le uniche macchine Windows che si sono salvate sono state le vostre ...".

Oggi ho ripensato a questo episodio mentre mi accanivo sul mio server Internet [3] per cercare di capire il motivo per cui il mio sito era andato malamente offline.

Già, perché dovete sapere che ricevo continuamente messaggi di avvertimento dal solerte Github. Il quale mi ricorda che non aggiorno il framework di sviluppo del sito: Django.

Oggi, stufo del bombardamento predetto, ho deciso di aggiornare. Detto, fatto. Aggiorno la macchina di sviluppo dalla versione Django utilizzata, la 2.1.2, alla versione LTE corrente, la 2.2.11.

Faccio due prove sullo sviluppo, e il tutto gira senza problemi. Rincuorato, mi trasferisco sul server e aggiorno Django per il sito. Resetto i soliti servizi di supporto: Gunicorn e Nginx. Ricarico la homepage con il web browser, ed invece della homepage vedo comparire il nefasto Bad gateway 502 error.

Con mia somma felicità passo un paio d'ore a cercare di capire che succede.

Che succede lo capisco: Gunicorn non riesce più ad eseguire la macro wsgi.py. Invece non comprendo per quale motivo ciò accada. Per ora sono stato costretto a tornare indietro. Ho rimontato [4] Django ver.2.1.2 e, per fortuna, il tutto è ripartito.

Ciò mi porta a ribadire la massima che ho usato tanto spesso in passato: "sperimentiamo senza timori, ma una volta messo in produzione, quel che funziona non si tocca".

Enjoy. ldfa

P.S. Gli sviluppatori di app per smartphone la pensano in tutt'altro modo. Ma io non sono convinto. A meno che non si usi un approccio Agile: aggiungere una qualche funzionalità in più ad ogni rilascio. Ma, in tal caso stiamo via via cambiando prodotto.