13 juillet 2010

La prise de risque

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".

11 commentaires:

  1. Bravo pour cette migration sans apparemment de gros accro. C'est signe que vous l'aviez bien préparée :) Dommage qu'il n'y ait pas plus de détails sur les opérations en elles-même, étant étudiant en réseaux ça m'intrigue, mais ce sont des infos ("par quoi on commence ?" par exemple) que j'apprendrai l'année prochaine de toutes façons :)

    RépondreSupprimer
  2. @Daenn: Chaque migration est très spécifique et nécessite une bonne préparation, mais les connaissances acquises ne servent pas vraiment (sauf si on fait de ce type de migration son métier). Les opérations techniques étaient assez simples une fois mises au point: suppression du client ZenWorks, suppression du client Novell, mettre le PC dans le domaine, rebooter, se connecter une fois sur le compte utilisateur pour créer un profil local AD, rebooter, se connecter admin pour appliquer le script-qui-va-bien pour migrer les données de l'ancien compte local vers le compte AD et enfin, se reconnecter sur le compte utilisateur pour vérifier les droits et paramétrer la messagerie.

    Voilà les grandes lignes ;)

    Bon courage pour les études.

    RépondreSupprimer
  3. Pour ADESoft, c'est du java et il existe également une version linux d'ADEServer ..

    RépondreSupprimer
  4. migrer (ou pas) la vieille

    Migrer la vieille infrastructure ? :-)

    Effectivement, c'est une bonne chose de savoir planifier et s'entourer pour ce genre de choses.

    Merci du compte-rendu qui rappelle que les choses peuvent bien se passer en informatique.

    RépondreSupprimer
  5. Effectivement, chaque migration est très spécifique.... il n'existe pas de manuel tout fait pour ça....
    Bonnes vacances !
    Ps : j'ai une migration de serveur de fichiers à faire la semaine prochaine, faudrait que je commence à y réfléchir..... :-)

    RépondreSupprimer
  6. Je suis toujours un peu tristouille d'apprendre la mort d'une NDS (ok eDirectory).
    Enfin, tu vas découvrir les joies de AD ou la représentation hiérarchique (seulement) sous forme d'OU, d'une bindery (qu'est un domaine AD). Sauf à pénétrer dans la forêt microsoftienne.
    Juste pour le fun: groupe local, groupe global, groupe universel. C'est pas beau ça?
    Mais là ou tu vas en chier à mort, c'est avec l'équivalent des trustees. C'est absolument imbuvable comparé à Novell.
    Mais pas seulement. C'est aussi impossible à maintenir et à contrôler.
    Encore une? Avoir une 'permission de lecture' sur un dossier ne suffit pas pour l'atteindre. Il faut en plus passer par un partage avec encore des permissions. Ce système (AD/2008) est une aberration technique.

    RépondreSupprimer
  7. @Marc,

    L'ensemble des softs cité Catia, Mathlab etc ...
    Tournent sur des plateformes autre que Microsoft,
    mais bien souvent la gestion d'un parc informatique c'est un peu comme quand l'armée brule des stocks d'essence,
    plus il y a de gaspillage plus le gâteau est important, et plus les parts suivante seront grosses.

    Genre : "ah mais si vous comprenez on a besoin d'un antivirus sur tous les postes ah mais si si ..."
    Qui va être contre ?

    RépondreSupprimer
  8. Et pour migrer les comptes eux même vous avez faits comment ?

    Je viens juste de passer 70-297 et bien que je suis incollable sur NT4, et 2000 je n'ai -jamais- toucher ni zenworks ni novel.

    RépondreSupprimer
  9. Il aurait été possible de limiter à un seul OS... tous ces softs de CAO tournant sous Linux.

    D'ailleurs, la CAO n'a pas de prime abord existé sur les PC... mais sur station Unix.

    Seule la convergence de puissance des 2 mondes à permis, tardivement, à Microsoft de prétendre a portage des applis de CAO.

    Et mon petit doigt me dis que cette migration, un peu à contre courant à l'heure ou le retour aux sources (libres) s'accélère, ne vivra pas 20 ans!

    RépondreSupprimer
  10. Bonjour,

    l'exercice que vous relatez, à savoir une migration de samba vers MS, est extrèmement rarement relaté sur la toile. Nous sommes dans une situation un peu similaire, et je suis dans une recherche de détails quand à cette migration. de nombreuses questions me viennent quand à votre expérience : avez-vous conservé le même nom de domaine pendant la migration? Si les deux domaines sont les mêmes, il y a un conflit d'identité de domaines (SID), comment est-ce géré ? a t-il fallu migrer chaque poste manuellement ?

    Merci pour précisions,

    Vos billets sont très bien écrits et agréables à lire,
    --
    Jean-Luc

    RépondreSupprimer
  11. @Jean-Luc: merci pour le compliment. Nous avons choisi de changer le nom du domaine pour justement éviter les conflits, et, oui, il a fallu gérer chaque poste manuellement.

    Bon courage.

    RépondreSupprimer

Lectrice, admiratrice, avocate, magistrate, programmeuse, dessinatrice, chère consœur, femmes de tous les pays, lecteur, j'ai toute confiance en vous pour prendre bien soin de vérifier que votre prose est compatible avec les normes orthographiques et grammaticales en vigueur. Et si vous pouviez éviter les propos insultants ou haineux, je vous en serais reconnaissant.
N'hésitez pas à respecter ces quelques règles qui peuvent même s'appliquer en dehors de ce blog.

Les commentaires sur ce blog sont modérés. Votre message apparaîtra sur le blog dès que le modérateur l'aura approuvé. Merci de votre patience.