Les documents que vous recevez, pas seulement le logiciel.

Deux systèmes détiennent des enregistrements censés concorder. Ils sont comparés à la main, à un rythme qui dépend du fait que quelqu'un s'en souvienne, et un écart est le plus souvent remarqué par la personne qu'il gêne plutôt que par le processus qui l'a produit. Le travail remplace cela par un service qui compare les deux côtés selon un calendrier fixe, clôt les écarts pour lesquels il a une règle et signale les autres.

Cette section est reformulée à l'attention de l'acheteur avec ses propres mots, et le cadrage n'est pas validé tant qu'il n'y reconnaît pas son problème. Un cadrage bâti sur un énoncé que le client aurait formulé autrement est déjà faux, et la plupart des désaccords qui surgissent plus tard remontent à ce paragraphe.

• Exécution de réconciliation: Une comparaison planifiée des deux enregistrements, qui produit un ensemble qui concorde, un ensemble d'écarts qu'une règle peut clore et un ensemble qui demande une personne.
• Règles de résolution: Les règles qui closent un écart sans intervention humaine, écrites et versionnées avec le service plutôt que de ne vivre que dans le code qui les applique.
• File d'exceptions: L'endroit où un écart qu'aucune règle ne clôt est envoyé pour examen, avec les deux enregistrements sources joints pour qu'on puisse agir sans seconde enquête.
• Surface d'exploitation: Ce dont les exploitants ont besoin pour lancer, suspendre et inspecter une réconciliation sans solliciter un ingénieur.
• Passation: Le runbook, la restitution des accès et une séance de travail avec les personnes qui exploiteront ensuite le service.

• Modifier l'un ou l'autre des systèmes de référence. Les deux sont lus tels quels, et le service n'a aucune opinion sur celui qui a raison au-delà des règles convenues ici.
• La correction automatique d'un écart qu'aucune règle ne couvre. Le service le signale. Une personne décide.
• La reprise de l'historique au-delà de la fenêtre indiquée dans les hypothèses ci-dessous.
• Tout ce qui est découvert après la validation de ce document, sauf s'il passe par la procédure de modification décrite à la fin de ce document.

Dans un document de cadrage, c'est la moitié consacrée à ce qui est hors périmètre qui fait le travail. Sur ce qui est dans le périmètre, les deux parties sont déjà d'accord. Ce qui est en dehors, ce sont les points que chacune a supposés différemment sans encore s'en apercevoir.

• Première étape, lire les deux côtés: Validée lorsqu'une exécution lit les deux enregistrements de bout en bout depuis un démarrage à froid et produit un ensemble d'écarts reproductible : mêmes entrées, même sortie, et l'exécution peut être répétée sans effet de bord.
• Deuxième étape, clore ce qui a une règle: Validée lorsque chaque règle de l'ensemble convenu est couverte par un test qui nomme le cas qu'il vérifie, et lorsque modifier une règle est une modification relue de l'ensemble de règles et non du service.
• Troisième étape, confier le reste à une personne: Validée lorsqu'un écart sans règle correspondante atteint la file d'exceptions avec les deux enregistrements sources joints, et qu'une personne qui n'a pas participé à la réalisation peut le résoudre.
• Quatrième étape, l'exploiter: Validée lorsque les exploitants mènent eux-mêmes un cycle complet, à partir du runbook, l'équipe de réalisation observant sans piloter.

Un critère de recette est une phrase à laquelle on peut tenir quelqu'un. Si une ligne ne peut pas être vérifiée par une personne extérieure à la réalisation, c'est un espoir et non un critère, et elle n'a pas sa place dans cette section.

Chaque ligne ci-dessous est tenue pour vraie afin d'ordonner et de chiffrer le travail. Si l'une se révèle fausse, le cadrage change, et le changement se voit au lieu d'être absorbé.

• Les deux enregistrements sont lisibles sans modifier les systèmes qui les détiennent, et un accès en lecture peut être accordé pour la durée de la mission.
• Les règles qui closent un écart peuvent être écrites. Lorsqu'une règle se révèle être un jugement porté au cas par cas, elle reste un jugement et l'écart va dans la file.
• Une personne côté client peut décider de ce qui compte comme une concordance. Un travail de réconciliation cale plus vite sur une définition sans réponse que sur une ligne de code non écrite.
• Les volumes et les délais restent dans la plage consignée au lancement, seul endroit de ce document où figure un chiffre.

• Une hypothèse fausse: L'hypothèse contredite est nommée, et le changement est chiffré par rapport à l'écart au lieu de rouvrir tout le document.
• Une nouvelle exigence: Elle arrive sous forme d'avenant avec sa propre étape et son propre critère de recette, ou elle attend.
• Une étape refusée deux fois en recette: Le second échec dit quelque chose du critère et pas seulement du travail : on examine donc les deux avant la troisième tentative.
• Rien d'autre: Un cadrage qui dérive sans avenant écrit n'est pas un cadrage, et à la fin personne ne peut dire ce qui avait été convenu.

Le cadrage est validé par écrit par les deux parties, et la version validée est celle à laquelle la mission est tenue.

Chaque exécution ajoute ses écarts à un registre au lieu de mettre à jour une table des désaccords actuellement ouverts. Un écart est une ligne dotée d'un marqueur de première observation, d'un marqueur de dernière observation et d'une résolution, et il n'est jamais modifié sur place : le clore ajoute une résolution, et le revoir ajoute une observation.

L'état courant, ce que l'exploitant regarde réellement, est dérivé du registre plutôt que stocké à côté.

• Une table modifiable des écarts ouverts: La forme évidente et la moins chère à écrire. Non retenue, car elle ne répond qu'à la question de ce qui diverge maintenant. La question à laquelle ce service existe pour répondre est de savoir quand les deux côtés ont commencé à diverger et ce qui a clos l'écart, et une table écrasée à chaque exécution ne peut pas y répondre du tout.
• Un journal sans vue dérivée: Conserve tout l'historique et ne coûte presque rien à écrire, mais fait porter la reconstruction à chaque lecteur, y compris à l'exploitant qui résout une exception dans l'urgence. Non retenu, car la surface d'exploitation est ici un livrable et non un effet secondaire.
• La réconciliation à l'intérieur de l'un des deux systèmes: Supprime une pièce mobile et une intégration. Non retenue, car elle fait d'un système l'arbitre d'un désaccord dont il est partie, et parce que le cadrage exclut de modifier l'un ou l'autre.

Les alternatives écartées sont la partie d'une note d'architecture qui se perd d'ordinaire, et la plus coûteuse à reconstituer plus tard. Une note qui ne consigne que la décision laisse au prochain ingénieur le soin de redécouvrir les trois formes qui ne fonctionnent pas.

• Le registre grandit sans limite tant qu'aucune règle de conservation n'est convenue, et cette règle est une question ouverte ci-dessous plutôt qu'une décision prise ici.
• Chaque lecture de l'état courant coûte une dérivation. La vue dérivée est un cache, et un cache est une seconde chose qui peut être fausse.
• Corriger une erreur revient à ajouter une correction, ce qui est plus lent à écrire et plus difficile à expliquer à quelqu'un qui attend une ligne modifiable. Le runbook porte cette explication pour cette raison précise.

• Une règle de conservation qui écarte l'historique plus vite que le registre ne se rentabilise. Si un écart clos peut être oublié après une courte fenêtre, la table modifiable devient le choix honnête.
• Une exigence de modifier une résolution plutôt que d'ajouter une correction, venant d'un auditeur et non d'un souci de commodité.
• Un coût de dérivation qui cesse de tenir dans la cadence d'exécution convenue au cadrage. C'est une mesure, et elle n'a sa place dans cette section qu'une fois que quelqu'un l'a prise.

• Conservation: La durée pendant laquelle un écart clos mérite d'être gardé n'est pas décidée, et c'est une question métier plutôt que d'ingénierie.
• Reconstruire ou maintenir: Savoir si la vue dérivée est reconstruite à chaque exécution ou maintenue de façon incrémentale. Les deux sont viables, et le choix dépend des volumes du document de cadrage, qu'un exemple ne remplit pas.
• À qui revient un changement de règle: Les règles sont versionnées avec le service, ce qui fait d'en modifier une un événement d'ingénierie, sauf si quelqu'un côté client reçoit l'autorité de la changer sans en passer par là.

Une question ouverte reste dans la note, avec un nom en face, jusqu'à ce qu'elle reçoive une réponse. C'est en la supprimant parce qu'elle gêne qu'un système acquiert une décision que personne ne se souvient d'avoir prise.

Une note d'architecture est amendée, jamais réécrite. Une décision remplacée garde sa section et reçoit une note indiquant ce qui l'a remplacée et pourquoi, car le raisonnement qui s'est révélé faux est souvent ce qu'il y a de plus utile dans le fichier.

• Lancer une exécution: Les exécutions sont planifiées, et en lancer une à la main est une action prise en charge. On peut la répéter sans risque : une exécution est idempotente par conception, donc une seconde exécution sur la même fenêtre produit le même ensemble d'écarts.
• Suspendre le calendrier: La suspension arrête les nouvelles exécutions et laisse finir celle en cours. C'est le bon premier geste chaque fois que l'un des systèmes sources est en maintenance.
• Clore une exception: L'ouvrir, lire les deux enregistrements sources qui y sont joints, puis soit appliquer une règle existante, soit consigner la résolution comme cas isolé avec un motif. Un cas isolé qui se répète est une règle manquante, et se signale comme telle.
• Ajouter une règle de résolution: Les règles sont versionnées avec le service, et en ajouter une est une modification relue. La relecture existe parce qu'une règle erronée clôt des écarts en silence, ce qui est pire que de ne pas les clore.

• Un système source est injoignable: L'exécution échoue entièrement plutôt que partiellement, rien n'est écrit, et le calendrier continue d'essayer. Aucune action n'est nécessaire sauf si la panne dépasse le retard acceptable consigné ci-dessous. Ne forcez pas une exécution partielle : un ensemble d'écarts construit à partir d'un seul côté n'est pas un ensemble d'écarts.
• Une exécution se termine avec un nombre invraisemblable d'écarts: Supposez qu'une source a changé de forme avant de supposer que les deux côtés ont divergé. Suspendez d'abord le calendrier, car une exécution sur une source mal lue remplit la file d'exceptions de bruit qu'il faut ensuite purger à la main.
• La vue dérivée diverge du registre: Le registre fait foi. Reconstruisez la vue à partir de lui. La reconstruction est sans risque à tout moment et n'exige pas de suspendre le calendrier.
• Une exception que personne de disponible ne peut résoudre: Laissez-la ouverte. Un écart non résolu est une inconnue connue, et les conserver est la raison d'être de ce service. Une résolution devinée est un faux enregistrement qui paraît ensuite correct pour toujours.

Un runbook qui dit de consulter les journaux n'est pas encore écrit. Les adresses ci-dessous relèvent du document réel, remplies à la passation et tenues à jour quand elles changent.

Certaines choses ne sont pas automatisées à dessein. Un runbook qui ne dit pas lesquelles laisse au prochain ingénieur le soin de les automatiser et d'en découvrir la raison après coup.

• Clore un écart qu'aucune règle ne couvre. Une personne décide, car l'alternative est un service qui invente un accord.
• Ajouter une règle. Relue plutôt qu'en libre-service, pour la raison donnée dans les opérations courantes.
• Restaurer depuis une sauvegarde. Répétée et documentée, mais lancée par une personne, car une restauration automatique déclenchée par une fausse alerte est un incident en soi.

• Le service signale un désaccord. Il ne décide pas quel côté a raison, sauf lorsqu'une règle le dit.
• L'historique grandit tant qu'aucune règle de conservation n'est convenue. La note d'architecture le porte comme question ouverte, et c'est répété ici parce que l'exploitant est le premier à s'en apercevoir.
• Un changement de règle s'applique aux exécutions qui suivent et non aux écarts déjà clos. Rouvrir un écart clos est une action délibérée, avec sa propre procédure, jamais un effet secondaire de la modification d'une règle.

Une section de limites vide signifie qu'elle n'a pas été écrite. Tout système a un comportement qui surprendra quelqu'un, et le nommer ici coûte moins cher que de le découvrir pendant un incident.

La passation n'est pas terminée tant que l'équipe de réalisation peut encore atteindre le système. Chaque identifiant émis pendant la mission est révoqué ou renouvelé, et la restitution est consignée dans la liste de contrôle des accès qui l'a émis.