# Incidente: "mi reserva no aparece"

Caso escrito para el laboratorio; el complejo, las horas y las personas son
ficticios. Es lo que la administración de Kallpa contó el lunes siguiente.
Los pasos 7 y 8 del laboratorio de la [semana 13](../../weeks/week-13.md) parten de aquí.

## Lo que vio la administración

**Viernes, 17:30.** Quien estaba de turno desplegó una versión nueva: corregía
un texto de la página. El cambio era pequeño y las pruebas pasaban. Desde su
terminal corrió:

```sh
docker build -t kallpa .
docker rm -f kallpa
docker run -d --name kallpa -p 8080:3000 kallpa
```

Hasta el jueves el contenedor se había levantado con un comando guardado en una
nota, en otra computadora. Abrió la página, vio el calendario con reservas y
se fue a su casa.

**Viernes, 18:40.** Llegó un equipo de fulbito con su reserva de las 19:00,
hecha el martes. El vecino mostró el WhatsApp de confirmación. En la página, a
esa hora, la cancha decía *Real Barranco*, un equipo que nadie en el complejo
conocía. La administradora pensó que era un error de ese equipo, le pidió
disculpas y les dio otra cancha.

**Viernes, 19:15.** Dos llamadas más por lo mismo. Una vecina dijo que había
reservado esa misma tarde, a las 17:50, y que ahí su reserva sí estaba.

**Viernes, 20:00.** La administradora abrió la caja del día: los totales no
cuadraban con el cuaderno. Escribió al grupo del equipo de desarrollo.

**Viernes, 20:10.** Quien estaba de turno miró el monitor: `GET /health`
respondía `200` y el contenedor decía `healthy`, como toda la tarde.
Respondió: "el sistema está arriba".

**Lunes.** La administración pide que no vuelva a pasar, y quiere saber a
cuántos vecinos tiene que llamar.

## Qué se les pide

1. **Reproducirlo** en su computadora, con su imagen, como dice el paso 7. Es
   un game day: lo provocan ustedes, a propósito.
2. **Explicar cada síntoma** con lo que ven en su reproducción: por qué aparece
   un equipo que nadie conoce, por qué `/health` dice que todo está bien, y por
   qué nada falló al desplegar.
3. **Mitigar** y comprobar que una reserva sobrevive a un nuevo despliegue.
4. **Responder a la administración:** qué se recupera, qué no y por qué. Piensen
   en dos grupos de vecinos: quienes reservaron antes del viernes a las 17:30 y
   quienes reservaron después. Comprueben su respuesta: hagan una reserva de
   cada tipo, antes de mitigar, y búsquenlas después.
5. **Escribir el postmortem** con [`postmortem-template.md`](postmortem-template.md).
   Las horas de la línea de tiempo y los datos del impacto salen de su propia
   reproducción y de sus logs, no de este relato. Sin nombres de personas.