La désactivation de règles de pare feu (demandée par Epiconcept 3578637) a entrainé un effet de bord

Les infras Epiconcept ne joignent plus le DNS 10.49.180.65 ⇒ appli ko

Aucune

Remontées client ⇒ Fabrice ⇒ ticket 3578637 + teams

Causes immédiates : La règle demandé à désactiver incluait des flux nécessaires au fonctionnement des services d’Epiconcept. Il n’y a pas eu de vérification d’utilisation de cette règle avant de la désactiver. Les règles de flux appliquées sur les pare-feu ne correspondent pas exactement à la matrice de flux. Certaines règles de flux ont été modifiés sans que la matrice de flux n’est été mis à jour. Y a t’il eu des faits aggravants

Réactivation de la règle de flux.

Ce qui s'est bien passé : Détection par l’utilisateur

Dysfonctionnement aléatoire d’un port d’un switch du stockage stdn.

Perturbations aléatoires des machines de base de données connectées au port de ce switch : On voit sur la courbe ci-dessous les périodes de perturbations : ⇒ sûrement des lenteurs sur les applications concernées Déconnexions Galaxie ?

Très faible. Enfin, peut-être… On n’a peut-être pas pu identifier les fois précédentes. Un dysfonctionnement physique est déjà arrivé en 2025 mais coté carte du serveur oracle, pas switch.

Alertes de supervision sur des montées de sessions oracle et ralentissement sur les webtests hm

Causes immédiates : Perte du lien ISL sur le port 5 entre les switches stdn-b48f-01 et stdn-b48f-05 (fabric prod_fabric1). Le port a été désactivé en CLI pour stabiliser le fabric. Défaillance unilatérale du laser TX du SFP (PN 57-1000485-01) sur le port 5 de stdn-b48f-01 (S/N BRCFME1903U07D, ~5 ans de fonctionnement). La puissance TX tombe à 0 uW (-99,99 dBm), tandis que la RX reste correcte à -8,9 dBm. Le switch distant stdn-b48f-05 remontait 35,8k erreurs FEC et plusieurs pertes de signal avant désactivation du

Désactivation du port 5 du switch.

Ce qui s'est bien passé : Manque d’expertise et de maîtrise technique. Le support des switch brocade n’est pas clair (qui fait, comment les joindre, etc.) Seul Benoit pouvait ouvrir un ticket ibm. Les comptes des admins (JBeau) ne le permettent pas. Seul l’ ”admin” a accès aux données dans xormon (récent outil de supervision hardware). Gestion de la cellule de communication de crise : Résumé (Post Mortem) — “SAN stdn - dys

Suite à des changements en production le 21/04 en soirée (mise en place d’un cron, nouveau volume de stockage et montage sur les pods OnlyOffice), des dysfonctionnements sont apparus le 22/04 au matin. Les utilisateurs ont rencontré des documents vides après validation ainsi que des problèmes de chargement aléatoires. L’incident a duré toute la matinée avec une résolution progressive en début d’après-midi après plusieurs actions techniques, dont notamment le passage de RabbitMq et Redis de 2 pod

Des clients ont été impactés de manière intermittente.

Pas de récurrence, première fois

Incident remonté par les utilisateurs (clients finaux et praticiens).

Causes immédiates : Dysfonctionnement dans la gestion des composants RabbitMQ et Redis en configuration multi-pods entraînant des comportements instables et des erreurs de traitement côté OnlyOffice (converter/docservice). Quelles sont les causes racines qui ont amené à la cause immédiate? Absence de monitoring fonctionnel permettant de détecter rapidement les anomalies utilisateurs. Un "service account Grafana" avec le rôle "Viewer" (lecture seule) / token associé pour grafana Un token pour Graylog Demande faite l

Réduction du nombre de pods de RabbitMQ, Redis et StatsD de 2 à 1.

Ce qui s'est bien passé : Possibilité de basculer vers le Word à la place de OnlyOffice, cette action aurait du être réalisée dès le matin et pas à 12h

Redémarrage du cluster Elastic search ‘alicante’ le 07/04 en fin d’après-midi A cause d’un problème de configuration ce redémarrage du cluster a entrainé la prise en compte d’un mauvais paramétrage qui a empêché l’accès aux données des clients, le cluster étant lui vu comme opérationnel. En l’absence de logs applicatifs utilisables plusieurs hypothèses ont été testées retardant le retour à la normale

Dimbox indisponible du mardi 7/04 19h35 au mercredi 08/04 19h07.

Aucune

Par les équipes fonctionnelles.

Causes immédiates : A la suite du redémarrage induit par le changement de certificat, les indexs clients ne sont pas accessibles. Installation non-conforme du cluster elasticsearch : 2 fichiers de configuration elasticsearch présents avec un paramétrage différent, le fichier de configuration utilisé par le service au niveau système contient le paramétrage standard softway pour les clusters Elastic qui dans ce cas particulier n’est pas celui à utiliser(ne pointe pas vers le bon répertoire ‘DATA’) Présence d’indexs d

Modification de la configuration puppet au niveau du service elastic pour pointer vers le répertoire DATA contenant les bons indexs Réactivation puppet OK redémarrage testé OK

Ce qui s'est bien passé : Disponibilité de la squad (C.Arizzi et F.Petit) et du prestataire (Julien T.) détection de l’incident : pas par la supervision Déclaration de l’incident : à un admin unique, plutôt qu’au support Déclenchement de la cellule de crise : tous les clients sont impactés, ça dure… et on tarde à déclencher. Changement de port qui ralenti le rétablissement, et fausse l’analyse pendant 1h Disponibilité du p

Depuis la mise a jour du socle Technique Tomcat6 vers Tomcat9

Les clients RAMSAY ayant migres ont des dysfonctionnement.

Le probleme s’est etendu a tous les sites RAMSAY migrés petit a petit.

Appel client au support.

Causes immédiates : Migration d’une nouvelle infra T9 Problèmes de configuration Tomcat Absence de site pilote Etablissement Couverture de tests ? Migration Oracle concomitante (à vérifier) a peut être brouillé les pistes Meconnaissance des changements operes par le client. (VLAN, EDR, Migration Oracle de temps en temps…..)

Comment l’incident a été résolu

Ce qui s'est bien passé : Mobilisation des equipes infra/Mindcraft/Support Méconnaissance de l’infra Site On Prem et non tele-exploite. Latence pour comprendre ou était les problème. Suite à la migration progressive des environnements RAMSAY de Tomcat 6 vers Tomcat 9, des dysfonctionnements applicatifs ont été constatés sur les sites migrés. Les impacts observés concernent notamment : l’accès/récupération de traitements an

Certificats citrix KO suite mise à jour des netscaler (RFC-2026-001034)

Nombre de clients impactés, produits impactés, features impactées, impact en cash

Ponctuelle

Appel client vers CP / DP / resp BU Certificats non pris en charge Le ticket au support Citrix semble indiquer que les caractères spéciaux de nos certificats présentent des incompatibilités avec la nouvelle version du netscaler. https://support.citrix.com/external/article/CTX461396/certificate-binding-lost-after-upgrade.html Fait suite à une RFC dans laquelle des tests sont précisés Le process HNO n’est pas existant / pas connu / mal appliqué par le client Problème non détecté par la supervision

Remise en place des certificats

Ce qui s'est bien passé : Tests après RFC Contacts du client vers le support en HNO détection du problème par la supervision Suite à une mise à jour de sécurité effectuée le 31/03 à 21h sur le netscaler citrix, un dysfonctionnement imprévu a impacté le certificat https, rendant l’accès indisponible.