Rompí producción, ¿y ahora qué hago?

Lo que nadie quiere oír

Sudor frío corriendo por la espalda del Software Engineer. Agarrada de cabeza, y de golpe, el silencio se corta con un fatídico “Che, rompí producción, qué hacemos?” No podemos confirmar ni negar que esa frase se oyó varias veces por los pasillos de Despegar. Frase que nadie quiere oír ni pronunciar. Pero pasa. Y en Despegar ya sabemos cómo lidiar con esta situación.

Primero: tratar de arreglarlo. Despegar no descansa, y nuestras aplicaciones tampoco deberían hacerlo. Buscamos el método que consideremos más conveniente para dejar la aplicación funcionando y minimizar el impacto a nuestros clientes y a la compañía. Una vez que logramos que pase el temporal, viene otra etapa: hacer el Post Mortem.

¿Qué es el Post Mortem?

En Despegar entendemos que no existe software sin bugs ni un ambiente de producción 100% libre de errores. Aún así, no es aceptable que esos errores se reiteren y no mejoremos nuestros procesos, herramientas o base de código, en pos de evitar, prevenir o mitigar un nuevo problema.

Para eso, una de las herramientas de la que nos valemos es el post mortem. Es un análisis que hacemos y compartimos entre nuestros equipos, evaluando qué rompimos, qué nivel de afectación tuvimos para la compañía, por qué rompimos, y qué acciones vamos a tomar para no repetir el error.

El simple hecho de llevar adelante el ejercicio de escribir un post mortem, teniendo presente que lo que tenemos que contar va a ser leído por alguien más nos obliga a poner especial atención a cada uno de los detalles. Y ,al hacerlo, es altamente probable que descubramos algunas cuestiones que antes pasaron desapercibidas y sobre las cuales queremos accionar para cambiarlas.

¿Para qué hacemos post mortem en Despegar?

• Para aprender de nuestros errores: para racionalizar y entender exactamente qué fue lo que ocurrió, para minimizar las chances de que vuelva a ocurrir.
• Para comunicar las causas (técnicas o no) de un problema que hayamos tenido al resto de la compañía, de forma transparente.
• Para hacernos responsables de nuestros errores.
• Para entender el impacto que tuvo en el negocio.
• Para compartir lo aprendido con el resto de nuestros equipos, y que más personas puedan nutrirse de nuestra experiencia.
• Para crear y fomentar cultura de aprendizaje.

¿Para qué NO hacemos el post mortem?

Es importante destacar que el espíritu del ejercicio es ser un mejor equipo, y debemos evitar buscar culpables o “señalar con el dedo”, a fin de mantener una cultura de aprendizaje y responsabilidad. Una de las cosas que no hacemos es poner nombres propios, sino que hablamos en forma de equipo (por ejemplo, no ponemos “tal persona me dijo tal cosa”, sino que lo expresamos como “en el equipo vimos que…”, de manera de no señalar, sino construir.

¿Cuándo hacemos post mortem?

No tenemos una fórmula exacta que indique la situación que lo requiere o no. Pero algunos motivos válidos para hacerlo podrían ser que hubo un impacto no despreciable en el negocio o en otros equipos, y podemos sacar un aprendizaje del problema, y que vale la pena compartirlo con el resto de los equipos.

Algunos ejemplos de casos en los que hicimos post mortems:

• “Corrimos un script que trabó una base de datos y no nos permitia vender vuelos”
• “Por un error en un refactor calculamos mal un campo que usan otras apps”
• “Este proyecto nos llevó mucho más tiempo del que estimamos”
• “Les mandamos notificaciones a usuarios que no correspondía mandarles”

¿Qué analizamos en el post mortem?

Impacto:

Nos detenemos a analizar a quién(es) impactamos y cuál fue el grado de afectación. Para eso nos sirve preguntarnos:

• ¿Afectamos a nuestros usuarios? ¿A cuántos? ¿Cómo afectamos su experiencia con Despegar?
• ¿Afectamos a otros equipos/aplicaciones?
• ¿Cantidad de reservas afectadas?
• ¿Qué porcentaje de los requests de la app fallaron?
• ¿Perdimos plata? ¿Cuánto?

Detección:

Explicamos cómo nos dimos cuenta del problema

• ¿Nos saltó una alerta?
• ¿Nos avisó el equipo de guardia?
• ¿Nos llegaron quejas de nuestros clientes?

Causa raíz:

Profundizamos en la causa del error, diferenciándolo del disparador del problema. Puede pasar que tengamos un error que no se manifieste por sí mismo, hasta que no prendimos/apagamos otra cosa. Pero lo que nos importa entender es el problema que estaba latente, y no el cambio de contexto que produjo la activación del error.

Resolución:

Acá explicamos todos los pasos con los que resolvimos el problema.

Status:

¿En qué estado está ahora el ambiente productivo? ¿Fue aplicado sólo un parche, o ya tomamos acciones definitivas tendientes a la solución del problema?

Lecciones aprendidas:

¿Qué aprendizajes nos llevamos de este problema? ¿Qué podríamos haber hecho diferente para que las cosas tuvieran otro desenlace?

Acciones ejecutadas:

En base al problema y los aprendizajes que tuvimos, ¿qué vamos a hacer distinto para que no se repita el problema?

En conclusión

Al tener que detenernos a analizar el impacto, nos obligamos a entender lo que hacemos en el día a día, y comprender el rol de nuestro software dentro de la maquinaria de Despegar.

Es importante ser honestos a la hora de escribir este documento. Como dijimos, el espíritu no es echar culpas, sino aprender de nuestros errores. De esta manera contribuimos a mantener la cultura de aprendizaje y responsabilidad que nos enorgullece tener en Despegar.