Nel film del 1971 "Dirty Harry", Clint Eastwood interpreta un poliziotto di strada, duro e intelligente. Nella scena di apertura, ferma con freddezza una rapina in banca sparando ai rapinatori con la sua enorme, lunga canna, Smith and Wesson .44 Magnum. Gli spari suonano e rimane un solo rapinatore, ferito. Harry si avvicina a lui e pronuncia la frase che è diventata la linea guida di questo film. "So cosa stai pensando. Ha sparato sei colpi o solo cinque? Beh, a dire la verità, in tutta questa eccitazione, anch'io ho un po' perso il conto. Ma visto che questa è una Magnum .44, la pistola più potente del mondo, e ti farebbe saltare la testa, devi farti una domanda: Mi sento fortunato? Beh, ti senti un teppista?" Il punk allora si arrende e chiede a Harry quanti colpi sono rimasti. Harry gli punta la pistola contro e preme il grilletto. La pistola è scarica. Il rapinatore di banca è stato fortunato.
Vi affidate alla fortuna per garantire che le vostre applicazioni mission-critical siano sempre al servizio della vostra azienda, giorno dopo giorno dopo giorno? Oppure disponete di una serie di procedure di test pre-rilascio che garantiscono che si comportino esattamente come previsto? Faccio questa domanda perché ultimamente mi sto chiedendo se è necessario o consigliabile ricostruire un'applicazione quando si aggiorna il rilascio del sistema operativo. Potrebbe non essere necessario ricostruire la vostra applicazione, ma vi consiglio di farlo, sia che usiate Windows, Linux, VOS o OpenVOS. Mentre i venditori di questi sistemi si impegnano a fondo per garantire che le loro nuove release siano compatibili con il codice esistente, penso comunque che la linea d'azione più sicura sia quella di ricostruire e ritestare il vostro software sulla nuova release, senza affidarsi alla fortuna.
Quando si esegue un'applicazione mission-critical, credo che sia obbligatorio effettuare questo livello di investimento. Altrimenti, come la scena del film, si rischia di esporre la propria attività a conseguenze davvero spiacevoli. La domanda che ti devi porre è la stessa: mi sento fortunato? Con tutti i cambiamenti che stanno avvenendo - nuovo codice di sistema, forse un aggiornamento della CPU ad un processore più veloce, forse qualche cambio di applicazione - come posso essere sicuro che nulla andrà storto?
La risposta è creare un'attenta serie di test di qualificazione. Ricostruendo il codice sorgente sulla nuova release, si potranno recuperare le correzioni di bug del compilatore e del runtime che sono disponibili. Potreste scoprire che il compilatore ha alcuni nuovi messaggi di errore che rivelano difetti latenti del codice sorgente. Eseguendo nuovamente i test a livello di unità, si può essere certi che gli aspetti funzionali della propria applicazione funzionino ancora come pianificato. Eseguendo nuovamente i test a livello di sistema, si può essere sicuri che tutto funzioni come previsto. Infine, eseguendo una serie di test di capacità o di stress, saprete che l'intera suite di hardware e software è in grado di gestire i carichi più severi che potete lanciare. Inoltre, avrete una misura della capacità massima della vostra applicazione e potrete utilizzare questa cifra nei prossimi mesi come indicatore di quanta capacità di riserva rimane disponibile.
Qualunque cosa facciate, non cadete nella trappola di credere che, non essendovi imbattuti in problemi sulla vecchia release, o sull'hardware più vecchio e lento, non troverete problemi quando farete l'upgrade. Le nostre statistiche interne mostrano che i difetti del software sono correlati all'aumento della velocità del processore. Problemi inediti, o semplicemente rari, possono diventare comuni su un processore più veloce. Un software che funziona per anni può facilmente rompersi quando la normale crescita del volume delle transazioni porta a un eccesso di code. L'unico modo per sapere che le vostre applicazioni funzioneranno correttamente nell'ambiente modificato è di condurre una serie di test il più possibile realistici e completi.
Non ritrovarsi a fissare una pistola chiedendosi quanti colpi sono rimasti. Non correte rischi con un'applicazione mission-critical. Non affidatevi alla fortuna. Mantenete il controllo della vostra situazione. Trovate i problemi nel vostro laboratorio, non nel vostro ambiente di produzione.
Se si seguono questi passi, ci si può rilassare dopo l'orario di lavoro, sapendo che si è fatto del proprio meglio per garantire che i sistemi funzionino senza problemi. Forse avrete anche il tempo di andare a vedere un film.
Questo è tutto per ora.
Azienda