Serveur IIS dédié à Ramsay non accessible

Plus d’accès à l’application pour tous les centres Ramsay utilisant la solution Galaxie

Pas de récurrence

Le support fonctionnel identifie qu’il n’est plus possible de se connecter chez le client

Causes immédiates : Ouverture d’un fichier de log (2,5Go) avec un bloc note, L’application voulant écrire dans le fichier de log, elle n’a pas pu donc l’application a planté.

Redémarrage du service ws_galaxie_C000333 Liste des actions post mortem : Demande de création de fichier de log moins volumineux Quand un fichier de log est ouvert, faire en sorte que l’application puisse continuer à fonctionner Vérifier pourquoi la supervision n’a pas reçu l’alerte

Ce qui s'est bien passé : Ouverture d’un fichier de log (c’est une manipulation quotidienne pour Galaxie) volumineux environ 2,5Go Ouverture d’un fichier de log avec un bloc note et non un notepad directement sur le serveur Serveur IIS dédié à Ramsay donc seul ce client a été impacté 📄 Indisponibilité du serveur IIS dédié à Ramsay — Application Galaxie inaccessible

Ralentissement entre 12h03 et 12h10, soit après la “vague habituelle” de ralentissement de midi (12h00~12h02)

Ralentissement x10 ~ x15 pendant 7min, voir impossibilité de se connecter, sur les applis One HM HMbloc Tamm hébergées à STDN

Ca arrive régulièrement.

Alertes de supervision sur la disponibilité et la perf de l’appli (donc seulement pour les applis qui en bénéficient, pas galaxie, pas sage, etc.).

Causes immédiates : Beaucoup d’utilisation réseau, notamment 6Gbps pendant les 10 min de ralentissement sur stdn-wsus (serveur de gestion des maj windows). Quelles sont les causes racines qui ont amener à la cause immédiate? Après l’incident du 26/03, les analyses menées ont conduit à limiter la bande passante de wsus à 1Gbps.

La bande passante a fini par diminuer sans action après 10min. Les perfs sont redevenues normales.

Ce qui s'est bien passé : Mobilisation des équipes. On ne sait pas pour quelle raison ça ralentit. C’est revenu en conditions nominales sans intervention et assez rapidement.

En production de MC et ME (samedi 23 mai) puis en test également à partir du lendemain, les professionnels ne peuvent plus accéder à la synthèse générale des patients, pour aucun patient, quelque soit le mode d’accès aux dossiers (LT, Portail Vision ou Recherche Patient/Séjour). À noter que l’ouverture du portail médical, de la note clinique, de l’écran des documents médicaux et des synthèses patient et séjour ne pos(ai)ent pas de soucis. Voici le message qui s'affiche (ex. pour ME) : (Sur MC, i

Tous les clients utilisant l’adviseur thérapeutique Vigilance ont été impactés ainsi que nos environnements internes et de développement Canadiens. Cela concerne donc les cml : C9915004 - Montérégie Centre - Client C9915005 - Montérégie Est - Client C9915006 - Université de Moncton - Cient R1600, R1601, R1602, R1603 - Bases de qualification et de formation - Internes R2004, R2007, R2008, R2009 - Bases de démo Clientèle Base de dév - Interne L’étendue du problème a pu être circonscrite à l’advise

Pas de récurrence. 1ère occurrence le 23 mai 2026.

Appel Client constatant les exceptions. Diagnostic détaillé par analyse fonctionnelle dans HM et des logs dans Graylog par Softway Medical Canada. Recensement des environnements impactés par SWM Canada.

Causes immédiates : Le certificat vigilance a expiré le 23 mai 2026 à 00h01, bloquant tous les appels émanant d’HM. Ce faisant, le blocage de l’appel au certificat a causé le blocage des écrans métier HM et des fonctionnalités corrélées à Vigilance. Selon le courriel transmis par le support Vigilance, le renouvellement du certificat aurait dû être automatique. Celui-ci ne s’est pas effectué comme attendu. Hypothèse à approfondir, cela aurait été causé par des versions de composants logiciels trop anciennes pour le

1ère partie : Rétablissement partiel des fonctionnalités pour le client 3ème partie : Réponse aux causes racines

Corruption de blocs latente sur la base P05OM suite à l’incident électrique du 4 mai. Elle pourrait être liée également à un problème de zoning au niveau du SAN. Corruption d’abord détectée pour 3 blocs d’indexs, corrigée dans la foulée, mais qui était beaucoup plus étendue. L’instance a détecté à 12h12 qu’une entête de fichier était invalide et s’est arrêtée. Une bascule a eu lieu sur l’infrastructure de secours, celle-ci s’est bien passé mais la machine de secours n’était pas paramétrée pour a

accès ko de 12h12 à 12h52 ⇒ 40min

Aucune, pas souvenir de corruption de bloc en prod

Alerte de supervision “Impossible de se connecter à l’application”.

Causes immédiates : Instance plantée et ne redémarre pas. Bloc corrompus sur la base à la suite de l’incident électrique du 04/05. Tant que cela concerne des blocs de données ou d’indexs la base continue à fonctionner (les requêtes qui touchent à ces blocs tombent en erreur par contre) Si le bloc concerné est un bloc d’entête de fichier la base s’arrête et une correction manuelle est nécessaire La cause racine de ces corruptions semble être la combinaison de : l’incident électrique du 4 mai qui a entrainé l’arrêt

Bascule sur la base oracle de secours, puis reconfiguration du paramétrage Oracle et de la configuration HugePages (qui a nécessité un redémarrage)

Ce qui s'est bien passé : Décision de basculer rapide et efficace Le serveur secondaire n’était pas prêt à accueillir de l’activité de prod : SGA trop faible (40Go au lieu de 160) (bloquant) HugePages pas activées ⇒ saturation mémoire ⇒ 1h18 d’interruption après les 40 premières minutes (bloquant) C’est arrivé entre midi et 2 Résumé du post‑mortem “Instance p05om ko” Le 11 mai à 12h12, l’instance détecte une entête de fich

Forts ralentissements (d’accès au stockage à priori ?) sur stdn. En raison d’une maintenance électrique du DC ?

12h15 - 12h35 Ralentissements sur toutes les applis lorsque VM share ou apache tamm ko : lorsque VM apache ou plusieurs tomcats ko :

Ca arrivait une fois l’an, souvent lors d’une maintenance du datacenter. Puis ça n’arrivait plus depuis plusieurs années.

Supervision (ralentissement appli et oracle)

Causes immédiates : Lors de la non-alimentation du pdu10 nous avons perdu des éléments de l'armoire R54B3 : donc perte : un nœud svc un switch fc (euw1fr01-swfc06) 5 esxi un optics un serial console switch un leaf (nx-leaf3-stdn) Accès au stockage ralenti (problème switch xxx ?) ⇒ ralentissement et corruption mysql sur p01 et p05tm 5 esxi stoppés ⇒ de nombreuses VM n’ont pas pu migrer correctement master Palo redémarre Suite à l'intervention de Digital Realty sur le PDU B2.01 (FR.PAR5 — R104, CS4177325), la remise

relance des VM indisponibles réparations des corruptions mysql Case ouvert auprès de Digital Realty le lendemain à 14h19 (CS4499545). Disjoncteur réarmé et redondance restaurée à 15h15.

Ce qui s'est bien passé : Le lendemain, lors d’une autre maintenance programmée, nous avons arrêté 2 serveur de la baie concernée. Pas d’impact sauf un accès autonome client (2375). Les MySQL de Tamm étant sous MyISAM et n’étant pas résistant au crash, les écritures ont été corrompues au moment de l’arrêt des esxi, entrainant un arrêt de production pour presque tous les utilisateurs des plateformes Tamm. Le lendemain, suit