Domingo, once de la noche
Marta está de guardia en una agencia de viajes online de Madrid. Es domingo y suena el móvil.
La alerta dice que el 40 % de los pagos de reservas falla. Hay familias intentando pagar sus vacaciones en este momento.
Marta tiene que decidir qué hace primero. Esta lección enseña ese orden.
Al final de esta lección
Nota
Puedo decir qué hacer cuando producción se cae.
Palabras clave
| Palabra | Qué significa | Ejemplo |
|---|---|---|
| Incidente | un fallo que afecta a los usuarios ahora | |
| Guardia | el turno de quien atiende las alertas fuera de horario | |
| Gravedad | cuánto daño hace un incidente | alta, media, baja |
| Mitigar | reducir el daño, aunque no se conozca la causa | |
| Vuelta atrás | volver a la versión anterior que funcionaba | |
| Revisión sin culpas | un análisis posterior que busca causas, no culpables |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Primero se para el daño
Un incidente se atiende en un orden fijo. Primero confirmas que el fallo es real y decides su gravedad.
Después avisas: al equipo y, si hace falta, a los clientes.
Luego mitigas: haces lo más rápido para que los usuarios dejen de sufrir. Buscar la causa de fondo viene después, con calma.
Un error frecuente
Advertencia
Mucha gente cree que lo primero es encontrar la causa del fallo. No es así cuando hay clientes afectados. Si el fallo empezó con una versión nueva, se vuelve a la anterior y se investiga después. Cada minuto de búsqueda es un minuto de pagos perdidos.
Volver atrás es lo más rápido
Muchos incidentes empiezan justo después de publicar una versión nueva. La mitigación más común es la vuelta atrás.
Por eso se guardan las versiones anteriores, igual que las imágenes con número de versión.
En el bloque, actual señala la versión que se sirve. Ejecútalo y haz la vuelta atrás del comentario.
Volver de la v42 a la v41
mkdir -p viajes/versiones && cd viajes
mkdir -p versiones/v41 versiones/v42
echo "Reservas: funcionan" > versiones/v41/estado.txt
echo "Reservas: error al pagar" > versiones/v42/estado.txt
# "actual" apunta a la versión que se está sirviendo
ln -sfn versiones/v42 actual
echo "Sirviendo: $(readlink actual)"
cat actual/estado.txt
# Vuelta atrás: cambia v42 por v41 en la orden ln de arriba y ejecuta.
La disponibilidad se mide en minutos
Los equipos se ponen un objetivo de disponibilidad: el porcentaje del tiempo en que el servicio funciona.
Un 99,9 % parece casi perfecto. Pero deja unos 43 minutos de caída al mes.
Ese margen decide cuánto riesgo se puede asumir al publicar. La tabla muestra los cálculos.
Minutos de caída permitidos
| Objetivo | Caída permitida | Al mes de 30 días |
|---|---|---|
| 99 % | 1 % del tiempo | unas 7 horas y 12 minutos |
| 99,9 % | 0,1 % del tiempo | unos 43 minutos |
| 99,99 % | 0,01 % del tiempo | unos 4 minutos |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Después se aprende sin buscar culpables
Cuando todo vuelve a funcionar, el equipo escribe una revisión sin culpas. Recoge qué pasó, minuto a minuto, por qué pasó y qué se cambia para que no se repita.
No señala a nadie. Si la gente teme el castigo, esconde los fallos y el equipo deja de aprender.
La cronología del domingo
| Hora | Qué pasó |
|---|---|
| 22:40 | Se publica la versión v42 |
| 23:02 | Salta la alerta: el 40 % de los pagos falla |
| 23:06 | Marta confirma el fallo y avisa al equipo |
| 23:11 | Vuelta atrás a la v41; los pagos se recuperan |
| Lunes | Se encuentra la causa: una prueba de pagos que faltaba |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.