Essais cliniques

parce qu’ils sont
plus sensibles aux problèmes subtils qui surviennent, et
qu’ils pourraient bien travailler avec le nouveau code ou les
nouvelles applications qui seront bientôt déployés. Il vous
faudra au moins une dizaine de machines parce que vous
aurez besoin d’un échantillonnage représentatif des OS, des
niveaux de packs de service, des applications, et des services
présents sur le réseau. Appliquez d’abord les patches à  ces machines, surveillez les problèmes et les doléances puis
commencez à  appliquer les patches au reste de l’entreprise
par étapes si tout se passe bien. Vous pensez peut-être ne pas
avoir le temps de tester les patches cruciaux de cette manière.
Mais vous pouvez raccourcir le test réel à  quelques
heures seulement, si vous manquez de temps, parce que les
problèmes qui entraînent l’arrêt de l’exécution surviennent
généralement dès l’application des patches défectueux.
Faites aussi des essais cliniques pour vos serveurs de production,
mais seulement après avoir fait une sauvegarde
complète des serveurs cobayes. Sélectionnez un de chacun
de vos types de serveurs (Web, mail, contrôleur de domaine
– DC, serveur d’impression, par exemple) et n’appliquez les
patches qu’à  ces machines, une à  une. Pour la disponibilité
des services 24 h x 7 j pendant des patchings fréquents, deux
dispositifs sont particulièrement utiles : le failover clustering
et le WLBS (Windows NT Load Balacing Service).
N’oubliez pas que d’autres sont confrontés aux mêmes
problèmes de gestion des patches que vous. Consultez les
newsgroups consacrés aux produits que vous gérez (par
exemple en consultant http/groups.google.com) et abonnezvous
aux listes de mailing concernant les patches ou la sécurité,
comme NTBugtraq (http://www.ntbugtraq.com) ou la
liste de gestion des patches à  http://www.patchmanagement.
org. Vous pouvez apprendre beaucoup de vos homologues
de la communauté informatique. Et quand, grâce à 
vos tests, vous découvrirez des patches défectueux, ne manquez
pas de leur en faire part.