Cronologia delle interruzioni di Flexera

1. 27 ottobre 2026 alle ore 17:00 UTCidentified

   Descrizione dell'incidente: Stiamo indagando ritardi che riguardano gli aggiornamenti dei contenuti di Technopedia. Il contenuto di Technopedia utilizzato da Data Platform, IT Visibility e API non è stato aggiornato dal 22 ottobre a causa di ripetuti errori di elaborazione dei dati. I clienti possono quindi vedere contenuti Technopedia obsoleti nei servizi interessati. Priorità: P2 Attività di ripristino: I nostri team tecnici hanno eseguito azioni di recupero per affrontare i guasti del trattamento dei dati e hanno aggiornato il contenuto sottostante. La generazione del catalogo è attualmente in corso e stiamo monitorando questa attività attraverso il completamento. Forniamo un ulteriore aggiornamento come progressi di recupero.

2. 28 ottobre 2026 alle ore 01:44 UTCidentified

   Il contenuto di Technopedia rimane in corso. I nostri team tecnici continuano a monitorare il rinfresco attraverso il completamento. Una volta completata l'elaborazione, convalideremo che i contenuti Technopedia aggiornati sono disponibili in tutti i servizi interessati per garantire il ripristino delle normali operazioni di aggiornamento dei contenuti.

3. 28 ottobre 2026 alle ore 09:39 UTCidentified

   Il contenuto di Technopedia rimane in corso e continua ad essere attentamente monitorato dai nostri team tecnici. Dopo il completamento, convalideremo il contenuto aggiornato nei servizi interessati per confermare le normali operazioni sono state ripristinate.

4. 28 ottobre 2026 alle ore 10:35 UTCresolved

   Il contenuto di Technopedia è stato completato e la validazione ha confermato che il contenuto aggiornato è disponibile in tutti i servizi interessati. Le operazioni di aggiornamento dei contenuti normali sono state ripristinate e il problema è risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 ottobre 2026 alle ore 07:05 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda la funzionalità di Snow Atlas SAM Core nella regione sud del Regno Unito. Alcuni clienti possono sperimentare problemi di accesso alla funzionalità degli utenti e possono incontrare errori durante l'accesso ai dettagli del computer. Priorità: P2 Attività di restauro: I nostri team tecnici stanno attivamente indagando sul problema e valutando la portata dell'impatto. Stiamo lavorando per identificare la causa sottostante e ripristinare la funzionalità interessata. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 22 ottobre 2026 alle ore 07:21 UTCmonitoring

   I nostri team tecnici hanno identificato errori di timeout che riguardano i componenti di servizio che supportano le funzionalità colpite e hanno eseguito riavviamenti di servizio mirati. A seguito di queste azioni di recupero, la funzionalità degli utenti e dei dettagli del computer risponde con successo durante la convalida. Stiamo continuando a monitorare il comportamento dei servizi e ad eseguire la validazione finale per confermare la stabilità sostenuta.

3. 22 ottobre 2026 alle ore 07:38 UTCresolved

   Dopo le azioni di recupero precedentemente implementate, i nostri team tecnici hanno completato la convalida e il monitoraggio aggiuntivi. La funzionalità degli utenti e dei dettagli del computer è rimasta stabile senza ulteriori problemi osservati. L'operazione normale è stata confermata, e questo incidente è ora considerato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 ottobre 2026 alle ore 22:37 UTCresolved

   Descrizione dell'incidente: Dopo il rilascio programmato di Flexera One IT Asset Management 2026R1.4 nella regione Australia, abbiamo sperimentato un problema che riguarda i servizi di Flexera One IT Asset Management in APAC. Di conseguenza, i clienti non sono stati in grado di accedere a Flexera One IT Asset Management durante il periodo di impatto. Priorità: P1 Inizio impatto: 15 ottobre 2026 ore 11:34 Fine impatto: 15 ottobre 2026 alle 12:32 PM PDT Attività di restauro: I nostri team tecnici hanno identificato un problema che riguarda i componenti di servizio in seguito al rilascio programmato di produzione. La riparazione è stata applicata ai componenti interessati per ripristinare la disponibilità del servizio. Dopo il recupero, Flexera One IT Asset Management servizi in APAC sono tornati al normale funzionamento, e il problema è ora considerato risolto.

2. 21 ottobre 2026 alle ore 23:40 UTCpostmortem

   **Descrizione:** Flexera One - IT Asset Management - APAC - Service Unvailability Comunicato **Timeframe:** 15 ottobre 2026, 11:34 AM PDT - 15 ottobre 2026, 12:32 PM PDT ## Riepilogo incidente Il 15 ottobre 2026 i clienti che utilizzano Flexera One IT Asset Management nella regione APAC hanno sperimentato una disgregazione del servizio che ha impedito l'accesso all'applicazione. La rottura si è verificata dopo il completamento del rilascio di produzione ITAM 2026R1.4. Anche se i servizi sono stati inizialmente disponibili e operativi normalmente dopo il rilascio, l'applicazione successivamente è diventata inaccessibile. I team tecnici hanno indagato la rottura e individuato i guasti che riguardano l'inizializzazione delle istanze delle applicazioni. Ulteriori indagini hanno rivelato che l'ambiente di produzione ha mantenuto una dipendenza da un precedente processo di inizializzazione delle applicazioni, mentre era in corso una transizione a un processo aggiornato. Anche se le istanze dell'applicazione erano state inizializzate con successo durante il rilascio, le istanze di sostituzione non erano in grado di completare lo stesso processo a causa di una configurazione obsoleta. Le istanze di sostituzione interessate non sono state in grado di completare l'inizializzazione con successo o passare i controlli sanitari necessari, impedendo l'applicazione di tornare al normale funzionamento. I team tecnici hanno corretto la configurazione di produzione per fare riferimento al processo di inizializzazione aggiornato e hanno eseguito un aggiornamento delle istanze. A seguito di questi cambiamenti, le istanze colpite hanno inizializzato con successo, e la disponibilità del servizio ITAM è stata ripristinata a circa 12:32 PM PDT. # Causa radice # L'incidente è stato causato da una dipendenza di produzione rimanente da un precedente processo di inizializzazione delle applicazioni durante la transizione a un processo aggiornato nell'ambiente di produzione APAC. Mentre gli ambienti di test di acquisizione e accettazione degli utenti erano già passati al processo aggiornato, l'ambiente di produzione APAC ha mantenuto una configurazione che richiamava il precedente processo di inizializzazione. Durante il rilascio di produzione 2026R1.4, le istanze delle applicazioni sono state inizializzate manualmente utilizzando il processo aggiornato, permettendo all'ITAM di operare inizialmente normalmente nonostante la dipendenza di produzione rimanente. I componenti che sostengono il processo precedente sono stati successivamente ridimensionati sotto la comprensione che la transizione più ampia era stata in gran parte completata. Quando sono state avviate le istanze delle applicazioni di sostituzione, la configurazione di produzione ha continuato a indirizzarle al processo di inizializzazione precedente. Le istanze interessate non erano quindi in grado di completare l'inizializzazione con successo o passare i controlli sanitari necessari, con conseguente interruzione del servizio. La dipendenza di produzione rimanente dal precedente processo di inizializzazione è stata confermata come la causa principale dell'incidente. Correggere la configurazione di produzione per utilizzare il processo di inizializzazione aggiornato ha rimosso che le istanze di dipendenza e ha permesso di inizializzare con successo. ## Azioni di bonifica Le seguenti azioni sono state prese durante la risposta incidente: 1. ** Iniziato l'indagine incidente:** I team tecnici hanno esaminato l'applicazione indisponibilità e individuato i guasti che riguardano l'inizializzazione e i controlli sanitari delle istanze applicative nell'ambiente di produzione APAC. 2. ** Problema di configurazione Identificata:** L'indagine ha determinato che la configurazione di produzione ha continuato a riferire il precedente processo di inizializzazione delle applicazioni piuttosto che il processo aggiornato. 3. ** Configurazione di produzione Corretto:** La configurazione di produzione è stata aggiornata per fare riferimento al corretto processo di inizializzazione dell'applicazione, rimuovendo la dipendenza dal processo precedente. 4. ** Casi di domanda Rifiuti: ** I team tecnici hanno eseguito un aggiornamento delle istanze dopo la correzione della configurazione, consentendo alle istanze sostitutive di inizializzare con successo. 5. ** Servizio di recupero convalidato: ** I team tecnici hanno confermato che le istanze interessate stavano inizializzando con successo, i controlli sanitari delle applicazioni sono stati di passaggio, e i servizi ITAM erano tornati al normale funzionamento. ## Misure preventive future A seguito dell'incidente, è stata condotta una retrospettiva per rivedere il processo di inizializzazione dell'applicazione, rimanenti dipendenze di produzione, procedure di rilascio-valida e opportunità per migliorare il rilevamento e la risposta degli incidenti. Sono state completate o in corso le seguenti azioni correttive e attività di miglioramento: 1. ** Correzione di configurazione di produzione:** L'ambiente di produzione APAC è stato aggiornato per utilizzare il corretto processo di inizializzazione delle applicazioni, sostituendo la configurazione precedente. 2. ** Convalida della dipendenza dalla legittimità:** È stata istituita un'azione di follow-up per aggiungere un passo di validazione prima che i componenti della piattaforma legacy vengano ridimensionati o disattivati, assicurando che i servizi di produzione siano completamente transizionati e che non esistano dipendenze rimanenti sulla piattaforma precedente. 3. **Release and Application Health-Check Review:** I controlli sanitari delle applicazioni esistenti, le procedure di rilascio-validazione e la copertura post-release sanity-test sono in fase di revisione contro il fallimento osservato durante questo incidente. La revisione determinerà se esistono lacune di copertura e se sono necessari ulteriori controlli, convalida o altri miglioramenti. 4. **Instance Scaling Investigation:** Continueremo a indagare su cosa ha innescato le istanze di applicazione originali per scalare dopo il rilascio e determinare se è necessario un'azione correttiva o preventiva aggiuntiva. 5. ** Miglioramenti della comunicazione del cliente: ** Abbiamo identificato un'opportunità per una comunicazione clienti più tempestiva durante questo incidente. Le nostre pratiche di escalation e comunicazione degli incidenti consolidate sono progettate per garantire la notifica proattiva del cliente quando viene identificato l'impatto del servizio non pianificato. L'apprendimento da questo incidente è stato incorporato nelle nostre pratiche di risposta incidente in corso per aiutare a garantire che queste procedure vengano applicate in modo coerente e che gli aggiornamenti proattivi tempestivi sono forniti ai clienti durante le interruzioni di servizio.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 ottobre 2026 alle ore 10:59 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda il servizio di licenza all'interno di SAM Core. Gli utenti potrebbero non essere in grado di caricare informazioni sulla licenza e possono incontrare messaggi di errore durante l'accesso alla funzionalità del Servizio licenze. Il problema è stato confermato nel Regno Unito Sud e nell'Europa occidentale, e i team tecnici stanno valutando l'intera portata dell'impatto. Priorità: P2 Attività di restauro: i team tecnici stanno attivamente indagando sul problema e rivedere il servizio interessato. La convalida aggiuntiva è in corso per determinare l'intera portata di impatto e ripristinare il normale funzionamento del servizio. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 8 ottobre 2026 alle ore 11:30 UTCmonitoring

   Abbiamo identificato il problema in relazione ad una recente distribuzione che riguarda il servizio licenze. Sono state implementate modifiche correttive e la funzionalità del servizio è stata ripristinata. Attualmente stiamo convalidando la salute del servizio e il monitoraggio dell'ambiente per garantire la stabilità continua. Ulteriori aggiornamenti saranno forniti come ulteriore validazione è completata.

3. 8 ottobre 2026 alle ore 12:11 UTCresolved

   Dopo la convalida e un periodo di monitoraggio, il servizio è rimasto stabile e la funzionalità di Licenza sta caricando con successo in tutte le regioni interessate. Il problema è ora considerato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 ottobre 2026 alle ore 00:08 UTCinvestigating

   Descrizione incidente: Stiamo indagando su un problema che riguarda la funzionalità Accordi in Atlante neve per i clienti in Australia. I clienti possono sperimentare i dati mancanti o non disponibili quando si accede alla scheda Accordi, e le operazioni di aggiornamento dati possono fallire. Priorità: P2 Attività di ripristino: i team tecnici stanno attivamente indagando il problema e valutando l'entità dell'impatto del cliente. Il lavoro è in corso per identificare la causa del problema e ripristinare la normale funzionalità. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 8 ottobre 2026 alle ore 01:39 UTCresolved

   Ulteriori indagini hanno identificato un problema di comunicazione che riguarda un servizio di backend che supporta la funzionalità Accordi in Snow Atlas Australia. I team tecnici hanno implementato azioni di recupero, tra cui riavviare i componenti di servizio colpiti, che hanno ripristinato la comunicazione e il normale funzionamento. La funzionalità è stata validata in più ambienti del cliente e i dati degli Accordi vengono visualizzati correttamente. Non abbiamo osservato ulteriori problemi a seguito delle attività di recupero e convalida. Il problema è ora considerato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 7 ottobre 2026 alle ore 20:27 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando i rapporti di questioni intermittenti che interessano i clienti di Ocean Kubernetes. Alcuni clienti hanno segnalato di ricevere avvisi relativi alla connettività tra i componenti di Ocean Kubernetes e i loro cluster. I team tecnici stanno indagando attivamente la portata dell'impatto e qualsiasi degradazione del servizio associato. Priorità: P2 Attività di ripristino: I nostri team tecnici stanno attivamente indagando sul comportamento segnalato, rivedendo i report dei clienti e convalidando la portata e l'impatto in ambienti colpiti. Forniremo aggiornamenti aggiuntivi come ulteriori informazioni diventano disponibili.

2. 7 ottobre 2026 alle ore 22:23 UTCinvestigating

   Continuiamo a indagare sui problemi di connettività intermittente precedentemente segnalati. In questo momento, non sono stati osservati ulteriori eventi dalla finestra di impatto originale. I team tecnici stanno esaminando attivamente i risultati della telemetria e delle indagini disponibili per determinare la causa sottostante e convalidare la portata complessiva dell'impatto. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

3. 8 ottobre 2026 alle ore 00:03 UTCinvestigating

   Non abbiamo osservato eventuali ulteriori eventi dal momento che la finestra di impatto originariamente segnalato, e la stabilità di servizio è stata mantenuta. I team tecnici continuano a indagare sulla causa sottostante dei problemi di connettività intermittente segnalati oggi.

4. 8 ottobre 2026 alle ore 00:04 UTCmonitoring

   Sulla base della stabilità sostenuta osservata dal momento che la finestra di impatto originariamente segnalato e l'assenza di ulteriori eventi segnalati, stiamo spostando questo incidente al monitoraggio. I team tecnici continuano a indagare sulla causa sottostante mentre la stabilità dei servizi viene monitorata. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

5. 8 ottobre 2026 alle ore 02:24 UTCresolved

   Non abbiamo osservato eventuali ulteriori eventi dal momento dell'impatto segnalato originale, e la stabilità di servizio è stata mantenuta. I team tecnici hanno completato un'indagine aggiuntiva sui problemi di connettività intermittente segnalati oggi. Nel corso dell'indagine sono state esaminate più potenziali correlazioni e l'analisi finale è ancora in sospeso. Sulla base della stabilità sostenuta osservata e dell'assenza di ricorrenza, questo incidente è ora considerato risolto. I team tecnici continueranno a svolgere attività di monitoraggio e indagine per comprendere ulteriormente il comportamento osservato durante la finestra di impatto riportata, e verrà fornito un rapporto formale RCA una volta che l'analisi è stata completata.

6. 20 ottobre 2026 alle ore 17:50 UTCpostmortem

   **Descrizione:** Spot Ocean - Kubernetes - Intermittent Controller Problemi di connettività **Timeframe:** 7 ottobre 2026, 11:20 PDT - 12:30 PM PDT **Riepilogo incidente** Mercoledì 7 ottobre 2026, alle 11:20 PDT, più Spot Ocean per ambienti Kubernetes hanno sperimentato avvisi di connettività del controller intermittente. Durante l'incidente, la piattaforma ha interpretato temporaneamente le informazioni di battito cardiaco del controller come operazioni di scaling obsolete e sospese per cluster interessati come misura di sicurezza. I controllori interessati hanno continuato a segnalare informazioni battito cardiaco durante l'incidente. Tuttavia, il timestamp utilizzato per convalidare la connettività del controller è diventato obsoleto all'interno di un componente del database, causando controller attivi a apparire temporaneamente non rispondenti. Il comportamento era intermittente, e le attuali informazioni battito cardiaco successivamente divennero disponibili senza intervento manuale, permettendo normali operazioni di scaling di riprendere. I team tecnici hanno esaminato il percorso di elaborazione del battito cardiaco del controller, il comportamento del database, la telemetria dei servizi e i relativi segnali infrastrutturali per determinare perché l'attività battito cardiaco valida è stata interpretata come stantio. Non sono stati osservati ulteriori eventi dopo la finestra incidente. Dopo il monitoraggio e la convalida della stabilità dei servizi, l'incidente è stato considerato risolto. ♪Root Cause ♪ L'incidente è stato causato da un vecchio controller timetamp battito cardiaco che sovrascrive un timestamp più recente valido all'interno di un componente del database. Anche se i controllori interessati hanno continuato a segnalare battiti cardiaci normalmente, il timestamp obsoleto ha reso il battito cardiaco più recentemente memorizzato apparire più vecchio di quanto fosse. Quando la piattaforma ha valutato questo timestamp, ha superato la soglia di battito cardiaco configurata e ha attivato un meccanismo di sicurezza che temporaneamente sospeso operazioni di scaling per i cluster interessati. La condizione specifica che ha ritardato l'aggiornamento del database precedente non è stata definitivamente stabilita. Tuttavia, il processo di aggiornamento del database non ha fornito una garanzia per evitare che un vecchio timestamp battito cardiaco sostituisca un nuovo timestamp valido. Ciò ha permesso di ritardare le informazioni battito cardiaco per creare l'aspetto che attivamente i controllori di reporting erano in risposta. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. Report dei clienti e comportamento dei servizi Recensito: i team tecnici hanno esaminato esempi per confermare il comportamento, stabilire la finestra di impatto, e determinare se il problema è stato isolato o che interessa più ambienti. 2. Controllore Heartbeat Attività convalidata: l'attività del controller è stata controllata per determinare se i controller interessati avevano smesso di segnalare. L'indagine ha confermato che le informazioni battito cardiaco continuarono ad essere inviate durante l'incidente. 3. Heartbeat Processing Path Investigated: i team tecnici hanno tracciato come le informazioni battito cardiaco sono state generate, memorizzate e valutate per identificare dove l'attività battito cardiaco corrente è stata interpretata come obsoleta. 4. Database e Service Health Assessed: prestazioni del database rilevanti, comportamento dei servizi e telemetria delle infrastrutture sono stati esaminati per valutare i potenziali ritardi di elaborazione e escludere l'instabilità della piattaforma più ampia. 5. Timestamp Regression Identificata: L'indagine ha determinato che un vecchio timestamp battito cardiaco aveva sovrascritto un nuovo timestamp valido, causando la piattaforma di interpretare temporaneamente il battito cardiaco come stante. 6. Stabilità del servizio convalidata: i team tecnici hanno continuato il monitoraggio dopo il recupero. Non sono stati osservati ulteriori eventi e le operazioni di scaling sono rimaste stabili prima che l'incidente fosse chiuso. **Misure di prevenzione complesse** I seguenti miglioramenti sono previsti per rafforzare la lavorazione del battito cardiaco e migliorare il rilevamento di condizioni simili: 1. Protezione dei timestamp Heartbeat: Il processo di aggiornamento del database sarà modificato per evitare che un vecchio timestamp battito cardiaco sovrascriva un timestamp più recente valido. 2. Logging diagnostico migliorato: Ulteriori logging saranno introdotti intorno aggiornamenti battito cardiaco per catturare la fonte di ogni aggiornamento, contesto di richiesta rilevante, valori di timestamp precedenti e nuovi, e la fonte del timestamp. 3. Monitoraggio e Alerting: Verrà sviluppato un nuovo monitoraggio e avviso utilizzando le ulteriori informazioni diagnostiche per identificare le regressioni dei timestamp e le condizioni di elaborazione del battito cardiaco simili più rapidamente. 4. Database Access Review: i modelli di accesso del database associati all'elaborazione del battito cardiaco saranno esaminati per identificare le opportunità per ridurre i ritardi di elaborazione e ottimizzare le prestazioni sotto carico elevato.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 settembre 2026 alle ore 11:08 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda il servizio di notifica dell'evento in più ambienti di produzione. I clienti possono sperimentare ritardi o guasti durante la ricezione di notifiche evento v2, comprese le notifiche consegnate tramite e-mail, webhooks, Slack e altri canali supportati. Gli eventi continuano ad essere registrati e rimangono accessibili attraverso la console e API Flexera One. Attualmente non vi è alcuna indicazione che le funzionalità della piattaforma core o i dati degli eventi siano stati influenzati. Priorità: P3 Attività di ripristino: I nostri team tecnici hanno identificato il problema e implementato azioni di recupero dei servizi. Il monitoraggio indica che i tassi di errore stanno diminuendo, e i team continuano a convalidare la stabilità dei servizi e valutare l'intera portata dell'impatto. Ulteriori aggiornamenti saranno forniti come progressi degli sforzi di indagine e di recupero. Aggiornamento: Ulteriori indagini hanno confermato che questo problema non ha influenzato i clienti. Le notifiche interessate non erano destinate a essere pubblicate.

2. 29 settembre 2026 alle ore 11:53 UTCresolved

   Dopo aver monitorato attentamente i servizi per confermare la stabilità, i nostri team non hanno osservato ulteriori errori o ricorrenza del problema. Questo incidente è ora risolto.

3. 13 ottobre 2026 alle ore 04:42 UTCpostmortem

   **Descrizione:** Spot by Flexera - Event Notification Processing Errors **Tempio:** 29 settembre 2026, 2:06 AM PDT - 4:51 AM PDT **Riepilogo incidente** Il 29 settembre 2026 Flexera ha identificato errori di applicazione elevati all'interno di un componente di elaborazione delle notifiche responsabile della gestione di determinati flussi di lavoro di notifica degli eventi. Il monitoraggio automatizzato ha rilevato un'elevata attività di errore, richiedendo un'indagine per determinare se le notifiche relative ai clienti sono state colpite. Durante l'indagine, i team tecnici hanno identificato i guasti che si verificano all'interno di un percorso di elaborazione delle notifiche e hanno effettuato una valutazione dettagliata degli eventi interessati, dei flussi di lavoro di notifica e del potenziale impatto del cliente. L'analisi iniziale ha suggerito che il problema potrebbe potenzialmente influenzare l'elaborazione delle notifiche più in generale, e un incidente maggiore è stato dichiarato mentre l'ambito e l'impatto sono stati convalidati. Ulteriori valutazioni di impatto hanno confermato che le notifiche interessate non erano destinate a essere pubblicate ai clienti. Le informazioni sugli eventi continuarono a essere registrate con successo e rimasero disponibili attraverso la piattaforma durante l'indagine. Nessuna funzionalità di customer-facing è stata interrotta, nessun dato evento è stato perso, e nessun impatto del cliente è stato identificato a seguito di questo problema. Sulla base dei risultati della valutazione dell'impatto, la priorità incidente è stata degradata e l'indagine è stata conclusa dopo la convalida ha confermato che i servizi di customer-facing sono rimasti inalterati. ♪Root Cause ♪ L'indagine ha determinato che un flusso di lavoro di elaborazione delle notifiche ha incontrato un'eccezione di applicazione durante la gestione di un sottoinsieme di eventi generati internamente. Questi eventi sono stati configurati in modo tale che non erano destinati alla consegna della notifica del cliente. Sebbene le eccezioni generassero errori di applicazione elevati e indagini garantite, l'analisi successiva ha confermato che le notifiche interessate non erano previste per essere distribuite ai clienti. Di conseguenza, la consegna della notifica, la funzionalità della piattaforma e l'accesso alle informazioni sugli eventi non hanno avuto un impatto negativo. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. Incident Investigation Iniziato: i team tecnici hanno indagato errori di applicazione elevati rilevati attraverso il monitoraggio automatizzato e valutato il potenziale impatto del cliente. 2. Analisi del trattamento di notifica Eseguita: Il flusso di lavoro di notifica interessato è stato esaminato per identificare la fonte delle eccezioni di applicazione e determinare la portata del problema. 3. Customer Impact Assessment Completato: i team tecnici hanno convalidato i tipi di notifica interessati, hanno esaminato il comportamento della pubblicazione degli eventi e hanno confermato che le notifiche in questione non erano destinate alla consegna del cliente. Condotto: Tendenze di errore, comportamento del servizio e elaborazione delle notifiche sono stati monitorati per confermare il funzionamento stabile e convalidare che i servizi di customer-facing non sono rimasti colpiti. 5. Riclassificazione degli incidenti Completo: Dopo la conferma che non esisteva alcun impatto del cliente, la priorità incidente è stata degradata e l'incidente è stato formalmente risolto. **Misure di prevenzione complesse** A seguito di questa indagine, abbiamo identificato le opportunità per migliorare la velocità e l'accuratezza della valutazione dell'impatto quando gli avvisi operativi comportano flussi di lavoro di elaborazione interni. 1. Valutazione dell'impatto migliorata: verifica le classificazioni delle notifiche interne e le procedure di indagine per accelerare la determinazione se un problema influisce sulla funzionalità di fronte al cliente durante gli incidenti futuri. 2. Maggiore visibilità del flusso di lavoro di notifica: migliorare la visibilità operativa nei percorsi di elaborazione delle notifiche rivolti al cliente e non al cliente per supportare le attività di convalida e risposta agli incidenti più veloci.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 28 settembre 2026 alle ore 09:10 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda la visibilità IT nella regione APAC dove i cruscotti Power BI non riescono a caricare. I clienti nella regione interessata potrebbero non essere in grado di accedere alle dashboard di report all'interno dell'applicazione. L'indagine attuale indica che il problema è limitato alla regione APAC, senza alcun impatto osservato in altre regioni in questo momento. Priorità: P2 Attività di ripristino: I nostri team tecnici stanno attivamente indagando sul problema per identificare la causa sottostante e ripristinare la funzionalità del report. Stiamo continuando a valutare la portata dell'impatto, monitorare la salute dei servizi e implementare azioni correttive come opportuno. Forniremo ulteriori aggiornamenti in quanto ulteriori informazioni diventano disponibili.

2. 28 settembre 2026 alle ore 09:26 UTCresolved

   Il problema riguardante i cruscotti di segnalazione Power BI nella regione APAC è stato risolto. L'indagine iniziale indica che è stato richiesto un aggiornamento di configurazione dopo un aggiornamento recente. I nostri team tecnici hanno completato la necessaria bonifica, e la successiva convalida ha confermato che i cruscotti interessati sono ora accessibili e operativi come previsto. Tutti i servizi sono tornati al normale funzionamento, e questo incidente è ora considerato risolto.

3. 26 ottobre 2026 alle ore 12:10 UTCpostmortem

   **Descrizione:** Flexera One- IT Visibility- APAC - Segnalazione cruscotti non disponibili **Timeframe:** 28 settembre 2026, 1:38 PDT al 28 settembre 2026, 2:15 **Riepilogo incidente** Lunedì 28 settembre 2026, alle ore 1:38 PDT, Flexera ha identificato un problema che riguarda l'accesso ai cruscotti di segnalazione Power BI per i clienti nella regione APAC. I nostri team tecnici sono stati prontamente impegnati e l'indagine iniziale ha confermato che l'impatto era limitato all'APAC, mentre le altre regioni sono rimaste reattive. Ulteriori indagini hanno determinato che le modifiche di configurazione associate a una migrazione pianificata di identità e gestione degli accessi hanno interessato le impostazioni di connessione richieste dai servizi di reporting. Durante l'applicazione di queste modifiche, le impostazioni di connessione dei servizi di reporting sono state ripristinate ai valori che non contengono gli indirizzi di servizio completi necessari per una comunicazione di successo. Di conseguenza, i servizi interessati non sono riusciti ad avviare correttamente, con conseguente indisponibilità dei cruscotti di segnalazione Power BI per i clienti APAC. Per ripristinare il servizio, il team tecnico ha corretto manualmente le impostazioni di connessione interessate nell'ambiente APAC. Questa comunicazione ripristinata tra i servizi di reporting e autenticazione, permettendo ai servizi interessati di recuperare. Dopo il restauro, la convalida ha confermato che i cruscotti di segnalazione Power BI erano accessibili e funzionavano normalmente a circa 2:15 PDT. ♪Root Cause ♪ L'incidente è stato causato da impostazioni di connessione errate applicate all'ambiente APAC durante una modifica di configurazione associata alla migrazione di identità e gestione degli accessi. La modifica reimposta gli indirizzi di connessione dei servizi di reporting ai valori che non contengono gli indirizzi completi necessari per una comunicazione di successo con i servizi di autenticazione. Di conseguenza, i servizi di reporting interessati non sono riusciti a iniziare correttamente, rendendo Power BI dashboard di reporting non disponibili per i clienti nella regione APAC. Fattori di distribuzione * Incongruenza di configurazione: Gli indirizzi di connessione richiesti erano stati precedentemente aggiornati direttamente nell'ambiente, ma non sono stati riflessi nella configurazione di distribuzione. Di conseguenza, il successivo cambiamento di configurazione reintrodusse i valori errati. * Deployment validation gap: Il processo di distribuzione non ha identificato le impostazioni di connessione errate prima che colpissero la disponibilità dei servizi. * Cambia il coordinamento e la convalida della dipendenza: Il processo di migrazione non ha pienamente tenuto conto dei requisiti di configurazione di tutti i servizi a carico, causando l'applicazione di modifiche di endpoint senza la preventiva convalida attraverso le dipendenze dei servizi interessati. ** Azioni di correzione ** I nostri team hanno eseguito le seguenti azioni per ripristinare i servizi alla normalità: * Le impostazioni di connessione interessate sono state corrette per ripristinare la comunicazione tra i servizi di reporting e autenticazione. * I servizi interessati recuperati e la convalida ha confermato che i cruscotti di segnalazione Power BI sono stati accessibili e operativi normalmente. * La configurazione è stata successivamente corretta per garantire che le impostazioni di connessione richieste siano mantenute in modo coerente per future distribuzioni. **Misure di prevenzione complesse** Sono state identificate le seguenti azioni e sono state elaborate per ridurre la probabilità di ricorrenza e migliorare la resilienza dei servizi: * Gestione configurazione: assicurarsi che le modifiche di configurazione del servizio siano gestite in modo coerente per evitare discrepanze tra impostazioni distribuite e configurazioni mantenute. * Validazione di distribuzione: Rivedere le modifiche di configurazione pianificate prima dell'implementazione per verificare che le impostazioni di connessione di servizio richieste rimangano corrette. * Consistenza di configurazione: assicurarsi che le impostazioni di connessione critica siano mantenute nelle sorgenti di configurazione appropriate e non dipendono dalle modifiche manuali agli ambienti individuali. * Cambia coordinamento: Migliora il coordinamento per le migrazioni pianificate e le modifiche di configurazione, compresa la convalida dei requisiti e delle dipendenze dei servizi interessati. * Protezioni di distribuzione: rafforzare i controlli di pre-deployment per identificare le impostazioni di configurazione errate prima di causare guasti di servizio.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 settembre 2026 alle ore 23:18 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda l'integrazione di IT Asset Management e i servizi App Portal in tutte le regioni. I clienti che utilizzano le integrazioni basate su API colpite possono verificarsi guasti di autenticazione derivanti da errori HTTP 401 non autorizzati, che possono impedire che le richieste vengano completate con successo. Gli utenti di App Portal possono anche riscontrare errori durante la presentazione delle richieste. Priorità: P2 Attività di restauro: I nostri team tecnici stanno attivamente indagando sul problema e valutando le azioni correttive. Le attività di indagine e validazione sono in corso, e stiamo lavorando per ripristinare la normale funzionalità di servizio il più rapidamente possibile. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 26 settembre 2026 alle ore 05:31 UTCidentified

   Il hotfix corretto è attualmente in attesa di completamento del processo di costruzione, che sta richiedendo più tempo del previsto. Una volta completata la costruzione, i nostri team tecnici procederanno con la validazione UAT prima di andare avanti con la distribuzione della produzione. Il team sta anche lavorando per confermare il piano di distribuzione, la proprietà e la timeline prevista. Ulteriori aggiornamenti saranno forniti come tali attività progrediscono.

3. 26 settembre 2026 alle ore 12:30 UTCmonitoring

   I nostri team hanno implementato con successo un hotfix, e la validazione iniziale conferma che i servizi sono operativi come previsto. Stiamo continuando a monitorare attentamente l'ambiente in attesa della conferma da parte dei clienti interessati.

4. 27 settembre 2026 alle ore 05:39 UTCmonitoring

   Le API funzionano come previsto, e gli errori precedentemente osservati non vengono più rilevati. L'incidente rimane in monitoraggio mentre viene completata la convalida aggiuntiva e si ottiene la conferma del cliente.

5. 28 settembre 2026 alle ore 17:14 UTCresolved

   Dopo le attività di bonifica completate nel fine settimana, abbiamo continuato a monitorare i servizi interessati per convalidare la stabilità e il recupero sostenuti. La convalida del cliente è stata ricevuta confermando che le funzionalità di App Portal e l'elaborazione delle richieste API funzionano normalmente. Ulteriori indagini hanno identificato un problema che riguarda l'elaborazione dell'autenticazione all'interno di un componente di servizio, con conseguente errore HTTP 401 non autorizzato per le richieste e gli errori delle API colpite durante la presentazione delle richieste tramite App Portal. I nostri team tecnici hanno implementato azioni correttive per affrontare il problema e hanno eseguito una validazione aggiuntiva dopo aver identificato e risolto un problema separato incontrato durante il processo di bonifica. A seguito della bonifica e del monitoraggio esteso, i servizi sono rimasti stabili senza ulteriori problemi osservati. Verrà condotta un'analisi completa delle cause, e un rapporto post-incidente sarà condiviso nel dettaglio la causa principale, le attività di bonifica e le azioni correttive identificate come parte dell'indagine.

6. 8 ottobre 2026 alle ore 11:25 UTCpostmortem

   **Descrizione:** Flexera One – IT Asset Management – Tutte le regioni – App Portal Errors and API Request Falls **Timeframe:** 24 settembre 2026, 12:12 PM PDT – 26 settembre 2026, 4:38 AM PDT **Riepilogo incidente** A partire dal 24 settembre 2026, a circa 12:12 PM PDT, i clienti che utilizzano le integrazioni basate su API con Flexera One IT Asset Management \(ITAM\) hanno sperimentato guasti di autenticazione che hanno restituito le risposte non autorizzate HTTP 401. Gli utenti di App Portal hanno anche incontrato errori durante la presentazione delle richieste, e le integrazioni come App Broker e Business Adapter che si basano su queste API sono state interessate. L'impatto è stato osservato in tutte le regioni del Nord America, Europa e Asia-Pacifico. I team tecnici hanno indagato e confermato che i guasti non erano legati alle credenziali del cliente o alla configurazione del cliente. I registri delle applicazioni hanno dimostrato che i componenti necessari per autenticare queste richieste non erano in grado di inizializzare. Ulteriori indagini hanno determinato che il comportamento è stato introdotto da un hotfix distribuito come misura preventiva durante la risposta al precedente evento di caricamento del menu ITAM il 24 settembre. I team tecnici hanno riprodotto il comportamento nel test, sviluppato una correzione correttiva, e convalidato. Durante la validazione della distribuzione, è stato identificato e affrontato un problema di caricamento dei componenti secondari tramite un hotfix aggiornato. A seguito dell'implementazione del hotfix aggiornato alla produzione, i team tecnici hanno verificato che la funzionalità API funzionava come previsto, e il servizio è stato ripristinato il 26 settembre a circa 4:38 AM PDT. L'incidente si è poi spostato a un monitoraggio prolungato mentre la conferma del cliente è stata ottenuta e la conferma è stata ricevuta il 28 settembre. Dopo il ripristino del servizio, sono stati segnalati e indagati separatamente i guasti di autenticazione intermittenti isolati dall'incidente principale. I team tecnici hanno individuato ulteriori condizioni di connessione e di configurazione specifiche per l'ambiente e implementato ulteriori hotfix, che sono stati convalidati fino al 30 settembre. Il monitoraggio continuato e la revisione dei clienti attraverso il 1 ° ottobre hanno confermato che il problema non poteva più essere riprodotto e che non erano stati osservati ulteriori eventi. ♪Root Cause ♪ L'incidente è stato causato da un difetto in un hotfix che è stato distribuito come misura preventiva durante la risposta al precedente evento di caricamento del menu ITAM il 24 settembre. Il hotfix ha rimosso una dipendenza dai componenti di autenticazione dell'applicazione e ha cambiato il modo in cui l'applicazione legge la configurazione utilizzata per connettersi ai servizi di autenticazione. Le impostazioni richieste sono state presenti nella configurazione distribuita. Tuttavia, l'applicazione ha tentato di leggerli utilizzando un metodo che non è supportato per la configurazione caricata a runtime. Di conseguenza, i componenti necessari per l'autenticazione non potrebbero essere inizializzati e le richieste di autenticazione richieste sono state rifiutate come non autorizzate. Ciò ha prodotto gli errori API e gli errori di richiesta App Portal che i clienti hanno sperimentato. Lo stesso comportamento si è verificato nell'ambiente di convalida della pre-produzione quando il hotfix è stato applicato lì. Non è stato identificato prima che il hotfix raggiunto Produzione perché le API interessate non sono attivamente utilizzate in quell'ambiente, e l'avviso di errore specifico non era ancora in atto per loro. La correzione iniziale ha affrontato il difetto di configurazione primaria. Durante la successiva convalida e monitoraggio, sono state identificate ulteriori condizioni di configurazione relative al carico dei componenti, alla connessione e all'ambiente e sono state richieste ulteriori correzioni di calore prima della conferma della stabilità. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. Incident Response Initiated: i team tecnici hanno iniziato a indagare dopo che i clienti hanno segnalato guasti di autenticazione e errori API. 2. Valutazione e configurazione del cliente: i team tecnici hanno confermato che i guasti non erano correlati alle credenziali del cliente o alla configurazione, e hanno confermato che l'impatto esteso a più regioni. 3. Underlying Condizione Identificata: i team tecnici hanno determinato che le impostazioni di autenticazione richieste erano presenti, ma non potevano essere lette in runtime, e hanno riprodotto il comportamento in testing. 4. Correttivo Fix Sviluppato e convalidato: Il codice dell'applicazione è stato aggiornato per leggere le impostazioni utilizzando un metodo supportato. I test di convalida hanno confermato che gli errori di autenticazione non si sono più verificati. 5. Correttivo Fix Deployed and Service Restored: Un problema di caricamento dei componenti secondari identificato durante la validazione di distribuzione è stato affrontato attraverso un hotfix aggiornato. Dopo che l'aggiornamento di hotfix è stato distribuito alla produzione, i team tecnici hanno verificato che la funzionalità API era operativa come previsto. 6. Monitoraggio esteso e Convalida del cliente: i team tecnici hanno monitorato il comportamento del servizio durante il fine settimana e hanno ottenuto la conferma da un cliente interessato. 7. Post-Incident Remediation: Dopo i fallimenti intermittenti isolati sono stati segnalati dopo il ripristino del servizio, i team tecnici hanno implementato ulteriori hotfix e convalidati fino al 30 settembre. Il monitoraggio e la revisione dei clienti hanno continuato fino al 1 ottobre per confermare che il problema non è più avvenuto. **Misure di prevenzione complesse** Dopo l'incidente, abbiamo condotto una retrospettiva per rivedere la causa tecnica, il processo di convalida di hotfix, le capacità di monitoraggio e i fattori che hanno contribuito all'impatto del cliente. Sono state completate o attuate le seguenti misure: 1. Correzione di configurazione di runtime: L'applicazione è stata corretta per leggere la sua configurazione di autenticazione utilizzando un metodo supportato e sono stati implementati e convalidati ulteriori hotfix in ambienti di produzione. 2. Monitoraggio delle API e Alerting: avviso di errore viene aggiunto per le API interessate in modo che i guasti di autenticazione vengano rilevati in ambienti pre-produzione e produzione, anche quando il servizio non viene utilizzato attivamente. 3. Processo di convalida di Hotfix: Stiamo valutando ulteriori controlli dei servizi dipendenti, come le integrazioni API e la funzionalità App Portal, come parte della validazione hotfix prima che le modifiche siano approvate per la produzione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 settembre 2026 alle ore 16:19 UTCinvestigating

   Descrizione: Stiamo indagando su un problema che riguarda un sottoinsieme di clienti di Flexera One IT Asset Management. I clienti interessati possono sperimentare i dati mancanti dell'inventario o i risultati vuoti quando si accede alla vista All Inventory e alle relative viste basate sull'inventario. Il problema è limitato a un sottoinsieme di clienti in Nord America. Priorità: P2 Attività di ripristino: i team tecnici stanno attivamente indagando sul problema e esaminando i flussi di lavoro di elaborazione dati dell'inventario associati alla funzionalità interessata. La portata dell'impatto viene convalidata mentre vengono valutate le opzioni di mitigazione e recupero. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 25 settembre 2026 alle ore 18:50 UTCidentified

   I team tecnici hanno identificato una probabile causa del problema associato a un recente cambiamento di livello di capacità che interessa l'elaborazione dei dati dell'inventario. Le attività di recupero sono in corso, tra cui rollback e azioni correttive progettate per ripristinare il normale elaborazione dati dell'inventario. I team tecnici stanno lavorando attivamente attraverso la bonifica e la convalida del recupero per i clienti interessati. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

3. 25 settembre 2026 alle ore 21:22 UTCidentified

   I team tecnici continuano a lavorare attraverso attività di bonifica associate al problema e stanno attivamente eseguendo azioni di recupero progettate per ripristinare il normale elaborazione dati dell'inventario. Durante l'esecuzione, i team hanno incontrato ulteriori condizioni che hanno richiesto modifiche all'approccio di bonifica, e le attività di recupero aggiornate sono attualmente in corso. I team tecnici rimangono attivamente impegnati e stanno lavorando continuamente per completare la bonifica e ripristinare il servizio normale per i clienti interessati il più rapidamente possibile. Apprezziamo la vostra pazienza mentre questi sforzi continuano e si scusano per l'impatto in corso. Ulteriori aggiornamenti saranno forniti come progresso significativo è fatto.

4. 26 settembre 2026 alle ore 00:55 UTCidentified

   I team tecnici continuano a lavorare attraverso attività di bonifica associate al problema e stanno attivamente eseguendo rollback e azioni correttive progettate per ripristinare il normale elaborazione dei dati dell'inventario. Le attività di recupero rimangono in corso e i team tecnici stanno monitorando attivamente l'esecuzione come procedere di bonifica.

5. 26 settembre 2026 alle ore 05:25 UTCmonitoring

   I nostri team tecnici hanno completato con successo l'attività di bonifica richiesta. I compiti di blocco sono stati cancellati. La validazione post-remediazione ha confermato che le funzioni e le procedure relative al database sono operative nello stato previsto. I team continueranno a monitorare l'ambiente per garantire la stabilità.

6. 26 settembre 2026 alle ore 07:13 UTCresolved

   Tutti i controlli di convalida sono stati completati con successo e i servizi sono tornati al normale funzionamento. Il problema è risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 settembre 2026 alle ore 21:43 UTCidentified

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda Spot Ocean per AWS. I clienti potrebbero non essere in grado di lanciare nuove istanze a causa di errori di provisioning delle istanze. Di conseguenza, i cluster interessati potrebbero non essere in grado di scalare come previsto. I carichi di lavoro esistenti rimangono operativi. I nostri team tecnici stanno indagando attivamente la portata e l'impatto del problema. Priorità: P2 Attività di ripristino: I nostri team tecnici hanno identificato un potenziale problema relativo a un recente cambiamento che riguarda il provisioning delle istanze e stanno convalidando attivamente l'impatto. Le attività di mitigazione sono in corso, tra cui rollback di un cambiamento recente, mentre le squadre monitorano il recupero e il comportamento di servizio. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 24 settembre 2026 alle ore 22:16 UTCresolved

   Ulteriori indagini hanno determinato che un cambiamento recente che riguarda il comportamento di provisioning delle istanze ha contribuito al problema. I team tecnici hanno completato un rollback del cambiamento e hanno convalidato il recupero. Dopo il rollback, i livelli di errore tornarono alla normale e la nuova disposizione delle istanze riprese con successo. Durante l'incidente, le istanze e i carichi di lavoro esistenti sono rimasti operativi. L'impatto è stato limitato ai nuovi lanci delle istanze e alle operazioni di scale-up dei cluster. Il problema è ora considerato risolto. Un dettagliato rapporto post-mortem sarà condiviso dopo il completamento dell'analisi della causa principale e della revisione post-incidente, documentando la sequenza completa degli eventi, fattori di contributo, lezioni apprese e qualsiasi azione di follow-up identificata.

3. 9 ottobre 2026 alle ore 06:33 UTCpostmortem

   **Descrizione:** Spot Ocean for AWS – Inadempimento **Timeframe:** 24 settembre 2026, 12:00 PDT al 24 settembre 2026, 2:54 PM PDT **Riepilogo incidente** Il 24 settembre 2026 Spot Ocean for AWS ha sperimentato un problema che ha impedito ad alcuni clienti di lanciare nuove istanze. Di conseguenza, i cluster interessati non erano in grado di scalare come previsto quando era necessaria una capacità di calcolo aggiuntiva. Le istanze e i carichi di lavoro esistenti sono rimasti operativi durante l'incidente. L'impatto è stato limitato a nuove operazioni di provisioning delle istanze e scale-up dei cluster. Il team tecnico ha identificato che un recente cambiamento software ha introdotto comportamenti inaspettati durante il processo di provisioning delle istanze. La modifica è stata rimossa, che ha eliminato gli errori di provisioning e ripristinato il normale funzionamento del servizio. Dopo il rollback, il problema del software sottostante è stato identificato e corretto. La funzionalità aggiornata ha subito una validazione aggiuntiva per garantire che il problema sia completamente affrontato prima di essere reintrodotto nell'ambiente di produzione. I team tecnici hanno convalidato il lancio di istanze di successo dopo il rollback, e la convalida del cliente ha confermato che il nuovo provisioning delle istanze funzionava come previsto. L'incidente è stato risolto alle 14:54 PM PDT il 24 settembre 2026. ♪Root Cause ♪ L'incidente è stato causato da un recente cambiamento software che ha introdotto il comportamento involontario durante il provisioning di istanze AWS. Il cambiamento ha interessato il modo in cui determinate informazioni di configurazione del cluster sono state elaborate, con conseguente mancanza di provisioning per alcune operazioni di scale-up. Mentre il cambiamento è stato progettato per supportare il tagging per specifiche risorse AWS, il suo comportamento ha interessato anche altre configurazioni cluster supportate. In determinate condizioni, la logica di tagging aggiornata ha comportato l'invio di informazioni di tag duplicati nell'ambito della richiesta di provisioning dell'istanza. AWS ha respinto queste richieste perché le informazioni del tag non soddisfavano i requisiti previsti. Di conseguenza, Spot Ocean non era in grado di completare con successo la fornitura di alcune nuove istanze. Ciò ha influito principalmente sul lancio di nuove istanze e sulle operazioni di scale-up dei cluster. Le istanze esistenti erano già state fornite con successo e quindi continuarono ad operare normalmente durante l'incidente. La funzionalità sottostante è stata corretta e viene eseguita una validazione aggiuntiva per garantire che il comportamento aggiornato funzioni costantemente attraverso le configurazioni di cluster AWS supportate prima di essere restituito alla produzione. ** Azioni di correzione ** I nostri team hanno eseguito le seguenti azioni per ripristinare i servizi alla normalità: * Rolled back the software change, ripristinando il normale provisioning delle istanze. * Identificata e corretta il problema sottostante nella funzionalità interessata. * Convalida aggiuntiva della funzionalità corretta. * Introduce ulteriori salvaguardie per consentire la funzionalità aggiornata di essere rimossa in modo controllato. * Convalida che le nuove operazioni di provisioning delle istanze e di scaling dei cluster funzionassero come previsto dopo il rollback. **Misure di prevenzione complesse** * Espandi test automatizzati per il provisioning di casi e scenari di scaling di cluster. * Aumentare i test di regressione attraverso le configurazioni di cluster AWS supportate. * Espandi i test end-to-end per i flussi di lavoro di scaling. * Migliorare il monitoraggio e l'avviso per il provisioning e i guasti di scaling. * Rafforzare la convalida dei cambiamenti prima della distribuzione della produzione. * Introdurre ulteriori salvaguardie per rollout controllato dei cambiamenti che influiscono sul comportamento di provisioning. * Aumentare la copertura di prova per i casi di bordo e gli scenari di gestione degli errori.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 settembre 2026 alle ore 20:46 UTCmonitoring

   Descrizione dell'incidente: All'inizio di oggi, un problema che riguarda l'elaborazione dell'inventario in Flexera One IT Asset Management (ITAM) nella regione NAM ha colpito un sottoinsieme di clienti. L'indagine ha identificato che i caricamenti di inventario sono stati ricevuti con successo, ma non sono stati trattati per i clienti interessati, con conseguente ritardo ai dati di inventario riflessi all'interno di Flexera One ITAM. Le azioni di recupero sono state implementate e l'elaborazione dell'inventario ha ripreso con successo. I file di inventario continuano a elaborare normalmente; tuttavia, il recupero del backlog rimanente è ancora in corso e viene monitorato attraverso questo incidente. Priorità: P2 Attività di ripristino: i team tecnici hanno implementato azioni di recupero che hanno ripristinato l'elaborazione dei file di inventario e hanno convalidato l'elaborazione di successo attraverso il monitoraggio e la registrazione. L'operazione di servizio rimane stabile, e il recupero di backlog continua come i file di inventario precedentemente in coda vengono elaborati. I team tecnici stanno monitorando attivamente i progressi del recupero, la salute dei servizi e la riduzione del backlog mentre continuano le attività di validazione in corso. Aggiornamenti precedenti relativi alle fasi precedenti di questo incidente possono essere trovati nella storia incidente collegata di seguito. Ulteriori aggiornamenti saranno forniti come i progressi di recupero backlog e le attività di validazione continuano. https://status.flexera.com/incidents/5wrg6jl9bj2h

2. 25 settembre 2026 alle ore 08:15 UTCmonitoring

   Il recupero di backlog continua mentre i file di inventario precedentemente in coda vengono elaborati. I livelli di backlog sono ora all'interno di una gamma accettabile, con un'organizzazione che rimane al di sopra dei livelli previsti. I team tecnici continuano a monitorare il recupero, la salute dei servizi e l'attività di elaborazione, mentre la convalida rimane in corso.

3. 25 settembre 2026 alle ore 13:28 UTCresolved

   Il backlog accumulato durante l'incidente è stato elaborato con successo e i livelli di lavorazione sono tornati a normali intervalli operativi. I nostri team hanno completato la validazione del recupero, e questo incidente viene risolto. Ulteriori dettagli relativi alla causa sottostante e alle azioni intraprese saranno forniti nella relazione post-mortem.

4. 23 ottobre 2026 alle ore 17:27 UTCpostmortem

   **Descrizione:** Flexera One - IT Asset Management - NAM - Inventory Processing Delays **Timeframe:** 22 settembre 2026, 7:05 PM PDT - 25 settembre 2026, 5:30 **Riepilogo incidente** Il 24 settembre 2026, i team tecnici hanno iniziato a indagare i rapporti degli aggiornamenti di inventario ritardati che interessano un sottoinsieme di clienti che utilizzano Flexera One IT Asset Management \(ITAM\) nella regione Nord America \(NAM\). Anche se i file di inventario sono stati caricati con successo e sono rimasti disponibili, alcuni clienti hanno sperimentato ritardi nell'elaborazione di questi file, impedendo che le ultime informazioni di inventario vengano riflesse nell'applicazione. Le informazioni sullo stato di Beacon visualizzate in ITAM potrebbero anche essere state obsolete per i clienti interessati. La lavorazione dell'inventario è continuata normalmente per altri clienti. Il problema si è verificato dopo l'attività di rilascio di produzione ITAM 2026R1.3 il 22 settembre 2026. L'indagine ha identificato un'interruzione del processo responsabile del trasferimento dei file di inventario caricati ai servizi di elaborazione dell'inventario ITAM. Mentre i file interessati sono rimasti disponibili nello storage, non sono stati inoltrati per l'elaborazione. I team tecnici hanno anche osservato errori di applicazione elevati durante l'indagine, anche se questi errori non sono stati definitivamente stabiliti come la causa dell'interruzione. I team tecnici hanno eseguito un riavvio mirato del componente di servizio interessato, ripristinando il trasferimento dei file di inventario e consentendo l'elaborazione di riprendere per i clienti precedentemente interessati. Per ulteriori indagini è stato possibile effettuare ulteriori indagini. Tuttavia, un significativo backlog dei file di inventario si era accumulato durante l'interruzione e richiedeva tempo supplementare per elaborare. Dopo il restauro del trattamento, i team tecnici hanno continuato a monitorare l'attività dell'inventario e il backlog accumulato. Entro venerdì 25 settembre 2026, a circa 5:30 PDT, il backlog relativo agli incidenti era tornato a normali livelli operativi, confermando il recupero dell'elaborazione dell'inventario. ♪Root Cause ♪ L'incidente è stato causato da un'interruzione del flusso di lavoro di elaborazione dell'inventario dopo l'attività di rilascio di produzione ITAM 2026R1.3 nella regione NAM. Anche se i file di inventario sono stati caricati con successo e sono rimasti disponibili nello storage, il componente responsabile per l'inoltro di questi file al trattamento ITAM ha smesso di trasferire i dati dell'inventario per un sottoinsieme di clienti. Di conseguenza, i file di inventario interessati non sono stati elaborati, ritardando gli aggiornamenti dell'inventario. Il problema non ha riguardato tutti i clienti, come l'elaborazione dell'inventario ha continuato normalmente per altre organizzazioni. L'indagine ha identificato errori e comportamenti applicativi elevati che indicano che il componente di elaborazione interessato non è stato recuperato come previsto. La precisa condizione tecnica responsabile dell'interruzione parziale rimane in fase di indagine. Un riavvio mirato del componente di servizio interessato ha ripristinato l'elaborazione dell'inventario per i clienti colpiti. Il backlog accumulato è stato successivamente elaborato, permettendo agli aggiornamenti dell'inventario di tornare ai livelli normali. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. ** Iniziato l'indagine incidente:** I team tecnici hanno esaminato i rapporti degli aggiornamenti di inventario ritardati che interessano un sottoinsieme di clienti nella regione del NAM e hanno esaminato il flusso di lavoro di elaborazione dell'inventario per determinare la portata del problema. 2. ** Interruzione di elaborazione dell'inventario Identificata:** L'indagine ha confermato che i file di inventario caricati sono stati disponibili nello storage ma non sono stati inoltrati ai servizi di elaborazione per i clienti interessati. 3. **Riavviata la componente del servizio:** Un riavvio mirato del componente di servizio interessato ha ripristinato il trasferimento dei file di inventario e ha permesso l'elaborazione di riprendere per i clienti precedentemente interessati. 4. ** Registrazione diagnostica supplementare Abilitato:** L'ulteriore registrazione è stata abilitata per catturare ulteriori informazioni tecniche e sostenere l'indagine continuata sull'interruzione di elaborazione sottostante. 5. **Recupero del Backlog dell'inventario Monitorato:** I team tecnici hanno monitorato il backlog dell'inventario accumulato dopo il ripristino dell'elaborazione e hanno confermato che i file di inventario sono stati elaborati con successo. 6. ** Servizio di recupero convalidato: ** I team tecnici hanno confermato che il backlog relativo agli incidenti era tornato ai normali livelli operativi entro il 25 settembre e che l'elaborazione dell'inventario è rimasta stabile. **Misure di prevenzione complesse** A seguito dell'incidente, abbiamo condotto una retrospettiva per rivedere il parziale guasto dell'inventario, l'architettura di consegna dell'inventario esistente, le informazioni diagnostiche disponibili e le opportunità per migliorare l'affidabilità di elaborazione e la visibilità di guasto. Sono in corso le seguenti azioni correttive e attività di miglioramento: 1. ** Miglioramento dell'architettura di elaborazione dell'inventario:** Il lavoro è progettato per semplificare l'integrazione dell'inventario, consentendo a ITAM di recuperare i file di inventario caricati direttamente dallo strato di archiviazione piuttosto che affidarsi al servizio di inoltro intermedio esistente. Questa modifica rimuoverà una dipendenza aggiuntiva dal percorso di elaborazione e fornirà un maggior controllo sull'elaborazione, la gestione del backlog, la capacità e il recupero. 2. ** Diagnostica di guasto migliorata: ** La registrazione diagnostica e la telemetria necessaria per catturare lo stato di servizio rilevante durante un parziale guasto di elaborazione dell'inventario saranno valutate e migliorate come opportuno. Ciò fornirà informazioni tecniche migliorate per supportare la determinazione del root-cause se una condizione simile si attenua.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 settembre 2026 alle ore 14:08 UTCinvestigating

   Descrizione: Stiamo indagando su un problema che riguarda un sottoinsieme di clienti che utilizzano Flexera One IT Asset Management (ITAM) nella regione NAM. I clienti interessati possono sperimentare problemi con la navigazione, comprese le voci di menu non visibili nell'interfaccia ITAM, con conseguente accesso limitato ad alcune funzionalità. Priorità: P2 Attività di restauro: I nostri team tecnici stanno attivamente indagando su questo problema e lavorano per ripristinare la piena funzionalità. Continueremo a fornire aggiornamenti come ulteriori informazioni diventano disponibili.

2. 24 settembre 2026 alle ore 15:44 UTCinvestigating

   I team tecnici continuano a indagare sul problema che interessa Flexera One IT Asset Management nell'ambiente NAM Production. Gli sforzi attuali si concentrano sull'individuazione in cui si verificano i guasti all'interno del flusso di lavoro interessato. I team stanno esaminando il comportamento delle applicazioni, i processi di validazione, le interazioni dei servizi, la telemetria della piattaforma e le eventuali recenti modifiche o condizioni ambientali che possono contribuire al problema. L'indagine rimane in corso, e ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

3. 24 settembre 2026 alle ore 17:48 UTCinvestigating

   I team tecnici hanno fatto progressi restringendo la portata del problema e si concentrano sui componenti applicativi coinvolti nel caricamento dell'accesso utente e delle informazioni di navigazione. I risultati attuali indicano che alcune richieste all'interno di questo processo non stanno completando come previsto, con conseguente elementi di menu che non riescono a caricare per gli utenti interessati. Il lavoro rimane in corso per determinare la causa sottostante e convalidare l'appropriata bonifica. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

4. 24 settembre 2026 alle ore 18:39 UTCmonitoring

   I team tecnici stanno attualmente osservando un comportamento di servizio stabile e una significativa riduzione degli errori associati a questo incidente. Le funzioni di applicazione colpite funzionano normalmente sulla base dei dati attuali di telemetria e monitoraggio. Mentre la stabilità dei servizi è migliorata, i team tecnici continuano a monitorare attentamente l'ambiente per confermare che il problema non si ripete. L'indagine sulla causa sottostante rimane in corso. Continueremo a monitorare e fornire ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

5. 24 settembre 2026 alle ore 20:33 UTCresolved

   I team tecnici hanno confermato che il servizio è rimasto stabile e la funzionalità IT Asset Management interessata funziona normalmente. Durante l'indagine, i team tecnici hanno identificato le condizioni di saturazione di connessione che riguardano i componenti applicativi responsabili delle funzioni di accesso e navigazione degli utenti. Queste condizioni sono state osservate durante la finestra di impatto e coincidono con i guasti sperimentati dagli utenti interessati. La funzionalità del servizio recuperata, e la convalida del cliente ha confermato che le pagine ITAM interessate e gli elementi del menu sono stati caricati con successo. A seguito di un periodo di monitoraggio senza ricorrenza del problema, l'incidente è ora considerato risolto. Una revisione dettagliata dell'incidente è in corso per convalidare ulteriormente i fattori che contribuiscono e identificare eventuali ulteriori azioni preventive.

6. 8 ottobre 2026 alle ore 11:23 UTCpostmortem

   **Descrizione:** Flexera One – IT Asset Management – NAM – Menu Articoli non in caricamento **Timeframe:** 24 settembre 2026, 5:27 AM PDT – 24 settembre 2026, 10:48 AM PDT **Riepilogo incidente** Il 24 settembre 2026, i clienti che utilizzano Flexera One IT Asset Management \(ITAM\) nella regione del Nord America hanno sperimentato problemi intermittenti di caricamento delle voci dei menu delle applicazioni e l'accesso a porzioni di funzionalità ITAM. Alcuni clienti hanno incontrato menu parzialmente caricati o mancanti, messaggi di errore e comportamento di applicazione inconsistente. I team tecnici hanno esaminato il problema attraverso l'applicazione e i servizi di supporto e hanno identificato l'uso di connessione anormale all'interno dei componenti che supportano la funzionalità ITAM. Poiché la capacità di connessione disponibile è diventata esausta, alcune richieste di applicazione non potrebbero più essere completate con successo, con conseguente guasti legati all'autenticazione e la prevenzione di porzioni di funzionalità ITAM dal caricamento. Il servizio ha cominciato a recuperare a circa 10:46 PDT, prima che l'implementazione del hotfix correttivo è stato completato. Gli ultimi errori di applicazione correlati sono stati registrati alle 10:48 AM PDT. I team tecnici hanno continuato a indagare sulla causa sottostante monitorando l'ambiente e convalidando le funzionalità dei clienti. L'analisi post-incidente ha indicato che i servizi applicativi sui server interessati erano riavviatiti, rilasciando connessioni accumulate e permettendo di stabilire nuove connessioni. Il hotfix correttivo è stato successivamente implementato come misura preventiva per affrontare il comportamento di connessione-handling mentre l'indagine sulla causa sottostante ha continuato. Dopo aver continuato a monitorare e convalidare i clienti, i team tecnici hanno confermato che la funzionalità ITAM era tornata al normale funzionamento. ♪Root Cause ♪ L'incidente è stato causato da un problema di gestione della connessione introdotto durante il rilascio di produzione ITAM 2026 R1.3. Una modifica del flusso di autenticazione dell'applicazione ha causato nuove connessioni di servizio da creare ripetutamente piuttosto che riutilizzare le connessioni esistenti. Nel corso del tempo, queste connessioni hanno accumulato e esaurito la capacità di connessione disponibile all'interno dei componenti applicativi interessati. Una volta esaurita tale capacità, nuove richieste di applicazione non potrebbero essere stabilite con successo. Ciò ha portato a guasti correlati all'autenticazione e ha impedito porzioni di funzionalità ITAM di caricare, causando elementi mancanti del menu, messaggi di errore e perdita intermittente di accesso per i clienti interessati. Un hotfix che correggeva questo comportamento era già stato creato ed era incluso nel piano di distribuzione del rilascio prima dell'implementazione della Produzione. Il hotfix era stato inizialmente designato per l'ambiente di convalida perché la produzione non era ancora stata aggiornata. Esso era destinato ad essere applicato alla produzione come parte del rilascio R1.3, ma non è stato applicato durante la distribuzione di produzione. Di conseguenza, la correzione di connessione-gestione non era in vigore quando il rilascio è andato in diretta. ** Azioni di correzione ** 1. Incident Investigation Iniziato: i team tecnici hanno indagato gli errori dell'applicazione e la perdita intermittente della funzionalità ITAM per determinare la portata e la causa sottostante. 2. Saturazione di connessione Identificata: l'analisi dei componenti di applicazione interessati ha identificato l'accumulo di connessione anormale che era esaurimento capacità di connessione disponibile e la prevenzione di nuove richieste di applicazione da completare con successo. 3. Correttivo Hotfix Confermato: i team tecnici hanno identificato il hotfix esistente che ha corretto il comportamento di connessione utilizzando connessioni di servizio piuttosto che creare nuove connessioni per ogni richiesta. 4. Correttivo Hotfix Deployed: Il hotfix è stato distribuito alla produzione come misura preventiva per affrontare il problema di gestione della connessione e prevenire ulteriori accumulo di connessione. 5. Servizio di recupero convalidato: i team tecnici hanno continuato a monitorare il comportamento delle applicazioni e convalidare la funzionalità del cliente dopo il recupero per confermare che i servizi ITAM erano tornati al normale funzionamento. **Misure di prevenzione complesse** Dopo l'incidente, abbiamo condotto una retrospettiva per rivedere la causa tecnica, il rilascio e il processo di distribuzione hotfix, le capacità di monitoraggio e i fattori che hanno contribuito all'impatto del cliente. Sono state completate o attuate le seguenti misure: 1. Correzione di gestione della connessione: Il cambiamento correttivo è stato implementato per garantire che i collegamenti di servizio siano opportunamente riutilizzati e per evitare l'accumulo di connessione da esaurimento risorse di applicazione disponibili. 2. Convalida della distribuzione di produzione: la correzione della gestione della connessione è stata implementata e validata in tutte le regioni di produzione per garantire un'implementazione coerente. 3. Miglioramenti del processo di rilascio e Hotfix: le procedure di rilascio sono rafforzate in modo che i fissi caldi inclusi nei piani di distribuzione del rilascio siano costantemente designati per la distribuzione di produzione, compresi i fissi inizialmente creati o convalidati prima che l'ambiente di produzione venga aggiornato. 4. Hotfix Process Review: stiamo valutando i miglioramenti al processo di hotfix complessivo per ridurre l'affidabilità sui hotfix di produzione e ridurre ulteriormente il rischio di modifiche correttive richieste non incluse nei futuri release di produzione. 5. Enhanced Application Monitoring: Vengono implementati ulteriori controlli e avvisi a livello di applicazione per migliorare il rilevamento precoce di guasti intermittenti e condizioni di errore anormali prima che si traducano in un impatto più ampio del cliente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 settembre 2026 alle ore 10:11 UTCinvestigating

   Descrizione dell'incidente: Abbiamo identificato un problema che riguarda l'elaborazione dell'inventario in Flexera One IT Asset Management (ITAM) nella regione del NAM, che colpisce un sottoinsieme di clienti. Di conseguenza, alcuni upload di inventario non vengono elaborati correttamente, causando i dati di inventario visualizzati in Flexera One ITAM per essere ritardato e non riflettere l'inventario più recentemente caricato. Priorità: P2 Attività di restauro: I nostri team tecnici stanno attivamente indagando sul problema per identificare la causa sottostante e implementare una correzione. Stiamo continuando a monitorare attentamente la situazione e forniremo ulteriori aggiornamenti mentre l'indagine progredisce.

2. 24 settembre 2026 alle ore 12:27 UTCinvestigating

   Ulteriori indagini indicano che il problema sembra essere associato al servizio responsabile del trasferimento dei dati dell'inventario a ITAM. I nostri team tecnici continuano a indagare sul problema e stanno lavorando per identificare la causa sottostante e determinare l'appropriata bonifica. Continueremo a fornire ulteriori aggiornamenti in quanto ulteriori informazioni diventano disponibili.

3. 24 settembre 2026 alle ore 14:32 UTCmonitoring

   Il nostro team ha eseguito riavviamenti mirati pod, a seguito del quale l'elaborazione dei file di inventario ha ripreso con successo per tutti i clienti interessati. L'elaborazione riuscita è stata validata attraverso registri e grafici di monitoraggio. Continueremo a monitorare attentamente i servizi per garantire la stabilità continua e fornire ulteriori aggiornamenti, poiché ulteriori informazioni diventano disponibili.

4. 24 settembre 2026 alle ore 18:42 UTCmonitoring

   I nostri team tecnici continuano a osservare l'elaborazione di file di inventario di successo e l'operazione di servizio stabile dopo le azioni di recupero. La convalida attraverso il monitoraggio conferma che i file di inventario interessati vengono elaborati con successo. Il recupero di backlog è attualmente in corso, con code di elaborazione dell'inventario che continuano a diminuire mentre i file vengono elaborati. I team tecnici stanno monitorando attivamente i progressi del recupero e la salute generale del servizio, mentre il backlog rimanente viene eliminato. Continueremo a fornire aggiornamenti come progressi di recupero.

5. 24 settembre 2026 alle ore 20:32 UTCresolved

   Questo incidente è stato inavvertitamente segnato come risolto con un aggiornamento destinato ad un incidente separato. Il recupero dell'elaborazione dell'inventario rimane sotto controllo poiché il restante backlog continua ad essere chiaro. I team tecnici continuano a osservare l'elaborazione di file di successo e l'operazione di servizio stabile. Gli aggiornamenti in corso di recupero e il monitoraggio del backlog continueranno sotto il nuovo incidente creato: https://status.flexera.com/incidents/vztp63wmxjb Forneremo ulteriori aggiornamenti come i progressi di recupero backlog e la validazione di recupero continua.

6. 23 ottobre 2026 alle ore 17:25 UTCpostmortem

   **Descrizione:** Flexera One - IT Asset Management - NAM - Inventory Processing Delays **Timeframe:** 22 settembre 2026, 7:05 PM PDT - 25 settembre 2026, 5:30 **Riepilogo incidente** Il 24 settembre 2026, i team tecnici hanno iniziato a indagare i rapporti degli aggiornamenti di inventario ritardati che interessano un sottoinsieme di clienti che utilizzano Flexera One IT Asset Management \(ITAM\) nella regione Nord America \(NAM\). Anche se i file di inventario sono stati caricati con successo e sono rimasti disponibili, alcuni clienti hanno sperimentato ritardi nell'elaborazione di questi file, impedendo che le ultime informazioni di inventario vengano riflesse nell'applicazione. Le informazioni sullo stato di Beacon visualizzate in ITAM potrebbero anche essere state obsolete per i clienti interessati. La lavorazione dell'inventario è continuata normalmente per altri clienti. Il problema si è verificato dopo l'attività di rilascio di produzione ITAM 2026R1.3 il 22 settembre 2026. L'indagine ha identificato un'interruzione del processo responsabile del trasferimento dei file di inventario caricati ai servizi di elaborazione dell'inventario ITAM. Mentre i file interessati sono rimasti disponibili nello storage, non sono stati inoltrati per l'elaborazione. I team tecnici hanno anche osservato errori di applicazione elevati durante l'indagine, anche se questi errori non sono stati definitivamente stabiliti come la causa dell'interruzione. I team tecnici hanno eseguito un riavvio mirato del componente di servizio interessato, ripristinando il trasferimento dei file di inventario e consentendo l'elaborazione di riprendere per i clienti precedentemente interessati. Per ulteriori indagini è stato possibile effettuare ulteriori indagini. Tuttavia, un significativo backlog dei file di inventario si era accumulato durante l'interruzione e richiedeva tempo supplementare per elaborare. Dopo il restauro del trattamento, i team tecnici hanno continuato a monitorare l'attività dell'inventario e il backlog accumulato. Entro venerdì 25 settembre 2026, a circa 5:30 PDT, il backlog relativo agli incidenti era tornato a normali livelli operativi, confermando il recupero dell'elaborazione dell'inventario. ♪Root Cause ♪ L'incidente è stato causato da un'interruzione del flusso di lavoro di elaborazione dell'inventario dopo l'attività di rilascio di produzione ITAM 2026R1.3 nella regione NAM. Anche se i file di inventario sono stati caricati con successo e sono rimasti disponibili nello storage, il componente responsabile per l'inoltro di questi file al trattamento ITAM ha smesso di trasferire i dati dell'inventario per un sottoinsieme di clienti. Di conseguenza, i file di inventario interessati non sono stati elaborati, ritardando gli aggiornamenti dell'inventario. Il problema non ha riguardato tutti i clienti, come l'elaborazione dell'inventario ha continuato normalmente per altre organizzazioni. L'indagine ha identificato errori e comportamenti applicativi elevati che indicano che il componente di elaborazione interessato non è stato recuperato come previsto. La precisa condizione tecnica responsabile dell'interruzione parziale rimane in fase di indagine. Un riavvio mirato del componente di servizio interessato ha ripristinato l'elaborazione dell'inventario per i clienti colpiti. Il backlog accumulato è stato successivamente elaborato, permettendo agli aggiornamenti dell'inventario di tornare ai livelli normali. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. ** Iniziato l'indagine incidente:** I team tecnici hanno esaminato i rapporti degli aggiornamenti di inventario ritardati che interessano un sottoinsieme di clienti nella regione del NAM e hanno esaminato il flusso di lavoro di elaborazione dell'inventario per determinare la portata del problema. 2. ** Interruzione di elaborazione dell'inventario Identificata:** L'indagine ha confermato che i file di inventario caricati sono stati disponibili nello storage ma non sono stati inoltrati ai servizi di elaborazione per i clienti interessati. 3. **Riavviata la componente del servizio:** Un riavvio mirato del componente di servizio interessato ha ripristinato il trasferimento dei file di inventario e ha permesso l'elaborazione di riprendere per i clienti precedentemente interessati. 4. ** Registrazione diagnostica supplementare Abilitato:** L'ulteriore registrazione è stata abilitata per catturare ulteriori informazioni tecniche e sostenere l'indagine continuata sull'interruzione di elaborazione sottostante. 5. **Recupero del Backlog dell'inventario Monitorato:** I team tecnici hanno monitorato il backlog dell'inventario accumulato dopo il ripristino dell'elaborazione e hanno confermato che i file di inventario sono stati elaborati con successo. 6. ** Servizio di recupero convalidato: ** I team tecnici hanno confermato che il backlog relativo agli incidenti era tornato ai normali livelli operativi entro il 25 settembre e che l'elaborazione dell'inventario è rimasta stabile. **Misure di prevenzione complesse** A seguito dell'incidente, abbiamo condotto una retrospettiva per rivedere il parziale guasto dell'inventario, l'architettura di consegna dell'inventario esistente, le informazioni diagnostiche disponibili e le opportunità per migliorare l'affidabilità di elaborazione e la visibilità di guasto. Sono in corso le seguenti azioni correttive e attività di miglioramento: 1. ** Miglioramento dell'architettura di elaborazione dell'inventario:** Il lavoro è progettato per semplificare l'integrazione dell'inventario, consentendo a ITAM di recuperare i file di inventario caricati direttamente dallo strato di archiviazione piuttosto che affidarsi al servizio di inoltro intermedio esistente. Questa modifica rimuoverà una dipendenza aggiuntiva dal percorso di elaborazione e fornirà un maggior controllo sull'elaborazione, la gestione del backlog, la capacità e il recupero. 2. ** Diagnostica di guasto migliorata: ** La registrazione diagnostica e la telemetria necessaria per catturare lo stato di servizio rilevante durante un parziale guasto di elaborazione dell'inventario saranno valutate e migliorate come opportuno. Ciò fornirà informazioni tecniche migliorate per supportare la determinazione del root-cause se una condizione simile si attenua.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 settembre 2026 alle ore 10:05 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda l'accesso ai nostri servizi nell'ambiente dell'UE. I clienti dell'UE possono sperimentare problemi di accesso al servizio. Priorità: P1 Attività di restauro: I nostri team tecnici stanno attivamente indagando il problema come priorità e lavorando per ripristinare il servizio normale il più rapidamente possibile.

2. 23 settembre 2026 alle ore 10:24 UTCmonitoring

   I servizi sono stati ripristinati e l'accesso è ora funzionante come previsto. I nostri team stanno monitorando attentamente la piattaforma per garantire una stabilità continua.

3. 23 settembre 2026 alle ore 11:43 UTCresolved

   I nostri team hanno continuato a monitorare la piattaforma e non hanno osservato alcuna ricorrenza del problema. Questo incidente è ora risolto. Continueremo la nostra indagine per determinare la causa principale sottostante e identificare le azioni correttive appropriate. Ulteriori dettagli saranno forniti nel rapporto post-mortem.

4. 26 ottobre 2026 alle ore 10:40 UTCpostmortem

   **Descrizione:** Flexera One - EU - Accesso non disponibile Revisione: * 24 settembre 2026, 2:51 AM PDT al 24 settembre 2026, 3:18 AM PDT * 25 settembre 2026, 3:50 AM al 25 settembre 2026, 4:30 AM PDT **Riepilogo incidente** Il 24 settembre 2026 alle 2:51 AM PDT, i clienti hanno sperimentato guasti di accesso quando si tenta di accedere all'ambiente Flexera One EU Production. L'indagine ha confermato il degrado dei servizi UE Identity and Access Management, che ha impedito ai clienti di accedere alla piattaforma. L'indagine ha identificato un significativo aumento delle connessioni di database associate a traffico elevato da un'unica organizzazione. Ulteriori analisi determinarono che le ripetute richieste a valle generate da altri servizi contribuirono anche all'aumento del carico sui servizi di autenticazione e controllo degli accessi. A 3:18 AM PDT, la funzionalità di login del cliente è stata ripristinata senza intervento tecnico diretto, e la piattaforma è tornata al normale funzionamento. Il 25 settembre 2026 a circa 3:50 PDT, è stato osservato un altro aumento delle connessioni di database, associato al traffico elevato dalla stessa organizzazione. Il carico aumentato è continuato per circa 40 minuti. In risposta, l'autoscaling è stato abilitato per il servizio di gestione delle risorse per aumentare la capacità e migliorare la stabilità della piattaforma.. ♪Root Cause ♪ L'incidente è stato causato da un aumento inaspettato del traffico che ha posto la domanda eccessiva sui servizi di autenticazione dell'UE e le connessioni di database associate. L'aumento del carico ha interessato i servizi responsabili dell'elaborazione delle richieste di autenticazione, con conseguente insufficienza di accesso al cliente nell'ambiente di produzione dell'UE. Le richieste ripetute da altri servizi ai servizi di autenticazione e controllo accessi hanno ulteriormente contribuito al carico elevato. Inoltre, la scalazione automatica non è stata abilitata per il servizio di gestione delle risorse, limitando la sua capacità di aumentare dinamicamente la capacità in risposta a una domanda più elevata. I guadagni nel monitoraggio proattivo e l'avviso limitano anche la capacità di identificare il degrado prima che i clienti hanno sperimentato guasti di accesso. ** Azioni di correzione ** I nostri team hanno eseguito le seguenti azioni per ripristinare i servizi alla normalità: * L'incidente del 24 settembre risolto senza intervento di ingegneria diretta, e la funzionalità di login del cliente è stata ripristinata alle 3:18 AM PDT. * Il 25 settembre, l'autoscaling è stato abilitato per il servizio di gestione delle risorse per aumentare la capacità in risposta alla domanda elevata. * Il team ha continuato a monitorare le connessioni del database e la salute dei servizi per valutare la stabilità della piattaforma. **Misure di prevenzione complesse** Sono state identificate le seguenti azioni e sono state elaborate per ridurre la probabilità di ricorrenza e migliorare la resilienza dei servizi: * Ridimensionamento automatico: revisione della configurazione di autoscaling per il servizio di gestione delle risorse in tutte le regioni di produzione, per garantire la capacità si adatta alle modifiche del carico di lavoro. * Gestione della capacità del database: rivedere le impostazioni del pool di connessione del database e garantire che la scalabilità del servizio rimanga all'interno della capacità di connessione disponibile del database. * Monitoraggio attivo e allerta: Review e introdurre avvisi per la crescita della connessione del database anormale, saturazione del pool di connessione, latenza del servizio, tassi di errore e utilizzo delle risorse. * Monitoraggio del traffico: Migliora la visibilità nei modelli di traffico a livello organizzativo per identificare i picchi di richiesta insoliti prima che colpiscano altri clienti. * Gestione del traffico: Valutare i controlli adeguati di limitazione e limitazione dei tassi per impedire il traffico eccessivo da un'unica organizzazione di influenzare la disponibilità della piattaforma. * Test di carico e capacità: Condurre test di carico utilizzando modelli di traffico rappresentativi dell'incidente per convalidare le prestazioni del servizio e la capacità del database sotto una domanda elevata.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 settembre 2026 alle ore 06:51 UTCinvestigating

   Descrizione dell'incidente: Stiamo attualmente indagando su un problema che riguarda l'ambiente Flexera One IT Asset Management (ITAM) North America Production, che rimane non disponibile a causa della manutenzione programmata che si estende oltre la finestra di manutenzione prevista. L'attività di manutenzione è ancora in corso mentre un database ricostruisce completa. Priorità: P1 Attività di restauro: I nostri team tecnici stanno lavorando attivamente per completare la restante attività di manutenzione e ripristinare il servizio il più rapidamente possibile. L'ETA per la ricostruzione del database è di circa 2 ore. I nostri team stanno monitorando attentamente i progressi e forniranno ulteriori dettagli man mano che saranno disponibili.

2. 23 settembre 2026 alle ore 09:15 UTCinvestigating

   I nostri team tecnici hanno completato una fase importante dell'attività di manutenzione in corso e continuano con i restanti trattamenti necessari per completare l'aggiornamento. Il processo richiede più tempo di quanto originariamente previsto. L'ambiente rimane indisponibile mentre queste attività sono in corso. I team stanno monitorando attivamente le rimanenti opzioni di elaborazione e valutazione per ripristinare il servizio il più rapidamente e in modo sicuro possibile. Ulteriori aggiornamenti saranno forniti come l'aggiornamento progredisce e la timeline di restauro diventa più chiaro.

3. 23 settembre 2026 alle ore 11:47 UTCmonitoring

   L'aggiornamento è stato completato con successo. I nostri team stanno ora lavorando per ripristinare i servizi ed eseguire la convalida post-deployment.

4. 23 settembre 2026 alle ore 13:02 UTCmonitoring

   L'aggiornamento è stato completato con successo, e il sito è ora tornato online. Il nostro team sta eseguendo i controlli di convalida finali per confermare la stabilità del servizio prima di dichiarare l'incidente risolto.

5. 23 settembre 2026 alle ore 15:57 UTCresolved

   Il servizio è stato ripristinato e funziona normalmente. Dopo il recupero, i team tecnici hanno completato attività di monitoraggio e convalida e hanno confermato un funzionamento stabile. L'incidente è ora considerato risolto.

6. 30 settembre 2026 alle ore 16:02 UTCpostmortem

   **Descrizione:** Flexera One – IT Asset Management – Nord America – Service Unavailability Dopo 2026R1.3 Manutenzione **Timeframe:** 22 settembre 2026, 21:00 PDT – 23 settembre 2026, 5:47 **Riepilogo incidente** Il 22 settembre 2026, Flexera condusse il programmato rilascio di produzione 2026R1.3 per Flexera One IT Asset Management nella regione del Nord America. L'aggiornamento è progredito con successo nella maggior parte dei database all'interno dell'ambiente. Tuttavia, quando la finestra di manutenzione prevista si è conclusa alle 9:00 PM PDT, un'operazione di migrazione del database richiesta è rimasta in corso. Poiché l'ambiente di produzione non poteva essere ripristinato fino al completamento della migrazione, IT Asset Management non era disponibile oltre il periodo di manutenzione programmata. La migrazione restante richiedeva una grande ricostruzione dell'indice di database che comportava un volume significativo di dati. L'operazione è diventata il percorso critico per completare il rilascio e ha preso sostanzialmente più di quanto previsto. Dopo la fase iniziale di elaborazione dell'indice, il database ha ancora bisogno di eseguire ulteriori attività di selezione e creazione di indici. Questo lavoro ha continuato per diverse ore e ha esteso la durata complessiva della migrazione. Durante l'indagine, i team tecnici hanno valutato le opzioni di recupero disponibili, compreso se il database interessato potrebbe essere temporaneamente separato dal percorso di migrazione per consentire al resto dell'ambiente di tornare al servizio. A causa della fase di distribuzione e del lavoro di recupero aggiuntivo che questo approccio avrebbe richiesto, il percorso di recupero più affidabile era quello di consentire il funzionamento del database per completare prima di ripristinare l'ambiente. Una volta completata la migrazione del database, i team tecnici hanno iniziato a ripristinare l'applicazione e i servizi di supporto. Durante l'avvio, è stato riscontrato un ulteriore problema di recupero dei servizi che richiedeva interventi manuali prima che il restauro potesse continuare. Dopo la bonifica, i restanti servizi di applicazione e piattaforma sono stati ripristinati con successo. I team tecnici hanno poi completato le attività di validazione, l'accesso al cliente confermato, e hanno eseguito un monitoraggio esteso per verificare la stabilità del servizio. L'impatto del cliente si è concluso il 23 settembre 2026, alle 5:47 PDT. ♪Root Cause ♪ L'outage è stato causato da una discrepanza di configurazione dell'indice del database che è stata identificata durante la migrazione 2026R1.3, con conseguente un grande indice di ricostruzione operazione che ha sostanzialmente superato la finestra di manutenzione prevista. L'indagine post-incidente ha determinato che un indice all'interno del database interessato non corrisponde alla struttura del database prevista dall'attuale rilascio. L'indice era stato precedentemente ricreato utilizzando una definizione precedente che non incorporava un successivo cambiamento di progettazione del database. Durante la distribuzione 2026R1.3, il processo di migrazione ha identificato questa differenza e ha avviato l'operazione di database necessaria per portare l'indice in allineamento con la definizione attuale del database. A causa delle dimensioni eccezionalmente grandi del dataset coinvolto, la ricostruzione risultante è diventata un'operazione a lungo termine e ad alta intensità di risorse che ha notevolmente superato la finestra di manutenzione prevista. Una volta che la ricostruzione era in corso, la durata di lavorazione rimanente non poteva essere prevedibile in modo affidabile, il che ha reso difficile fornire una stima accurata del completamento mentre l'operazione ha continuato. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: * Indice Rebuild Monitorato: L'indice ricostruisce e le restanti attività di aggiornamento del database sono state continuamente monitorate attraverso il completamento. * Opzioni di recupero Valutata: Sono stati valutati gli approcci di restauro disponibili per determinare il percorso più sicuro e affidabile per il ritorno dell'ambiente di produzione al servizio. * Aggiornamento Database Completato: L'indice ricostruisce e le restanti attività di aggiornamento del database sono state completate prima dell'avvio del ripristino delle applicazioni. * Servizi di applicazione e supporto Restaurato: sono stati ripristinati i servizi di applicazione e di supporto. Le azioni mirate di recupero sono state eseguite quando è stato riscontrato un ulteriore problema di assistenza-startup. * Servizio di recupero convalidato: l'accesso del cliente e la funzionalità dell'applicazione sono stati confermati, l'elaborazione di sfondo rimanente è stata controllata e il monitoraggio esteso è stato completato per verificare l'operazione stabile. **Misure di prevenzione complesse** Flexera riconosce il significato e la durata di questo outage e l'impatto che ha avuto sui clienti nella regione del Nord America. Sono state completate un'analisi completa delle cause e una retrospettiva trasversale, e le seguenti misure preventive sono state identificate come parte dello sforzo di miglioramento in corso: 1. Convalida della procedura del database: i team tecnici stanno valutando il modo in cui le procedure di bonifica del database vengono esaminate e mantenute per garantire che rimangano allineate ai requisiti attuali del prodotto in quanto la piattaforma si evolve. 2. Verificazione pre-deployment: vengono valutati i processi di valutazione del rilascio per determinare come possono essere identificate e valutate le differenze di configurazione del database inattese prima dell'inizio della manutenzione di produzione. 3. Valutazione dell'operazione ad alto impatto: i team tecnici stanno valutando come le operazioni di database potenzialmente a lungo termine o ad alta intensità di risorse possono essere identificate durante la preparazione del rilascio in modo che la durata prevista e l'impatto operativo possano essere meglio compresi prima dell'implementazione. 4. Prontezza di rilascio e pianificazione di recupero: le pratiche di prontezza di rilascio e di pianificazione di recupero sono in fase di revisione per migliorare la visibilità in attività che possono influenzare significativamente la durata di distribuzione e tempi di ripristino dei servizi. Fornire servizi affidabili e resilienti rimane una priorità. I risultati dell'analisi e della retrospettiva della causa principale completati sono incorporati in miglioramenti tecnici e operativi volti a ridurre la probabilità di ricorrenza e rafforzare la pianificazione e l'esecuzione delle future attività di manutenzione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 settembre 2026 alle ore 05:56 UTCinvestigating

   Descrizione dell'incidente: Stiamo attualmente indagando su un problema che riguarda un sottoinsieme dei nostri clienti utilizzando Snow Atlas nella regione Australia. I clienti interessati possono sperimentare ritardi nel vedere le ultime informazioni del computer e l'ingestione dei dati possono anche essere influenzati. Priorità: P2 Attività di ripristino: un precedente problema relativo al DNS è stato identificato ed è stato risolto. Tuttavia, si stanno osservando altri errori. I nostri team tecnici stanno attivamente indagando questi errori per determinare la causa sottostante e ripristinare l'elaborazione normale. Continueremo a valutare l'impatto e fornire ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 22 settembre 2026 alle ore 07:19 UTCinvestigating

   I nostri team hanno eseguito riavviamenti di servizio mirati, che hanno migliorato i ritardi di elaborazione. Il monitoraggio indica che i dati dell'inventario vengono aggiornati con successo. I rimanenti errori sono ancora sotto indagine, e i nostri team stanno lavorando per identificare la causa sottostante e implementare una fissazione permanente.

3. 22 settembre 2026 alle ore 10:15 UTCmonitoring

   Le azioni di bonifica hanno risolto i ritardi di trattamento e i problemi di dati stanti. Alcuni problemi residui rimangono e sono attualmente sotto indagine dai nostri team tecnici. I team stanno monitorando i servizi e continueranno a raccogliere e rivedere i registri nelle prossime 24 ore per sostenere l'indagine. Continueremo a monitorare attentamente i servizi e fornire ulteriori aggiornamenti in quanto ulteriori informazioni diventano disponibili.

4. 23 settembre 2026 alle ore 07:05 UTCresolved

   I nostri team hanno continuato a monitorare i servizi durante la notte e hanno confermato che non sono stati osservati nuovi problemi. Inoltre, sono stati completati con successo anche altri controlli spot. Questo incidente si sta risolvendo. Ulteriori informazioni sulla causa principale e le azioni intraprese saranno fornite nella relazione post-mortem.

5. 13 ottobre 2026 alle ore 12:49 UTCpostmortem

   **Descrizione:** Atlante neve- APAC - Ingestione dati e ritardi di elaborazione **Timeframe:** 21 settembre 2026, 5:48 PM PDT al 22 settembre 2026, 3:15 AM PDT **Riepilogo incidente** Lunedì 21 settembre 2026, alle ore 17:48 PDT , un problema ha interessato più inquilini Snow Atlas nella regione Australia Est \(AE\), con conseguente ritardo negli aggiornamenti dei dati dell'inventario. I clienti interessati hanno sperimentato le informazioni del dispositivo obsoleto sulla pagina Computer, mentre Snow Extenders ha mostrato uno stato "Running with Errors". Sono stati osservati anche errori durante l'ingestione dei dati. L'indagine ha identificato un record DNS obsoleto associato a infrastrutture precedentemente decommissionate nella regione Australia Southeast. Questo record ha interferito con la connettività all'ambiente Australia Est, impedendo che i dati dell'inventario vengano elaborati come previsto. Il record DNS obsoleto è stato rimosso, permettendo al traffico di raggiungere il punto finale corretto e consentendo agli aggiornamenti di scansione dell'inventario di riprendere. Dopo il cambiamento, i conteggi delle scorte hanno cominciato a progredire, e gli stati dei servizi di connettività interessati sono poi tornati alla normalità il 22 settembre 2026, alle 3:15 PDT. Dopo un lungo periodo di monitoraggio notturno, i servizi di connettività sono rimasti stabili, e il problema è stato dichiarato risolto il 23 settembre alle 12:05 AM PDT. Non sono stati segnalati ulteriori problemi, e l'infrastruttura precedentemente utilizzata Australia Southeast è stata completamente dismessa. ♪Root Cause ♪ L'incidente è stato causato da un record DNS obsoleto che è rimasto dopo la dismissione delle infrastrutture nella regione Australia Southeast. Questo record ha diretto il traffico lontano dal punto di estremità corretto per l'ambiente Australia Est, interrompendo la connettività necessaria per l'elaborazione dei dati dell'inventario. Di conseguenza, gli aggiornamenti dell'inventario sono stati ritardati, e i clienti interessati non potrebbero recuperare le ultime informazioni del dispositivo. Il record obsoleto è stato rimosso, ripristinando la connettività al punto finale corretto e permettendo l'elaborazione dell'inventario di riprendere. ** Azioni di correzione ** I nostri team hanno eseguito le seguenti azioni per ripristinare i servizi alla normalità: * Identificata e rimossa il record DNS obsoleto associato all'infrastruttura precedentemente disattivata. * Connettività ripristinata al corretto endpoint Australia Est. * Verificato che gli aggiornamenti della scansione dell'inventario e i conteggi dell'inventario stavano procedendo. * Monitorato l'ambiente per confermare la stabilità del servizio. * Confermato che gli stati del servizio di connettività neve sono poi tornati alla normalità e non sono stati segnalati ulteriori problemi. **Misure di prevenzione complesse** * Verificare la pulizia dei record DNS durante la decommissione delle infrastrutture per garantire la rimozione dei record obsoleti. * Migliorare i controlli post-decommissioning per identificare i record che rimangono dopo la rimozione delle risorse.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 settembre 2026 alle ore 13:03 UTCinvestigating

   Descrizione dell'incidente: Stiamo indagando su un problema che riguarda il trattamento dei dati dell'inventario negli ambienti di produzione dell'UE e dell'APAC. I clienti possono osservare ritardi negli aggiornamenti dell'inventario, con conseguente dati dell'inventario che non riflettono l'attività di importazione più recente. Priorità: P2 Attività di restauro: I nostri team tecnici stanno attivamente indagando il problema, convalidando la portata dell'impatto e lavorando con le dipendenze rilevanti per ripristinare il normale processo di inventario. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 18 settembre 2026 alle ore 13:50 UTCidentified

   I nostri team tecnici hanno tracciato il problema di una recente distribuzione e hanno implementato azioni di bonifica. La validazione iniziale indica che l'elaborazione dell'inventario è ripresa, e i team tecnici stanno monitorando attivamente l'attività di elaborazione e il recupero del backlog. Stiamo continuando a convalidare il recupero attraverso gli ambienti interessati e fornirà ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

3. 18 settembre 2026 alle ore 14:34 UTCidentified

   I team tecnici hanno completato gli aggiornamenti di configurazione richiesti e i dati di inventario continuano ad essere elaborati con successo. La capacità di elaborazione aggiuntiva è stata assegnata per accelerare il recupero del backlog, e i team tecnici stanno monitorando attivamente la riduzione del throughput e del backlog negli ambienti interessati. Le attività di recupero rimangono in corso, e ulteriori aggiornamenti saranno forniti come backlog processing continua.

4. 18 settembre 2026 alle ore 14:39 UTCmonitoring

   L'elaborazione dei dati dell'inventario continua a recuperare, e i team tecnici stanno osservando una tendenza verso il basso nel volume del backlog. Resta in vigore una capacità di elaborazione aggiuntiva e i progressi di recupero vengono monitorati da vicino negli ambienti interessati. Continueremo a monitorare la riduzione del backlog e fornire ulteriori aggiornamenti come progressi di recupero.

5. 18 settembre 2026 alle ore 18:52 UTCmonitoring

   Il trattamento dei dati dell'inventario continua a seguito della bonifica precedentemente implementata. I team tecnici stanno monitorando attivamente l'elaborazione del throughput e del recupero del backlog negli ambienti interessati. I team tecnici continuano a valutare i progressi del recupero e le eventuali azioni aggiuntive che possono contribuire ad accelerare il processo di backlog. Ulteriori aggiornamenti saranno forniti come progressi di recupero.

6. 18 settembre 2026 alle ore 19:49 UTCmonitoring

   Il recupero di backlog è completato in APAC dopo la bonifica precedentemente implementata, e il trattamento dei dati di inventario è tornato ai livelli previsti nella regione. Le attività di recupero continuano nell’UE, dove i team tecnici stanno monitorando il processo di elaborazione attraverso la riduzione del rendimento e del backlog. Vengono valutate ulteriori misure di recupero per sostenere l'elaborazione del backlog come progressi nel recupero.

7. 18 settembre 2026 alle ore 21:55 UTCmonitoring

   Gli sforzi di recupero continuano nell'UE, e i team tecnici stanno osservando la continua riduzione del backlog rimanente. Sono state implementate ulteriori ottimizzazioni di recupero per supportare l'elaborazione del backlog nell'UE, e i team tecnici continuano a monitorare il throughput e il progresso complessivo del recupero. Ulteriori aggiornamenti saranno forniti come proseguono i progressi.

8. 19 settembre 2026 alle ore 11:07 UTCmonitoring

   Il recupero continua a progredire, con il restante backlog in costante diminuzione. Ulteriori ottimizzazioni attuate nell’ambiente dell’UE sostengono efficacemente l’elaborazione del backlog. I nostri team continuano a monitorare attentamente i progressi del recupero e forniranno ulteriori aggiornamenti, se del caso.

9. 19 settembre 2026 alle ore 19:09 UTCmonitoring

   Gli sforzi di recupero continuano nell'UE e i team tecnici stanno osservando una continua riduzione del backlog dopo le ottimizzazioni precedentemente implementate. Sulla base delle attuali tendenze di recupero, i livelli di backlog sono stati significativamente ridotti e continuano a muoversi nella direzione prevista. Ulteriori aggiornamenti saranno forniti come proseguono i progressi.

10. 20 settembre 2026 alle ore 19:55 UTCresolved

    I team tecnici hanno confermato che il trattamento dei dati dell'inventario nell'UE è tornato al normale funzionamento dopo la bonifica precedentemente implementata. Il problema è stato tracciato a un problema di configurazione di distribuzione che riguarda l'elaborazione dei dati dell'inventario. Gli aggiornamenti di configurazione richiesti sono stati applicati, ripristinando l'elaborazione normale. Dopo la convalida e il monitoraggio esteso, il recupero del backlog nell'UE ha completato e l'elaborazione dell'inventario rimane stabile sia nell'UE che nell'APAC. Questo incidente è ora considerato risolto.

11. 23 ottobre 2026 alle ore 17:20 UTCpostmortem

    **Descrizione:** Flexera One - IT Asset Management - EU & APAC - Inventory Processing Delays **Timeframe:** 16 settembre 2026, 14:00 PM PDT - 20 settembre 2026, 9:52 AM PDT **Riepilogo incidente** Venerdì 18 settembre 2026, i team tecnici hanno iniziato a indagare sulle relazioni degli aggiornamenti di inventario ritardati che interessano i clienti di Flexera One IT Asset Management \(ITAM\) in Europa \(EU\) e Asia-Pacific \(APAC\) regioni. Le informazioni aggiornate sull'inventario non sono state riflesse nell'applicazione, con alcuni clienti che hanno riferito che i loro ultimi dati disponibili dell'inventario sono rimasti datati 16 settembre. Il problema ha interessato l'elaborazione dell'inventario piuttosto che la disponibilità generale della piattaforma ITAM. L'analisi iniziale indicava che i servizi di elaborazione dell'inventario sembravano sani, ma i file di inventario in entrata non stavano progredendo attraverso il flusso di lavoro di elaborazione previsto. Ulteriori indagini hanno tracciato l'interruzione di una distribuzione eseguita il 16 settembre, durante la quale un problema di configurazione ha interessato i servizi responsabili del trattamento dei dati dell'inventario. I team tecnici hanno identificato e corretto la configurazione di distribuzione, permettendo l'elaborazione dell'inventario di riprendere. Tuttavia, un significativo backlog dei file di inventario si era accumulato durante l'interruzione e richiedeva tempo supplementare per elaborare. La lavorazione dell'inventario è stata recuperata prima in APAC, dove il backlog accumulato è stato cancellato il 18 settembre a circa 12:21 PM PDT. La regione dell'UE ha richiesto ulteriori tempi di recupero a causa del volume dei file in sospeso. I team tecnici hanno regolato le impostazioni della capacità di elaborazione e hanno continuato a monitorare il backlog come file di inventario sono stati elaborati. Il restante backlog dell'UE è stato completamente sgomberato il 20 settembre a circa 9:52 PDT. Il monitoraggio successivo ha confermato che l'elaborazione dell'inventario era tornata a livelli operativi normali. ♪Root Cause ♪ L'incidente è stato causato da un problema di configurazione di distribuzione introdotto durante un aggiornamento del 16 settembre ai servizi di elaborazione dell'inventario. Al momento dell'implementazione, l'infrastruttura di elaborazione dell'inventario stava passando tra gli ambienti applicativi, con diversi servizi necessari per rimanere attivi in ogni ambiente a seconda della regione. Ciò ha aumentato la complessità di mantenere la corretta configurazione di produzione, e la configurazione di servizio richiesta non è stata mantenuta correttamente durante l'implementazione. Di conseguenza, il flusso di lavoro di elaborazione dell'inventario è stato interrotto nelle regioni dell'UE e dell'APAC, impedendo ai file di inventario in entrata di essere elaborati e ritardando gli aggiornamenti dei dati dell'inventario. Una volta che la configurazione è stata corretta, l'elaborazione dell'inventario ha ripreso, con il backlog accumulato che richiede un ulteriore tempo per elaborare prima che i livelli operativi normali siano stati completamente ripristinati. ** Azioni di correzione ** Le seguenti azioni sono state prese durante la risposta incidente: 1. ** Iniziato l'indagine incidente:** I team tecnici hanno esaminato i rapporti degli aggiornamenti di inventario ritardati nelle regioni UE e APAC e hanno esaminato il flusso di lavoro di elaborazione dell'inventario per identificare la fonte dell'interruzione. 2. ** Problema di configurazione di distribuzione identificato:** L'indagine ha tracciato l'interruzione della distribuzione del 16 settembre e ha identificato una configurazione di servizio errata che interessa l'elaborazione dell'inventario nelle regioni colpite. 3. ** Configurazione di produzione Corretto:** Gli aggiornamenti di configurazione richiesti sono stati applicati per ripristinare i servizi di inventario interessati, consentendo ai file di inventario in arrivo di riprendere l'elaborazione. 4. **Inventory Backlog Recovery Iniziato:** I team tecnici hanno monitorato i file di inventario accumulati e le risorse di elaborazione disponibili regolate per supportare il recupero del backlog dopo il ripristino del flusso di lavoro di elaborazione. 5. **Processing throughput Ottimizzato:** Durante il recupero dell'UE, i team tecnici hanno individuato i vincoli di capacità di elaborazione nell'ambito dell'aumento del carico di lavoro e dell'ottimizzazione dell'elaborazione per migliorare la produttività mantenendo la stabilità dei servizi. 6. ** Servizio di recupero convalidato: ** I team tecnici hanno confermato che il backlog APAC era stato sgomberato il 18 settembre, seguito da un recupero completo del backlog UE il 20 settembre. Il monitoraggio continuato ha verificato che l'elaborazione dell'inventario era tornata a livelli operativi normali. **Misure di prevenzione complesse** Dopo l'incidente, abbiamo condotto una retrospettiva per rivedere il problema della configurazione di distribuzione, le differenze tra gli ambienti applicativi, le capacità di monitoraggio dell'inventario e le opportunità per migliorare la convalida di distribuzione e la visibilità operativa. Sono state completate o in corso le seguenti azioni correttive e attività di miglioramento: 1. ** Gestione della configurazione del servizio regionale:** Un elenco di configurazione regionale dei servizi è stato implementato per documentare e mantenere le configurazioni di servizio richieste nei diversi ambienti di distribuzione, riducendo il rischio di incongruenze di configurazione durante le versioni future. 2. ** Miglioramenti di convalida: ** Una lista di controllo di distribuzione è stata implementata per verificare che i servizi di elaborazione dell'inventario richiesti siano in esecuzione negli ambienti appropriati durante le attività di distribuzione. 3. ** Monitoraggio dell'elaborazione dell'inventario avanzato:** Sono stati implementati ulteriori controlli e avvisi per identificare le interruzioni nell'elaborazione dell'inventario prima e consentire un'indagine e un recupero più rapidi. 4. ** Visibilità di errore di elaborazione migliorata:** Le dashboard di monitoraggio sono state implementate per fornire maggiore visibilità nei modelli di risposta alle applicazioni anormali, inclusi gli errori relativi alla capacità di elaborazione. Questi miglioramenti hanno già supportato il rilevamento e il recupero precedenti durante i successivi problemi di elaborazione. 5. **Produzione Ambiente Semplificazione: ** I lavori in corso per consolidare il modello di distribuzione ridurranno la complessità operativa associata al mantenimento di diverse configurazioni di servizio in ambienti e regioni, contribuendo a ridurre il rischio di interruzioni di elaborazione correlate alla configurazione simili.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 settembre 2026 alle ore 09:04 UTCidentified

   Descrizione incidente: Stiamo vivendo un problema che riguarda il sito della Comunità Flexera. A causa di un'interruzione in corso che colpisce un fornitore di servizi di terze parti, i clienti potrebbero non essere in grado di accedere al portale Flexera Community o possono sperimentare comportamenti intermittenti e inaffidabili. Inoltre, i clienti potrebbero non essere in grado di creare, aggiornare o interagire con i casi di supporto attraverso il sito comunitario. Le e-mail inviate a [email protected] durante questo periodo non possono essere ricevute o elaborate fino a quando l'outage sottostante non è stato risolto. Questo fornitore di servizi di terze parti outage inoltre influisce sulla capacità di monitoraggio proattiva per i team di supporto Spot per rilevare eventuali problemi di ambiente del cliente insieme a un widget di chatbot all'interno della console Spot. Priorità: P3 Attività di restauro: I nostri team tecnici stanno monitorando attivamente la situazione e lavorano con il fornitore di terze parti per monitorare gli sforzi di restauro. Continueremo a valutare l'impatto del cliente e fornire ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 16 settembre 2026 alle ore 12:31 UTCidentified

   Il fornitore di servizi ha convalidato con successo la correzione in un ambiente di prova e ha iniziato a dispiegarla in tutte le istanze interessate. Il rollout sta progredendo su una base regionale per regione, e i servizi stanno tornando alla normalità nelle regioni in cui il dispiegamento è stato completato.

3. 16 settembre 2026 alle ore 19:25 UTCmonitoring

   Il nostro fornitore di servizi riferisce che la telemetria di servizio è rimasta sana dopo l'implementazione della mitigazione. La Comunità rimane accessibile in questo momento e non è stato identificato alcun impatto costante confermato. Continueremo a monitorare l'ambiente per garantire la stabilità in corso mentre vengono completate le attività di validazione finale. Forniamo un ulteriore aggiornamento in quanto ulteriori informazioni diventano disponibili.

4. 16 settembre 2026 alle ore 22:00 UTCmonitoring

   Il nostro fornitore di servizi ha dichiarato l'incidente sottostante risolto dopo la mitigazione di successo e la validazione estesa. La Comunità rimane accessibile e non è stato identificato alcun impatto costante confermato. Il monitoraggio durante il periodo di recupero non ha identificato alcun problema aggiuntivo. Questo incidente è ora considerato risolto.

5. 17 settembre 2026 alle ore 11:01 UTCresolved

   I nostri team hanno continuato a monitorare il servizio durante il periodo di recupero, e non sono stati osservati ulteriori problemi. Sulla base della stabilità sostenuta del servizio, questo incidente è ora considerato risolto.

6. 30 settembre 2026 alle ore 12:30 UTCpostmortem

   **Descrizione:** Flexera Community- Service non disponibile **Timeframe:** 16 settembre 2026, 12:50 AM PDT a 16 settembre 2026, 8:26 AM PDT **Riepilogo incidente** Il 16 settembre 2026, alle ore 12:50 PDT , Flexera ha individuato un problema che riguarda la disponibilità e l'affidabilità del sito comunitario Flexera a causa di un'estrazione che interessa un fornitore di servizi esterno che supporta la piattaforma comunitaria. Durante l'incidente, i clienti potrebbero non essere stati in grado di accedere alla Comunità di Flexera, aumentare o gestire i casi di supporto, o ricevere risposte ai casi esistenti attraverso la Comunità. Le e-mail inviate a [email protected] potrebbero anche essere state ritardate o non elaborate durante l'outage. Il problema ha anche interessato la funzionalità chatbot all'interno della console Spot, che si basa sui servizi colpiti. Inoltre, l'outage ha interessato le capacità di monitoraggio proattivo utilizzate dai team di Spot Support per identificare alcuni problemi di ambiente del cliente che dipendono dalle notifiche di servizio. Il fornitore di servizi ha successivamente convalidato una correzione e ha cominciato a distribuirlo attraverso le istanze interessate su una base regionale per regione. Poiché la mitigazione è stata implementata, i servizi sono tornati progressivamente alla normalità. In seguito all'implementazione, la telemetria di servizio è rimasta sana in tutti gli ambienti orientati al cliente. La convalida ha confermato che la funzionalità di Flexera Community e Spot chatbot funzionavano normalmente. L'incidente del fornitore sottostante è stato successivamente dichiarato risolto, e Flexera ha completato la convalida finale e ha chiuso l'incidente.. ♪Root Cause ♪ L'incidente è stato causato da un'interruzione che riguarda i servizi di un fornitore di servizi esterno che supporta la Comunità Flexera e le relative funzionalità. La disgregazione del servizio ha interessato la disponibilità e l'affidabilità della piattaforma comunitaria e le relative integrazioni, con conseguente rottura temporanea alla funzionalità del caso di assistenza clienti e alle relative funzionalità Spot. ** Azioni di correzione ** * Remediazione del fornitore: Il fornitore di servizi esterno ha convalidato e implementato una correzione tra le istanze interessate. * Validazione del servizio: i team di Flexera hanno monitorato la funzionalità Community, chatbot e i servizi correlati in quanto la bonifica è stata implementata. * Monitoraggio di recupero: La salute e la funzionalità del servizio sono stati monitorati per confermare la stabilità dopo la bonifica. * Chiusura incidente: Dopo il problema del fornitore sottostante è stato risolto e Flexera ha completato la convalida, l'incidente è stato chiuso. **Misure di prevenzione complesse** * Monitoraggio della dipendenza migliorato: Continua a monitorare le dipendenze esterne critiche che supportano i servizi di customer-facing. * Valutazione dell'impatto del cliente: Continua a valutare l'impatto delle interruzioni dei servizi esterni attraverso i servizi integrati Flexera, tra cui Community, gestione dei casi di supporto e funzionalità Spot. * Monitoraggio post-incidente: Continua il monitoraggio per l'impatto residuo del cliente dopo il ripristino dei servizi esterni.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 settembre 2026 alle ore 23:05 UTCinvestigating

   Descrizione dell'incidente: Stiamo attualmente indagando su un problema che riguarda i servizi Politiche e Automazione nell'ambiente di produzione dell'UE. I clienti dell'UE possono sperimentare guasti durante l'utilizzo di Criteri e potrebbero non essere in grado di visualizzare le loro politiche attraverso l'interfaccia utente. L'impatto è limitato alla regione dell'UE. Priorità: P2 Attività di ripristino: I nostri team tecnici sono stati impegnati e stanno indagando attivamente un problema incontrato durante un aggiornamento delle infrastrutture per identificare la causa sottostante e ripristinare il servizio normale il più rapidamente possibile. Ulteriori aggiornamenti saranno forniti come l'indagine progredisce.

2. 16 settembre 2026 alle ore 06:16 UTCmonitoring

   Il problema dell'ambiente dell'UE è stato risolto e l'accesso all'interfaccia utente è stato completamente ripristinato. Mentre il servizio è ora operativo normalmente, può richiedere un po 'di tempo per il backlog di lavoro in coda che si è accumulato durante l'outage da elaborare. I nostri team stanno monitorando attivamente il recupero per garantire che il backlog sia cancellato e i servizi continuino a svolgere come previsto. Continueremo a monitorare attentamente l'ambiente e a confermare una volta che l'elaborazione è tornata a livelli normali.

3. 16 settembre 2026 alle ore 08:24 UTCresolved

   I nostri team hanno continuato a monitorare il servizio da vicino, e non sono stati osservati nuovi problemi. Il backlog del lavoro in coda che si è accumulato durante la rottura è l'elaborazione con successo e continua a diminuire come previsto. Sulla base della stabilità osservata dal recupero, questo incidente è ora risolto. Continueremo a monitorare l'elaborazione per garantire che il backlog rimanente si chiarisca completamente e il servizio continua a funzionare come previsto.

4. 12 ottobre 2026 alle ore 12:02 UTCpostmortem

   **Descrizione:** Flexera - EU - Policy/Automation Non disponibile **Timeframe:** 15 settembre 2026, 15:50 PM PDT al 16 settembre 2026, 1:22 AM PDT **Riepilogo incidente** Il 15 settembre 2026, alle 15:50 PM PDT, un potenziamento delle infrastrutture che supporta l'automazione nell'ambiente di produzione dell'UE ha portato a una disgregazione della connettività di rete che interessa Politiche e Automazione. I clienti hanno sperimentato difficoltà di visualizzazione delle politiche nell'interfaccia utente, e le operazioni correlate alle policy sono fallite. L'indagine ha identificato un comportamento inaspettato da un componente di rete legacy . Questa connettività interrotta richiesta dai servizi interessati. Il team ha identificato il componente coinvolto e ha portato la risorsa necessaria online, ripristinando la connettività di rete. Il problema sottostante è stato risolto il 15 settembre alle 10:13 PM PDT. In seguito, il team ha continuato a monitorare il recupero dei servizi e il trattamento del backlog accumulato durante la rottura. Una volta che la lavorazione del backlog era progredita come previsto e la stabilità di servizio è stata confermata, l'incidente è stato dichiarato completamente restaurato il 16 settembre 2026, a 1:22 PDT. L'impatto è stato limitato all'ambiente di produzione dell'UE. ♪Root Cause ♪ L'incidente è stato causato da un comportamento inaspettato da un componente di rete legacy durante l'aggiornamento dell'infrastruttura di Automation nella regione dell'UE. Questa connettività di rete interrotta richiesta da Politiche e Automazione, con conseguente indisponibilità del servizio e guasti nella funzionalità relativa alle policy. ** Azioni di correzione ** I nostri team hanno eseguito le seguenti azioni per ripristinare i servizi alla normalità: * Ripristino della connettività: Ho identificato il componente legacy coinvolto e portato la risorsa necessaria online per ripristinare la connettività di rete. * Servizio di recupero: Connettività ripristinata e risolto il problema sottostante che interessa Politiche e Automazione. * Trattamento Backlog: Monitorato il backlog accumulato come trattamento recuperato dopo il ripristino del servizio. * convalida post-restorazione: stabilità di servizio confermata e verificata che l'elaborazione backlog stava progredendo come previsto prima di dichiarare l'incidente completamente restaurato. **Misure di prevenzione complesse** * Programmazione della migrazione: la migrazione degli Stati Uniti corrispondente è stata riprogrammata con una finestra di manutenzione più lunga per consentire il tempo supplementare per la risoluzione dei problemi e il recupero. * Sostituzione dei componenti legacy: Il componente legacy viene sostituito come parte dello sforzo di modernizzazione delle infrastrutture. Una volta completata la sostituzione, questa specifica dipendenza legacy dovrebbe essere eliminata in tutti gli ambienti.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.