Plantilla de Revisión Semanal de Operaciones

Visión General

Las revisiones de operaciones son donde los equipos detectan tendencias antes de que se conviertan en incidentes. Una revisión semanal de incidentes, costos y rendimiento transforma alertas dispersas en patrones útiles. Sin estructura, las revisiones de operaciones se convierten en sesiones de quejas o actualizaciones de estado que nadie lee. Lo que esta plantilla te da es una forma repetible: qué pasó, qué costó, qué viene en tendencia y qué pensamos hacer al respecto.

La plantilla es deliberadamente densa en tablas: los números en una página son más difíciles de discutir que las impresiones en una reunión. Cada sección responde una pregunta: resumen (¿cómo fue la semana?), incidentes (¿qué se rompió?), costos (¿qué gastamos?), rendimiento (¿estamos dentro del SLO?), acciones (¿qué cambia la próxima semana?) y riesgos (¿qué podría romperse pronto?).

Cuándo Usar

Usa este recurso cuando:

• Tu equipo reacciona a incidentes pero nunca analiza patrones
• Los costos en la nube aumentan silenciosamente sin explicación
• Estás estableciendo una práctica de SRE o ingeniería de plataforma y necesitas una cadencia de revisión regular

Sáltala cuando una revisión mensual de negocio ya cubre la salud operativa, o cuando el equipo es tan pequeño que todos saben qué se rompió esta semana: una startup de cinco personas puede arreglarse con un canal compartido y un hilo los viernes. Para análisis profundos de rendimiento, la Plantilla de Regresión de Rendimiento encaja mejor.

Solución

# Revisión Semanal de Operaciones: `<Semana del AAAA-MM-DD>`

## 1. Resumen Ejecutivo

| Métrica | Esta Semana | Semana Pasada | Tendencia | Objetivo |
|---------|-------------|---------------|-----------|----------|
| Incidentes | `X` | `Y` | ↑ / ↓ / → | `< 3` |
| SEV 1–2 | `X` | `Y` | ↑ / ↓ / → | `0` |
| MTTR (promedio) | `X min` | `Y min` | ↑ / ↓ / → | `< 30 min` |
| Costo en la Nube | `$X` | `$Y` | ↑ / ↓ / → | `< $Z` |
| Presupuesto de Error Restante | `X%` | `Y%` | ↑ / ↓ / → | `> 50%` |

**Narrativa:** `Un párrafo resumiendo la semana: mayor problema, mayor éxito, mayor riesgo.`

## 2. Revisión de Incidentes

| ID | Severidad | Servicio | Causa Raíz | MTTR | Acción | Responsable | Estado |
|----|-----------|----------|------------|------|--------|-------------|--------|
| INC-### | SEV 1/2/3 | `servicio` | `causa` | `X min` | `acción` | `@nombre` | Abierto / Cerrado |

### Temas Recurrentes

- `Tema 1: descripción y frecuencia`
- `Tema 2: descripción y frecuencia`

### Seguimiento de la Semana Pasada

- [ ] `Acción 1` — `@responsable` — `estado`
- [ ] `Acción 2` — `@responsable` — `estado`

## 3. Análisis de Costos

| Categoría | Esta Semana | Semana Pasada | Delta | Presupuesto | Variación |
|-----------|-------------|---------------|-------|-------------|-----------|
| Compute (EC2 / GCE) | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Almacenamiento | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Transferencia de Datos | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Servicios Administrados | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| **Total** | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |

### Motores de Costo

- `Motor 1: descripción`
- `Motor 2: descripción`

### Acciones de Costo

| Acción | Ahorro Proyectado | Responsable | Fecha Límite |
|--------|-------------------|-------------|--------------|
| | | | |

## 4. Rendimiento y Confiabilidad

| Servicio | Disponibilidad | Latencia P99 | Tasa de Error | Saturación | Estado |
|----------|----------------|--------------|---------------|------------|--------|
| `API` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |
| `Web` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |
| `Worker` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |

### Violaciones de SLO

| Servicio | SLO | Actual | Impacto en Presupuesto | Acción |
|----------|-----|--------|------------------------|--------|
| | | | | |

## 5. Acciones para la Próxima Semana

| Prioridad | Acción | Responsable | ETA | Criterio de Éxito |
|-----------|--------|-------------|-----|-------------------|
| P0 | | | | |
| P1 | | | | |
| P2 | | | | |

## 6. Riesgos y Escalados

| Riesgo | Probabilidad | Impacto | Mitigación | Escalado |
|--------|--------------|---------|------------|----------|
| | | | | |

Explicación

La plantilla separa datos de narrativa. Las tablas fuerzan una revisión cuantitativa; la narrativa explica qué significan los números. Muchos equipos omiten el análisis de costos hasta que la factura sorprende a finanzas: incluirlo semanalmente construye consciencia de costos en la cultura de ingeniería. La sección de temas recurrentes es donde detectas problemas sistémicos: tres incidentes relacionados con memoria en tres semanas es un patrón, no mala suerte.

Si estás construyendo el hábito de revisión junto a una rotación de guardias, la guía de Playbook de Guardias e Incidentes cubre la parte de incidentes, y la guía de prácticas SRE cubre presupuestos de error y mecánica de SLO en profundidad.

Archivos complementarios: el repo companion de weekly-ops-review-template tiene la revisión como archivo Markdown independiente más un script summarize-week.py que calcula la tabla de resumen ejecutivo a partir de un JSON de incidentes y costos.

Consulta de Dashboard de la Revisión Semanal

=== Dashboard de la Revisión Semanal de Operaciones ===

Semana del: 2026-07-08 al 2026-07-14

1. RESUMEN DE INCIDENTES
   Incidentes totales:      3
   P0 (crítico):            0
   P1 (alto):               1 (timeout de auth-service, 2026-07-10)
   P2 (medio):              2 (tormenta de evicción de caché, query lenta en DB)
   Tiempo medio detección:  4 min
   Tiempo medio resolución: 22 min
   Impacto al cliente:      1.200 usuarios afectados (P1)

2. ESTADO DE SLO
   Servicio          Objetivo SLO  Actual    Presupuesto Restante
   api-gateway       99.9%         99.92%    78%
   auth-service      99.9%         99.85%    42% (en bajada)
   payment-service   99.95%        99.96%    65%
   search-service    99.5%         99.51%    51%

3. ANÁLISIS DE COSTOS
   Esta semana:      $12.450
   Semana pasada:    $11.800
   Tendencia:        +5,5% (investigar)
   Mayor costo:      Instancias EC2 ($4.200)
   Anomalía:         Egress S3 +40% (¿nueva feature de exportación?)

4. RESUMEN DE DESPLIEGUES
   Despliegues totales:   7
   Rollbacks:             1 (api-gateway v2.3, error de config)
   Hotfixes:              1 (arreglo de sesión en auth-service)
   Despliegues fallidos:  0

5. TEMAS RECURRENTES
   - Picos de latencia en auth-service en hora punta (3ª semana)
   - Tasa de evicción de caché sobre la línea base (2ª semana)
   - Costo de egress S3 aumentando (1ª semana, patrón nuevo)

Plantilla de Seguimiento de Acciones

=== Tracker de Acciones ===

Semana: 2026-07-08

| ID  | Prioridad | Acción                                | Responsable | Estado      | ETA         |
|-----|-----------|---------------------------------------|-------------|-------------|-------------|
| A01 | P1        | Investigar latencia de auth-service   | alice       | En progreso | 2026-07-15  |
| A02 | P1        | Arreglar política de evicción de caché| bob         | Abierta     | 2026-07-18  |
| A03 | P2        | Revisar pico de costo de egress S3    | charlie     | Abierta     | 2026-07-22  |
| A04 | P2        | Actualizar query DB con índice faltante| dba-team   | Hecha       | 2026-07-10  |
| A05 | P0        | Añadir alerta auth p99 > 2s           | alice       | Hecha       | 2026-07-11  |

Acciones de la Semana Anterior:
| ID  | Acción                                   | Responsable | Estado      |
|-----|------------------------------------------|-------------|-------------|
| P01 | Reducir costos EC2 con right-sizing      | platform    | Hecha       |
| P02 | Añadir test sintético para checkout      | qa-team     | En progreso |
| P03 | Documentar procedimiento de failover     | sre-team    | Hecha       |

Cómo Dirigir la Revisión

Nada de esto funciona sin una reunión con forma fija. Un formato que aguanta en la práctica:

1. Datos primero (5 min). Rellena las tablas antes de la reunión: quien facilita saca los números de monitoreo, gestión de incidentes y herramientas de costos. La reunión discute; no va a buscar datos.
2. Seguimiento antes que novedades (5 min). Repasa primero las acciones de la semana pasada. Si una acción lleva dos semanas estancada, o es lo bastante importante para escalarla o lo bastante honesta para cerrarla.
3. Incidentes y tendencias (10 min). Revisa qué se rompió y si se siguen rompiendo las mismas cosas. Aquí es donde los temas recurrentes reciben nombre.
4. Costos y rendimiento (5 min). Ojea salvo que algo se haya movido: un cambio de costo del 5%+ o un SLO acercándose al límite se ganan la palabra.
5. Acciones y riesgos (5 min). Ninguna acción sale de la sala sin responsable ni fecha límite, y los riesgos quedan escritos antes de convertirse en incidentes.

Dos modos de fallo a vigilar: la revisión deriva en reunión de estado (la gente reporta en vez de analizar: córtalo), o muere silenciosamente tras unas semanas tranquilas (una semana tranquila es justo cuando el análisis de tendencias paga; mantén la cadencia).

Variantes

Contexto	Enfoque	Cadencia
Startup (< 20 personas)	Solo incidentes + costos; omitir tablas SLO	Semanal, 15 min
Scale-up (20–100)	Plantilla completa; asignar responsables de acciones	Semanal, 30 min
Enterprise (100+)	Revisiones por servicio; agregación mensual	Semanal por equipo, mensual entre equipos
Equipo de Plataforma / SRE	Enfoque en infraestructura compartida y salud de tenants	Semanal, 45 min
Organización consciente de costos	Expandir sección de costos; incluir costo por feature	Semanal, 30 min

Lo Que Funciona

1. Mantén la revisión bajo 30 minutos; las reuniones largas matan la participación
2. Asigna responsables a cada acción en la reunión, no después
3. Revisa primero las acciones de la semana pasada; la rendición de cuentas refuerza el hábito
4. Usa números reales, no anécdotas; “se siente lento” no es útil
5. Documenta riesgos antes de que se conviertan en incidentes; escalar temprano previene incendios

Errores Comunes

1. Convertir la revisión en una sesión de culpas; enfócate en sistemas, no en personas
2. Omitir el análisis de costos hasta que finanzas se queje; los costos crecen silenciosamente
3. No revisar acciones de semanas anteriores; eso hace inútil la reunión
4. Permitir que “no hubo incidentes esta semana” signifique “no hay nada que discutir”; siempre revisa tendencias
5. No escalar riesgos temprano; esperar a que un riesgo se convierta en incidente desperdicia la revisión

Resolución de Problemas

Estos son los modos de fallo de la propia revisión: cuando el ritual existe pero no produce resultados:

• La revisión se volvió una reunión de estado: la gente recita lo que hizo en vez de analizar lo que hizo el sistema. Arréglalo prohibiendo actualizaciones individuales; las tablas llevan los hechos, la discusión lleva el significado.
• Las acciones se acumulan sin responsable: cada ítem salió de la reunión con nombre pero nadie cierra nada. Limita la lista activa (10 por equipo funciona) y cierra o escala lo que lleve más de dos semanas: una lista que crece es ruido, no rendición de cuentas.
• Nadie confía en los números: la tabla de costos y el dashboard no cuadran, o las métricas se recogen a mano con errores. Automatiza la recogida desde las APIs de origen (monitoreo, incidentes, costos) y deja de editar cifras a mano.
• La asistencia no para de caer: la revisión se hizo demasiado larga o genérica. Recórtala a las secciones que cambiaron esta semana y rota el facilitador: la titularidad de la reunión mantiene a la gente dentro.
• El mismo incidente se repite: los temas se anotan pero nunca se convierten en arreglos. Cuando un tema aparece tres semanas seguidas, pasa de “tema” a acción registrada con responsable, o se queda para siempre.

Lectura Adicional

• Google SRE Workbook — Implementing SLOs: la mecánica de presupuestos de error detrás de la sección de Rendimiento y Confiabilidad.
• DORA: las cuatro métricas clave que vale la pena añadir al resumen ejecutivo cuando lo básico ya es estable.
• Plantillas relacionadas: Plantilla de Regresión de Rendimiento para análisis profundos de latencia, Plantilla de Gestión de Cambios para la parte de despliegues.