Comprender dónde dirigirse y qué esperar durante un incidente
Cuando hablamos de un "incidente", estamos hablando específicamente de un problema en nuestro lado de Microsoft/Azure, un problema del lado de la plataforma que afecta a los servicios. Durante estos problemas poco frecuentes pero inevitables, nuestro objetivo es ser lo más transparente posible con usted proporcionando actualizaciones periódicas directas de nuestros ingenieros. Nos esforzamos por informar a las personas adecuadas a través de los canales adecuados y compartir tantos detalles como sea posible.
Aunque por lo general no compartimos especulación ni el funcionamiento interno de los pasos de solución de problemas, compartimos todo lo que sabemos sobre el incidente. No hay ningún retraso en la mensajería, incluso para la mensajería detallada, basada en el tamaño o segmento del cliente, el estado del asociado o el plan de soporte técnico, por lo que las organizaciones asociadas de Microsoft e incluso los equipos de cuentas de Microsoft se notifican al mismo tiempo y con las mismas actualizaciones que los clientes afectados que representan.
Durante un incidente
Revise Azure Service Health en Azure Portal para obtener las actualizaciones más recientes de nuestros ingenieros.
Si nota un problema y necesita averiguar si "somos nosotros o es Azure", debería empezar por comprobar Azure Service Health en el portal. Aunque debería estar al tanto de este lugar de " referencia", no debería tener que buscar información de forma reactiva, si ha configurado de antemano las alertas pertinentes sobre el estado del servicio. Durante un problema conocido, estas alertas de estado del servicio se desencadenarán y se notificarán mediante su canal de comunicaciones elegido.
Nota:
Como recordatorio, configure la alerta de Service Health para recibir notificaciones de las comunicaciones del portal a través del canal de su elección (correo electrónico, SMS, webhook).
Si hay problemas para acceder al Service Health o al propio portal, compruebe la página pública de Estado de Azure.
En el improbable caso de que un problema de servicio le impida acceder al Service Health en Azure Portal, se usará azure.status.microsoft para publicar las actualizaciones del problema. Esta página solo se usa para problemas que interrumpen la ruta de comunicación habitual o para problemas poco frecuentes.
Es importante recordarle que azure.status.microsoft sirve realmente como respaldo de Azure Service Health. La mayoría de nuestras comunicaciones de problemas de servicio se proporcionan como notificaciones dirigidas enviadas directamente a suscripciones o inquilinos afectados. Se entregan a través de Azure Service Health en Azure Portal y desencadenan las alertas de Azure Service Health que se han configurado. La página de estado público (azure.status.microsoft) solo se usa para comunicarse sobre los problemas de servicio en tres escenarios específicos:
Escenario 1: Un impacto grande, que implica varias regiones, zonas o servicios: un problema de servicio que tiene un impacto grande o significativo para el cliente en varios servicios, abarcando una región completa o varias. Le avisamos en este caso porque la capacidad de recuperación configurada por el cliente, como la alta disponibilidad o la recuperación ante desastres, puede no ser suficiente para evitar el impacto.
Escenario 2: Azure Portal o Service Health no accesible: un problema de servicio impide el acceso a Azure Portal o a Azure Service Health y, por tanto, afecta a nuestra ruta estándar de comunicación de interrupciones, descrita anteriormente.
Escenario 3: Hay un impacto en el servicio, pero aún no está claro a quién ha afectado: el problema de servicio tiene un impacto grande o significativo para el cliente, pero aún no podemos confirmar qué clientes, regiones o servicios se ven afectados. En este caso, no podemos enviar comunicaciones dirigidas, por lo que proporcionamos actualizaciones públicas.
Si hay problemas con la página de Estado, compruebe si hay actualizaciones a través de @AzureSupport en X.
Solo unas pocas veces en la historia de Azure, ha habido problemas técnicos que han impedido publicar actualizaciones de incidentes en azure.status.microsoft. En estas circunstancias extraordinarias, publicamos actualizaciones de incidentes a través de X en @AzureSupport. Sin embargo, independientemente del problema, los clientes deben sentirse libres de ponerse en contacto con @AzureSupport para cualquier pregunta relacionada con posibles problemas que estén viendo o con cuestiones de soporte. El equipo de @AzureSupport suele responder en menos de 5 minutos (¡estamos muy orgullosos de ello!), pero es importante saber que durante los problemas conocidos (por ejemplo, si hay una interrupción en Service Health) los ingenieros adecuados ya están trabajando en el incidente, por lo que potencialmente no hay mucho que el equipo de @AzureSupport pueda hacer para ayudar, más allá de dirigir a los clientes a las actualizaciones oficiales de ingeniería sobre lo que está sucediendo.
Si el impacto o los problemas no coinciden con el incidente (o si se conservan después de la mitigación), póngase en contacto con el soporte técnico.
Esta es la nota más importante para que los clientes comprendan qué hacer (o no hacer) durante un incidente. Como se mencionó anteriormente, durante los problemas conocidos (por ejemplo, si hay una interrupción en Service Health), los ingenieros adecuados ya están trabajando en el incidente, por lo que los clientes no necesitan ponerse en contacto con el soporte técnico para las actualizaciones. Recibirán actualizaciones periódicas a través de Service Health (y sus alertas de Service Health) y los ingenieros de soporte técnico no tienen acceso a información más detallada de la que se proporciona a los clientes afectados. Si los clientes han leído las actualizaciones de ingeniería, pero requieren soporte técnico para responder al incidente (por ejemplo, para implementar sus planes de conmutación por error), pueden y deben generar una incidencia de soporte técnico.
Del mismo modo, si los síntomas que observa no parecen "alinearse" con los síntomas que se describen en las actualizaciones del problema (por ejemplo, si hay un problema conocido con Redis Cache en el Este de EE. UU., pero está viendo problemas con Redis Cache en el Este de EE. UU. 2), puede que no esté relacionado y los clientes pueden y deben generar una incidencia de soporte técnico. Por último, si se resuelve o mitiga un problema de servicio, pero el cliente sigue viendo problemas con sus servicios, los ingenieros de soporte técnico pueden ayudar a ver si hay algo especial que sucede con sus recursos, por lo que los clientes pueden y deben generar una incidencia de soporte técnico.