Allegro ETRM : les incidents de production courants et comment les investiguer

Toute personne ayant assuré le support de production d'un environnement Allegro assez longtemps finit par reconnaître les mêmes quelques catégories d'incidents, trimestre après trimestre, environnement après environnement. Connaître le motif à l'avance rend l'investigation nettement plus rapide que de repartir de zéro à chaque fois.

1. P&L incorrect ou inattendu

C'est la catégorie la plus fréquente - et la plus urgente. L'investigation suit presque toujours la même chaîne : confirmer que les données de deals et de positions sont correctes, puis vérifier que les données de marché utilisées pour la valorisation sont bien celles attendues, puis contrôler que la logique de valorisation elle-même (construction des courbes, actualisation, ajustements de base) est paramétrée conformément à l'intention. D'après notre expérience, les problèmes de données de marché - un prix manquant, un repli sur une valeur périmée, une courbe mal appariée - sont une cause racine plus fréquente que les erreurs de logique de valorisation.

2. Prix de marché manquants

Lorsqu'un prix ne s'alimente pas, la cause est généralement l'une des suivantes : un retard ou une défaillance du flux à la source, une incohérence de mapping entre le nom de l'indice dans le flux et l'indice paramétré dans Allegro, ou un décalage de calendrier ou de jour férié faisant sauter une date de prix attendue. Comparer le flux entrant brut à ce qu'Allegro a effectivement reçu est le moyen le plus rapide d'isoler laquelle de ces causes est en jeu.

3. Views et ViewSets qui ne remontent pas de données

Les Views et ViewSets sont puissants, mais leur logique (jointures, filtres, paramètres) reste opaque tant que l'on n'a pas lu la requête ou le paramétrage sous-jacent. Lorsqu'une View renvoie un résultat inattendu ou vide, commencez par exécuter la requête sous-jacente directement en base avec les mêmes paramètres que la View, plutôt que de déboguer via l'interface : cela permet d'isoler si le problème vient des données, de la logique de la requête ou de la couche de présentation.

4. Écarts de positions

Les écarts de positions remontent typiquement à l'une des causes suivantes : un deal qui a échoué à la validation et n'a jamais été agrégé dans la position, un avenant qui n'a pas été entièrement propagé, ou un décalage temporel entre les moments d'exécution de deux rapports. Comparer des instantanés de positions pris au même moment, plutôt que de confronter une vue en direct à un rapport historique, élimine une grande part des faux écarts.

5. Lenteur d'extraction des données

Les problèmes de performance concernent généralement une View, un rapport ou un traitement batch précis, plutôt que l'ensemble du système. Analyser la requête lente en question - indexation, complexité des jointures, volume de données parcouru par rapport au besoin réel - est plus productif qu'un réglage général de l'infrastructure, qui résout rarement le cas d'un rapport isolément lent.

6. Écarts de règlement

Les problèmes de règlement proviennent le plus souvent d'un décalage entre les conditions du deal utilisées pour la programmation et la livraison et celles utilisées pour la facturation, ou d'un écart temporel entre le moment où un prix a été figé pour le règlement et celui où le règlement a effectivement eu lieu sur le marché. Remonter la ligne de facture concernée jusqu'au deal source et à ses conditions de prix résout généralement l'écart.

Un cadre d'investigation général