Dollar Universe : pourquoi la reprise après incident se décide à la conception

L’alerte part, l’astreinte ouvre Univiewer et trouve une uproc en ABORTED. Le statut est exact, et parfaitement insuffisant : il indique qu’un traitement s’est arrêté. Il ne dit ni ce qui a été traité avant l’arrêt, ni à partir d’où la chaîne peut repartir sans produire de dégâts.

Dans un incident d’ordonnancement, le temps de la panne pèse peu. C’est le temps de l’arbitrage qui coûte : reconstituer le périmètre réellement traité, choisir un point de reprise, obtenir l’accord de l’application concernée. Ce délai ne dépend presque pas de qui est de garde ce soir-là. Il dépend de la façon dont le plan de production a été conçu, plusieurs mois plus tôt.

Cet article porte sur ce second temps, dans un contexte précis et rarement documenté : Dollar Universe sous Windows Server, des traitements en BAT et PowerShell, et des chaînes qui appellent SAP ou des services extérieurs au système d’information.

La reprise se prépare à la conception, pas pendant l’incident. Un plan découpé finement, nommé dans le vocabulaire du métier et documenté se reprend en quelques minutes. Un plan monolithique se reprend en heures, quelle que soit la compétence de la personne qui l’ouvre en pleine nuit.

Les chaînes qui sortent du système d’information cassent différemment. Dollar Universe raisonne en synchrone : il lance, il attend, il récupère un code retour. La plupart des services externes rendent la main avant d’avoir terminé leur travail. Tant que cet écart n’est pas traité explicitement, le plan de production tient pour acquis des choses fausses.

Un statut n’est pas une trace. ABORTED décrit une exécution interrompue. Ce qui permet de reprendre, c’est ce que le traitement a écrit lui-même avant de s’arrêter.

Dollar Universe fait exactement ce qu’on lui demande : il exécute, il surveille, il enchaîne si le code retour est conforme, il s’arrête sinon. Le statut d’une uproc décrit l’état de l’exécution telle que l’ordonnanceur l’a observée. Rien de plus, et c’est déjà beaucoup.

Ce qu’il ne contient pas, c’est l’état du système en aval. Une uproc qui déclenche un traitement de facturation et qui part en ABORTED au bout de trente minutes recouvre trois situations très différentes : rien n’a été écrit, une partie du périmètre a été traitée, ou l’intégralité du traitement s’est déroulée correctement et seule la remontée du résultat a échoué. Les trois produisent le même statut. Les trois appellent une décision opposée.

C’est là que se perd le temps d’un incident. Pas dans le diagnostic technique, qui prend quelques minutes, mais dans la reconstitution de ce qui s’est réellement passé, et dans les échanges avec l’application concernée pour valider un point de reprise. Une organisation qui veut réduire son temps d’indisponibilité ne gagne pas grand-chose à surveiller mieux. Elle gagne à rendre ses chaînes interprétables.

Un traitement local est simple à ordonnancer. Le script tourne, il se termine, il rend un code. L’ordonnanceur sait précisément quand l’étape est finie, parce qu’il tient le processus.

Dès qu’un système externe entre en jeu, ce contrat se rompt. Sur SAP, le Manager for SAP Solutions permet de déclencher un job et d’en suivre l’exécution, ce qui règle une grande partie du problème : la surveillance est prise en charge par le composant, pas par un script maison. Mais dès qu’on sort du périmètre couvert par un Manager, appel d’API, service tiers, plateforme d’intégration, c’est au traitement d’assurer lui-même la surveillance. Déclencher, conserver l’identifiant de l’appel distant, interroger périodiquement son état, puis traduire cet état en code retour intelligible pour l’uproc.

Cette boucle, il faut l’écrire, et c’est là que se logent les erreurs qui coûtent une nuit. Un script qui déclenche puis rend la main immédiatement fait passer l’uproc en succès alors que le travail commence à peine. La suite de la chaîne démarre sur des données incomplètes. C’est le scénario le plus coûteux de tous, parce que l’incident ne se déclare pas à l’étape fautive mais deux ou trois étapes plus loin, sur un symptôme sans rapport apparent avec la cause.

La parade habituelle consiste à poser une durée maximale dans les paramètres de l’uproc. Elle est indispensable : sans cette borne, une uproc bloquée sur un service qui ne répond plus immobilise le plan de production jusqu’au matin, et l’incident cesse d’être local pour devenir général.

Mais un timeout protège la chaîne, il n’informe personne. Quand il se déclenche, il produit précisément la situation qu’on cherchait à éviter : une uproc en anomalie, et aucune indication sur l’état réel du traitement distant. Le service externe a peut-être terminé une seconde plus tard. Il a peut-être traité la moitié du périmètre. Rien dans le plan de production ne permet de le savoir.

D’où une règle simple, et qui ne coûte presque rien à appliquer : tout appel vers l’extérieur doit produire sa propre trace, indépendamment du statut renvoyé à l’ordonnanceur. Un fichier horodaté, écrit par le traitement, qui consigne l’identifiant de l’appel distant, l’heure de déclenchement, les étapes franchies et le dernier état connu. C’est ce fichier, et non le statut de l’uproc, qui permet de décider d’un point de reprise en trois minutes plutôt qu’en trente.

La documentation de Dollar Universe, comme la quasi-totalité des retours d’expérience disponibles en ligne, décrit des environnements Unix et des traitements en shell. Les plans de production sous Windows Server, avec des scripts BAT et PowerShell, sont pourtant nombreux, et ils posent des problèmes qui leur sont propres.

Le code retour est le piège numéro un. Un script PowerShell se termine par défaut avec un code nul, y compris lorsqu’une exception a été levée en cours de route. L’uproc voit un succès, la chaîne continue, et l’erreur ne se manifeste que plus loin. Trois réflexes ferment ce trou : positionner $ErrorActionPreference sur Stop en tête de script, encadrer le corps du traitement dans un bloc try/catch, et terminer par un exit explicite dont la valeur est décidée par le script. Si le script appelle un exécutable externe, c’est $LASTEXITCODE qu’il faut relayer, et non le résultat de la commande PowerShell qui l’enveloppe.

Le script qui fonctionne en manuel et échoue en ordonnancé est le second classique, et la cause est presque toujours la même. L’exécution manuelle se fait sous votre compte, dans votre session ouverte, avec vos lecteurs réseau montés et votre profil chargé. L’uproc, elle, s’exécute sous le compte de service, sans profil, sans lecteur mappé, avec sa propre politique d’exécution. Les corrections sont connues : chemins UNC absolus plutôt que lettres de lecteur, aucun chemin relatif, politique d’exécution vérifiée pour le compte concerné, variables d’environnement déclarées dans le script plutôt que supposées présentes.

L’encodage ferme la liste, et c’est le plus rageant. Un script qui écrit des accents dans un fichier de trace peut produire un contenu illisible selon la page de code active, ce qui rend inexploitable exactement le document dont on a besoin en pleine nuit.

Ce qu’il faut en retenir si ces détails ne sont pas votre métier : un traitement qui remonte un statut faux est plus dangereux qu’un traitement qui échoue franchement. La fiabilité d’un plan de production se joue autant dans le code des scripts que dans le paramétrage de l’ordonnanceur.

Documenter le plan de production et les procédures de reprise. Reprendre chaîne par chaîne ce que fait chaque uproc, ce dont elle dépend, et ce qu’il faut vérifier avant de la relancer. C’est le chantier le moins visible et celui qui change le plus de choses au premier incident.

Fiabiliser les scripts. Codes retour explicites, traces horodatées, gestion propre des appels vers les systèmes externes, suppression des dépendances implicites à un profil ou à un lecteur mappé.

Paramétrer et faire évoluer. Création et refonte d’uproc, de sessions, de tâches, de règles de dépendance et de business views, avec un découpage pensé pour la reprise plutôt que pour la seule exécution.

Renforcer l’équipe ponctuellement. Surveillance du plan de production, traitement des incidents et relances, en appui d’une équipe en sous-effectif ou pendant une période de charge.

Nos interventions se font en mode mixte, sur site et à distance, partout en France, sur des engagements au mois. Nous n’assurons pas d’astreinte permanente et nous ne conduisons pas de migration d’ordonnanceur : notre terrain, c’est le contenu des chaînes et leur fiabilité.