Le plan de migration de votre centre de données est finalisé et tout le monde est satisfait de la structure. Le nouvel environnement est prêt et la fenêtre de transition est fixée. C'est alors que quelqu'un pose une question sur le plan de déclassement.
Une personne pensait qu'elle était déjà prise en charge. Une autre personne suggère de “l'externaliser”, sans entrer dans les détails. Enfin, quelqu'un suggère d'attendre que la migration soit terminée.
C'est là que les problèmes peuvent commencer.
La migration et le déclassement ne sont pas le même projet, mais ils sont étroitement liés.
Lorsque les équipes les regroupent dans un même panier mental, la migration est traitée comme un événement technologique et le démantèlement comme un reste de logistique.
C'est ainsi que la récupération des actifs disparaît, que des lacunes dans la chaîne de contrôle apparaissent et que les travaux les plus ingrats sont découverts lorsque les dirigeants pensent que le projet est déjà pratiquement terminé.
La migration et le déclassement résolvent des problèmes différents
La manière la plus propre de comprendre les défis que vous pouvez rencontrer est de séparer les emplois.
| La migration est une question de continuité Il s'agit de transférer les charges de travail, les applications, les utilisateurs, les dépendances et l'état de l'infrastructure d'un environnement à un autre sans interrompre l'activité de l'entreprise. | Le déclassement, c'est la fermeture Il s'agit de prouver ce qu'il est advenu de l'ancien environnement une fois que la migration n'en a plus besoin. Cela comprend le séquençage de l'arrêt, l'identification des actifs, la chaîne de contrôle, l'enlèvement, l'assainissement, la récupération, la destruction, le recyclage et le rapport final. |
Il s'agit là de conditions de réussite différentes.
Une migration peut être techniquement réussie même si le déclassement devient un gâchis financier, de conformité ou de preuve. Un déclassement peut être géré de manière rigoureuse alors que le plan de migration lui-même a été négligé. Le chevauchement est réel, mais il s'agit d'un transfert et non d'une fusion.
La zone de transfert présente des défis logistiques
Si une équipe échoue, c'est parce que personne n'est responsable de la transition entre l'environnement réel et l'environnement supprimé.
C'est dans cette zone de transfert que le risque de catastrophe est le plus élevé. Si vous ne pouvez pas répondre à ces questions, les choses deviendront dangereuses :
| Quand l'actif est-il réellement hors production ? | Qui autorise l'éloignement ? | Qui confirme que les médias porteurs de données sont sur la bonne voie ? |
| À qui appartient l'inventaire final ? | Qui décide ce qui est récupérable et ce qui est destructible ? | Qui réconcilie ce qui était censé bouger avec ce qui a réellement bougé ? |
Si ces questions n'ont pas de responsables désignés avant la fin de la fenêtre de migration, le projet commence à improviser.
L'improvisation crée exactement le type de problèmes que vous voulez éviter : ambiguïté de la garde, sérialisation manquante, mauvaise gestion de la récupération et travail de nettoyage inattendu. Alors que tout le monde se réjouit de la migration, le déclassement est en train de s'effondrer.
Ce qui appartient à la migration et ce qui appartient au déclassement
Il s'agit des opérations que les équipes doivent explicitement définir avant l'exécution :
| Workstream | La migration possède | Le démantèlement est la propriété de |
| Réduction de la charge de travail | Déplacement de l'application, validation, logique de retour en arrière | N/A |
| Arrêt de la production | Confirmation que les systèmes ne sont plus nécessaires dans l'ancien environnement | Ne procéder au retrait qu'après approbation de l'état d'arrêt |
| État des stocks | Identifier ce qui reste en vie et ce qui reste à la retraite | Saisie de l'inventaire final sérialisé des biens mis hors service |
| Risque lié aux données | Protéger les données en direct pendant le basculement | Assainissement, destruction et preuves après le départ à la retraite |
| Résultat financier | Éviter les coûts d'immobilisation | Préserver la valeur de revente et contrôler les coûts d'enlèvement et de destruction |
| Rapport final | Achèvement de la migration et rétablissement du service | Registres de garde, registres de disposition, récupération et clôture |
Cette table est volontairement simple.
Les opérateurs ont tendance à compliquer à l'excès la frontière lors des discussions et à ne pas la définir suffisamment lors de l'exécution.
Cinq points de défaillance à l'origine de l'échec des projets
La plupart des problèmes liés au démantèlement et à la migration des centres de données se résument à quelques domaines spécifiques.
1. L'ancien environnement est traité comme un problème de stockage
C'est l'erreur post-migration la plus fréquente. La migration est terminée, mais l'environnement retiré reste dans une zone grise. Personne ne veut y toucher tant que tout le monde n'est pas sûr que la transition est stable. Plus l'ancien environnement reste dans les limbes, plus vous risquez de perdre l'état de l'inventaire, de mélanger des actifs fonctionnels avec des actifs morts, de mal gérer les supports ou de laisser le matériel de récupération vieillir dans un marché plus difficile. Il faut un point d'entrée défini, même si l'exécution se fait par phases contrôlées après la mise en service.
2. Personne ne définit le dernier inventaire de confiance
Les équipes de migration se concentrent généralement sur l'état des services, et non sur l'état des résidus. Elles savent ce qui a été déplacé. Elles sont généralement moins disciplinées sur ce qui est resté, ce qui a été mis hors tension, ce qui contient encore des données et ce qui a changé d'état au cours du projet. C'est là que la mise hors service commence à perdre de l'argent et du contrôle. Si vous ne verrouillez pas l'inventaire final au bon moment, chaque conversation est plus faible que la précédente : ce qui peut être récupéré, ce qui doit être détruit, ce qui a été effectivement retiré et ce qui manque encore dans le dossier.Plus vous essayez de reconstituer cette liste, plus votre projet commence à dépendre de feuilles de calcul qui ne sont pas alignées.
3. Le chemin des données est conçu trop tard
Les équipes chargées de la migration partent souvent du principe que l'ancien environnement peut être assaini une fois le transfert effectué. Il s'agit d'une solution provisoire, pas d'un plan. Au moment où la solution provisoire se transforme en travail réel, les actifs peuvent déjà être mélangés et les conditions de conservation peuvent être moins bonnes. La décision de réutiliser ou de détruire se résume alors à des contraintes de calendrier plutôt qu'à des contraintes politiques.
Le document NIST SP 800-88 Revision 2 est utile ici car il présente l'assainissement comme un programme avec des contrôles liés au type de support et à la sensibilité de l'information. Le chemin d'accès aux données doit être décidé dans le cadre de la conception de la mise hors service. On ne peut pas se contenter de traverser ce pont quand on y arrive.
4. Le plan de relance relève soit de la fantaisie, soit de la négligence
Les équipes vont généralement trop loin dans une direction. Soit elles partent du principe que l'environnement des retraités est une mine d'or cachée, soit elles traitent tout ce qui est ancien comme de la ferraille et détruisent accidentellement de la valeur.Les deux erreurs proviennent du même problème : personne n'a fait le travail de séparation entre l'inventaire de première qualité et l'inventaire de queue.
Si le plan de déclassement n'identifie pas ce qui fait l'objet d'une véritable demande sur le marché secondaire, le matériel est traité comme un nettoyage et non comme une catégorie d'actifs. Si le plan part du principe que tout a encore de la valeur, les finances se voient vendre une chimère et le budget du projet est faussé avant même que l'exécution ne commence.
5. La frontière du fournisseur est floue
Un fournisseur de services de migration, une équipe de déménageurs, un entrepreneur en installations et un opérateur ITAD peuvent tous intervenir dans le même projet. Cela ne signifie pas qu'ils partagent les mêmes motivations.
Une partie veut que la transition soit stable. Une autre veut que la salle soit nettoyée. Une autre veut que le matériel soit sérialisé et protégé, et une autre veut que le résultat de la récupération soit préservé. Si ces limites ne sont pas définies, le projet est confié à celui qui se fait le plus entendre au cours de la dernière semaine. Le propriétaire de la mise hors service a besoin d'avoir autorité sur la trajectoire du bien mis hors service, même si c'est la migration qui est à l'origine de la mise hors service.
Un meilleur modèle de fonctionnement
Si vous voulez que le projet reste propre, faites de la migration et du déclassement des flux de travail liés mais distincts, avec un transfert formel.
Ce transfert doit être défini :
- Inventaire final : Inventaire fiable de l'état final
- Plan de redressement : Stratégie de revente du matériel
- La retraite : Le moment où un actif est mis hors service
- Propriétaire de la clôture : Propriétaire du dossier de clôture
- Assainissement : Chemin de destruction ou d'assainissement des données
Cinq questions pour forcer la conversation
Avant que la migration ne se termine, posez la question :
- Qui est propriétaire des stocks retirés une fois le transfert terminé ?
- Quelle est la dernière liste des biens de confiance et quand est-elle verrouillée ?
- Quels sont les actifs en état de récupération, en état de destruction ou encore en état d'exception ?
- Quel est le parcours de garde depuis la retraite jusqu'à la disposition finale ?
- Qui signe le dossier de clôture du déclassement ?
Si les réponses sont vagues, vous devrez régler ce problème avant le début de la procédure.
Le déménagement est peut-être prêt. La charge de travail est peut-être stable. Le nouvel environnement est peut-être en pleine effervescence. Cela ne signifie pas pour autant que le projet est sous contrôle.
Une migration se termine lorsque l'entreprise est opérationnelle sur le nouveau site. Une mise hors service se termine lorsque vous pouvez prouver ce qu'il est advenu de l'ancien matériel. Les projets échouent lorsque les équipes confondent ces deux lignes d'arrivée.