Gestión de incidentes para equipos de alta velocidad
Análisis a toro pasado de los incidentes
En Atlassian realizamos los análisis a toro pasado irreprochables para asegurarnos de comprender y remediar el origen del problema de cada incidente con una gravedad de nivel 2 o superior. A continuación te mostramos una versión resumida de nuestra documentación interna que describe cómo llevamos a cabo los análisis a toro pasado en Atlassian.
Obtén el manual en versión impresa o PDF
Tenemos un suministro limitado de versiones impresas de nuestro Manual de gestión de incidentes, que enviamos de forma gratuita. También puedes descargar una versión en PDF.
| Campo | Instrucciones | Ejemplo |
| "Incident summary" (Resumen del incidente) | Resume el incidente brevemente. Incluye la gravedad, la razón y la duración del impacto. | Entre las El evento se detectó a través de Este incidente de gravedad Se produjeron |
| "Leadup" (Suceso previo) | Describe las circunstancias que condujeron a esta incidencia, por ejemplo, cambios anteriores que introdujeron errores latentes. | A las |
| "Fault" (Fallo) | Describe qué falló. Adjunta capturas de pantalla de gráficos o datos pertinentes que muestren el fallo. | |
| Consecuencias | Describe qué vieron los clientes internos y externos durante el incidente. Incluye cuántos casos de soporte se produjeron. | Durante Esto afectó a Se produjeron |
| Detección | ¿Cómo y dónde detectó Atlassian el incidente? ¿Cómo se podría mejorar el tiempo de detección? Plantéate cómo habrías reducido el tiempo a la mitad. | El incidente se detectó cuando se activó |
| Respuesta | ¿Quién respondió, cuándo y cómo? ¿Existieron retrasos en nuestra respuesta o impedimentos? | Tras contactar con el ingeniero de KITT a las 14:34 UTC, este se conectó a las 14:38 en la sala de chat del incidente. No obstante, el ingeniero de guardia no tenía suficiente experiencia con el autoescalador Escalator, por lo que se envió una nueva alerta a las 14:50 que condujo a la conexión de un ingeniero de KITT altamente especializado en la sala a las 14:58. |
| Recuperación | Describe cómo y cuándo se restauró el servicio. ¿Cómo alcanzaste el punto en el que sabías cómo mitigar el impacto? Pregunta adicionales, según el escenario: ¿cómo se podría mejorar el tiempo de mitigación? Plantéate cómo habrías reducido el tiempo a la mitad. | La recuperación contó con una respuesta triple:
|
| Cronograma | Presenta un cronograma detallado del incidente en orden cronológico, con la hora y la zona horaria. Incluye cualquier precedente, el comienzo del impacto, la hora en la que se detectó, las derivaciones, las decisiones, los cambios y la finalización del impacto. | Todas las horas están en formato UTC. 11:48 - Actualización K8S 1.9 del panel de control finalizada12:46 - Actualización Goliath a V1.9 completada, incluidos el autoescalador de clúster y la instancia de programador de BuildEng 14:20 - Build Engineering informa de un error en KITT Disturbed 14:27 - KITT Disturbed comienza a investigar los fallos de una instancia determinada de EC2 (ip-203-153-8-204) 14:42 - KITT Disturbed aísla el nodo específico 14:49 - BuildEng informa de que el problema afecta a más de un nodo. 86 instancias del problema muestran que los fallos son más sistémicos 15:00 - KITT Disturbed sugiere cambiar al programador estándar 15:34 - BuildEng informa de que han fallado 300 pods 16:00 - BuildEng elimina todas las compilaciones fallidas con informes de OutOfCpu 16:13 - BuildEng informa de que los fallos siguen ocurriendo en las nuevas compilaciones y que no eran pasajeros. 16:30 - KITT reconoce los fallos como incidente y los ejecuta como tal. 16:36 - KITT deshabilita el autoescalador Escalator con el fin de evitar que este elimine el proceso para disminuir el problema. 16:40 - KITT confirma que ASG es estable, la carga de clúster es normal y el impacto de cliente se ha resuelto. |
| "Five whys" (Cinco porqués) | Usa la técnica de identificación del origen del problema. Comienza con el impacto y pregunta por qué sucedió y por qué tuvo tal impacto. Continúa preguntando por qué hasta que llegues al origen del problema. Documenta tus preguntas como muestra la siguiente lista o en un diagrama adjunto al incidente. |
|
| "Root cause" (Origen del problema) | ¿Cuál fue el origen del problema? Esto es lo que debe cambiar para que esta clase de incidente no se vuelva a producir. | Un error en la gestión del grupo de conexión de |
| "Backlog check" (Comprobación de backlog) | ¿Hay algo en tu backlog que pudo haberlo evitado o haber reducido enormemente su impacto? Si la respuesta es afirmativa, ¿por qué no se llevó a cabo? Una evaluación sincera en este punto ayuda a aclarar decisiones pasadas en cuanto a prioridad y riesgo. | De manera no específica. Las mejoras relativas a los tipos de flujos eran tareas en curso que se estaban llevando a cabo (p. ej., agregar tipos de flujos al cambiar/crear un archivo). Se habían realizado tickets para corregir las pruebas de integración, pero fallaron al intentar implementarlos |
| "Recurrence" (Recurrencia) | ¿Ha ocurrido antes este incidente (con el mismo origen del problema)? Si la respuesta es afirmativa, ¿por qué ha vuelto a ocurrir? | Este mismo origen del problema tuvo como resultado los incidentes HOT-13432, HOT-14932 y HOT-19452. |
| Lecciones aprendidas | ¿Qué hemos aprendido? Comenta qué fue bien, qué pudo haber ido mejor y en qué aspecto tuvisteis suerte para encontrar oportunidades de mejora. |
|
| "Corrective actions" (Acciones correctivas) | ¿Qué vamos a hacer para asegurarnos de que esta clase de incidente no vuelva a suceder? ¿Quién realizará las acciones y en qué momento? Crea vínculos de incidencia "Priority Action" (Acción prioritaria) para incidencias que supervisan cada acción. |
|
| Escenario | Causa inmediata y acción | "Root cause" (Origen del problema) | Mitigación del origen del problema |
| Los servicios del equipo "Red Dawn" (Amanecer rojo) de Stride no tenían establecidas las supervisiones de Datadog y las alertas de guardia para sus servicios, o no las habían configurado correctamente. | Los miembros del equipo no configuraron el sistema de supervisión y alertas para nuevos servicios. Configúralo para estos servicios. | No existe ningún proceso para poner en pie servicios nuevos, lo que incluye la supervisión y las alertas. | Crea un proceso para poner en pie nuevos servicios y enseña a los equipos a seguirlo. |
| Stride no se puede utilizar en IE11 debido a una actualización de "Fabric Editor (Editor de tejido)" que no funciona en esta versión del navegador. | Una actualización de una dependencia. Deshaz la actualización. | No se ha realizado una prueba de compatibilidad entre navegadores. | Automatiza continuas pruebas de compatibilidad entre navegadores. |
| Los registros de Micros EU no llegaban al servicio de registros. | La función asignada a Micros para enviar registros era incorrecta. Corrige la función | No podemos saber cuándo falla el registro de un entorno. | Agrega los sistemas de supervisión y alertas sobre registros ausentes para cualquier entorno. |
| Los nodos de Confluence Vertigo, activados por un incidente de AWS anterior, agotaron su grupo de conexión con Media, lo que resultó en problemas a la hora de adjuntar datos y errores de medios para los clientes. | Fallo de AWS. Obtén el análisis a toro pasado de AWS. | Un error en la gestión del grupo de conexión de Confluence produjo conexiones filtradas en condiciones de fallo, en combinación con la falta visibilidad en el estado de conexión. | Corrige el error y añade el sistema de supervisión que detectará situaciones futuras similares antes de que causen impacto. |
| Categoría | Definición | ¿Qué deberíamos hacer al respecto? |
| Error | Un cambio en el código realizado por Atlassian (este es un tipo de cambio específico) | prueba Valor controlado. Haz implementaciones graduales y obsérvalas. Usa indicadores. Habla con tu ingeniero de calidad. |
| Cambio | Un cambio realizado por Atlassian (que no sea un cambio en el código) | Mejora la manera de introducir los cambios, por ejemplo, tus procesos de gestión de cambios o de revisión de cambios. Toda la información que aparece junto a "error" también se aplica aquí. |
| Escala | Error al ampliar (p. ej., sin visión de restricciones de recursos o falta de planificación de capacidad) | What are your service's resource constraints? Are they monitored and alerted? If you don't have a capacity plan, make one. If you do have one, what new constraint do you need to factor in? |
| Arquitectura | Mala organización de diseño con condiciones operativas | Revisa tu diseño. ¿Necesitas cambiar de plataforma? |
| Dependencia | Fallo de servicio de terceros (no de Atlassian) | ¿Estás gestionando el riesgo del fallo de terceros? ¿Hemos tomado la decisión empresarial de aceptar un riesgo o necesitamos crear reducciones? Consulta la sección "Orígenes del problema con dependencias" que aparece a continuación. |
| Desconocido | No se puede determinar (la acción es aumentar la capacidad de diagnóstico) | Mejora la capacidad de observación de tu sistema agregando funciones de registro, supervisión, depuración de errores y similares. |
| Categoría | Preguntas que se deben plantear | Ejemplos |
| Investigar este incidente | "¿Qué ha pasado para que se produjese este incidente y por qué se ha producido?" Determinar los orígenes del problema es tu objetivo final. | Análisis de registros, diagramar la ruta de solicitud, revisar los volcados de memoria |
| Mitigar este incidente | "¿Qué acciones inmediatas realizamos para resolver y gestionar este evento específico?" | Revertir cambios, realizar practicas selectivas, insertar configuraciones, comunicarse con los usuarios afectados |
| Reparar el daño de este incidente | "¿Cómo resolvemos el daño inmediato o colateral de este incidente?" | Restablecer datos, corregir máquinas, eliminar la desviaciones de tráfico |
| Detectar incidentes futuros | "¿Cómo podemos disminuir el tiempo empleado para detectar con precisión un fallo similar?" | Supervisar, alertar, realizar comprobaciones de plausibilidad en entradas/salidas |
| Mitigar futuros incidentes | "¿Cómo podemos disminuir la gravedad o la duración de futuros incidentes como este?" "¿Cómo podemos reducir el porcentaje de usuarios a los que afecta esta clase de fallo la próxima vez que se produzca?" | Aplicar degradaciones ligeras, eliminar resultados no esenciales, generar errores de apertura, aumentar prácticas actuales con paneles o manuales de estrategias, aplicar cambios de proceso de incidentes |
| Evitar incidentes futuros | "¿Cómo podemos evitar una recurrencia de este tipo de fallo?" | Aplicar mejoras de estabilidad en la base de código, realizar pruebas de unidad más exhaustivas, llevar a cabo la validación de las entradas y comprobar la resistencia ante condiciones de errores, aprovisionar cambios |
Asimismo, utilizamos el consejo de Lueder y Beyer sobre cómo formular nuestras acciones de análisis a toro pasado.
Formulación de las acciones de análisis a toro pasado:
La manera correcta de formular una acción de análisis a toro pasado puede marcar la diferencia entre una ejecución sencilla y el retraso indefinido debido a la inviabilidad o a la procrastinación. Una acción de análisis a toro pasado bien elaborada debe tener las siguientes propiedades:
Práctica: expresa cada acción en forma de frase que comience por un verbo. La acción debe traducirse en un resultado útil, no en un proceso. Por ejemplo, "Enumera la lista de dependencias críticas" es una buena acción, mientras que "Investiga las dependencias" no lo es.
Específica: define el alcance de cada acción de la forma más precisa posible, dejando claro qué se incluye en el trabajo.
Delimitada: formula cada acción de manera que se pueda indicar cuándo se ha finalizado, en oposición a dejar la acción en curso o sin fin definido.
| De... | A... |
| Investiga la supervisión de este escenario. | (Práctica). Agrega el sistema de alertas para todos los casos en los que este servicio devuelva >1 % errores. |
| Corrige el problema que causó la interrupción. | (Específica). Gestiona el código postal inválido de la entrada del formulario de dirección del usuario de forma segura. |
| Asegúrate de que el ingeniero comprueba que el esquema de la base de datos puede analizarse antes de aplicar la actualización. | (Delimitada). Agrega una comprobación automatizada previa al envío para los cambios aplicados al esquema. |
Configuración de un horario de guardias con Opsgenie
En este tutorial aprenderás a configurar un horario de guardias, aplicar reglas de anulación, configurar notificaciones de guardias y mucho más, todo dentro de Opsgenie.
Leer el tutorialDescubre la comunicación de incidentes con Statuspage
En este tutorial, te mostraremos cómo utilizar plantillas de incidentes para comunicarte eficazmente durante las interrupciones. Puedes aplicarlo a muchos tipos de interrupciones del servicio.
Leer el tutorial