Störungsverlauf von Flexera

1. 27. Oktober 2026 um 17:00 UTCidentified

   Incident Description: Wir untersuchen Verzögerungen bei der Aktualisierung von Technopedia-Inhalten. Technopedia-Inhalte, die von Data Platform, IT Visibility und API-Diensten verwendet werden, wurden seit dem 22. Oktober aufgrund wiederholter Datenverarbeitungsfehler nicht aktualisiert. Kunden können daher veraltete Technopedia-Inhalte in betroffenen Diensten sehen. Priorität: P2 Wiederherstellungsaktivität: Unsere technischen Teams haben Wiederherstellungsmaßnahmen durchgeführt, um die Datenverarbeitungsfehler zu beheben, und den zugrunde liegenden Inhalt aktualisiert. Die Erstellung von Katalogen ist derzeit im Gange, und wir überwachen diese Aktivität bis zum Abschluss. Wir werden ein weiteres update zur verfügung stellen, wenn die wiederherstellung fortschreitet.

2. 28. Oktober 2026 um 01:44 UTCidentified

   Die Aktualisierung der Technopedia-Inhalte ist noch nicht abgeschlossen. Unsere technischen Teams überwachen die Aktualisierung weiterhin bis zur Fertigstellung. Sobald die Verarbeitung abgeschlossen ist, werden wir bestätigen, dass aktualisierte Technopedia-Inhalte für die betroffenen Dienste verfügbar sind, um sicherzustellen, dass die normalen Aktualisierungsvorgänge wiederhergestellt wurden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Oktober 2026 um 07:05 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem mit Auswirkungen auf die Snow Atlas SAM Core-Funktionalität in der britischen Region South. Einige Kunden können Probleme beim Zugriff auf die Benutzerfunktionalität haben und beim Zugriff auf Computerdetails auf Fehler stoßen. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams untersuchen aktiv das Problem und bewerten den Umfang der Auswirkungen. Wir arbeiten daran, die zugrunde liegende Ursache zu identifizieren und die betroffene Funktionalität wiederherzustellen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 22. Oktober 2026 um 07:21 UTCmonitoring

   Unsere technischen Teams identifizierten Timeout-Fehler bei Servicekomponenten, die die betroffene Funktionalität unterstützen, und führten gezielte Service-Neustarts durch. Nach diesen Wiederherstellungsaktionen reagiert die Funktionalität Benutzer und Computerdetails während der Validierung erfolgreich. Wir überwachen weiterhin das Serviceverhalten und führen eine endgültige Validierung durch, um eine nachhaltige Stabilität zu bestätigen.

3. 22. Oktober 2026 um 07:38 UTCresolved

   Nach den zuvor implementierten Wiederherstellungsmaßnahmen haben unsere technischen Teams zusätzliche Validierung und Überwachung abgeschlossen. Die Funktionalität von Benutzern und Computerdetails ist stabil geblieben, ohne dass weitere Probleme beobachtet wurden. Der normale Betrieb wurde bestätigt, und dieser Vorfall gilt nun als behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 22:37 UTCresolved

   Vorfallbeschreibung: Nach der geplanten Veröffentlichung der Flexera One IT Asset Management 2026R1.4-Produktion in der Region Australien haben wir ein Problem mit den Flexera One IT Asset Management Services in APAC festgestellt. Infolgedessen konnten die Kunden während des Impact-Zeitraums nicht auf Flexera One IT Asset Management zugreifen. Priorität: P1 Impact Start: 15. Oktober 2026 um 11:34 Uhr PDT Impact End: 15. Oktober 2026 um 12:32 Uhr PDT Restaurierungsaktivität: Unsere technischen Teams haben nach der geplanten Veröffentlichung der Produktion ein Problem mit Servicekomponenten festgestellt. Die betroffenen Komponenten wurden saniert, um die Verfügbarkeit des Dienstes wiederherzustellen. Nach der Wiederherstellung kehrten die Flexera One IT Asset Management Services in APAC zum normalen Betrieb zurück, und das Problem gilt nun als gelöst.

2. 21. Oktober 2026 um 23:40 UTCpostmortem

   **Beschreibung:** Flexera One - IT Asset Management - APAC - Service Nichtverfügbarkeit nach 2026R1.4 Freigabe **Zeitrahmen:** 15. Oktober 2026, 11:34 Uhr PDT - 15. Oktober 2026, 12:32 Uhr PDT ## Incident Summary Am 15. Oktober 2026 erlebten Kunden, die Flexera One IT Asset Management in der APAC-Region nutzten, eine Serviceunterbrechung, die den Zugriff auf die Anwendung verhinderte. Die Störung trat nach Abschluss der Produktionsfreigabe ITAM 2026R1.4 auf. Obwohl Dienste ursprünglich verfügbar waren und nach der Veröffentlichung normal funktionierten, wurde die Anwendung später unzugänglich. Technische Teams untersuchten die Störung und identifizierten Ausfälle, die die Initialisierung von Anwendungsinstanzen beeinflussten. Weitere Untersuchungen ergaben, dass die Produktionsumgebung eine Abhängigkeit von einem früheren Anwendungsinitialisierungsprozess beibehielt, während ein Übergang zu einem aktualisierten Prozess im Gange war. Obwohl die Anwendungsinstanzen während des Releases erfolgreich initialisiert wurden, waren Ersatzinstanzen aufgrund einer veralteten Konfiguration nicht in der Lage, den gleichen Prozess abzuschließen. Die betroffenen Ersatzinstanzen waren nicht in der Lage, die Initialisierung erfolgreich abzuschließen oder die erforderlichen Gesundheitskontrollen zu bestehen, was die Rückkehr der Anwendung in den normalen Betrieb verhinderte. Die technischen Teams korrigierten die Produktionskonfiguration, um auf den aktualisierten Initialisierungsprozess zu verweisen, und führten eine Instanzaktualisierung durch. Nach diesen Änderungen wurden die betroffenen Instanzen erfolgreich initialisiert und die Verfügbarkeit des ITAM-Services wurde um ca. 12:32 Uhr PDT wiederhergestellt. ## Wurzelursache Der Vorfall wurde durch eine verbleibende Produktionsabhängigkeit von einem vorherigen Anwendungsinitialisierungsprozess während des Übergangs zu einem aktualisierten Prozess in der APAC-Produktionsumgebung verursacht. Während Staging- und Benutzerakzeptanz-Testumgebungen bereits auf den aktualisierten Prozess umgestellt waren, behielt die APAC-Produktionsumgebung eine Konfiguration bei, die auf den vorherigen Initialisierungsprozess Bezug nahm. Während der Produktionsfreigabe 2026R1.4 wurden Anwendungsinstanzen mit dem aktualisierten Prozess manuell initialisiert, so dass ITAM trotz der verbleibenden Produktionsabhängigkeit zunächst normal arbeiten konnte. Komponenten, die den vorherigen Prozess unterstützten, wurden anschließend unter der Voraussetzung verkleinert, dass der breitere Übergang weitgehend abgeschlossen war. Als Ersatzanwendungsinstanzen gestartet wurden, leitete die Produktionskonfiguration sie weiter an den vorherigen Initialisierungsprozess. Die betroffenen Instanzen waren daher nicht in der Lage, die Initialisierung erfolgreich abzuschließen oder die erforderlichen Gesundheitskontrollen zu bestehen, was zu einer Unterbrechung des Dienstes führte. Die verbleibende Produktionsabhängigkeit vom vorherigen Initialisierungsprozess wurde als Grund für den Vorfall bestätigt. Durch die Korrektur der Produktionskonfiguration zur Verwendung des aktualisierten Initialisierungsprozesses wurde diese Abhängigkeit beseitigt und die erfolgreiche Initialisierung von Ersatzinstanzen ermöglicht. ## Sanierungsmaßnahmen Während der Incident Response wurden folgende Maßnahmen ergriffen: **Incident Investigation Initiiert:** Die technischen Teams untersuchten die Nichtverfügbarkeit der Anwendung und identifizierten Fehler, die sich auf die Initialisierung und die Zustandsprüfung von Anwendungsinstanzen in der APAC-Produktionsumgebung auswirkten. 2. **Konfigurationsproblem identifiziert:** Die Untersuchung ergab, dass die Produktionskonfiguration weiterhin den vorherigen Anwendungsinitialisierungsprozess anstelle des aktualisierten Prozesses referenzierte. 3. **Produktionskonfiguration korrigiert:** Die Produktionskonfiguration wurde aktualisiert, um auf den korrekten Anwendungsinitialisierungsprozess zu verweisen, wodurch die Abhängigkeit vom vorherigen Prozess beseitigt wurde. 4. **Anwendungsinstanzen aktualisiert:** Die technischen Teams führten nach der Konfigurationskorrektur eine Instanzaktualisierung durch, so dass Ersatzinstanzen erfolgreich initialisiert werden konnten. 5. **Service Recovery Validiert:** Die technischen Teams bestätigten, dass die betroffenen Instanzen erfolgreich initialisiert wurden, die Gesundheitschecks der Anwendung bestanden und die ITAM-Dienste in den Normalbetrieb zurückgekehrt waren. ## Künftige Präventivmaßnahmen Nach dem Vorfall wurde eine Retrospektive durchgeführt, um den Anwendungsinitialisierungsprozess, die verbleibenden Produktionsabhängigkeiten, Release-Validierungsverfahren und Möglichkeiten zur Verbesserung der Vorfallerkennung und -reaktion zu überprüfen. Die folgenden Korrekturmaßnahmen und Verbesserungsmaßnahmen wurden abgeschlossen oder sind im Gange: 1. **Produktionskonfigurationskorrektur:** Die APAC-Produktionsumgebung wurde aktualisiert, um den korrekten Anwendungsinitialisierungsprozess zu verwenden und die vorherige Konfiguration zu ersetzen. 2. **Validierung der Vermächtnisabhängigkeit:** Es wurde eine Folgemaßnahme eingerichtet, um einen Validierungsschritt hinzuzufügen, bevor ältere Plattformkomponenten verkleinert oder stillgelegt werden, um sicherzustellen, dass die Produktionsdienste vollständig umgestellt wurden und keine verbleibenden Abhängigkeiten von der vorherigen Plattform bestehen. 3. **Freigabe und Anwendung Health-Check Review: ** Bestehende Anwendungsgesundheitskontrollen, Freigabe-Validierungsverfahren und die Abdeckung des Sanitätstests nach der Freigabe werden gegen den Fehler überprüft, der während dieses Vorfalls beobachtet wurde. Bei der Überprüfung wird festgestellt, ob Deckungslücken bestehen und ob zusätzliche Überwachung, Validierung oder andere Verbesserungen erforderlich sind. 4. **Instance Scaling Investigation:** Wir werden weiterhin untersuchen, was die ursprünglichen Anwendungsinstanzen nach der Veröffentlichung zur Skalierung veranlasst hat, und feststellen, ob zusätzliche Korrektur- oder Präventivmaßnahmen erforderlich sind. 5. ** Verbesserung der Kundenkommunikation:** Wir haben eine Gelegenheit für eine zeitnahere Kundenkommunikation während dieses Vorfalls identifiziert. Unsere etablierten Eskalations- und Kommunikationspraktiken für Vorfälle sind darauf ausgelegt, eine proaktive Kundenbenachrichtigung zu gewährleisten, wenn ungeplante Auswirkungen auf den Service erkannt werden. Das Lernen aus diesem Vorfall wurde in unsere laufenden Incident-Response-Praktiken integriert, um sicherzustellen, dass diese Verfahren konsistent angewendet werden und dass Kunden bei Serviceunterbrechungen zeitnahe, proaktive Updates bereitgestellt werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 10:59 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das den Lizenzdienst innerhalb von SAM Core betrifft. Benutzer können möglicherweise keine Lizenzinformationen laden und beim Zugriff auf die Funktionalität des Lizenzdienstes auf Fehlermeldungen stoßen. Das Problem wurde in Süd- und Westeuropa bestätigt, und technische Teams bewerten derzeit den vollen Umfang der Auswirkungen. Priorität: P2 Restaurierungsaktivität: Technische Teams untersuchen aktiv das Problem und überprüfen den betroffenen Service. Zusätzliche Validierung ist im Gange, um den vollen Umfang der Auswirkungen zu bestimmen und den normalen Servicebetrieb wiederherzustellen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 8. Oktober 2026 um 11:30 UTCmonitoring

   Wir haben festgestellt, dass das Problem mit einer kürzlichen Bereitstellung zusammenhängt, die den Lizenzdienst betrifft. Korrekturänderungen wurden implementiert und die Servicefunktionalität wurde wiederhergestellt. Wir validieren derzeit den Gesundheitszustand des Dienstes und überwachen die Umwelt, um eine anhaltende Stabilität zu gewährleisten. Weitere Aktualisierungen werden bereitgestellt, sobald die zusätzliche Validierung abgeschlossen ist.

3. 8. Oktober 2026 um 12:11 UTCresolved

   Nach der Validierung und einem Überwachungszeitraum ist der Dienst stabil geblieben und die Lizenzfunktionalität wird in den betroffenen Regionen erfolgreich geladen. Das Problem gilt nun als gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 00:08 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das die Vertragsfunktionalität in Snow Atlas für Kunden in Australien betrifft. Kunden können beim Zugriff auf die Registerkarte Vereinbarungen fehlende oder nicht verfügbare Daten feststellen, und Datenaktualisierungsvorgänge können fehlschlagen. Priorität: P2 Restaurierungsaktivität: Technische Teams untersuchen aktiv das Problem und bewerten das Ausmaß der Auswirkungen auf den Kunden. Es wird daran gearbeitet, die Ursache des Problems zu identifizieren und die normale Funktionalität wiederherzustellen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 8. Oktober 2026 um 01:39 UTCresolved

   Weitere Untersuchungen ergaben ein Kommunikationsproblem, das einen Backend-Service zur Unterstützung der Agreements-Funktionalität in Snow Atlas Australia betrifft. Die technischen Teams implementierten Wiederherstellungsmaßnahmen, einschließlich des Neustarts der betroffenen Servicekomponenten, wodurch die Kommunikation und der normale Betrieb wiederhergestellt wurden. Die Funktionalität wurde in mehreren Kundenumgebungen validiert, und die Vertragsdaten werden jetzt korrekt angezeigt. Wir haben keine weiteren Probleme nach Wiederherstellungs- und Validierungsaktivitäten beobachtet. Das Problem gilt nun als gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 20:27 UTCinvestigating

   Vorfallbeschreibung: Wir untersuchen Berichte über intermittierende Probleme, die Ocean Kubernetes-Kunden betreffen. Einige Kunden haben gemeldet, dass sie Benachrichtigungen bezüglich der Konnektivität zwischen Ocean Kubernetes-Komponenten und ihren Clustern erhalten haben. Technische Teams untersuchen aktiv den Umfang der Auswirkungen und die damit verbundene Verschlechterung des Service. Priorität: P2 Wiederherstellungsaktivität: Unsere technischen Teams untersuchen aktiv das gemeldete Verhalten, überprüfen Kundenberichte und validieren den Umfang und die Auswirkungen in den betroffenen Umgebungen. Wir werden zusätzliche Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 7. Oktober 2026 um 22:23 UTCinvestigating

   Wir untersuchen weiterhin die zuvor gemeldeten intermittierenden Verbindungsprobleme. Zu diesem Zeitpunkt wurden seit dem ursprünglichen Aufprallfenster keine zusätzlichen Ereignisse beobachtet. Technische Teams überprüfen aktiv die verfügbaren Telemetrie- und Untersuchungsergebnisse, um die zugrunde liegende Ursache zu bestimmen und den Gesamtumfang der Auswirkungen zu validieren. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

3. 8. Oktober 2026 um 00:03 UTCinvestigating

   Wir haben seit dem ursprünglich gemeldeten Aufprallfenster keine zusätzlichen Ereignisse beobachtet, und die Servicestabilität wurde beibehalten. Technische Teams untersuchen weiterhin die zugrunde liegende Ursache der heute gemeldeten intermittierenden Verbindungsprobleme.

4. 8. Oktober 2026 um 00:04 UTCmonitoring

   Basierend auf der anhaltenden Stabilität, die seit dem ursprünglich gemeldeten Aufprallfenster beobachtet wurde, und dem Fehlen zusätzlicher gemeldeter Ereignisse, verschieben wir diesen Vorfall auf Monitoring. Technische Teams untersuchen weiterhin die zugrunde liegende Ursache, während die Servicestabilität überwacht wird. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

5. 8. Oktober 2026 um 02:24 UTCresolved

   Wir haben seit den ursprünglich gemeldeten Auswirkungen keine zusätzlichen Ereignisse beobachtet und die Servicestabilität wurde beibehalten. Die technischen Teams haben eine zusätzliche Untersuchung der heute gemeldeten intermittierenden Verbindungsprobleme abgeschlossen. Mehrere mögliche Korrelationen wurden während der Untersuchung überprüft, und die endgültige Analyse steht noch aus. Basierend auf der beobachteten anhaltenden Stabilität und dem Fehlen einer Wiederholung gilt dieser Vorfall nun als gelöst. Die technischen Teams werden weiterhin Überwachungs- und Untersuchungsaktivitäten durchführen, um das während des gemeldeten Aufprallfensters beobachtete Verhalten besser zu verstehen, und nach Abschluss der Analyse wird ein formeller RCA-Bericht bereitgestellt.

6. 20. Oktober 2026 um 17:50 UTCpostmortem

   **Beschreibung:** Spot Ocean - Kubernetes - Intermittent Controller Connectivity Issues **Zeitrahmen:** 7. Oktober 2026, 11:20 Uhr PDT - 12:30 Uhr PDT **Incident Summary** Am Mittwoch, den 7. Oktober 2026, um 11:20 Uhr PDT erlebten mehrere Spot Ocean für Kubernetes-Umgebungen intermittierende Controller-Konnektivitätswarnungen. Während des Vorfalls interpretierte die Plattform Controller-Herzschlaginformationen vorübergehend als veraltet und setzte Skalierungsvorgänge für betroffene Cluster als Sicherheitsmaßnahme aus. Die betroffenen Controller meldeten während des Vorfalls weiterhin Herzschlaginformationen. Der Zeitstempel zur Validierung der Controller-Konnektivität wurde jedoch innerhalb einer Datenbankkomponente veraltet, wodurch aktive Controller vorübergehend nicht mehr reagieren. Das Verhalten war intermittierend, und aktuelle Herzschlaginformationen wurden anschließend ohne manuelles Eingreifen verfügbar, so dass normale Skalierungsvorgänge wieder aufgenommen werden konnten. Technische Teams überprüften den Controller-Herzschlag-Verarbeitungspfad, das Datenbankverhalten, die Service-Telemetrie und die damit verbundenen Infrastruktursignale, um festzustellen, warum gültige Herzschlag-Aktivität als veraltet interpretiert wurde. Nach dem Ereignisfenster wurden keine weiteren Ereignisse beobachtet. Nach kontinuierlicher Überwachung und Validierung der Servicestabilität wurde der Vorfall als behoben betrachtet. **Wurzelursache** Der Vorfall wurde dadurch verursacht, dass ein älterer Controller-Herzschlag-Zeitstempel einen neueren gültigen Zeitstempel innerhalb einer Datenbankkomponente überschrieben hat. Obwohl die betroffenen Controller weiterhin normal über Herzschläge berichteten, ließ der veraltete Zeitstempel den zuletzt gespeicherten Herzschlag älter erscheinen als er war. Als die Plattform diesen Zeitstempel auswertete, überschritt sie die konfigurierte Herzschlagschwelle und löste einen Sicherheitsmechanismus aus, der die Skalierungsvorgänge für die betroffenen Cluster vorübergehend aussetzte. Die spezifische Bedingung, die die ältere Datenbankaktualisierung verzögert hat, wurde nicht abschließend festgelegt. Der Datenbankaktualisierungsprozess enthielt jedoch keine Sicherheit, um zu verhindern, dass ein älterer Herzschlag-Zeitstempel einen neueren gültigen Zeitstempel ersetzt. Dies ermöglichte verzögerte Herzschlaginformationen, um den Anschein zu erzeugen, dass aktiv berichtende Controller nicht reagierten. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: 1. Kundenberichte und Serviceverhalten überprüft: Technische Teams überprüften die gemeldeten Beispiele, um das Verhalten zu bestätigen, das Wirkungsfenster festzulegen und festzustellen, ob das Problem isoliert war oder mehrere Umgebungen betraf. 2. Controller Heartbeat Activity Validated: Die Controller-Aktivität wurde überprüft, um festzustellen, ob die betroffenen Controller die Berichterstattung eingestellt hatten. Die Untersuchung bestätigte, dass während des Vorfalls weiterhin Herzschlaginformationen gesendet wurden. 3. Heartbeat Processing Path Investigated: Technische Teams verfolgten, wie Herzschlaginformationen generiert, gespeichert und ausgewertet wurden, um festzustellen, wo die aktuelle Herzschlagaktivität als veraltet interpretiert wurde. Datenbank und Service Health Assessed: Relevante Datenbankleistung, Serviceverhalten und Infrastrukturtelemetrie wurden überprüft, um mögliche Verarbeitungsverzögerungen zu bewerten und eine breitere Plattforminstabilität auszuschließen. 5. Timestamp Regression identifiziert: Die Untersuchung ergab, dass ein älterer Herzschlag-Zeitstempel einen neueren gültigen Zeitstempel überschrieben hatte, was dazu führte, dass die Plattform den Herzschlag vorübergehend als veraltet interpretierte. 6. Service Stability Validated: Die technischen Teams überwachten nach der Wiederherstellung weiter. Es wurden keine zusätzlichen Vorkommnisse beobachtet und die Skalierungsoperationen blieben stabil, bevor der Vorfall abgeschlossen wurde. ** Künftige Präventivmaßnahmen** Die folgenden Verbesserungen sind geplant, um die Herzschlagverarbeitung zu stärken und die Erkennung ähnlicher Bedingungen zu verbessern: 1. Heartbeat Timetamp Schutz: Der Datenbankaktualisierungsprozess wird geändert, um zu verhindern, dass ein älterer Herzschlag-Zeitstempel einen neueren gültigen Zeitstempel überschreibt. 2. Verbesserte Diagnoseprotokollierung: Zusätzliche Protokollierung wird rund um Heartbeat-Updates eingeführt, um die Quelle jedes Updates, den relevanten Anforderungskontext, frühere und neue Zeitstempelwerte und die Quelle des Zeitstempels zu erfassen. 3. Überwachung und Alarmierung: Neue Überwachung und Alarmierung werden unter Verwendung der zusätzlichen diagnostischen Informationen entwickelt, um Zeitstempel-Regressionen und ähnliche Herzschlag-Verarbeitungsbedingungen schneller zu identifizieren. 4. Datenbankzugriffsprüfung: Datenbankzugriffsmuster, die mit der Herzschlagverarbeitung verbunden sind, werden überprüft, um Möglichkeiten zur Verringerung von Verarbeitungsverzögerungen und zur Optimierung der Leistung bei erhöhter Belastung zu ermitteln.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 11:08 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das den Ereignisbenachrichtigungsdienst in mehreren Produktionsumgebungen betrifft. Kunden können Verzögerungen oder Ausfälle auftreten, wenn sie v2-Ereignisbenachrichtigungen erhalten, einschließlich Benachrichtigungen, die per E-Mail, Webhooks, Slack und anderen unterstützten Kanälen gesendet werden. Ereignisse werden weiterhin aufgezeichnet und bleiben über die Flexera One Konsole und API zugänglich. Es gibt derzeit keinen Hinweis darauf, dass die Funktionalität der Kernplattform oder Ereignisdaten betroffen sind. Priorität: P3 Wiederherstellungsaktivität: Unsere technischen Teams haben das Problem identifiziert und Service-Recovery-Aktionen implementiert. Die Überwachung zeigt, dass die Fehlerquoten sinken und die Teams weiterhin die Servicestabilität validieren und den vollen Umfang der Auswirkungen bewerten. Weitere Updates werden bereitgestellt, wenn die Untersuchungs- und Wiederherstellungsbemühungen voranschreiten. Update: Weitere Untersuchungen bestätigten, dass dieses Problem keine Auswirkungen auf die Kunden hatte. Die betroffenen Meldungen sollten nicht veröffentlicht werden.

2. 29. September 2026 um 11:53 UTCresolved

   Nach einer genauen Überwachung der Dienste zur Bestätigung der Stabilität beobachteten unsere Teams keine weiteren Fehler oder Wiederholungen des Problems. Dieser Vorfall ist nun gelöst.

3. 13. Oktober 2026 um 04:42 UTCpostmortem

   **Beschreibung:** Spot by Flexera - Fehler bei der Verarbeitung von Ereignismeldungen **Zeitrahmen:** 29. September 2026, 2:06 Uhr PDT - 4:51 Uhr PDT **Incident Summary** Am 29. September 2026 identifizierte Flexera erhöhte Anwendungsfehler innerhalb einer Benachrichtigungsverarbeitungskomponente, die für die Handhabung bestimmter Ereignisbenachrichtigungsworkflows verantwortlich ist. Die automatisierte Überwachung erkannte eine erhöhte Fehleraktivität und veranlasste eine Untersuchung, um festzustellen, ob kundenbezogene Benachrichtigungen betroffen waren. Während der Untersuchung identifizierten die technischen Teams Fehler innerhalb eines Benachrichtigungsverarbeitungspfads und führten eine detaillierte Bewertung der betroffenen Ereignisse, Benachrichtigungsworkflows und potenziellen Kundenauswirkungen durch. Erste Analysen deuteten darauf hin, dass das Problem die Benachrichtigungsverarbeitung möglicherweise breiter beeinflussen könnte, und es wurde ein schwerer Vorfall gemeldet, während der Umfang und die Auswirkungen validiert wurden. Eine weitere Folgenabschätzung bestätigte, dass die betroffenen Meldungen nicht für die Veröffentlichung an die Kunden gedacht waren. Die Ereignisinformationen wurden weiterhin erfolgreich aufgezeichnet und blieben während der gesamten Untersuchung über die Plattform verfügbar. Keine kundenorientierte Funktionalität wurde gestört, keine Ereignisdaten gingen verloren und es wurden keine Kundenauswirkungen als Folge dieses Problems identifiziert. Basierend auf den Ergebnissen der Folgenabschätzung wurde die Incident-Priorität herabgestuft und die Untersuchung abgeschlossen, nachdem die Validierung bestätigt hatte, dass kundenorientierte Dienste nicht betroffen waren. **Wurzelursache** Die Untersuchung ergab, dass ein Benachrichtigungsverarbeitungsworkflow auf eine Anwendungsausnahme stieß, während er eine Teilmenge intern generierter Ereignisse behandelte. Diese Ereignisse wurden so konfiguriert, dass sie nicht für die Zustellung von Kundenbenachrichtigungen vorgesehen waren. Obwohl die Ausnahmen zu erhöhten Anwendungsfehlern führten und eine Untersuchung rechtfertigten, bestätigte die anschließende Analyse, dass die betroffenen Anmeldungen nicht an die Kunden verteilt werden sollten. Infolgedessen wurden die Benachrichtigungsbereitstellung, die Plattformfunktionalität und der Zugang zu Ereignisinformationen nicht beeinträchtigt. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: Initiiert: Technische Teams untersuchten erhöhte Anwendungsfehler, die durch automatisierte Überwachung erkannt wurden, und bewerteten potenzielle Kundenauswirkungen. 2. Analyse der Benachrichtigungsverarbeitung: Der betroffene Benachrichtigungsworkflow wurde überprüft, um die Quelle der Anwendungsausnahmen zu ermitteln und den Umfang des Problems zu bestimmen. 3. Customer Impact Assessment abgeschlossen: Technische Teams validierten die betroffenen Benachrichtigungstypen, überprüften das Verhalten der Ereignisveröffentlichung und bestätigten, dass die betreffenden Benachrichtigungen nicht für die Lieferung durch den Kunden bestimmt waren. 4. Durchführung von Systemvalidierung und -überwachung: Fehlertrends, Serviceverhalten und Benachrichtigungsverarbeitung wurden überwacht, um einen stabilen Betrieb zu bestätigen und zu bestätigen, dass kundenorientierte Dienste nicht betroffen sind. 5. Incident-Neuklassifizierung abgeschlossen: Nach der Bestätigung, dass keine Auswirkungen auf den Kunden bestanden, wurde die Incident-Priorität herabgestuft und der Incident formell behoben. ** Künftige Präventivmaßnahmen** Im Anschluss an diese Untersuchung identifizierten wir Möglichkeiten, die Geschwindigkeit und Genauigkeit der Folgenabschätzung zu verbessern, wenn Betriebswarnungen interne Verarbeitungsabläufe beinhalten. 1. Verbesserte Folgenabschätzung: Überprüfung interner Benachrichtigungsklassifikationen und Untersuchungsverfahren, um schneller festzustellen, ob ein Problem die Kundenfunktionalität bei zukünftigen Vorfällen beeinflusst. 2. Erweiterte Sichtbarkeit des Benachrichtigungs-Workflows: Verbesserung der operativen Sichtbarkeit von Benachrichtigungsverarbeitungspfaden, die auf den Kunden und nicht auf den Kunden ausgerichtet sind, um eine schnellere Wirkungsvalidierung und Reaktion auf Vorfälle zu unterstützen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. September 2026 um 09:10 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem mit Auswirkungen auf die IT-Sichtbarkeit in der APAC-Region, in der Power BI-Dashboards nicht geladen werden können. Kunden in der betroffenen Region können möglicherweise nicht auf die Reporting-Dashboards innerhalb der Anwendung zugreifen. Die aktuelle Untersuchung zeigt, dass das Problem auf die APAC-Region beschränkt ist, wobei derzeit keine Auswirkungen in anderen Regionen beobachtet werden. Priorität: P2 Wiederherstellungsaktivität: Unsere technischen Teams untersuchen das Problem aktiv, um die zugrunde liegende Ursache zu identifizieren und die Berichtsfunktionalität wiederherzustellen. Wir bewerten weiterhin den Umfang der Auswirkungen, überwachen den Zustand des Dienstes und setzen gegebenenfalls Korrekturmaßnahmen um. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 28. September 2026 um 09:26 UTCresolved

   Das Problem mit Power BI Reporting Dashboards in der APAC-Region wurde behoben. Erste Untersuchungen zeigen, dass nach einem kürzlichen Upgrade ein Konfigurationsupdate erforderlich war. Unsere technischen Teams haben die notwendigen Abhilfemaßnahmen abgeschlossen und die anschließende Validierung bestätigt, dass die betroffenen Dashboards jetzt zugänglich sind und wie erwartet funktionieren. Alle Dienste sind zum normalen Betrieb zurückgekehrt, und dieser Vorfall gilt nun als behoben.

3. 26. Oktober 2026 um 12:10 UTCpostmortem

   **Beschreibung:** Flexera One- IT Visibility- APAC - Reporting Dashboards nicht verfügbar **Zeitrahmen:** 28. September 2026, 1:38 Uhr PDT bis 28. September 2026, 2:15 Uhr PDT **Incident Summary** Am Montag, den 28. September 2026, um 1:38 Uhr PDT, identifizierte Flexera ein Problem, das den Zugriff auf Power BI Reporting Dashboards für Kunden in der APAC-Region beeinflusste. Unsere technischen Teams wurden umgehend engagiert und die erste Untersuchung bestätigte, dass die Auswirkungen auf APAC beschränkt waren, während die anderen Regionen reagierten. Weitere Untersuchungen ergaben, dass Konfigurationsänderungen im Zusammenhang mit einer geplanten Identitäts- und Zugriffsmanagement-Migration die von den Berichtsdiensten erforderlichen Verbindungseinstellungen beeinflusst hatten. Während der Anwendung dieser Änderungen wurden die Verbindungseinstellungen der Berichtsdienste auf Werte zurückgesetzt, die nicht die vollständigen für eine erfolgreiche Kommunikation erforderlichen Dienstadressen enthielten. Folglich konnten die betroffenen Dienste nicht korrekt gestartet werden, was dazu führte, dass Power BI Reporting Dashboards für APAC-Kunden nicht verfügbar waren. Um den Service wiederherzustellen, korrigierte das technische Team die betroffenen Verbindungseinstellungen in der APAC-Umgebung manuell. Dadurch wurde die Kommunikation zwischen den Berichts- und Authentifizierungsdiensten wiederhergestellt, so dass die betroffenen Dienste wiederhergestellt werden können. Nach der Wiederherstellung bestätigte die Validierung, dass die Power BI Reporting Dashboards zugänglich waren und normal bei etwa 2:15 Uhr PDT betrieben wurden. **Wurzelursache** Der Vorfall wurde durch falsche Verbindungseinstellungen in der APAC-Umgebung während einer Konfigurationsänderung im Zusammenhang mit der Migration des Identitäts- und Zugriffsmanagements verursacht. Die Änderung setzt die Verbindungsadressen der Meldedienste auf Werte zurück, die nicht die vollständigen Adressen enthielten, die für eine erfolgreiche Kommunikation mit den Authentifizierungsdiensten erforderlich sind. Infolgedessen konnten die betroffenen Reporting-Dienste nicht richtig starten, so dass Power BI-Reporting-Dashboards für Kunden in der APAC-Region nicht verfügbar waren. Beitragende Faktoren * Konfigurationsinkonsistenz: Die erforderlichen Verbindungsadressen wurden zuvor direkt in der Umgebung aktualisiert, aber nicht in der Bereitstellungskonfiguration berücksichtigt. Folglich führte die nachfolgende Konfigurationsänderung die falschen Werte wieder ein. * Lücke bei der Bereitstellungsvalidierung: Der Bereitstellungsprozess hat die falschen Verbindungseinstellungen nicht identifiziert, bevor sie die Verfügbarkeit des Dienstes beeinträchtigt haben. * Änderungskoordination und Abhängigkeitsvalidierung: Der Migrationsprozess berücksichtigte die Konfigurationsanforderungen aller abhängigen Dienste nicht vollständig, was dazu führte, dass Endpunktänderungen ohne vorherige Validierung in den betroffenen Dienstabhängigkeiten angewendet wurden. **Abhilfemaßnahmen** Unsere Teams führten die folgenden Aktionen durch, um die Dienste wieder normal zu machen: * Die betroffenen Verbindungseinstellungen wurden korrigiert, um die Kommunikation zwischen den Berichts- und Authentifizierungsdiensten wiederherzustellen. * Die betroffenen Dienste wurden wiederhergestellt und die Validierung bestätigte, dass Power BI Reporting Dashboards zugänglich waren und normal funktionierten. * Die Konfiguration wurde anschließend korrigiert, um sicherzustellen, dass die erforderlichen Verbindungseinstellungen für zukünftige Bereitstellungen konsistent beibehalten werden. ** Künftige Präventivmaßnahmen** Die folgenden Maßnahmen wurden identifiziert und werden derzeit bearbeitet, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern und die Widerstandsfähigkeit des Dienstes zu verbessern: Konfigurationsmanagement: Stellen Sie sicher, dass Änderungen der Servicekonfiguration konsistent verwaltet werden, um Diskrepanzen zwischen bereitgestellten Einstellungen und gepflegten Konfigurationen zu vermeiden. Bereitstellungsvalidierung: Überprüfen Sie geplante Konfigurationsänderungen vor der Bereitstellung, um sicherzustellen, dass die erforderlichen Serviceverbindungseinstellungen korrekt bleiben. Konfigurationskonsistenz: Stellen Sie sicher, dass kritische Verbindungseinstellungen in den entsprechenden Konfigurationsquellen beibehalten werden und nicht von manuellen Änderungen einzelner Umgebungen abhängen. * Änderungskoordination: Verbesserung der Koordination für geplante Migrationen und Konfigurationsänderungen, einschließlich der Validierung der Anforderungen und Abhängigkeiten der betroffenen Dienste. * Bereitstellungsschutzmaßnahmen: Verbessern Sie die Überprüfungen vor der Bereitstellung, um falsche Konfigurationseinstellungen zu identifizieren, bevor sie zu Dienstausfällen führen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. September 2026 um 23:18 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das bestimmte IT Asset Management-Integrations- und App Portal-Dienste in allen Regionen betrifft. Kunden, die betroffene API-basierte Integrationen verwenden, können Authentifizierungsfehler auftreten, die zu HTTP 401 Nicht autorisierten Fehlern führen, die den erfolgreichen Abschluss von Anfragen verhindern können. App Portal-Benutzer können auch Fehler beim Einreichen von Anfragen auftreten. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams untersuchen das Problem aktiv und bewerten Korrekturmaßnahmen. Die Untersuchungs- und Validierungsaktivitäten sind im Gange und wir arbeiten daran, die normale Servicefunktionalität so schnell wie möglich wiederherzustellen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 26. September 2026 um 05:31 UTCidentified

   Der korrigierte Hotfix steht derzeit vor dem Abschluss des Build-Prozesses, der länger dauert als erwartet. Sobald der Build abgeschlossen ist, werden unsere technischen Teams mit der UAT-Validierung fortfahren, bevor sie mit der Bereitstellung der Produktion fortfahren. Das Team arbeitet auch daran, den Bereitstellungsplan, das Eigentum und den erwarteten Zeitplan zu bestätigen. Weitere Aktualisierungen werden bereitgestellt, wenn diese Aktivitäten fortschreiten.

3. 26. September 2026 um 12:30 UTCmonitoring

   Unsere Teams haben erfolgreich einen Hotfix implementiert, und die erste Validierung bestätigt, dass die Dienste wie erwartet funktionieren. Wir beobachten die Umwelt weiterhin genau und warten auf die Bestätigung durch betroffene Kunden.

4. 27. September 2026 um 05:39 UTCmonitoring

   Die APIs arbeiten wie erwartet und die zuvor beobachteten Fehler werden nicht mehr erkannt. Der Vorfall bleibt im Monitoring, während eine zusätzliche Validierung abgeschlossen und eine Kundenbestätigung eingeholt wird.

5. 28. September 2026 um 17:14 UTCresolved

   Nach den am Wochenende abgeschlossenen Sanierungsmaßnahmen haben wir die betroffenen Dienste weiter überwacht, um eine nachhaltige Stabilität und Erholung zu validieren. Die Kundenvalidierung wurde nun erhalten und bestätigt, dass die App-Portal-Funktionalität und die API-Anfrageverarbeitung normal funktionieren. Weitere Untersuchungen identifizierten ein Problem, das die Authentifizierungsverarbeitung innerhalb einer Dienstkomponente beeinflusste, was zu HTTP 401 Nicht autorisierten Fehlern bei betroffenen API-Anfragen und Fehlern beim Senden von Anfragen über das App-Portal führte. Unsere technischen Teams implementierten Korrekturmaßnahmen, um das Problem zu beheben, und führten eine zusätzliche Validierung durch, nachdem sie ein separates Problem identifiziert und behoben hatten, das während des Sanierungsprozesses aufgetreten war. Nach der Sanierung und erweiterten Überwachung sind die Dienste stabil geblieben, ohne dass weitere Probleme beobachtet wurden. Eine vollständige Ursachenanalyse wird durchgeführt und ein Bericht nach dem Vorfall wird geteilt, in dem die Ursache, die Sanierungsaktivitäten und die als Teil der Untersuchung identifizierten Korrekturmaßnahmen detailliert beschrieben werden.

6. 8. Oktober 2026 um 11:25 UTCpostmortem

   **Beschreibung:** Flexera One – IT Asset Management – All Regions – App Portal Errors und API Request Failures **Zeitrahmen:** 24. September 2026, 12:12 Uhr PDT – 26. September 2026, 4:38 Uhr PDT **Incident Summary** Ab dem 24. September 2026, um ca. 12:12 Uhr PDT, erlebten Kunden, die API-basierte Integrationen mit Flexera One IT Asset Management (ITAM) verwendeten, Authentifizierungsfehler, die HTTP 401 Nicht autorisierte Antworten zurückgaben. App-Portal-Benutzer sind auch bei der Übermittlung von Anfragen auf Fehler gestoßen, und Integrationen wie App Broker und Business Adapter, die auf diesen APIs basieren, waren betroffen. Die Auswirkungen wurden in den Regionen Nordamerika, Europa und Asien-Pazifik beobachtet. Technische Teams untersuchten und bestätigten, dass die Fehler nicht mit den Kundendaten oder der Kundenkonfiguration zusammenhingen. Anwendungsprotokolle zeigten, dass die Komponenten, die zur Authentifizierung dieser Anforderungen erforderlich waren, nicht initialisiert wurden. Weitere Untersuchungen ergaben, dass das Verhalten durch einen Hotfix eingeführt wurde, der als vorbeugende Maßnahme während der Reaktion auf den früheren ITAM-Menüladevorfall am 24. September eingesetzt wurde. Technische Teams reproduzierten das Verhalten beim Testen, entwickelten eine Korrekturlösung und validierten es. Während der Validierung des Einsatzes wurde ein Problem beim Laden von sekundären Komponenten identifiziert und durch einen aktualisierten Hotfix behoben. Nach der Bereitstellung des aktualisierten Hotfixes in der Produktion bestätigten die technischen Teams, dass die API-Funktionalität wie erwartet funktionierte, und der Service wurde am 26. September um ca. 4:38 Uhr PDT wiederhergestellt. Der Vorfall wechselte dann zu einer erweiterten Überwachung, während die Kundenbestätigung erhalten wurde und die Bestätigung am 28. September einging. Nach der Wiederherstellung des Dienstes wurden isolierte intermittierende Authentifizierungsfehler gemeldet und getrennt vom Hauptvorfall untersucht. Die technischen Teams identifizierten zusätzliche Verbindungshandling- und umgebungsspezifische Konfigurationsbedingungen und setzten weitere Hotfixes ein, die bis zum 30. September validiert wurden. Die fortgesetzte Überwachung und Kundenüberprüfung bis zum 1. Oktober bestätigte, dass das Problem nicht mehr reproduziert werden konnte und dass keine weiteren Ereignisse beobachtet wurden. **Wurzelursache** Der Vorfall wurde durch einen Defekt in einem Hotfix verursacht, der als vorbeugende Maßnahme während der Reaktion auf den früheren ITAM-Menüladevorfall am 24. September eingesetzt wurde. Der Hotfix entfernte eine Abhängigkeit von den Authentifizierungskomponenten der Anwendung und änderte, wie die Anwendung die Konfiguration liest, die sie zur Verbindung mit Authentifizierungsdiensten verwendet. Die erforderlichen Einstellungen waren in der bereitgestellten Konfiguration vorhanden. Die Anwendung versuchte jedoch, sie mit einer Methode zu lesen, die für die zur Laufzeit geladene Konfiguration nicht unterstützt wird. Infolgedessen konnten die für die Authentifizierung erforderlichen Komponenten nicht initialisiert werden, und Anforderungen, die eine Authentifizierung erforderten, wurden als nicht autorisiert abgelehnt. Dies führte zu API-Fehlern und Anforderungsfehlern im App Portal, die Kunden erlebten. Das gleiche Verhalten trat in der Vorproduktionsvalidierungsumgebung auf, als der Hotfix dort angewendet wurde. Es wurde nicht identifiziert, bevor der Hotfix die Produktion erreichte, da die betroffenen APIs in dieser Umgebung nicht aktiv verwendet werden und eine spezifische Fehlerwarnung für sie noch nicht vorhanden war. Der anfängliche Fix behebt den primären Konfigurationsfehler. Während der anschließenden Validierung und Überwachung wurden zusätzliche Bedingungen für das Laden von Komponenten, das Verbindungshandling und die umgebungsspezifische Konfiguration identifiziert und weitere Hotfixes erforderlich, bevor eine nachhaltige Stabilität bestätigt werden konnte. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: Initiiert: Technische Teams begannen mit der Untersuchung, nachdem Kunden Authentifizierungsfehler und API-Fehler gemeldet hatten. 2. Bewertung des Umfangs und der Kundenkonfiguration: Technische Teams bestätigten, dass die Fehler nicht mit den Kundendaten oder der Konfiguration zusammenhingen, und bestätigten, dass sich die Auswirkungen auf mehrere Regionen erstreckten. 3. Basisbedingung identifiziert: Technische Teams stellten fest, dass die erforderlichen Authentifizierungseinstellungen vorhanden waren, aber nicht zur Laufzeit gelesen werden konnten, und reproduzierten das Verhalten beim Testen. 4. Korrekturkorrektur entwickelt und validiert: Der Anwendungscode wurde aktualisiert, um die Einstellungen mit einer unterstützten Methode zu lesen. Validierungstests bestätigten, dass die Authentifizierungsfehler nicht mehr aufgetreten sind. 5. Deployed und Service Restored: Ein während der Validierung des Deployments identifiziertes Problem beim Laden von sekundären Komponenten wurde durch einen aktualisierten Hotfix behoben. Nachdem der aktualisierte Hotfix in der Produktion bereitgestellt wurde, verifizierten die technischen Teams, dass die API-Funktionalität wie erwartet funktionierte. 6. Erweiterte Überwachung und Kundenvalidierung: Technische Teams überwachten das Serviceverhalten während des Wochenendes und erhielten eine Bestätigung von einem betroffenen Kunden. 7. Mängelbeseitigung nach Zwischenfällen: Nachdem einzelne intermittierende Fehler nach der Wiederherstellung des Dienstes gemeldet wurden, setzten die technischen Teams weitere Hotfixes ein und validierten sie bis zum 30. September. Die Überwachung und Kundenüberprüfung wurde bis zum 1. Oktober fortgesetzt, um zu bestätigen, dass das Problem nicht mehr aufgetreten ist. ** Künftige Präventivmaßnahmen** Nach dem Vorfall führten wir eine Retrospektive durch, um die technische Ursache, den Hotfix-Validierungsprozess, die Überwachungsfähigkeiten und Faktoren, die zu den Auswirkungen des Kunden beigetragen haben, zu überprüfen. Folgende Maßnahmen wurden abgeschlossen oder werden derzeit durchgeführt: 1. Korrektur der Laufzeitkonfiguration: Die Anwendung wurde korrigiert, um ihre Authentifizierungskonfiguration mit einer unterstützten Methode zu lesen, und zusätzliche Hotfixes wurden in Produktionsumgebungen bereitgestellt und validiert. 2. API-Überwachung und Alarmierung: Für die betroffenen APIs wird eine Fehlerratenwarnung hinzugefügt, so dass Authentifizierungsfehler sowohl in Vorproduktions- als auch in Produktionsumgebungen erkannt werden, auch wenn der Dienst nicht aktiv genutzt wird. 3. Hotfix-Validierungsverfahren: Wir prüfen zusätzliche Prüfungen abhängiger Dienste wie API-Integrationen und App-Portal-Funktionalität im Rahmen der Hotfix-Validierung, bevor Änderungen für die Produktion genehmigt werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. September 2026 um 16:19 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das eine Teilmenge von Flexera One IT Asset Management-Kunden betrifft. Betroffene Kunden können fehlende Inventardaten oder leere Ergebnisse beim Zugriff auf die Gesamtinventaransicht und die zugehörigen inventarbasierten Ansichten feststellen. Die Emission ist auf eine Untergruppe von Kunden in Nordamerika beschränkt. Priorität: P2 Restaurierungsaktivität: Technische Teams untersuchen aktiv das Problem und überprüfen die Arbeitsabläufe der Bestandsdatenverarbeitung, die mit der betroffenen Funktionalität verbunden sind. Der Umfang der Auswirkungen wird validiert, während Minderungs- und Wiederherstellungsoptionen bewertet werden. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 25. September 2026 um 18:50 UTCidentified

   Technische Teams haben eine wahrscheinliche Ursache für das Problem identifiziert, das mit einer kürzlichen Änderung der Fähigkeitsstufe verbunden ist, die sich auf die Verarbeitung von Bestandsdaten auswirkt. Wiederherstellungsaktivitäten sind im Gange, einschließlich Rollback- und Korrekturmaßnahmen zur Wiederherstellung der normalen Bestandsdatenverarbeitung. Technische Teams arbeiten aktiv an der Sanierung und Validierung der Wiederherstellung für betroffene Kunden. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

3. 25. September 2026 um 21:22 UTCidentified

   Die technischen Teams arbeiten weiterhin an den mit dem Problem verbundenen Sanierungsmaßnahmen und führen aktiv Wiederherstellungsmaßnahmen durch, um die normale Bestandsdatenverarbeitung wiederherzustellen. Während der Ausführung stießen die Teams auf zusätzliche Bedingungen, die Anpassungen des Sanierungsansatzes erforderten, und aktualisierte Wiederherstellungsaktivitäten sind derzeit im Gange. Technische Teams bleiben aktiv und arbeiten kontinuierlich daran, die Sanierung abzuschließen und den normalen Service für betroffene Kunden so schnell wie möglich wiederherzustellen. Wir schätzen Ihre Geduld, während diese Bemühungen weitergehen und entschuldigen uns für die anhaltenden Auswirkungen. Weitere Aktualisierungen werden bereitgestellt, wenn bedeutende Fortschritte erzielt werden.

4. 26. September 2026 um 00:55 UTCidentified

   Die technischen Teams arbeiten weiterhin an den mit dem Problem verbundenen Sanierungsmaßnahmen und führen aktiv Rollback- und Korrekturmaßnahmen durch, um die normale Bestandsdatenverarbeitung wiederherzustellen. Recovery-Aktivitäten bleiben im Gange, und technische Teams überwachen aktiv die Ausführung, während die Sanierung fortschreitet.

5. 26. September 2026 um 05:25 UTCmonitoring

   Unsere technischen Teams haben die erforderlichen Sanierungsmaßnahmen erfolgreich abgeschlossen. Die Sperraufgaben wurden gelöscht. Die Validierung nach der Sanierung bestätigte, dass die relevanten Datenbankfunktionen und -verfahren im erwarteten Zustand funktionieren. Die Teams werden weiterhin die Umwelt überwachen, um Stabilität zu gewährleisten.

6. 26. September 2026 um 07:13 UTCresolved

   Alle Validierungsprüfungen wurden erfolgreich abgeschlossen und die Dienste sind in den Normalbetrieb zurückgekehrt. Das Problem ist nun gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 21:43 UTCidentified

   Incident Description: Wir untersuchen ein Problem, das Spot Ocean für AWS betrifft. Kunden sind möglicherweise nicht in der Lage, neue Instanzen aufgrund von Fehlern bei der Bereitstellung von Instanzen zu starten. Infolgedessen können betroffene Cluster möglicherweise nicht wie erwartet skaliert werden. Bestehende Workloads bleiben funktionsfähig. Unsere technischen Teams untersuchen aktiv den Umfang und die Auswirkungen des Problems. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams haben ein potenzielles Problem im Zusammenhang mit einer kürzlichen Änderung identifiziert, die sich auf die Bereitstellung von Instanzen auswirkt, und validieren die Auswirkungen aktiv. Minderungsaktivitäten sind im Gange, einschließlich des Rollbacks einer kürzlichen Änderung, während Teams das Wiederherstellungs- und Serviceverhalten überwachen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 24. September 2026 um 22:16 UTCresolved

   Weitere Untersuchungen ergaben, dass eine kürzliche Änderung, die sich auf das Verhalten der Instanzen auswirkt, zu dem Problem beigetragen hat. Die technischen Teams schlossen ein Rollback der Änderung ab und validierten die Wiederherstellung. Nach dem Rollback kehrten die Fehlerpegel zu normal zurück und die neue Instanzbereitstellung wurde erfolgreich wieder aufgenommen. Während des gesamten Vorfalls blieben bestehende Instanzen und Workloads funktionsfähig. Die Auswirkungen beschränkten sich auf neue Instanzstarts und Cluster-Skalierungsoperationen. Das Problem gilt nun als gelöst. Ein detaillierter Post-Mortem-Bericht wird nach Abschluss der Ursachenanalyse und der Überprüfung nach einem Vorfall veröffentlicht, in dem die vollständige Abfolge der Ereignisse, die beitragenden Faktoren, die gewonnenen Erkenntnisse und die ermittelten Folgemaßnahmen dokumentiert werden.

3. 9. Oktober 2026 um 06:33 UTCpostmortem

   **Beschreibung:** Spot Ocean für AWS – Instance Provisioning Failures **Zeitrahmen:** 24. September 2026, 12:00 Uhr PDT bis 24. September 2026, 14:54 Uhr PDT **Incident Summary** Am 24. September 2026 hatte Spot Ocean für AWS ein Problem, das einige Kunden daran hinderte, neue Instanzen zu starten. Infolgedessen konnten die betroffenen Cluster nicht wie erwartet skaliert werden, wenn zusätzliche Rechenkapazität erforderlich war. Bestehende Instanzen und Workloads blieben während des gesamten Vorfalls funktionsfähig. Die Auswirkungen beschränkten sich auf neue Instanzbereitstellungs- und Cluster-Skalierungsoperationen. Das technische Team stellte fest, dass eine kürzliche Softwareänderung ein unerwartetes Verhalten während des Instanzbereitstellungsprozesses einführte. Die Änderung wurde zurückgerollt, wodurch die Bereitstellungsfehler behoben und der normale Servicebetrieb wiederhergestellt wurde. Nach dem Rollback wurde das zugrunde liegende Softwareproblem identifiziert und korrigiert. Die aktualisierte Funktionalität wurde einer zusätzlichen Validierung unterzogen, um sicherzustellen, dass das Problem vollständig behoben wird, bevor es wieder in die Produktionsumgebung eingeführt wird. Technische Teams validierten erfolgreiche Instanzstarts nach dem Rollback, und die Kundenvalidierung bestätigte, dass die neue Instanzbereitstellung wie erwartet funktionierte. Der Vorfall wurde am 24. September 2026 um 2:54 Uhr PDT gelöst. **Wurzelursache** Der Vorfall wurde durch eine kürzliche Softwareänderung verursacht, die ein unbeabsichtigtes Verhalten während der AWS-Instanzbereitstellung einführte. Die Änderung beeinflusste, wie bestimmte Clusterkonfigurationsinformationen verarbeitet wurden, was zu Bereitstellungsfehlern für einige Scale-up-Operationen führte. Während die Änderung so konzipiert wurde, dass sie das Tagging für bestimmte AWS-Ressourcen unterstützt, wirkte sich ihr Verhalten auch auf andere unterstützte Clusterkonfigurationen aus. Unter bestimmten Bedingungen führte die aktualisierte Tagging-Logik dazu, dass doppelte Tag-Informationen als Teil der Instanzbereitstellungsanforderung übermittelt wurden. AWS lehnte diese Anfragen ab, weil die Tag-Informationen nicht den erwarteten Anforderungen entsprachen. Infolgedessen konnte Spot Ocean die Bereitstellung einiger neuer Instanzen nicht erfolgreich abschließen. Dies betraf in erster Linie neue Instanzstarts und Cluster-Scale-Up-Operationen. Bestehende Instanzen wurden bereits erfolgreich bereitgestellt und arbeiteten daher während des gesamten Vorfalls normal weiter. Die zugrunde liegende Funktionalität wurde seitdem korrigiert und es wird eine zusätzliche Validierung durchgeführt, um sicherzustellen, dass das aktualisierte Verhalten in den unterstützten AWS-Clusterkonfigurationen konsistent funktioniert, bevor es in die Produktion zurückkehrt. **Abhilfemaßnahmen** Unsere Teams führten die folgenden Aktionen durch, um die Dienste wieder normal zu machen: * Die Softwareänderung wurde zurückgerollt und die normale Instanzbereitstellung wiederhergestellt. * Identifiziert und korrigiert das zugrunde liegende Problem in der betroffenen Funktionalität. * Zusätzliche Validierung der korrigierten Funktionalität. * Es wurden zusätzliche Sicherheitsvorkehrungen eingeführt, damit die aktualisierte Funktionalität kontrolliert eingeführt werden kann. * Validiert, dass neue Instanzbereitstellungs- und Clusterskalierungsoperationen nach dem Rollback wie erwartet funktionierten. ** Künftige Präventivmaßnahmen** * Erweitern Sie automatisierte Tests, z. B. Provisioning- und Cluster-Skalierungsszenarien. * Erhöhen Sie Regressionstests in unterstützten AWS-Clusterkonfigurationen. * Erweitern Sie End-to-End-Tests für die Skalierung von Workflows. * Verbessern Sie die Überwachung und Alarmierung auf Provisioning- und Skalierungsfehler. * Stärkung der Validierung von Änderungen vor der Bereitstellung der Produktion. * Einführung zusätzlicher Sicherheitsvorkehrungen für die kontrollierte Einführung von Änderungen, die das Bereitstellungsverhalten beeinflussen. * Erhöhen Sie die Testabdeckung für Edge Cases und Fehlerbehandlungsszenarien.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 20:46 UTCmonitoring

   Incident Description: Ein Problem, das sich auf die Bestandsverarbeitung in Flexera One IT Asset Management (ITAM) in der NAM-Region ausgewirkt hat, betraf heute eine Teilgruppe von Kunden. Die Untersuchung ergab, dass Inventar-Uploads erfolgreich empfangen, aber nicht für betroffene Kunden verarbeitet wurden, was zu Verzögerungen bei den Inventardaten führte, die in Flexera One ITAM reflektiert wurden. Recovery-Aktionen wurden implementiert und die Bestandsverarbeitung wurde seitdem erfolgreich wieder aufgenommen. Inventardateien werden weiterhin normal verarbeitet; die Wiederherstellung des verbleibenden Rückstands ist jedoch noch im Gange und wird durch diesen Vorfall verfolgt. Priorität: P2 Wiederherstellungsaktivität: Technische Teams implementierten Wiederherstellungsaktionen, die die Bestandsdateiverarbeitung wiederherstellten und die erfolgreiche Verarbeitung durch Überwachung und Protokollierung validierten. Der Servicebetrieb bleibt stabil und die Backlog-Wiederherstellung wird fortgesetzt, da zuvor in die Warteschlange gestellte Inventardateien verarbeitet werden. Die technischen Teams überwachen aktiv den Wiederherstellungsfortschritt, den Servicezustand und die Reduzierung des Rückstands, während die laufenden Validierungsaktivitäten fortgesetzt werden. Frühere Updates zu den früheren Phasen dieses Vorfalls finden Sie in der unten verlinkten Vorfallhistorie. Weitere Aktualisierungen werden zur Verfügung gestellt, wenn die Wiederherstellung des Rückstands fortschreitet und die Validierungsaktivitäten fortgesetzt werden. https://status.flexera.com/incidents/5wrg6jl9bj2h

2. 25. September 2026 um 08:15 UTCmonitoring

   Die Backlog-Wiederherstellung wird fortgesetzt, da zuvor in die Warteschlange gestellte Inventardateien verarbeitet werden. Das Backlog-Niveau liegt nun in einem akzeptablen Bereich, wobei eine Organisation über dem erwarteten Niveau bleibt. Technische Teams überwachen weiterhin die Wiederherstellungs-, Service-Gesundheits- und Verarbeitungsaktivitäten, während die Validierung fortgesetzt wird.

3. 25. September 2026 um 13:28 UTCresolved

   Der während des Vorfalls akkumulierte Rückstand wurde erfolgreich verarbeitet und die Verarbeitungsstufen sind in normale Betriebsbereiche zurückgekehrt. Unsere Teams haben die Wiederherstellungsvalidierung abgeschlossen, und dieser Vorfall wird nun behoben. Weitere Einzelheiten zu den zugrunde liegenden Ursachen und ergriffenen Maßnahmen werden im Post-Mortem-Bericht enthalten sein.

4. 23. Oktober 2026 um 17:27 UTCpostmortem

   **Beschreibung:** Flexera One - IT Asset Management - NAM - Inventarverarbeitung verzögert sich nach Produktionsfreigabe **Zeitrahmen:** 22. September 2026, 19:05 Uhr PDT - 25. September 2026, 5:30 Uhr PDT **Incident Summary** Am 24. September 2026 begannen technische Teams, Berichte über verzögerte Bestandsaktualisierungen zu untersuchen, die eine Teilmenge von Kunden betreffen, die Flexera One IT Asset Management (ITAM) in der Region Nordamerika (NAM) verwenden. Obwohl Inventardateien erfolgreich hochgeladen wurden und verfügbar blieben, kam es bei einigen Kunden zu Verzögerungen bei der Verarbeitung dieser Dateien, wodurch verhindert wurde, dass die neuesten Inventarinformationen in der Anwendung widergespiegelt werden. Die in ITAM angezeigten Beacon-Statusinformationen könnten auch für betroffene Kunden veraltet sein. Die Bestandsverarbeitung wurde für andere Kunden normal fortgesetzt. Das Problem trat nach der Produktionsfreigabe von ITAM 2026R1.3 am 22. September 2026 auf. Die Untersuchung ergab eine Unterbrechung des Prozesses, der für die Übertragung der hochgeladenen Inventardateien an die ITAM-Inventarverarbeitungsdienste verantwortlich ist. Während die betroffenen Dateien im Speicher verfügbar blieben, wurden sie nicht zur Verarbeitung weitergeleitet. Technische Teams beobachteten während der Untersuchung auch erhöhte Anwendungsfehler, obwohl diese Fehler nicht abschließend als Ursache der Unterbrechung festgestellt wurden. Die technischen Teams führten einen gezielten Neustart der betroffenen Servicekomponente durch, stellten die Übertragung von Bestandsdateien wieder her und ermöglichten die Wiederaufnahme der Verarbeitung für zuvor betroffene Kunden. Zusätzliche diagnostische Protokollierung wurde ermöglicht, um weitere Untersuchungen zu unterstützen. Allerdings hatte sich während der Unterbrechung ein erheblicher Bestand an Inventardateien angesammelt und erforderte zusätzliche Bearbeitungszeit. Nach der Wiederherstellung der Verarbeitung überwachten die technischen Teams weiterhin die Bestandsaktivitäten und den akkumulierten Rückstand. Am Freitag, den 25. September 2026, um ca. 5:30 Uhr PDT, war der vorfallbedingte Rückstand auf das normale Betriebsniveau zurückgekehrt, was die Wiederherstellung der Bestandsverarbeitung bestätigte. **Wurzelursache** Der Vorfall wurde durch eine Unterbrechung des Inventarverarbeitungsworkflows nach der Produktionsfreigabe von ITAM 2026R1.3 in der NAM-Region verursacht. Obwohl Inventardateien erfolgreich hochgeladen wurden und im Speicher verfügbar blieben, hat die Komponente, die für die Weiterleitung dieser Dateien an die ITAM-Verarbeitung verantwortlich ist, die Übertragung von Inventardaten für eine Teilmenge von Kunden eingestellt. Infolgedessen wurden die betroffenen Inventardateien nicht verarbeitet, was die Aktualisierung des Inventars verzögerte. Das Problem betraf nicht alle Kunden, da die Bestandsverarbeitung für andere Organisationen normal fortgesetzt wurde. Die Untersuchung identifizierte erhöhte Anwendungsfehler und Verhalten, was darauf hindeutet, dass sich die betroffene Verarbeitungskomponente nicht wie erwartet erholte. Der genaue technische Zustand, der für die teilweise Unterbrechung verantwortlich ist, wird noch untersucht. Ein gezielter Neustart der betroffenen Servicekomponente stellte die Bestandsverarbeitung für betroffene Kunden wieder her. Der akkumulierte Rückstand wurde anschließend verarbeitet, so dass Bestandsaktualisierungen auf ein normales Niveau zurückkehren konnten. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: **Incident Investigation Initiiert:** Technische Teams untersuchten Berichte über verzögerte Bestandsaktualisierungen, die eine Teilmenge von Kunden in der NAM-Region betreffen, und überprüften den Workflow zur Bestandsverarbeitung, um den Umfang des Problems zu bestimmen. 2. **Inventarverarbeitungsunterbrechung identifiziert:** Die Untersuchung bestätigte, dass hochgeladene Inventardateien gespeichert waren, aber nicht an die Verarbeitungsdienste für betroffene Kunden weitergeleitet wurden. 3. **Betroffene Servicekomponente neu gestartet:** Ein gezielter Neustart der betroffenen Servicekomponente stellte die Übertragung von Bestandsdateien wieder her und ermöglichte die Wiederaufnahme der Verarbeitung für zuvor betroffene Kunden. 4. **Zusätzliche Diagnoseprotokollierung aktiviert:** Zusätzliche Protokollierung wurde ermöglicht, um weitere technische Informationen zu erfassen und die weitere Untersuchung der zugrunde liegenden Verarbeitungsunterbrechung zu unterstützen. 5. **Inventory Backlog Recovery Überwacht: ** Die technischen Teams überwachten den akkumulierten Bestandsbestand nach Wiederherstellung der Verarbeitung und bestätigten, dass die Bestandsdateien erfolgreich verarbeitet wurden. 6. **Service Recovery Validiert:** Die technischen Teams bestätigten, dass der auf Vorfälle bezogene Rückstand bis zum 25. September wieder auf das normale Betriebsniveau zurückgekehrt war und die Bestandsverarbeitung stabil blieb. ** Künftige Präventivmaßnahmen** Nach dem Vorfall führten wir eine Retrospektive durch, um den Fehler in der teilweisen Bestandsverarbeitung, die bestehende Bestandslieferarchitektur, verfügbare Diagnoseinformationen und Möglichkeiten zur Verbesserung der Verarbeitungszuverlässigkeit und der Fehlersichtbarkeit zu überprüfen. Folgende Korrekturmaßnahmen und Verbesserungsmaßnahmen sind im Gange: 1. **Inventarverarbeitungsarchitekturverbesserung:** Es ist geplant, die Integration in die Bestandsverarbeitung zu vereinfachen, indem ITAM in die Lage versetzt wird, hochgeladene Bestandsdateien direkt von der Speicherschicht abzurufen, anstatt sich auf den bestehenden Zwischenweiterleitungsdienst zu verlassen. Diese Änderung wird eine zusätzliche Abhängigkeit vom Verarbeitungspfad beseitigen und eine bessere Kontrolle über Verarbeitung, Backlog-Management, Kapazität und Wiederherstellung bieten. 2. **Verbesserte Fehlerdiagnose:** Die Diagnoseprotokollierung und Telemetrie, die erforderlich sind, um den jeweiligen Betriebszustand während eines teilweisen Fehlers bei der Bestandsverarbeitung zu erfassen, werden bewertet und gegebenenfalls verbessert. Dies wird verbesserte technische Informationen liefern, um die Bestimmung der Wurzelursache zu unterstützen, wenn eine ähnliche Bedingung erneut auftritt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 14:08 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das eine Teilmenge von Kunden betrifft, die Flexera One IT Asset Management (ITAM) in der NAM-Region verwenden. Betroffene Kunden können Probleme mit der Navigation haben, einschließlich Menüpunkten, die in der ITAM-Schnittstelle nicht sichtbar sind, was zu einem eingeschränkten Zugriff auf einige Funktionen führt. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams untersuchen dieses Problem aktiv und arbeiten daran, die volle Funktionalität wiederherzustellen. Wir werden weiterhin Updates bereitstellen, sobald mehr Informationen verfügbar sind.

2. 24. September 2026 um 15:44 UTCinvestigating

   Technische Teams untersuchen weiterhin das Problem, das Flexera One IT Asset Management im NAM-Produktionsumfeld betrifft. Aktuelle Bemühungen konzentrieren sich auf die Identifizierung, wo die Fehler innerhalb des betroffenen Workflows auftreten. Teams überprüfen das Anwendungsverhalten, Validierungsprozesse, Serviceinteraktionen, Plattformtelemetrie und alle jüngsten Änderungen oder Umweltbedingungen, die zu dem Problem beitragen können. Die Untersuchung läuft noch, und weitere Updates werden bereitgestellt, sobald zusätzliche Informationen verfügbar werden.

3. 24. September 2026 um 17:48 UTCinvestigating

   Die technischen Teams haben Fortschritte gemacht, um den Umfang des Problems einzuschränken, und konzentrieren sich auf die Anwendungskomponenten, die beim Laden von Benutzerzugriffen und Navigationsinformationen beteiligt sind. Aktuelle Ergebnisse zeigen, dass einige Anfragen innerhalb dieses Prozesses nicht wie erwartet abgeschlossen werden, was dazu führt, dass Menüpunkte für betroffene Benutzer nicht geladen werden. Es wird noch daran gearbeitet, die zugrunde liegende Ursache zu bestimmen und die angemessene Sanierung zu validieren. Zusätzliche Updates werden bereitgestellt, sobald mehr Informationen verfügbar sind.

4. 24. September 2026 um 18:39 UTCmonitoring

   Technische Teams beobachten derzeit ein stabiles Serviceverhalten und eine signifikante Reduzierung der mit diesem Vorfall verbundenen Fehler. Betroffene Anwendungsfunktionen funktionieren normal basierend auf aktuellen Telemetrie- und Überwachungsdaten. Während sich die Servicestabilität verbessert hat, überwachen technische Teams die Umgebung weiterhin genau, um zu bestätigen, dass das Problem nicht erneut auftritt. Die Untersuchung der zugrunde liegenden Ursache ist noch nicht abgeschlossen. Wir werden die Überwachung fortsetzen und weitere Updates bereitstellen, sobald zusätzliche Informationen verfügbar sind.

5. 24. September 2026 um 20:33 UTCresolved

   Technische Teams haben bestätigt, dass der Service stabil geblieben ist und die betroffene IT Asset Management-Funktionalität normal funktioniert. Während der Untersuchung ermittelten die technischen Teams Verbindungssättigungsbedingungen, die sich auf Anwendungskomponenten auswirken, die für den Benutzerzugriff und die Navigationsfunktionen verantwortlich sind. Diese Bedingungen wurden während des Aufprallfensters beobachtet und fielen mit den Ausfällen der betroffenen Benutzer zusammen. Die Servicefunktionalität wurde wiederhergestellt und die Kundenvalidierung bestätigte, dass die betroffenen ITAM-Seiten und Menüpunkte erfolgreich geladen wurden. Nach einer Überwachungsphase ohne Wiederholung des Problems gilt der Vorfall nun als gelöst. Eine detaillierte Überprüfung des Vorfalls wird derzeit durchgeführt, um die beitragenden Faktoren weiter zu validieren und zusätzliche vorbeugende Maßnahmen zu ermitteln.

6. 8. Oktober 2026 um 11:23 UTCpostmortem

   **Beschreibung:** Flexera One – IT Asset Management – NAM – Menu Items Not Loading **Zeitrahmen:** 24. September 2026, 5:27 Uhr PDT – 24. September 2026, 10:48 Uhr PDT **Incident Summary** Am 24. September 2026 erlebten Kunden, die Flexera One IT Asset Management (ITAM) in der Region Nordamerika nutzten, intermittierende Probleme beim Laden von Anwendungsmenüelementen und beim Zugriff auf Teile der ITAM-Funktionalität. Einige Kunden stießen auf teilweise geladene oder fehlende Menüs, Fehlermeldungen und inkonsistentes Anwendungsverhalten. Technische Teams untersuchten das Problem in den Anwendungs- und Unterstützungsdiensten und identifizierten eine abnormale Verbindungsauslastung innerhalb von Komponenten, die die ITAM-Funktionalität unterstützen. Da die verfügbare Verbindungskapazität erschöpft war, konnten einige Anwendungsanforderungen nicht mehr erfolgreich abgeschlossen werden, was zu Authentifizierungsfehlern führte und das Laden von Teilen der ITAM-Funktionalität verhinderte. Der Service begann sich um ca. 10:46 Uhr PDT zu erholen, bevor der Einsatz des korrigierenden Hotfixes abgeschlossen wurde. Die letzten verwandten Anwendungsfehler wurden um 10:48 Uhr PDT aufgezeichnet. Die technischen Teams untersuchten weiterhin die zugrunde liegende Ursache, überwachten die Umgebung und validierten die Kundenfunktionalität. Die Analyse nach dem Vorfall ergab, dass Anwendungsdienste auf den betroffenen Servern neu gestartet wurden, wodurch akkumulierte Verbindungen freigegeben und neue Verbindungen aufgebaut werden konnten. Der korrigierende Hotfix wurde anschließend als vorbeugende Maßnahme eingesetzt, um das Verbindungsverhalten zu adressieren, während die Untersuchung der zugrunde liegenden Ursache fortgesetzt wurde. Nach kontinuierlicher Überwachung und Kundenvalidierung bestätigten die technischen Teams, dass die ITAM-Funktionalität wieder in den Normalbetrieb zurückgekehrt war. **Wurzelursache** Der Vorfall wurde durch ein Verbindungsmanagementproblem verursacht, das während der Produktionsfreigabe von ITAM 2026 R1.3 eingeführt wurde. Eine Änderung des Authentifizierungsflusses der Anwendung führte dazu, dass neue Dienstverbindungen wiederholt erstellt wurden, anstatt bestehende Verbindungen erneut zu verwenden. Im Laufe der Zeit akkumulierten und erschöpften diese Verbindungen die verfügbare Verbindungskapazität innerhalb der betroffenen Anwendungskomponenten. Sobald diese Kapazität erschöpft war, konnten neue Antragsanträge nicht erfolgreich erstellt werden. Dies führte zu Authentifizierungsfehlern und verhinderte, dass Teile der ITAM-Funktionalität geladen wurden, was zu fehlenden Menüpunkten, Fehlermeldungen und intermittierenden Zugriffsverlusten für betroffene Kunden führte. Ein Hotfix, der dieses Verhalten korrigiert, wurde bereits erstellt und wurde vor der Bereitstellung in den Release-Bereitstellungsplan aufgenommen. Der Hotfix war ursprünglich für die Validierungsumgebung vorgesehen, da die Produktion noch nicht aktualisiert wurde. Es war beabsichtigt, als Teil des R1.3-Releases auf Production angewendet zu werden, aber es wurde nicht während der Production-Bereitstellung angewendet. Infolgedessen war die Korrektur des Verbindungsmanagements nicht vorhanden, als das Release live ging. **Abhilfemaßnahmen** Initiiert: Technische Teams untersuchten die Anwendungsfehler und den intermittierenden Verlust der ITAM-Funktionalität, um den Umfang und die zugrunde liegende Ursache zu bestimmen. 2. Verbindungssättigung identifiziert: Die Analyse der betroffenen Anwendungskomponenten identifizierte eine abnormale Verbindungsakkumulation, die die verfügbare Verbindungskapazität erschöpfte und den erfolgreichen Abschluss neuer Anwendungsanforderungen verhinderte. 3. Korrigierender Hotfix bestätigt: Technische Teams identifizierten den vorhandenen Hotfix, der das Verhalten der Verbindung korrigierte, indem sie Dienstverbindungen wiederverwendeten, anstatt für jede Anforderung neue Verbindungen zu erstellen. 4. Corrective Hotfix Deployed: Der Hotfix wurde in der Produktion als vorbeugende Maßnahme eingesetzt, um das Problem des Verbindungsmanagements zu lösen und eine weitere Verbindungsakkumulation zu verhindern. 5. Service Recovery Validated: Die technischen Teams überwachten weiterhin das Anwendungsverhalten und validierten die Kundenfunktionalität nach der Wiederherstellung, um zu bestätigen, dass die ITAM-Dienste in den Normalbetrieb zurückgekehrt waren. ** Künftige Präventivmaßnahmen** Nach dem Vorfall haben wir eine Retrospektive durchgeführt, um die technische Ursache, den Release- und Hotfix-Bereitstellungsprozess, die Überwachungsfähigkeiten und die Faktoren, die zu den Auswirkungen des Kunden beigetragen haben, zu überprüfen. Folgende Maßnahmen wurden abgeschlossen oder werden derzeit durchgeführt: 1. Korrektur des Verbindungsmanagements: Die Korrekturänderung wurde implementiert, um sicherzustellen, dass Dienstverbindungen angemessen wiederverwendet werden und die Akkumulation von Verbindungen die verfügbaren Anwendungsressourcen nicht erschöpft. 2. Validierung des Produktionseinsatzes: Die Korrektur des Verbindungsmanagements wurde in allen Produktionsregionen eingesetzt und validiert, um eine einheitliche Umsetzung zu gewährleisten. 3. Verbesserungen des Release- und Hotfix-Prozesses: Die Release-Prozeduren werden verbessert, sodass Hotfixes, die in den Release-Bereitstellungsplänen enthalten sind, konsistent für die Bereitstellung in der Produktion bestimmt sind, einschließlich Hotfixes, die ursprünglich erstellt oder validiert wurden, bevor die Produktionsumgebung aktualisiert wird. 4. Überprüfung des Hotfix-Prozesses: Wir evaluieren Verbesserungen des gesamten Hotfix-Prozesses, um die Abhängigkeit von Produktions-Hotfixes zu verringern und das Risiko, dass erforderliche Korrekturänderungen nicht in zukünftigen Produktionsversionen enthalten sind, weiter zu verringern. 5. Verbesserte Anwendungsüberwachung: Zusätzliche Überwachung und Alarmierung auf Anwendungsebene werden implementiert, um die Früherkennung von intermittierenden Fehlern und abnormalen Fehlerbedingungen zu verbessern, bevor sie zu breiteren Auswirkungen auf den Kunden führen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 10:11 UTCinvestigating

   Incident Description: Wir haben ein Problem identifiziert, das sich auf die Bestandsverarbeitung in Flexera One IT Asset Management (ITAM) in der NAM-Region auswirkt und eine Teilmenge von Kunden betrifft. Infolgedessen werden einige Inventar-Uploads nicht erfolgreich verarbeitet, was dazu führt, dass die in Flexera One ITAM angezeigten Inventardaten verzögert werden und nicht das zuletzt hochgeladene Inventar widerspiegeln. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams untersuchen das Problem aktiv, um die zugrunde liegende Ursache zu identifizieren und einen Fix zu implementieren. Wir beobachten die Situation weiterhin genau und werden im Verlauf der Untersuchung weitere Updates bereitstellen.

2. 24. September 2026 um 12:27 UTCinvestigating

   Weitere Untersuchungen deuten darauf hin, dass das Problem mit dem Dienst verbunden zu sein scheint, der für die Übertragung von Bestandsdaten an ITAM verantwortlich ist. Unsere technischen Teams untersuchen das Problem weiter und arbeiten daran, die zugrunde liegende Ursache zu identifizieren und die angemessene Abhilfe zu finden. Wir werden weiterhin weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

3. 24. September 2026 um 14:32 UTCmonitoring

   Unser Team führte gezielte Pod-Neustarts durch, woraufhin die Bestandsdateiverarbeitung für alle betroffenen Kunden erfolgreich fortgesetzt wurde. Die erfolgreiche Verarbeitung wurde durch Protokolle und Überwachungsgraphen validiert. Wir werden die Dienste weiterhin genau beobachten, um eine anhaltende Stabilität zu gewährleisten und weitere Updates bereitzustellen, sobald zusätzliche Informationen verfügbar sind.

4. 24. September 2026 um 18:42 UTCmonitoring

   Unsere technischen Teams beobachten weiterhin eine erfolgreiche Bestandsdateiverarbeitung und einen stabilen Servicebetrieb nach den Wiederherstellungsaktionen. Die Validierung durch Überwachung bestätigt, dass betroffene Inventardateien erfolgreich verarbeitet werden. Die Backlog-Wiederherstellung ist derzeit im Gange, wobei die Warteschlangen für die Bestandsverarbeitung mit der Verarbeitung von Dateien weiter abnehmen. Technische Teams überwachen aktiv den Wiederherstellungsfortschritt und den allgemeinen Servicezustand, während der verbleibende Rückstand behoben wird. Wir werden weiterhin Updates bereitstellen, wenn die Wiederherstellung fortschreitet.

5. 24. September 2026 um 20:32 UTCresolved

   Dieser Vorfall wurde versehentlich als mit einem Update für einen separaten Vorfall behoben markiert. Die Wiederherstellung der Bestandsverarbeitung wird weiterhin überwacht, da der verbleibende Rückstand weiter abgebaut wird. Technische Teams beobachten weiterhin eine erfolgreiche Dateiverarbeitung und einen stabilen Servicebetrieb. Die laufenden Aktualisierungen der Wiederherstellung und die Überwachung des Auftragsbestands werden unter dem neu geschaffenen Vorfall fortgesetzt: https://status.flexera.com/incidents/vztp63wmxjjb Wir werden weitere Updates bereitstellen, wenn die Wiederherstellung des Rückstands fortschreitet und die Validierung der Wiederherstellung fortgesetzt wird.

6. 23. Oktober 2026 um 17:25 UTCpostmortem

   **Beschreibung:** Flexera One - IT Asset Management - NAM - Inventarverarbeitung verzögert sich nach Produktionsfreigabe **Zeitrahmen:** 22. September 2026, 19:05 Uhr PDT - 25. September 2026, 5:30 Uhr PDT **Incident Summary** Am 24. September 2026 begannen technische Teams, Berichte über verzögerte Bestandsaktualisierungen zu untersuchen, die eine Teilmenge von Kunden betreffen, die Flexera One IT Asset Management (ITAM) in der Region Nordamerika (NAM) verwenden. Obwohl Inventardateien erfolgreich hochgeladen wurden und verfügbar blieben, kam es bei einigen Kunden zu Verzögerungen bei der Verarbeitung dieser Dateien, wodurch verhindert wurde, dass die neuesten Inventarinformationen in der Anwendung widergespiegelt werden. Die in ITAM angezeigten Beacon-Statusinformationen könnten auch für betroffene Kunden veraltet sein. Die Bestandsverarbeitung wurde für andere Kunden normal fortgesetzt. Das Problem trat nach der Produktionsfreigabe von ITAM 2026R1.3 am 22. September 2026 auf. Die Untersuchung ergab eine Unterbrechung des Prozesses, der für die Übertragung der hochgeladenen Inventardateien an die ITAM-Inventarverarbeitungsdienste verantwortlich ist. Während die betroffenen Dateien im Speicher verfügbar blieben, wurden sie nicht zur Verarbeitung weitergeleitet. Technische Teams beobachteten während der Untersuchung auch erhöhte Anwendungsfehler, obwohl diese Fehler nicht abschließend als Ursache der Unterbrechung festgestellt wurden. Die technischen Teams führten einen gezielten Neustart der betroffenen Servicekomponente durch, stellten die Übertragung von Bestandsdateien wieder her und ermöglichten die Wiederaufnahme der Verarbeitung für zuvor betroffene Kunden. Zusätzliche diagnostische Protokollierung wurde ermöglicht, um weitere Untersuchungen zu unterstützen. Allerdings hatte sich während der Unterbrechung ein erheblicher Bestand an Inventardateien angesammelt und erforderte zusätzliche Bearbeitungszeit. Nach der Wiederherstellung der Verarbeitung überwachten die technischen Teams weiterhin die Bestandsaktivitäten und den akkumulierten Rückstand. Am Freitag, den 25. September 2026, um ca. 5:30 Uhr PDT, war der vorfallbedingte Rückstand auf das normale Betriebsniveau zurückgekehrt, was die Wiederherstellung der Bestandsverarbeitung bestätigte. **Wurzelursache** Der Vorfall wurde durch eine Unterbrechung des Inventarverarbeitungsworkflows nach der Produktionsfreigabe von ITAM 2026R1.3 in der NAM-Region verursacht. Obwohl Inventardateien erfolgreich hochgeladen wurden und im Speicher verfügbar blieben, hat die Komponente, die für die Weiterleitung dieser Dateien an die ITAM-Verarbeitung verantwortlich ist, die Übertragung von Inventardaten für eine Teilmenge von Kunden eingestellt. Infolgedessen wurden die betroffenen Inventardateien nicht verarbeitet, was die Aktualisierung des Inventars verzögerte. Das Problem betraf nicht alle Kunden, da die Bestandsverarbeitung für andere Organisationen normal fortgesetzt wurde. Die Untersuchung identifizierte erhöhte Anwendungsfehler und Verhalten, was darauf hindeutet, dass sich die betroffene Verarbeitungskomponente nicht wie erwartet erholte. Der genaue technische Zustand, der für die teilweise Unterbrechung verantwortlich ist, wird noch untersucht. Ein gezielter Neustart der betroffenen Servicekomponente stellte die Bestandsverarbeitung für betroffene Kunden wieder her. Der akkumulierte Rückstand wurde anschließend verarbeitet, so dass Bestandsaktualisierungen auf ein normales Niveau zurückkehren konnten. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: **Incident Investigation Initiiert:** Technische Teams untersuchten Berichte über verzögerte Bestandsaktualisierungen, die eine Teilmenge von Kunden in der NAM-Region betreffen, und überprüften den Workflow zur Bestandsverarbeitung, um den Umfang des Problems zu bestimmen. 2. **Inventarverarbeitungsunterbrechung identifiziert:** Die Untersuchung bestätigte, dass hochgeladene Inventardateien gespeichert waren, aber nicht an die Verarbeitungsdienste für betroffene Kunden weitergeleitet wurden. 3. **Betroffene Servicekomponente neu gestartet:** Ein gezielter Neustart der betroffenen Servicekomponente stellte die Übertragung von Bestandsdateien wieder her und ermöglichte die Wiederaufnahme der Verarbeitung für zuvor betroffene Kunden. 4. **Zusätzliche Diagnoseprotokollierung aktiviert:** Zusätzliche Protokollierung wurde ermöglicht, um weitere technische Informationen zu erfassen und die weitere Untersuchung der zugrunde liegenden Verarbeitungsunterbrechung zu unterstützen. 5. **Inventory Backlog Recovery Überwacht: ** Die technischen Teams überwachten den akkumulierten Bestandsbestand nach Wiederherstellung der Verarbeitung und bestätigten, dass die Bestandsdateien erfolgreich verarbeitet wurden. 6. **Service Recovery Validiert:** Die technischen Teams bestätigten, dass der auf Vorfälle bezogene Rückstand bis zum 25. September wieder auf das normale Betriebsniveau zurückgekehrt war und die Bestandsverarbeitung stabil blieb. ** Künftige Präventivmaßnahmen** Nach dem Vorfall führten wir eine Retrospektive durch, um den Fehler in der teilweisen Bestandsverarbeitung, die bestehende Bestandslieferarchitektur, verfügbare Diagnoseinformationen und Möglichkeiten zur Verbesserung der Verarbeitungszuverlässigkeit und der Fehlersichtbarkeit zu überprüfen. Folgende Korrekturmaßnahmen und Verbesserungsmaßnahmen sind im Gange: 1. **Inventarverarbeitungsarchitekturverbesserung:** Es ist geplant, die Integration in die Bestandsverarbeitung zu vereinfachen, indem ITAM in die Lage versetzt wird, hochgeladene Bestandsdateien direkt von der Speicherschicht abzurufen, anstatt sich auf den bestehenden Zwischenweiterleitungsdienst zu verlassen. Diese Änderung wird eine zusätzliche Abhängigkeit vom Verarbeitungspfad beseitigen und eine bessere Kontrolle über Verarbeitung, Backlog-Management, Kapazität und Wiederherstellung bieten. 2. **Verbesserte Fehlerdiagnose:** Die Diagnoseprotokollierung und Telemetrie, die erforderlich sind, um den jeweiligen Betriebszustand während eines teilweisen Fehlers bei der Bestandsverarbeitung zu erfassen, werden bewertet und gegebenenfalls verbessert. Dies wird verbesserte technische Informationen liefern, um die Bestimmung der Wurzelursache zu unterstützen, wenn eine ähnliche Bedingung erneut auftritt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 10:05 UTCinvestigating

   Incident Description: Wir untersuchen derzeit ein Problem, das den Zugang zu unseren Diensten im EU-Umfeld betrifft. Kunden in der EU können Probleme beim Zugriff auf den Dienst haben. Priorität: P1 Restaurierungsaktivität: Unsere technischen Teams untersuchen das Problem vorrangig und arbeiten daran, den normalen Service so schnell wie möglich wiederherzustellen.

2. 23. September 2026 um 10:24 UTCmonitoring

   Die Dienste wurden wiederhergestellt und der Zugang funktioniert nun wie erwartet. Unsere Teams beobachten die Plattform genau, um weiterhin Stabilität zu gewährleisten.

3. 23. September 2026 um 11:43 UTCresolved

   Unsere Teams haben die Plattform weiterhin überwacht und keine Wiederholung des Problems beobachtet. Dieser Vorfall ist nun gelöst. Wir werden unsere Untersuchung fortsetzen, um die zugrunde liegende Ursache zu ermitteln und geeignete Korrekturmaßnahmen zu identifizieren. Weitere Einzelheiten werden im Post-Mortem-Bericht enthalten sein.

4. 26. Oktober 2026 um 10:40 UTCpostmortem

   **Beschreibung:** Flexera One - EU - Zugang nicht verfügbar **Zeitrahmen:** * 24. September 2026, 2:51 Uhr PDT bis 24. September 2026, 3:18 Uhr PDT * 25. September 2026, 3:50 Uhr bis 25. September 2026, 4:30 Uhr PDT **Incident Summary** Am 24. September 2026 um 2:51 Uhr PDT erlebten Kunden Anmeldefehler beim Versuch, auf die Flexera One EU Production-Umgebung zuzugreifen. Die Untersuchung bestätigte eine Verschlechterung der EU-Services für Identitäts- und Zugangsmanagement, die Kunden am Zugriff auf die Plattform hinderte. Die Untersuchung ergab einen signifikanten Anstieg der Datenbankverbindungen, die mit einem erhöhten Traffic von einer einzelnen Organisation verbunden sind. Eine weitere Analyse ergab, dass wiederholte nachgelagerte Anfragen, die von anderen Diensten generiert wurden, ebenfalls zur erhöhten Belastung der Authentifizierungs- und Zugriffskontrolldienste beitrugen. Um 3:18 Uhr PDT wurde die Kunden-Login-Funktionalität ohne direkten technischen Eingriff wiederhergestellt und die Plattform kehrte in den normalen Betrieb zurück. Am 25. September 2026 um etwa 3:50 Uhr PDT wurde ein weiterer Anstieg der Datenbankverbindungen beobachtet, der mit einem erhöhten Datenverkehr derselben Organisation verbunden war. Die erhöhte Belastung dauerte ca. 40 Minuten. Als Reaktion darauf wurde die automatische Skalierung für den Ressourcenmanagementdienst ermöglicht, um die Kapazität zu erhöhen und die Plattformstabilität zu verbessern. **Wurzelursache** Der Vorfall wurde durch einen unerwarteten Anstieg des Datenverkehrs verursacht, der die EU-Authentifizierungsdienste und die damit verbundenen Datenbankverbindungen übermäßig nachfragte. Die erhöhte Belastung betraf die Dienste, die für die Verarbeitung von Authentifizierungsanforderungen verantwortlich sind, was zu Fehlern beim Anmelden von Kunden innerhalb der EU-Produktionsumgebung führte. Wiederholte Anfragen von anderen Diensten an die Authentifizierungs- und Zugriffskontrolldienste trugen weiter zu der erhöhten Belastung bei. Darüber hinaus wurde die automatische Skalierung für den Ressourcenmanagementdienst nicht aktiviert, was seine Fähigkeit einschränkte, die Kapazität als Reaktion auf eine höhere Nachfrage dynamisch zu erhöhen. Lücken in der proaktiven Überwachung und Alarmierung beschränkten auch die Fähigkeit, die Verschlechterung zu erkennen, bevor Kunden Zugriffsfehler erlebten. **Abhilfemaßnahmen** Unsere Teams führten die folgenden Aktionen durch, um die Dienste wieder normal zu machen: * Der Vorfall vom 24. September wurde ohne direkte technische Eingriffe behoben und die Anmeldefunktionalität des Kunden wurde um 3:18 Uhr PDT wiederhergestellt. * Am 25. September wurde die automatische Skalierung für den Ressourcenmanagementdienst ermöglicht, um die Kapazität als Reaktion auf die erhöhte Nachfrage zu erhöhen. * Das Team überwachte weiterhin die Datenbankverbindungen und den Servicezustand, um die Stabilität der Plattform zu bewerten. ** Künftige Präventivmaßnahmen** Die folgenden Maßnahmen wurden identifiziert und werden derzeit bearbeitet, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern und die Widerstandsfähigkeit des Dienstes zu verbessern: * Automatische Skalierung: Überprüfen Sie die automatische Skalierungskonfiguration für den Ressourcenmanagementdienst in allen Produktionsregionen, um sicherzustellen, dass sich die Kapazität an Änderungen der Arbeitslast anpasst. Datenbankkapazitätsmanagement: Überprüfen Sie die Einstellungen des Datenbankverbindungspools und stellen Sie sicher, dass die Service-Skalierung innerhalb der verfügbaren Verbindungskapazität der Datenbank bleibt. Proaktive Überwachung und Alarmierung: Überprüfung und Einführung von Warnmeldungen für abnormales Wachstum der Datenbankverbindung, Sättigung des Verbindungspools, Dienstlatenz, Fehlerquoten und Ressourcenauslastung. * Traffic-Überwachung: Verbessern Sie die Sichtbarkeit von Traffic-Mustern auf Organisationsebene, um ungewöhnliche Anforderungsspitzen zu identifizieren, bevor sie andere Kunden betreffen. * Traffic-Management: Evaluieren Sie geeignete Tarifbegrenzungs- und Drosselungskontrollen, um zu verhindern, dass übermäßiger Traffic von einer einzelnen Organisation die plattformweite Verfügbarkeit beeinträchtigt. * Last- und Kapazitätstests: Durchführung von Lasttests unter Verwendung von Verkehrsmustern, die für den Vorfall repräsentativ sind, um die Serviceleistung und die Datenbankkapazität bei erhöhter Nachfrage zu validieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 06:51 UTCinvestigating

   Vorfallbeschreibung: Wir untersuchen derzeit ein Problem, das sich auf die Flexera One IT Asset Management (ITAM) North America Production-Umgebung auswirkt, die aufgrund der geplanten Wartung, die über das geplante Wartungsfenster hinausgeht, nicht verfügbar ist. Die Wartungsaktivität ist noch im Gange, während ein Datenbankumbau abgeschlossen ist. Priorität: P1 Restaurierungsaktivität: Unsere technischen Teams arbeiten aktiv daran, die verbleibenden Wartungsaktivitäten abzuschließen und den Service so schnell wie möglich wiederherzustellen. Die ETA für den Datenbankumbau beträgt ca. 2 Stunden. Unsere Teams beobachten den Fortschritt genau und werden weitere Details zur Verfügung stellen, sobald sie verfügbar sind.

2. 23. September 2026 um 09:15 UTCinvestigating

   Unsere technischen Teams haben eine wichtige Phase der laufenden Wartungsaktivitäten abgeschlossen und setzen die verbleibende Verarbeitung fort, die für den Abschluss des Upgrades erforderlich ist. Der Prozess dauert länger als ursprünglich angenommen. Die Umwelt bleibt nicht verfügbar, während diese Aktivitäten im Gange sind. Die Teams überwachen aktiv die verbleibenden Verarbeitungen und bewerten Optionen, um den Service so schnell und sicher wie möglich wiederherzustellen. Weitere Updates werden bereitgestellt, wenn das Upgrade fortschreitet und der Wiederherstellungs-Zeitrahmen klarer wird.

3. 23. September 2026 um 11:47 UTCmonitoring

   Das Upgrade wurde erfolgreich abgeschlossen. Unsere Teams arbeiten nun daran, die Dienste wiederherzustellen und die Validierung nach dem Einsatz durchzuführen.

4. 23. September 2026 um 13:02 UTCmonitoring

   Das upgrade wurde erfolgreich abgeschlossen, und die website ist jetzt wieder online. Unser Team führt abschließende Validierungsprüfungen durch, um die Servicestabilität zu bestätigen, bevor der Vorfall behoben wird.

5. 23. September 2026 um 15:57 UTCresolved

   Der Service wurde wiederhergestellt und funktioniert normal. Nach der Wiederherstellung schlossen die technischen Teams erweiterte Überwachungs- und Validierungsaktivitäten ab und bestätigten einen stabilen Betrieb. Der Vorfall gilt nun als gelöst.

6. 30. September 2026 um 16:02 UTCpostmortem

   **Beschreibung:** Flexera One – IT Asset Management – Nordamerika – Service-Nichtverfügbarkeit nach 2026R1.3 Instandhaltung **Zeitrahmen:** 22. September 2026, 9:00 Uhr PDT – 23. September 2026, 5:47 Uhr PDT **Incident Summary** Am 22. September 2026 führte Flexera die geplante Produktionsfreigabe 2026R1.3 für Flexera One IT Asset Management in der Region Nordamerika durch. Das Upgrade schritt in der überwiegenden Mehrheit der Datenbanken in der Umgebung erfolgreich voran. Als das geplante Wartungsfenster jedoch um 21:00 Uhr PDT endete, blieb eine erforderliche Datenbankmigration im Gange. Da die Produktionsumgebung erst nach Abschluss der Migration wiederhergestellt werden konnte, blieb IT Asset Management über den geplanten Wartungszeitraum hinaus nicht verfügbar. Die verbleibende Migration erforderte einen großen Datenbankindex-Wiederaufbau mit einem erheblichen Datenvolumen. Die Operation wurde zum kritischen Weg für den Abschluss der Veröffentlichung und dauerte wesentlich länger als erwartet. Nach Abschluss der ersten Phase der Indexverarbeitung musste die Datenbank noch zusätzliche Sortier- und Indexerstellungsaktivitäten durchführen. Diese Arbeit dauerte mehrere Stunden und verlängerte die Gesamtdauer der Migration. Während der Untersuchung bewerteten die technischen Teams die verfügbaren Wiederherstellungsoptionen, einschließlich der Frage, ob die betroffene Datenbank vorübergehend vom Migrationspfad getrennt werden könnte, damit der Rest der Umgebung wieder in Betrieb genommen werden kann. Aufgrund des Bereitstellungsstadiums und der zusätzlichen Wiederherstellungsarbeiten, die dieser Ansatz erfordert hätte, bestand der zuverlässigste Wiederherstellungspfad darin, den Datenbankbetrieb vor der Wiederherstellung der Umgebung abzuschließen. Nach Abschluss der Datenbankmigration begannen die technischen Teams mit der Wiederherstellung der Anwendungs- und Supportdienste. Während des Starts wurde ein zusätzliches Service-Wiederherstellungsproblem festgestellt, das manuelle Eingriffe erforderte, bevor die Wiederherstellung fortgesetzt werden konnte. Nach der Sanierung wurden die verbleibenden Anwendungs- und Plattformdienste erfolgreich wiederhergestellt. Die technischen Teams schlossen dann Validierungsaktivitäten ab, bestätigten den Kundenzugang und führten eine erweiterte Überwachung durch, um die Servicestabilität zu überprüfen. Der Kundeneinfluss endete am 23. September 2026 um 5:47 Uhr PDT. **Wurzelursache** Der Ausfall wurde durch eine Diskrepanz der Datenbankindexkonfiguration verursacht, die während der Migration 2026R1.3 identifiziert wurde, was zu einem großen Indexumbauvorgang führte, der das geplante Wartungsfenster erheblich überstieg. Die Untersuchung nach dem Vorfall ergab, dass ein Index innerhalb der betroffenen Datenbank nicht mit der Datenbankstruktur übereinstimmte, die von der aktuellen Veröffentlichung erwartet wurde. Der Index wurde zuvor mit einer älteren Definition neu erstellt, die keine nachfolgende Änderung des Datenbankdesigns enthielt. Während der 2026R1.3-Bereitstellung identifizierte der Migrationsprozess diesen Unterschied und initiierte die Datenbankoperation, die erforderlich ist, um den Index mit der aktuellen Datenbankdefinition in Einklang zu bringen. Aufgrund der außergewöhnlich großen Größe des Datensatzes wurde der daraus resultierende Umbau zu einem langjährigen und ressourcenintensiven Betrieb, der das geplante Wartungsfenster deutlich übertraf. Sobald der Umbau im Gange war, konnte die verbleibende Verarbeitungsdauer nicht zuverlässig vorhergesagt werden, was es schwierig machte, eine genaue Abschlussschätzung zu liefern, während der Vorgang fortgesetzt wurde. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: * Index Rebuild Überwacht: Der Index-Wiederaufbau und die verbleibenden Datenbank-Upgrade-Aktivitäten wurden kontinuierlich bis zum Abschluss überwacht. * Ausgewertete Wiederherstellungsoptionen: Verfügbare Wiederherstellungsansätze wurden bewertet, um den sichersten und zuverlässigsten Weg für die Rückgabe der Produktionsumgebung zu ermitteln. * Datenbank-Upgrade abgeschlossen: Der Index-Wiederaufbau und die verbleibenden Datenbank-Upgrade-Aktivitäten wurden abgeschlossen, bevor die Wiederherstellung der Anwendung begann. * Anwendungs- und Unterstützungsdienste wiederhergestellt: Anwendungs- und Unterstützungsdienste wurden wiederhergestellt. Gezielte Wiederherstellungsaktionen wurden durchgeführt, wenn ein zusätzliches Service-Startup-Problem aufgetreten war. * Service Recovery Validated: Der Kundenzugriff und die Anwendungsfunktionalität wurden bestätigt, die verbleibende Hintergrundverarbeitung wurde überprüft und die erweiterte Überwachung wurde abgeschlossen, um den stabilen Betrieb zu überprüfen. ** Künftige Präventivmaßnahmen** Flexera erkennt die Bedeutung und Dauer dieses Ausfalls und die Auswirkungen auf die Kunden in der Region Nordamerika an. Eine vollständige Ursachenanalyse und funktionsübergreifende Retrospektive wurden abgeschlossen und die folgenden vorbeugenden Maßnahmen wurden als Teil der laufenden Verbesserungsbemühungen identifiziert: 1. Datenbankprozedurvalidierung: Technische Teams bewerten, wie Datenbanksanierungsverfahren überprüft und gepflegt werden, um sicherzustellen, dass sie mit den aktuellen Produktanforderungen in Einklang bleiben, während sich die Plattform weiterentwickelt. 2. Pre-Deployment Verification: Release-Validierungsprozesse werden evaluiert, um festzustellen, wie unerwartete Datenbankkonfigurationsunterschiede identifiziert und bewertet werden können, bevor die Wartung der Produktion beginnt. 3. High-Impact Operation Assessment: Technische Teams prüfen, wie potenziell lang laufende oder ressourcenintensive Datenbankoperationen während der Release-Vorbereitung identifiziert werden können, damit ihre erwartete Dauer und operative Auswirkungen vor dem Einsatz besser verstanden werden können. 4. Release Readiness and Recovery Planning: Release-Readiness- und Recovery-Planungspraktiken werden überprüft, um die Sichtbarkeit von Aktivitäten zu verbessern, die die Bereitstellungsdauer und die Service-Wiederherstellungszeiten erheblich beeinflussen können. Die Bereitstellung zuverlässiger und belastbarer Dienstleistungen bleibt eine Priorität. Die Erkenntnisse aus der abgeschlossenen Ursachenanalyse und Retrospektive fließen in technische und betriebliche Verbesserungen ein, die die Wahrscheinlichkeit eines erneuten Auftretens verringern und die Planung und Durchführung zukünftiger Wartungsarbeiten stärken sollen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. September 2026 um 05:56 UTCinvestigating

   Vorfallbeschreibung: Wir untersuchen derzeit ein Problem, das eine Teilmenge unserer Kunden betrifft, die Snow Atlas in der Region Australien verwenden. Die betroffenen Kunden können Verzögerungen beim Sehen der neuesten Computerinformationen erleben, und die Datenaufnahme kann ebenfalls beeinträchtigt werden. Priorität: P2 Wiederherstellungsaktivität: Ein früheres DNS-Problem wurde identifiziert und behoben. Allerdings werden jetzt zusätzliche Fehler beobachtet. Unsere technischen Teams untersuchen diese Fehler aktiv, um die zugrunde liegende Ursache zu ermitteln und die normale Verarbeitung wiederherzustellen. Wir werden die Auswirkungen weiterhin bewerten und weitere Updates bereitstellen, sobald zusätzliche Informationen verfügbar sind.

2. 22. September 2026 um 07:19 UTCinvestigating

   Unsere Teams haben gezielte Service-Neustarts durchgeführt, was die Verarbeitungsverzögerungen verbessert hat. Die Überwachung zeigt, dass die Bestandsdaten nun erfolgreich aktualisiert werden. Die verbleibenden Fehler werden noch untersucht, und unsere Teams arbeiten daran, die zugrunde liegende Ursache zu identifizieren und eine dauerhafte Lösung zu implementieren.

3. 22. September 2026 um 10:15 UTCmonitoring

   Die Sanierungsmaßnahmen haben die Verarbeitungsverzögerungen und veralteten Datenprobleme behoben. Einige Restprobleme bleiben bestehen und werden derzeit von unseren technischen Teams untersucht. Die Teams überwachen die Dienste und werden in den nächsten 24 Stunden weiterhin Protokolle sammeln und überprüfen, um die Untersuchung zu unterstützen. Wir werden die Dienste weiterhin genau beobachten und weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

4. 23. September 2026 um 07:05 UTCresolved

   Unsere Teams überwachten die Dienste weiterhin über Nacht und bestätigten, dass keine neuen Probleme beobachtet wurden. Zusätzliche Stichproben wurden ebenfalls erfolgreich durchgeführt. Dieser Vorfall wird nun behoben. Weitere Informationen über die Ursache und die ergriffenen Maßnahmen werden im Post-Mortem-Bericht enthalten sein.

5. 13. Oktober 2026 um 12:49 UTCpostmortem

   **Beschreibung:** Snow Atlas- APAC - Datenaufnahme und Verarbeitungsverzögerungen **Zeitrahmen:** 21. September 2026, 5:48 Uhr PDT bis 22. September 2026, 3:15 Uhr PDT **Incident Summary** Am Montag, den 21. September 2026, um 17:48 Uhr PDT, betraf ein Problem mehrere Snow Atlas-Mieter in der Region Australia East (AE), was zu Verzögerungen bei der Aktualisierung der Bestandsdaten führte. Betroffene Kunden erlebten veraltete Geräteinformationen auf der Computerseite, während Snow Extenders den Status "Running with Errors" anzeigte. Fehler wurden auch bei der Datenaufnahme beobachtet. Die Untersuchung identifizierte einen veralteten DNS-Datensatz, der mit der zuvor stillgelegten Infrastruktur in der Region Australien im Südosten verbunden war. Dieser Datensatz beeinträchtigte die Konnektivität mit der Umgebung in Australien Ost und verhinderte, dass Inventardaten wie erwartet verarbeitet wurden. Der veraltete DNS-Eintrag wurde entfernt, so dass der Datenverkehr den richtigen Endpunkt erreicht und Inventar-Scan-Updates wieder aufgenommen werden können. Nach der Änderung begannen die Bestandszählungen fortzuschreiten, und die betroffenen Konnektivitätsdienststatus wurden am 22. September 2026 um 3:15 Uhr PDT wieder normalisiert. Nach einer längeren Überwachungszeit über Nacht blieben die Konnektivitätsdienste stabil, und das Problem wurde am 23. September um 12:05 Uhr PDT für gelöst erklärt. Es wurden keine weiteren Probleme gemeldet, und die zuvor genutzte Infrastruktur in Australien im Südosten wurde vollständig stillgelegt. **Wurzelursache** Der Vorfall wurde durch einen veralteten DNS-Datensatz verursacht, der nach der Stilllegung der Infrastruktur in der Region Australien im Südosten blieb. Dieser Datensatz lenkte den Datenverkehr vom richtigen Endpunkt für die Umgebung Australia East weg und unterbrach die für die Bestandsdatenverarbeitung erforderliche Konnektivität. Infolgedessen verzögerten sich Bestandsaktualisierungen und betroffene Kunden konnten die neuesten Geräteinformationen nicht abrufen. Der veraltete Datensatz wurde entfernt, wodurch die Konnektivität zum richtigen Endpunkt wiederhergestellt und die Bestandsverarbeitung wieder aufgenommen wurde. **Abhilfemaßnahmen** Unsere Teams führten die folgenden Aktionen durch, um die Dienste wieder normal zu machen: * Identifiziert und entfernt den veralteten DNS-Eintrag, der mit der zuvor stillgelegten Infrastruktur verbunden ist. * Wiederherstellung der Konnektivität zum korrekten Endpunkt Australien Ost. * Vergewissert, dass Inventar-Scan-Updates und Inventarzahlen voranschreiten. * Überwachte die Umgebung, um die Servicestabilität zu bestätigen. * Bestätigt, dass der Status des Snow-Verbindungsdienstes anschließend wieder normalisiert wurde und keine weiteren Probleme gemeldet wurden. ** Künftige Präventivmaßnahmen** * Überprüfen Sie die Bereinigung von DNS-Datensätzen während der Stilllegung der Infrastruktur, um sicherzustellen, dass veraltete Datensätze entfernt werden. * Verbessern Sie die Überprüfungen nach der Stilllegung, um Datensätze zu identifizieren, die nach der Ressourcenentfernung verbleiben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. September 2026 um 13:03 UTCinvestigating

   Incident Description: Wir untersuchen ein Problem, das die Bestandsdatenverarbeitung in der EU- und APAC-Produktionsumgebung betrifft. Kunden können Verzögerungen bei Bestandsaktualisierungen feststellen, die dazu führen, dass die Bestandsdaten nicht die letzte Importaktivität widerspiegeln. Priorität: P2 Restaurierungsaktivität: Unsere technischen Teams untersuchen das Problem aktiv, validieren den Umfang der Auswirkungen und arbeiten mit relevanten Abhängigkeiten, um die normale Bestandsverarbeitung wiederherzustellen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 18. September 2026 um 13:50 UTCidentified

   Unsere technischen Teams haben das Problem auf einen kürzlichen Einsatz zurückgeführt und Abhilfemaßnahmen umgesetzt. Die erste Validierung zeigt an, dass die Bestandsverarbeitung wieder aufgenommen wurde, und die technischen Teams überwachen aktiv die Verarbeitungsaktivität und die Wiederherstellung des Rückstands. Wir werden die Wiederherstellung in den betroffenen Umgebungen weiterhin validieren und werden weitere Updates bereitstellen, sobald mehr Informationen verfügbar sind.

3. 18. September 2026 um 14:34 UTCidentified

   Die technischen Teams haben die erforderlichen Konfigurationsupdates abgeschlossen und die Bestandsdaten werden weiterhin erfolgreich verarbeitet. Zusätzliche Verarbeitungskapazität wurde zugewiesen, um die Rückstandswiederherstellung zu beschleunigen, und technische Teams überwachen aktiv den Durchsatz und die Rückstandsreduzierung in den betroffenen Umgebungen. Die Recovery-Aktivitäten sind weiterhin im Gange, und weitere Updates werden bereitgestellt, wenn die Verarbeitung des Backlogs fortgesetzt wird.

4. 18. September 2026 um 14:39 UTCmonitoring

   Die Bestandsdatenverarbeitung erholt sich weiter, und die technischen Teams beobachten einen Abwärtstrend beim Auftragsvolumen. Zusätzliche Verarbeitungskapazität bleibt bestehen, und der Fortschritt der Wiederherstellung wird in den betroffenen Umgebungen genau überwacht. Wir werden die Reduzierung des Rückstands weiterhin überwachen und weitere Updates bereitstellen, wenn die Erholung fortschreitet.

5. 18. September 2026 um 18:52 UTCmonitoring

   Die Bestandsdatenverarbeitung wird nach der zuvor durchgeführten Sanierung fortgesetzt. Technische Teams überwachen aktiv den Verarbeitungsdurchsatz und die Wiederherstellung des Backlogs in den betroffenen Umgebungen. Die technischen Teams bewerten weiterhin den Wiederherstellungsfortschritt und alle zusätzlichen Maßnahmen, die zur Beschleunigung der Auftragsverarbeitung beitragen können. Weitere Updates werden bereitgestellt, wenn die Wiederherstellung fortschreitet.

6. 18. September 2026 um 19:49 UTCmonitoring

   Die Wiederherstellung des Rückstands in APAC ist nach der zuvor implementierten Sanierung abgeschlossen, und die Bestandsdatenverarbeitung ist in der Region auf das erwartete Niveau zurückgekehrt. Die Rückgewinnungsmaßnahmen werden in der EU fortgesetzt, wo technische Teams den Verarbeitungsdurchsatz und die Reduzierung des Rückstands überwachen. Zusätzliche Wiederherstellungsmaßnahmen werden evaluiert, um die Backlog-Verarbeitung im Verlauf der Wiederherstellung zu unterstützen.

7. 18. September 2026 um 21:55 UTCmonitoring

   Die Sanierungsbemühungen in der EU werden fortgesetzt, und die technischen Teams beobachten eine anhaltende Reduzierung des verbleibenden Rückstands. Zur Unterstützung der Backlog-Verarbeitung in der EU wurden zusätzliche Wiederherstellungsoptimierungen implementiert, und die technischen Teams überwachen weiterhin den Durchsatz und den gesamten Wiederherstellungsfortschritt. Weitere Updates werden bereitgestellt, wenn die Fortschritte fortgesetzt werden.

8. 19. September 2026 um 11:07 UTCmonitoring

   Die Erholung schreitet weiter voran, wobei der verbleibende Rückstand stetig abnimmt. Zusätzliche Optimierungen im EU-Umfeld unterstützen die Backlog-Verarbeitung effektiv. Unsere Teams überwachen den Fortschritt der Wiederherstellung weiterhin genau und werden gegebenenfalls weitere Updates bereitstellen.

9. 19. September 2026 um 19:09 UTCmonitoring

   Die Wiederherstellungsbemühungen in der EU gehen weiter, und die technischen Teams beobachten eine fortgesetzte Reduzierung des Rückstands nach den zuvor implementierten Optimierungen. Basierend auf den aktuellen Erholungstrends wurden die Rückstandsbestände deutlich reduziert und bewegen sich weiter in die erwartete Richtung. Weitere Updates werden bereitgestellt, wenn die Fortschritte fortgesetzt werden.

10. 20. September 2026 um 19:55 UTCresolved

    Technische Teams haben bestätigt, dass die Bestandsdatenverarbeitung in der EU nach der zuvor durchgeführten Sanierung wieder in den Normalbetrieb zurückgekehrt ist. Das Problem wurde auf ein Problem mit der Bereitstellungskonfiguration zurückgeführt, das sich auf die Verarbeitung der Bestandsdaten auswirkt. Die erforderlichen Konfigurationsupdates wurden angewendet, um die normale Verarbeitung wiederherzustellen. Nach Validierung und erweiterter Überwachung ist die Bestandserholung in der EU abgeschlossen und die Bestandsaufbereitung bleibt sowohl in der EU als auch in der APAC stabil. Dieser Vorfall gilt nun als gelöst.

11. 23. Oktober 2026 um 17:20 UTCpostmortem

    **Beschreibung:** Flexera One - IT Asset Management - EU & APAC - Inventarverarbeitung verzögert sich nach einem Problem mit der Bereitstellungskonfiguration **Zeitrahmen:** 16. September 2026, 14:00 Uhr PDT - 20. September 2026, 9:52 Uhr PDT **Incident Summary** Am Freitag, den 18. September 2026 begannen technische Teams, Berichte über verspätete Bestandsaktualisierungen von Flexera One IT Asset Management-Kunden in den Regionen Europa und Asien-Pazifik zu untersuchen. Aktualisierte Inventarinformationen wurden in der Anwendung nicht berücksichtigt, wobei einige Kunden berichteten, dass ihre neuesten verfügbaren Inventardaten auf den 16. September datiert blieben. Das Problem betraf die Bestandsverarbeitung und nicht die allgemeine Verfügbarkeit der ITAM-Plattform. Die erste Analyse ergab, dass die Inventarverarbeitungsdienste gesund erschienen, die eingehenden Inventardateien jedoch nicht den erwarteten Verarbeitungsworkflow durchlaufen. Weitere Untersuchungen ergaben die Unterbrechung einer Bereitstellung am 16. September, bei der ein Konfigurationsproblem die für die Verarbeitung von Bestandsdaten zuständigen Dienste betraf. Die technischen Teams identifizierten und korrigierten die Bereitstellungskonfiguration, sodass die Bestandsverarbeitung wieder aufgenommen werden konnte. Allerdings hatte sich während der Unterbrechung ein erheblicher Bestand an Inventardateien angesammelt und erforderte zusätzliche Bearbeitungszeit. Die Bestandsverarbeitung erholte sich zuerst in APAC, wo der akkumulierte Rückstand am 18. September um ca. 12:21 Uhr PDT gelöscht wurde. Die EU-Region benötigte aufgrund des Umfangs der ausstehenden Dateien zusätzliche Erholungszeit. Die technischen Teams passten die Einstellungen der Verarbeitungskapazität an und überwachten den Rückstand weiter, während Inventardateien verarbeitet wurden. Der verbleibende EU-Auftrag wurde am 20. September um ca. 9:52 Uhr PDT vollständig gelöscht. Die anschließende Überwachung bestätigte, dass die Bestandsverarbeitung auf ein normales Betriebsniveau zurückgekehrt war. **Wurzelursache** Der Vorfall wurde durch ein Bereitstellungskonfigurationsproblem verursacht, das während eines Updates der Inventarverarbeitungsdienste am 16. September eingeführt wurde. Zum Zeitpunkt der Bereitstellung wechselte die Inventarverarbeitungsinfrastruktur zwischen Anwendungsumgebungen, wobei je nach Region verschiedene Dienste in jeder Umgebung aktiv bleiben mussten. Dies erhöhte die Komplexität der Aufrechterhaltung der korrekten Produktionskonfiguration, und die erforderliche Servicekonfiguration wurde während des Einsatzes nicht korrekt beibehalten. Infolgedessen wurde der Inventarverarbeitungs-Workflow in den EU- und APAC-Regionen unterbrochen, wodurch die Verarbeitung eingehender Inventardateien verhindert und die Aktualisierung der Inventardaten verzögert wurde. Sobald die Konfiguration korrigiert wurde, wurde die Bestandsverarbeitung wieder aufgenommen, wobei der akkumulierte Rückstand zusätzliche Zeit für die Verarbeitung erforderte, bevor die normalen Betriebsniveaus vollständig wiederhergestellt wurden. **Abhilfemaßnahmen** Während der Incident Response wurden folgende Maßnahmen ergriffen: **Incident Investigation Initiiert:** Die technischen Teams untersuchten Berichte über verzögerte Bestandsaktualisierungen in den Regionen der EU und der APAC und überprüften den Workflow zur Bestandsverarbeitung, um die Quelle der Unterbrechung zu identifizieren. 2. **Deployment Configuration Issue Identifiziert:** Die Untersuchung verfolgte die Unterbrechung der Bereitstellung am 16. September und identifizierte eine falsche Servicekonfiguration, die die Bestandsverarbeitung in den betroffenen Regionen beeinflusste. 3. **Produktionskonfiguration korrigiert:** Die erforderlichen Konfigurationsupdates wurden angewendet, um die betroffenen Inventarverarbeitungsdienste wiederherzustellen, so dass eingehende Inventardateien die Verarbeitung wieder aufnehmen können. 4. **Inventory Backlog Recovery Initiiert: ** Die technischen Teams überwachten die akkumulierten Bestandsdateien und passten die verfügbaren Verarbeitungsressourcen an, um die Wiederherstellung des Rückstands nach Wiederherstellung des Verarbeitungsworkflows zu unterstützen. 5. **Verarbeitungsdurchsatz optimiert:** Während der EU-Wiederherstellung identifizierten die technischen Teams Verarbeitungskapazitätsengpässe unter dem erhöhten Arbeitsaufwand und passten die Verarbeitungsgleichzeit an, um den Durchsatz zu verbessern und gleichzeitig die Servicestabilität zu erhalten. 6. **Service Recovery Validiert:** Die technischen Teams bestätigten, dass der APAC-Rückstau am 18. September abgeschlossen war, gefolgt von einer vollständigen Wiederherstellung des EU-Rückstaus am 20. September. Die kontinuierliche Überwachung bestätigte, dass die Bestandsverarbeitung wieder auf ein normales Betriebsniveau zurückgekehrt war. ** Künftige Präventivmaßnahmen** Nach dem Vorfall führten wir eine Retrospektive durch, um das Problem der Bereitstellungskonfiguration, die Unterschiede zwischen Anwendungsumgebungen, die Überwachungsfunktionen für die Bestandsverarbeitung und die Möglichkeiten zur Verbesserung der Bereitstellungsvalidierung und der operativen Sichtbarkeit zu überprüfen. Die folgenden Korrekturmaßnahmen und Verbesserungsmaßnahmen wurden abgeschlossen oder sind im Gange: 1. **Regionales Service-Konfigurationsmanagement:** Eine regionale Servicekonfigurationsliste wurde implementiert, um die erforderlichen Servicekonfigurationen in den verschiedenen Bereitstellungsumgebungen zu dokumentieren und zu pflegen, wodurch das Risiko von Konfigurationsinkonsistenzen bei zukünftigen Releases reduziert wird. 2. **Validierungsverbesserungen:** Es wurde eine Bereitstellungs-Checkliste implementiert, um zu überprüfen, ob die erforderlichen Inventarverarbeitungsdienste während der Bereitstellungsaktivitäten in den entsprechenden Umgebungen ausgeführt werden. 3. **Verbesserte Bestandsüberwachung:** Zusätzliche Überwachung und Alarmierung wurden implementiert, um Unterbrechungen in der Bestandsverarbeitung früher zu erkennen und eine schnellere Untersuchung und Wiederherstellung zu ermöglichen. 4. **Verbesserte Sichtbarkeit von Verarbeitungsfehlern:** Monitoring-Dashboards wurden implementiert, um eine bessere Sichtbarkeit von abnormalen Reaktionsmustern für Anwendungen zu ermöglichen, einschließlich Fehlern im Zusammenhang mit der Verarbeitungskapazität. Diese Verbesserungen haben bereits eine frühere Erkennung und Wiederherstellung bei nachfolgenden Verarbeitungsproblemen unterstützt. 5. **Vereinfachung der Produktionsumgebung:** Die laufenden Arbeiten zur Konsolidierung des Bereitstellungsmodells werden die operative Komplexität im Zusammenhang mit der Aufrechterhaltung unterschiedlicher Servicekonfigurationen in Umgebungen und Regionen reduzieren und das Risiko ähnlicher konfigurationsbedingter Verarbeitungsunterbrechungen verringern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 09:04 UTCidentified

   Vorfallbeschreibung: Wir haben derzeit ein Problem mit der Flexera Community-Website. Aufgrund eines anhaltenden Ausfalls, der sich auf einen Drittanbieter auswirkt, können Kunden möglicherweise nicht auf das Flexera Community-Portal zugreifen oder es kann zu intermittierendem und unzuverlässigem Verhalten kommen. Darüber hinaus können Kunden möglicherweise keine Supportfälle über die Community-Website erstellen, aktualisieren oder mit diesen interagieren. E-Mails, die während dieses Zeitraums an [email protected] gesendet werden, können erst empfangen oder verarbeitet werden, wenn der zugrunde liegende Ausfall behoben wurde. Dieser Ausfall eines Drittanbieters wirkt sich auch auf die proaktive Überwachung aus, mit der Spot-Supportteams Probleme in der Kundenumgebung sowie ein Chatbot-Widget in der Spot-Konsole erkennen können. Priorität: P3 Restaurierungsaktivität: Unsere technischen Teams überwachen die Situation aktiv und arbeiten mit dem Drittanbieter zusammen, um die Restaurierungsbemühungen zu verfolgen. Wir werden weiterhin die Auswirkungen auf die Kunden bewerten und weitere Updates bereitstellen, sobald zusätzliche Informationen verfügbar sind.

2. 16. September 2026 um 12:31 UTCidentified

   Der Dienstanbieter hat den Fix erfolgreich in einer Testumgebung validiert und mit der Bereitstellung in allen betroffenen Instanzen begonnen. Der Rollout schreitet von Region zu Region voran, und die Dienste kehren in Regionen, in denen die Bereitstellung abgeschlossen wurde, wieder normalisiert.

3. 16. September 2026 um 19:25 UTCmonitoring

   Unser Dienstleister berichtet, dass die Service-Telemetrie nach dem Einsatz der Milderung gesund geblieben ist. Die Community bleibt zu diesem Zeitpunkt zugänglich, und es wurden keine bestätigten anhaltenden Auswirkungen festgestellt. Wir werden die Umwelt weiterhin überwachen, um eine anhaltende Stabilität zu gewährleisten, während die endgültigen Validierungsaktivitäten abgeschlossen sind. Wir werden ein weiteres Update bereitstellen, sobald zusätzliche Informationen verfügbar sind.

4. 16. September 2026 um 22:00 UTCmonitoring

   Unser Dienstleister hat den zugrunde liegenden Vorfall nach erfolgreicher Minderung und erweiterter Validierung für behoben erklärt. Die Gemeinschaft bleibt zugänglich, und es wurden keine bestätigten anhaltenden Auswirkungen festgestellt. Bei der Überwachung während des gesamten Erholungszeitraums wurden keine zusätzlichen Probleme festgestellt. Dieser Vorfall gilt nun als gelöst.

5. 17. September 2026 um 11:01 UTCresolved

   Unsere Teams haben den Service während der gesamten Wiederherstellungsphase weiterhin überwacht, und es wurden keine zusätzlichen Probleme beobachtet. Aufgrund der anhaltenden Stabilität des Dienstes gilt dieser Vorfall nun als gelöst.

6. 30. September 2026 um 12:30 UTCpostmortem

   **Beschreibung:** Flexera Community-Service nicht verfügbar **Zeitrahmen:** 16. September 2026, 12:50 Uhr PDT bis 16. September 2026, 8:26 Uhr PDT **Incident Summary** Am 16. September 2026 um 12:50 Uhr stellte Flexera ein Problem fest, das die Verfügbarkeit und Zuverlässigkeit der Flexera Community-Website aufgrund eines Ausfalls eines externen Dienstleisters, der die Community-Plattform unterstützt, beeinträchtigte. Während des Vorfalls konnten Kunden möglicherweise nicht auf die Flexera Community zugreifen, Supportfälle ansprechen oder verwalten oder Antworten auf bestehende Fälle über die Community erhalten. E-Mails, die an [email protected] gesendet wurden, wurden möglicherweise während des Ausfalls verzögert oder nicht verarbeitet. Das Problem betraf auch die Chatbot-Funktionalität in der Spot-Konsole, die auf den betroffenen Diensten beruht. Darüber hinaus wirkte sich der Ausfall auf die proaktiven Überwachungsmöglichkeiten aus, die von Spot-Support-Teams verwendet werden, um bestimmte Probleme in der Kundenumgebung zu identifizieren, die von Servicebenachrichtigungen abhängen. Der Dienstanbieter validierte daraufhin einen Fix und begann, ihn regionenweise über betroffene Instanzen hinweg einzusetzen. Als die Abschwächung eingesetzt wurde, kehrten die Dienste schrittweise zum Normalzustand zurück. Nach der Bereitstellung blieb die Service-Telemetrie in kundenorientierten Umgebungen gesund. Die Validierung bestätigte, dass die Flexera Community und die Spot Chatbot-Funktionalität normal funktionierten. Der zugrunde liegende Anbietervorfall wurde anschließend für behoben erklärt, und Flexera schloss die endgültige Validierung ab und schloss den Vorfall ab. **Wurzelursache** Der Vorfall wurde durch einen Ausfall eines externen Dienstleisters verursacht, der die Flexera Community und die damit verbundenen Funktionen unterstützt. Die Serviceunterbrechung wirkte sich auf die Verfügbarkeit und Zuverlässigkeit der Community-Plattform und der damit verbundenen Integrationen aus, was zu einer vorübergehenden Störung der Funktionalität des Kundensupports und der damit verbundenen Spot-Fähigkeiten führte. **Abhilfemaßnahmen** * Behebung des Anbieters: Der externe Dienstleister validierte und implementierte einen Fix in den betroffenen Instanzen. Service-Validierung: Flexera-Teams überwachten die Community, die Chatbot-Funktionalität und die damit verbundenen Dienste, als die Behebung bereitgestellt wurde. * Recovery-Monitoring: Service-Gesundheit und Funktionalität wurden überwacht, um die Stabilität nach der Sanierung zu bestätigen. * Incident Closing: Nachdem das zugrunde liegende Provider-Problem behoben und Flexera die Validierung abgeschlossen hatte, wurde der Incident geschlossen. ** Künftige Präventivmaßnahmen** * Verbesserte Abhängigkeitsüberwachung: Weitere Überwachung kritischer externer Abhängigkeiten, die kundenorientierte Dienste unterstützen. * Folgenabschätzung für Kunden: Weitere Bewertung der Auswirkungen externer Serviceunterbrechungen über integrierte Flexera-Dienste hinweg, einschließlich Community, Support Case Management und Spot-Funktionalität. * Überwachung nach Zwischenfällen: Weitere Überwachung auf verbleibende Kundenauswirkungen nach Wiederherstellung externer Dienste.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. September 2026 um 23:05 UTCinvestigating

   Incident Description: Wir untersuchen derzeit ein Problem, das die Richtlinien und Automatisierungsdienste in der EU-Produktionsumgebung betrifft. Kunden in der EU können bei der Verwendung von Richtlinien Fehler auftreten und können ihre Richtlinien möglicherweise nicht über die Benutzeroberfläche anzeigen. Die Auswirkungen beschränken sich auf die EU-Region. Priorität: P2 Wiederherstellungsaktivität: Unsere technischen Teams wurden engagiert und untersuchen aktiv ein Problem, das während eines Infrastruktur-Upgrades aufgetreten ist, um die zugrunde liegende Ursache zu identifizieren und den normalen Service so schnell wie möglich wiederherzustellen. Weitere Aktualisierungen werden im Laufe der Untersuchung bereitgestellt.

2. 16. September 2026 um 06:16 UTCmonitoring

   Das Problem, das die EU-Umgebung betrifft, wurde behoben und der Zugang zur Benutzeroberfläche vollständig wiederhergestellt. Während der Dienst jetzt normal funktioniert, kann es einige Zeit dauern, bis der Arbeitsrückstand in der Warteschlange, der sich während des Ausfalls angesammelt hat, verarbeitet wird. Unsere Teams überwachen die Wiederherstellung aktiv, um sicherzustellen, dass der Rückstand behoben wird und die Dienstleistungen weiterhin wie erwartet funktionieren. Wir werden die Umwelt weiterhin genau beobachten und bestätigen, sobald die Verarbeitung vollständig auf das normale Niveau zurückgekehrt ist.

3. 16. September 2026 um 08:24 UTCresolved

   Unsere Teams haben den Service weiterhin genau beobachtet, und es wurden keine neuen Probleme beobachtet. Der Arbeitsrückstand, der sich während der Störung angesammelt hat, wird erfolgreich verarbeitet und nimmt wie erwartet weiter ab. Basierend auf der seit der Erholung beobachteten Stabilität ist dieser Vorfall nun behoben. Wir werden die Verarbeitung weiterhin überwachen, um sicherzustellen, dass der verbleibende Rückstand vollständig gelöscht wird und der Service weiterhin wie erwartet funktioniert.

4. 12. Oktober 2026 um 12:02 UTCpostmortem

   **Beschreibung:** Flexera - EU - Richtlinien/Automatisierung nicht verfügbar **Zeitrahmen:** 15. September 2026, 3:50 Uhr PDT bis 16. September 2026, 1:22 Uhr PDT **Incident Summary** Am 15. September 2026, um 15.50 Uhr PDT, führte ein Infrastruktur-Upgrade zur Unterstützung der Automatisierung in der EU-Produktionsumgebung zu einer Unterbrechung der Netzwerkverbindung, die sich auf Richtlinien und Automatisierung auswirkte. Kunden hatten Schwierigkeiten beim Anzeigen von Richtlinien in der Benutzeroberfläche, und richtlinienbezogene Operationen scheiterten. Die Untersuchung identifizierte unerwartetes Verhalten einer Legacy-Netzwerkkomponente. Dies unterbrach die von den betroffenen Diensten benötigte Konnektivität. Das Team identifizierte die beteiligte Komponente und brachte die erforderliche Ressource online, um die Netzwerkverbindung wiederherzustellen. Das zugrunde liegende Problem wurde am 15. September um 10:13 Uhr PDT gelöst. Im Anschluss daran überwachte das Team die Servicewiederherstellung und die Verarbeitung des während der Störung akkumulierten Rückstands. Nachdem die Auftragsverarbeitung wie erwartet fortgeschritten war und die Servicestabilität bestätigt wurde, wurde der Vorfall am 16. September 2026 um 1:22 Uhr PDT für vollständig wiederhergestellt erklärt. Die Auswirkungen beschränkten sich auf die Produktion in der EU. **Wurzelursache** Der Vorfall wurde durch unerwartetes Verhalten einer Legacy-Netzwerkkomponente während des Upgrades der Automatisierungsinfrastruktur in der EU-Region verursacht. Dadurch wurde die von Richtlinien und Automatisierung geforderte Netzwerkkonnektivität gestört, was zur Nichtverfügbarkeit von Diensten und zu Ausfällen der richtlinienbezogenen Funktionalität führte. **Abhilfemaßnahmen** Unsere Teams führten die folgenden Aktionen durch, um die Dienste wieder normal zu machen: Konnektivitätswiederherstellung: Identifizierte die betroffene Legacy-Komponente und brachte die erforderliche Ressource online, um die Netzwerkverbindung wiederherzustellen. Service Recovery: Konnektivität wiederhergestellt und das zugrunde liegende Problem mit Richtlinien und Automatisierung behoben. * Backlog-Verarbeitung: Überwachte den akkumulierten Backlog als Verarbeitung, die nach der Servicewiederherstellung wiederhergestellt wurde. * Validierung nach der Wiederherstellung: Bestätigte Servicestabilität und verifizierte, dass die Backlog-Verarbeitung wie erwartet voranschritt, bevor der Vorfall vollständig wiederhergestellt wurde. ** Künftige Präventivmaßnahmen** * Migrationsplanung: Die entsprechende US-Migration wurde mit einem längeren Wartungsfenster verschoben, um zusätzliche Zeit für die Fehlersuche und Wiederherstellung zu haben. * Ersatz von Legacy-Komponenten: Die Legacy-Komponente wird im Rahmen der Modernisierung der Infrastruktur ersetzt. Sobald der Ersatz abgeschlossen ist, wird erwartet, dass diese spezifische Legacy-Abhängigkeit in allen Umgebungen beseitigt wird.

Automatisch aus der offiziellen Störungsmeldung übersetzt.