Historique des pannes de Flexera

1. 27 octobre 2026 à 17:00 UTCidentified

   Description de l'incident: Nous enquêtons sur les retards affectant les mises à jour du contenu de Technopedia. Le contenu Technopedia utilisé par les services Data Platform, IT Visibility et API n'a pas été actualisé depuis le 22 octobre en raison de défaillances répétées du traitement des données. Les clients peuvent donc voir des contenus Technopedia dépassés dans les services concernés. Priorité : P2 Activité de restauration : Nos équipes techniques ont effectué des actions de récupération pour remédier aux défaillances du traitement des données et ont actualisé le contenu sous-jacent. La génération de catalogues est en cours, et nous suivons cette activité jusqu'à sa fin. Nous fournirons une nouvelle mise à jour à mesure que le rétablissement progressera.

2. 28 octobre 2026 à 01:44 UTCidentified

   La mise à jour du contenu Technopedia reste en cours. Nos équipes techniques continuent de surveiller le rafraîchissement jusqu'à sa fin. Une fois le traitement terminé, nous validerons que le contenu Technopedia mis à jour est disponible dans l'ensemble des services concernés afin de s'assurer que les opérations normales de mise à jour du contenu ont été rétablies.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 octobre 2026 à 07:05 UTCinvestigating

   Description de l'incident: Nous enquêtons sur un problème affectant la fonctionnalité de base de l'Atlas des neiges SAM dans la région du Sud du Royaume-Uni. Certains clients peuvent éprouver des problèmes d'accès à la fonctionnalité des utilisateurs et peuvent rencontrer des erreurs lors de l'accès aux détails informatiques. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question et évaluent l'étendue de l'impact. Nous travaillons à identifier la cause sous-jacente et à restaurer la fonctionnalité affectée. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 22 octobre 2026 à 07:21 UTCmonitoring

   Nos équipes techniques ont relevé des erreurs de délai affectant les composantes de service soutenant la fonctionnalité impactée et ont effectué des redémarrages de service ciblés. Suite à ces actions de récupération, la fonctionnalité Users and Computer Details répond avec succès lors de la validation. Nous continuons à surveiller le comportement de service et effectuer la validation finale pour confirmer la stabilité soutenue.

3. 22 octobre 2026 à 07:38 UTCresolved

   Suite aux actions de récupération précédemment mises en œuvre, nos équipes techniques ont complété la validation et le suivi supplémentaires. Utilisateurs et détails informatiques La fonctionnalité est demeurée stable, sans autre problème. L'opération normale a été confirmée, et cet incident est maintenant considéré comme résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 octobre 2026 à 22:37 UTCresolved

   Description de l'incident: Suite à la sortie de production de Flexera One IT Asset Management 2026R1.4 prévue dans la région de l'Australie, nous avons connu un problème affectant les services de Flexera One IT Asset Management dans APAC. Par conséquent, les clients n'ont pas pu accéder à Flexera One IT Asset Management pendant la période d'impact. Priorité: P1 Début de l'impact: 15 octobre 2026 à 11h34 PDT Fin de l'impact: 15 octobre 2026 à 12:32 PDT Activité de restauration : Nos équipes techniques ont identifié un problème touchant les composantes de service après la sortie de production prévue. Des mesures correctives ont été appliquées aux composantes touchées pour rétablir la disponibilité du service. Après la récupération, les services de gestion d'actifs de la technologie de l'information Flexera One dans APAC sont retournés à l'exploitation normale, et la question est maintenant considérée comme résolue.

2. 21 octobre 2026 à 23:40 UTCpostmortem

   **Description :** Flexera One - Gestion des biens informatiques - APAC - Indisponibilité du service après 2026R1.4 Libération **Calendrier:** 15 octobre 2026, 11 h 34 PDT - 15 octobre 2026, 12 h 32 PDT ## Résumé de l'incident Le 15 octobre 2026, les clients utilisant Flexera One IT Asset Management dans la région APAC ont connu une interruption de service qui a empêché l'accès à l'application. La perturbation s'est produite après l'achèvement de la production d'ITAM 2026R1.4. Bien que les services soient initialement disponibles et fonctionnent normalement après la libération, la demande est devenue inaccessible par la suite. Les équipes techniques ont enquêté sur la perturbation et ont relevé des défaillances affectant l'initialisation des cas d'application. Une enquête plus approfondie a révélé que l'environnement de production continuait de dépendre d'un processus d'initialisation des demandes antérieur alors qu'une transition vers un processus mis à jour était en cours. Bien que les instances d'application aient été initialisées avec succès pendant la libération, les instances de remplacement n'ont pas pu terminer le même processus en raison d'une configuration désuète. Les cas de remplacement touchés n'ont pas été en mesure de terminer l'initialisation avec succès ou de réussir les contrôles de santé requis, ce qui a empêché la demande de revenir à l'exploitation normale. Les équipes techniques ont corrigé la configuration de production pour référencer le processus d'initialisation mis à jour et ont effectué une mise à jour d'instance. À la suite de ces changements, les cas touchés ont été initialisés avec succès, et la disponibilité du service ITAM a été rétablie vers 12h32. La cause profonde L'incident a été causé par la dépendance de la production à l'égard d'un processus d'initialisation de la demande antérieur au cours de la transition vers un processus mis à jour dans l'environnement de production de l'APAC. Alors que les environnements d'essai de mise en place et d'acceptation des utilisateurs étaient déjà passés au processus mis à jour, l'environnement de production d'APAC a conservé une configuration qui faisait référence au processus d'initialisation précédent. Au cours de la sortie de production 2026R1.4, les instances d'application ont été initialisées manuellement en utilisant le procédé mis à jour, permettant à ITAM de fonctionner normalement au départ malgré la dépendance de production restante. Les éléments appuyant le processus précédent ont ensuite été réduits, étant entendu que la transition plus vaste avait été achevée dans une large mesure. Lorsque des instances d'application de remplacement ont été lancées, la configuration de production a continué de les diriger vers le processus d'initialisation précédent. Les cas touchés n'ont donc pas été en mesure d'effectuer l'initialisation avec succès ou de réussir les examens de santé requis, ce qui a entraîné une interruption du service. Le fait que la production reste dépendante du processus d'initialisation antérieur a été confirmé comme étant la cause sous-jacente de l'incident. Correction de la configuration de production pour utiliser le processus d'initialisation mis à jour a supprimé cette dépendance et a permis aux instances de remplacement d'initialiser avec succès. Mesures correctives Les mesures suivantes ont été prises pendant l'intervention : 1. **Incident Enquête ouverte :** Les équipes techniques ont étudié l'indisponibilité de l'application et ont relevé des défaillances affectant l'initialisation et les contrôles de santé des cas d'application dans l'environnement de production de l'APAC. 2. **Question de configuration identifiée :** L'enquête a permis de déterminer que la configuration de production continuait de renvoyer au processus d'initialisation de la demande antérieure plutôt qu'au processus mis à jour. 3. ** Configuration de la production corrigée :** La configuration de production a été mise à jour pour référencer le processus d'initialisation de l'application correcte, éliminant la dépendance par rapport au processus précédent. 4. **Instances de demande rafraîchies** Les équipes techniques ont effectué une mise à jour de l'instance après la correction de configuration, permettant ainsi aux instances de remplacement d'initialiser avec succès. 5. ** Récupération de service validée :** Les équipes techniques ont confirmé que les cas visés étaient en train d'initialiser avec succès, que les contrôles de santé des applications étaient en cours et que les services de l'ITAM étaient de nouveau opérationnels. Mesures préventives futures À la suite de l'incident, une rétrospective a été effectuée pour examiner le processus d'initialisation de la demande, les dépendances de production restantes, les procédures de validation des rejets et les possibilités d'améliorer la détection et l'intervention des incidents. Les mesures correctives et les activités d'amélioration suivantes ont été prises ou sont en cours : 1. ** Correction de la configuration de la production :** L'environnement de production APAC a été mis à jour pour utiliser le processus d'initialisation de l'application correcte, remplaçant la configuration précédente. 2. ** Validation de la dépendance à la clémence :** Une mesure de suivi a été mise en place pour ajouter une étape de validation avant que les composantes de la plate-forme héritée ne soient réduites ou déclassées, en veillant à ce que les services de production aient complètement changé et qu'il n'y ait plus de dépendances sur la plate-forme précédente. 3. **Release and Application Health-Check Review:** Les contrôles de santé des applications, les procédures de validation des rejets et la couverture des tests de santé post-libératoire sont en cours d'examen en regard de l'échec observé au cours de cet incident. L'examen déterminera s'il existe des lacunes dans la couverture et s'il faut procéder à une surveillance, à une validation ou à d'autres améliorations. 4. ** Enquête sur l'expansion des activités :** Nous continuerons d'étudier ce qui a déclenché les cas d'application initiaux à l'échelle suivant la libération et de déterminer si des mesures correctives ou préventives supplémentaires sont nécessaires. 5. **Améliorations de la communication avec les clients** Nous avons identifié une occasion de communiquer plus rapidement avec les clients pendant cet incident. Nos pratiques établies d'escalade de l'incident et de communication sont conçues pour assurer une notification proactive des clients lorsque l'impact imprévu du service est identifié. Les leçons tirées de cet incident ont été intégrées à nos pratiques d'intervention continue afin de s'assurer que ces procédures sont appliquées de façon uniforme et que des mises à jour proactives en temps opportun sont fournies aux clients pendant les interruptions de service.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 octobre 2026 à 10:59 UTCinvestigating

   Description de l'incident: Nous enquêtons sur une question touchant le service de licence au sein de SAM Core. Les utilisateurs peuvent ne pas être en mesure de charger les informations de licence et peuvent rencontrer des messages d'erreur lors de l'accès à la fonctionnalité Service de licence. Cette question a été confirmée au Royaume-Uni, en Europe du Sud et de l'Ouest, et les équipes techniques évaluent actuellement l'ampleur de l'impact. Priorité : P2 Activité de restauration : Les équipes techniques étudient activement la question et examinent le service touché. Une validation supplémentaire est en cours pour déterminer la portée complète de l'impact et rétablir l'exploitation normale du service. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 8 octobre 2026 à 11:30 UTCmonitoring

   Nous avons identifié le problème comme étant lié à un déploiement récent affectant le service Licences. Des modifications correctives ont été apportées et la fonctionnalité du service a été rétablie. Nous sommes actuellement en train de valider la santé des services et de surveiller l'environnement pour assurer la stabilité continue. D'autres mises à jour seront fournies à mesure que la validation supplémentaire sera terminée.

3. 8 octobre 2026 à 12:11 UTCresolved

   Après une validation et une période de surveillance, le service est demeuré stable et la fonctionnalité de licence est chargée avec succès dans les régions touchées. La question est maintenant considérée comme résolue.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 octobre 2026 à 00:08 UTCinvestigating

   Description de l'incident: Nous enquêtons sur une question touchant la fonctionnalité des accords dans Snow Atlas pour les clients en Australie. Les clients peuvent rencontrer des données manquantes ou non disponibles lors de l'accès à l'onglet Accords, et les opérations de mise à jour des données peuvent échouer. Priorité : P2 Activité de restauration: Les équipes techniques étudient activement la question et évaluent l'ampleur de l'impact client. Des travaux sont en cours pour déterminer la cause du problème et rétablir la fonctionnalité normale. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 8 octobre 2026 à 01:39 UTCresolved

   Une enquête plus approfondie a mis en évidence un problème de communication touchant la fonctionnalité d'un service de soutien aux ententes dans Snow Atlas Australia. Les équipes techniques ont mis en œuvre des mesures de récupération, y compris le redémarrage des composantes de service touchées, qui ont rétabli la communication et le fonctionnement normal. La fonctionnalité a été validée dans plusieurs environnements clients, et les données des accords s'affichent maintenant correctement. Nous n'avons observé aucun autre problème à la suite des activités de rétablissement et de validation. La question est maintenant considérée comme résolue.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 octobre 2026 à 20:27 UTCinvestigating

   Description de l'incident: Nous enquêtons sur les rapports de problèmes intermittents affectant les clients d'Ocean Kubernetes. Certains clients ont signalé avoir reçu des alertes liées à la connectivité entre les composants d'Ocean Kubernetes et leurs grappes. Les équipes techniques étudient activement la portée de l'impact et toute dégradation des services qui y est associée. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement le comportement signalé, examinent les rapports des clients et valident la portée et l'impact dans les environnements touchés. Nous fournirons des mises à jour supplémentaires à mesure que de plus amples renseignements seront disponibles.

2. 7 octobre 2026 à 22:23 UTCinvestigating

   Nous continuons d'étudier les problèmes de connectivité intermittents signalés précédemment. À l'heure actuelle, aucun événement supplémentaire n'a été observé depuis la fenêtre d'impact initiale. Les équipes techniques examinent activement les résultats de télémétrie et d'enquête disponibles pour déterminer la cause sous-jacente et valider la portée globale de l'impact. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

3. 8 octobre 2026 à 00:03 UTCinvestigating

   Nous n'avons pas observé d'autres événements depuis la fenêtre d'impact initialement signalée, et la stabilité du service a été maintenue. Les équipes techniques continuent d'étudier la cause sous-jacente des problèmes de connectivité intermittents signalés plus tôt aujourd'hui.

4. 8 octobre 2026 à 00:04 UTCmonitoring

   Compte tenu de la stabilité soutenue observée depuis la fenêtre d'impact initialement signalée et de l'absence d'événements supplémentaires signalés, nous acheminons cet incident à Surveillance. Les équipes techniques continuent d'étudier la cause sous-jacente pendant la surveillance de la stabilité du service. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

5. 8 octobre 2026 à 02:24 UTCresolved

   Nous n'avons pas observé d'autres événements depuis l'impact initial signalé, et la stabilité du service a été maintenue. Les équipes techniques ont mené une enquête supplémentaire sur les problèmes de connectivité intermittents signalés plus tôt aujourd'hui. Plusieurs corrélations potentielles ont été examinées au cours de l'enquête, et l'analyse finale est toujours en cours. Compte tenu de la stabilité soutenue observée et de l'absence de récidive, cet incident est maintenant considéré comme résolu. Les équipes techniques poursuivront les activités de surveillance et d'investigation afin de mieux comprendre le comportement observé pendant la fenêtre d'impact signalée, et un rapport officiel de l'ACR sera fourni une fois l'analyse terminée.

6. 20 octobre 2026 à 17:50 UTCpostmortem

   **Description:** Ocean de l'emplacement - Kubernetes - Questions de connectivité du contrôleur intermittent **Calendrier:** 7 octobre 2026, 11 h 20 PDT - 12 h 30 PDT **Résumé de l'incident** Le mercredi 7 octobre 2026, à 11h20 PDT, plusieurs environnements Spot Ocean pour Kubernetes ont connu des alertes intermittentes de connectivité de contrôleur. Au cours de l'incident, la plate-forme a temporairement interprété l'information sur les battements cardiaques du contrôleur comme des opérations d'échelle dépassées et suspendues pour les grappes touchées comme une mesure de sécurité. Les contrôleurs touchés ont continué de signaler les battements cardiaques pendant l'incident. Cependant, l'horodatage utilisé pour valider la connectivité des contrôleurs est devenu obsolète au sein d'un composant de base de données, ce qui a provoqué l'apparition temporaire de contrôleurs actifs. Le comportement était intermittent, et l'information actuelle sur les battements cardiaques est ensuite devenue disponible sans intervention manuelle, ce qui a permis aux opérations d'échelle normale de reprendre. Les équipes techniques ont examiné le chemin de traitement des battements cardiaques du contrôleur, le comportement de la base de données, la télémétrie de service et les signaux d'infrastructure connexes afin de déterminer pourquoi l'activité des battements cardiaques valides était interprétée comme étant discontinue. Aucun autre événement n'a été observé après la fenêtre de l'incident. Après une surveillance continue et une validation de la stabilité du service, l'incident a été considéré résolu. ** Cause de la mort** L'incident a été causé par l'écrasement d'un horodatage du rythme cardiaque par un contrôleur plus ancien, un horodatage valide plus récent dans un composant de base de données. Bien que les contrôleurs touchés aient continué à signaler les battements cardiaques normalement, l'horodatage dépassé a fait apparaître le battement cardiaque le plus récent. Lorsque la plate-forme a évalué cet horodatage, il a dépassé le seuil de battement cardiaque configuré et a déclenché un mécanisme de sécurité qui a temporairement suspendu les opérations de mise à l'échelle pour les grappes touchées. La condition spécifique qui a retardé l'ancienne mise à jour de la base de données n'a pas été établie de manière concluante. Toutefois, le processus de mise à jour de la base de données ne contenait pas de protection pour empêcher un horodatage cardiaque plus ancien de remplacer un horodatage plus récent valide. Cela a permis de retarder l'information sur les battements cardiaques pour créer l'apparence que les contrôleurs déclarant activement étaient insensibles. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. Rapports clients et comportement de service examinés : Les équipes techniques ont examiné des exemples signalés pour confirmer le comportement, établir la fenêtre d'impact et déterminer si le problème était isolé ou affectant plusieurs environnements. 2. Activité de battement cardiaque du contrôleur Validée : L'activité de contrôle a été revue pour déterminer si les contrôleurs touchés avaient cessé de signaler. L'enquête a confirmé que des informations sur les battements cardiaques ont continué d'être envoyées pendant l'incident. 3. Chemin de traitement des battements cardiaques étudié: Les équipes techniques ont tracé comment l'information sur les battements cardiaques a été générée, stockée et évaluée pour identifier où l'activité actuelle des battements cardiaques était interprétée comme dépassée. 4. Évaluation de la base de données et de la santé des services : Le rendement de la base de données, le comportement des services et la télémétrie de l'infrastructure ont été examinés afin d'évaluer les retards éventuels de traitement et d'éliminer l'instabilité des plates-formes. 5. Régression de l'horodatage identifiée: L'enquête a permis de déterminer qu'un horodatage plus ancien du rythme cardiaque avait écrasé un horodatage plus récent valide, ce qui a amené la plate-forme à interpréter temporairement le rythme cardiaque comme une impasse. 6. Stabilité du service validée: Les équipes techniques ont poursuivi la surveillance après récupération. Aucun autre événement n'a été observé, et les opérations d'échelle sont restées stables avant la fermeture de l'incident. ** Mesures préventives à venir** Les améliorations suivantes sont prévues pour renforcer le traitement des battements cardiaques et améliorer la détection de conditions similaires: 1. Protection contre le rythme cardiaque : Le processus de mise à jour de la base de données sera modifié afin d'éviter qu'un horodatage cardiaque plus ancien n'écrase un horodatage plus récent valide. 2. Amélioration de l'enregistrement diagnostique : Une nouvelle mise à jour du rythme cardiaque permettra de saisir la source de chaque mise à jour, le contexte de demande pertinent, les valeurs d'horodatage antérieures et nouvelles et la source de l'horodatage. 3. Surveillance et alerte: De nouvelles mesures de surveillance et d'alerte seront mises au point à l'aide des informations diagnostiques supplémentaires afin d'identifier plus rapidement les régressions de l'horodatage et les états de rythme cardiaque similaires. 4. Examen de l'accès à la base de données : Les modèles d'accès à la base de données associés au traitement des battements cardiaques seront examinés afin de déterminer les possibilités de réduire les retards de traitement et d'optimiser les performances sous charge élevée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 septembre 2026 à 11:08 UTCinvestigating

   Description de l'incident : Nous enquêtons sur une question touchant le service de notification d'événement dans plusieurs environnements de production. Les clients peuvent subir des retards ou des défaillances lors de la réception des notifications d'événements v2, y compris les notifications envoyées par courriel, des webhooks, Slack et d'autres canaux pris en charge. Les événements continuent d'être enregistrés et restent accessibles via la console Flexera One et l'API. À l'heure actuelle, rien n'indique que la fonctionnalité de la plate-forme centrale ou les données d'événements aient été touchées. Priorité: P3 Activité de restauration : Nos équipes techniques ont identifié le problème et mis en oeuvre des mesures de rétablissement des services. La surveillance indique que les taux d'erreur diminuent et que les équipes continuent de valider la stabilité des services et d'évaluer l'ampleur de l'impact. D'autres mises à jour seront fournies à mesure que les efforts d'enquête et de rétablissement progresseront. Mise à jour: Une enquête plus approfondie a confirmé que cette question n'avait pas d'incidence sur les clients. Les notifications concernées ne devaient pas être publiées.

2. 29 septembre 2026 à 11:53 UTCresolved

   Après avoir suivi de près les services pour confirmer la stabilité, nos équipes n'ont observé aucune autre erreur ou récurrence du problème. Cet incident est maintenant résolu.

3. 13 octobre 2026 à 04:42 UTCpostmortem

   **Description:** Emplacement par Flexera - Erreurs de traitement des notifications d'événements **Calendrier:** 29 septembre 2026, 2:06 PDT - 4:51 PDT **Résumé de l'incident** Le 29 septembre 2026, Flexera a identifié des erreurs d'application élevées au sein d'un composant de traitement de notification responsable du traitement de certains workflows de notification d'événements. La surveillance automatisée a permis de détecter une activité d'erreur accrue, ce qui a conduit à une enquête pour déterminer si les notifications adressées aux clients étaient touchées. Au cours de l'enquête, les équipes techniques ont identifié les défaillances survenues dans le cadre d'un processus de traitement des notifications et ont procédé à une évaluation détaillée des événements touchés, des processus de notification et de l'impact potentiel sur les clients. L'analyse initiale a suggéré que la question pourrait avoir une incidence plus générale sur le traitement des notifications, et un incident majeur a été déclaré pendant que la portée et l'incidence étaient validées. D'autres analyses d'impact ont confirmé que les notifications concernées ne devaient pas être publiées aux clients. Les informations sur les événements ont continué d'être enregistrées avec succès et sont restées disponibles tout au long de l'enquête. Aucune fonctionnalité orientée vers le client n'a été perturbée, aucune donnée d'événement n'a été perdue et aucun impact client n'a été identifié à la suite de ce problème. Sur la base des résultats de l'analyse d'impact, la priorité de l'incident a été déclassée et l'enquête a été menée à terme après validation, ce qui a confirmé que les services destinés aux clients n'étaient pas touchés. ** Cause de la mort** L'enquête a permis de déterminer qu'un processus de traitement des notifications a fait l'objet d'une exception lors de la gestion d'un sous-ensemble d'événements internes. Ces événements ont été configurés de telle sorte qu'ils n'étaient pas destinés à la notification à la clientèle. Bien que les exceptions aient entraîné des erreurs d'application élevées et justifié une enquête, l'analyse subséquente a confirmé que les avis visés ne devaient pas être distribués aux clients. Par conséquent, la livraison des avis à la clientèle, la fonctionnalité de la plateforme et l'accès à l'information sur les événements n'ont pas été affectés. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. Ouverture d'une enquête sur les incidents : Les équipes techniques ont étudié les erreurs d'application élevées détectées par une surveillance automatisée et ont évalué l'impact potentiel sur les clients. 2. Analyse du traitement des notifications effectuée : Le processus de notification touché a été examiné pour déterminer la source des exceptions à la demande et la portée de la question. 3. Évaluation de l'impact client terminée: Les équipes techniques ont validé les types de notification concernés, examiné le comportement de publication de l'événement et confirmé que les notifications en cause n'étaient pas destinées à la livraison du client. 4. Validation et surveillance du système : Les tendances des erreurs, le comportement des services et le traitement des notifications ont été surveillés afin de confirmer la stabilité du fonctionnement et de confirmer que les services destinés aux clients n'étaient pas touchés. 5. Reclassification de l'incident terminée : Après confirmation qu'il n'y avait pas d'impact sur le client, la priorité de l'incident a été réduite et l'incident a été officiellement résolu. ** Mesures préventives à venir** À la suite de cette enquête, nous avons identifié des occasions d'améliorer la rapidité et l'exactitude de l'analyse d'impact lorsque les alertes opérationnelles impliquent des processus de traitement internes. 1. Amélioration de l ' évaluation d ' impact: Examiner les classifications des notifications internes et les procédures d ' enquête afin d ' accélérer la détermination de l ' incidence d ' une question sur la fonctionnalité du client au cours des incidents futurs. 2. Amélioration de la visibilité des processus de notification : améliorer la visibilité opérationnelle des voies de traitement des notifications orientées vers le client et non vers le client afin de faciliter la validation des impacts et les activités d'intervention en cas d'incident.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 septembre 2026 à 09:10 UTCinvestigating

   Description de l'incident : Nous enquêtons sur une question touchant la visibilité informatique dans la région APAC où les tableaux de bord Power BI ne sont pas en charge. Les clients de la région touchée peuvent être incapables d'accéder aux tableaux de bord de déclaration dans l'application. L'enquête en cours indique que la question est limitée à la région de l'APAC, et qu'aucune incidence n'a été observée dans d'autres régions pour le moment. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question pour identifier la cause sous-jacente et restaurer la fonctionnalité du rapport. Nous continuons d'évaluer l'ampleur de l'impact, de surveiller la santé des services et de mettre en oeuvre des mesures correctives au besoin. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 28 septembre 2026 à 09:26 UTCresolved

   La question touchant les tableaux de bord des rapports Power BI dans la région APAC a été résolue. L'enquête initiale indique qu'une mise à jour de configuration était nécessaire après une mise à niveau récente. Nos équipes techniques ont effectué les travaux d'assainissement nécessaires, et la validation subséquente a confirmé que les tableaux de bord concernés sont maintenant accessibles et fonctionnent comme prévu. Tous les services sont revenus à la normale, et cet incident est maintenant considéré comme résolu.

3. 26 octobre 2026 à 12:10 UTCpostmortem

   **Description:** Flexera Une- Visibilité TI- APAC - Rapports des tableaux de bord non disponibles **Calendrier:** 28 septembre 2026, 1:38 PDT au 28 septembre 2026, 2:15 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Lundi 28 septembre 2026, à 1:38 AM PDT, Flexera a identifié un problème affectant l'accès aux tableaux de bord de rapports Power BI pour les clients de la région APAC. Nos équipes techniques ont été rapidement engagées et l'enquête initiale a confirmé que l'impact était limité à l'APAC, tandis que les autres régions sont restées réactives. Une enquête plus approfondie a permis de déterminer que les changements de configuration associés à une migration planifiée de gestion de l'identité et de l'accès avaient affecté les paramètres de connexion requis par les services de rapport. Au cours de l'application de ces changements, les paramètres de connexion des services déclarants ont été remis à des valeurs qui ne contenaient pas l'adresse complète requise pour une communication réussie. Par conséquent, les services concernés n'ont pas démarré correctement, ce qui a entraîné l'indisponibilité des tableaux de bord de rapports Power BI pour les clients d'APAC. Pour restaurer le service, l'équipe technique a corrigé manuellement les paramètres de connexion touchés dans l'environnement APAC. Cela a rétabli la communication entre les services de rapport et d'authentification, ce qui a permis aux services touchés de récupérer. Après la restauration, la validation a confirmé que les tableaux de bord Power BI étaient accessibles et fonctionnaient normalement à environ 2h15 HAP. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été causé par des paramètres de connexion incorrects appliqués à l'environnement APAC lors d'un changement de configuration associé à la migration d'identité et de gestion d'accès. Le changement réinitialise les adresses de connexion des services de rapport à des valeurs qui ne contenaient pas les adresses complètes requises pour une communication réussie avec les services d'authentification. Par conséquent, les services de déclaration touchés n'ont pas commencé correctement, rendant les tableaux de bord Power BI indisponibles pour les clients de la région APAC. Facteurs contributifs * Incohérence de configuration : Les adresses de connexion requises avaient déjà été mises à jour directement dans l'environnement mais n'étaient pas reflétées dans la configuration de déploiement. Par conséquent, le changement de configuration subséquent a réintroduit les valeurs incorrectes. * Lacune de validation du déploiement : Le processus de déploiement n'a pas identifié les paramètres de connexion incorrects avant qu'ils n'affectent la disponibilité du service. * Coordination du changement et validation de la dépendance : Le processus de migration n'a pas pleinement tenu compte des exigences de configuration de tous les services dépendants, ce qui a entraîné l'application de modifications au paramètre sans validation préalable des dépendances de service concernées. (en milliers de dollars) **Mesures correctives** Nos équipes ont effectué les actions ci-dessous pour rétablir les services à la normale: * Les paramètres de connexion touchés ont été corrigés pour rétablir la communication entre les services de reporting et d'authentification. * Les services touchés se sont rétablis et la validation a confirmé que les tableaux de bord des rapports Power BI étaient accessibles et fonctionnaient normalement. * La configuration a par la suite été corrigée pour s'assurer que les réglages de connexion requis sont maintenus systématiquement pour les déploiements futurs. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) Les mesures suivantes ont été identifiées et sont en cours d'élaboration pour réduire la probabilité de récidive et améliorer la résilience des services : * Gestion de la configuration : S'assurer que les modifications de la configuration du service sont gérées de façon cohérente pour éviter les écarts entre les paramètres déployés et les configurations maintenues. * Validation du déploiement : Examiner les changements de configuration prévus avant le déploiement pour vérifier que les paramètres de connexion de service requis demeurent corrects. * Cohérence de configuration : S'assurer que les paramètres de connexion critiques sont maintenus dans les sources de configuration appropriées et ne dépendent pas des modifications manuelles apportées aux environnements individuels. * Coordination du changement : Améliorer la coordination des migrations prévues et des changements de configuration, y compris la validation des besoins et des dépendances des services touchés. * Protections de déploiement : Renforcer les vérifications préalables au déploiement pour identifier les paramètres de configuration incorrects avant qu'ils ne causent des pannes de service.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 septembre 2026 à 23:18 UTCinvestigating

   Description de l'incident : Nous enquêtons sur une question touchant certains services d'intégration de la gestion des actifs de TI et de portail d'applications dans toutes les régions. Les clients utilisant des intégrations basées sur l'API touchées peuvent subir des défaillances d'authentification résultant en des erreurs HTTP 401 non autorisées, ce qui peut empêcher les demandes de compléter avec succès. Les utilisateurs du portail d'applications peuvent également rencontrer des erreurs lors de la soumission des demandes. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question et évaluent les mesures correctives. Les activités d'enquête et de validation sont en cours et nous nous efforçons de rétablir la fonctionnalité de service normale le plus rapidement possible. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 26 septembre 2026 à 05:31 UTCidentified

   Le hotfix corrigé est actuellement en attente d'achèvement du processus de construction, qui prend plus de temps que prévu. Une fois la construction terminée, nos équipes techniques procéderont à la validation UAT avant d'aller de l'avant avec le déploiement de la production. L'équipe s'emploie également à confirmer le plan de déploiement, l'appropriation et le calendrier prévu. D'autres mises à jour seront fournies à mesure que ces activités progresseront.

3. 26 septembre 2026 à 12:30 UTCmonitoring

   Nos équipes ont mis en place avec succès un hotfix, et la validation initiale confirme que les services fonctionnent comme prévu. Nous continuons de surveiller de près l'environnement en attendant la confirmation des clients touchés.

4. 27 septembre 2026 à 05:39 UTCmonitoring

   Les API fonctionnent comme prévu, et les erreurs précédemment observées ne sont plus détectées. L'incident demeure en cours de surveillance pendant que la validation supplémentaire est terminée et que la confirmation du client est obtenue.

5. 28 septembre 2026 à 17:14 UTCresolved

   À la suite des activités d'assainissement terminées au cours de la fin de semaine, nous avons continué de surveiller les services touchés afin de valider la stabilité et le rétablissement durables. La validation client a maintenant été reçue confirmant que la fonctionnalité de l'App Portal et le traitement des demandes d'API fonctionnent normalement. Une enquête plus approfondie a permis d'identifier un problème touchant le traitement d'authentification au sein d'un composant de service, ce qui a entraîné des erreurs non autorisées pour les demandes d'API touchées et les erreurs lors de la soumission des demandes par le biais du portail App. Nos équipes techniques ont mis en oeuvre des mesures correctives pour régler le problème et ont effectué une validation supplémentaire après avoir identifié et résolu un problème distinct rencontré au cours du processus d'assainissement. Après l'assainissement et la surveillance élargie, les services sont demeurés stables et aucun autre problème n'a été observé. Une analyse complète des causes profondes sera effectuée, et un rapport post-incident sera partagé détaillant la cause profonde, les activités d'assainissement et les mesures correctives identifiées dans le cadre de l'enquête.

6. 8 octobre 2026 à 11:25 UTCpostmortem

   **Description:** Flexera One – Gestion des actifs informatiques – Toutes les régions – Erreurs dans le portail de l'application et défaillances de l'API **Calendrier:** 24 septembre 2026, 12h12 PDT – 26 septembre 2026, 16h38 PDT **Résumé de l'incident** À partir du 24 septembre 2026, vers 12h12 PDT, les clients utilisant des intégrations basées sur l'API avec Flexera One IT Asset Management \(ITAM\) ont connu des défaillances d'authentification qui ont retourné des réponses HTTP 401 non autorisées. Les utilisateurs du portail d'applications ont également rencontré des erreurs lors de la soumission des demandes, et des intégrations comme App Broker et Business Adapter qui dépendent de ces API ont été affectées. L'impact a été observé dans les régions de l'Amérique du Nord, de l'Europe et de l'Asie-Pacifique. Les équipes techniques ont étudié et confirmé que les défaillances n'étaient pas liées aux qualifications du client ou à la configuration du client. Les registres d'application ont montré que les éléments requis pour authentifier ces demandes n'avaient pas été initialisés. Une enquête plus approfondie a permis de déterminer que le comportement a été introduit par un hotfix déployé comme mesure préventive lors de la réponse à l'incident précédent de chargement du menu ITAM le 24 septembre. Les équipes techniques ont reproduit le comportement dans les tests, développé un correctif, et l'ont validé. Au cours de la validation du déploiement, un problème de chargement secondaire des composants a été identifié et réglé par un correctif à chaud mis à jour. Après le déploiement du hotfix mis à jour à Production, les équipes techniques ont vérifié que la fonctionnalité de l'API fonctionnait comme prévu, et le service a été rétabli le 26 septembre à environ 4:38 AM PDT. L'incident est ensuite passé à une surveillance étendue pendant que la confirmation du client était obtenue, et la confirmation a été reçue le 28 septembre. Après la restauration du service, des défaillances d'authentification intermittentes isolées ont été signalées et examinées séparément de l'incident principal. Les équipes techniques ont identifié d'autres conditions de connexion et de configuration spécifiques à l'environnement et ont déployé d'autres correctifs, qui ont été validés jusqu'au 30 septembre. La surveillance continue et l'examen des clients jusqu'au 1er octobre ont confirmé que la question ne pouvait plus être reproduite et qu'aucun autre événement n'avait été observé. ** Cause de la mort** L'incident a été causé par un défaut dans un raccord à chaud qui a été déployé comme mesure préventive lors de la réponse à l'incident précédent de chargement du menu ITAM le 24 septembre. Le hotfix a supprimé une dépendance des composants d'authentification de l'application et a changé la façon dont l'application lit la configuration qu'elle utilise pour se connecter aux services d'authentification. Les réglages requis étaient présents dans la configuration déployée. Cependant, l'application a tenté de les lire en utilisant une méthode qui n'est pas supportée pour la configuration chargée à l'exécution. Par conséquent, les composants requis pour l'authentification n'ont pas pu être initialisés et les demandes d'authentification ont été rejetées comme non autorisées. Cela a produit les erreurs API et les défaillances de requête du portail App que les clients ont vécus. Le même comportement s'est produit dans l'environnement de validation de préproduction lorsque le hotfix y a été appliqué. Il n'a pas été identifié avant que le hotfix atteigne Production parce que les API touchées ne sont pas activement utilisées dans cet environnement, et que l'alerte d'erreur spécifique n'était pas encore en place pour eux. La correction initiale portait sur le défaut de configuration primaire. Au cours de la validation et de la surveillance subséquentes, d'autres conditions de chargement, de manipulation de la connexion et de configuration propres à l'environnement ont été identifiées et ont exigé d'autres correctifs à chaud avant de pouvoir confirmer une stabilité soutenue. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. Incident Response Initiated: Les équipes techniques ont commencé à enquêter après que les clients ont signalé des défaillances d'authentification et des erreurs d'API. 2. Portée et configuration du client évalués : Les équipes techniques ont confirmé que les défaillances n'étaient pas liées aux qualifications ou à la configuration du client et ont confirmé que l'impact s'étendait à plusieurs régions. 3. Condition sous-jacente identifiée : Les équipes techniques ont déterminé que les paramètres d'authentification requis étaient présents mais ne pouvaient pas être lus au moment de l'exécution et ont reproduit le comportement lors des essais. 4. Correction développée et validée: Le code de l'application a été mis à jour pour lire les paramètres en utilisant une méthode supportée. Les tests de validation ont confirmé que les erreurs d'authentification ne se sont plus produites. 5. Correction du déploiement et rétablissement du service : Un problème de chargement de composants secondaires identifié lors de la validation du déploiement a été réglé par un correctif mis à jour. Après le déploiement du hotfix à la production, les équipes techniques ont vérifié que la fonctionnalité de l'API fonctionnait comme prévu. 6. Surveillance étendue et validation du client: Les équipes techniques ont suivi le comportement de service tout au long du week-end et ont obtenu la confirmation d'un client affecté. 7. Remise en état après l ' incident : Après que des défaillances intermittentes isolées ont été signalées après la restauration du service, les équipes techniques ont déployé de nouveaux correctifs et les ont validés jusqu ' au 30 septembre. La surveillance et l'examen des clients se sont poursuivis jusqu'au 1er octobre pour confirmer que le problème ne s'est plus produit. ** Mesures préventives à venir** Après l'incident, nous avons effectué une rétrospective pour examiner la cause technique, le processus de validation de hotfix, les capacités de surveillance et les facteurs qui ont contribué à l'impact client. Les mesures suivantes ont été prises ou sont en cours de mise en œuvre : 1. Correction de configuration d'exécution: L'application a été corrigée pour lire sa configuration d'authentification en utilisant une méthode supportée, et des correctifs supplémentaires ont été déployés et validés dans les environnements de production. 2. Surveillance et alerte d'API: Une alerte de taux d'erreur est ajoutée pour les API concernées afin que les défaillances d'authentification soient détectées dans les environnements de préproduction et de production, même lorsque le service n'est pas activement utilisé. 3. Processus de validation à chaud: Nous évaluons les contrôles supplémentaires des services dépendants, tels que les intégrations API et la fonctionnalité du portail App, dans le cadre de la validation de hotfix avant que les modifications ne soient approuvées pour Production.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 septembre 2026 à 16:19 UTCinvestigating

   Description de l'incident: Nous enquêtons sur une question touchant un sous-ensemble de clients de Flexera One IT Asset Management. Les clients touchés peuvent connaître des données d'inventaire manquantes ou des résultats vides lors de l'accès à la vue All Inventory et aux vues connexes basées sur l'inventaire. La question est limitée à un sous-ensemble de clients en Amérique du Nord. Priorité : P2 Activité de restauration : Les équipes techniques étudient activement la question et examinent les processus de traitement des données d'inventaire associés à la fonctionnalité touchée. La portée de l'impact est en cours de validation pendant l'évaluation des options d'atténuation et de rétablissement. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 25 septembre 2026 à 18:50 UTCidentified

   Les équipes techniques ont identifié une cause probable du problème associé à un changement récent du niveau de capacité touchant le traitement des données d'inventaire. Des activités de rétablissement sont en cours, y compris des mesures de recul et des mesures correctives visant à rétablir le traitement normal des données d'inventaire. Les équipes techniques travaillent activement à l'assainissement et à la validation de la récupération pour les clients touchés. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

3. 25 septembre 2026 à 21:22 UTCidentified

   Les équipes techniques continuent de mener des activités d'assainissement liées à la question et exécutent activement des mesures de rétablissement conçues pour rétablir le traitement normal des données d'inventaire. Au cours de l'exécution, les équipes ont rencontré d'autres conditions qui ont nécessité des ajustements à l'approche de remise en état et des activités de rétablissement actualisées sont en cours. Les équipes techniques demeurent actives et travaillent en permanence pour terminer l'assainissement et rétablir le service normal pour les clients touchés le plus rapidement possible. Nous apprécions votre patience pendant que ces efforts se poursuivent et nous excusons pour l'impact continu. D'autres mises à jour seront fournies à mesure que des progrès significatifs seront réalisés.

4. 26 septembre 2026 à 00:55 UTCidentified

   Les équipes techniques continuent de mener des activités d'assainissement associées à la question et exécutent activement des mesures de renversement et de correction conçues pour rétablir le traitement normal des données d'inventaire. Les activités de relèvement sont toujours en cours, et les équipes techniques surveillent activement l'exécution au fur et à mesure que les travaux de remise en état se poursuivent.

5. 26 septembre 2026 à 05:25 UTCmonitoring

   Nos équipes techniques ont mené à bien les activités d'assainissement requises. Les tâches de blocage ont été réglées. La validation après l'assainissement a confirmé que les fonctions et procédures de base de données pertinentes fonctionnent dans l'état prévu. Les équipes continueront de surveiller l'environnement pour assurer la stabilité.

6. 26 septembre 2026 à 07:13 UTCresolved

   Toutes les vérifications de validation ont été effectuées avec succès, et les services sont revenus à la normale. La question est maintenant réglée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 21:43 UTCidentified

   Description de l'incident : Nous enquêtons sur une question touchant l'océan Spot pour les SSFE. Les clients peuvent ne pas être en mesure de lancer de nouvelles instances en raison de défaillances de provisionnement. Par conséquent, les grappes touchées pourraient ne pas être en mesure d'atteindre l'échelle prévue. La charge de travail actuelle reste opérationnelle. Nos équipes techniques étudient activement la portée et l'impact de la question. Priorité : P2 Activité de restauration : Nos équipes techniques ont identifié un problème potentiel lié à un changement récent touchant l'approvisionnement en instance et valident activement l'impact. Des activités d'atténuation sont en cours, y compris le renversement d'un changement récent tandis que les équipes surveillent le rétablissement et le comportement de service. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 24 septembre 2026 à 22:16 UTCresolved

   Une enquête plus approfondie a permis de déterminer qu'un changement récent affectant le comportement de provisionnement de l'instance a contribué à la question. Les équipes techniques ont effectué un renversement du changement et validé la récupération. Après le renversement, les niveaux d'erreur sont revenus à la normale et la provisionnement de la nouvelle instance a repris avec succès. Tout au long de l'incident, les cas et la charge de travail existants sont demeurés opérationnels. L'impact s'est limité aux lancements d'instances nouvelles et aux opérations de renforcement des grappes. La question est maintenant considérée comme résolue. Un rapport détaillé post mortem sera communiqué après l'achèvement de l'analyse des causes profondes et de l'examen post-incident, documentant la séquence complète des événements, les facteurs contributifs, les leçons apprises et toutes les mesures de suivi identifiées.

3. 9 octobre 2026 à 06:33 UTCpostmortem

   **Description:** Océan de l'emplacement pour les AWS – Défauts de fourniture d'instances **Calendrier:** 24 septembre 2026, 12h00 PDT au 24 septembre 2026, 14h54 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le 24 septembre 2026, Spot Ocean for AWS a connu un problème qui a empêché certains clients de lancer de nouvelles instances. En conséquence, les groupes touchés n ' ont pas été en mesure d ' atteindre l ' échelle prévue lorsque des capacités de calcul supplémentaires étaient nécessaires. Les cas et la charge de travail existants sont restés opérationnels tout au long de l'incident. L'impact s'est limité aux nouvelles opérations de fourniture d'instances et d'expansion des grappes. L'équipe technique a constaté qu'un changement récent de logiciel a introduit un comportement inattendu pendant le processus de fourniture d'instances. Le changement a été repoussé, ce qui a permis d'éliminer les erreurs de fourniture et de rétablir l'exploitation normale du service. Après le retour en arrière, le problème du logiciel sous-jacent a été identifié et corrigé. La fonctionnalité mise à jour a fait l'objet d'une validation supplémentaire pour s'assurer que la question est entièrement traitée avant d'être réintroduite dans l'environnement de production. Les équipes techniques ont validé les lancements d'instances réussies après le renversement, et la validation du client a confirmé que la fourniture de nouvelles instances fonctionnait comme prévu. L'incident a été réglé à 14 h 54 PDT le 24 septembre 2026. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été causé par un changement récent de logiciel qui a introduit un comportement non intentionnel pendant la fourniture de l'instance AWS. Le changement a eu une incidence sur le traitement de certaines informations relatives à la configuration des grappes, ce qui a entraîné des défaillances pour certaines opérations d'expansion. Alors que le changement a été conçu pour supporter le marquage pour des ressources AWS spécifiques, son comportement a également affecté d'autres configurations de cluster supportées. Dans certaines conditions, la logique d'étiquetage mise à jour a donné lieu à la présentation de renseignements sur les étiquettes en double dans le cadre de la demande de fourniture d'instances. AWS a rejeté ces demandes parce que les renseignements sur les étiquettes ne satisfaisaient pas aux exigences prévues. Par conséquent, Spot Ocean n'a pas été en mesure d'achever la mise à disposition de certains nouveaux cas. Cela a surtout affecté les lancements de nouvelles instances et les opérations de mise à niveau des grappes. Les cas existants avaient déjà été fournis avec succès et ont donc continué à fonctionner normalement tout au long de l ' incident. La fonctionnalité sous-jacente a depuis été corrigée, et une validation supplémentaire est effectuée pour s'assurer que le comportement mis à jour fonctionne de manière cohérente dans les configurations de clusters AWS prises en charge avant qu'il ne soit retourné à la production. (en milliers de dollars) (en milliers de dollars) **Mesures correctives** Nos équipes ont effectué les actions ci-dessous pour rétablir les services à la normale: * Renversé le changement de logiciel, rétablissant l'approvisionnement en instance normale. * Identifié et corrigé le problème sous-jacent dans la fonctionnalité affectée. * Validation supplémentaire de la fonctionnalité corrigée. * Mise en place de mesures de protection supplémentaires pour permettre le déploiement de la fonctionnalité mise à jour de manière contrôlée. * Validé que les nouvelles opérations de fourniture d'instances et d'échelle des grappes fonctionnaient comme prévu après le renversement. (en milliers de dollars) ** Mesures préventives à venir** * Développer les essais automatisés, par exemple les scénarios de fourniture et de mise à l'échelle des groupes. * Augmenter les tests de régression dans les configurations de grappes AWS supportées. * Élargir les tests de bout en bout pour l'échelle des flux de travail. * Améliorer la surveillance et l'alerte en cas de défaillances de l'approvisionnement et de l'échelle. * Renforcer la validation des changements avant le déploiement de la production. * Instaurer des garanties supplémentaires pour le déploiement contrôlé des changements qui affectent le comportement de provisionnement. * Augmenter la couverture des tests pour les cas de bord et les scénarios de gestion des erreurs.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 20:46 UTCmonitoring

   Description de l'incident : Plus tôt aujourd'hui, un problème touchant le traitement des stocks dans Flexera One IT Asset Management (ITAM) dans la région du NAM a touché un sous-ensemble de clients. L'enquête a révélé que les chargements d'inventaire étaient reçus avec succès mais qu'ils n'étaient pas traités pour les clients touchés, ce qui a entraîné des retards dans les données d'inventaire reflétées dans Flexera One ITAM. Des mesures de rétablissement ont été mises en oeuvre et le traitement des stocks a depuis repris avec succès. Les dossiers d'inventaire continuent de faire l'objet d'un traitement normal; toutefois, le recouvrement du reste de l'arriéré est toujours en cours et est suivi par cet incident. Priorité : P2 Activité de restauration : Les équipes techniques ont mis en œuvre des mesures de rétablissement qui ont rétabli le traitement des dossiers d'inventaire et validé le traitement réussi par la surveillance et l'enregistrement. L'exploitation du service demeure stable et le recouvrement de l'arriéré se poursuit à mesure que les dossiers d'inventaire en attente sont traités. Les équipes techniques surveillent activement les progrès en matière de rétablissement, la santé des services et la réduction de l'arriéré tandis que les activités de validation se poursuivent. Les mises à jour antérieures relatives aux étapes antérieures de cet incident se trouvent dans l'historique de l'incident ci-dessous. D'autres mises à jour seront fournies à mesure que l'arriéré de recouvrement progressera et que les activités de validation se poursuivront. https://status.flexera.com/incidents/5wrg6jl9bj2h

2. 25 septembre 2026 à 08:15 UTCmonitoring

   La récupération de backlog continue comme les fichiers d'inventaire précédemment en attente sont traités. Les niveaux de backlog sont maintenant dans une plage acceptable, une organisation restant au-dessus des niveaux prévus. Les équipes techniques continuent de surveiller le rétablissement, la santé des services et les activités de traitement, tandis que la validation se poursuit.

3. 25 septembre 2026 à 13:28 UTCresolved

   L'arriéré accumulé au cours de l'incident a été traité avec succès, et les niveaux de traitement sont revenus à des plages d'exploitation normales. Nos équipes ont terminé la validation du rétablissement, et cet incident est en cours de résolution. De plus amples détails sur la cause sous-jacente et les mesures prises seront fournis dans le rapport post mortem.

4. 23 octobre 2026 à 17:27 UTCpostmortem

   **Description :** Flexera One - Gestion des biens de TI - NAM - Retards dans le traitement des stocks après l'activité de mainlevée de production **Calendrier:** 22 septembre 2026, 19 h 05 PDT - 25 septembre 2026, 5 h 30 PDT **Résumé de l'incident** Le 24 septembre 2026, les équipes techniques ont commencé à enquêter sur les rapports de mises à jour d'inventaire retardées touchant un sous-ensemble de clients utilisant Flexera One IT Asset Management \(ITAM\) dans la région de l'Amérique du Nord \(NAM\). Bien que les dossiers d'inventaire aient été téléchargés avec succès et soient demeurés disponibles, certains clients ont connu des retards dans le traitement de ces dossiers, ce qui a empêché que les renseignements les plus récents sur l'inventaire soient reflétés dans la demande. L'information sur l'état des balises affichée dans ITAM aurait également pu être dépassée pour les clients touchés. Le traitement des stocks s'est poursuivi normalement pour les autres clients. Le problème est survenu à la suite de l'activité de diffusion de la production ITAM 2026R1.3 le 22 septembre 2026. L'enquête a révélé une interruption du processus de transfert des fichiers d'inventaire téléchargés aux services de traitement des stocks de l'ITAM. Bien que les dossiers touchés demeurent disponibles en entreposage, ils n'étaient pas transmis pour traitement. Les équipes techniques ont également observé des erreurs d'application élevées au cours de l'enquête, bien que ces erreurs n'aient pas été établies de façon concluante comme cause de l'interruption. Les équipes techniques ont effectué un redémarrage ciblé de la composante de service touchée, rétablissant le transfert des fichiers d'inventaire et permettant le traitement pour les clients précédemment touchés. Des relevés diagnostiques supplémentaires ont été effectués pour appuyer des recherches plus poussées. Cependant, un important arriéré de dossiers d'inventaire s'était accumulé pendant l'interruption et avait nécessité un délai supplémentaire pour le traitement. Après la restauration du traitement, les équipes techniques ont continué de surveiller les stocks et l'arriéré accumulé. Le vendredi 25 septembre 2026, vers 5 h 30 HAP, l'arriéré lié à l'incident était revenu à des niveaux d'exploitation normaux, confirmant le rétablissement du traitement des stocks. ** Cause de la mort** Cet incident a été causé par une interruption du processus de traitement des stocks à la suite de l ' activité de lancement de la production de l ' ITAM 2026R1.3 dans la région du Mouvement des pays non alignés. Bien que les fichiers d'inventaire aient été téléchargés avec succès et soient demeurés disponibles en stockage, la composante responsable du transfert de ces fichiers au traitement ITAM a cessé de transférer les données d'inventaire pour un sous-ensemble de clients. Par conséquent, les dossiers d'inventaire touchés n'ont pas été traités, ce qui a retardé les mises à jour. La question n'a pas touché tous les clients, car le traitement des stocks s'est poursuivi normalement pour d'autres organisations. L'enquête a mis en évidence des erreurs d'application et un comportement élevés indiquant que le composant de traitement affecté ne se rétablissait pas comme prévu. La condition technique précise responsable de l'interruption partielle est toujours à l'étude. Un redémarrage ciblé de la composante de service touchée a rétabli le traitement des stocks pour les clients touchés. L'arriéré accumulé a ensuite été traité, ce qui a permis aux mises à jour des stocks de revenir à des niveaux normaux. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. **Incident Enquête ouverte :** Les équipes techniques ont examiné les rapports sur les mises à jour tardives des inventaires touchant un sous-ensemble de clients dans la région du Mouvement des pays non alignés et ont examiné le déroulement du traitement des stocks pour déterminer la portée de la question. 2. **Interruption du traitement des stocks identifiée :** L'enquête a confirmé que les dossiers d'inventaire téléchargés étaient disponibles en entreposage, mais qu'ils n'étaient pas envoyés aux services de traitement pour les clients touchés. 3. **Reprise de la composante service :** Un redémarrage ciblé de la composante de service touchée a rétabli le transfert des fichiers d'inventaire et permis de reprendre le traitement pour les clients précédemment touchés. 4. **Logage diagnostique supplémentaire activé:** L'exploitation d'une autre partie a permis de saisir d'autres informations techniques et d'appuyer la poursuite des enquêtes sur l'interruption de traitement sous-jacente. 5. **Recovery Backlog de l'inventaire surveillé:** Les équipes techniques ont surveillé l'arriéré accumulé après la restauration du traitement et ont confirmé que les dossiers d'inventaire étaient traités avec succès. 6. ** Récupération de service validée :** Les équipes techniques ont confirmé que l'arriéré lié aux incidents était revenu au niveau normal d'exploitation au 25 septembre et que le traitement des stocks était demeuré stable. ** Mesures préventives à venir** À la suite de l'incident, nous avons effectué une rétrospective pour examiner la défaillance partielle du traitement de l'inventaire, l'architecture existante de livraison de l'inventaire, les renseignements diagnostiques disponibles et les possibilités d'améliorer la fiabilité du traitement et la visibilité de la défaillance. Les mesures correctives et les activités d'amélioration suivantes sont en cours : 1. **Amélioration de l'architecture de traitement des stocks :** Des travaux sont prévus pour simplifier l'intégration du traitement des stocks en permettant à ITAM de récupérer les fichiers d'inventaire téléchargés directement depuis la couche de stockage plutôt que de s'appuyer sur le service de transit intermédiaire existant. Ce changement éliminera une dépendance supplémentaire du processus de traitement et assurera un meilleur contrôle du traitement, de la gestion de l'arriéré, de la capacité et de la récupération. 2. **Diagnostic amélioré de l'échec :** L'enregistrement diagnostique et la télémétrie nécessaires pour saisir l'état de service pertinent lors d'une défaillance partielle de l'inventaire seront évalués et améliorés selon les besoins. Cela fournira de l'information technique améliorée pour appuyer la détermination de la cause racine si une condition similaire se rétablit.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 14:08 UTCinvestigating

   Description de l'incident: Nous enquêtons sur une question touchant un sous-ensemble de clients utilisant Flexera One IT Asset Management (ITAM) dans la région du NAM. Les clients touchés peuvent éprouver des problèmes de navigation, y compris les éléments de menu qui ne sont pas visibles dans l'interface ITAM, ce qui entraîne un accès limité à certaines fonctionnalités. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement cette question et s'emploient à restaurer la fonctionnalité complète. Nous continuerons de fournir des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 24 septembre 2026 à 15:44 UTCinvestigating

   Les équipes techniques continuent d'étudier la question touchant la gestion des biens informatiques Flexera One dans l'environnement de production du NAM. Les efforts actuels visent à déterminer où les échecs se produisent dans le flux de travail touché. Les équipes examinent le comportement de l'application, les processus de validation, les interactions de service, la télémétrie de la plate-forme et tout changement récent ou les conditions environnementales qui pourraient contribuer au problème. L'enquête est toujours en cours et d'autres mises à jour seront fournies à mesure que des renseignements supplémentaires seront disponibles.

3. 24 septembre 2026 à 17:48 UTCinvestigating

   Les équipes techniques ont fait des progrès en réduisant la portée de la question et se concentrent sur les éléments d'application liés au chargement des informations d'accès et de navigation des utilisateurs. Les résultats actuels indiquent que certaines demandes de ce processus ne sont pas remplies comme prévu, ce qui entraîne l'omission de charger des éléments de menu pour les utilisateurs touchés. Des travaux sont en cours pour déterminer la cause sous-jacente et valider les mesures correctives appropriées. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

4. 24 septembre 2026 à 18:39 UTCmonitoring

   Les équipes techniques observent actuellement un comportement de service stable et une réduction significative des erreurs associées à cet incident. Les fonctions d'application touchées fonctionnent normalement en fonction des données actuelles de télémétrie et de surveillance. Bien que la stabilité du service se soit améliorée, les équipes techniques continuent de surveiller étroitement l'environnement pour confirmer que la question ne se reproduise pas. L'enquête sur la cause sous-jacente se poursuit. Nous continuerons de surveiller et de fournir d'autres mises à jour à mesure que des renseignements supplémentaires seront disponibles.

5. 24 septembre 2026 à 20:33 UTCresolved

   Les équipes techniques ont confirmé que le service est demeuré stable et que la fonctionnalité de gestion des actifs de TI a été affectée fonctionne normalement. Au cours de l'enquête, les équipes techniques ont identifié les conditions de saturation de la connexion affectant les composants d'application responsables des fonctions d'accès et de navigation des utilisateurs. Ces conditions ont été observées pendant la fenêtre d'impact et ont coïncidé avec les défaillances subies par les utilisateurs touchés. La fonctionnalité de service a été récupérée, et la validation du client a confirmé que les pages ITAM et les éléments de menu étaient chargés avec succès. Après une période de surveillance sans récurrence de la question, l'incident est maintenant considéré résolu. Un examen détaillé de l'incident est en cours afin de valider davantage les facteurs contributifs et de déterminer toute autre mesure préventive.

6. 8 octobre 2026 à 11:23 UTCpostmortem

   **Description:** Flexera One – Gestion des actifs informatiques – NAM – Menu Éléments non chargés **Calendrier:** 24 septembre 2026, 5h27 PDT – 24 septembre 2026, 10h48 PDT **Résumé de l'incident** Le 24 septembre 2026, les clients utilisant Flexera One IT Asset Management \(ITAM\) dans la région de l'Amérique du Nord ont connu des problèmes intermittents en chargeant des éléments de menu d'application et en accédant à des parties de la fonctionnalité ITAM. Certains clients ont rencontré des menus partiellement chargés ou manquants, des messages d'erreur et un comportement d'application incohérent. Les équipes techniques ont étudié la question dans l'ensemble des services d'application et de soutien et ont identifié une utilisation anormale de la connexion dans les composants qui soutiennent la fonctionnalité ITAM. Au fur et à mesure que la capacité de connexion disponible s'épuise, certaines demandes d'application ne peuvent plus être remplies avec succès, ce qui entraîne des défaillances liées à l'authentification et empêche le chargement de parties de la fonctionnalité ITAM. Le service a commencé à récupérer vers 10h46 HAP, avant le déploiement du correctif. Les dernières erreurs d'application connexes ont été enregistrées à 10:48 AM PDT. Les équipes techniques ont continué à étudier la cause sous-jacente tout en surveillant l'environnement et en validant la fonctionnalité du client. L'analyse post-incident a indiqué que les services d'application sur les serveurs touchés avaient redémarré, libérant les connexions accumulées et permettant l'établissement de nouvelles connexions. Le correctif a ensuite été déployé comme mesure préventive pour traiter le comportement de la manipulation de connexion pendant que l'enquête sur la cause sous-jacente se poursuivait. Suite à la poursuite de la surveillance et de la validation des clients, les équipes techniques ont confirmé que la fonctionnalité ITAM était revenue à son fonctionnement normal. ** Cause de la mort** L'incident a été causé par un problème de gestion de la connexion introduit lors du lancement de la production ITAM 2026 R1.3. Un changement au flux d'authentification de l'application a provoqué la création de nouvelles connexions de service à plusieurs reprises plutôt que la réutilisation des connexions existantes. Au fil du temps, ces connexions ont accumulé et épuisé la capacité de connexion disponible dans les composants d'application touchés. Une fois cette capacité épuisée, de nouvelles demandes n'ont pu être établies avec succès. Cela a entraîné des défaillances liées à l'authentification et empêché des parties de la fonctionnalité ITAM de charger, causant des éléments de menu manquants, des messages d'erreurs et une perte intermittente d'accès pour les clients touchés. Un hotfix corrigeant ce comportement avait déjà été créé et était inclus dans le plan de déploiement avant le déploiement de Production. Le hotfix avait initialement été désigné pour l'environnement de validation parce que la production n'avait pas encore été améliorée. Il devait être appliqué à la production dans le cadre de la libération R1.3, mais il n'a pas été appliqué pendant le déploiement de la production. Par conséquent, la correction de la gestion de la connexion n'était pas en place lorsque la version est mise en service. **Mesures correctives** 1. Incident Investigation Initiated: Les équipes techniques ont étudié les erreurs d'application et la perte intermittente de la fonctionnalité ITAM pour déterminer la portée et la cause sous-jacente. 2. Saturation de connexion identifiée : L'analyse des composants d'application touchés a permis de déceler une accumulation anormale de connexion qui épuisait la capacité de connexion disponible et empêchait les nouvelles demandes d'application de remplir avec succès. 3. Hotfix correctif Confirmé : Les équipes techniques ont identifié le hotfix existant qui a corrigé le comportement de gestion de connexion en réutilisant les connexions de service plutôt que de créer de nouvelles connexions pour chaque demande. 4. Hotfix correctif déployé: Le hotfix a été déployé sur Production comme mesure préventive pour résoudre le problème de la gestion des connexions et empêcher l'accumulation de connexions. 5. Récupération de service Validé: Les équipes techniques ont continué à surveiller le comportement de l'application et valider la fonctionnalité du client après la récupération pour confirmer que les services ITAM étaient retournés à l'exploitation normale. ** Mesures préventives à venir** À la suite de l'incident, nous avons effectué une rétrospective pour examiner la cause technique, le processus de lancement et de déploiement à chaud, les capacités de surveillance et les facteurs qui ont contribué à l'impact du client. Les mesures suivantes ont été prises ou sont en cours de mise en œuvre : 1. Correction de la gestion des connexions : La modification corrective a été mise en place pour s'assurer que les connexions de service sont réutilisées de façon appropriée et pour empêcher l'accumulation de connexions d'épuiser les ressources d'application disponibles. 2. Validation du déploiement de la production : La correction de la gestion des connexions a été déployée et validée dans toutes les régions de production pour assurer une mise en œuvre cohérente. 3. Améliorations des processus de libération et de traitement à chaud: Les procédures de libération sont renforcées de sorte que les correctifs à chaud inclus dans les plans de déploiement de la libération sont systématiquement désignés pour le déploiement de la production, y compris les correctifs à chaud initialement créés ou validés avant la mise à niveau de l'environnement de production. 4. Examen du processus Hotfix: Nous évaluons les améliorations au processus Hotfix global afin de réduire la dépendance à l'égard des correctifs de production et de réduire encore le risque que les changements correctifs requis ne soient pas inclus dans les futurs rejets de production. 5. Surveillance améliorée de l'application : Des mesures supplémentaires de surveillance et d'alerte au niveau de l'application sont mises en place pour améliorer la détection précoce des défaillances intermittentes et des conditions anormales d'erreur avant qu'elles n'aient un impact plus large sur les clients.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 10:11 UTCinvestigating

   Description de l'incident : Nous avons relevé un problème touchant le traitement des stocks dans Flexera One IT Asset Management (ITAM) dans la région du NAM, qui touche un sous-ensemble de clients. Par conséquent, certains chargements d'inventaire ne sont pas traités avec succès, ce qui fait que les données d'inventaire affichées dans Flexera One ITAM sont retardées et ne reflètent pas l'inventaire le plus récent. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question afin d'identifier la cause sous-jacente et de mettre en œuvre une solution. Nous continuons de suivre de près la situation et fournirons d'autres mises à jour à mesure que l'enquête progressera.

2. 24 septembre 2026 à 12:27 UTCinvestigating

   Une enquête plus approfondie indique que la question semble être liée au service responsable du transfert des données d'inventaire à l'ITAM. Nos équipes techniques continuent d'étudier la question et s'efforcent de déterminer la cause sous-jacente et de déterminer les mesures correctives appropriées. Nous continuerons de fournir d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

3. 24 septembre 2026 à 14:32 UTCmonitoring

   Notre équipe a effectué des redémarrages ciblés, après quoi le traitement des fichiers d'inventaire a repris avec succès pour tous les clients touchés. Le traitement réussi a été validé au moyen de registres et de graphiques de surveillance. Nous continuerons de surveiller de près les services afin d'assurer la stabilité continue et de fournir d'autres mises à jour au fur et à mesure que des renseignements supplémentaires seront disponibles.

4. 24 septembre 2026 à 18:42 UTCmonitoring

   Nos équipes techniques continuent d'observer avec succès le traitement des dossiers d'inventaire et l'opération de service stable après les actions de récupération. La validation par la surveillance confirme que les dossiers d'inventaire touchés sont traités avec succès. La récupération backlog est en cours, les files d'attente de traitement des stocks continuant à diminuer au fur et à mesure que les fichiers sont traités. Les équipes techniques surveillent activement les progrès en matière de rétablissement et la santé globale des services, tandis que l'arriéré restant est éliminé. Nous continuerons de fournir des mises à jour à mesure que le rétablissement progressera.

5. 24 septembre 2026 à 20:32 UTCresolved

   Cet incident a été signalé par inadvertance comme résolu par une mise à jour destinée à un incident distinct. Le recouvrement du traitement des stocks est toujours sous surveillance à mesure que l ' arriéré continue de s ' accumuler. Les équipes techniques continuent d'observer avec succès le traitement des dossiers et le fonctionnement stable du service. Les mises à jour en cours sur le rétablissement et la surveillance de l'arriéré se poursuivront dans le cadre de l'incident nouvellement créé : https://status.flexera.com/incidents/vztp63wmxjjb Nous fournirons d'autres mises à jour à mesure que l'arriéré de recouvrement progresse et que la validation du recouvrement se poursuit.

6. 23 octobre 2026 à 17:25 UTCpostmortem

   **Description :** Flexera One - Gestion des biens de TI - NAM - Retards dans le traitement des stocks après l'activité de mainlevée de production **Calendrier:** 22 septembre 2026, 19 h 05 PDT - 25 septembre 2026, 5 h 30 PDT **Résumé de l'incident** Le 24 septembre 2026, les équipes techniques ont commencé à enquêter sur les rapports de mises à jour d'inventaire retardées touchant un sous-ensemble de clients utilisant Flexera One IT Asset Management \(ITAM\) dans la région de l'Amérique du Nord \(NAM\). Bien que les dossiers d'inventaire aient été téléchargés avec succès et soient demeurés disponibles, certains clients ont connu des retards dans le traitement de ces dossiers, ce qui a empêché que les renseignements les plus récents sur l'inventaire soient reflétés dans la demande. L'information sur l'état des balises affichée dans ITAM aurait également pu être dépassée pour les clients touchés. Le traitement des stocks s'est poursuivi normalement pour les autres clients. Le problème est survenu à la suite de l'activité de diffusion de la production ITAM 2026R1.3 le 22 septembre 2026. L'enquête a révélé une interruption du processus de transfert des fichiers d'inventaire téléchargés aux services de traitement des stocks de l'ITAM. Bien que les dossiers touchés demeurent disponibles en entreposage, ils n'étaient pas transmis pour traitement. Les équipes techniques ont également observé des erreurs d'application élevées au cours de l'enquête, bien que ces erreurs n'aient pas été établies de façon concluante comme cause de l'interruption. Les équipes techniques ont effectué un redémarrage ciblé de la composante de service touchée, rétablissant le transfert des fichiers d'inventaire et permettant le traitement pour les clients précédemment touchés. Des relevés diagnostiques supplémentaires ont été effectués pour appuyer des recherches plus poussées. Cependant, un important arriéré de dossiers d'inventaire s'était accumulé pendant l'interruption et avait nécessité un délai supplémentaire pour le traitement. Après la restauration du traitement, les équipes techniques ont continué de surveiller les stocks et l'arriéré accumulé. Le vendredi 25 septembre 2026, vers 5 h 30 HAP, l'arriéré lié à l'incident était revenu à des niveaux d'exploitation normaux, confirmant le rétablissement du traitement des stocks. ** Cause de la mort** Cet incident a été causé par une interruption du processus de traitement des stocks à la suite de l ' activité de lancement de la production de l ' ITAM 2026R1.3 dans la région du Mouvement des pays non alignés. Bien que les fichiers d'inventaire aient été téléchargés avec succès et soient demeurés disponibles en stockage, la composante responsable du transfert de ces fichiers au traitement ITAM a cessé de transférer les données d'inventaire pour un sous-ensemble de clients. Par conséquent, les dossiers d'inventaire touchés n'ont pas été traités, ce qui a retardé les mises à jour. La question n'a pas touché tous les clients, car le traitement des stocks s'est poursuivi normalement pour d'autres organisations. L'enquête a mis en évidence des erreurs d'application et un comportement élevés indiquant que le composant de traitement affecté ne se rétablissait pas comme prévu. La condition technique précise responsable de l'interruption partielle est toujours à l'étude. Un redémarrage ciblé de la composante de service touchée a rétabli le traitement des stocks pour les clients touchés. L'arriéré accumulé a ensuite été traité, ce qui a permis aux mises à jour des stocks de revenir à des niveaux normaux. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. **Incident Enquête ouverte :** Les équipes techniques ont examiné les rapports sur les mises à jour tardives des inventaires touchant un sous-ensemble de clients dans la région du Mouvement des pays non alignés et ont examiné le déroulement du traitement des stocks pour déterminer la portée de la question. 2. **Interruption du traitement des stocks identifiée :** L'enquête a confirmé que les dossiers d'inventaire téléchargés étaient disponibles en entreposage, mais qu'ils n'étaient pas envoyés aux services de traitement pour les clients touchés. 3. **Reprise de la composante service :** Un redémarrage ciblé de la composante de service touchée a rétabli le transfert des fichiers d'inventaire et permis de reprendre le traitement pour les clients précédemment touchés. 4. **Logage diagnostique supplémentaire activé:** L'exploitation d'une autre partie a permis de saisir d'autres informations techniques et d'appuyer la poursuite des enquêtes sur l'interruption de traitement sous-jacente. 5. **Recovery Backlog de l'inventaire surveillé:** Les équipes techniques ont surveillé l'arriéré accumulé après la restauration du traitement et ont confirmé que les dossiers d'inventaire étaient traités avec succès. 6. ** Récupération de service validée :** Les équipes techniques ont confirmé que l'arriéré lié aux incidents était revenu au niveau normal d'exploitation au 25 septembre et que le traitement des stocks était demeuré stable. ** Mesures préventives à venir** À la suite de l'incident, nous avons effectué une rétrospective pour examiner la défaillance partielle du traitement de l'inventaire, l'architecture existante de livraison de l'inventaire, les renseignements diagnostiques disponibles et les possibilités d'améliorer la fiabilité du traitement et la visibilité de la défaillance. Les mesures correctives et les activités d'amélioration suivantes sont en cours : 1. **Amélioration de l'architecture de traitement des stocks :** Des travaux sont prévus pour simplifier l'intégration du traitement des stocks en permettant à ITAM de récupérer les fichiers d'inventaire téléchargés directement depuis la couche de stockage plutôt que de s'appuyer sur le service de transit intermédiaire existant. Ce changement éliminera une dépendance supplémentaire du processus de traitement et assurera un meilleur contrôle du traitement, de la gestion de l'arriéré, de la capacité et de la récupération. 2. **Diagnostic amélioré de l'échec :** L'enregistrement diagnostique et la télémétrie nécessaires pour saisir l'état de service pertinent lors d'une défaillance partielle de l'inventaire seront évalués et améliorés selon les besoins. Cela fournira de l'information technique améliorée pour appuyer la détermination de la cause racine si une condition similaire se rétablit.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 10:05 UTCinvestigating

   Description de l'incident: Nous enquêtons actuellement sur une question touchant l'accès à nos services dans l'environnement de l'UE. Les clients de l'UE peuvent rencontrer des problèmes d'accès au service. Priorité: P1 Activité de restauration : Nos équipes techniques étudient activement la question en priorité et s'efforcent de rétablir le service normal le plus rapidement possible.

2. 23 septembre 2026 à 10:24 UTCmonitoring

   Les services ont été restaurés et l'accès fonctionne désormais comme prévu. Nos équipes surveillent de près la plateforme pour assurer une stabilité continue.

3. 23 septembre 2026 à 11:43 UTCresolved

   Nos équipes ont continué à surveiller la plateforme et n'ont observé aucune récurrence de la question. Cet incident est maintenant résolu. Nous poursuivrons notre enquête afin de déterminer la cause fondamentale sous-jacente et de déterminer les mesures correctives appropriées. De plus amples détails seront fournis dans le rapport post mortem.

4. 26 octobre 2026 à 10:40 UTCpostmortem

   **Description:** Flexera Un - UE - Accès non disponible **Cadre horaire:** * 24 septembre, 2026, 2:51 PDT au 24 septembre, 2026, 3:18 PDT * 25 septembre 2026, 3 h 50 au 25 septembre 2026, 4 h 30 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le 24 septembre 2026 à 2:51 PDT, les clients ont connu des défaillances de connexion lorsqu'ils ont tenté d'accéder à l'environnement Flexera One EU Production. L'enquête a confirmé la dégradation des services de gestion de l'identité et de l'accès de l'UE, qui ont empêché les clients d'accéder à la plateforme. L'enquête a mis en évidence une augmentation significative des connexions aux bases de données associées à une augmentation du trafic provenant d'une seule organisation. Une analyse plus approfondie a permis de déterminer que les demandes répétées en aval générées par d'autres services contribuaient également à l'augmentation de la charge sur les services d'authentification et de contrôle d'accès. À 3:18 AM PDT, la fonctionnalité de connexion du client a été restaurée sans intervention technique directe, et la plate-forme est revenue à un fonctionnement normal. Le 25 septembre 2026, vers 3h50 HAP, une autre augmentation des connexions à la base de données a été observée, associée à une augmentation du trafic de la même organisation. La charge accrue a continué pendant environ 40 minutes. En réponse, le service de gestion des ressources a pu augmenter la capacité et améliorer la stabilité des plateformes. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été causé par une augmentation inattendue du trafic qui a imposé une demande excessive aux services d'authentification de l'UE et aux connexions de bases de données associées. L'augmentation de la charge a affecté les services responsables du traitement des demandes d'authentification, entraînant des défaillances de connexion des clients dans l'environnement de production de l'UE. Les demandes répétées d'autres services aux services d'authentification et de contrôle d'accès ont également contribué à la charge élevée. En outre, le service de gestion des ressources n ' a pas pu être redimensionné automatiquement, ce qui l ' a empêché d ' accroître dynamiquement sa capacité en réponse à une demande accrue. Les lacunes dans la surveillance proactive et l'alerte ont également limité la capacité d'identifier la dégradation avant que les clients n'aient subi des défaillances d'accès. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) Nos équipes ont effectué les actions ci-dessous pour rétablir les services à la normale: * L'incident du 24 septembre résolu sans intervention d'ingénierie directe, et la fonctionnalité de connexion du client a été restaurée à 3:18 PDT. * Le 25 septembre, le service de gestion des ressources a pu augmenter sa capacité en réponse à une demande accrue. * L'équipe a continué de surveiller les connexions aux bases de données et la santé des services pour évaluer la stabilité de la plateforme. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) Les mesures suivantes ont été identifiées et sont en cours d'élaboration pour réduire la probabilité de récidive et améliorer la résilience des services : * Échelle automatique : Examiner la configuration de l'échelle automatique pour le service de gestion des ressources dans toutes les régions de production, afin de s'assurer que la capacité s'adapte aux changements dans la charge de travail. * Gestion des capacités de la base de données : Examiner les paramètres de la base de données et veiller à ce que l'échelle des services reste dans la capacité de connexion disponible de la base de données. * Surveillance et alerte proactives : Revoir et introduire des alertes pour la croissance anormale de la connexion à la base de données, la saturation du bassin de connexion, la latence de service, les taux d'erreur et l'utilisation des ressources. * Surveillance du trafic : améliorer la visibilité dans les modèles de trafic au niveau de l'organisation pour identifier les pics de demande inhabituels avant qu'ils n'affectent d'autres clients. * Gestion du trafic : Évaluer les contrôles appropriés de limitation des tarifs et de réduction du trafic afin d'éviter que le trafic excessif provenant d'une seule organisation n'affecte la disponibilité à l'échelle de la plate-forme. * Essais de charge et de capacité : Effectuer des essais de charge à l'aide de modèles de circulation représentatifs de l'incident pour valider la performance du service et la capacité de la base de données à la demande élevée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 06:51 UTCinvestigating

   Description de l'incident : Nous enquêtons actuellement sur une question touchant l'environnement de production de Flexera One IT Asset Management (ITAM) en Amérique du Nord, qui demeure indisponible en raison d'une maintenance planifiée dépassant la fenêtre de maintenance prévue. L'activité de maintenance est toujours en cours alors qu'une base de données est en cours de reconstruction. Priorité: P1 Activité de restauration : Nos équipes techniques s'emploient activement à terminer les activités de maintenance restantes et à rétablir le service le plus rapidement possible. L'ETA pour la reconstruction de la base de données est d'environ 2 Heures. Nos équipes suivent de près les progrès accomplis et fourniront d'autres détails dès qu'ils seront disponibles.

2. 23 septembre 2026 à 09:15 UTCinvestigating

   Nos équipes techniques ont terminé une phase majeure de l'activité de maintenance continue et poursuivent le traitement restant nécessaire pour terminer la mise à niveau. Le processus prend plus de temps que prévu. L'environnement demeure indisponible pendant que ces activités sont en cours. Les équipes surveillent activement les options de traitement et d'évaluation restantes pour rétablir le service le plus rapidement et en toute sécurité possible. D'autres mises à jour seront fournies à mesure que la mise à niveau progresse et que le calendrier de restauration devient plus clair.

3. 23 septembre 2026 à 11:47 UTCmonitoring

   La mise à niveau a été achevée avec succès. Nos équipes travaillent maintenant à restaurer les services et à effectuer la validation après déploiement.

4. 23 septembre 2026 à 13:02 UTCmonitoring

   La mise à niveau a été effectuée avec succès, et le site est maintenant de retour en ligne. Notre équipe effectue des vérifications de validation finales pour confirmer la stabilité du service avant de déclarer l'incident résolu.

5. 23 septembre 2026 à 15:57 UTCresolved

   Le service a été restauré et fonctionne normalement. Après le rétablissement, les équipes techniques ont mené des activités de surveillance et de validation étendues et ont confirmé leur stabilité. L'incident est maintenant considéré comme résolu.

6. 30 septembre 2026 à 16:02 UTCpostmortem

   **Description:** Flexera One – Gestion des biens informatiques – Amérique du Nord – Indisponibilité des services après 2026R1.3 Entretien **Calendrier:** 22 septembre 2026, 21:00 PDT – 23 septembre 2026, 5:47 PDT **Résumé de l'incident** Le 22 septembre 2026, Flexera a réalisé la sortie de production prévue de 2026R1.3 pour Flexera One IT Asset Management en Amérique du Nord. La mise à niveau a progressé avec succès dans la grande majorité des bases de données de l'environnement. Cependant, lorsque la fenêtre de maintenance prévue s'est terminée à 21h00 HAP, une opération de migration de la base de données requise est en cours. Étant donné que l'environnement de production n'a pu être rétabli que lorsque la migration a été achevée, IT Asset Management est demeurée indisponible au-delà de la période de maintenance prévue. La migration restante a nécessité une reconstruction importante de l'indice de base de données impliquant un volume important de données. L'opération est devenue le chemin critique pour terminer la libération et a pris beaucoup plus de temps que prévu. Après la phase initiale de traitement de l'index, la base de données devait encore effectuer des activités supplémentaires de tri et de création d'index. Ce travail s'est poursuivi pendant plusieurs heures et a prolongé la durée globale de la migration. Au cours de l'enquête, les équipes techniques ont évalué les options de récupération disponibles, notamment si la base de données touchée pouvait être temporairement séparée du chemin de migration afin de permettre au reste de l'environnement de retourner en service. En raison de l'étape du déploiement et des travaux de récupération supplémentaires qu'il aurait fallu entreprendre, la voie de récupération la plus fiable était de permettre à l'exploitation de la base de données de se terminer avant de restaurer l'environnement. Une fois la migration de la base de données terminée, les équipes techniques ont commencé à restaurer les services d'application et de soutien. Pendant le démarrage, un problème supplémentaire de récupération du service a été rencontré qui a nécessité une intervention manuelle avant que la restauration puisse se poursuivre. Après l'assainissement, les autres services d'application et de plateforme ont été restaurés avec succès. Les équipes techniques ont ensuite effectué des activités de validation, confirmé l'accès du client et effectué une surveillance étendue pour vérifier la stabilité du service. L'impact client s'est terminé le 23 septembre 2026, à 5h47 PDT. ** Cause de la mort** La panne a été causée par une anomalie de configuration de l'indice de base de données qui a été décelée lors de la migration de 2026R1.3, ce qui a entraîné une opération importante de reconstruction de l'indice qui a largement dépassé la fenêtre de maintenance prévue. Une enquête post-incident a permis de déterminer qu'un index dans la base de données touchée ne correspondait pas à la structure de base de données attendue par la version actuelle. L'index avait déjà été recréé à l'aide d'une définition plus ancienne qui n'incluait pas de modification ultérieure de la conception de la base de données. Au cours du déploiement de 2026R1.3, le processus de migration a identifié cette différence et lancé l'opération de base de données nécessaire pour aligner l'index sur la définition actuelle de la base de données. En raison de la taille exceptionnelle de l'ensemble de données en cause, la reconstruction qui en a résulté est devenue une opération à long terme et à forte intensité de ressources qui a largement dépassé le guichet d'entretien prévu. Une fois la reconstruction en cours, la durée de traitement restante n'a pu être prédite de façon fiable, ce qui a rendu difficile l'établissement d'une estimation précise de l'achèvement pendant que l'opération se poursuivait. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : * Reconstruction de l'indice Surveillé : Les activités de reconstruction de l'indice et de mise à niveau de la base de données ont été suivies en permanence jusqu'à leur achèvement. * Options de rétablissement évaluées : Les approches de restauration disponibles ont été évaluées afin de déterminer la voie la plus sûre et la plus fiable pour remettre l'environnement de production en service. * Mise à niveau de la base de données terminée : Les activités de reconstruction de l'index et de mise à niveau de la base de données restantes ont été terminées avant le début de la restauration de l'application. * Services d'application et de soutien restaurés : les services d'application et de soutien ont été rétablis. Des mesures de rétablissement ciblées ont été prises lorsqu'un problème supplémentaire de démarrage du service a été rencontré. * Récupération de service Validée : La fonctionnalité d'accès et d'application du client a été confirmée, le traitement des dossiers a été revu et une surveillance élargie a été effectuée pour vérifier la stabilité du fonctionnement. ** Mesures préventives à venir** Flexera reconnaît l'importance et la durée de cette panne et l'impact qu'elle a eu sur ses clients en Amérique du Nord. Une analyse complète des causes profondes et une rétrospective interfonctionnelle ont été réalisées, et les mesures préventives suivantes ont été identifiées dans le cadre des efforts d'amélioration continue : 1. Validation de la procédure de la base de données: Les équipes techniques évaluent la façon dont les procédures de restauration de la base de données sont examinées et maintenues afin de s'assurer qu'elles demeurent conformes aux exigences actuelles en matière de produits à mesure que la plateforme évolue. 2. Vérification préalable au déploiement : On évalue les processus de validation des rejets afin de déterminer comment les différences de configuration inattendues de la base de données peuvent être identifiées et évaluées avant le début de la maintenance de la production. 3. Évaluation des opérations à forte incidence : Les équipes techniques évaluent la façon dont les opérations de base de données à long terme ou à forte intensité de ressources peuvent être identifiées au cours de la préparation des libérations afin de mieux comprendre la durée prévue et l ' impact opérationnel avant leur déploiement. 4. Préparation à la mise en liberté et planification du rétablissement : Les pratiques de préparation à la mise en liberté et de planification du rétablissement sont en cours d'examen afin d'améliorer la visibilité des activités susceptibles d'avoir une incidence importante sur la durée du déploiement et les délais de rétablissement du service. Fournir des services fiables et résilients demeure une priorité. Les résultats de l'analyse et de la rétrospective des causes profondes sont intégrés aux améliorations techniques et opérationnelles visant à réduire la probabilité de récidive et à renforcer la planification et l'exécution des futures activités d'entretien.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 septembre 2026 à 05:56 UTCinvestigating

   Description de l'incident: Nous enquêtons actuellement sur un problème touchant un sous-ensemble de nos clients utilisant Snow Atlas dans la région de l'Australie. Les clients touchés peuvent avoir des retards dans la consultation des dernières informations informatiques et l'ingestion de données peut également être affectée. Priorité : P2 Activité de restauration : Un problème antérieur lié au DNS a été identifié et résolu. Cependant, d'autres erreurs sont maintenant observées. Nos équipes techniques enquêtent activement sur ces erreurs pour déterminer la cause sous-jacente et restaurer le traitement normal. Nous continuerons d'évaluer l'impact et de fournir d'autres mises à jour à mesure que des renseignements supplémentaires seront disponibles.

2. 22 septembre 2026 à 07:19 UTCinvestigating

   Nos équipes ont effectué des redémarrages ciblés, ce qui a amélioré les délais de traitement. La surveillance indique que les données d'inventaire sont maintenant mises à jour avec succès. Les erreurs restantes sont toujours à l'étude, et nos équipes s'efforcent d'identifier la cause sous-jacente et de mettre en œuvre une correction permanente.

3. 22 septembre 2026 à 10:15 UTCmonitoring

   Les mesures d'assainissement ont permis de résoudre les problèmes liés aux retards de traitement et à l'absence de données. Certains problèmes résiduels demeurent et sont actuellement à l'étude par nos équipes techniques. Les équipes surveillent les services et continueront de recueillir et d'examiner les registres au cours des 24 prochaines heures pour appuyer l'enquête. Nous continuerons de surveiller de près les services et de fournir d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

4. 23 septembre 2026 à 07:05 UTCresolved

   Nos équipes ont continué de surveiller les services du jour au lendemain et ont confirmé qu'aucun nouveau problème n'avait été observé. D'autres vérifications ponctuelles ont également été effectuées avec succès. Cet incident est en cours de règlement. De plus amples renseignements sur la cause profonde et les mesures prises seront fournis dans le rapport post mortem.

5. 13 octobre 2026 à 12:49 UTCpostmortem

   **Description :** Atlas des neiges - APAC - Délais d'ingestion et de traitement des données **Calendrier:** 21 septembre 2026, 17h48 PDT au 22 septembre 2026, 15h15 PDT (en milliers de dollars) **Résumé de l'incident** Le lundi 21 septembre 2026, à 17h48, un problème a touché plusieurs locataires de l'Atlas des neiges dans la région de l'Australie-Est \(AE\), ce qui a retardé les mises à jour des données d'inventaire. Les clients touchés avaient des informations obsolètes sur l'appareil sur la page Ordinateurs, tandis que Snow Extenders affichait un statut de "Running with Errors". Des erreurs ont également été observées lors de l'ingestion des données. L'enquête a permis d'identifier un dossier désuet du DNS associé à une infrastructure précédemment déclassée dans la région de l'Australie-Est. Ce dossier interfère avec la connectivité à l'environnement de l'Australie-Est, empêchant le traitement des données d'inventaire comme prévu. L'enregistrement DNS obsolète a été supprimé, permettant au trafic d'atteindre le bon point d'arrêt et permettant aux mises à jour de l'analyse d'inventaire de reprendre. À la suite du changement, les inventaires ont commencé à progresser et les états des services de connectivité touchés sont revenus à la normale le 22 septembre 2026, à 3 h 15 HAP. Après une longue période de surveillance du jour au lendemain, les services de connectivité sont restés stables, et la question a été déclarée résolue le 23 septembre à 12 h 05 PDT. Aucun autre problème n'a été signalé et l'infrastructure australienne du Sud-Est utilisée précédemment a été complètement déclassée. (en milliers de dollars) ** Cause de la mort** L'incident a été causé par un dossier de DNS dépassé qui est resté après le démantèlement des infrastructures dans la région de l'Australie-Sud. Ce record a orienté le trafic loin du bon point d'arrêt pour l'environnement Australie-Est, perturbant la connectivité nécessaire au traitement des données d'inventaire. Par conséquent, les mises à jour de l'inventaire ont été retardées et les clients touchés n'ont pas pu récupérer les dernières informations sur l'appareil. L'enregistrement périmé a été supprimé, ce qui a permis de rétablir la connectivité au bon point d'arrivée et de reprendre le traitement des stocks. (en milliers de dollars) **Mesures correctives** Nos équipes ont effectué les actions ci-dessous pour rétablir les services à la normale: * Identifié et retiré le dossier désuet DNS associé à l'infrastructure précédemment déclassée. * Restauré la connectivité au bon paramètre Australie-Est. * Vérifié que les mises à jour de l'inventaire et le dénombrement des stocks progressaient. * Surveillait l'environnement pour confirmer la stabilité du service. * Confirmé que les états du service de connectivité Snow sont revenus à la normale et qu'aucun autre problème n'a été signalé. (en milliers de dollars) ** Mesures préventives à venir** * Examiner le nettoyage des dossiers du DNS pendant le déclassement de l'infrastructure pour s'assurer que les dossiers périmés sont supprimés. * Améliorer les vérifications post-déclassement afin d'identifier les documents qui demeurent après l'enlèvement des ressources.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 septembre 2026 à 13:03 UTCinvestigating

   Description de l'incident: Nous enquêtons sur une question touchant le traitement des données d'inventaire dans les environnements de production de l'UE et de l'APAC. Les clients peuvent observer des retards dans les mises à jour des stocks, ce qui fait que les données d'inventaire ne reflètent pas l'activité d'importation la plus récente. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question, valident la portée de l'impact et travaillent avec les dépendances pertinentes pour rétablir le traitement normal des stocks. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 18 septembre 2026 à 13:50 UTCidentified

   Nos équipes techniques ont retracé la question à un déploiement récent et ont mis en œuvre des mesures de remise en état. La validation initiale indique que le traitement des stocks a repris et que les équipes techniques surveillent activement les activités de traitement et le recouvrement des arriérés. Nous continuons de valider la récupération dans les environnements touchés et fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

3. 18 septembre 2026 à 14:34 UTCidentified

   Les équipes techniques ont terminé les mises à jour de configuration requises et les données d'inventaire continuent d'être traitées avec succès. Des capacités de traitement supplémentaires ont été allouées pour accélérer le recouvrement des arriérés, et les équipes techniques surveillent activement le débit et la réduction des arriérés dans les environnements touchés. Les activités de rétablissement sont toujours en cours et d'autres mises à jour seront fournies à mesure que l'arriéré se poursuivra.

4. 18 septembre 2026 à 14:39 UTCmonitoring

   Le traitement des données d'inventaire continue de se rétablir et les équipes techniques observent une tendance à la baisse du volume des arriérés. Des capacités de traitement supplémentaires demeurent en place et les progrès en matière de rétablissement sont étroitement surveillés dans les environnements touchés. Nous continuerons de surveiller la réduction de l'arriéré et de fournir d'autres mises à jour à mesure que le rétablissement progressera.

5. 18 septembre 2026 à 18:52 UTCmonitoring

   Le traitement des données d'inventaire se poursuit à la suite de l'assainissement déjà mis en oeuvre. Les équipes techniques surveillent activement le débit de traitement et le rétablissement de l'arriéré dans les environnements touchés. Les équipes techniques continuent d'évaluer les progrès réalisés en matière de rétablissement et toute autre mesure qui pourrait aider à accélérer le traitement des arriérés. D'autres mises à jour seront fournies à mesure que le rétablissement progressera.

6. 18 septembre 2026 à 19:49 UTCmonitoring

   Le rétablissement de l'arriéré a été effectué dans le PPAC à la suite de l'assainissement déjà mis en oeuvre, et le traitement des données d'inventaire est revenu aux niveaux prévus dans la région. Les activités de redressement se poursuivent dans l'UE, où les équipes techniques surveillent le débit de traitement et la réduction de l'arriéré. D'autres mesures de recouvrement sont évaluées pour appuyer le traitement de l'arriéré à mesure que le recouvrement progresse.

7. 18 septembre 2026 à 21:55 UTCmonitoring

   Les efforts de redressement se poursuivent dans l'UE, et les équipes techniques observent la réduction continue de l'arriéré restant. D'autres optimisations de récupération ont été mises en œuvre pour soutenir le traitement des arriérés dans l'UE, et les équipes techniques continuent de suivre le débit et les progrès globaux de récupération. D'autres mises à jour seront fournies à mesure que les progrès se poursuivront.

8. 19 septembre 2026 à 11:07 UTCmonitoring

   Le redressement continue de progresser, l'arriéré restant diminuant régulièrement. D'autres optimisations mises en œuvre dans l'environnement de l'UE soutiennent efficacement le traitement des arriérés. Nos équipes continuent de suivre de près les progrès en matière de rétablissement et fourniront d'autres mises à jour au besoin.

9. 19 septembre 2026 à 19:09 UTCmonitoring

   Les efforts de redressement se poursuivent dans l'UE, et les équipes techniques observent une réduction continue de l'arriéré suite aux optimisations précédemment mises en œuvre. Compte tenu des tendances actuelles en matière de redressement, les niveaux d'arriéré ont été considérablement réduits et continuent de progresser dans la direction prévue. D'autres mises à jour seront fournies à mesure que les progrès se poursuivront.

10. 20 septembre 2026 à 19:55 UTCresolved

    Les équipes techniques ont confirmé que le traitement des données d'inventaire dans l'UE est revenu à la normale après la réhabilitation précédemment mise en œuvre. La question était liée à une question de configuration du déploiement touchant le traitement des données d'inventaire. Les mises à jour de configuration requises ont été appliquées, rétablissant le traitement normal. Après validation et suivi prolongé, le recouvrement de l'arriéré dans l'UE s'est achevé et le traitement des stocks demeure stable tant dans l'UE que dans l'APAC. Cet incident est maintenant considéré comme résolu.

11. 23 octobre 2026 à 17:20 UTCpostmortem

    **Description:** Flexera One - Gestion des actifs informatiques - EU & APAC - Retards dans le traitement des stocks à la suite d'un problème de configuration de déploiement **Calendrier:** 16 septembre 2026, 14:00 PDT - 20 septembre 2026, 9:52 PDT **Résumé de l'incident** Le vendredi 18 septembre 2026, les équipes techniques ont commencé à enquêter sur les rapports de mises à jour d'inventaire retardées touchant les clients de Flexera One IT Asset Management \(ITAM\) dans les régions Europe \(EU\) et Asie-Pacifique \(APAC\). La mise à jour des données d'inventaire n'était pas prise en compte dans la demande, certains clients ayant indiqué que leurs dernières données d'inventaire disponibles étaient toujours datées du 16 septembre. La question a affecté le traitement des stocks plutôt que la disponibilité générale de la plateforme ITAM. L'analyse initiale a révélé que les services de traitement des stocks semblaient sains, mais que les dossiers d'inventaire entrants ne progressaient pas dans le processus de traitement prévu. Une enquête plus approfondie a révélé l'interruption d'un déploiement effectué le 16 septembre, au cours duquel un problème de configuration a affecté les services chargés du traitement des données d'inventaire. Les équipes techniques ont identifié et corrigé la configuration de déploiement, ce qui permet de reprendre le traitement des stocks. Cependant, un important arriéré de dossiers d'inventaire s'était accumulé pendant l'interruption et avait nécessité un délai supplémentaire pour le traitement. Le traitement des stocks s'est d'abord rétabli dans l'APAC, où l'arriéré accumulé a été éliminé le 18 septembre à environ 12 h 21 PDT. La région de l'UE a eu besoin d'un délai de récupération supplémentaire en raison du volume de dossiers en suspens. Les équipes techniques ont ajusté la capacité de traitement et continué de surveiller l'arriéré au fur et à mesure que les dossiers d'inventaire étaient traités. Le reste de l'arriéré de l'UE a été entièrement éliminé le 20 septembre à environ 9h52 HAP. La surveillance subséquente a confirmé que le traitement des stocks était revenu à des niveaux d'exploitation normaux. ** Cause de la mort** L'incident a été causé par une question de configuration de déploiement introduite lors d'une mise à jour du 16 septembre aux services de traitement des stocks. Au moment du déploiement, l'infrastructure de traitement des stocks était en transition entre les environnements d'application, les différents services devant rester actifs dans chaque environnement selon la région. Cela a accru la complexité du maintien de la configuration de production correcte, et la configuration de service requise n'a pas été correctement maintenue pendant le déploiement. En conséquence, le processus de traitement des stocks a été interrompu dans les régions de l'UE et de l'APAC, ce qui a empêché le traitement des fichiers d'inventaire entrants et retardé la mise à jour des données d'inventaire. Une fois la configuration corrigée, le traitement de l'inventaire a repris, l'arriéré accumulé nécessitant un délai supplémentaire pour le traitement avant le rétablissement complet des niveaux d'exploitation normaux. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. **Incident Enquête ouverte :** Les équipes techniques ont examiné les rapports sur les mises à jour tardives des inventaires dans les régions de l'UE et de l'APAC et ont examiné le déroulement du traitement des stocks afin de déterminer la source de l'interruption. 2. **Configuration du détachement L'enquête a permis de retracer l'interruption du déploiement du 16 septembre et d'identifier une configuration de service incorrecte affectant le traitement des stocks dans les régions touchées. 3. ** Configuration de la production corrigée :** Les mises à jour de configuration requises ont été appliquées pour restaurer les services de traitement des stocks concernés, ce qui a permis aux fichiers d'inventaire entrants de reprendre le traitement. 4. **Inventory Backlog Recovery Initié :** Les équipes techniques ont surveillé les dossiers d'inventaire accumulés et ajusté les ressources de traitement disponibles pour appuyer le rétablissement de l'arriéré après la restauration du processus de traitement. 5. **Traitement du débit optimisé :** Au cours de la reprise de l'UE, les équipes techniques ont relevé des contraintes en matière de capacité de traitement en raison de l'augmentation de la charge de travail et de l'adaptation de la cohérence de traitement pour améliorer le débit tout en maintenant la stabilité des services. 6. ** Récupération de service validée :** Les équipes techniques ont confirmé que l'arriéré de l'APAC avait été réglé le 18 septembre, puis que l'arriéré de l'UE avait été complètement recouvré le 20 septembre. La surveillance continue a permis de vérifier que le traitement des stocks était revenu à des niveaux d'exploitation normaux. ** Mesures préventives à venir** À la suite de l'incident, nous avons effectué une rétrospective pour examiner la question de la configuration du déploiement, les différences entre les environnements d'application, les capacités de surveillance du traitement des stocks et les possibilités d'améliorer la validation du déploiement et la visibilité opérationnelle. Les mesures correctives et les activités d'amélioration suivantes ont été prises ou sont en cours : 1. **Gestion de la configuration des services régionaux :** Une liste de configuration de service régional a été mise en place pour documenter et maintenir les configurations de service requises dans les différents environnements de déploiement, réduisant ainsi le risque d'incohérences de configuration lors des futures versions. 2. ** Amélioration de la validation dudéploiement** Une liste de contrôle pour le déploiement a été mise en place pour vérifier que les services requis de traitement des stocks fonctionnent dans les environnements appropriés pendant les activités de déploiement. 3. **Surveillance améliorée du traitement des stocks :** D'autres activités de surveillance et d'alerte ont été mises en place pour détecter les interruptions du traitement des stocks plus tôt et accélérer les enquêtes et le recouvrement. 4. **Visibilité améliorée des erreurs de traitement :** Des tableaux de bord de surveillance ont été mis en place afin d'assurer une plus grande visibilité dans les modèles de réponse anormale aux demandes, y compris les erreurs liées à la capacité de traitement. Ces améliorations ont déjà permis une détection et une récupération plus précoces lors de problèmes de traitement subséquents. 5. ** Simplification de l ' environnement de production :** Les travaux en cours visant à consolider le modèle de déploiement permettront de réduire la complexité opérationnelle associée au maintien de différentes configurations de services dans les environnements et les régions, ce qui contribuera à réduire le risque d'interruptions de traitement semblables liées à la configuration.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 septembre 2026 à 09:04 UTCidentified

   Description de l'incident: Nous sommes actuellement confrontés à un problème affectant le site de la communauté Flexera. En raison d'une interruption continue affectant un fournisseur de services tiers, les clients peuvent être incapables d'accéder au portail communautaire Flexera ou avoir un comportement intermittent et peu fiable. En outre, les clients peuvent ne pas être en mesure de créer, de mettre à jour ou d'interagir avec les dossiers de soutien via le site communautaire. Les courriels envoyés à [email protected] pendant cette période ne peuvent être reçus ni traités tant que la panne sous-jacente n'a pas été résolue. Cette panne de fournisseur de services de tiers affecte également la capacité de surveillance proactive des équipes de soutien de Spot pour détecter tout problème d'environnement client avec un widget chatbot à l'intérieur de la console Spot. Priorité: P3 Activité de restauration : Nos équipes techniques surveillent activement la situation et travaillent avec le fournisseur tiers pour suivre les efforts de restauration. Nous continuerons d'évaluer l'impact client et de fournir d'autres mises à jour à mesure que des informations supplémentaires seront disponibles.

2. 16 septembre 2026 à 12:31 UTCidentified

   Le fournisseur de services a validé la correction avec succès dans un environnement d'essai et a commencé à la déployer dans toutes les instances touchées. Le déploiement progresse selon les régions, et les services reviennent à la normale dans les régions où le déploiement est terminé.

3. 16 septembre 2026 à 19:25 UTCmonitoring

   Notre fournisseur de services signale que la télémétrie des services est demeurée saine après le déploiement de l'atténuation. La communauté demeure accessible à l'heure actuelle, et aucun impact continu confirmé n'a été identifié. Nous continuerons de surveiller l'environnement afin d'assurer une stabilité continue pendant les activités de validation finales. Nous fournirons une nouvelle mise à jour à mesure que des renseignements supplémentaires seront disponibles.

4. 16 septembre 2026 à 22:00 UTCmonitoring

   Notre fournisseur de services a déclaré l'incident sous-jacent résolu après une atténuation réussie et une validation prolongée. La collectivité demeure accessible et aucun impact continu confirmé n'a été identifié. La surveillance tout au long de la période de rétablissement n'a relevé aucun autre problème. Cet incident est maintenant considéré comme résolu.

5. 17 septembre 2026 à 11:01 UTCresolved

   Nos équipes ont continué de surveiller le service tout au long de la période de récupération, et aucun autre problème n'a été observé. Compte tenu de la stabilité soutenue du service, cet incident est maintenant considéré comme résolu.

6. 30 septembre 2026 à 12:30 UTCpostmortem

   **Description:** Flexera Community- Service indisponible **Calendrier:** 16 septembre 2026, 12 h 50 PDT au 16 septembre 2026, 8 h 26 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le 16 septembre 2026, à 12h50, Flexera a identifié un problème affectant la disponibilité et la fiabilité du site communautaire Flexera en raison d'une panne affectant un prestataire de services externe soutenant la plateforme communautaire. Au cours de l'incident, les clients n'ont peut-être pas pu accéder à la Communauté Flexera, soulever ou gérer des cas de soutien ou recevoir des réponses aux cas existants par l'intermédiaire de la Communauté. Les courriels envoyés à [email protected] peuvent également avoir été retardés ou non pendant la panne. Le problème a également affecté la fonctionnalité chatbot dans la console Spot, qui dépend des services touchés. En outre, les pannes ont affecté les capacités de surveillance proactive utilisées par les équipes de Spot Support pour identifier certains problèmes d'environnement client qui dépendent des notifications de service. Par la suite, le fournisseur de services a validé un correctif et a commencé à le déployer dans les instances touchées, région par région. Au fur et à mesure que l'atténuation était déployée, les services revenaient progressivement à la normale. Après le déploiement, la télémétrie de service est demeurée saine dans tous les environnements orientés vers la clientèle. La validation a confirmé que la fonctionnalité de chatbot Flexera Community et Spot fonctionnait normalement. L'incident du fournisseur sous-jacent a ensuite été déclaré résolu, et Flexera a terminé la validation finale et a clos l'incident. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été causé par une panne affectant les services d'un fournisseur de services externe qui soutiennent la communauté Flexera et les fonctionnalités connexes. La perturbation du service a affecté la disponibilité et la fiabilité de la plate-forme communautaire et des intégrations connexes, ce qui a entraîné une perturbation temporaire de la fonctionnalité du dossier de soutien à la clientèle et des capacités Spot connexes. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Remise en état du fournisseur : Le fournisseur de services externe a validé et déployé une correction dans les cas touchés. * Validation du service : Les équipes de Flexera ont surveillé la communauté, la fonctionnalité du chatbot et les services connexes au moment du déploiement de la réhabilitation. * Surveillance du rétablissement : La santé et la fonctionnalité des services ont été surveillées pour confirmer la stabilité après l'assainissement. * Fermeture de l'incident : Après la résolution du problème du fournisseur sous-jacent et la validation de Flexera terminée, l'incident a été clos. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Surveillance améliorée de la dépendance : Continuer à surveiller les dépendances externes critiques qui soutiennent les services destinés aux clients. * Évaluation de l'impact client : Continuer d'évaluer l'impact des perturbations des services externes sur les services intégrés Flexera, y compris la collectivité, la gestion des cas de soutien et la fonctionnalité Spot. * Surveillance post-incident: Continuer la surveillance de l'impact résiduel de la clientèle après la restauration des services externes.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 septembre 2026 à 23:05 UTCinvestigating

   Description de l'incident: Nous enquêtons actuellement sur une question touchant les services de politiques et d'automatisation dans l'environnement de production de l'UE. Les clients de l'UE peuvent connaître des défaillances lors de l'utilisation des politiques et ne pas être en mesure de voir leurs politiques par l'intermédiaire de l'interface utilisateur. L'impact est limité à la région de l'UE. Priorité : P2 Activité de restauration : Nos équipes techniques ont été engagées et étudient activement un problème rencontré lors d'une modernisation de l'infrastructure afin d'identifier la cause sous-jacente et de rétablir le service normal le plus rapidement possible. D'autres mises à jour seront fournies à mesure que l'enquête progressera.

2. 16 septembre 2026 à 06:16 UTCmonitoring

   La question touchant l'environnement de l'UE a été résolue et l'accès à l'interface utilisateur a été entièrement rétabli. Bien que le service fonctionne maintenant normalement, il peut prendre un certain temps pour le travail en attente qui s'est accumulé pendant la panne à traiter. Nos équipes surveillent activement la reprise pour s'assurer que l'arriéré est réglé et que les services continuent de fonctionner comme prévu. Nous continuerons de surveiller de près l'environnement et de confirmer une fois que le traitement sera entièrement revenu à des niveaux normaux.

3. 16 septembre 2026 à 08:24 UTCresolved

   Nos équipes ont continué à surveiller de près le service, et aucun nouveau problème n'a été observé. L'arriéré de travaux en attente qui s'est accumulé pendant la perturbation est traité avec succès et continue de diminuer comme prévu. D'après la stabilité observée depuis le rétablissement, cet incident est maintenant résolu. Nous continuerons de surveiller le traitement afin de nous assurer que le reste de l'arriéré est complètement éliminé et que le service fonctionne comme prévu.

4. 12 octobre 2026 à 12:02 UTCpostmortem

   **Description:** Flexera - UE - Politiques/Automation Indisponible **Calendrier:** 15 septembre 2026, 15 h 50 PDT au 16 septembre 2026, 13 h 22 PDT (en milliers de dollars) **Résumé de l'incident** Le 15 septembre 2026, à 15h50 PDT, une modernisation de l'infrastructure soutenant l'automatisation dans l'environnement de production de l'UE a entraîné une perturbation de la connectivité réseau affectant les politiques et l'automatisation. Les clients ont éprouvé des difficultés à voir les politiques dans l'interface utilisateur, et les opérations liées à la politique ont échoué. L'enquête a identifié un comportement inattendu d'un composant de réseau ancien. Cela a perturbé la connectivité requise par les services touchés. L'équipe a identifié la composante concernée et a mis en ligne la ressource requise, rétablissant ainsi la connectivité du réseau. La question sous-jacente a été résolue le 15 septembre à 22h13 PDT. Par la suite, l'équipe a continué de surveiller le rétablissement des services et le traitement de l'arriéré accumulé pendant la perturbation. Une fois que le traitement de l'arriéré a progressé comme prévu et que la stabilité du service a été confirmée, l'incident a été déclaré entièrement rétabli le 16 septembre 2026, à 1 h 22. L'impact a été limité à l'environnement de production de l'UE. (en milliers de dollars) ** Cause de la mort** L'incident a été causé par un comportement inattendu de la part d'un composant de réseau existant lors de la modernisation de l'infrastructure d'automatisation dans la région de l'UE. Cette connectivité réseau perturbée requise par les politiques et l'automatisation, entraînant l'indisponibilité du service et des défaillances dans la fonctionnalité liée aux politiques. (en milliers de dollars) **Mesures correctives** Nos équipes ont effectué les actions ci-dessous pour rétablir les services à la normale: * Restauration de la connectivité : Identification de l'élément hérité et mise en ligne de la ressource requise pour restaurer la connectivité réseau. * Récupération du service : Rétablissement de la connectivité et règlement du problème sous-jacent touchant les politiques et l'automatisation. * Traitement des dossiers : Surveillance de l'arriéré accumulé lorsque le traitement a été récupéré après la restauration du service. * Validation postérieure à la restauration : a confirmé la stabilité du service et a vérifié que le traitement des arriérés progressait comme prévu avant de déclarer l'incident entièrement rétabli. (en milliers de dollars) ** Mesures préventives à venir** * Planification de la migration: La migration américaine correspondante a été reprogrammée avec une fenêtre de maintenance plus longue pour permettre un délai supplémentaire pour le dépannage et la récupération. * Remplacement de la composante héritée : La composante héritée est remplacée dans le cadre des efforts de modernisation de l'infrastructure. Une fois le remplacement terminé, cette dépendance spécifique de l'héritage devrait être éliminée dans tous les environnements.

Traduit automatiquement depuis la mise à jour officielle de l'incident.