Transformer une opération risquée en succès stratégique : récit d’un déménagement de datacenter

Intro

Relever les défis ne nous a jamais fait peur chez enioka. Mais quand il s’agit de déménager dans son intégralité le datacenter d’un client, acteur majeur de la construction, dans un délai de moins de 6 mois, on se pose un peu et on réfléchit. Et puis on accepte et on se retrousse les manches !

Les raisons d’un déménagement nécessaire

Resituons un peu le contexte. Quand une entreprise prend la décision de déménager l’ensemble de son SI, c’est un choix mûrement réfléchi. Les avantages et les inconvénients ont été pesés, et la fenêtre de tir a été (judicieusement) choisie. En l’occurrence, les raisons ici étaient clairement établies et laissaient peu de place à l’incertitude : obsolescence à venir du LAN (cœur de réseau) managé, annonce par l’hébergeur de l’évolution de la supervision vers de l’offshore, départ de plusieurs clients majeurs, donc hausses tarifaires à prévoir…

C’est un faisceau d’éléments convergents qui pousse une grande entreprise à changer d’hébergeur et à étudier le déplacement physique de plusieurs centaines de machines. Une fois la décision prise, il faut étudier finement le projet et son planning.

Un contexte bien maîtrisé

Ce fut d’autant plus le cas chez ce client qu’il avait choisi, dès le départ, de se faire accompagner par enioka pour le cadrage de ce déménagement. Les analyses effectuées en amont des travaux de déménagement proprement dit sont indispensables :

Cartographie des différentes couches du SI
Recensement des composants du SI (applications critiques, middleware, équipements et réseau …)
Analyse de la redondance entre les salles, des clusters, des socles de virtualisation…
Étude des amortissements et obsolescences
Proposition de scénarios de déménagement
Sélection de la période la moins impactante pour les activités de l’entreprise

Le déménagement peut aussi être l’occasion de renouveler certains équipements, de revoir des plans d’adressage réseau, de modifier la clusterisation… Le déménagement peut alors devenir une opportunité et non une contrainte !

Pour notre SI, l’état des lieux était le suivant :

Plus de 200 applications à arrêter puis redémarrer, dont 41 applications jugées critiques.
850 bases de données recensées et 1430 machines virtuelles.
Plus de 150 équipements à déménager.

Parmi les différentes hypothèses, le choix d’un déménagement en Lift & Shift des 2 salles sur 4 jours a été retenu (du jeudi 18h au mardi 7h).

Mobiliser toute la DSI mais pas seulement

Une telle opération nécessite de mobiliser l’ensemble des acteurs impactés. Évidemment la DSI, mais pas uniquement la DSI. Les équipes projets, les utilisateurs métiers, tous sont concernés de près ou de loin par l’interruption du SI à venir.

Voici donc une liste des parties prenantes pour ce client (le périmètre et la dénomination des équipes pouvant varier en fonction des organisations) :

Direction : Elle sponsorise le programme de déménagement, débloque le budget nécessaire, effectue les arbitrages.
DSI – Archi & Réseau : Experte des équipements, responsable du réseau et des équipements du Datacenter, cette équipe a été la première mobilisée.
DSI – Prod : En charge de maintenir la Production et les environnements pour les équipes projet, elle est forcément impliquée pour arrêter/relancer les applications.
DSI – Intégration : Responsable des middlewares (base de données, serveurs d’application, outils d’échange de données etc.) et d’applications techniques, elle est à l’intersection des équipements physiques et des applications.
DSI – Tests et Performances : Cette équipe a planifié et contrôlé l’ensemble du plan de test pour donner suite à la relance des salles.
Équipes Projets : Elles suivent de près les impacts sur leurs applications : arrêt/redémarrage des applications, interruptions/reprises des flux, modification des IP publiques utilisées par les partenaires, exécution des plans de tests…
Les directions métiers : Chaque collaborateur utilise quotidiennement une ou plusieurs applications hébergées dans le Datacenter. Ils doivent donc être informés, voire avertis.
Le nouvel hébergeur : Le nouveau partenaire qui va héberger les 2 salles est impliqué au quotidien dans les travaux préparatoires au déménagement.
L’ancien hébergeur : L’ancien partenaire est également concerné.
L’équipe de déménagement : Il est d’usage de faire appel à une entreprise spécialisée dans le déménagement de salles informatiques.

(Re)Définir les responsabilités

Dans notre cas, le déménagement a été l’occasion de préciser les responsabilités au sein des différents départements de la DSI. Toutes les DSI ne sont pas organisées exactement de la même manière, néanmoins, voici quelques questions que nous avons dû nous poser :

Qui prend en charge l’arrêt et la relance des AS400, équipements les plus sensibles ? La Prod ou bien une équipe dédiée, multi-profils ?
Qui prend en charge l’arrêt/relance des machines virtuelles (VMs) ? L’équipe qui gère les applications sur ces VM au quotidien, ou bien l’équipe qui va arrêter physiquement les socles de virtualisation ?
Qui prend en charge l’arrêt/relance des bases de données (BDD) ? L’équipe qui arrête les VMs sur lesquelles elles se trouvent, ou bien l’équipe qui gère les middlewares en général ?

Selon les organisations, ces responsabilités peuvent être déjà établies, mais ce n’était pas notre cas. La préparation du déménagement a donc nécessité d’acter certaines responsabilités, qui autant que possible, perdureront par la suite. Une fois face à leur périmètre de responsabilité, chaque équipe a pu mener les analyses nécessaires et s’outiller. Là aussi, le déménagement a été une opportunité pour recenser finement l’état du SI et automatiser un certain nombre de tâches (arrêt/relance des BDD et des VMs notamment).

Une démarche axée sur les livrables

Venons-en au cœur de ce programme de déménagement. Quels sont les objectifs de ce programme ? Nous nous étions fixé 2 objectifs majeurs et 2 objectifs complémentaires :

1 – Préparer les opérations de déménagement des 2 salles du Datacenter

2 – Sécuriser l’arrêt et la reprise des applications et des services

3 – Enrichir le patrimoine permettant le maintien en conditions opérationnelles (documentation, scripts)

4 – Rationaliser et décommissionner pour lutter contre l’obsolescence

Arrêtons-nous sur les 2 premiers objectifs :

Préparer les opérations de déménagement des 2 salles du Datacenter : Très concrètement, le déménagement consistait à arrêter 2 salles serveurs d’une grande ville de province, séparées de quelques kilomètres, déracker toutes les machines, les charger dans 2 camions, les transporter jusqu’en Ile-de-France, pour les re-racker dans 2 salles distantes cette fois de quelques dizaines de kilomètres. Pour ce move « physique », il était nécessaire d’établir le timing précis des opérations, des interventions des équipes de dérackage/rackage, les durées de transport, la présence des uns et des autres, etc … Ceci se concrétise par une timeline fine, à minima heure par heure, des journées de déménagement.
Sécuriser l’arrêt et la reprise des applications et des services : Du plan métier (processus, activités …) au plan technique (serveurs, stockage, composants réseau …), le SI est composé de couches distinctes dont les éléments sont interconnectés sur une même couche, mais également dont les couches supérieures dépendent. Si j’éteins ce serveur virtuel, quels sont les services et applications concernés ? Si je stoppe cette application, quels serveurs applicatifs et quels services de stockage vais-je pouvoir éteindre ? …. Il est indispensable d’entrer dans les détails de compréhension de cette cartographie du SI pour établir le chronogramme détaillé des arrêts / relances.

Outre ces livrables majeurs, d’autres livrables intermédiaires ou annexes sont à prévoir :

Liste exhaustive des équipements à déménager (à extraire de la CMDB ou de la supervision pour ceux ayant une base suffisamment précise et à jour)
Liste des applications, avec en particulier les applications critiques et les responsables applicatifs.
Liste des personnes mobilisées pour le déménagement et déclarations RH (car oui, ces opérations se font la plupart du temps en heures non ouvrées et nécessitent donc des déclarations légales préalables).

Est-ce qu’on oublie quelque chose une fois les éléments précédents listés ? Oui ! Et des éléments majeurs ! Qui sont indissociables d’une Prod efficace, mais qui, il faut bien l’avouer, font régulièrement défaut :

Des procédures d’arrêt/relance pour chaque application
Des procédures d’arrêt/relance pour les VMs et tous les middlewares
Des procédures d’arrêt/relance pour les équipements physiques
Des tests de non régression (TNR) pour chaque application

Disposer de l’ensemble de ces livrables pour l’ensemble du périmètre est extrêmement ambitieux, néanmoins il résidera un risque pour chacune des procédures manquantes.

Vous le comprenez, un programme de déménagement est donc majoritairement dédié à la production de ces livrables, qui permettent de sécuriser les opérations. Et également à la communication, parent pauvre des opérations techniques, mais indispensable ici au vu de l’impact pour l’ensemble de l’entreprise.

Un mot encore sur le sujet livrables, ces documents doivent être disponibles à tous et rédigés de manière collaborative, puisqu’ils sont au cœur des travaux et prises de décisions. Il est indispensable d’utiliser pour cela une solution de travail collaboratif (Teams, Google Suite …)

Gouvernance

Pour conduire ce programme, une gouvernance forte est nécessaire. Composée des différents responsables des équipes DSI mentionnées précédemment, ainsi que du ou des C-Level desquels ils dépendent, il est important d’associer les ressources clés qui sont en interne les plus expertes sur le Datacenter.

Il est aussi nécessaire de nommer un directeur de projet dédié. Celui-ci est responsable de l’avancement des travaux préparatoires, anime le comité de pilotage et est porteur des livrables et des lignes budgétaires du déménagement. Il mène en parallèle des points de suivi hebdomadaires avec les différents acteurs, pour :

Identifier et qualifier les risques
Creuser les difficultés avec les experts nécessaires
S’assurer que les sujets identifiés en comité de pilotage soient traités.

Dans notre cas, il était également responsable des ateliers et de la communication avec les parties prenantes en dehors de la DSI.

En termes de comitologie, nous avions fait le choix de faire deux instances régulières distinctes : l’une interne, l’autre avec les intervenants externes (les équipes du nouvel hébergeur et l’équipe de déménagement). Cette organisation s’est avérée plutôt vertueuse. Elle a permis de discuter et de suivre en détails les sujets internes et d’être efficace en parallèle sur les chantiers de préparation avec les externes.

Les deux premiers mois, des rendez-vous bimensuels étaient suffisants, mais à l’approche du déménagement, les comités de pilotage sont devenus hebdomadaires, tant il était indispensable d’impulser un avancement continu, soutenu et de réagir vite face à chaque incident ou risque nouveau.

Autres points d’attention

Avant d’aborder les journées de déménagement, citons pêle-mêle quelques autres éléments intéressants à garder en tête :

Maintien de garantie : Les équipements les plus critiques d’un SI (IBM iSeries par exemple) sont sujets à une garantie de la part des éditeurs ou revendeurs. Mais cette garantie peut être invalidée si les procédures de déménagement ne sont pas respectées. Il convient de contacter au préalable ces éditeurs ou revendeurs pour aborder le sujet en amont. Le déplacement d’un prestataire pour contrôler avant/après est souvent nécessaire, et facturable.
Infrastructure minimale à destination : Afin de sécuriser des sauvegardes et d’assurer une continuité de service minimum (AD par exemple pour ne pas couper la messagerie, Office et autres logiciels Saas s’appuyant sur le SSO), il est recommandé d’installer un minimum de service de stockage et un socle de machines virtuelles permettant de migrer ou d’étendre certains serveurs en amont du déménagement.
Répétition à blanc : Le chronogramme des opérations d’arrêts/relances va aboutir à un séquencement fin d’actions, à effectuer de manière coordonnée par différentes équipes. Il est donc intéressant de faire une répétition à blanc, en rassemblant tous les acteurs de ces opérations, afin de s’assurer que tout le monde comprenne bien le chronogramme, que les actions attendues de chacun sont claires, que les prérequis soient validés (accès admin, mots de passe, disponibilité des ressources …). Et surtout de valider le mode et le contenu des échanges inter-équipes durant les journées de déménagement. Dans notre cas, cette répétition a été extrêmement utile, pour détecter certains problèmes mais aussi pour donner confiance aux équipes et préparer les esprits aux opérations à venir.

Les journées de déménagement

Pour les journées de déménagement, il a été demandé aux équipes de la DSI d’être en présentiel, afin de faciliter les échanges. Sur 4 journées, week-end inclus, cela demande une planification précise de l’arrivée et du départ de chaque équipe, de la rotation des effectifs, des déclarations de mobilisation planifiée…

Durant le déménagement, nous avions définis des relais, responsables de communiquer dans le canal commun au début et à la fin de chaque étape prévue dans le chronogramme, et avions formaté le contenu des messages attendus sur ce canal commun. Les communications intra-équipe se faisant dans des canaux dédiés, afin que la cellule de pilotage ne perde pas de vue l’avancement global. Nous avions également défini des jalons majeurs, dont le franchissement nécessitait de communiquer au top management.

Nous n’allons pas détailler de manière exhaustive le déroulé du déménagement, ni l’ensemble des impondérables plus ou moins sérieux que nous avons rencontré. Ce serait trop spécifique, et chaque déménagement va présenter ses propres évènements, positifs ou négatifs, qu’il faudra être capable de gérer.

Voici tout de même à grosse maille les différentes étapes que nous avons suivi :

Jour J – Jeudi : Journée

Désactivation des démarrages automatiques (serveurs, VM, flux …)
Arrêt des environnements anté-Prod

Jour J – Jeudi : Soir

18h : Fermeture de la Prod
Arrêt de l’ordonnanceur
Arrêt des applications métier
Arrêt des applications techniques
Arrêt des BDD et des VMs
Arrêt des équipements

J+1 – Vendredi : matin

Dérackage de la Salle 1
Transport
Rackage et Power On
Check et Go de la Salle 2

J+1 – Vendredi : après-midi

Dérackage salle 2
Transport

J+2 – Samedi : matin

Rackage et Power On
Relance des VM et des bases

J+2 – Samedi : après-midi

Relance des Applis

J+3 et J+4 :

Tests applicatifs

J+4 – 8h Réouverture de la Prod

En synthèse, nous avons rencontré plusieurs aléas que l’on peut craindre dans ce genre d’opération, et que nous avions auparavant identifié comme des risques plus ou moins probables selon les cas : absence au dernier moment d’une ressource clé, problème réseau, matériel KO au redémarrage, surcharge horaire pour certaines ressources, absence préjudiciable de quelques procédures …

Néanmoins, notre préparation minutieuse, la mobilisation totale des équipes et la chronologie maîtrisée des évènements nous ont permis de gagner un temps considérable et de surmonter ces difficultés. Pour finalement reprendre le service en temps et en heure, tel qu’annoncé aux utilisateurs, avec un nombre d’anomalies très faible, que ce soit lors des tests de recevabilité, ou par les utilisateurs suite à la reprise de l’activité.

Conclusion

L’objectif des mois de projet qui précèdent le déménagement est d’anticiper suffisamment les risques, de mettre les opérations sous contrôle, d’automatiser ce qui peut l’être pour avoir le temps de gérer les aléas qui manqueront inéluctablement de se produire. Le déménagement doit s’appuyer sur le patrimoine des procédures de Production. Si elles n’existent pas, il va falloir les produire. Il faut donc profiter de cette occasion pour s’améliorer, conduire les changements qui sont laissés de côté lors du quotidien agité d’un SI. Et pour tout cela, il faut être prêt à allouer au programme de déménagement un budget conséquent, puisque c’est la source de dépenses multiples (prestations, forte mobilisation des ressources internes, renouvellement des équipements, rédaction des procédures manquantes). Mais tout cela est nécessaire pour pérenniser et rationaliser le SI… et effectuer des économies dans les années qui suivent !

Si vous souhaitez discuter avec nous du déménagement de votre Datacenter, si vous cherchez des profils experts qui puissent vous accompagner pour analyser les scénarios d’architecture et piloter un tel projet, vous savez où nous contacter : contact@enioka.com.