Búsquedas recientes
No hay búsquedas recientes

Attila Takacs
Incorporación 14 abr 2021
·
Última actividad 05 feb 2025
Seguimientos
0
Seguidores
2
Actividad total
72
Voto
1
Suscripciones
63
RESUMEN DE LA ACTIVIDAD
INSIGNIAS
ARTÍCULOS
PUBLICACIONES
COMENTARIOS DE LA COMUNIDAD
COMENTARIOS DE ARTÍCULOS
RESUMEN DE LA ACTIVIDAD
Última actividad de Attila Takacs
Attila Takacs creó un artículo,
RESUMEN
05 de febrero de 2025 11:48 a.m. UTC | 05 de febrero de 2025 03:48 a.m. PT
Nos complace informarle que nuestro equipo de ingeniería ha identificado y resuelto los problemas de inicio de sesión con nuestro servicio de Guide. Ahora debería poder acceder al servicio sin ningún problema. Gracias por su paciencia y comprensión durante este incidente. Si sigue teniendo problemas, comuníquese con nuestro equipo de soporte.
05 de febrero de 2025 11:29 a.m. UTC | 05 de febrero de 2025 03:29 a.m. PT
Estamos experimentando una degradación del servicio con el inicio de sesión del servicio Guide desde navegadores móviles. Si encuentra errores al acceder a su cuenta, intente iniciar sesión desde un escritorio. Nuestro equipo está trabajando activamente para resolver el problema.
POST-MORTEM
TBD
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de Zendesk y los impactos específicos en su cuenta, visite nuestra página de estado del sistema. Puede seguir este artículo para recibir una notificación cuando se publique nuestro informe post-mortem. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 05 feb 2025 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 1 de febrero de 2025, de 00:13 UTC a 00:59 UTC, los clientes del POD 26 tuvieron problemas para acceder a los tickets archivados. Durante este tiempo, varios nodos lectores de bases de datos no pudieron abrir una tabla debido a un defecto en el sistema de la base de datos. Esto resultó en consultas fallidas para los tickets archivados.
CRONOGRAMA
1 de febrero de 2025 01:13 a.m. UTC | 31 de enero de 2025 05:13 p.m. PT
Nos complace informar que el problema que causaba errores que afectaban a un grupo de nuestros clientes de Support en el POD 26 ya ha sido resuelto. Gracias por su paciencia durante nuestra investigación.
1 de febrero de 2025 12:57 a.m. UTC | 31 de enero de 2025 04:57 p.m. PT
Nuestros ingenieros creen que han identificado la causa raíz de los errores que afectan a un grupo de nuestros clientes de Support en el POD 26 y están trabajando para resolver el problema.
1 de febrero de 2025 12:57 a.m. UTC | 31 de enero de 2025 04:57 p.m. PT
Estamos investigando posibles errores para nuestros clientes de Support alojados en el POD 26.
POST-MORTEM
Análisis de causa raíz
Este incidente fue causado por un defecto en el sistema de la base de datos que impedía que los nodos lectores del clúster accedieran a una tabla de tickets archivados. El defecto fue confirmado por el soporte técnico de nuestro proveedor y era específico de la versión de la base de datos instalada en ese momento.
Resolución
Para resolver este problema, nuestros ingenieros detuvieron una implementación en otros fragmentos y permitieron que las modificaciones en curso se completaran en los fragmentos afectados. En ese momento, se podía acceder a la tabla de la base de datos. Posteriormente, el equipo planea actualizar a una nueva versión de nuestro sistema de base de datos, que incluye un parche para el defecto identificado.
Elementos de corrección
- Actualice a la versión con parches o una versión posterior antes de reanudar los cambios de esquema.
- Divida las adiciones de columnas y las eliminaciones de índices en acciones separadas para minimizar el riesgo durante las implementaciones.
- Actualice el run-book para exigir que las migraciones grandes lleguen solo a un clúster inicialmente antes de expandirse a otros.
- Implemente un proceso de revisión regular (por lo menos una vez al año) de los parches del sistema de base de datos y establezca un ritmo de actualización.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de Zendesk y los impactos específicos en su cuenta, visite nuestra página de estado del sistema. Puede seguir este artículo para recibir una notificación cuando se publique nuestro informe post-mortem. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 06 feb 2025 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 13 de enero de 2025 de 11:07 UTC a 12:07 UTC, los clientes del pod 17 experimentaron problemas con los disparadores de mensajería que no se ejecutaban.
CRONOGRAMA
13 de enero de 2025 12:24 p.m. UTC | 13 de enero de 2025 04:24 a.m. PT
El problema reciente de mensajería se ha resuelto por completo y nuestros servicios han vuelto a funcionar por completo. Gracias por su paciencia durante este tiempo. Nuestro equipo seguirá monitoreando de cerca nuestros sistemas para garantizar que todo funcione sin problemas. Agradecemos su apoyo y estamos aquí para cualquier pregunta o comentario que pueda tener.
13 de enero de 2025 11:51 a.m. UTC | 13 de enero de 2025 03:51 a.m. PT
Estamos investigando problemas con la ejecución de disparadores de mensajería para nuestros clientes en POD17.
POST-MORTEM
Análisis de causa raíz
Este incidente fue causado por las terminaciones prematuras de los consumidores para el servicio de eventos de registro de tickets de mensajería, que ocurrieron mientras el servicio aún estaba en ejecución. Como resultado, los consumidores no pudieron procesar los eventos entrantes, lo que detuvo por completo la evaluación y la ejecución de los disparadores de mensajería en el pod 17.
Resolución
Para resolver este problema, identificamos el error de configuración que establecía el número máximo de registros que se podían procesar en un solo lote en 500 en lugar de los 250 previstos. Al corregir este error tipográfico y reducir el valor máximo de registros, nuestro objetivo era disminuir la probabilidad de que los clientes terminaran debido a problemas de tiempo de espera.
Elementos de corrección
- Implemente una verificación de estado para detectar las terminaciones prematuras de los consumidores.
- Cree un monitor para hacer seguimiento del número de consumidores activos.
- Establecer un monitor para monitorear las particiones detenidas para el consumidor de eventos del registro de tickets de Tessaging.
- Agregue un widget de estado de retraso del consumidor al panel Servicio de disparadores de mensajería.
- Cree una nueva métrica para medir el tiempo que se tarda en procesar un lote de mensajes del tema Eventos del registro de tickets de mensajería.
Estas correcciones están diseñadas para mejorar el monitoreo y evitar incidentes similares en el futuro, lo que garantiza la estabilidad y confiabilidad del servicio Messaging Trigger.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de Zendesk y los impactos específicos en su cuenta, visite nuestra página de estado del sistema. Puede seguir este artículo para recibir una notificación cuando se publique nuestro informe post-mortem. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 29 ene 2025 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 9 de diciembre de 2024, de 8:08 UTC a 13:03 UTC, los clientes que usaban la funcionalidad multimarca experimentaron errores al intentar crear tickets o actualizar los títulos de los tickets, pero los cambios se guardaron.
Cronología
9 de diciembre de 2024 22:21 UTC | 14:21 (hora del Pacífico)
Nos complace informarle que el cambio reciente se ha revertido correctamente y que el problema con la creación de tickets multimarca ya se ha resuelto.
Si aún tiene problemas, intente realizar una actualización completa (Ctrl + F5) o borre la memoria caché y las cookies del navegador, ya que esto puede ayudar a resolver los problemas persistentes.
No dude en comunicarse si sigue teniendo dificultades. Gracias por su paciencia.
9 de diciembre de 2024 12:58 p.m. UTC | 04:58 a.m. (PT)
Actualmente tenemos problemas con la creación de tickets multimarca. Nuestro equipo de ingeniería está al tanto del problema y está trabajando activamente para resolverlo lo más rápido posible.
Proporcionaremos actualizaciones tan pronto como haya más información disponible. Gracias por su paciencia y comprensión.
POST-MORTEM
Análisis de causa raíz
La causa raíz del incidente fue una falla en la lógica de inicialización del ticket. Cuando la ID del solicitante no estaba definida, el sistema intentaba recuperarla en función de la clave del ticket, lo que generaba errores cada vez que se producía un cambio de campo en la interfaz de usuario del ticket. La introducción de una nueva lógica para leer la ID de usuario de la página de perfil de usuario y establecerla en la ID del solicitante inadvertidamente estableció el objeto del solicitante en undefined, lo que rompió la funcionalidad esperada.
Resolución
Para resolver el problema, se revirtió la actualización problemática.
Elementos de corrección
- Corregir código defectuoso: Asegúrese de que el sistema establezca correctamente los datos del solicitante al crear tickets para evitar entradas en blanco.
- Agregar pruebas automáticas: Cree una prueba para verificar que el proceso de guardado del ticket maneje correctamente la información del solicitante.
- Confirmar prueba manual: Requerir que los implementadores prueben manualmente los cambios en los POD “canary” y confirmen que todo funciona antes de la implementación.
- Mejorar el monitoreo: Configure el monitoreo para alertar sobre errores del navegador, como “algo salió mal”, para identificar rápidamente los problemas.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, contacte a atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 17 dic 2024 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 3 de diciembre de 2024 desde las 21:09 UTC hasta las 3:36 UTC del 7 de diciembre de 2024, algunos clientes que usaban el SDK para móviles experimentaron 400 errores al crear tickets. Debido a un cambio, a los tokens OAuth recién creados se les asignó un tiempo de vencimiento predeterminado de 8 horas. Este cambio inadvertidamente rompió los SDK para móviles heredados, que no podían recuperar nuevos tokens si sus tokens existentes dejaban de ser válidos, lo que generaba una experiencia frustrante para los usuarios. El problema se resolvió revirtiendo el cambio.
Cronograma
6 de diciembre de 2024 6:20 p.m. UTC | 6 de diciembre de 2024 10:20 a.m. PT
Nos complace informar que se ha resuelto el problema que hacía que algunos clientes experimentaran errores 400 al crear tickets a través del SDK. Nos disculpamos por cualquier interrupción que esto pueda haber causado y le agradecemos su paciencia durante nuestra investigación.
6 de diciembre de 2024 12:06 p.m. UTC | 6 de diciembre de 2024 04:06 a.m. PT
Nuestro equipo continúa trabajando para corregir el comportamiento que causa los errores 400 en los envíos de tickets a través de la API a través de nuestro SDK para móviles. Por ahora, si los usuarios finales encuentran este error, pueden reiniciar la aplicación y los tickets se crearán normalmente.
6 de diciembre de 2024 09:45 a.m. UTC | 6 de diciembre de 2024 01:45 a.m. PT
Somos conscientes de que algunos de nuestros clientes pueden experimentar errores 400 al intentar crear tickets a través de nuestro SDK para móviles. Si se encuentra con este error, reinicie la aplicación para solucionar el problema.
POST-MORTEM
Análisis de causa raíz
Este incidente surgió por un descuido al evaluar cómo se utilizaban los tokens de autenticación en los diferentes productos antes de implementar un cambio en su tiempo de vencimiento. Los SDK heredados por diseño no pueden obtener nuevos tokens de OAuth cuando vencen los tokens existentes, pero este aspecto no se tuvo en cuenta completamente durante las etapas de planificación e integración. Una colaboración mejorada y una evaluación más exhaustiva del uso de tokens podrían haber ayudado a evitar esta interrupción.
Resolución
Para resolver el problema, el equipo de autenticación primero desactivó el proceso de reposición que agregaba tiempos de vencimiento a los tokens existentes. Posteriormente, implementaron una solicitud de extracción que revirtió la configuración de vencimiento para los tokens nuevos e inició un reabastecimiento para eliminar el vencimiento de los tokens existentes. Esta acción restauró la funcionalidad para la mayoría de los clientes afectados.
Elementos de corrección
- Establezca un protocolo de comunicación claro entre los equipos para garantizar que los defectos conocidos estén debidamente documentados y revisados antes de implementar cambios significativos.
- Mejorar las herramientas de implementación existentes para administrar mejor el flujo de autenticación y reducir la deuda técnica asociada con los SDK heredados.
- Cree alertas adicionales y sistemas de monitoreo para detectar problemas similares en el futuro, centrándose particularmente en las fallas del token OAuth .
- Introducir límites de conexión en aplicaciones específicas para evitar la generación excesiva de tokens y mitigar la inflación del tamaño de la base de datos.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, contacte a atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 20 dic 2024 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 21 de noviembre de 2024, de 21:02 UTC a 21:56 UTC, algunos clientes que usaban Sunshine Conversations alojado en el pod 17 experimentaron problemas de lentitud y rendimiento.
CRONOGRAMA
24 de noviembre de 2024 22:23 UTC | 24 de noviembre de 2024 02:23 p.m. PT
Nos complace anunciar que ya se han resuelto los problemas de latencia que afectaban a Sunshine Conversations para algunos de nuestros clientes en el POD 17. ¡Muchas gracias por su paciencia!
24 de noviembre de 2024 22:09 UTC | 24 de noviembre de 2024 02:09 p.m. PT
Creemos que hemos identificado la causa raíz de los problemas de rendimiento que afectan a SunCo para nuestro cliente en Pod17. Ahora estamos viendo mejoras y continuaremos monitoreando el comportamiento.
24 de noviembre de 2024 09:53 p.m. UTC | 24 de noviembre de 2024 01:53 p.m. PT
Seguimos investigando los problemas de rendimiento del pod 17. Esto puede causar lentitud en Sunshine Conversations. Proporcionaremos más actualizaciones en breve.
24 de noviembre de 2024 09:36 p.m. UTC | 24 de noviembre de 2024 01:36 p.m. PT
Estamos investigando posibles problemas de rendimiento que afectan a algunos de nuestros clientes alojados en el pod 17. Próximamente publicaremos una actualización con más detalles.
POST-MORTEM
Análisis de causa raíz
Este incidente fue causado por un aumento inesperado en el tráfico en el Pod17, que se duplicó con creces en la semana anterior y casi se triplicó el día del incidente. El SDK de Unity utilizado por un cliente estaba haciendo demasiadas solicitudes a la API de SunCo para recuperar los recuentos de mensajes no leídos, lo que aumentaba la carga en el sistema. El escalador automático de recursos ya estaba al máximo de su capacidad, lo que impedía agregar más recursos para manejar el aumento del tráfico. En consecuencia, esta sobrecarga resultó en tiempos de respuesta más lentos y, en última instancia, activó verificaciones de estado que iniciaron reinicios, lo que agravó el problema.
Resolución
Para resolver los problemas de rendimiento, aumentamos el número máximo de réplicas para la API de SunCo en el Pod17. Este ajuste permitió que el sistema manejara mejor el aumento del tráfico y restableció los tiempos de respuesta normales para todos los clientes.
Elementos de corrección
- Investigue el SDK de Unity para comprender por qué está enviando una cantidad excesiva de solicitudes a SunCo e implemente optimizaciones.
- Documente los patrones de interacción de back-end en incrustables para aclarar el uso e identificar posibles ineficiencias.
- Evaluar la implementación de una estrategia de almacenamiento en caché para las API de SDK en SunCo para reducir el número de solicitudes realizadas.
- Agregue monitoreo para detectar el crecimiento anormal del tráfico durante períodos específicos para abordar de manera proactiva las posibles sobrecargas.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 24 nov 2024 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
Entre las 23:30 UTC del 12 de noviembre de 2024 y las 11:26 UTC del 15 de noviembre de 2024, los clientes de Support que usaban SLA en los pods 25 y 30 experimentaron cálculos de SLA retrasados, y las insignias de SLA en sus tickets no aparecían como se esperaba después de aplicable actualizaciones de tickets.
CRONOGRAMA
15 de noviembre de 2024 13:00 UTC | 15 de noviembre de 2024 05:00 a.m. PT
Nos complace informar que ya se han resuelto los problemas que afectan el rendimiento de los SLA de métricas en los pods 25 y 30. Gracias por su paciencia.
15 de noviembre de 2024 12:16 p.m. UTC | 15 de noviembre de 2024 04:16 a.m. PT
Ahora estamos viendo mejoras en el problema que afecta el rendimiento de los SLA de métricas en los pods 25 y 30. Seguimos monitoreando y proporcionaremos más actualizaciones tan pronto como las tengamos.
POST-MORTEM
Análisis de causa raíz
Este incidente fue causado por un secreto mal configurado para el servicio de eventos de métricas. Esto significaba que cuando Zendesk implementaba una actualización con validación adicional, el servicio no se inicializaba para las implementaciones de Asia-Pacífico, lo que generaba demoras en el procesamiento.
Resolución
Para solucionar este problema, se agregó un valor "predeterminado" para el secreto afectado el 15 de noviembre de 2024. Esto permitió que el servicio de eventos de métricas se inicializara correctamente y reanudara las operaciones normales. Zendesk también identificó y estableció un valor predeterminado para un secreto del servicio de transcripción de conversaciones para mitigar cualquier riesgo futuro.
Elementos de corrección
- Realice una auditoría exhaustiva de todos los secretos para asegurarse de que los valores estén establecidos para todas las localidades, especialmente en las regiones de Asia y el Pacífico.
- Mejore las herramientas de implementación existentes para evitar errores de configuración similares en el futuro.
- Cree alertas adicionales para notificar a los equipos pertinentes sobre fallas y problemas de inicialización.
- Investigue el seguimiento de las métricas de fallas para asegurarse de que dichos incidentes activen alertas para resoluciones oportunas.
Al implementar estas soluciones, nuestro objetivo es mejorar la resiliencia de nuestros servicios y evitar incidentes similares en el futuro.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 04 dic 2024 · Attila Takacs
0
Seguidores
1
Voto
0
Comentarios
Attila Takacs creó un artículo,
RESUMEN
El 14 de noviembre de 2024 desde las 14:15 UTC hasta las 23:20 UTC, los clientes que usaban Explore experimentaron errores de red al acceder a los informes y paneles.
Cronograma
14 de noviembre de 2024 06:11 p.m. UTC | 14 de noviembre de 2024 10:11 a.m. PT
Nos complace informar que se ha resuelto el problema que causaba los mensajes de "Error de red" al cargar los paneles o informes de Explore. Gracias por su paciencia durante nuestra investigación.
14 de noviembre de 2024 03:18 p.m. UTC | 14 de noviembre de 2024 07:18 a.m. PT
Algunos usuarios de Explore pueden ver un mensaje de "Error de red" al cargar paneles o informes. Si esto sucede, el problema se resolverá borrando las cookies y la memoria caché del navegador. Disculpe las molestias.
POST-MORTEM
Análisis de causa raíz
Este incidente fue causado por un cambio en la red que aumentó el número de encabezados enviados al servicio de Explore más allá del límite configurado. Esto provocó que el servicio fallara silenciosamente, lo que provocó que los paneles no se cargaran para los clientes.
Resolución
Para resolver este problema, se envió un mensaje al equipo de red para que investigara los cambios. Una vez identificado el problema, revirtieron los cambios que agregaban encabezados excesivos, lo que restauró la funcionalidad normal de los paneles de Explore.
Elementos de corrección
- Mejorar las herramientas de implementación existentes: Revise y mejore las herramientas que se usan para administrar los límites de encabezados en las solicitudes de API para evitar incidentes similares.
- Crear alertas adicionales: Configure alertas para monitorear los recuentos de encabezados y otras métricas críticas para detectar problemas antes de que afecten a los clientes.
- Agregue límites de conexión en aplicaciones específicas: Implemente límites de conexión en las API para asegurarse de que no excedan los umbrales operativos, lo que reduce el riesgo de futuros incidentes.
PARA MÁS INFORMACIÓN
Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 03 dic 2024 · Attila Takacs
1
Seguidor
1
Voto
0
Comentarios