J’ai effectué avec mes deux techniciens une migration importante ce week-end: nous sommes passés d’un environnement Novell à un environnement Microsoft. Cela nous a amené à changer d’annuaire pour l’authentification (eDirectory vers Active Directory), à changer de serveur de fichiers (Netware vers Windows 2008 R2), à changer nos serveurs d’impression, à transférer 2000 comptes (fichiers + droits) et à modifier nos logiciels et systèmes de sauvegarde.

Après 11 années passées comme expert judiciaire informatique à constater les échecs des autres, il me semblait important de mettre toutes les chances de mon côté pour éviter la catastrophe.

1) Préludes:

L’idée d’abandonner un système pour un autre ne vient pas brutalement. C’est une idée qui murit depuis plusieurs années et qui s’impose comme évidente. Nous sommes équipés depuis 20 ans d’un OS réseau Novell. Nous avons suivi, au rythme de nos capacités et priorités d’investissement, les différentes évolutions de ce produit, pour rester bloqué sur la version précédant leur passage à SUSE Linux.

J’utilise GNU/Linux depuis longtemps, principalement pour gérer l’accès internet, la sécurité, le monitoring des serveurs et l’hébergement web. Après avoir démarré en 1993 avec la distribution Yggdrasil, j’ai adopté pendant plusieurs années la distribution Slackware, pour migrer ensuite vers le Chapeau Rouge. N’approuvant pas le choix fait avec l’apparition du projet Fedora, j’ai finalement opté pour la distribution Debian qui équipe maintenant tous mes serveurs GNU/Linux.

Parallèlement, les besoins de l’entreprise m’imposaient un certain nombre de logiciels nécessitant pour fonctionner, la présence d’un serveur Windows. Des logiciels comme Catia, Matlab, Comsol ou encore Octime, Adesoft ou Cegid, tournent de manière native dans l’environnement Windows.

Je me suis donc trouvé à un moment à la croisée des chemins avec un choix important à faire: basculer vers un linux commercial au doux nom de boisson alcoolisée apéritive amère ou vers l’univers classique Windows.

C’est une prise de risque dans un cas comme dans l’autre.

Finalement, en tenant compte également du fait que nous ne sommes que trois pour gérer une quinzaine de serveurs, 350 PC et 2000 comptes utilisateurs, j’ai préféré limiter le nombre de systèmes d’exploitation à maitriser. J’ai donc choisi de limiter la salle serveur à deux univers: Windows pour l’annuaire, les serveurs de fichiers, les applications et les DNS internes, et Debian GNU/Linux pour les passerelles, routeurs, serveurs proxy, le monitoring, les firewalls, les DNS externes et les serveurs webs.

2) La migration:

Je pense qu’il faut être modeste et réaliste. Il est difficile de consacrer un temps important à la préparation d’une telle migration alors que les tâches du quotidien et le service à rendre aux utilisateurs occupent déjà très largement mes deux techniciens et moi-même. Après quelques mois de réflexion en mode coucou sur mes autres projets, je me suis rendu à l’évidence, il me fallait l’aide d’un consultant externe pour faire baisser la prise de risque.

J’ai donc appelé ma SSII favorite qui m’a monté une prestation que nous avons construite sur six jours suffisamment espacés pour que le travail préparatoire à faire puisse être réalisé. Chaque jour était bloqué pour que mon équipe puisse se consacrer pleinement à cette activité. Le personnel et les étudiants étaient prévenus que pendant cette période, les temps de résolution des demandes d’intervention allaient être dégradés, sauf urgence absolue.

A la fin de chaque journée, nous faisions un point sur l’état d’avancement, sur les tâches restant à faire, les arbitrages sur les priorités… L’affaire s’annonçait bien, la date de migration prévue a été maintenue, confirmée et enfin est arrivée.

3) Le D day:

Parmi les leçons apprises des échecs observés lors de mes expertises judiciaires, la plus importante consiste à rythmer la migration avec les étapes claires suivantes:

– GO/NOGO: on décide de migrer (ou pas) la vieille de la date prévue;

– Le Rubicon: savoir quand le point de non retour se présente et décider de franchir le pas, ou décider l’annulation et la remise en état. Ces décisions sont lourdes de sens et difficiles à prendre. Le cœur du risque est ici.

– Le mur du fond de l’impasse: il faut être capable de se rendre compte que l’on s’est engagé dans une voie sans issu. Savoir renoncer est une des clefs de la survie en spéléologie, comme en informatique.

– Aller se coucher avant que l’erreur ne se produise: David .J. Way l’écrivait très bien dans un manuel de construction de clavecin que j’aime citer sur ce blog.

Le jour “J” s’est déroulé pour nous samedi dernier. L’entreprise vide était notre royaume pour la journée. Le briefing de la veille nous avait attribué à chacun notre zone d’intervention.

Il régnait dans la mienne comme un parfum de victoire au petit matin.

4) La victoire totale:

Autant le dire tout de suite, la migration s’est déroulée comme sur des roulettes. L’ensemble des utilisateurs a pu s’authentifier dès le démarrage de son poste de travail, accéder à ses applications et ses fichiers et imprimer comme d’habitude.

Bien sur, en salle serveur, base de commandement où convergent tous les appels à l’aide des combattants du quotidien, nous avons traité quelques demandes Ctrl-Alt-Suppr vites réglées^[1], et quelques soucis propres aux informaticiens (la nouvelle sauvegarde fonctionne-t-elle?).

Bien sur, comme tout séisme, il y a quelques répliques, mais celles-ci sont de moins en moins graves et de plus en plus faciles à résoudre.

Finalement, la prise de risque la plus grande aura été de planifier ce genre de migration juste avant de partir en vacances. Je suis en congé ce soir. A moi les Youessai! Bonnes vacances à tous, et ne prenez pas de risque: sauvegardez vos données et ne changez pas vos mots de passe avant de partir.

A dans trois semaines!

————————

[1] Demande: “j’ai appuyé sur les touches Ctrl, Alt et Suppr comme demandé pour me connecter, mais rien ne se passe”. Réponse: “Il faut appuyer sur les trois touches en même temps”.