Uso del análisis de los 5 porqués en los informes de incidentes - Amazon CloudWatch
¿Qué es el análisis de los 5 porqués?Beneficios de los informes de incidentesEjemplos de escenarios de informes de incidentesUso del flujo de trabajo guiado de los 5 porquésGestión de incidentes complejos con múltiples causasPrácticas recomendadas para un análisis efectivo de los 5 porqués

Uso del análisis de los 5 porqués en los informes de incidentes

Al generar informes de incidentes, Investigaciones de CloudWatch pueden llevar a cabo un análisis de la causa raíz de los 5 porqués para identificar sistemáticamente las causas subyacentes de los problemas operativos. Este enfoque estructurado mejora los informes de incidentes con información más profunda y pasos de corrección prácticas.

Esta característica utiliza Amazon Q para ofrecer un chat conversacional. El usuario que inició sesión en la Consola de administración de AWS debe tener permisos para llevar a cabo lo siguiente:

{ 
    "Sid" : "AmazonQAccess",
    "Effect" : "Allow",
    "Action" : [
       "q:StartConversation", 
       "q:SendMessage", 
       "q:GetConversation", 
       "q:ListConversations", 
       "q:UpdateConversation", 
       "q:DeleteConversation", 
       "q:PassRequest" 
     ],
    "Resource" : "*"
 }

Puede agregar estos permisos directamente o al adjuntar la política administrada AIOpsConsoleAdminPolicy o AIOpsOperatorAccess al usuario o al rol.

¿Qué es el análisis de los 5 porqués?

Los 5 porqués son una técnica de análisis de causa raíz que se pregunta “por qué” repetidamente para desglosar desde los síntomas de los incidentes hasta las causas fundamentales. Cada respuesta se convierte en la base de la siguiente pregunta, lo que crea una cadena lógica que revela la verdadera causa raíz y no solo los síntomas superficiales.

Durante la generación de informes de incidentes, Investigaciones de CloudWatch utiliza este método para analizar los resultados de las investigaciones y proporcionar un análisis estructurado de la causa raíz que va más allá de los fallos técnicos inmediatos para identificar problemas de proceso, de configuración o sistémicos.

Beneficios de los informes de incidentes

Incluir el análisis de los 5 porqués en los informes de incidentes ofrece varias ventajas:

  • Identificación exhaustiva de la causa raíz: va más allá de las causas técnicas inmediatas para identificar los problemas subyacentes del proceso o del sistema.

  • Planes de corrección prácticos: proporciona acciones específicas y específicas para evitar que se repitan, en lugar de soluciones temporales.

  • Aprendizaje organizativo: documenta la cadena causal completa para futuras referencias e intercambio de conocimientos en equipo.

  • Análisis estructurado: garantiza la investigación sistemática en lugar de la resolución de problemas ad hoc.

Ejemplos de escenarios de informes de incidentes

Incidente de fallo de conexión de la base de datos

Incidente inicial: la aplicación de comercio electrónico sufrió errores 500 generalizados

  1. Porqué 1: ¿por qué los usuarios reciben errores 500? La aplicación no se puede conectar a la base de datos principal.

  2. Porqué 2: ¿por qué la aplicación no puede conectarse a la base de datos? La instancia de base de datos se quedó sin conexiones disponibles.

  3. Porqué 3: ¿por qué la base de datos se quedó sin conexiones? Un trabajo de procesamiento por lotes abrió muchas conexiones sin cerrarlas correctamente.

  4. Porqué 4: ¿por qué el trabajo por lotes no cerró las conexiones correctamente? La gestión de errores del trabajo no incluye la limpieza de la conexión en caso de fallo.

  5. Porqué 5: ¿por qué no se implementó una gestión de errores adecuada? El proceso de revisión del código no incluye comprobaciones específicas de los patrones de administración de recursos.

Causa raíz: estándares de revisión de código inadecuados para la administración de recursos

Acciones recomendadas: actualización de la lista de verificación de la revisión de código, implementación de la supervisión del grupo de conexiones y adición de una detección automática de fugas de recursos

Incidente de degradación del rendimiento

Incidente inicial: los tiempos de respuesta de la API aumentaron de 200 a 5000 ms durante un pico de tráfico

  1. Porqué 1: ¿por qué aumentaron los tiempos de respuesta? El uso de la CPU alcanzó el 100 % en todas las instancias de la aplicación.

  2. Porqué 2: ¿por qué el escalado automático no agregó más instancias? Se activó el escalado automático, pero las instancias nuevas no superaron las comprobaciones de estado.

  3. Porqué 3: ¿por qué las nuevas instancias no superaron las comprobaciones de estado? El proceso de arranque de la aplicación tarda 8 minutos, más que el tiempo de espera de la comprobación de estado.

  4. Porqué 4: ¿por qué tarda tanto el arranque? La aplicación descarga archivos de configuración de gran tamaño de S3 cada vez que se arranca.

  5. Porqué 5: ¿por qué no se consideró este retraso del arranque en la configuración de escalado automático? Las pruebas de rendimiento se hicieron con instancias precalentadas, no con arranques en frío.

Causa principal: la metodología de pruebas de rendimiento no refleja los escenarios de escalado automático de producción

Acciones recomendadas: inclusión de pruebas de arranque en frío, optimización del inicio de las aplicaciones, ajuste de los tiempos de espera de las comprobaciones de estado e implementación del almacenamiento en caché de la configuración

Incidente complejo con análisis de ramificaciones

Incidente inicial: los clientes de OpenSearch sin servidor experimentaron una disminución de la disponibilidad del 48,3 % durante 11 horas

Cadena de análisis principal:

  1. Porqué 1: ¿por qué los clientes experimentaron una degradación del servicio? La disponibilidad del servicio se redujo al 48,3 % debido a un escalado incorrecto de ingesta.

  2. Porqué 2: ¿por qué el escalado de ingesta era incorrecto? CortexOperator redujo la ingesta de 223 a 174 por un error de cálculo del equilibrio de AZ.

  3. Porqué 3: ¿por qué se produjo el error de cálculo del equilibrio de AZ de CortexOperator? El código no pudo procesar los nuevos formatos de etiquetas de Kubernetes tras la actualización a la versión 1.17.

  4. Porqué 4 (ramificación A, técnica): ¿por qué el código no gestionó los nuevos formatos de etiquetas? El código esperaba las etiquetas “failure-domain.beta.kubernetes.io/zone”, pero Kubernetes 1.17 cambió a “topology.kubernetes.io/zone”.

  5. Porqué 5 (ramificación A): ¿por qué no se implementó la compatibilidad con versiones anteriores? El cambio de formato de la etiqueta no estaba documentado en las notas de la actualización revisadas durante la planificación de la implementación.

Ramificación B: análisis de procesos:

  1. Porqué 4 (ramificación B: proceso): ¿por qué no se detectó esto en las pruebas? Las pruebas de integración utilizaron clústeres preconfigurados con formatos de etiquetas antiguos.

  2. Porqué 5 (ramificación B): ¿por qué las pruebas no incluyeron la validación del formato de las etiquetas? La configuración del entorno de prueba no reflejaba la secuencia de actualización de la versión de producción de Kubernetes.

Causas raíz identificadas:

  • Técnica: falta compatibilidad con versiones anteriores para los cambios de formatos de etiquetas de Kubernetes.

  • Proceso: la metodología de prueba no valida el impacto de la actualización de la versión.

Plan de corrección integrado: implementación de una lógica de detección de formatos de etiquetas, mejora de los procedimientos de pruebas de actualización, adición de una validación automática de la compatibilidad y establecimiento de un proceso de evaluación del impacto de los cambios de versión

Uso del flujo de trabajo guiado de los 5 porqués

Investigaciones de CloudWatch proporciona un flujo de trabajo de análisis guiado de los 5 porqués para poder abordar los hechos faltantes y reforzar los informes de incidentes. Esta característica aparece como un flujo de trabajo sugerido cuando el sistema identifica oportunidades para mejorar el análisis de la causa raíz.

Experiencia interactiva de análisis

El análisis de los 5 porqués de Investigaciones de CloudWatch utiliza un enfoque interactivo basado en el chat que lo guía a lo largo del proceso de investigación. Este método conversacional ayuda a garantizar un análisis exhaustivo y, al mismo tiempo, mantener un flujo lógico entre las preguntas.

Características clave de la experiencia interactiva:

  • Inicialización basada en hechos: el sistema presenta los hechos pertinentes de la investigación por adelantado, los utiliza para rellenar previamente respuestas obvias e indica claramente las sugerencias basadas en hechos frente a las basadas en inferencias.

  • Sondeo guiado: para cada pregunta sobre el “porqué”, el sistema sugiere respuestas en función de los datos disponibles, solicita un contexto adicional específico y lo guía para que considere aspectos importantes antes de continuar.

  • Administración de ramificaciones: cuando se identifican varios factores que contribuyen, el sistema presenta claramente las opciones de las ramificaciones, explica las relaciones entre ellas y ayuda a priorizar las investigaciones paralelas.

  • Validación progresiva: para cada respuesta, el sistema reformula las respuestas para mayor claridad, busca confirmación, destaca la información clave y relaciona los resultados con un contexto más amplio.

Este enfoque garantiza que se recopile toda la información pertinente y, al mismo tiempo, centrarse en las relaciones causales más importantes.

Acceso al flujo de trabajo guiado:

  1. Durante la generación del informe de incidentes, revise la sección Hechos que requieren atención en el panel derecho.

  2. Busque la sugerencia Análisis guiado de los 5 porqués en Flujo de trabajo sugerido.

  3. Elija Guíeme para iniciar el proceso interactivo de los 5 porqués.

  4. Siga las instrucciones de la guía para analizar de forma sistemática cada pregunta sobre el “porqué”, lo que creará una cadena de causas completa, desde los síntomas hasta la causa raíz.

El flujo de trabajo guiado ayuda a garantizar que se recopile información completa sobre las causas raíz, ya que muestra cada paso de la metodología de los 5 porqués. Los resultados del análisis se incorporan automáticamente al informe de incidentes, lo que proporciona una documentación estructurada para las revisiones posteriores al incidente y el aprendizaje organizativo.

También puede solicitar un análisis de los 5 porqués a través de la interfaz de chat mediante preguntas como “Haga un análisis de los 5 porqués de este incidente” o “¿Cuál es la causa raíz según la metodología de los 5 porqués?”.

Gestión de incidentes complejos con múltiples causas

Algunos incidentes implican varios factores contribuyentes que requieren rutas de análisis paralelas. Investigaciones de CloudWatch permite el análisis de ramificaciones para garantizar que se identifiquen y aborden todas las causas importantes.

Cuando es necesario analizar las ramificaciones:

  • Se produjeron varios fallos independientes simultáneamente.

  • Los diferentes componentes del sistema contribuyeron al mismo impacto en los clientes.

  • Tanto los fallos técnicos como los de proceso desempeñaron un papel importante.

  • Los fallos en cascada crearon múltiples cadenas causales.

Proceso de análisis de ramificaciones:

  1. Identificación de ramificaciones: el sistema identifica los puntos en los que convergen o divergen múltiples causas.

  2. Investigación paralela: cada ramificación se analiza según la metodología completa de los 5 porqués.

  3. Asignación de conexiones: las relaciones entre las ramificaciones se documentan para mostrar cómo interactúan.

  4. Resolución integrada: los planes de corrección abordan todas las causas raíz identificadas y sus interacciones.

Este enfoque integral garantiza que los incidentes complejos sean objeto de un análisis exhaustivo y que todos los factores contribuyente se aborden en el plan de corrección final.

Prácticas recomendadas para un análisis efectivo de los 5 porqués

Para maximizar la eficacia del análisis de los 5 porqués en los informes de incidentes, siga estas prácticas recomendadas derivadas de la experiencia operativa:

Directrices de formulación de preguntas

  • Comience con el impacto en el cliente: comience cada análisis con el problema al que se enfrenta el cliente para centrarse en el impacto empresarial.

  • Aumente la profundidad técnica progresivamente: pase del impacto empresarial a los detalles técnicos a medida que vaya resolviendo las preguntas.

  • Mantenga la continuidad lógica: asegúrese de que cada respuesta lleve naturalmente a la siguiente pregunta sin deficiencias lógicas.

  • Incluya pruebas de respaldo: consulte métricas, registros o eventos cronológicos específicos para validar cada respuesta.

Validación de análisis

Valide el análisis de los 5 porqués según estos criterios:

  • Flujo lógico: progresión clara desde los síntomas hasta la causa raíz sin omitir ningún paso

  • Precisión técnica: terminología correcta, descripciones precisas del comportamiento del sistema e interacciones válidas entre los componentes

  • Exhaustividad: análisis que explica todos los síntomas observados y determina una causa fundamental que, si se aborda, evitaría la periodicidad

  • Capacidad de acción: causa raíz identificada que lleva a acciones correctivas específicas e implementables

Errores comunes que se deben evitar

  • Concentración en los síntomas: no concluya el análisis ante el primer fallo técnico; continúe hasta llegar a las causas sistémicas o del proceso.

  • Análisis centrado en la culpa: céntrese en los fallos del sistema y los procesos en lugar de las acciones individuales.

  • Pensamiento unidireccional: tenga en cuenta los distintos factores contribuyente y utilice el análisis de ramificaciones cuando sea apropiado.

  • Pruebas insuficientes: asegúrese de que cada respuesta esté respaldada por datos concretos de la investigación.

Integración con las secciones de informes de incidentes

El análisis de los 5 porqués se integra con otras secciones del informe de incidentes para proporcionar una documentación completa:

  • Correlación cronológica: cada pregunta sobre el “porqué” puede hacer referencia a eventos cronológicos específicos, lo que proporciona un contexto temporal para las relaciones causales.

  • Validación de métricas: las respuestas están respaldadas por métricas y gráficos que demuestran los comportamientos técnicos descritos.

  • Alineación de la evaluación del impacto: el primer “porqué” se relaciona directamente con las métricas de impacto sobre los clientes documentadas en la sección de evaluación del impacto.

  • Base de las lecciones aprendidas: las causas raíz identificadas mediante el análisis de los 5 porqués informan directamente de las lecciones aprendidas y las secciones de acciones correctivas

Esta integración garantiza la coherencia en todo el informe de incidentes y proporciona a las partes interesadas una descripción completa y coherente, desde los síntomas iniciales hasta la causa raíz y los planes de corrección.