Política de Excepciones Técnicas
1. Objetivo
Permitir excepciones solo cuando sean estrictamente necesarias, con riesgo explícito, aprobación formal y fecha de caducidad.
2. Alcance
Aplica a excepciones de:
- Documentación obligatoria (RFC/ADR/changelog/runbook).
- Calidad (tests, cobertura, contratos).
- Seguridad (controles mínimos, secretos, hardening).
- Operación (SLO/alertas/observabilidad).
3. Reglas obligatorias
- Ninguna excepción puede ser indefinida.
- Toda excepción requiere
owner, riesgo, mitigación y fecha de cierre. - Toda excepción P0/P1 requiere aprobación del Tech Lead.
- Excepciones de seguridad/compliance requieren además aprobación de Security o PO.
4. Formato de solicitud
| Campo | Descripción |
|---|---|
| ID excepción | EXC-YYYY-### |
| Sistema/Módulo | Servicio o producto impactado |
| Regla afectada | Norma que no se cumple |
| Justificación | Motivo concreto y verificable |
| Riesgo | Bajo / Medio / Alto |
| Mitigación temporal | Controles compensatorios |
| Owner | Responsable de cierre |
| Fecha límite | Máximo 30 días calendario |
| Aprobadores | Tech Lead, PO y/o Security |
5. Flujo de aprobación
6. Renovación y cierre
- Renovación permitida solo 1 vez y con nueva justificación.
- Si no se cierra en fecha, se escala a comité de gobernanza operativa.
- Excepciones vencidas bloquean nuevos releases del módulo afectado.
7. KPIs de control
| KPI | Meta |
|---|---|
| Excepciones vencidas | 0 |
| Excepciones sin owner | 0 |
| Excepciones con plan de cierre validado | 100% |
| Tiempo promedio de cierre | <= 30 días |