Análisis de incidencias


Curso de escalabilidad v2, día 5

Qué veremos hoy


Investigación de causa raíz. Los cinco porqués


Postmortems sin culpa


Tareas post-incidente


Actitudes y expectativas. Liderazgo

Un hueco con forma de incidencias



¿Qué es una incidencia?



Un problema con impacto negativo en el servicio


Idealmente, resulta en una o más alertas


Requiere atención fuera de lo ordinario


Con consecuencias en usuarios o negocio

Ejercicio: Explosión de Chernóbil





Intenta pensar cuál es la causa raíz


¿Cómo la resolverías?



¡Suspense!



Investigación de causa raíz


Los cinco porqués


Hay que preguntar como un niño


No detenerse en la primera causa


Pero, ¿por qué cinco porqués?


Hay que seguir hasta que esté todo claro

Problema: ¿causa raíz?


En un sistema complejo
los fallos no son por una única causa


Siempre hay que buscar múltiples fallos
y luego arreglarlos todos


Bucea hasta que tengas completa seguridad
de que has entendido el problema

Raíz de causas


Diagrama de Ishikawa






Finding the root cause of a failure is like finding the root cause of a success

Ejercicio: Colisión USS John McCain




Revisa las consecuencias del mismo


¿Quién tuvo la culpa?


¿Qué medidas fueron acertadas y cuáles no?


Mystery solved!


Situaciones emocionales



Los ejercicios que estamos viendo son fuertes


¿Es posible un punto de vista desapasionado?


Estas industrias han tenido décadas (o siglos) para aprender


Saber hacer un análisis desapasionado es la clave

Postmortems sin culpa


¡Error humano!



Human error is not a cause, it is an effect.


Si se castiga a la gente por ser honrada sobre lo que ha pasado, los empleados pronto aprenderán que el coste personal de hablar no compensa los posibles beneficios personales. La mejora en seguridad de un sistema se basa en la información.

United States Forest Service

Segundas historias


First Stories Second Stories
Human error is seen as cause of failure Human error is seen as the effect of systemic vulnerabilities deeper inside the organization
Saying what people should have done is a satisfying way to describe failure Saying what people should have done doesn’t explain why it made sense for them to do what they did
Telling people to be more careful will make the problem go away Only by constantly seeking out its vulnerabilities can organizations enhance safety

Línea temporal (Timeline)


Habla con las partes implicadas


Asegúrate de entender las consecuencias


Narra los sucesos en orden


Crea una historia
Captura los detalles
Contrástala

Labor de equipo



Revisión de código


Responsabilidad compartida

Ejercicio: Accidente del Challenger





¿Crees que fue una buena investigación?


¿Crees que las recomendaciones fueron útiles?



Excellent!


Facilitación del análisis


If the incident analyst participated in the incident, they will inevitably have a deeper understanding and bias towards the incident that  will be impossible to remove in the process of analysis.


Ryan Kitchens, Netflix

Tareas post-incidente




¿Cómo hacer un informe?


Un simple email puede bastar


Que no sea un tostón




Con gráficos y datos

Informe público


Para enviar a la organización


Todo el mundo puede aprender


Amplía la audiencia a los afectados


Un fallo público suele aceptarse mejor

Planifica medidas


Resolución: resuelve problemas


Mitigación: reduce consecuencias


Prevención: evita incidentes


Monitorización: alerta de futuros problemas

Checklists


Revisa los procedimientos


Elabora una checklist


Cada procedimiento delicado debería tener su checklist
elaborado en frío


Mantén scripts



El siguiente paso es automatizar las tareas


Un script permite ejecutar múltiples tareas


Los scripts deben estar repositados y catalogados

Crea sistemas resistentes


Un sistema robusto resiste los embates del azar


Intenta que tus sistemas se recuperen solos


Mejor un aviso el lunes que una alerta el sábado

Usa lo que más convenga





What you want to avoid at all cost is incident-driven development. Testing should be deeply enshrined in the genes of the organization. We want to do this in as structured a way as possible.

Edwin Hakkennes:

Mal: Apagando fuegos todo el día

¡No confundir con IDD!

Bien: Incident-Driven Development


Los incidentes marcan el camino a seguir


Son incógnitas desconocidas: ¡acéptalo!


Intenta resolverlos a fondo


¿Qué puedo hacer para que no se repita?

Ejercicio: Accidente de Santiago




¿Cuáles fueron las causas?


¿Qué se podía haber hecho mejor?




We can do better!



Liderazgo





Consider listening to what an incident has to teach you. It's your job to figure out what that is.


John Allspaw, Incidents as we Imagine Them Versus How They Actually Are

Actitudes y expectativas


Cómo actúes en una crisis marcará el tono


La comunicación es lo más importante


Explica claramente qué buscas


Intenta sacar lo mejor de cada cual


The problems begin when the pressure to fix outweighs the pressure to learn.


Todd Conklin, via John Allspaw

Riesgo


Fija las expectativas de riesgo


Sin riesgo no hay beneficio
Sin riesgo no hay mejora


El único software "estable" es el que no cambia


Calibración del riesgo


Según el tipo de sistema


Riesgo menor
Riesgo económico
Riesgo de impacto a clientes
...
Riesgo de vidas humanas


Elabora planes de contingencia si es necesario

¡Sí se puede!


Inversión


¿Cuánto tiempo del equipo estás dispuesto o dispuesta
a dedicar a mejorar la estabilidad?


¿Prefieres pagar en horas de trabajo
o en "sangre" (alertas fuera del trabajo)?


Nota: la "sangre" no es gratis

Los incidentes afectan al desarrollo


Las planificaciones sufren


A no ser que tengas un equipo aparte
y ni por ésas


¡Y así es como debería ser!


Deja que guíen las mejoras del sistema

Ejercicio: Boeing 737 MAX




Pregúntale al ingeniero residente


Elabora un análisis del incidente


Sigue el checklist


Busted!



Bibliografía



The New Yorker: The Checklist



Recapitulemos

Sistemas distribuidos. Escalado y replicación


Pruebas de carga. Optimización de rendimiento


Uso de métricas. Incógnitas desconocidas


Monitorización y observabilidad


Análisis de incidencias

CdEv2 5: Análisis de incidencias

By Alex Fernández

CdEv2 5: Análisis de incidencias

Curso de escalabilidad v2, día 5: análisis de incidencias.

  • 158
Loading comments...

More from Alex Fernández