RIEPILOGO
A giugno 2024, in particolare il 13 e il 25 e alcuni giorni di luglio, si sono verificati diversi problemi nello spazio di lavoro agente Support di Zendesk. Questi incidenti hanno interrotto i workflow degli agenti, rendendo difficile l’accesso ai ticket. I problemi principali riscontrati includevano l’errore “Messaggi non trovati” e il codice di errore “A_xxx” durante il tentativo di caricare i ticket. Questi problemi si sono verificati principalmente in vari pod in più giorni. Ogni picco di interruzione in genere durava in media 2 minuti. Sebbene i clienti potessero tentare di aggiornare il sistema come soluzione alternativa, rischiavano di perdere le conversazioni in corso nel processo.
Cronologia
25 giugno 2024 16:05 UTC | 25 giugno 2024 09:05 PT
Siamo a conoscenza di un picco di errori che ha interessato i clienti su più pod tra le 15:40 e le 15:47 UTC del 25 giugno 2024, che ha prodotto le risposte "Messaggi non trovati" e i messaggi "Codice di errore A_xxx" durante il tentativo di caricare i ticket in Assistenza. Abbiamo risolto questi errori e il problema dovrebbe essere risolto ricaricando il browser e/o svuotando la cache e i cookie.
POST-MORTEM
Analisi della causa principale
La causa principale di questi incidenti è stato un aumento inaspettato delle richieste HTTP al server, spesso nei momenti di picco del traffico. Questo aumento ha portato a un effetto di "gregge tonante" che ha sovraccaricato le connessioni del server Agent Graph, causando il fallimento dei sondaggi di disponibilità. Lotus, un componente vitale del sistema, è stato identificato per svolgere un ruolo significativo. Ha sovraccaricato Ticket Data Manager (TDM) con più richieste ogni volta che si ricollegava. Questo aumento di traffico è attribuito principalmente alla riconnessione degli abbonamenti allo stato della conversazione dopo disconnessioni di massa apparentemente dovute a Zorg/Nginx e/o distribuzioni di servizi in abbonamento.
Il TDM è principalmente responsabile della gestione dei dati dei ticket. Organizza e memorizza le informazioni quando viene generato un ticket, quindi recupera e presenta questi dati quando un agente o un cliente ha bisogno di accedervi e funge da controller principale di tutti i dati relativi ai ticket, garantendo operazioni senza interruzioni all’interno del sistema.
Soluzione
In risposta a questi problemi sono state implementate misure preventive. Questi includevano il limitatore di velocità di connessione e richiesta, responsabile della regolazione del traffico in ingresso. Contemporaneamente, sono state adottate misure per migliorare la resilienza di Agent Graph durante gli errori di memorizzazione nella cache. Questa strategia è servita a prevenire interruzioni a livello di sistema dovute a inevitabili problemi tecnici, che agiscono come un generatore di backup durante un'interruzione di corrente. Sebbene siano state implementate numerose soluzioni di mitigazione, la soluzione effettiva che ha concluso che l’incidente del servizio è stata una modifica apportata in Lotus. La modifica ha ridotto il numero di scenari in cui il recupero dei dati si sarebbe verificato successivamente, ponendo fine al fragoroso effetto di branco.
Modificato il 25 luglio: Dopo aver apportato alcune modifiche il 10 luglio per evitare l’accumulo di richieste che causano problemi, non abbiamo riscontrato ulteriori picchi che influiscono sull’interfaccia utente dei ticket. Abbiamo continuato a tenere d’occhio le cose e siamo stati soddisfatti di scoprire che le cose si sarebbero svolte senza intoppi nei giorni successivi.
Inoltre, durante il mese precedente, abbiamo notato alcuni cali di prestazioni su pod specifici il venerdì, tuttavia le cose sono migliorate il 12 luglio, il che ci ha dato maggiore fiducia nelle nostre modifiche. In seguito, il 15 luglio, non abbiamo riscontrato alcun aumento o aumento delle prestazioni, il che ci ha fatto pensare che il problema fosse stato risolto.
Elementi correttivi
Sono state pianificate ulteriori strategie per migliorare ulteriormente la stabilità del sistema e prevenire future interruzioni:
- Avviso per errori di Readiness Probe: Implementa uno smoke test per avvisare tempestivamente il team tecnico di eventuali problemi, consentendo un’azione rapida.
- Considerazioni sul recupero dei pattern: Consigli agli sviluppatori di software di considerare attentamente il volume e la frequenza del recupero delle informazioni per evitare squilibri nel sistema.
- Definizione di una base di richieste: Determina la capacità del sistema di gestire le richieste simultanee di informazioni sui ticket per evitare il malfunzionamento del sistema.
- Distanzia i recuperi: Introduci un jitter per mitigare i fragorosi effetti della mandria.
- Scopri una conservazione degli abbonamenti più aggraziata: Studia i modi per gestire gli abbonamenti in modo più efficace durante le distribuzioni.
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.