Les transactions financières sans interruption – qui ne souhaite pas cela ?

Certains systèmes logiciels sont tellement essentiels qu’ils requièrent les niveaux de disponibilité les plus élevés. Certes, dans le secteur financier, il ne s’agit pas d’une question de vie ou de mort. Mais dans le cas des procédures de paiement en temps réel ou des processus d’autorisation en temps réel, des exigences toujours plus importantes sont définies et surtout les périodes de maintenance ne sont plus acceptées. Et cela à juste titre : si, à cause d’une fenêtre de maintenance, vous recevez votre relevé de compte une heure plus tard, ou si le portail est inaccessible pendant une heure, cela peut être fâcheux, mais sans trop de conséquences. En revanche, si le client d’une banque ne peut plus payer sur le point de vente ou ne peut autoriser un paiement en temps réel, l’indisponibilité est d’une importance sérieuse.

Par conséquent, après le processus d’autorisation des paiements par carte, le transfert en temps réel est également devenu un domaine d’application des systèmes sans interruption avec l’introduction des paiements instantanés en Europe.

Commençons par le concept de continuité de service. Un fonctionnement sans interruption est défini par deux propriétés différentes :

  1. Éviter l’indisponibilité prévue
    En fonctionnement normal, le système est prêt à fonctionner en permanence. Il n’existe donc pas de période de fonctionnement limité, par exemple en fin de journée ou lors d’une réorganisation.
    Le système est conçu pour que les changements de version puissent également être effectués en cours d’exploitation et ne provoquent aucun temps d’arrêt. 
  2. Réduire l’indisponibilité non prévue
    Le système est hautement disponible même en cas d’erreur. La garantie de fonctionnement est donc importante malgré la défaillance de certains composants. Cette probabilité est calculée ou mesurée comme le rapport entre le temps de production et la durée d’exécution, c’est-à-dire le temps incluant le temps d’interruption, par exemple 99,99 %.
    La robustesse des scénarios de surcharge est particulièrement importante dans ce contexte. Bien que chaque système ait ses limites, il y a une différence entre l’effondrement total du système en raison d’un dépassement de la limite de charge et le fait que seule la charge supplémentaire ne peut être traitée conformément aux spécifications.

En règle générale, l’enthousiasme pour le sujet diminue considérablement lorsque l’on considère les coûts. Il convient alors de trouver des solutions architecturales et non seulement déplacer tout sur l’infrastructure. Néanmoins, même le meilleur logiciel ne pourra fonctionner que si l’environnement système est disponible. Je ne vais pas rentrer dans les détails de l’infrastructure hautement disponible, des systèmes d’exploitation, des systèmes de base de données et des agents de messages – tous ces éléments sont les conditions de base pour un système global sans interruption. Je voudrais plutôt me concentrer sur l’architecture logicielle. Cela permettrait de mettre en œuvre les exigences de disponibilité de manière ciblée tout en surveillant les coûts.

La haute disponibilité étant coûteuse, il faut avant tout identifier les processus critiques. Par conséquent, il faut savoir quels sont les processus devant toujours fonctionner et ceux qui peuvent être exécutés ultérieurement. Dans le cas des paiements en temps réel par exemple, les traitements en masse sont moins cruciaux que les paiements individuels.

Au cas où les grands composants relèvent des processus critiques, il convient d’analyser si ceux-ci peuvent être contournés. Un composant alternatif peut-il remplacer les tâches critiques d’un grand composant qui n’est pas hautement disponible pendant la période de défaillance ? Dans les transferts de paiements, le système de réservation peut être un très grand système qui n’est pas hautement disponible et la vérification de solde en ligne peut être le processus critique qui doit être contourné.

Bien entendu, dans l’ensemble, les transactions financières ne sont traitées sans statut: l’argent ne peut malheureusement être dépensé qu’une seule fois, le solde du compte étant alors un statut pertinent et un logiciel bancaire doit bien sûr pouvoir le refléter avec précision. Dans notre cas, cela se traduit toujours par l’utilisation de bases de données et par la nécessité de faire preuve de persistance avant et après chaque changement de statut. C’est surtout la conception du modèle de base de données qui détermine si nous atteignons ou non notre objectif. Les processus hautement disponibles sont conçus pour fonctionner avec des structures de données stables et sans migration. C’est la seule possibilité pour éviter l’arrêt de processus critiques pour changer le schéma de la base de données.

Il reste la question de la robustesse. La science parle également de résilience lorsque l’on décrit que les défaillances ou les défaillances partielles des systèmes techniques ne conduisent pas à une panne totale. Dans les transferts de paiement, ces pannes peuvent être des pics de charge supérieurs aux limites convenues ou des systèmes périphériques qui ne répondent pas aussi rapidement que convenu. Les défaillances chez les partenaires commerciaux et les accusés de réception manquants en grandes quantités peuvent également entraîner des défaillances. Nous avons trouvé un paradigme dans la programmation réactive permettant la robustesse souhaitée à travers l’orientation des flux de données. Une surcharge peut ainsi être encapsulée dans les zones touchées et rien ne s’oppose au traitement sans panne des données restantes – dans notre cas, les paiements.


Auteur : Thomas Riedel

0 commentaires:

Publier un commentaire