Close

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.

Manual de gestión de incidentes

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.


¿Qué es un análisis retrospectivo?

Un análisis a toro pasado es un registro escrito de un incidente que describe:

  • El impacto de un incidente.
  • Las acciones realizadas para mitigar o resolver el incidente.
  • El origen del problema del incidente.
  • Las acciones de seguimiento realizadas para evitar que el incidente se vuelva a repetir.

En Atlassian, supervisamos de todos los análisis a toro pasado con incidencias de Jira para garantizar que se completan y aprueban. Si tus necesidades son menos complejas, puedes optar por un sistema más sencillo, como una página de Confluence, para cada análisis a toro pasado.


¿Qué hacemos en los análisis a toro pasado?

Los objetivos de un análisis a toro pasado son comprender los orígenes que han contribuido a causar el problema, documentar el incidente para futuras referencias y el descubrimiento de patrones y realizar acciones preventivas efectivas para reducir la probabilidad o el impacto de la recurrencia.

Para que los análisis retrospectivos sean efectivos a la hora de reducir incidencias repetidas, el proceso de revisión debe fomentar que los equipos identifiquen los orígenes del problema y los solucionen. El método exacto depende de la política corporativa de tu equipo; en Atlassian, hemos encontrado una combinación de métodos que funciona con nuestros equipos de respuesta ante incidentes:

  • Las reuniones presenciales ayudan a llevar a cabo análisis adecuados y a sincronizar al equipo con respecto a qué necesita solución.
  • Las aprobaciones de los análisis a toro pasado de los gestores de los equipos de entregas y operaciones fomentan a los equipos a llevarlos a cabo de forma minuciosa.
  • Las "acciones prioritarias" designadas tienen un objetivo de nivel de servicio (SLO) de unas 4 u 8 semanas de duración, según el servicio, con recordatorios e informes para garantizar que se lleven a cabo.

Participar en este proceso y asegurarse de que sea efectivo requiere un compromiso a todos los niveles de la organización. Nuestros gestores y directores de ingeniería optaron por aprobadores y SLO para la resolución de acciones en sus áreas. Este sistema solo codifica e intenta aplicar sus decisiones.


¿Cuándo es necesario un análisis a toro pasado?

Llevamos a cabo análisis a toro pasado con incidentes de gravedad 1 y 2. De lo contrario, son opcionales.

Durante la resolución de la incidencia o justo después, el propietario del análisis a toro pasado crea una nueva incidencia de análisis a toro pasado.


¿Quién lleva a cabo un análisis a toro pasado?

El equipo de entregas del servicio que ha fallado (el equipo que posee el "Faulty Service" [Servicio defectuoso] en la incidencia) es el responsable de llevar a cabo el análisis a toro pasado. Este equipo selecciona al propietario del análisis a toro pasado y asigna la incidencia de análisis a toro pasado.

  • El propietario del análisis retrospectivo gestiona dicho análisis desde la redacción y la aprobación hasta que se publica. Es responsable de llevar a cabo el análisis retrospectivo.
  • Los aprobadores de análisis a toro pasado son los encargados de revisar y aprobar estos análisis, y se espera que prioricen las acciones de seguimiento en su backlog.

Tenemos una página de Confluence que enumera a los aprobadores de análisis a toro pasado (opcionales y obligatorios) por grupo de servicio, que normalmente se corresponden con un producto de Atlassian (p. ej., Bitbucket Cloud).


¿Cómo se supervisan de las acciones de análisis a toro pasado?

Por cada acción que deriva de un análisis a toro pasado:

  • Emitimos una incidencia de Jira en el backlog del equipo que la posea. Todas las acciones de análisis a toro pasado deben supervisarse en Jira.
  • Las vinculamos desde la incidencia del análisis a toro pasado como "Priority Action" (Acción prioritaria) (para correcciones de origen del problema) o "Improvement Action" (Acción de mejora) (para mejoras no relacionadas con el origen del problema).

Creamos informes personalizados con las API de Jira REST para supervisar el número de incidentes por cada nivel de gravedad cuyo origen del problema se ha solucionado mediante las acciones prioritarias del análisis a toro pasado. Los gestores de ingeniería de cada departamento revisan esta lista con regularidad.


Proceso del análisis a toro pasado

Llevar a cabo el proceso de análisis a toro pasado incluye crear una incidencia de análisis a toro pasado, convocar una reunión de análisis a toro pasado, capturar acciones, conseguir la aprobación y (de manera opcional) comunicar el resultado.

El propietario del análisis a toro pasado es responsable de llevar a cabo las siguientes tareas:

  1. Crear un análisis a toro pasado y vincularlo con el incidente.
  2. Editar la incidencia de análisis a toro pasado, leer las descripciones de los campos y completar los campos.
  3. Para determinar el origen del problema del incidente, utilizar la técnica de los "cinco porqués" con el fin de atravesar la cadena de causalidad hasta encontrar el origen verdadero y real del problema.
  4. Programar la reunión de análisis a toro pasado. Invitar al equipo de entregas, a los equipos afectados y a las partes interesadas, mediante la plantilla de invitación a reuniones.
  5. Reunirse con el equipo y revisar la programación de la reunión que se incluye más adelante.
  6. Realizar un seguimiento con el responsable de los gestores de desarrollo para obtener el compromiso de realizar acciones específicas que evitarán esta clase de incidente.
  7. Crear una incidencia de Jira para las acciones de los backlogs de los equipos que las poseen. Vincularlas desde la incidencia del análisis a toro pasado como "Priority Action" (Acción prioritaria) (para correcciones de origen del problema) o "Improvement Action" (Acción de mejora) (para otras mejoras).
  8. Buscar los aprobadores adecuados en Confluence y añadirlos al campo "Approvers" (Aprobadores) del análisis retrospectivo.
  9. Seleccionar la transición "Request Approval" (Solicitar aprobación) para solicitar la aprobación a los aprobadores designados. La automatización realizará comentarios sobre la incidencia que incluyan instrucciones para los aprobadores.
  10. Realizar el seguimiento necesario hasta que se apruebe el análisis a toro pasado.
  11. Cuando se aprueba el análisis a toro pasado, la automatización crea un blog de análisis a toro pasado de borrador en Confluence para editarlo y publicarlo. Mediante la creación de blogs de análisis a toro pasado se comparten las lecciones aprendidas con esfuerzo, lo que multiplica su valor.

Una vez terminado el proceso de análisis a toro pasado, el equipo de desarrollo prioriza las acciones como parte de su backlog habitual, según el SLO del equipo.


Reuniones de análisis a toro pasado

Hemos descubierto que reunir al equipo para tratar lo aprendido de manera conjunta se consigue un análisis más profundo de los orígenes del problema. A menudo se lleva a cabo mediante videoconferencia debido a la dispersión de nuestros equipos y, a veces, se realiza en grupos en casos en los que los incidentes afectan a grandes grupos de personas.

Agenda recomendada:

  1. Recuerda al equipo que los análisis a toro pasado son irreprochables y por qué lo son
  2. Confirma el cronograma de los eventos
  3. Confirma el origen del problema
  4. Genera acciones con "creatividad": "¿Qué podríamos hacer para evitar que esta clase de incidente se produzca en el futuro?"
  5. Pregunta al equipo qué fue bien, qué pudo haber ido mejor y en qué aspecto tuvisteis suerte.

Plantilla de reserva de calendario sugerida:

Te invito a unirte a mí en un análisis a toro pasado irreprochable sobre , en la que .

Los objetivos de un análisis a toro pasado son comprender los orígenes que han contribuido a causar el problema, documentar el incidente para futuras referencias y el descubrimiento de patrones y realizar acciones preventivas efectivas para reducir la probabilidad o el impacto de la recurrencia.

Durante esta reunión, determinaremos el origen del problema y decidiremos qué acciones realizar para mitigarlo.

Si los gestores de desarrollo responsables no están presentes, evita comprometerte a realizar acciones específicas en la reunión, puesto que es un contexto insuficiente para tomar decisiones de priorización. Las personas se sentirán presionadas a comprometerse y no tendrán en su mano toda la información. En cambio, consulta con los gestores responsables después de la reunión para obtener el compromiso de determinar las acciones prioritarias identificadas.


Campos de incidencia del análisis retrospectivo

Nuestra incidencia de análisis a toro pasado posee una gran variedad de campos para favorecer la recopilación de toda la información importante relativa al incidente antes de celebrar la reunión de análisis a toro pasado. A continuación incluimos algunos ejemplos sobre cómo completar estos campos.

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 , clientes experimentaron . El evento se activó después de la implementación que tuvo lugar a las . La implementación contenía un cambio de código para . El error en este implementación causó .

El evento se detectó a través de . Mitigamos los efectos del evento mediante .

Este incidente de gravedad afectó a un X % de los clientes.

Se produjeron en relación con este incidente.

"Leadup" (Suceso previo)

Describe las circunstancias que condujeron a esta incidencia, por ejemplo, cambios anteriores que introdujeron errores latentes.

A las del , (), se introdujo un cambio en para . El cambió causó .

"Fault" (Fallo)

Describe qué falló. Adjunta capturas de pantalla de gráficos o datos pertinentes que muestren el fallo.

respuestas se enviaron de manera incorrecta al X % de las solicitudes durante .

Impacto

Describe qué vieron los clientes internos y externos durante el incidente. Incluye cuántos casos de soporte se produjeron.

Durante entre las del , se experimentó .

Esto afectó a clientes (X % de todos los clientes de ), que experimentaron .

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ó y se contactó con. Estos a su vez tuvieron que contactar con puesto que no eran propietarios del servicio que escribe en el disco, lo que retrasó la respuesta.

establecerá para que .

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:

  • Ampliar el tamaño de BuildEng EC2 ASG con el fin de aumentar el número de nodos disponibles para asistir en la carga de trabajo y reducir la probabilidad de programar sobre nodos con suscripción excesiva

  • Deshabilitar el autoescalador Escalator para evitar que los clúster se reduzcan de manera agresiva

  • Deshacer el programador de Build Engineering a la versión anterior.

"Timeline" (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 finalizada
12: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.

  1. El servicio se interrumpió porque la base de datos estaba bloqueada

  2. Porque había demasiadas escrituras de bases de datos

  3. Porque se hizo un cambio en el servicio y no se esperara el aumento

  4. Porque no tenemos establecido un proceso de desarrollo establecido para cuando debamos cargar cambios de prueba

  5. Nunca hemos hecho pruebas de carga y están alcanzando nuevos niveles de ampliación

"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 produjo conexiones filtradas en condiciones de fallo, en combinación con la falta visibilidad en el estado de conexión.

"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.

"Lessons learned" (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.

  1. Es necesario realizar una prueba de unidad para verificar que el limitador de velocidad del trabajo cuenta con un mantenimiento adecuado

  2. Se deben revisar las cargas de trabajo de operaciones en masa que no son comunes en el funcionamiento habitual

  3. Las operaciones en masa deben iniciarse poco a poco, supervisarse y aumentar cuando las métricas de servicio sean nominales

"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.

  1. Establecimiento de un límite de velocidad de autoescalación temporal para limitar los fallos

  2. Limitación de velocidad de reintroducción de trabajo y prueba de unidad

  3. Introducción de un mecanismo secundario para recopilar la información sobre la velocidad distribuida en el clúster con el fin de guiar los efectos de ampliación

  4. Coordinación necesaria de las migraciones de gran tamaño, puesto que AWS ES no realiza ampliaciones automáticas.

  5. Verificación de que la búsqueda de Stride aún se clasifica como de nivel 2

  6. Archivo de un ticket en el servicio pt-directory como fallo parcial en lugar de fallo completo cuando falle xpsearch-chat-searcher.

  7. Alerta de Cloudwatch para identificar un problema importante IO en el clúster ElasticSearch


Origen del problema y causas inmediatas

Cuando estás escribiendo o leyendo un análisis a toro pasado, es necesario distinguir entre el origen del problema y las causas inmediatas

  • Las causas inmediatas son los motivos que han llevado directamente a este incidente.
  • El origen del problema es el motivo que se encuentra en el lugar óptimo de la cadena de eventos sobre el que si se aplica un cambio se evitará esta clase completa de incidente.

Un análisis retrospectivo tiene el objetivo de descubrir el origen del problema y decidir cómo mitigarlo. Encontrar ese lugar óptimo de la cadena de eventos es la auténtica razón de un análisis retrospectivo. Usa una técnica como la de los cinco porqués para "subir por la cadena" y descubrir el origen del problema.

A continuación te mostramos unos ejemplos seleccionados de causas inmediatas y orígenes del problema:

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ías de orígenes del problema y sus acciones

Usamos estas categorías para agrupar las causas raíz y debatir las posibles acciones en cada caso.

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 marcas de función. 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)

¿Cuáles son las restricciones de recursos de tu servicio? ¿Se supervisan y emiten alertas al respecto? Si no tienes una planificación de capacidad, crea una. Si ya tienes una, ¿qué nuevas restricciones debes considerar?

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.


Causas raíz con dependencias

Cuando tu servicio tiene un incidente porque una dependencia falla, el lugar del fallo y el origen del problema dependerán de si la dependencia es interna de Atlassian o de terceros y de qué se puede esperar razonablemente del rendimiento de la dependencia.

Si es una dependencia interna, pregúntate cuál es el objetivo de nivel de servicio (SLO) de la dependencia:

  • ¿La dependencia ha incumplido su SLO?
    • El fallo reside en la dependencia y deben aumentar su fiabilidad.
  • ¿La dependencia se ha mantenido en el SLO, pero el servicio ha fallado igualmente?
    • Tu servicio debe aumentar su resistencia.
  • ¿La dependencia no tiene un SLO?
    • ¡Necesita uno!

Si es una dependencia de terceros, pregúntate qué se puede esperar razonablemente de la disponibilidad, latencia y demás características de esta dependencia de terceros.

  • ¿La dependencia de terceros ha excedido nuestras expectativas (en sentido negativo)?
    • Nuestras expectativas eran incorrectas.
      • ¿Estamos seguros de que no volverá a suceder? P. ej., hemos revisado su RCA (Análisis de origen del problema) y estamos de acuerdo con él. En este caso, la acción es su RCA.
      • ¿Necesitamos ajustar nuestras expectativas? En este caso, las acciones son aumentar nuestra resistencia y ajustar nuestras expectativas.
      • ¿Son nuestras expectativas ajustadas inaceptables? En este caso, necesitamos solucionar la desconexión entre requisitos y solución de algún modo, como por ejemplo, buscando otro proveedor.
  • ¿La dependencia de terceros se ha mantenido dentro de nuestras expectativas, pero el servicio ha fallado igualmente?
    • En este caso, tu servicio debe aumentar su resistencia.
  • ¿Realmente no tenemos expectativas?
    • El propietario de la dependencia de terceros debe establecerlas y compartirlas con los equipos para que conozcan el nivel de resistencia que deben crear en sus servicios dependientes.

* ¿Por qué "expectativas"? ¿No tenemos acuerdos de nivel de servicio (SLA) con terceros? En realidad, los acuerdos de nivel de servicio (SLA) contractuales con terceros son demasiado bajos para ser útiles al determinar el fallo y la mitigación. Por ejemplo, AWS no publica casi ningún acuerdo de nivel de servicio (SLA) para EC2. Por lo tanto, cuando dependemos de un servicio de terceros, tenemos que tomar una decisión con respecto al nivel de fiabilidad, disponibilidad, rendimiento o cualquier otra métrica clave que esperamos recibir de ellos de manera razonable.


Acciones de análisis a toro pasado

Sue Lueder y Betsy Beyer, de Google, tienen una presentación y artículo excelentes sobre los elementos de acción del análisis a toro pasado, que usamos en Atlassian para realizar preguntas al equipo.

Trabaja con las siguientes preguntas para ayudarte a garantizar que la revisión tras incidentes (PIR) cubre las correcciones a corto y largo plazo:

"Mitigar futuros incidentes" y "Evitar futuros incidentes" son tu fuente de acciones más probable para abordar el origen del problema. Asegúrate de obtener al menos una de estas.

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.


Aprobaciones del análisis a toro pasado

Atlassian utiliza el workflow de Jira con un paso de aprobación para garantizar que se aprueben los análisis a toro pasado. Por lo general, los aprobadores son propietarios de servicios u otros gestores con responsabilidad para la gestión de un servicio. La aprobación de un análisis a toro pasado indica:

  • el acuerdo con los hallazgos de la revisión posterior al incidente, incluido el origen del problema; y
  • el acuerdo con que las acciones "Priority Action" (Acción prioritaria) vinculadas constituyen una manera aceptable de abordar el origen del problema.

Nuestros aprobadores a menudo solicitarán acciones adicionales o que se identifique una cadena determinada de causalidad que no hayan abordado las acciones propuestas. De este modo, vemos que las aprobaciones añaden mucho valor a nuestro proceso de análisis a toro pasado en Atlassian.

En equipos con menos incidentes o una infraestructura menos compleja, las aprobaciones de análisis a toro pasado pueden no ser necesarias.


Análisis retrospectivos sin acusaciones

Cuando algo va mal, la tendencia humana natural es buscar a alguien a quien culpar. Para Atlassian es beneficioso evitarlo; sin embargo, cuando estás ejecutando un análisis a toro pasado tienes que superarlo constantemente. Asumimos que nuestro personal tiene buenas intenciones y nunca culpamos de los fallos a las personas. El análisis a toro pasado debe examinar de manera objetiva y honesta las circunstancias que provocaron el fallo, para poder encontrar los orígenes reales del problema y mitigarlos. Culpar a los individuos pone esta labor en peligro por los siguientes motivos:

  • El sentimiento de una persona al ver el riesgo de su prestigio en los ojos de sus compañeros o de su trayectoria profesional supera normalmente a los beneficios empresariales de su empleador en su jerarquía personal, por lo que probablemente oculte la verdad para proteger sus necesidades básicas.
  • Aunque una persona realizara la acción que provocase directamente un incidente, lo que deberíamos preguntar no es "por qué el individuo X hizo esto", sino "por qué el sistema le ha permitido hacerlo o le ha hecho pensar que era lo más adecuado".
  • Culpar a las personas es cruel y, si se repite lo suficiente, creará una cultura de miedo y desconfianza.

En nuestros análisis a toro pasado, utilizamos las siguientes técnicas para crear seguridad personal para todos los participantes:

  • Comienza la reunión del análisis retrospectivo haciendo saber que se trata de un análisis retrospectivo sin reproches y explica el motivo
  • Dirígete a los individuos según su función (p. ej., "el ingeniero de mecanismos incorporados de guardia") en lugar de por nombres (dejando los hechos claros y perfectamente definidos)
  • Asegúrate de que el cronograma, la cadena de casualidad y las mitigaciones del análisis a toro pasado se enmarquen en el contexto de sistemas, procesos y funciones, no en individuos.

La inspiración de los análisis a toro pasado irreprochables y el práctico concepto de "segunda historia" viene del influyente artículo de John Allspaw.