Dans le film « Dirty Harry » sorti en 1971, Clint Eastwood incarne un policier coriace et débrouillard. Dans la scène d'ouverture, il met fin avec sang-froid à un braquage de banque en abattant les braqueurs à l'aide de son énorme pistolet Smith & Wesson .44 Magnum à long canon. Les coups de feu retentissent et il ne reste plus qu'un seul braqueur, blessé. Harry s'approche de lui et prononce la phrase qui est devenue la réplique emblématique de ce film. « Je sais ce que vous pensez. A-t-il tiré six coups ou seulement cinq ? Eh bien, pour vous dire la vérité, dans toute cette agitation, j'ai moi-même perdu le compte. Mais comme il s'agit d'un Magnum .44, le pistolet le plus puissant au monde, capable de vous faire sauter la tête, vous devez vous poser une question : est-ce que je me sens chanceux ? Alors, punk ? » Le punk se rend alors et demande à Harry combien de balles il lui restait. Harry pointe son arme sur lui et appuie sur la gâchette. Le pistolet est vide. Le braqueur de banque a eu de la chance.
Comptez-vous sur la chance pour garantir que vos applications critiques continuent de fonctionner sans interruption au sein de votre entreprise, jour après jour ? Ou disposez-vous d'un ensemble de procédures de test préalables à la mise en production qui garantissent leur fonctionnement conforme ? Je pose cette question car, ces derniers temps, on me demande souvent s'il est nécessaire ou conseillé de reconstruire une application lors de la mise à niveau du système d'exploitation. Vous n'êtes peut-être pas obligé de reconstruire votre application, mais je vous conseille de le faire, que vous utilisiez Windows, Linux, VOS ou OpenVOS. Bien que les fournisseurs de ces systèmes mettent tout en œuvre pour garantir la compatibilité de leurs nouvelles versions avec le code existant, je pense toujours que la solution la plus sûre consiste à reconstruire et à retester votre logiciel sur la nouvelle version, plutôt que de compter sur la chance.
Lorsque vous utilisez une application critique, je pense qu'il est indispensable de réaliser un tel investissement. Sinon, comme dans la scène du film, vous risquez d'exposer votre entreprise à des conséquences vraiment désagréables. La question que vous devez vous poser est la même : est-ce que je me sens chanceux ? Avec tous les changements qui ont lieu (nouveau code système, mise à niveau du processeur vers un modèle plus rapide, quelques modifications apportées aux applications), comment puis-je être sûr que tout se passera bien ?
La solution consiste à créer un ensemble rigoureux de tests de qualification. En reconstruisant votre code source sur la nouvelle version, vous bénéficierez des corrections de bogues disponibles pour le compilateur et le runtime. Vous constaterez peut-être que le compilateur affiche de nouveaux messages d'erreur qui révèlent des défauts latents dans le code source. En réexécutant vos tests au niveau des unités, vous pouvez vous assurer que les aspects fonctionnels de votre application fonctionnent toujours comme prévu. En réexécutant les tests au niveau du système, vous pouvez être sûr que tout fonctionne ensemble. Enfin, en exécutant une série de tests de capacité ou de résistance, vous saurez que l'ensemble du matériel et des logiciels peut supporter les charges les plus lourdes que vous pouvez lui imposer. De plus, vous disposerez d'une mesure du débit maximal de votre application et pourrez utiliser ce chiffre au cours des prochains mois comme indicateur de la capacité disponible restante.
Quoi que vous fassiez, ne tombez pas dans le piège de croire que, parce que vous n'avez rencontré aucun problème avec l'ancienne version ou avec un matériel plus ancien et plus lent, vous ne rencontrerez aucun problème lors de la mise à niveau. Nos propres statistiques internes montrent que les défauts logiciels sont corrélés à l'augmentation de la vitesse du processeur. Des problèmes inconnus ou simplement rares peuvent devenir courants sur un processeur plus rapide. Un logiciel qui fonctionne depuis des années peut facilement tomber en panne lorsque la croissance normale du volume des transactions entraîne des débordements de file d'attente. La seule façon de savoir si vos applications fonctionneront correctement dans l'environnement modifié est de réaliser des tests aussi réalistes et complets que possible.
Ne vous retrouvez pas face à une arme à feu en vous demandant combien de balles il reste. Ne prenez pas de risques avec une application critique. Ne comptez pas sur la chance. Gardez le contrôle de la situation. Identifiez les problèmes dans votre laboratoire, pas dans votre environnement de production.
Si vous suivez ces étapes, vous pourrez vous détendre après le travail, sachant que vous avez fait tout votre possible pour garantir le bon fonctionnement de vos systèmes. Vous aurez peut-être même le temps d'aller voir un film.
C'est tout pour le moment.