---
# System prepended metadata

title: Parte teórica

---

# Parte teórica
## 1. ¿Qué es un postmortem? ¿Qué elementos lo componen? 

Es un documento escrito (registro) de un incidente, su impacto, las acciones tomadas para resolverlo o mitigarlo, las causas y las acciones por hacer para prevenir la recurrencia de esta falla (Postmortem Culture: Learning from failure).

Los principales elementos que lo componen según el artículo de Google y charla de Fintual son: título, fecha, autores, resumen, estado, impacto, causa principal (y gatillador), resolución, detección, _action items_, lecciones, descripción técnica y línea de tiempo.

## 2. ¿Cuáles son los 2 principales objetivos de mantener una cultura de postmortems? 

Los principales objetivos son, en primer lugar, asegurar que el incidente es documentado, de tal forma de entender las causas de raíz y, en segundo lugar, que las acciones preventivas estén bien implementadas para así reducir la probabilidad y/o impacto de recurrencia de estos incidentes.

## 3. ¿Por qué es importante que un postmortem sea _blameless_ y _actionable_?

Primero, es importante que sea blameless para que la cultura de la empresa no se rompa. Tal como se mencionaba en la charla de Fintual, no se debe apuntar con el dedo a quien apretó el “botón rojo” que destruye el software, sino que más bien se debe apuntar a eliminar este botón rojo. Además, el hecho de que sea blameless contribuye a que se quiera llegar al fondo del asunto y que reporten todo (que no se tenga miedo a repercusiones).

Segundo, es importante que un _postmortem_ sea _actionable_, de tal forma que existan acciones para reducir o eliminar la probabilidad de que ocurra nuevamente el incidente, y así eliminar la posibilidad de que se rompa el software. Siguiendo el ejemplo del botón rojo, agregar una alerta para la próxima vez que alguien presione el botón rojo no implica que sea _actionable_. Para que lo sea, deberían proponer una acción que se cuestione desde la raíz el por qué existe ese botón y que se proponga una forma de evitar que alguien pueda siquiera llegar a presionarlo. 

# Parte práctica: _Postmortem_ Fintual

## Título: 

2020-08-08: Postmortem subida de foto carnet no disponible afectando el registro de usuarios.


## Resumen: 

Durante la noche del 8 de agosto no se podían aprobar carnets para el registro en Fintual (lo cual inhabilitó la funcionalidad de registro). Esto debido a que la plataforma de Google Cloud estaba inoperativa por problemas con el método de pago. Se tuvo que poner una tarjeta de crédito no de la empresa para poder solucionar el problema.
## Impacto:

- Funcionalidad para que usuarios suban fotos de carnet y ver admin de usuarios caída durante aproximadamente 1 hora (estimado a partir de la conversación).
- Aproximadamente 3 clientes que no pudieron utilizar la funcionalidad mencionada durante ese rato (mencionado en penúltimo mensaje conversación). Dos de ellos tuvieron que volver a realizarlo más tarde.

## Causa principal: 

La tarjeta de crédito asociada no estaba habilitada para pagar el servicio de Google Cloud (problemas con el pago, nunca queda 100% claro cual era, pero había llegado una advertencia antes con problemas en el pago). 


## Resolución: 
Se puso momentáneamente la tarjeta de crédito de uno de los desarrolladores.

## Detección: 
CEO notó que no se podían ver los carnets pendientes (alerta de Google Cloud salta al momento de hacer la request). Además, llegaron reclamos por chat de usuarios con problemas al subir la imagen del carnet.

## Action Items: 
- Mantener todos los servicios con la misma tarjeta de crédito asociada a la empresa (y no a desarrolladores). Lo mismo con los servicios (actualmente el billing estaba asociado a la cuenta de google de un desarrollador y no de la empresa lo que limitaba el acceso).
- Monitorear el billing de los servicios mensualmente.
- No eludir los correos de advertencia (no dejar para después).

## Lecciones: 
### Qué salió bien
- Se resolvió rápidamente (en sólo una hora) a pesar de estar en horario no laboral.
- La comunicación y apoyo del equipo facilitaron llegar a una resolución rápida.


### Qué salió mal
- No hubo una alerta general que permitiera notar inmediatamente el problema (el CEO se dió cuenta por estar revisando manualmente a esa hora los carnets pendientes).
- El billing estaba asociado a la cuenta personal de un desarrollador por lo que los otros desarrolladores no tenían acceso para poner una tarjeta rápidamente.

### Donde tuvimos suerte
- Fue en horario no peak (de noche un sábado) para una funcionalidad específica, por lo que no muchos usuarios fueron afectados (3).
- Estaba despierto (o atento) John, quien era el único con acceso al billing debido a la configuración.
- La caída de este servicio es externo a la app web y móvil, por lo que no afectó la accesibilidad a otras funcionalidades
- El servicio se restableció casi instantáneamente al momento de agregar el nuevo carnet.

## Descripción técnica

Debido a un problema de billing (pago) asociado a Google Cloud, la funcionalidad para subir imágenes del carnet (por parte de los usuarios) o ver los admin de los usuarios (por parte de Fintual) no estuvo disponible por un un par de horas, lo cual inhabilitó la funcionalidad de registro. Además, el billing estaba asociado a una cuenta personal en vez de la empresa, dificultando la resolución.

## Línea de tiempo
No se especifica dado que está en el enunciado de la actividad (el registro del chat). Asumimos esto porque en los ejemplos de Google y Fintual son lo mismo.


