Plantilla de Production Readiness Review

Descripcion General

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

Cuando Usar

• For alternatives, see Blue-Green Deployment.

Usa esta plantilla cuando:

• Un nuevo servicio se despliega a produccion por primera vez
• Un feature o refactor mayor cambia como 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 auditoria requiere evidencia documentada de preparacion para produccion

Prerrequisitos

Antes de conducir un PRR:

• El servicio o feature esta completo en codigo y pasa todos los tests automaticos
• Existe un documento de ownership de servicio (o se creara como parte de esta revision)
• La rotacion de on-call esta definida y entrenada
• Existen runbooks para escenarios comunes de falla
• Un procedimiento de rollback ha sido probado en un ambiente no productivo

Solucion

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

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

---

## 1. Definicion del Servicio

- [ ] El proposito del servicio esta documentado y entendido por ingenieros de on-call
- [ ] El tier de servicio esta definido (1 / 2 / 3) y coincide con requerimientos operacionales
- [ ] El documento de ownership de servicio esta completo y accesible
- [ ] Las dependencias (upstream y downstream) estan documentadas
- [ ] La clasificacion de datos esta definida (Publico / Interno / Confidencial / Restringido)

## 2. Arquitectura y Calidad de Codigo

- [ ] La arquitectura fue revisada y aprobada por un ingeniero senior o arquitecto
- [ ] El codigo sigue estandares del equipo (linting, formato, cobertura de tests)
- [ ] No hay vulnerabilidades de seguridad conocidas en dependencias (escaneadas en 30 dias)
- [ ] Los secretos se manejan via secret manager, no hardcodeados ni en archivos de config
- [ ] No hay puntos unicos de falla sin mitigaciones documentadas

## 3. Testing

- [ ] La cobertura de unit tests esta por encima del minimo del equipo (usualmente 70-80%)
- [ ] Los integration tests cubren dependencias externas y caminos criticos
- [ ] Los load tests confirman que el servicio maneja el trafico pico esperado
- [ ] Los chaos o failure injection tests verifican degradacion graceful
- [ ] Los end-to-end tests cubren el journey completo del usuario donde aplica

## 4. Observabilidad

- [ ] Se emiten metricas para tasa de requests, errores, y duracion (RED)
- [ ] Los logs son estructurados, correlacionados con trace IDs, y consultables
- [ ] El distributed tracing esta configurado para requests cross-servicio
- [ ] Existen dashboards para salud del servicio y metricas clave de negocio
- [ ] Las reglas de alertado estan configuradas con severidad y umbrales apropiados
- [ ] Los ingenieros de on-call pueden distinguir entre sintomas 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 estan configurados para llamadas externas
- [ ] Rate limiting esta en place para endpoints publicos o de socios
- [ ] Las conexiones a base de datos estan pooleadas y acotadas
- [ ] El servicio degrada gracefulmente cuando dependencias fallan

## 6. Despliegue y Release

- [ ] Existe pipeline CI/CD y esta verde
- [ ] Los deploys son automatizados; no se requieren cambios manuales en produccion
- [ ] Canary o staged rollout esta configurado para servicios de alto tier
- [ ] Feature flags estan disponibles para cambios riesgosos o irreversibles
- [ ] Las migraciones de base de datos son compatibles hacia atras o tienen rollback probado
- [ ] El procedimiento de rollback esta documentado y probado en los ultimos 30 dias

## 7. Seguridad

- [ ] Autenticacion y autorizacion estan implementadas correctamente
- [ ] Validacion y sanitizacion de inputs protegen contra ataques de inyeccion
- [ ] Encripcion en transito (TLS 1.2+) esta forzada
- [ ] Datos sensibles estan encriptados en reposo
- [ ] Revision 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 estan configurados y probados (restore verificado en 90 dias)
- [ ] Politicas de retencion de datos estan documentadas y forzadas
- [ ] Requerimientos GDPR / CCPA / compliance se cumplen para datos de usuarios
- [ ] Scripts de migracion son idempotentes y reversibles donde sea posible

## 9. Documentacion

- [ ] El README explica como construir, testear, y ejecutar el servicio localmente
- [ ] La documentacion de API esta actualizada (OpenAPI / Swagger / equivalente)
- [ ] Existen runbooks para: deploy, rollback, incidentes comunes, y escalamiento
- [ ] El documento de handoff de on-call esta actualizado con cambios y riesgos recientes
- [ ] Los ADRs cubren decisiones de diseno mayores

## 10. Preparacion Operacional

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

---

## Notas de Revision

| Item | Hallazgo | Riesgo | Mitigacion / Accion | Dueno | Fecha limite |
|------|----------|--------|---------------------|-------|-------------|
| ______ | ______ | Alto / Medio / Bajo | ______ | ______ | ______ |

## Sign-Off

| Rol | Nombre | Fecha | Firma (aprobar / bloquear) |
|-----|--------|-------|---------------------------|
| Dueno de ingenieria | ______ | ______ | ______ |
| Product owner | ______ | ______ | ______ |
| Revisor de seguridad | ______ | ______ | ______ |
| SRE / Plataforma | ______ | ______ | ______ |

Explicacion

El PRR esta organizado en diez dominios que cubren el ciclo de vida completo de operar software en produccion. Cada dominio tiene checkboxes concretas que pueden verificarse objetivamente. La seccion de sign-off asegura que ninguna persona pueda declarar un servicio listo sin input de ingenieria, producto, seguridad, y operaciones. La tabla de notas de revision captura gaps que no son bloqueadores pero necesitan seguimiento.

Ejemplo de PRR Completado

# PRR: Servicio de Notificaciones en Tiempo Real

## Servicio
- Nombre: notification-service
- Tipo: Microservicio (Go)
- Tier: 1 (Critico para experiencia de usuario)
- Fecha de revision: 2026-07-11

## Hallazgos de Revision

| Item | Hallazgo | Riesgo | Mitigacion | Dueno | 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 | JWT validacion falta test de expiracion | Alto | Agregar test antes de lanzar | carol | 2026-07-14 |
| Documentacion | Runbook de rollback no existe | Medio | Escribir runbook antes de lanzar | alice | 2026-07-16 |
| Operacional | On-call no entrenado en WebSocket | Medio | Sesion de capacitacion | platform | 2027-07-18 |

## Sign-Off

| Rol | Nombre | Fecha | Decision |
|-----|--------|-------|----------|
| Dueno de ingenieria | 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 |

## Decision
Aprobado condicionalmente. Lanzamiento permitido despues de
completar los 3 items de riesgo Alto (alertas, seguridad, test).
Items de riesgo Medio rastreados con fechas limite pero no
bloquean el lanzamiento.

Variantes

Contexto	Ajustes	Notas
Release de app mobile	Agregar revision de app store, porcentaje de rollout, y monitoreo con crashlytics	Los releases mobile son mas dificiles de revertir
Plataforma de datos / pipeline	Agregar checks de calidad de datos, plan de evolucion de esquema, y evaluacion de impacto a consumidores	Los cambios de datos afectan a equipos downstream silenciosamente
Integracion de terceros	Agregar revision de SLA de vendor, terminos de contrato, y comportamiento de fallback	No controlas el upstream
Lanzamiento critico de seguridad	Requerir revision de seguridad obligatoria y sign-off del equipo de seguridad	Auth, pagos, y datos de salud
Promocion de herramienta interna	Reducir requerimientos de observabilidad y on-call; enfocarse en documentacion y soporte	Las herramientas internas tienen estandares operativos diferentes

Lo que funciona

1. Corre el PRR temprano. No esperes al dia del lanzamiento; identifica gaps mientras hay tiempo de arreglarlos
2. Hazlo una conversacion, no una puerta. El objetivo es preparacion, no papeleo; colabora en mitigaciones
3. Rastrea gaps explicitamente. Items no chequeados deberian tener duenos y fechas limite, no ser ignorados
4. Revisa trimestralmente servicios existentes. Los servicios se desvian de la preparacion con el tiempo; programa revisiones periodicas
5. Automatiza lo que puedas. Reportes de cobertura, scans de dependencias, y checks de salud de deploy deberian alimentar el PRR automaticamente

Errores Comunes

1. Tratar el PRR como un evento unico. La preparacion para produccion decae; programa re-revisiones para cambios mayores
2. Saltarse la prueba de rollback. Lo unico peor que un mal deploy es no saber como deshacerlo
3. No involucrar a operaciones temprano. SREs y equipos de plataforma detectan restricciones que desarrolladores omiten
4. Chequear casillas sin verificar. “tenemos monitoreo” no es suficiente; confirma que los dashboards son utiles y las alertas son útiles
5. Olvidar el lado humano. Los ingenieros de on-call necesitan entrenamiento, no solo documentacion; verifica que han corrido los runbooks

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de production y checklist para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de production readiness review cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.