Corrección

Completado

La división en cinco fases del ciclo de vida de la respuesta ante incidentes que puede verse en este módulo ayuda a comprender el proceso, pero las fases no siempre están tan diferenciadas como se muestra en el diagrama. En concreto, la línea que separa las fases de respuesta y corrección a veces se vuelve borrosa. Esto es especialmente cierto cuando las acciones destinadas a mitigar o mejorar la situación tienen el efecto contrario. En este caso, la respuesta y la corrección tienden a superponerse o a alternarse.

Cycle diagram of circles labeled with incident responses phases. Circles are connected to next circle with arrows from phase to phase. Detections, Response, and Remediation are highlighted.

En esta unidad, obtendrá más información sobre la corrección y los pasos que componen esta fase, y descubrirá algunas sugerencias y herramientas útiles. Una cuestión importante que debe tener en cuenta: no debe tomar las medidas que se describen aquí como una lista de comprobación prescriptiva.

Si ya tiene disponible una lista de comprobación para la corrección, esto suele ser un indicador de que ha llegado el momento de incorporar automatización. En el momento en que sea capaz de describir exactamente lo que se debe hacer y en qué orden se corregirá un problema, estará listo para enseñarle estos pasos a una máquina para que el sistema lo haga automáticamente.

Por dónde empezar

Ya ha aprendido la importancia que tiene reducir el tiempo que se tarda en responder a un incidente. Veamos ahora algunas cosas que pueden ayudar a acelerar el proceso de corregir o solucionar un problema.

Es probable que los miembros del equipo tengan diferentes modelos mentales de cómo funcionan las cosas e ideas dispares sobre cuál debe ser el primer paso. Uno de ellos podría examinar primero los registros, mientras que otro podría ejecutar primero las consultas y, después, examinar las métricas. No hay un único camino correcto hacia el éxito.

Aun así, resulta de ayuda proporcionar contexto y orientación a los miembros del equipo para que sepan adónde ir y en qué fijarse.

Cómo y a quién se debe escalar

Una pregunta importante a la hora de formular el punto de partida de la corrección es la siguiente: si se bloquea, ¿a quién se puede llamar para escalar el problema? Debe intentar delegar más las responsabilidades de las personas de guardia al equipo en general, no solo a las operaciones o a la ingeniería de confiabilidad de sitios. Debe ser responsabilidad de todos los miembros del equipo conseguir que los sistemas funcionen bien para cumplir los objetivos de confiabilidad.

¿Qué recursos son útiles para los primeros respondedores?

La siguiente consideración consiste en determinar los elementos que los primeros respondedores pueden usar para empezar a trabajar en el proceso. Esto podría incluir métricas pertinentes, registros, consultas, etc. Si es posible, se deben proporcionar en una guía de solución de problemas o un libro de Azure, si es posible. Hablaremos de ellos en un momento.

También resulta útil proporcionar vínculos sencillos a los recursos (a menudo, en una guía de solución de problemas). En caso de que su objetivo sea responder al problema y corregirlo lo antes posible, acelerará el proceso si ayuda a los usuarios a encontrar una respuesta a las preguntas sin necesidad de buscar el documento o la dirección URL correctos.

Puesta al día de las partes interesadas

Tal vez se centre tanto en solucionar el problema que llegue a olvidarse de que hay muchas personas que no participan directamente en la respuesta ante el incidente, pero que quieren saber lo que sucede.

Es importante comunicarse con otros equipos internos y mantenerlos informados de lo que ocurre cuando se produce un incidente. Si no los pone al corriente de forma sistemática, es probable que se pongan en contacto con usted para que les mantenga al tanto del estado. Tienen derecho a esta información, pero necesita una mejor manera de comunicarles el problema y las medidas que se han tomado.

Debe ser claro al comunicarse con los equipos internos. Exponga claramente lo que sabe y lo que se está haciendo e indique cuándo volverán a tener noticias suyas.

La fórmula para comunicarse con las partes interesadas es sencilla:

  • Esto es lo que sabemos.
  • Esto es lo que estamos haciendo.
  • Nos pondremos en contacto con usted dentro de un plazo de tiempo X.

Esto le ayudará a evitar que las partes interesadas se pongan en contacto con usted y le interrumpan cuando esté intentando solucionar los problemas.

Una manera de distribuir esta información consiste en usar una página web de estado fácilmente editable, como la que mencionamos en la última unidad. En muchos casos, es posible que le interese tener una página de estado independiente más detallada para las partes interesadas internas y otra externa para los clientes. La fórmula anterior funciona para ambos casos.

Uso de los libros de Azure Monitor y las guías de solución de problemas

Azure tiene dos características estrechamente relacionadas que pueden ser muy útiles para un equipo en la fase de corrección: libros de Azure Monitor y guías de solución de problemas de Application Insights. Para este módulo, son intercambiables y, además, tienen la misma interfaz de usuario. Puede encontrar Workbooks de Azure Monitor en Azure Portal en Azure Monitor. Encontrará guías de solución de problemas de Azure Insights en Azure Portal cuando se haya seleccionado una instancia de Applications Insight.

Los libros y guías de solución de problemas son "documentos dinámicos" que puede crear con una interfaz de creación de páginas. Al crear uno, puede agregar a la página:

  • Texto arbitrario, como una lista con viñetas de elementos pendientes u otra información útil para quienes consulten la página
  • Vínculos a otros sistemas, por ejemplo, a otros paneles o documentación
  • Consultas de lenguaje de consulta de Kusto (KQL)

Es este último elemento el que hace que el documento sea "activo". En un módulo anterior de esta ruta de aprendizaje, analizamos el lenguaje de consulta de KQL integrado en Log Analytics y otras partes de Azure Monitor. Con este lenguaje, podríamos escribir nuestras propias consultas para devolver y mostrar información de diagnóstico de la aplicación y de la infraestructura de Azure. Cuando se inserta una consulta KQL en un libro o una guía de solución de problemas, los resultados actuales de esa consulta se muestran en directo a los lectores del documento. Esto significa que la guía de solución de problemas puede indicar no solo "Asegúrese de comprobar la tasa de errores del servidor web", sino mostrar también un gráfico actual para esa tasa de errores junto a las instrucciones. Puede incluir un vínculo como "esta es la documentación de reinicio del servidor web" que lleva al primer respondedor a la documentación que necesita.

Azure también proporciona algunas plantillas que le ayudarán a empezar a crear sus propios documentos. Aquí se muestra una captura de pantalla con algunas de las plantillas predefinidas que encontrará:

Screenshot of default example troubleshooting guides as found in the Azure portal.

Hay una característica de editor avanzado para Workbooks y las guías de solución de problemas que le permiten acceder a e insertar un JSON o una representación de plantilla de Azure Resource Manager de ese documento. Esto significa que es posible realizar un seguimiento y distribuir estos documentos mediante el sistema de control de código fuente de su elección. También permite automatizar el aprovisionamiento de libros o guías de solución de problemas, lo que resulta útil para cuando se aprovisiona otra infraestructura. Con este procedimiento recomendado, resulta más fácil crear un conjunto de documentos de solución de problemas personalizados para incluirlos con un nuevo servicio en el momento en que este se aprovisione.

Otras sugerencias y herramientas útiles

En este módulo, ha descubierto las diversas herramientas y fórmulas que puede usar para aumentar la eficacia y reducir el tiempo de respuesta ante incidentes. Para cerrar esta última unidad, presentaremos brevemente algunas herramientas y técnicas útiles para diagnosticar problemas en los sistemas.

  • Puede usar el vínculo Panel de la aplicación de Application Insights para generar automáticamente un panel que tenga la mayoría de los elementos clave que se necesitarán como punto de partida. Tenga en cuenta que no incluye Azure Service Health. Es recomendable anclarlo al panel para poder comprobar si el problema está relacionado con los sistemas o con el propio servicio en la nube.
  • Puede usar el mapa de aplicación de Application Insights para explorar en detalle lo que está causando los problemas. Puede seguir las rutas de navegación para encontrar la causa del error (por ejemplo, una dirección URL con formato incorrecto).
  • Puede usar Log Analytics para consultar cualquier parte del sistema.

Todas las herramientas anteriores son valiosas para solucionar problemas.

Comprobación de conocimientos

1.

Cuando se comunica con las partes interesadas, ¿cuál de estos elementos no es necesario en la fórmula sugerida?

2.

¿Por qué los libros y las guías de solución de problemas se consideran documentos activos en nuestra descripción?