Incidents — One Manager

📣 Communication interneIncident de ralentissement détecté sur le datacenter STDN (HM/OM) le jour J entre 12h04 et 12h15, soit une durée de perturbation d'environ 11 minutes. La cause racine identifiée est un pic de consommation réseau massif généré par les mises à jour Windows via WSUS : 270 Go transférés en l'espace de 15 minutes, saturant la bande passante malgré le bridage configuré. L'ensemble des clients hébergés sur STDN ont subi une dégradation des performances applicatives (ralentissements) pendant cette fenêtre. La résolution est intervenue spontanément à 12h15 sans action corrective immédiate requise. Des investigations approfondies sur les stratégies WSUS sont à engager pour revoir les politiques de déploiement des mises à jour Windows et éviter toute récurrence (plages horaires, limitation de débit, étalement des déploiements).

📣 Communication interneIncident de ralentissement détecté sur le datacenter STDN (HM/OM) le jour J entre 12h04 et 12h15, soit une durée de perturbation d'environ 11 minutes. La cause racine identifiée est un pic de consommation réseau massif généré par les mises à jour Windows via WSUS : 270 Go transférés en l'espace de 15 minutes, saturant la bande passante malgré le bridage configuré. L'ensemble des clients hébergés sur STDN ont subi une dégradation des performances applicatives (ralentissements) pendant cette fenêtre. La résolution est intervenue spontanément à 12h15 sans action corrective immédiate requise. Des investigations approfondies sur les stratégies WSUS sont à engager pour revoir les politiques de déploiement des mises à jour Windows et éviter toute récurrence (plages horaires, limitation de débit, étalement des déploiements).

📣 Communication interneLe 04/05/2026, une coupure d'alimentation sur un PDU (Power Distribution Unit) du datacenter STDN a entraîné un impact multi-composants sur notre infrastructure. Les détails techniques précis (root cause confirmée, périmètre exact des services affectés, durée d'indisponibilité) ne sont pas encore renseignés dans le ticket — il est impératif de compléter ces informations dès que possible pour permettre un retour d'expérience complet. L'incident a impliqué une indisponibilité potentielle de plusieurs services hébergés sur ce datacenter, avec un impact probable sur les clients raccordés aux composants alimentés par ce PDU. Des investigations sont à mener ou ont été menées pour identifier l'étendue exacte de la panne, les composants concernés (serveurs, équipements réseau, instances applicatives) et les actions de remédiation appliquées. Des actions correctives et préventives (redondance d'alimentation, surveillance PDU via Zabbix, procédure de bascule) doivent être documentées et engagées suite à cet incident.

📣 Communication interneIncident déclenché suite à la perte d'un chemin réseau sur le SAN STDN, provoquant une montée anormale des sessions Oracle et une indisponibilité des environnements hébergés pour les clients P07HM, P11HM, P13HM, P01AM, P05OM, P15HM, P01GX, P21HM ainsi que les clients HM (Cognacq Jay, Dunkerque, FILIERIS), OM (SAAS2/3/4/7) et XTS (Ramsay). La root cause identifiée est un port d'attachement du stockage défaillant côté SAN STDN — la piste SAN IBM a été initialement suspectée puis écartée après investigation. La résolution a consisté en l'identification et l'arrêt du port d'attachement défaillant à 11h45, avec confirmation de fin d'incident à 12h05 après 20 minutes de surveillance. Les clients ont donc subi une indisponibilité ou dégradation de service le temps de l'investigation et de la résolution. En corrective, l'équipe stockage a planifié des opérations de remplacement des ports d'attachement défaillants pour prévenir toute récurrence.

📣 Communication interneIncident OnlyOffice confirmé sur les environnements HM et OM (portail radiologue V2) : les utilisateurs rencontraient des erreurs aléatoires au chargement et à la création de comptes-rendus. La root cause identifiée est une mauvaise configuration du cluster RabbitMQ suite à l'intervention de maintenance du 21/04 (déploiement d'un nouveau volume OnlyOffice + CronJob) : les 2 pods RabbitMQ ne se connaissaient pas entre eux, provoquant des incohérences de traitement des messages et des erreurs aléatoires côté client. La résolution a consisté à réduire RabbitMQ, Redis et StatsD à 1 seul pod chacun, à nettoyer les tables doc_changes et task_result, puis à effectuer un redémarrage complet et ordonné de tous les pods OnlyOffice. L'incident a démarré suite à la maintenance du 21/04 et a été résolu le 23/04 matin (confirmation définitive), soit un impact s'étalant sur environ 2 jours pour les clients CSE, IMEV, CIMRAD, radiologies SAAS1/2/3/7, groupe AIM Nantes et GOVI. Action corrective immédiate : passage à 1 replica pour les composants concernés ; une revue du process de validation post-intervention de maintenance doit être engagée pour éviter ce type de régression silencieuse sur les configurations de cluster.

📣 Communication interneLe cluster Elasticsearch de l'infrastructure Alicante a été indisponible suite à l'expiration des certificats TLS swmcloud.net, provoquant des StreamCorruptedException lors des handshakes TLS sur le port 9300 (communication inter-nodes). L'ensemble des clients hébergés sur l'infrastructure Alicante ont été impactés par cette indisponibilité. KLECH Salim est intervenu pour réparer le cluster ES en passant Puppet en mode noop sur les 3 nodes Elasticsearch afin d'éviter toute réapplication de la configuration défectueuse, permettant le rétablissement du service à 17h01. Actions correctives et préventives à engager : mettre en place une supervision proactive de l'expiration des certificats TLS (alertes Zabbix ou équivalent) et revoir le processus de renouvellement automatique des certificats swmcloud.net pour éviter toute récidive.

📣 Communication interneUn dysfonctionnement réseau majeur a impacté l'ensemble des clients SaaS accessibles via Internet, entraînant une indisponibilité des accès ainsi que la perte de supervision (Zabbix, Graylog, Grafana). La root cause identifiée est une règle NAT trop large configurée pour Epiconcept sur le Palo Alto CRBV, générant une collision d'adresse IP (duplicate IP 91.208.222.253) entre l'ASR et le Palo Alto CRBV, ce qui a provoqué la chute des sessions BGP. La résolution a été effectuée en deux temps : désactivation de la règle NAT fautive sur le Palo Alto CRBV à 15h56, suivie d'un flush ARP et des sessions BGP à 16h27, soit un temps de rétablissement complet estimé à environ 31 minutes entre les deux actions. Des actions correctives doivent être engagées pour auditer l'ensemble des règles NAT existantes afin d'identifier et corriger toute règle trop permissive susceptible de générer des conflits d'adressage similaires. Une revue des procédures de validation des règles NAT avant mise en production est également à planifier pour éviter toute récurrence.

📣 Communication interneIncident de connexion total sur l'environnement CRBV : les clients ne pouvaient plus accéder à l'application en raison d'une mauvaise résolution DNS. La root cause est un job Rundeck de décommissionnement qui a supprimé le reverse proxy rproxy7 ainsi que l'entrée DNS associée à l'IP 193.23.123.89, utilisée par le tenant AVI production-crbv.xtremcloud.cloud. La résolution a consisté à recréer manuellement l'entrée DNS de type A pointant vers 193.23.123.89, puis à corriger l'enregistrement CNAME pour qu'il pointe vers cette nouvelle entrée. L'impact a concerné 44 clients CRBV ainsi que les tenants OMSAAS, OMSAAS3, OMPILOTE, Imagerie de Provence, CSE Beaurepaire et les MS locaux, qui ont subi une indisponibilité complète de l'accès à l'application. Action corrective immédiate : le job Rundeck de décommissionnement doit être audité et sécurisé pour éviter toute suppression non contrôlée d'entrées DNS ou de composants d'infrastructure en production.

📣 Communication interneUn incident de stockage a affecté 44 clients CRBV ainsi que les environnements OMSAAS, OMSAAS3 et OMPILOTE, provoquant une indisponibilité des services liés au stockage IBM. La cause racine identifiée est une combinaison entre la réplication de volume vers la salle distante et une instabilité sur le port d'attachement du stockage IBM, entraînant une dégradation ou une indisponibilité des accès aux données pour les clients impactés. La résolution a consisté à arrêter la réplication de volume en cours, ce qui a permis de rétablir le service à 17h05. Des actions correctives et préventives doivent être engagées sur la configuration de la réplication et la supervision de la stabilité des ports d'attachement IBM afin d'éviter toute récurrence.

📣 Communication interneSuite à une augmentation du nombre de pods OnlyOffice déployée le 25/02, les sessions actives des utilisateurs ont été déconnectées, entraînant une non-synchronisation des comptes-rendus et leur disparition apparente dans le portail. L'incident a impacté plusieurs clients SAAS (C2532, CIMRAD, SAAS7, Polyclinique de Moulin, CIMROD, CSE Beaurepaire SAAS1, Dr Morillon SAAS3, Dr TERNAMIAN, Dr GALLET), avec des CRs inaccessibles ou vides côté utilisateur. La résolution a été assurée par BARON Charles-Edouard via un retour arrière sur la configuration des pods OnlyOffice, avec stabilisation confirmée à 14h45. Des actions correctives sont à engager pour encadrer les montées en charge de pods OnlyOffice afin d'éviter toute déconnexion de session en cours de production.