Saturation du volume de base de données contenant le journal des transactions de P01GX. Saturation liée a une operation de copie d’environnement sur P01GX.

Arrêt de l’Oracle et indisponibilitée de l’application Galaxie pour les clients hébergé sur cette instance.

Moyenne 2eme cas de saturation sur cette instance en 2 ans (le 1er cas n’a pas généré d’indispo car traité juste avant saturation totale)

Supervision Zabbix

Causes immédiates : Saturation des AL Opération de copie Cellule de crise partiellement déclenchée.

• Purge manuelle de volume Fermé/RCA/Récurrent/Prevention/Exécuté/Récurrence Possible 1 →Poor, 2→ Partiel, 3→ Nominal

Ce qui s'est bien passé : Prise en charge rapide (6 minutes) Le lancement de la cellule de crise. Vidage des AL inopérant en premier lieu. Bof pas trop.

Entre le 21 et le 23 janvier 2026, plusieurs TOMCAT OMSAAS ont subi une surcharge CPU, entraînant de fortes lenteurs pour les utilisateurs connectés. L’origine provient de l’exécution du rapprochement bancaire intelligent (N‑N) déclenché par un utilisateur, cette exécution est restée en traitement suffisamment longtemps (plus de 24 h) pour saturer le CPU du TOMCAT, provoquant ensuite un impact sur les utilisateurs connectés (ralentissement important).

Tous les clients du SAAS1 connectés au serveurs Tomcat impactés (Maximum une vingtaine de clients/tomcat) subissent des ralentissements (Ex: 30 seconde pour l’affichage de l’écran de facturation) sur l’application ONE manager (Navigation globale ralentie sur ONE). Perte de productivité. Traitement utilisateur sur le rappro non abouti. Mobilisation forte OPS/Support/dev.

Quelle est la récurrence du problème? Lien vers les Post Mortems similaires

Signals : webtests internes.

Causes immédiates : Threads du process RapproBancProcessor bloqués (boucle prolongée dans getListeCombinaisonsSumRn), maintenant le CPU à plus de 93% sur le Tomcat. Ne pas ne pas avoir limiter en amont le nombre de mouvements bancaires et de retours NOEMI à rapprocher, afin de prévenir tout risque de calculs interminables. Impossibilité de retirer des Tomcat du pool sans déconnecter les utilisateurs. Temps de réaction allongé pour identifier et résoudre la saturation des instances Tomcat. Relances utilisateur inte

Retirer les Tomcat du répartiteur et rebooter si CPU reste bloqué a plus de 90%, avec communication sur l’impact (déconnexion possible). → (OPS/Infra) Action coté paramétrage client : Communication et basculer le rapprochement bancaire en mode non intelligent pour les clients concernés le temps du correctif. (Définir le paramètre simple CDCT_RAPPRO_BANC_MULTIPLE à 0) Fermé/RCA/Récurrent/Prevention/Exécuté/Récurrence Possible 1 →Poor, 2→ Partiel, 3→ Nominal Vendredis 23 janvier Nombre d’appel au

Ce qui s'est bien passé : Charge absorbée pas d’autres Tomcats / Alerting. Bonne communication entre équipes Support / OPS / Développement. Client coopérative et bascule rapide du rapprochement bancaire en mode non intelligent. La cause mise en évidence par les mécanismes en place (alertes 15min ⇒ envoi de stack trace dans graylog : rappro bancaire A CHAQUE FOIS) a d’abord été mise en doute, avant de se mettre à travailler

Suite au remplacement du convertisseur JOD par le Report Converter OnlyOffice, une augmentation des lenteurs en production a été observée la semaine du 12 janvier 2026. Voir sur Graylog Voir sur Graylog Voir le Graylog (clic droit sur une ligne GET /reports/visualizer/api/q/health/ready HTTP/1.1 puis clic sur duration_sec puis chart) Face à ces lenteurs, un rollback complet vers JOD a été effectué sur l’ensemble des SaaS. Un plan d’action progressif a été défini afin de sécuriser une future migr

Clients impactés Produits impactés / features impactées La conversion et la génération de rapports via le Report Converter. Une augmentation des lenteurs se traduisant par des timeouts HTTP 504. Références de performance en situation normale Sur 7 jours : Sur 1 jour : Impact en cash non mesuré

Le problème n’a pas été observé avant la bascule du convertisseur JOD vers le Report Converter OnlyOffice. Il s’est manifesté uniquement après cette bascule sur certains SaaS et a disparu après le rollback vers JOD. À ce stade, l’incident est considéré comme non récurrent en production, mais une récurrence est possible tant que la migration vers le Report Converter n’est pas finalisée et sécurisée.

L’incident a été détecté via la surveillance des métriques de performance dans Grafana, avec une augmentation des timeouts HTTP 504 sur l’API de conversion des documents. Des retours clients signalant des temps de génération de rapports plus longs ont également contribué à identifier le problème. Détecter le % de lenteur REQUÊTE : http_request:/reports/converter/api/v1/documents/converter/ AND http_status:504 GRAYLOG : ICI Ici, on voit clairement un pic uniquement la semaine du 12 janvier 2026.

Causes immédiates : Le passage de JOD au Report Converter OnlyOffice a augmenté le temps de traitement des conversions, entraînant des timeouts HTTP 504 sur l’API /reports/converter/api/v1/documents/converter/. Nous suspectons principalement un problème de capacité/performance lié à l’infrastructure OnlyOffice/Report Converter : calibrage CPU/mémoire des pods insuffisant (sous-dimensionnement sur certains composants) nombre de pods insuffisant par rapport à la charge (besoin de scale-up progressif) Lien Grafana Que

Résolution immédiate L’incident a été traité rapidement par un rollback complet vers le convertisseur JOD sur l’ensemble des SaaS concernés. Ce rollback a supprimé l’utilisation du Report Converter OnlyOffice et a permis un retour immédiat à des performances nominales, avec disparition des lenteurs et des timeouts HTTP 504. Résolution durable (en cours) Une seconde phase de résolution est en cours afin de sécuriser la migration vers le Report Converter. Elle consiste à : recalibrer les ressource

Ce qui s'est bien passé : La décision de rollback a été prise rapidement après identification du problème. Le rollback vers JOD a été réalisé en moins d’une heure et a permis un retour rapide à des performances nominales. Les équipes ont su se mobiliser rapidement pour rétablir le service. Les lenteurs n’ont pas été détectées de manière proactive via le monitoring, mais principalement suite aux retours clients. Le groupe T