Incidents — Infrastructure (All Applis)

📣 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 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.