Ricerche recenti


Nessuna ricerca recente

Attila Takacs's Avatar

Attila Takacs

Data ingresso 14 apr 2021

·

Ultima attività 05 feb 2025

Seguiti

0

Follower

2

Attività totali

72

Voto

1

Abbonamenti

63

PANORAMICA ATTIVITÀ

Ultima attività di Attila Takacs

Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

5 febbraio 2025 11:48 UTC | 05 febbraio 2025 03:48 PT
Siamo lieti di informarti che i problemi di accesso al nostro servizio Guide sono stati identificati e risolti dal nostro team tecnico. Ora dovresti essere in grado di accedere al servizio senza problemi. Grazie per la pazienza e la comprensione dimostrate durante questo incidente. Se continui a riscontrare problemi, contatta il nostro team di assistenza.

5 febbraio 2025 11:29 UTC | 05 febbraio 2025 03:29 PT
Stiamo riscontrando un degrado del servizio a causa dell’accesso al servizio Guide dai browser per dispositivi mobili. Se riscontri errori durante l’accesso al tuo account, prova ad accedere da un desktop. Il nostro team sta lavorando attivamente per risolvere il problema.

POST-MORTEM

DA DEFINIRE

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk e sugli impatti specifici sul tuo account, visita la nostra pagina sullo stato del sistema. Puoi seguire questo articolo per ricevere una notifica quando verrà pubblicato il nostro report post mortem. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 05 feb 2025 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Il 1° febbraio 2025, dalle 00:13 UTC alle 00:59 UTC, i clienti del POD 26 hanno riscontrato problemi con l’accesso ai ticket archiviati. Durante questo periodo, più nodi di lettura del database non sono stati in grado di aprire una tabella a causa di un difetto nel sistema del database. Ciò ha comportato query non riuscite per i ticket archiviati.

CRONOLOGIA

01 febbraio 2025 01:13 UTC | 31 gennaio 2025 17:13 PT
Siamo lieti di informarti che il problema che causava errori in un gruppo di clienti Support sul POD 26 è stato risolto. Grazie per la pazienza dimostrata durante la nostra indagine.

01 febbraio 2025 00:57 UTC | 31 gennaio 2025 16:57 PT
I nostri tecnici ritengono di aver identificato la causa principale degli errori che hanno interessato un gruppo di clienti Support nel POD 26 e stanno lavorando per risolvere il problema.

01 febbraio 2025 00:57 UTC | 31 gennaio 2025 16:57 PT
Stiamo esaminando potenziali errori per i nostri clienti Support ospitati sul POD 26.


POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da un difetto nel sistema del database che impediva ai nodi di lettura del cluster di accedere a una tabella di ticket archiviata. Il difetto è stato confermato dall’assistenza tecnica del nostro fornitore ed era specifico della versione del database installata in quel momento.


Soluzione

Per risolvere il problema, i nostri ingegneri hanno interrotto la distribuzione ad altri shard e hanno consentito il completamento delle modifiche in corso sugli shard interessati. A quel punto la tabella del database era accessibile. Successivamente, il team prevede di passare a una nuova versione del nostro sistema di database, che include una patch per il difetto identificato.


Elementi correttivi

  1. Passa alla versione con patch o successiva prima di riprendere le modifiche allo schema.
  2. Suddividi le aggiunte di colonne e le riduzioni di indici in azioni separate per ridurre al minimo i rischi durante le distribuzioni.
  3. Aggiorna il runbook per richiedere che le migrazioni di grandi dimensioni raggiungano inizialmente un solo cluster prima di espandersi ad altri.
  4. Implementa un processo di revisione regolare (almeno annuale) delle patch del sistema di database e stabilisci una cadenza di aggiornamento.

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk e sugli impatti specifici sul tuo account, visita la nostra pagina sullo stato del sistema. Puoi seguire questo articolo per ricevere una notifica quando verrà pubblicato il nostro report post mortem. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 06 feb 2025 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO
Il 13 gennaio 2025, dalle 11:07 UTC alle 12:07 UTC, i clienti del Pod 17 hanno riscontrato problemi con la mancata esecuzione dei trigger di messaggistica.

CRONOLOGIA

13 gennaio 2025 12:24 UTC | 13 gennaio 2025 04:24 PT
Il recente problema di messaggistica è stato completamente risolto e i nostri servizi sono tornati alla piena operatività. Grazie per la pazienza dimostrata durante questo periodo. Il nostro team continuerà a monitorare da vicino i nostri sistemi per garantire che tutto funzioni senza intoppi. Apprezziamo il tuo supporto e siamo qui per qualsiasi domanda o feedback tu possa avere.

13 gennaio 2025 11:51 UTC | 13 gennaio 2025 03:51 PT
Stiamo esaminando i problemi con i trigger di messaggistica in esecuzione per i nostri clienti sul POD17.


POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato dalla chiusura anticipata dei consumer del servizio Eventi del registro dei ticket di messaggistica, avvenuta mentre il servizio era ancora in esecuzione. Di conseguenza, i consumer non sono stati in grado di elaborare gli eventi in ingresso, con conseguente interruzione completa della valutazione e dell’esecuzione dei trigger di messaggistica nel pod 17.

Soluzione

Per risolvere questo problema, abbiamo identificato l’errore di configurazione che impostava il numero massimo di record da elaborare in un singolo batch su 500 anziché 250. Correggendo questo errore di battitura e riducendo il valore massimo di record, abbiamo mirato a ridurre la probabilità che i consumatori cessino a causa di problemi di timeout.

Elementi correttivi

  1. Implementa un controllo dello stato per rilevare le terminazioni premature dei consumer.
  2. Crea un monitor per monitorare il numero di consumer in esecuzione.
  3. Stabilisci un monitor per monitorare le partizioni interrotte per il consumer degli eventi del registro dei ticket Tessaging.
  4. Aggiungi un widget per lo stato del ritardo del consumatore al dashboard del servizio trigger di messaggistica.
  5. Crea una nuova metrica per misurare il tempo impiegato per elaborare un batch di messaggi dall’argomento Eventi del registro dei ticket di messaggistica.

Queste soluzioni sono progettate per migliorare il monitoraggio e prevenire incidenti simili in futuro, garantendo la stabilità e l’affidabilità del servizio trigger di messaggistica.


PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk e sugli impatti specifici sul tuo account, visita la nostra pagina sullo stato del sistema. Puoi seguire questo articolo per ricevere una notifica quando verrà pubblicato il nostro report post mortem. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 29 gen 2025 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Il 9 dicembre 2024, dalle 8:08 UTC alle 13:03 UTC, i clienti che usavano la funzionalità multibrand hanno riscontrato errori durante il tentativo di creare ticket o aggiornare i titoli dei ticket, ma le modifiche sono state salvate.

Cronologia

9 dicembre 2024 22:21 UTC | 14:21 PT

Siamo lieti di informarti che la recente modifica è stata ripristinata e che il problema con la creazione di ticket multibrand è stato risolto.
Se i problemi persistono, prova a eseguire un aggiornamento completo (Ctrl + F5) o a svuotare la cache del browser e i cookie, in quanto ciò può aiutare a risolvere eventuali problemi persistenti.
Non esitare a contattarci se continui a riscontrare difficoltà. Grazie per la pazienza.

9 dicembre 2024 12:58 UTC | 04:58 PT
Stiamo riscontrando problemi con la creazione di ticket multibrand. Il nostro team tecnico è a conoscenza del problema e sta lavorando attivamente per risolverlo il più rapidamente possibile.
Forniremo aggiornamenti non appena saranno disponibili ulteriori informazioni. Grazie per la pazienza e la comprensione.

 

POST-MORTEM

Analisi della causa principale

La causa principale dell’incidente è un difetto nella logica di inizializzazione dei ticket. Quando l’ID del richiedente non era definito, il sistema ha tentato di recuperarlo in base alla chiave del ticket, generando errori ogni volta che si verificava una modifica di un campo nell’interfaccia utente del ticket. L’introduzione di una nuova logica per leggere l’ID utente dalla pagina del profilo utente e impostarlo sull’ID richiedente ha impostato inavvertitamente l’oggetto richiedente su non definito, interrompendo la funzionalità prevista.


Soluzione

Per risolvere il problema, l’aggiornamento problematico è stato ripristinato.


Elementi correttivi

  1. Correzione del codice errato: Assicurati che il sistema imposti correttamente i dati del richiedente durante la creazione dei ticket per evitare voci vuote.
  2. Aggiungi test automatico: Crea un test per verificare che il processo di salvataggio del ticket gestisca correttamente le informazioni del richiedente.
  3. Conferma test manuale: Prima della distribuzione, chiedi ai distributori di testare manualmente le modifiche sui POD "canarie" e di confermare che tutto funzioni.
  4. Migliora il monitoraggio: Imposta il monitoraggio per avvisare in caso di errori del browser, ad esempio "si è verificato un problema", per identificare rapidamente i problemi.

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta il nostro pagina di stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 17 dic 2024 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Il 3 dicembre 2024, dalle 21:09 UTC alle 3:36 UTC del 7 dicembre 2024, alcuni clienti che usavano l’SDK per dispositivi mobili hanno riscontrato 400 errori durante la creazione dei ticket. A causa di una modifica, ai token OAuth appena creati è stata assegnata una scadenza predefinita di 8 ore. Questa modifica ha inavvertitamente interrotto gli SDK per dispositivi mobili legacy, che non potevano recuperare nuovi token se i token esistenti diventavano non validi, causando un'esperienza utente frustrante. Il problema è stato risolto annullando la modifica.


Cronologia

6 dicembre 2024 18:20 UTC | 6 dicembre 2024 10:20 PT

Siamo lieti di informarti che il problema che causava l’errore 400 di alcuni clienti durante la creazione dei ticket tramite l’SDK è stato risolto. Ci scusiamo per eventuali disagi causati e ti ringraziamo per la pazienza dimostrata durante la nostra indagine.

6 dicembre 2024 12:06 UTC | 6 dicembre 2024 04:06 PT
Il nostro team continua a lavorare per risolvere il problema che causa 400 errori negli invii dei ticket tramite l’API tramite il nostro SDK per dispositivi mobili. Per ora, se gli utenti finali riscontrano questo errore possono riavviare i ticket dell’app verranno creati normalmente.


6 dicembre 2024 09:45 UTC | 6 dicembre 2024 01:45 PT

Siamo consapevoli del fatto che alcuni dei nostri clienti potrebbero riscontrare 400 errori durante il tentativo di creare ticket tramite il nostro SDK per dispositivi mobili. Se riscontri questo errore, riavvia l’app per risolvere il problema.


POST-MORTEM

Analisi della causa principale

Questo incidente è dovuto a una svista nella valutazione del modo in cui i token di autenticazione sono stati utilizzati nei diversi prodotti prima di implementare una modifica alla data di scadenza. Gli SDK legacy in base alla progettazione non possono ottenere nuovi token OAuth alla scadenza dei token esistenti, ma questo aspetto non è stato completamente preso in considerazione durante le fasi di pianificazione e integrazione. Una collaborazione migliorata e una valutazione più approfondita dell'utilizzo dei token avrebbero potuto aiutare a evitare questa interruzione.


Soluzione

Per risolvere il problema, il team di autenticazione ha prima disabilitato il processo di backfill che ha aggiunto tempi di scadenza ai token esistenti. Successivamente, hanno distribuito una richiesta pull che ha ripristinato le impostazioni di scadenza per i nuovi token e ha avviato un backfill per rimuovere la scadenza dai token esistenti. Questa azione ha ripristinato la funzionalità per la maggior parte dei clienti interessati.


Elementi correttivi

  1. Stabilisci un protocollo di comunicazione chiaro tra i team per garantire che i difetti noti siano adeguatamente documentati e verificati prima di implementare modifiche significative.
  2. Migliora gli strumenti di implementazione esistenti per gestire meglio il flusso di autenticazione e ridurre i debiti tecnici associati agli SDK legacy.
  3. Crea ulteriori avvisi e sistemi di monitoraggio per rilevare problemi simili in futuro, concentrandoti in particolare sugli errori dei token OAuth .
  4. Introduci limiti di connessione su applicazioni specifiche per evitare la generazione eccessiva di token e ridurre l’aumento delle dimensioni del database.

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta il nostro pagina di stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 20 dic 2024 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Il 21 novembre 2024, dalle 21:02 UTC alle 21:56 UTC, alcuni clienti che usavano Sunshine Conversations ospitate sul Pod 17 hanno riscontrato problemi di lentezza e di prestazioni.

 

CRONOLOGIA

24 novembre 2024 22:23 UTC | 24 novembre 2024 14:23 PT
Siamo lieti di annunciare che i problemi di latenza che influiscono su Sunshine Conversations per alcuni dei nostri clienti sul POD 17 sono stati risolti. Grazie mille per la pazienza.

24 novembre 2024 22:09 UTC | 24 novembre 2024 14:09 PT
Riteniamo di aver identificato la causa principale dei problemi di prestazioni che influiscono su SunCo per i nostri clienti su Pod17. Stiamo riscontrando miglioramenti e continueremo a monitorare il comportamento.

24 novembre 2024 21:53 UTC | 24 novembre 2024 13:53 PT
Continuiamo a esaminare i problemi di prestazioni del Pod 17. Potrebbero causare lentezza in Sunshine Conversations. Forniremo ulteriori aggiornamenti al più presto.

24 novembre 2024 21:36 UTC | 24 novembre 2024 13:36 PT
Stiamo esaminando potenziali problemi di prestazioni che influiscono su alcuni dei nostri clienti ospitati sul Pod 17. A breve pubblicheremo un aggiornamento con ulteriori dettagli.


POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da un aumento inaspettato del traffico sul Pod17, che è più che raddoppiato nella settimana precedente e ha quasi triplicato il giorno dell’incidente. L’SDK Unity utilizzato da un cliente inviava richieste eccessive all’API SunCo per recuperare il numero di messaggi non letti, con conseguente aumento del carico del sistema. Il ridimensionamento automatico delle risorse era già al massimo, impedendo l’aggiunta di altre risorse per gestire l’aumento del traffico. Di conseguenza, questo sovraccarico ha comportato tempi di risposta più lenti e alla fine ha attivato controlli di integrità che hanno avviato i riavvii, aggravando il problema.

Soluzione

Per risolvere i problemi di prestazioni, abbiamo aumentato il numero massimo di repliche per l’API SunCo sul Pod17. Questa modifica ha consentito al sistema di gestire meglio l’aumento del traffico e di ripristinare i normali tempi di risposta per tutti i clienti.

Elementi correttivi

  1. Esamina l’SDK Unity per capire perché invia un numero eccessivo di richieste a SunCo e implementa le ottimizzazioni.
  2. Documenta i modelli di interazione del back-end negli incorporabili per chiarire l’uso e identificare potenziali inefficienze.
  3. Valuta l’implementazione di una strategia di memorizzazione nella cache per le API SDK in SunCo per ridurre il numero di richieste.
  4. Aggiungi il monitoraggio per rilevare la crescita anomala del traffico in periodi specificati per affrontare in modo proattivo potenziali sovraccarichi.

 

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 04 dic 2024 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Tra le 23:30 UTC del 12 novembre 2024 e le 11:26 UTC del 15 novembre 2024, i clienti Support che usavano gli SLA nei pod 25 e 30 hanno riscontrato ritardi nei calcoli degli SLA e i badge SLA sui loro ticket non venivano visualizzati come previsto dopo l’applicazione aggiornamenti dei ticket.

 

CRONOLOGIA

15 novembre 2024 13:00 UTC | 15 novembre 2024 05:00 PT
Siamo lieti di comunicare che i problemi che influiscono sulle prestazioni degli SLA per le metriche nei pod 25 e 30 sono stati risolti. Grazie per la pazienza.

15 novembre 2024 12:16 UTC | 15 novembre 2024 04:16 PT
Stiamo riscontrando miglioramenti al problema che influisce sulle prestazioni degli SLA per le metriche nel pod 25 e 30. Continuiamo a monitorare e forniremo ulteriori aggiornamenti non appena saranno disponibili.

 

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da un segreto configurato in modo errato per il servizio eventi di metrica. Ciò significava che quando Zendesk ha distribuito un aggiornamento con ulteriore convalida, il servizio non veniva inizializzato per le distribuzioni nell’area Asia-Pacifico, causando ritardi nell’elaborazione.

Soluzione

Per risolvere questo problema, il 15 novembre 2024 è stato aggiunto un valore "predefinito" per il segreto interessato. Ciò ha consentito al servizio eventi di metrica di inizializzarsi correttamente e di riprendere le normali operazioni. Zendesk ha anche identificato e impostato un valore predefinito per un segreto del servizio di trascrizione talk per mitigare eventuali rischi futuri.

Elementi correttivi

  1. Esegui un controllo approfondito di tutti i segreti per garantire che i valori siano impostati per tutte le località, in particolare nelle regioni Asia-Pacifico.
  2. Migliora gli strumenti di implementazione esistenti per evitare configurazioni errate simili in futuro.
  3. Crea ulteriori avvisi per notificare ai team interessati gli errori e i problemi di inizializzazione.
  4. Analizza il monitoraggio delle metriche degli errori per garantire che tali incidenti attivino avvisi per soluzioni tempestive.

Implementando queste soluzioni, miriamo a migliorare la resilienza dei nostri servizi e a prevenire incidenti simili in futuro.

 

PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 04 dic 2024 · Attila Takacs

0

Follower

1

Voto

0

Commenti


Attila Takacs ha creato un articolo,

ArticoloNotifiche di servizio

RIEPILOGO

Il 14 novembre 2024, dalle 14:15 UTC alle 23:20 UTC, i clienti che usano Explore hanno riscontrato errori di rete nell’accesso a report e dashboard. 

 

Cronologia

14 novembre 2024 18:11 UTC | 14 novembre 2024 10:11 PT
Siamo lieti di informarti che il problema che causava i messaggi di “Errore di rete” durante il caricamento dei dashboard o dei report di Explore è stato risolto. Grazie per la pazienza dimostrata durante la nostra indagine.

14 novembre 2024 15:18 UTC | 14 novembre 2024 07:18 PT
Alcuni utenti di Explore potrebbero visualizzare il messaggio “Errore di rete” durante il caricamento di dashboard o report. In tal caso, il problema dovrebbe essere risolto cancellando i cookie e la cache del browser. Ci scusiamo per il disagio.

POST-MORTEM

Analisi della causa principale

Questo incidente è stato causato da una modifica alla rete che ha aumentato il numero di intestazioni inviate al servizio Explore oltre il limite configurato. Ciò ha comportato un errore silenzioso del servizio, con conseguente mancato caricamento dei dashboard per i clienti.

Soluzione

Per risolvere il problema, il team di rete è stato contattato per esaminare le modifiche. Dopo aver identificato il problema, hanno ripristinato le modifiche che aggiungevano intestazioni eccessive, ripristinando la normale funzionalità dei dashboard Explore.

Elementi correttivi

  • Migliora gli strumenti di implementazione esistenti: Esamina e migliora gli strumenti usati per gestire i limiti di intestazione nelle richieste API per prevenire incidenti simili.
  • Crea ulteriori avvisi: Imposta avvisi per il monitoraggio del conteggio delle intestazioni e di altre metriche critiche per rilevare i problemi prima che influiscano sui clienti.
  • Aggiungi limiti di connessione ad applicazioni specifiche: Implementa i limiti di connessione sulle API per garantire che non superino le soglie operative, riducendo il rischio di incidenti futuri.


PER MAGGIORI INFORMAZIONI

Per informazioni sullo stato attuale del sistema su Zendesk, consulta la nostra pagina sullo stato del sistema. Di solito, il riepilogo della nostra indagine post mortem viene pubblicato qui pochi giorni dopo la fine dell’incidente. Per ulteriori domande su questo incidente, contatta l’assistenza clienti Zendesk.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 03 dic 2024 · Attila Takacs

1

Follower

1

Voto

0

Commenti