Migrer les systèmes centraux existants sans arrêter l'activité

Les migrations principales échouent lors du basculement. Ni dans la conception, ni dans la construction, ni dans les tests : le week-end, lorsque l'ancien système est éteint, le nouveau est allumé et l'entreprise ouvre le lundi pour découvrir ce que personne ne savait. Ce modèle est suffisamment courant pour avoir un nom, le big bang, et suffisamment courant pour que la plupart des dirigeants qui commandent un remplacement de base en aient vécu un.

La position ici est que le big bang est un choix, et un mauvais choix. L’alternative est bien comprise en ingénierie et rarement exigée par les signataires du contrat. Une couche de compatibilité se trouve devant l’ancien système. Les consommateurs y accèdent un par un. Le nouveau noyau prend le relais, domaine par domaine. Les données se déplacent sous forme de flux, réconciliés quotidiennement, et non comme la charge d'une seule nuit. Chaque étape comporte une restauration qui a été exécutée, chronométrée et détenue. Le programme est plus lent à montrer un résultat spectaculaire et a beaucoup plus de chances de se terminer.

Pourquoi le Big Bang échoue

Trois choses vont mal, et elles vont mal ensemble.

Le gel. Pour basculer à une date donnée, l'entreprise doit arrêter de modifier l'ancien système des semaines ou des mois à l'avance afin que le nouveau puisse rattraper un objectif fixé. Les lancements de produits attendent. Les changements réglementaires sont corrigés à la main. L’arriéré s’accroît, les dates glissent, le gel s’étend et l’organisation apprend à travailler autour de son propre noyau. Au moment du basculement, le nouveau système remplace une version de l’ancien qui n’existe plus.

Le retour en arrière inédit. Le plan de restauration est un document. Il décrit comment, si le nouveau système tombe en panne lundi, l'ancien sera restauré. Il n’a jamais été exécuté, car le faire fonctionner signifierait mettre hors service l’ancien système en production. Lorsque lundi arrive et que le nouveau système tombe en panne d'une manière que personne ne prévoyait, l'équipe découvre que la restauration prend plus de temps que l'entreprise ne peut attendre, que les données écrites depuis le basculement ne peuvent pas être déplacées vers l'arrière et que la décision de restauration n'a pas de propriétaire. Alors ils avancent, dans un système qui ne fonctionne pas, parce que revenir en arrière est pire.

Les consommateurs inconnus. Chaque système de base qui fonctionne depuis une décennie n'a aucun consommateur répertorié. Une feuille de calcul en finance qui lit directement un tableau. Un travail par lots écrit par un entrepreneur décédé. Une intégration partenaire qui s'authentifie avec un identifiant partagé. Un rapport que le régulateur reçoit mensuellement. La carte des dépendances a été construite à partir de documentation et d’entretiens, et la documentation était erronée et les personnes interrogées ne le savaient pas. Le big bang découvre ces consommateurs au moment où ils se brisent.

Le plan de restauration n’a jamais été mis en œuvre, car le mettre en œuvre impliquerait la suppression de l’ancien système. Quand lundi arrive, l'équipe découvre ce que cela signifie.

Le modèle alternatif

Le modèle comporte une poignée de composants et chacun supprime l’un des modes de défaillance ci-dessus.

Une couche de compatibilité, parfois appelée façade, est placée devant le noyau existant. Il parle des contrats existants du système existant, des mêmes interfaces, des mêmes formats de fichiers, des mêmes formes de messages, de sorte qu'aucun consommateur n'a besoin de changer pour lui parler. Le premier jour, il ne fait que transmettre les appels. C'est la couture le long de laquelle tout le reste se fait.

Remplacement de style étrangleur. Derrière la couche, le nouveau noyau est construit domaine par domaine. Lorsqu'un domaine est prêt, la couche achemine le trafic de ce domaine vers la nouvelle implémentation et continue d'acheminer tout le reste vers l'ancienne. Le système existant n'est pas éteint ; il est affamé, domaine par domaine, jusqu'à ce que plus rien n'en dépende. Puis il se retire, un jour qui n'importe à personne.

Un consommateur à la fois. Les consommateurs sont déplacés individuellement vers la couche de compatibilité, dans un ordre choisi en fonction du risque : les moins critiques en premier, ceux dont le comportement est le plus connu, ceux dont les propriétaires se trouvent dans le bâtiment. Chaque mouvement est suffisamment petit pour être compris et inversé. Les consommateurs inconnus font surface au fur et à mesure que les consommateurs connus se déplacent, car le trafic qui atteint toujours directement le système existant provient, par définition, d'un consommateur qui ne figure pas encore sur la carte. La carte se finalise en production, en toute sécurité.

Double course et réconciliation. Pour chaque domaine, le nouveau noyau cohabite avec l'ancien pendant une durée convenue. Les deux reçoivent les mêmes entrées. Leurs productions sont comparées, enregistrement par enregistrement, chaque jour. Le rapport de réconciliation est la preuve que le nouveau système fait ce que l’ancien faisait, y compris des comportements que personne n’a documentés. Là où les deux diffèrent, la différence est étudiée, et c’est souvent l’ancien système qui s’avère erroné.

Indicateurs de fonctionnalités. Les décisions de routage dans la couche de compatibilité sont contrôlées par la configuration et non par le déploiement. Un indicateur déplace un consommateur ou un domaine vers le nouveau noyau ; le même drapeau le fait reculer. Une version et un basculement sont séparés : le code est expédié en continu et le comportement change lorsque quelqu'un le décide.

Migration de données sous forme de flux. Les données ne bougent pas en une nuit. Un flux de capture de données modifiées ou un mécanisme équivalent copie continuellement les enregistrements de l'ancien vers le nouveau, de sorte que le nouveau noyau soit toujours proche du courant. La synchronisation finale pour n'importe quel domaine correspond à des minutes de delta, et non à des heures de charge. Si le domaine est restauré, le flux s'inverse ou l'ancien système n'a jamais cessé d'écrire en premier lieu.

Rollback répété avec des déclencheurs définis

Un rollback est une procédure, pas un plan. La différence est qu'une procédure a été exécutée.

Chaque étape de basculement, qu'il s'agisse du déplacement d'un consommateur, du routage d'un domaine ou du retrait d'un composant, comporte une restauration qui a été exécutée dans un environnement façonné comme la production, chronométrée et documentée avec la durée réelle. La personne qui le dirigera en production l’a dirigé en répétition. Le pas n’est franchi qu’une fois la répétition passée.

Les déclencheurs sont définis avant l'étape. Un déclencheur de restauration est une condition mesurable convenue à l'avance : un taux d'erreur supérieur à un seuil pour une durée spécifiée, une différence de rapprochement supérieure à un nombre convenu, un échec d'un processus métier nommé, un rapport réglementaire qui ne peut pas être produit. Lorsqu'un déclencheur se déclenche, la restauration est exécutée. Il n'y a pas de réunion. La réunion a eu lieu lorsque le déclencheur a été convenu, et elle a inclus les personnes qui autrement devraient être réveillées pour prendre une décision.

La décision a un propriétaire nommé. Une personne détient le pouvoir d'annuler chaque étape, est présente lorsque l'étape est franchie et n'est pas la personne qui a construit l'objet en cours de reconstruction.

Observabilité et réconciliation comme acceptation

Le critère d’acceptation pour un consommateur ou un domaine migré n’est pas une réunion de signature. Il s'agit d'un rapport de rapprochement montrant aucune différence entre l'ancien et le nouveau pour la période convenue, et une vue d'observabilité montrant que le nouveau système se comporte dans les limites attendues sous charge réelle.

Le rapprochement compare les résultats au niveau qui compte pour l'entreprise : soldes, rendez-vous, politiques, factures, quel que soit le système d'enregistrement principal. Il est exécuté quotidiennement, est examiné par quelqu'un qui comprend le domaine, et chaque différence est soit expliquée et acceptée, soit corrigée. Le rapport est conservé, car le commissaire aux comptes le demandera.

L'observabilité est conçue avec les opérateurs qui vont la lire. Les journaux, métriques et traces structurés répondent aux questions qu'ils se posent réellement lorsque quelque chose ne va pas : qu'est-ce qui a changé, qui est affecté, depuis quand et si la situation s'aggrave. Les alertes se déclenchent dans des conditions qui nécessitent une action et restent silencieuses dans le cas contraire. Une alerte sur laquelle personne n’agit est du bruit, et le bruit cache l’alerte qui compte.

Ensemble, ces éléments remplacent la confiance qu’un big bang demande au conseil d’administration de prendre en confiance. Un directeur peut voir le rapprochement et les tableaux de bord et décider si la prochaine étape est sûre, sur la base de preuves plutôt que d'assurances.

L'organisation autour de la migration

Le modèle d’ingénierie échoue si l’organisation qui l’entoure se comporte toujours comme si un big bang était imminent.

Un tableau de changement. Un groupe permanent composé de représentants de la technologie, des opérations, des unités commerciales concernées et de la conformité se réunit à une cadence fixe et approuve chaque étape de basculement sur la base des preuves : le journal de répétition, le rapport de rapprochement, les définitions de déclencheurs, le propriétaire du rollback nommé. C'est petit et c'est lui qui décide. Il ne s'agit pas d'une réunion de statut.

Gel des fenêtres négocié, non imposé. Certaines étapes nécessitent encore une période de calme : courte, pour un domaine précis, au moment choisi par l'entreprise. L'unité commerciale nomme la fenêtre et la migration s'y adapte, plutôt que la migration déclarant un gel et l'entreprise travaillant autour de celle-ci. Une fenêtre négociée est honorée. Celui imposé est contourné.

La formation est une étape et non une réflexion après coup. Les personnes qui exploitent le noyau, au comptoir, dans la salle, au pupitre de négociation, se déplacent avec le consommateur qu'ils utilisent. Ils sont formés au nouveau comportement avant que leur consommateur ne déménage, l'ancien système étant toujours disponible, et le runbook qu'ils utilisent a été testé par quelqu'un qui ne faisait pas partie du projet.

Contextes réglementés

Dans un réseau hospitalier ou une banque, la migration est un changement régulé, et le schéma ci-dessus indique également la manière dont les obligations sont remplies.

En vertu de la HIPAA, un réseau hospitalier aux États-Unis gère des informations de santé protégées, et la règle de sécurité exige des garanties administratives, physiques et techniques, notamment des contrôles d'accès, des contrôles d'audit et des contrôles d'intégrité. Une migration touche les trois. Le double fonctionnement signifie que les informations de santé protégées existent dans deux systèmes pendant une période donnée, et que les deux doivent respecter les garanties. Le rapport de rapprochement est un contrôle d'intégrité. Les journaux d'accès sur la couche de compatibilité constituent un contrôle d'audit. Les accords de partenariat commercial avec les fournisseurs concernés doivent couvrir explicitement la période de migration.

En Suisse, les attentes de la FINMA à l'égard des assujettis comprennent des exigences en matière d'externalisation, de résilience opérationnelle et de gestion des risques liés aux technologies de l'information et de la communication. D’une manière générale, une banque supervisée est censée conserver le contrôle des fonctions externalisées importantes, identifier ses fonctions critiques et les tolérances quant à leur perturbation, et être en mesure de démontrer au superviseur qu’une modification significative apportée à un système central a été gouvernée, testée et réversible. Une migration qui déplace un consommateur à la fois avec une restauration répétée et une réconciliation quotidienne produit ces preuves en tant que sous-produit. Un big bang produit une promesse.

Dans tout contexte réglementé, les pistes d’audit ne sont pas facultatives. Chaque changement de routage dans la couche de compatibilité, chaque drapeau retourné, chaque résultat de rapprochement et chaque annulation sont enregistrés avec qui, quand et pourquoi, et le journal est conservé pendant la période requise par le régulateur. Le pipeline qui déploie le code produit sa propre trace : ce qui a été modifié, qui l'a examiné, quels tests ont réussi. La conformité devient une propriété du système plutôt qu'une feuille de calcul à côté de celui-ci.

Comment contracter pour cela

Le contrat façonne le comportement. Un contrat avec une seule date de mise en service et un paiement qui y est attaché produit un big bang, quoi qu'en dise la déclaration de méthode, car le fournisseur est payé pour la date.

Contrat par consommateur migré. Définissez les consommateurs et les domaines dans la carte des dépendances, acceptez un ordre et attachez un jalon à chacun : le consommateur est sur la couche de compatibilité, la réconciliation n'a montré aucune différence pour la période convenue, la restauration a été répétée et les opérateurs ont exécuté le runbook. Le paiement suit le jalon. La date est une prévision, pas un terme.

Écrivez la définition de done dans le contrat : tests, observabilité, documentation et journal de répétition pour chaque étape. Écrivez exit dans le contrat dès le début : source dans vos référentiels dès la première semaine, et un gate qui exige que votre équipe ait libéré, annulé et résolu un incident sans le fournisseur avant le paiement final.

Les signes que c'est en train de devenir un big bang de toute façon

Un contrat bien rédigé n’arrête pas à lui seul la dérive. Les programmes qui démarrent progressivement se dirigent vers le big bang sous la pression du calendrier, et les signes sont visibles des mois à l’avance.

La couche de compatibilité est ignorée pour les consommateurs « simples », et le nombre de consommateurs déplacés directement vers le nouveau noyau augmente. La période de double exécution est raccourcie pour correspondre à une date. Les différences de réconciliation sont acceptées sans explication car leur enquête prend du temps. Les répétitions de restauration se sont arrêtées et la dernière enregistrée date d'il y a trois étapes. Un gel a été annoncé plutôt que négocié. Le comité de changement est devenu une réunion de statut qui approuve tout. Une seule date est apparue dans un document du conseil d'administration avec le mot go-live à côté. Quelqu'un a proposé de regrouper les consommateurs restants pour gagner du temps.

Chacun de ces éléments est une conversation. Trois ensemble, c'est un big bang avec un nom différent, et le conseil d'administration devrait demander les journaux de répétition avant l'étape suivante.

Que faire lundi

1. Demandez la carte des dépendances et demandez comment elle a été construite. Si cela provient uniquement de la documentation et des entretiens, commandez l'analyse du trafic qui trouve les consommateurs que personne n'a répertoriés.
2. Demandez le journal de répétition de restauration pour l'étape de basculement la plus récente. S'il n'y en a pas, arrêtez l'étape suivante jusqu'à ce qu'il y en ait.
3. Demandez le rapport de rapprochement du domaine le plus récemment migré et le nom de la personne qui l'examine quotidiennement.
4. Lisez le contrat. Si le paiement est attaché à une date plutôt qu'aux consommateurs migrés, renégociez avant que la date ne devienne le plan.
5. Convoquez le comité de changement avec le pouvoir d'approuver ou d'arrêter chaque étape contre preuve, et excluez de celui-ci toute personne qui ne peut pas y assister.
6. Écrivez les déclencheurs de restauration pour l'étape suivante, avec les chiffres, et nommez la personne qui détient la décision.