Avances en relación con las interrupciones del servicio: automatización, comunicación y transparencia

Publicado el 17 agosto, 2020

Chief Technology Officer, Microsoft Azure

“Lamentablemente, los incidentes de servicio, como las interrupciones, son inevitables en el sector de la tecnología. Por supuesto, mejoramos constantemente la confiabilidad de la plataforma en la nube Microsoft Azure. Cumplimos y superaremos nuestros acuerdos de nivel de servicio para la gran mayoría de los clientes y seguiremos invirtiendo en cursos y herramientas en constante evolución que faciliten el diseño y la administración de sistemas críticos con confianza.

A pesar de estos esfuerzos, tenemos que reconocer la triste realidad. Dada la escala de nuestras operaciones y el ritmo del cambio, nunca podremos evitar las interrupciones por completo. En esas ocasiones, nos esforzamos por ser los más abiertos y transparentes posible para asegurarnos de que todos los clientes y asociados afectados sepan lo que está sucediendo. Dentro de nuestra serie de entradas de blog sobre la mejora de la confiabilidad, le pedí a Sami Kubba, administrador de programas principal que supervisa el proceso de comunicación durante las interrupciones, que explicara las inversiones que estamos realizando para seguir mejorando esta experiencia”. —Mark Russinovich, director de tecnología, Azure.


 

En el sector de la nube, tenemos el compromiso de ofrecer a nuestros clientes la tecnología más reciente a gran escala, manteniendo la seguridad tanto de los clientes como de la plataforma y asegurándonos de que la experiencia de los clientes sea siempre óptima. Para que esto sea posible, Azure está sujeto a un volumen de cambios importante y, en circunstancias excepcionales, son estos cambios los que pueden suponer un impacto imprevisto para nuestros clientes. Como hemos mencionado antes en esta serie de entradas de blog, nos tomamos los cambios muy en serio y nos aseguramos de que disponemos de un enfoque sistemático y por fases para implementar los cambios con el mayor cuidado posible.

Seguimos identificando las imperfecciones inherentes (y, a veces, sutiles) de las formas complejas en las que nuestros diseños arquitectónicos, procesos operativos, problemas de hardware, defectos de software y factores humanos pueden alinearse para causar incidentes de servicio, también conocidos como interrupciones. La realidad de nuestro sector es que el impacto causado por los cambios es un problema intrínseco. Cuando pensamos en la comunicación de una interrupción, no solemos pensar que la competencia son otros proveedores de nube, sino más bien el entorno local. En el entorno local, los administradores controlan los períodos de implementación de cambios. Eligen el mejor momento para invocar cualquier cambio, administrar y supervisar los riesgos, y revertirlo si se detectan errores.

Del mismo modo, cuando se produce una interrupción en un entorno local, los clientes y los usuarios sienten que “tienen más conocimiento” al respecto. La directiva tiene pleno conocimiento en seguida de la interrupción, se pone en contacto con el servicio de soporte técnico para solucionar el problema y espera que su equipo o asociado pueda proporcionar un informe completo posterior al incidente (PIR), antes conocido como análisis de la causa principal, una vez que se tiene una idea clara del problema. Aunque nuestro análisis de los datos sustenta la hipótesis de que el tiempo para mitigar un incidente es más rápido en la nube que en el entorno local, las interrupciones en la nube pueden ser más estresantes para los clientes cuando se trata de comprender el problema y de qué pueden hacer al respecto.

Nuestros principios de comunicación

Durante las interrupciones en la nube, algunos clientes han dicho siempre que no se les ha informado con prontitud o que les faltan actualizaciones necesarias y, por tanto, no tienen una idea clara de lo ocurrido ni de lo que se está haciendo para evitar que se produzcan problemas en el futuro. En respuesta a estas opiniones, hemos incluido en nuestras operaciones cinco pilares que guían nuestra estrategia de comunicaciones y en los que se basa nuestra experiencia de Azure Service Health en Azure Portal, y son los siguientes:

  1. Velocidad
  2. Granularidad
  3. Detectabilidad
  4. Paridad
  5. Transparencia

Velocidad

Debemos informar a los clientes afectados lo más rápido posible. Este es nuestro objetivo principal en torno a la comunicación de las interrupciones. Nuestro objetivo es informar de todas las suscripciones de Azure afectadas en un plazo de 15 minutos desde que se produce una interrupción. Sabemos que no podemos lograr esto solo con personas. Para cuando un ingeniero se pone a investigar una alerta de supervisión para confirmar el impacto (no digamos ya llamar a los ingenieros adecuados para mitigarlo, en lo que puede ser una red compleja de interconexiones, incluidas dependencias de terceros), ha pasado demasiado tiempo. Cualquier retraso en la comunicación deja a los clientes preguntándose: “¿Soy yo o es Azure?”. Así, puede que los clientes dediquen un tiempo innecesario a solucionar el problema en su propio entorno. En cambio, si decidimos pecar por exceso de precavidos e informar cada vez que tengamos la sospecha de cualquier posible impacto en los clientes, estos podrían recibir demasiados falsos positivos. Y lo que es más importante: si están teniendo un problema en su propio entorno, podrían atribuir fácilmente ese problema no relacionado a una falsa alarma enviada por la plataforma. Es fundamental invertir para que nuestras comunicaciones sean tanto rápidas como precisas.

El mes pasado, hablamos sobre nuestra inversión constante en mejorar la calidad de los servicios de Azure con inteligencia artificial: AIOps. Esto incluye trabajar para mejorar la detección automática, la involucración y la mitigación de las interrupciones en la nube. Los elementos de este amplio programa de AIOps ya se usan en producción para informar a los clientes de las interrupciones que pueden afectar a sus recursos. Estas notificaciones automáticas representaron más de la mitad de las comunicaciones de interrupciones en el último trimestre. Para muchos servicios de Azure, se envían notificaciones automáticas en menos de 10 minutos a los clientes afectados a través de Service Health, para acceder a ellas en Azure Portal o para desencadenar alertas de Service Health que se hayan configurado. Hablaremos sobre esto más adelante.

Con nuestra inversión en esta área, que ya ha mejorando la experiencia de los clientes, continuaremos ampliando los escenarios en los que podemos informar a los clientes en menos de 15 minutos desde que se inicia el impacto, todo ello sin la necesidad de personas que confirmen el impacto en el cliente. También estamos en las primeras etapas de la ampliación del uso de operaciones basadas en inteligencia artificial para identificar automáticamente los servicios afectados relacionados y, tras la mitigación, comunicar la resolución (para los escenarios admitidos) lo más rápido posible.

Granularidad

Sabemos que, cuando una interrupción provoca un impacto, los clientes necesitan saber exactamente cuáles de sus recursos se han visto afectados. Uno de los principales bloques de creación para obtener el estado de los recursos específicos son las señales de Resource Health. La señal de Resource Health comprueba si un recurso, como una máquina virtual (VM), una base de datos SQL o una cuenta de almacenamiento, tiene un estado correcto. Los clientes también pueden crear alertas de Resource Health, que aprovechan Azure Monitor, para hacer saber a las personas adecuadas si un recurso determinado tiene problemas, independientemente de si se trata de un problema de toda la plataforma o no. Es importante tener en cuenta que se puede desencadenar una alerta de Resource Health si un recurso pasa a tener un estado incorrecto (por ejemplo, si una máquina virtual se reinicia desde el invitado) que no esté necesariamente relacionado con un evento de la plataforma, como una interrupción. Los clientes pueden ver las comprobaciones de Resource Health asociadas, organizadas por tipo de recurso.

Estamos construyendo en esta tecnología para aumentar y correlacionar cada uno de los recursos de cliente que se han pasado a un estado incorrecto con interrupciones de la plataforma, todo dentro de Service Health. También estamos investigando cómo podemos incluir los recursos afectados en nuestras cargas de comunicación, de modo que los clientes no tengan que iniciar sesión en Service Health para saber los recursos afectados. Por supuesto, todos deberían poder usar esta opción mediante programación.

Todo esto permitirá que los clientes con un gran número de recursos sepan con más exactitud cuáles de sus servicios se han visto afectados por una interrupción, sin tener que investigarlo por su parte. Y lo que es más importante: los clientes pueden crear alertas y desencadenar respuestas a estas alertas del estado de los recursos mediante la integración nativa con Logic Apps y Azure Functions.

Detectabilidad

Aunque admitimos enfoques tanto de “inserción” como de “extracción” para la comunicación de interrupciones, se recomienda a los clientes que configuren alertas pertinentes para que se envíe automáticamente la información correcta a las personas y los sistemas que corresponda. Nuestros clientes y asociados no deben tener que buscar para ver si los recursos que le interesan se ven afectados por una interrupción, ya que deben poder usar las notificaciones que se envían (en el medio de su elección) y reaccionar a ellos según corresponda. A pesar de esto, vemos constantemente que los clientes visitan la página Estado de Azure para determinar el estado de los servicios en Azure.

Antes de incorporar la experiencia autenticada de Service Health en el portal, la página Estado de Azure era la única manera de saber los problemas conocidos de la plataforma. Actualmente, esta página pública sobre el estado solo se usa para comunicar interrupciones generalizadas (por ejemplo, que afecten a varias regiones o a varios servicios), por lo que los clientes que busquen posibles problemas que les afecten no verán ahí toda la información. Dado que implementamos los cambios en la plataforma de la manera más segura posible, la gran mayoría de los problemas, como las interrupciones, solo afectan a las suscripciones de clientes que se encuentran en un “radio de impacto” muy reducido. Estos problemas, que son más del 95 % de nuestros incidentes, se comunican directamente a los clientes afectados en el portal a través de Service Health.

También hemos integrado recientemente la característica “Problemas emergentes” en Service Health. Esto significa que, si se indica un incidente en la página pública sobre el estado y todavía tenemos que identificar e informar a los clientes afectados, los usuarios pueden ver esta misma información en el portal a través de Service Health, con lo que recibirán toda la información pertinente sin tener que visitar la página Estado de Azure. Animamos a todos los usuarios de Azure a que usen Service Health como único lugar central donde obtener información relacionada con incidentes de servicio, de modo que puedan ver los problemas que les afectan, saber cuáles de sus suscripciones y recursos se han visto afectados y evitar el riesgo de hacer una correlación falsa, como cuando se publica un incidente en la página Estado de Azure, pero no les afecta a ellos.

Y lo que es más importante, puesto que estamos hablando del principio de detectabilidad: en Service Health, los clientes pueden crear alertas de Service Health, que son notificaciones push que aprovechan la integración con Azure Monitor. De esta manera, los clientes y asociados pueden configurar notificaciones pertinentes en función de quién tiene que recibirlas y cuál es la mejor manera de informarles, por ejemplo, por correo electrónico, SMS, LogicApp o a través de un webhook que se puede integrar en herramientas de administración de servicios, como ServiceNow, Ops Genie o PagerDuty.

Para empezar a trabajar con alertas sencillas, considere el enrutamiento de todas las notificaciones para enviar el correo a una sola lista de distribución. Si desea avanzar al siguiente nivel, considere la posibilidad de configurar diferentes alertas de estado de los servicios para casos de uso diferentes. Por ejemplo, todos los problemas de producción se podrían notificar a ServiceNow; los problemas de desarrollo y pruebas o de preproducción se podrían enviar por correo electrónico solo al equipo de desarrollo pertinente; cualquier problema con una suscripción determinada se podría notificar con un mensaje de texto a las personas correspondientes. Todo esto es totalmente personalizable, para asegurarse de que las personas adecuadas reciben una notificación de la forma correcta.

Paridad

Todos los usuarios de Azure deben saber que Service Health es el lugar que deben consultar para saber todos los eventos que afectan a los servicios. En primer lugar, nos aseguramos de que esta experiencia sea coherente entre todos los servicios de Azure, donde cada uno de ellos usa Service Health para comunicar cualquier problema. A pesar de lo sencillo que esto suena, todavía estamos explorando algunos escenarios únicos que lo hacen complejo. Por ejemplo, la mayoría de las personas que usan Azure DevOps no interactúan con Azure Portal. Dado que DevOps no tiene su propia experiencia de Service Health autenticada, no podemos comunicar las novedades directamente a los clientes afectados cuando se trata de pequeñas interrupciones de DevOps que no justifican su publicación en la página Estado de Azure. Para admitir escenarios como este, hemos configurado la página del estado de Azure DevOps para que se puedan comunicar las interrupciones de DevOps más pequeñas directamente a la comunidad de DevOps.

En segundo lugar, la experiencia de Service Health está diseñada para comunicar todos los eventos que afecten a Azure, que incluyen los eventos de mantenimiento y la retirada de servicios o características, tanto para interrupciones generalizadas como para interrupciones aisladas que solo afecten a una suscripción. Es imperativo que, para cualquier impacto (ya sea potencial, real o próximo), los clientes puedan esperar la misma experiencia y poner en marcha un plan de acción predecible en todos sus servicios de Azure.

Por último, estamos trabajando para ampliar nuestra filosofía de este pilar a otros productos en la nube de Microsoft. Somos conscientes de que, a veces, navegar por nuestros diversos productos en la nube, como Azure, Microsoft 365 y Power Platform, puede dar la impresión de que se están explorando tecnologías de tres empresas distintas. A medida que nos planteamos el futuro, invertimos en la armonización de estos productos para ofrecer una experiencia más coherente y de la máxima calidad.

Transparencia

Como hemos mencionado muchas veces en la serie de entradas de blog sobre la mejora de la confiabilidad, sabemos que la confianza se gana y debe mantenerse. En lo que respecta a las interrupciones del servicio, sabemos que ser transparentes sobre lo que está ocurriendo, lo que sabemos y lo que no sabemos es muy importante. La nube no debería dar la sensación de ser una caja negra. Durante los problemas que se producen en los servicios, informamos periódicamente a todos los clientes y asociados afectados. A menudo, en las primeras etapas de la investigación de un problema, estas actualizaciones no son muy detalladas hasta que obtenemos más información sobre lo que sucede. Aunque nos comprometemos a compartir las noticias tangibles, generalmente evitamos hablar sobre especulaciones, ya que sabemos que los clientes toman decisiones empresariales basadas en estas noticias durante las interrupciones del servicio.

Además, una interrupción no se supera cuando se mitiga el impacto en el cliente. Podríamos seguir analizando las complejidades que dieron lugar al problema, por lo que, a veces, el mensaje que se envía cuando se mitiga o después de mitigar el impacto es un resumen básico de lo que ha sucedido. En el caso de los incidentes más importantes, enviamos un informe posterior al incidente (PIR) en un plazo de tres días, cuando ya tenemos una idea más clara de los factores que han influido.

En el caso de incidentes que afectan a menos suscripciones, nuestros clientes y asociados pueden solicitar un PIR en Service Health. En el pasado, hemos recibido comentarios de que los PIR deben ser aún más transparentes, por lo que seguimos animando a nuestros administradores de incidentes y de comunicaciones a que proporcionen tantos detalles como sea posible, incluida información sobre el impacto del problema y los pasos siguientes para mitigar el riesgo futuro. Lo ideal es que esto sirva para asegurar que esa clase de problema sea menos probable o tenga un impacto menor en el futuro.

Aunque nuestro sector nunca será totalmente inmune a las interrupciones del servicio, hacemos todo lo posible por ver lo sucedido desde una perspectiva holística y compartir nuestros hallazgos. Una de las próximas áreas de inversión que estamos estudiando de cerca es cómo mantener a los clientes al día de nuestro progreso en relación con los compromisos que se describen en los pasos siguientes que se detallan en el PIR. Al vincular nuestros elementos de reparación internos con nuestros compromisos externos en los pasos siguientes, los clientes y asociados podrán hacer un seguimiento del progreso de nuestros equipos de ingeniería para asegurarse de que se llevan a cabo las medidas correctoras.

Nuestras comunicaciones en todos estos escenarios (interrupciones, mantenimiento, retirada de servicios y avisos sobre el estado) seguirán evolucionando a medida que aprendamos más y sigamos invirtiendo en programas que sustenten estos cinco pilares.

La confiabilidad es una responsabilidad compartida

Aunque Microsoft es responsable de la confiabilidad de la plataforma Azure, nuestros clientes y asociados son responsables de la confiabilidad de sus aplicaciones en la nube, incluido el uso de procedimientos recomendados para la arquitectura basados en los requisitos de cada carga de trabajo. Crear una aplicación confiable en la nube es diferente a desarrollar una aplicación tradicional. Puede que los clientes hayan adquirido siempre niveles de hardware redundante de altas prestaciones para reducir al mínimo la probabilidad de que se produzca un error generalizado en una plataforma de aplicaciones. En la nube, somos conscientes de antemano de que se producirán errores. Como ya hemos mencionado varias veces, nunca podremos evitar todas las interrupciones. Además de los intentos de Microsoft por evitar errores, cuando crea aplicaciones confiables en la nube, su objetivo debe ser minimizar los efectos de cualquier componente que dé error.

Para ello, lanzamos recientemente Microsoft Azure Well-Architected Framework, un conjunto de principios orientativos que se pueden usar para mejorar la calidad de una carga de trabajo. La confiabilidad es uno de los cinco pilares de la excelencia en el diseño de la arquitectura, junto con la optimización de costos, la excelencia operativa, la eficiencia del rendimiento y la seguridad. Si ya tiene una carga de trabajo que se ejecuta en Azure y desea valorar en qué medida está en línea con los procedimientos recomendados para una o varias de estas áreas, pruebe Microsoft Azure Well-Architected Review.

En concreto, el pilar de la confiabilidad describe seis pasos para la creación de una aplicación confiable para Azure. Definir los requisitos de disponibilidad y recuperación en función de cada carga de trabajo y necesidad empresarial. Usar procedimientos recomendados para la arquitectura con el fin de identificar posibles puntos de error en la arquitectura propuesta o actual, y determinar cómo responderá la aplicación ante errores. Hacer pruebas con simulaciones y conmutaciones por error forzadas para probar la detección y la recuperación de diversos errores. Implementar la aplicación de forma coherente usando procesos confiables y repetibles. Supervisar el estado de la aplicación para detectar errores, supervisar indicadores de posibles errores y controlar el estado de las aplicaciones. Finalmente, responder a los errores y desastres determinando la mejor forma de solucionarlos en función de las estrategias establecidas.

Volviendo a nuestro tema principal de la comunicación de interrupciones, estamos trabajando para incorporar una guía Well-Architected pertinente a nuestros informes PIR después de cada incidente en un servicio. Los clientes que ejecutan cargas de trabajo críticas podrán obtener información sobre los pasos específicos para mejorar la confiabilidad que habría ayudado a evitar y reducir el impacto de esa interrupción en particular. Por ejemplo, si una interrupción solo ha afectado a los recursos de una sola zona de disponibilidad, la mencionaremos en los informes PIR y recomendaremos a los clientes afectados que consideren el uso de la redundancia de zona para sus cargas de trabajo críticas.

De cara al futuro

Hemos descrito el procedimiento de comunicación de Azure durante y después de los incidentes, como las interrupciones del servicio. Queremos ser transparentes sobre nuestros cinco pilares de la comunicación, para explicar tanto nuestro progreso hasta la fecha como las áreas en las que vamos a seguir invirtiendo. Del mismo modo que nuestros equipos de ingeniería intentan aprender de cada incidente para mejorar la confiabilidad de la plataforma, nuestros equipos de comunicación intentan aprender de cada incidente para ser más transparentes, ofrecer a los clientes y asociados los detalles oportunos para tomar decisiones informadas y ofrecer soporte técnico a los clientes y asociados de la mejor forma posible durante cada una de estas situaciones difíciles.

Estamos seguros de que estamos haciendo las inversiones adecuadas para continuar mejorando en este campo, pero cada vez buscamos más comentarios sobre si nuestras comunicaciones están dando la talla. Al final de cada informe PIR que publicamos, incluimos una encuesta posterior a un incidente en Azure. Nos esforzamos por revisar todas las respuestas para aprender de nuestros clientes y asociados, y comprobar si nos estamos centrando en las áreas correctas y seguir mejorando la experiencia.

Seguimos identificando las imperfecciones inherentes (y, a veces, sutiles) de las formas complejas en las que nuestros diseños arquitectónicos, procesos operativos, problemas de hardware, defectos de software y factores humanos pueden alinearse para causar interrupciones del servicio. Puesto que la confianza se gana y debe mantenerse, nos comprometemos a ser lo más transparentes posible, especialmente durante estos problemas de servicio infrecuentes, pero inevitables.