RFC / CAB
Gobierno de pasos a producción para que cada cambio sea validado, autorizado, ejecutado de forma controlada, monitoreado y cerrado con evidencia.
Qué es RFC / CAB
El RFC es la solicitud formal que da trazabilidad al cambio. El CAB es la instancia de revisión y autorización que valida riesgo, evidencia, ventana, rollback, impacto, comunicación y responsables antes del paso a producción.
RFC como punto de entrada
Todo cambio productivo debe iniciar con una solicitud formal, clasificación de riesgo y relación con el requerimiento o ticket correspondiente.
CAB como control de decisión
El CAB revisa alcance, impacto, dependencias, QA, UAT, evidencias, plan de despliegue, rollback y criterios de Go / No-Go.
Producción con hypercare
El despliegue no termina al publicar. Debe existir monitoreo, evidencias, seguimiento, soporte N1/N2 y cierre formal posterior.
Seis principios inquebrantables
Reglas simples para asegurar control, trazabilidad y reversibilidad en cada paso a producción.
Tipos de cambio
El nivel de control depende del riesgo, impacto y urgencia.
Estándar
Riesgo: Bajo, repetible e impacto acotado.
Requisitos: QA y validación TPO.
Go / No-Go: CAB.
Normal
Riesgo: Medio, impacto funcional relevante.
Requisitos: QA + regresión, UAT y aceptación de negocio.
Go / No-Go: CAB.
Crítico
Riesgo: Alto impacto, continuidad operacional o Core.
Requisitos: Auditoría previa, QA exhaustivo, UAT y aceptación formal.
Go / No-Go: CAB.
Emergente
Riesgo: Incidente crítico o riesgo inminente.
Requisitos: Ejecución inmediata y regularización documental.
Go / No-Go: Gerencia TI / Subgerencia.
Proceso de paso a producción
El flujo ordena desde la solicitud hasta el cierre posterior al despliegue.
Árbol de decisión RFC
El PM o líder de proyecto analiza impacto y riesgo para clasificar el cambio en uno de los cuatro flujos.
Flujo EstándarRoles: PM, QA, DevOps. Aprobación: CAB.
Flujo NormalRoles: Dev, QA, Usuario, PM, Negocio. Aprobación: Negocio + CAB.
Flujo CríticoRoles: Dev Senior, QA Lead, Comité TI, DevOps. Aprobación: Comité TI + CAB.
Flujo EmergenteRoles: DevOps, Equipo TI, QA. Aprobación: On-call / Gerencia TI / Subgerencia.Ventanas de mantenimiento
El calendario depende del impacto del cambio y de la criticidad del sistema.
RACI resumido
Roles mínimos para asegurar ownership, aprobación y comunicación.
| Etapa | Líder Des. | Líder Pro. | QA | Negocio | Infra/DevOps | CAB | Gerente TI | Soporte |
|---|---|---|---|---|---|---|---|---|
| RFC & Clasificación | R | A | C | C | C | I | I | I |
| Desarrollo | R | A | I | I | C | I | I | I |
| QA / UAT | C | A | R | R | C | I | I | I |
| Evidencias | R | A | R | I | C | I | I | I |
| Go / No-Go | C | R | C | C | C | A* | I* | I |
| Despliegue | I | A | I | I | R | I | I | C |
R = Responsable · A = Accountable · C = Consultado · I = Informado. En cambios emergentes la aprobación fuera de CAB corresponde a Gerencia TI.
Checklist pre-CAB
- ✓RFC completo y clasificado.
- ✓Ticket CTS aprobado.
- ✓QA / UAT y evidencias consolidadas.
- ✓Rollback validado.
- ✓Traspaso de conocimiento a N2 / Operaciones.
- ✓Ventana, responsables y plan de monitoreo confirmados.
Control sin burocracia
El CAB no busca frenar el delivery: busca que producción sea predecible, reversible, medible y alineada al negocio.
Portlets principales
Accesos permanentes a documentación, dashboards, cambios, arquitectura y soporte.