Dans le film "Dirty Harry" de 1971, Clint Eastwood joue le rôle d'un flic dur et intelligent. Dans la scène d'ouverture, il arrête froidement un braquage de banque en abattant les braqueurs avec son énorme arme de poing Smith and Wesson .44 Magnum à long canon. Les coups de feu retentissent et il ne reste plus qu'un braqueur, blessé. Harry s'approche de lui et prononce la phrase qui est devenue la signature de ce film. "Je sais ce que tu penses. A-t-il tiré six coups de feu ou seulement cinq ? Pour tout vous dire, dans toute cette agitation, je me suis un peu perdu moi-même. Mais comme il s'agit d'un 44 Magnum, l'arme de poing la plus puissante au monde, et qu'il vous ferait exploser la tête, vous devez vous poser une question : Est-ce que je me sens chanceux ? Et bien, est-ce que vous êtes un punk ?" Le punk se rend alors, et demande à Harry combien de coups il lui reste. 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 que vos applications critiques servent continuellement votre entreprise, jour après jour ? Ou disposez-vous d'un ensemble de procédures de test avant la mise en service qui garantissent qu'elles se comportent exactement comme prévu ? Je pose cette question parce que dernièrement, on me demande s'il est nécessaire ou conseillé de reconstruire une application lors de la mise à jour de la version du système d'exploitation. Il n'est peut-être pas nécessaire 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 fassent de gros efforts pour s'assurer que leurs nouvelles versions sont compatibles avec le code existant, je pense toujours que la ligne de conduite la plus sûre est de reconstruire et de tester à nouveau votre logiciel sur la nouvelle version, et de ne pas compter sur la chance.
Lorsque vous utilisez une application critique, je crois qu'il est obligatoire de faire ce niveau d'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 se produisent - nouveau code système, peut-être une mise à niveau de l'unité centrale vers un processeur plus rapide, peut-être quelques changements d'application - comment puis-je être sûr que rien ne va mal tourner ?
La solution consiste à créer un ensemble de tests de qualification minutieux. En reconstruisant votre code source sur la nouvelle version, vous récupérerez les corrections de bogues du compilateur et du runtime qui sont disponibles. Vous constaterez peut-être que le compilateur a de nouveaux messages d'erreur qui révèlent des défauts latents du code source. En relançant vos tests au niveau de l'unité, vous pouvez être certain que les aspects fonctionnels de votre application fonctionnent toujours comme prévu. En relançant les tests au niveau du système, vous pouvez être sûr que tout fonctionne ensemble. Enfin, en effectuant une série de tests de capacité ou de stress, vous saurez que l'ensemble du matériel et des logiciels peut supporter les charges les plus sévères que vous puissiez lui imposer. De plus, vous aurez une mesure du débit maximal de votre application, et vous pourrez utiliser ce chiffre au cours des prochains mois comme indicateur de la capacité de réserve encore disponible.
Quoi que vous fassiez, ne tombez pas dans le piège de croire que parce que vous n'avez rencontré aucun problème sur l'ancienne version, ou sur le matériel plus ancien et plus lent, vous ne trouverez pas de problèmes lors de la mise à niveau. Nos propres statistiques internes montrent que les défauts des logiciels sont en corrélation avec 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 pendant des années peut facilement se casser 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 d'effectuer des séries de tests aussi réalistes et complètes que possible.
Ne vous retrouvez pas à regarder un fusil en vous demandant combien de coups de feu il reste. Ne prenez pas de risques avec une application critique. Ne comptez pas sur la chance. Gardez le contrôle de votre situation. Trouvez les problèmes dans votre laboratoire, et non dans votre environnement de production.
Si vous suivez ces étapes, vous pourrez vous détendre après les heures de travail, sachant que vous avez fait de votre mieux pour assurer le bon fonctionnement de vos systèmes. Vous aurez peut-être même le temps d'aller voir un film.
C'est tout pour l'instant.
Entreprise