Votre système de transmission des données du CDC n'est pas hors service. Êtes-vous sûr qu'il fonctionne correctement ?

Un processus de contrôle des maladies chroniques (CDC) n'a pas besoin de dysfonctionner pour créer un risque.

Parfois, la réplication est toujours en cours. Le statut du processus est vert. La cible est toujours disponible. Mais la liste d'attente s'allonge.

La cible devient de plus en plus obsolète. Et chaque minute qui passe en retard sur le pipeline réduit les options de récupération. La question n'est pas simplement: « La réplication est-elle en cours ? » mais: « La réplication suit-elle le rythme ? »

Et si ce n'est pas le cas: « De combien de temps disposons-nous avant que cela ne devienne un problème de rétablissement ? »

La surveillance CDC la plus efficace ne se contente pas d'indiquer aux opérateurs si un processus est en marche ou à l'arrêt. Elle les aide à déceler les signes avant-coureurs d'une situation qui, bien qu'apparemment saine, se dégrade insidieusement et dont la reprise sera plus difficile.

Un bon suivi aide les équipes à répondre à:

• Quel est notre retard ?
• Le carnet de commandes augmente-t-il ou diminue-t-il ?
• Le projet progresse-t-il réellement ?
• Les équipes en aval utilisent-elles déjà des données obsolètes ?
• Comprenons-nous encore nos options de rétablissement si la situation s'aggrave ?

L'objectif n'est pas de prédire tous les échecs, mais de repérer les problèmes naissants suffisamment tôt pour que l'équipe ait encore des solutions.

Selon les plateformes source et de réplication, une surveillance efficace des données modifiées (CDC) peut impliquer des indicateurs et des concepts tels que le délai de réplication, la croissance du backlog, le délai d'application des données source et cible, l'état de redémarrage, la position du journal, l'historique des modifications conservées, les journaux archivés, la progression RBA/LRSN, le comportement de rattrapage et l'exposition des données en aval. La terminologie exacte varie, mais l'objectif reste le même: comprendre si la réplication suit le rythme et si la récupération demeure simple en cas de dégradation de la situation.

Comment puis-je détecter qu'un pipeline CDC prend du retard avant qu'il ne tombe en panne ?

Un pipeline peut fonctionner pendant que le délai augmente, que le retard s'accumule et que les données en aval deviennent obsolètes.

Réponse rapide: Commencez par répondre à cinq questions opérationnelles:

1. Quel est notre retard ?
2. Le carnet de commandes est-il en croissance, stable ou en diminution ?
3. Disposons-nous encore de l'historique source dont nous pourrions avoir besoin en cas de nécessité de récupération ?
4. Le projet progresse-t-il réellement ?
5. Qui dépend déjà des données en aval, et y a-t-il des signes indiquant que la situation s'aggrave ?

Les indicateurs et seuils d'alerte précis dépendent de la source, de la cible, de la plateforme de réplication, de la charge de travail, des exigences de récupération et du cas d'utilisation en aval. Il n'existe pas de nombre universel de minutes, d'enregistrements ou d'espace de journalisation définissant une situation d'urgence CDC.

Un pipeline peut afficher « En fonctionnement » tout en se dirigeant vers un problème de récupération.

Le suivi doit répondre à deux questions différentes

1. Le pipeline est-il en bonne santé actuellement ?

Voici la question opérationnelle immédiate: la réplication ?

• Vous suivez ?
• Vous prenez du retard ?
• Bloqué ?
• En convalescence ?
• Fonctionnement en mode dégradé ?

L'état d'avancement du processus fait partie de la réponse. Ce n'est pas la réponse complète.

2. Perdons-nous des options de récupération à mesure que le délai augmente ?

Voici la question plus complexe. Un pipeline peut rester actif pendant que:

• Le nombre de dossiers en attente continue d'augmenter.
• La cible devient de plus en plus obsolète
• Le rattrapage prend plus de temps.
• Les équipes en aval continuent d'utiliser d'anciennes données
• Modifications de l'historique des sources disponibles
• Un problème opérationnel relativement circonscrit se transforme en un problème de récupération plus important.

La question la plus importante est: « Si la situation s'aggrave, savons-nous encore comment nous en remettre ? »

1. Quel est notre retard ?

Le délai de réplication indique l'écart entre l'activité cible et l'activité source actuelle. Cependant, un chiffre brut ne suffit pas toujours. Un retard de 100 000 modifications peut être négligeable dans un environnement et significatif dans un autre. Ce que les opérateurs doivent généralement comprendre, c'est: « Quel est l'impact de ce délai sur le temps et l'activité ? »

Métriques de délai de réplication du CDC: que mesurer et comment les interpréter

Les différentes plateformes affichent différemment les délais et la progression. Selon la source, la cible et la technologie de réplication, une surveillance utile peut inclure:

• délai de réplication écoulé
• décalage côté source
• cibler ou appliquer un décalage
• arriéré de modifications ou de transactions
• position source par rapport à la position de traitement actuelle
• profondeur de la file d'attente ou de la tâche
• débit
• horodatage du dernier traitement réussi
• tendance de rattrapage
• informations de diagnostic et d'état spécifiques à la plateforme

L'appellation exacte des indicateurs importe moins que la capacité des opérateurs à répondre:

• Quel est notre retard ?
• Où se situe le retard ?
• La situation s'améliore-t-elle ?

Demander

• Quel est le retard par rapport à l'objectif ?
• Quand le décalage a-t-il commencé ?
• Est-ce normal pour cette période de charge de travail ?
• Quels systèmes en aval dépendent de ces données ?
• À quel moment le décalage devient-il important pour eux ?

Pourquoi c'est important

Un objectif retardé de cinq minutes peut être acceptable pour une charge de travail et inacceptable pour une autre. L'indicateur technique doit être interprété en fonction des données utilisées.

À quoi ressemble le bien

L'équipe opérationnelle peut dire: « Nous avons environ tant de retard, et voici ce que cela signifie pour les systèmes qui utilisent ces données. »

Pas simplement: « La tâche est toujours en cours d'exécution. »

2. Le carnet de commandes est-il en croissance, stable ou en diminution ?

Le sens du retard est aussi important que son ampleur. Un pipeline fortement en retard mais qui rattrape rapidement son retard présente une situation différente d'un pipeline avec un retard plus faible mais qui perd progressivement du terrain. Les professionnels décrivent souvent cela très simplement: « Est-ce qu'il est en train de s'effondrer ? »

Demander

• Le nombre de dossiers en attente augmente-t-il ?
• La situation s'est-elle stabilisée ?
• Est-ce que ça rétrécit ?
• Le pipeline suit-il le rythme de l'activité des nouvelles sources ?
• Le traitement est-il plus rapide que l'arrivée des nouvelles tâches pendant la période de rattrapage ?
• La tendance a-t-elle changé depuis le début de l'incident ?

Taux de capture par rapport au taux de traitement ou d'application

Lorsque la plateforme propose des indicateurs pertinents, la comparaison des modifications entrant dans le flux de réplication avec celles en cours de traitement sur la cible permet d'évaluer l'évolution de l'environnement. Les mesures spécifiques varient selon la plateforme. Le principe est simple: si, pendant une période prolongée, le volume de nouvelles tâches arrive plus rapidement que la capacité de traitement du pipeline, le backlog continuera de croître, même si le processus n'est pas interrompu.

À quoi ressemble le bien

Les opérateurs peuvent rapidement faire la distinction: prendre du retard → maintenir le cap → rattraper son retard

Drapeau rouge

Le tableau de bord indique le délai actuel, mais pas si la situation s'améliore.

4. Le pipeline progresse-t-il réellement ?

Un processus peut être actif sans pour autant faire progresser significativement les données.

Cela fait de la preuve d' une activité de traitement réussie un contrôle de cohérence important.

Selon la plateforme, les équipes peuvent examiner:

• activité de réplication réussie la plus récente
• modification traitée la plus récente
• application de la cible la plus récente
• progression dans une position enregistrée ou état de traitement
• mouvement des dossiers en attente
• débit
• un autre indicateur de progrès spécifique à la plateforme

Demander

Y a-t-il eu des progrès concrets ?

Et puis:

Le développement progresse-t-il au rythme attendu compte tenu de cette source et de cette charge de travail ?

La réponse doit tenir compte du mode d'activité normal du système.

Un environnement transactionnel à volume élevé peut normalement évoluer en permanence.

Une autre source peut présenter des périodes légitimes de faible ou d'inactivité.

Pourquoi c'est important

Cela permet d'identifier l'état inconfortable dans lequel:

« Il indique qu'il fonctionne, mais rien ne bouge. »

À quoi ressemble le bien

L'environnement de surveillance permet de distinguer:

la source est naturellement calme

depuis

La réplication a cessé de progresser.

Drapeau rouge

Le seul contrôle d'intégrité consiste à vérifier si le processus de réplication existe.

5. Qui utilise déjà des données obsolètes ?

De nombreux problèmes liés au CDC commencent par des problèmes techniques et deviennent ensuite des problèmes commerciaux:

La source peut encore être fonctionnelle. La cible peut encore être disponible. La réplication peut encore être en cours. Cependant, les rapports, tableaux de bord, API, systèmes opérationnels et environnements analytiques peuvent déjà fonctionner avec des données de plus en plus obsolètes.

Cela crée l'un des modes de défaillance les plus dangereux pour les CDC: les écrans sont installés, mais les données vieillissent.

Demander

• Quelles applications dépendent de la cible concernée ?
• Quels rapports ou tableaux de bord l'utilisent ?
• Les données sont-elles toujours consommées par les outils d'analyse, les API, les systèmes opérationnels ou les charges de travail d'IA ?
• Quelqu'un en aval sait-il que le flux est obsolète ?
• Une échéance importante de reporting, de règlement, de traitement par lots, de relation client ou d'opérations approche-t-elle ?
• Toute utilisation en aval doit-elle être suspendue ou soumise à des restrictions pendant que le problème est examiné ?

Pourquoi c'est important

Plusieurs choses très différentes peuvent être vraies en même temps:

• La source est saine.
• La cible est disponible.
• Le pipeline est en retard.
• Des gens utilisent encore la cible.

Cela peut rendre la détection d'une exposition à des données obsolètes plus difficile que celle d'une panne nette.

À quoi ressemble le bien

L'équipe peut répondre:

« Voilà à quel point les données sont obsolètes, voici les consommateurs concernés, et ces personnes connaissent la situation actuelle. »

6. Les avertissements, les erreurs ou les événements environnementaux nous indiquent-ils que quelque chose est en train de changer ?

Tous les avertissements ne sont pas synonymes de crise.

Et le fait de recevoir une alerte pour chaque message peut générer suffisamment de bruit pour que les opérateurs cessent de faire confiance au système de surveillance.

L'objectif est d'identifier les événements importants dans votre environnement et de les interpréter dans leur contexte.

Les signaux utiles peuvent inclure

• erreurs de connectivité répétées
• échecs d'application de la cible
• tentatives
• modifications d'authentification ou d'autorisation
• changements inhabituels dans le décalage
• maintenance de la source ou de la cible
• messages de diagnostic spécifiques à la plateforme

Observez l'environnement autour du pipeline.

Un changement de comportement de réplication qui coïncide avec:

• un événement Db2
• une IPL
• maintenance des infrastructures
• un changement de réseau
• un changement de sécurité
• une mise à jour de schéma ou de configuration
• une période de charge de travail importante

Il pourrait être nécessaire d'interpréter cela différemment d'un événement de réplication isolé.

Cela ne signifie pas nécessairement que l'événement source a causé le problème CDC.

Cela signifie que les opérateurs doivent pouvoir disposer de suffisamment de contexte pour analyser la relation.

À quoi ressemble le bien

L'équipe sait:

• Ce qui nécessite une action immédiate
• Ce qui nécessite une enquête
• ce qui peut être observé
• lorsque une escalade plus large est justifiée

Drapeau rouge

L'un ou l'autre extrême:

Chaque avertissement réveille quelqu'un

or

Les avertissements sont ignorés jusqu'à l'arrêt du pipeline.

Comment paramétrer les seuils d'alerte de délai du CDC ?

Quel est le délai de réponse excessif du CDC ?

Il n'existe pas de seuil universel applicable à tous les environnements CDC mainframe.

Un seuil d'alerte utile doit tenir compte de facteurs tels que:

• volume de transactions normal
• monnaie des données attendues
• tolérance en aval pour les données obsolètes
• disponibilité de l'historique des sources
• objectifs de rétablissement
• modèles de charge de travail
• temps de réponse de l'équipe
• coupures d'activité
• conséquences de l'absence de réponse

Au lieu de copier une règle générique telle que:

«Alerte après 30 minutes de délai.»

demander:

« À quel moment cette situation commence-t-elle à menacer les exigences réelles en matière de données, d'actualisation, d'exploitation ou de récupération ? »

Voilà le seuil autour duquel il vaut mieux concevoir le projet.

Concevez des alertes basées sur les décisions, et pas seulement sur les chiffres.

Une alerte utile devrait permettre à quelqu'un de décider de la suite des événements.

Un modèle simple est:

Enquêter

Un élément s'est déplacé hors des limites prévues par l'environnement.

Exemples:

• Le décalage commence à s'accentuer.
• Ralentissement du processus
• avertissements répétés
• changements inexpliqués du débit

La tâche immédiate consiste à comprendre pourquoi.

Acte

Cette situation affecte sensiblement une exigence opérationnelle ou accroît la complexité du processus de récupération.

Les actions peuvent inclure:

• enquête sur un goulot d'étranglement cible
• examiner les conditions de la source ou de l'infrastructure
• impliquant une équipe adjacente
• examiner les informations sources dont dépend le chemin de récupération
• protéger les utilisateurs en aval contre les données obsolètes
• se préparer à une reprise contrôlée

Intensifier

Le problème a dépassé le cadre des compétences opérationnelles normales de l'équipe technique ou a commencé à affecter des décisions plus générales en matière d'activité, de risques ou de services.

Cela peut nécessiter l'implication de:

• leadership en matière de données ou de plateforme
• opérations sur mainframe
• propriétaires de systèmes en aval
• parties prenantes commerciales
• gouvernance ou risque
• gestion des incidents

Les seuils différeront.

Le processus de décision doit déjà exister avant le déclenchement de l'alerte.

Le test d'observabilité du CDC en deux minutes: Votre équipe peut-elle répondre à ces cinq questions ?

Un tableau de bord de supervision n'est pas précieux parce qu'il affiche des indicateurs. Il est précieux parce qu'il aide les opérateurs à prendre des décisions. Faites ce test: un opérateur lambda peut-il répondre aux cinq questions suivantes en moins de deux minutes sans faire appel à un spécialiste de la plateforme ?

Cela correspond aux directives opérationnelles plus générales de Google Site Reliability Engineering, qui considèrent la surveillance comme un moyen d'évaluer l'état du service, de diagnostiquer les problèmes, d'identifier les tendances et de comparer le comportement au fil du temps, et non pas simplement de collecter ou d'afficher des indicateurs.*

1. Quel est notre retard ?

L'opérateur peut-il identifier le retard ou l'arriéré actuel ?

2. La situation s'améliore-t-elle ou s'aggrave-t-elle ?

Peuvent-ils déterminer si le carnet de commandes est en augmentation, stable ou en train de se remplir ?

3. Le traitement est-il réellement en cours ?

Peuvent-ils identifier les activités récentes réussies plutôt que de se fier à un statut générique « En cours » ?

4. Si cela devient un événement de rétablissement, comprenons-nous de quoi dépend le rétablissement ?

Peuvent-ils déterminer quelles sources historiques, étatiques ou autres informations seraient pertinentes ?

5. Qui est déjà touché ?

Peuvent-ils identifier les systèmes ou équipes en aval qui pourraient utiliser des données obsolètes ?

Si l'opérateur ne peut pas répondre à ces cinq questions en deux minutes environ, demandez:

• Quelles informations manquent ?
• Qu'est-ce qui est réparti entre trop d'outils ?
• Qu’est-ce qui nécessite une interprétation spécialisée ?
• Quel contexte n'existe que dans la tête de quelqu'un ?
• Quelles procédures de surveillance ou d'exploitation doivent être modifiées ?
• Le cadrage de deux minutes est une heuristique opérationnelle pratique, et non une norme sectorielle.
• C'est le principe qui compte:

La personne intervenant sur les lieux doit être en mesure de comprendre la situation suffisamment rapidement pour pouvoir agir.

Un système de surveillance que seul un spécialiste de la plateforme peut interpréter ne suffit pas pour un pipeline opérationnel critique.

Comment suivre la reprise des données du CDC après une interruption

Comment savoir si le CDC rattrape effectivement son retard ? La surveillance ne s’arrête pas une fois le processus redémarré. Pendant la phase de rattrapage, posez-vous les questions suivantes:

• Le carnet de commandes se réduit-il ?
• À quelle vitesse rétrécit-il ?
• Y a-t-il encore de nouvelles sources d'activité ?
• Le processus de traitement suit-il le rythme des nouvelles activités tout en réduisant l'écart ?
• Des erreurs ou des tentatives de réessai se produisent-elles ?
• Quel impact le rattrapage a-t-il sur la source et la cible ?
• Les systèmes en aval fonctionnent-ils encore avec des données obsolètes ?
• Quelles preuves nous indiqueront que le rattrapage est réellement terminé ?

La distinction importante est la suivante:

courir à nouveau

contre

rattrapé

contre

récupéré et validé.

Il ne s'agit pas nécessairement du même état.

Les modèles de charge de travail des mainframes peuvent modifier ce qui ressemble à la « normalité ».

Les environnements mainframe ont souvent des périodes de fonctionnement distinctes:

• traitement en ligne de pointe
• lot de nuit
• fin de journée
• fin de mois
• clôture financière
• pics saisonniers
• maintenance programmée

Un décalage temporel normal à un moment donné peut signaler un problème à un autre.

• Il en va de même pour:
• charge de travail source
• enregistrer ou modifier le volume
• pression cible
• capacité de rattrapage disponible
• contention d'infrastructure

Évitez de définir ce qui est « sain » à partir d'une seule moyenne.

Surveillez le pipeline en fonction de la charge de travail qu'il prend en charge.

Lorsque le système de surveillance détecte un problème: que doit-il se passer en premier ?

Le suivi offre aux équipes quelque chose qui finit toujours par manquer lors des efforts de récupération: du temps.

Plus tôt un problème naissant est identifié, plus les options de réparation restent nombreuses.

Confirmez ce qui se passe réellement.

Cet état est-il transitoire ou persistant ?

À quelle étape du processus de réplication la progression ralentit-elle ou s'arrête-t-elle ?

Établir le calendrier

Depuis combien de temps cela dure-t-il ?

Quand a eu lieu la dernière activité réussie confirmée ?

Comprendre le backlog

Quel est votre retard ?

Est-ce que ça grandit ou est-ce que ça brûle ?

Identifier l'exposition en aval

Qui compte déjà sur cette cible ?

Ont-ils besoin de savoir que les données peuvent être obsolètes ?

Préserver l'état actuel

Consignez l'état pertinent, les erreurs, les horodatages, les diagnostics et autres preuves avant d'apporter des modifications importantes.

Déterminez s'il s'agit toujours d'un problème de surveillance ou s'il s'agit d'une décision de rétablissement

Si le pipeline s'arrête ou si la situation se détériore suffisamment pour que des mesures de récupération soient envisagées, il convient de mettre en œuvre un processus de récupération structuré plutôt que d'improviser.

Mon processus de validation des données CDC prend du retard. Peut-il encore rattraper son retard ?

Un décalage temporel ne signifie pas en soi que des données ont été perdues.

Et un arriéré croissant ne signifie pas automatiquement qu'une refonte complète sera nécessaire.

Mais le décalage peut devenir un problème de récupération lorsque l'équipe ne peut pas répondre avec assurance à des questions telles que:

• Quel est notre retard ?
• Le carnet de commandes se réduit-il ?
• Quel est l'état de récupération/processus existant ?
• De quel historique source la récupération dépendrait-elle ?
• Combien de temps faudra-t-il probablement pour rattraper le retard ?
• Qui utilise des données obsolètes ?
• Que se passe-t-il si le pipeline s'arrête complètement ?
• Comment prouverons-nous par la suite que la cible est digne de confiance ?

À ce stade, la question utile passe de:

« La réplication est-elle en cours ? »

à:

« Sommes-nous encore en mesure de nous remettre de la situation actuelle ? »

Comment Rocket Data Replicate & Sync prend en charge la visibilité opérationnelle

Rocket Data Replicate & Sync (RDRS) fournit des capacités de surveillance opérationnelle et de diagnostic qui peuvent aider les équipes à comprendre l'état des environnements de réplication pris en charge.

La validation technique du RDRS identifie des capacités telles que:

• informations sur l'état du processus
• informations diagnostiques
• traces  
• vérifications de latence
• État de redémarrage/processus enregistré pour les configurations prises en charge

Les indicateurs précis destinés à l'opérateur, les coordonnées de redémarrage, les alertes et le comportement de surveillance peuvent varier en fonction de la source, de la cible, de la version, de la topologie et de la configuration.

Les équipes qui évaluent RDRS devraient donc demander à Rocket de leur démontrer son expérience de surveillance en fonction de leur environnement spécifique.

Voici quelques questions utiles:

• Que peut constater l'opérateur lorsque la réplication commence à prendre du retard ?
• Quelles informations sur la latence ou l'état du processus sont disponibles ?
• Comment l'équipe peut-elle savoir si la réplication progresse ?
• Quels sont les messages d'erreur et de diagnostic disponibles ?
• Quels états de redémarrage/processus enregistrés les opérateurs peuvent-ils consulter ?
• Que peut voir l'équipe pendant la phase de rattrapage ou de récupération ?
• Comment ce dispositif de surveillance s'intègre-t-il au modèle opérationnel global de l'organisation ?
• Quels changements de comportement du système faut-il mesurer lors d'une reprise à volume élevé ?

Les allégations relatives à l'impact sur la production doivent également être évaluées à l'aide de preuves spécifiques à la source, tant dans le cadre d'une charge de travail normale que d'une charge de travail de rattrapage.

La norme utile n'est pas:

« Le système RDRS dispose-t-il d'un système de surveillance ? »

C'est:

« Notre opérateur habituel peut-il identifier la situation suffisamment rapidement pour prendre la bonne décision ? »

Liste de contrôle de préparation à la surveillance du CDC

Avant de vous fier à un pipeline CDC mainframe pour des données aval importantes, posez-vous les questions suivantes:

• Peut-on constater à quel point la réplication est en retard ?
• Peut-on déterminer si le carnet de commandes augmente, se stabilise ou diminue ?
• Peut-on déterminer si le traitement progresse réellement ?
• Comprenons-nous de quelles informations sources le chemin de récupération pris en charge peut dépendre ?
• Savons-nous quels systèmes en aval dépendent de la cible affectée ?
• Peut-on identifier les cas où ces systèmes utilisent des données obsolètes ?
• Les erreurs et les diagnostics significatifs sont-ils visibles ?
• Peut-on relier le comportement de réplication à des événements pertinents au niveau de la source, de la cible ou de l'infrastructure ?
• Les seuils d'alerte sont-ils basés sur notre environnement plutôt que sur des valeurs par défaut génériques ?
• Chaque alerte pertinente correspond-elle à une action ou à une décision d'escalade ?
• Peut-on suivre les progrès pendant la période de rattrapage ?
• L'équipe soignante habituelle peut-elle répondre rapidement aux questions de santé essentielles sans l'aide de spécialistes ?

Si plusieurs réponses sont non, vous disposez peut-être de données de surveillance.

Vous n'avez peut-être pas encore une visibilité opérationnelle suffisante.

En résumé

La plupart des problèmes de reprise d'activité du CDC ne commencent pas par une panne totale. Ils commencent par un processus qui prend du retard, un arriéré inexpliqué et un objectif qui devient de plus en plus obsolète alors que le processus semble encore fonctionner correctement.

Un bon suivi aide les équipes à répondre à:

• Quel est notre retard ?
• Le carnet de commandes augmente-t-il ou diminue-t-il ?
• La réplication progresse-t-elle réellement ?
• Qui est déjà exposé à des données obsolètes ?
• Si cela se transforme en situation de rétablissement, comprenons-nous encore nos options ?

L'objectif n'est pas de collecter davantage de données.

Il s'agit de détecter un problème naissant suffisamment tôt pour que les opérateurs puissent réagir et que la récupération reste simple.

*Google SRE: Surveillance des systèmes distribués

Prochaine étape: Avant de redémarrer

Si le pipeline s'arrête — ou si le retard a progressé au point où une action de récupération est envisagée —, passez de la surveillance à une décision de récupération structurée.

Avant de redémarrer un pipeline CDC défaillant: 7 questions à se poser

Analysez où la réplication s'est arrêtée, où elle peut reprendre, ce qui s'est passé pendant l'interruption, si un rattrapage ou une resynchronisation plus large est nécessaire, et comment vous prouverez par la suite que la cible est fiable.