Plantilla de Production Readiness Review

Descripción General

Enviar a producción no es la línea de meta. Es la línea de salida de la responsabilidad operativa. Un Production Readiness Review (PRR) es un checkpoint estructurado que verifica que un servicio o feature está listo para correr en producción: puede monitorearse, revertirse, asegurarse y operarse por personas distintas al autor. Los PRRs previenen las sorpresas de las 3 AM donde nadie sabe cómo reiniciar un servicio, cómo se ve “normal” o cómo revertir un mal deploy.

Cuándo Usar

Usa esta plantilla cuando:

• Un nuevo servicio se despliega a producción por primera vez
• Un feature o refactor mayor cambia cómo opera un servicio existente
• Un servicio cambia de tier (ej., de herramienta interna Tier 3 a customer-facing Tier 1)
• Adquieres o migras un servicio de otro equipo o empresa
• Una auditoría requiere evidencia documentada de preparación para producción

Prerrequisitos

Antes de conducir un PRR:

• El servicio o feature está completo en código y pasa todos los tests automáticos
• Existe un documento de ownership de servicio (o se creará como parte de esta revisión)
• La rotación de on-call está definida y entrenada
• Existen runbooks para escenarios comunes de falla
• Un procedimiento de rollback ha sido probado en un ambiente no productivo

Ejecutando la Revisión

1. Circula la plantilla temprano. Envía la checklist al dueño del servicio y a los revisores al menos una semana antes de la sesión — los gaps encontrados en la sala son gaps encontrados demasiado tarde.
2. Recorre los dominios en orden. Cada casilla se marca solo con evidencia: un enlace al dashboard, un runbook, una ejecución de test. “Lo tenemos” no cuenta.
3. Registra hallazgos sobre la marcha. Cada gap aterriza en Notas de Revisión con nivel de riesgo, responsable y fecha límite. Sin responsable no hay arreglo.
4. Sign-off por rol. Ingeniería, producto, seguridad y SRE firman (o bloquean) su propio dominio — nadie firma por otro.
5. Decide: aprobado, condicional o rechazado. Aprobado condicional significa que se puede lanzar una vez cerrados los items de alto riesgo; los medios se rastrean. Rechazado significa arreglar y reprogramar.
6. Rastrea las acciones. La revisión no termina hasta que los hallazgos terminan. Da seguimiento a las fechas antes de llamar “listo” al servicio.

Acotando la Revisión

No todo servicio necesita la misma profundidad. Tier 1 (customer-facing, toca revenue) recibe los diez dominios completos más una re-revisión trimestral de los más riesgosos — observabilidad y rollback primero. Tier 2 (importante pero no crítico) corre la revisión completa una vez y luego re-revisiones anuales. Tier 3 (herramientas internas) puede quedarse con un subconjunto: definición de servicio, despliegue, seguridad y preparación operacional rara vez son opcionales; chaos testing y distributed tracing a menudo sí.

La conversación de alcance ocurre antes de la revisión, en el kickoff — no durante, cuando media sala ya está a la defensiva. Documenta qué dominios recortaste y por qué; un dominio acotado es una decisión documentada, no una casilla saltada.

Solución

# Production Readiness Review: `<Servicio / Feature>`

> Revisor: ______ | Fecha: ______ | Estado: Aprobado / Condicional / Rechazado
> Dueño del servicio: ______ | Equipo: ______ | Target de release: ______

---

## 1. Definición del Servicio

- [ ] El propósito del servicio está documentado y entendido por ingenieros de on-call
- [ ] El tier de servicio está definido (1 / 2 / 3) y coincide con requerimientos operacionales
- [ ] El documento de ownership de servicio está completo y accesible
- [ ] Las dependencias (upstream y downstream) están documentadas
- [ ] La clasificación de datos está definida (Público / Interno / Confidencial / Restringido)

## 2. Arquitectura y Calidad de Código

- [ ] La arquitectura fue revisada y aprobada por un ingeniero senior o arquitecto
- [ ] El código sigue estándares del equipo (linting, formato, cobertura de tests)
- [ ] No hay vulnerabilidades de seguridad conocidas en dependencias (escaneadas en 30 días)
- [ ] Los secretos se manejan vía secret manager, no hardcodeados ni en archivos de config
- [ ] No hay puntos únicos de falla sin mitigaciones documentadas

## 3. Testing

- [ ] La cobertura de unit tests está por encima del mínimo del equipo (usualmente 70-80%)
- [ ] Los integration tests cubren dependencias externas y caminos críticos
- [ ] Los load tests confirman que el servicio maneja el tráfico pico esperado
- [ ] Los chaos o failure injection tests verifican degradación controlada
- [ ] Los end-to-end tests cubren el recorrido completo del usuario donde aplica

## 4. Observabilidad

- [ ] Se emiten métricas para tasa de requests, errores y duración (RED)
- [ ] Los logs son estructurados, correlacionados con trace IDs y consultables
- [ ] El distributed tracing está configurado para requests entre servicios
- [ ] Existen dashboards para salud del servicio y métricas clave de negocio
- [ ] Las reglas de alertado están configuradas con severidad y umbrales apropiados
- [ ] Los ingenieros de on-call pueden distinguir entre síntomas y causas

## 5. Confiabilidad y Resiliencia

- [ ] Existe endpoint de health check y es usado por load balancers
- [ ] Circuit breakers o bulkheads protegen contra fallas en cascada
- [ ] Timeouts y retries están configurados para llamadas externas
- [ ] Rate limiting está en marcha para endpoints públicos o de socios
- [ ] Las conexiones a base de datos están pooleadas y acotadas
- [ ] El servicio degrada de forma controlada cuando dependencias fallan

## 6. Despliegue y Release

- [ ] Existe pipeline CI/CD y está verde
- [ ] Los deploys son automatizados; no se requieren cambios manuales en producción
- [ ] Canary o staged rollout está configurado para servicios de alto tier
- [ ] Feature flags están disponibles para cambios riesgosos o irreversibles
- [ ] Las migraciones de base de datos son compatibles hacia atrás o tienen rollback probado
- [ ] El procedimiento de rollback está documentado y probado en los últimos 30 días

## 7. Seguridad

- [ ] Autenticación y autorización están implementadas correctamente
- [ ] Validación y sanitización de inputs protegen contra ataques de inyección
- [ ] Encriptación en tránsito (TLS 1.2+) está forzada
- [ ] Datos sensibles están encriptados en reposo
- [ ] Revisión de seguridad completada para cambios de auth, pagos o manejo de datos
- [ ] Resultados de pentest o security scan revisados y remediados

## 8. Datos y Estado

- [ ] Cambios de esquema de base de datos fueron revisados por impacto en rendimiento
- [ ] Backups están configurados y probados (restore verificado en 90 días)
- [ ] Políticas de retención de datos están documentadas y aplicadas
- [ ] Requerimientos GDPR / CCPA / compliance se cumplen para datos de usuarios
- [ ] Scripts de migración son idempotentes y reversibles donde sea posible

## 9. Documentación

- [ ] El README explica cómo construir, testear y ejecutar el servicio localmente
- [ ] La documentación de API está actualizada (OpenAPI / Swagger / equivalente)
- [ ] Existen runbooks para: deploy, rollback, incidentes comunes y escalamiento
- [ ] El documento de handoff de on-call está actualizado con cambios y riesgos recientes
- [ ] Los ADRs cubren decisiones de diseño mayores

## 10. Preparación Operacional

- [ ] La rotación de on-call está cubierta y entrenada en este servicio
- [ ] Las alertas de paging llegan a las personas correctas con contexto útil
- [ ] La ruta de escalamiento está documentada y los contactos verificados
- [ ] Los runbooks fueron probados por alguien que no escribió el servicio
- [ ] Los pasos de verificación post-deploy están definidos y automatizados donde sea posible

---

## Notas de Revisión

| Item | Hallazgo | Riesgo | Mitigación / Acción | Responsable | Fecha límite |
|------|----------|--------|---------------------|-------------|--------------|
| ______ | ______ | Alto / Medio / Bajo | ______ | ______ | ______ |

## Sign-Off

| Rol | Nombre | Fecha | Firma (aprobar / bloquear) |
|-----|--------|-------|---------------------------|
| Dueño de ingeniería | ______ | ______ | ______ |
| Product owner | ______ | ______ | ______ |
| Revisor de seguridad | ______ | ______ | ______ |
| SRE / Plataforma | ______ | ______ | ______ |

Explicación

Los diez dominios mapean a las formas en que los servicios realmente fallan: errores no detectados (observabilidad), sin vuelta atrás (despliegue), defaults inseguros (seguridad) y el lado humano del que nadie piensa hasta las 3 AM (preparación operacional). Cada dominio tiene checkboxes concretas verificables con evidencia, no con intenciones.

El modelo de sign-off importa tanto como la checklist: cuatro aprobaciones distintas evitan el “me parece bien” de un revisor que también es el autor. El camino condicional es deliberado — un PRR que solo produce “no” se convierte en una puerta que los equipos rodean; uno que produce mitigaciones rastreadas se convierte en hábito.

Ejemplo de PRR Completado

# PRR: Servicio de Notificaciones en Tiempo Real

## Servicio
- Nombre: notification-service
- Tipo: Microservicio (Go)
- Tier: 1 (Crítico para experiencia de usuario)
- Fecha de revisión: 2026-07-11

## Hallazgos de Revisión

| Item | Hallazgo | Riesgo | Mitigación | Responsable | Fecha |
|------|----------|--------|------------|-------------|-------|
| Observabilidad | No hay dashboard de WebSocket | Medio | Crear dashboard antes de lanzar | alice | 2026-07-15 |
| Alertas | No hay alerta para conexiones rechazadas | Alto | Agregar alerta antes de lanzar | bob | 2026-07-14 |
| Seguridad | Validación JWT sin test de expiración | Alto | Agregar test antes de lanzar | carol | 2026-07-14 |
| Documentación | No existe runbook de rollback | Medio | Escribir runbook antes de lanzar | alice | 2026-07-16 |
| Operacional | On-call no entrenado en WebSocket | Medio | Sesión de capacitación | platform | 2026-07-18 |

## Sign-Off

| Rol | Nombre | Fecha | Decisión |
|-----|--------|-------|----------|
| Dueño de ingeniería | alice | 2026-07-18 | Aprobar condicional |
| Product owner | dave | 2026-07-18 | Aprobar |
| Revisor de seguridad | carol | 2026-07-18 | Aprobar (test agregado) |
| SRE / Plataforma | bob | 2026-07-18 | Aprobar condicional |

## Decisión
Aprobado condicionalmente. Lanzamiento permitido después de
completar los 3 items de riesgo Alto (alertas, seguridad, test).
Items de riesgo Medio rastreados con fechas límite pero no
bloquean el lanzamiento.

Plantilla companion: el repo companion de production-readiness-review-template tiene la checklist en blanco y este ejemplo rellenado como archivos Markdown descargables.

Variantes

Contexto	Ajustes	Notas
Release de app mobile	Agregar revisión de app store, porcentaje de rollout y monitoreo con crashlytics	Los releases mobile son más difíciles de revertir
Plataforma de datos / pipeline	Agregar checks de calidad de datos, plan de evolución de esquema y evaluación de impacto a consumidores	Los cambios de datos afectan a equipos downstream silenciosamente
Integración de terceros	Agregar revisión de SLA de vendor, términos de contrato y comportamiento de fallback	No controlas el upstream
Lanzamiento crítico de seguridad	Requerir revisión de seguridad obligatoria y sign-off del equipo de seguridad	Auth, pagos y datos de salud
Promoción de herramienta interna	Reducir requerimientos de observabilidad y on-call; enfocarse en documentación y soporte	Las herramientas internas tienen estándares operativos diferentes

Lo Que Funciona

1. Corre el PRR temprano. No esperes al día antes del lanzamiento; identifica gaps mientras hay tiempo de arreglarlos
2. Hazlo una conversación, no una puerta. El objetivo es preparación, no papeleo; colabora en mitigaciones
3. Rastrea gaps explícitamente. Los items no marcados deberían tener responsable y fecha límite, no ser ignorados
4. Revisa periódicamente servicios existentes. Los servicios se desvían de la preparación con el tiempo; programa revisiones periódicas
5. Automatiza lo que puedas. Reportes de cobertura, scans de dependencias y checks de salud de deploy deberían alimentar el PRR automáticamente

Errores Comunes

1. Tratar el PRR como un evento único. La preparación para producción decae; programa re-revisiones para cambios mayores
2. Saltarse la prueba de rollback. Lo único peor que un mal deploy es no saber cómo deshacerlo
3. No involucrar a operaciones temprano. SREs y equipos de plataforma detectan restricciones que desarrolladores omiten
4. Marcar casillas sin verificar. “Tenemos monitoreo” no es suficiente; confirma que los dashboards son útiles y las alertas accionables
5. Olvidar el lado humano. Los ingenieros de on-call necesitan entrenamiento, no solo documentación; verifica que han recorrido los runbooks

Solución de Problemas de la Revisión

• Los revisores aprueban sin evidencia: la checklist se convierte en teatro. Exige un enlace o artefacto por casilla — dashboard URL, runbook, salida de test — y trata “lo tenemos” como no marcado.
• El sign-off se estanca por semanas: nadie quiere bloquear, así que nadie firma. Pon una fecha límite de respuesta (5 días hábiles es común) y escala a liderazgo de ingeniería cuando un firmante se queda en silencio.
• Los hallazgos se acumulan sin responsables: una lista de gaps sin nombres es una lista de deseos. Cada fila de Notas de Revisión necesita responsable y fecha límite antes de que termine la reunión, o no cuenta como rastreada.
• El PRR se convierte en sello automático: cuando cada revisión termina en “aprobado” el proceso ha decaído. Rota revisores periódicamente y compara hallazgos entre servicios para calibrar.
• Los pases condicionales nunca se cierran: llega el día del lanzamiento, las mitigaciones no. Mete los hallazgos en el issue tracker — no en un doc que nadie abre — y revísalos en los límites de sprint.

Lectura Adicional

• Plantilla de handoff de on-call — el prerrequisito que espera la sección de preparación operacional.
• Plantilla de comunicación de incidentes — para la ruta de escalamiento que la revisión pide documentar.
• Guía de blue-green deployment — una de las estrategias de rollback que verifica el dominio de despliegue.
• Plantilla de forecast de capacity planning — de donde salen los objetivos de load tests.

Notas de Producción

• Re-revisa en calendario. Tier 1 anualmente, Tier 2 cada 18 meses, Tier 3 cada dos años — la preparación decae lo notes o no.
• Dispara revisiones fuera de ciclo ante cambios de dueño, refactors grandes, migraciones o un SEV1 que exponga un gap operacional.
• Alimenta la checklist con automatización. Reportes de cobertura, scans de dependencias y checks de salud de deploy pueden pre-rellenar la mitad de los dominios antes de la sesión.
• Mantén un registro. Una línea por revisión — servicio, fecha, resultado, hallazgos abiertos — es la pista de auditoría que compliance pide después.

Puntos Clave

• Un PRR responde una sola pregunta: ¿puede alguien distinto del autor operar esto de forma segura? Cada casilla sirve a eso.
• La evidencia vence a la intención — una casilla marcada necesita un enlace, un runbook o un test detrás.
• El pase condicional es lo que hace sostenible el proceso: lanza el release, rastrea los gaps.
• Las revisiones son por servicio y por cambio, no de una vez — la preparación se pudre entre revisiones.

Errores Comunes en Producción

• Saltarse el requisito de evidencia cuando “todos conocen el servicio” — el próximo revisor no lo conocerá.
• Escribir el PRR la noche antes del lanzamiento, así cada gap se vuelve emergencia o encoger de hombros.
• Archivar la revisión donde el on-call nunca mira — un runbook que no encuentras no existe.
• Copiar el último PRR con hallazgos viejos; cada revisión necesita verificación fresca.
• Dejar los hallazgos en el doc en vez del issue tracker — trabajo sin asignar es trabajo sin terminar.
• Tratar “aprobado condicional” como aprobado; las condiciones tienen responsables y fechas por algo.