Bucle de Hardening Post-Incidente en Codex — De la Recuperación a Controles Duraderos

Official References: Best Practices · Review · Worktrees · Automations

Por qué el hardening es un bucle separado

La respuesta a incidentes te devuelve a verde. El hardening define si te quedas en verde.

Trata hardening como un bucle dedicado, no como tarea de cierre opcional.

Modelo de timeline de hardening

Buckets del portafolio de control

Sigue acciones de hardening en:

• Controles de detección: ruteo de alertas, calidad de señal, claridad de dashboard
• Controles de prevención: pruebas, checks de política, salvaguardas estáticas
• Controles de recuperación: rehearsals de rollback, contratos de handoff, mapas de escalación

Cada acción necesita owner, fecha límite y evidencia de verificación.

Modelo de ejecución por lanes

• Lane de controles: implementa enforcement y automatización
• Lane de calidad: fija cobertura de regresión para la clase raíz
• Lane de operaciones: actualiza runbooks y protocolo de comunicación

Cuando varios lanes toquen archivos compartidos, asigna un merge owner único.

Scorecard de confiabilidad

Usa scoring binario por control:

• clase raíz cubierta por pruebas
• rollback rehearseado y cronometrado
• ownership de escalación documentado
• monitoreo/alertas actualizados
• runbook actualizado y confirmado por owners

Umbral mínimo de cierre: 4/5.

Gate de cierre de hardening

Hardening termina solo cuando:

• se alcanza el umbral del scorecard
• los controles están activos en flujo regular
• la adopción por owners está confirmada
• no queda seguimiento de alto riesgo sin resolver

Bundle de evidencia de cierre

Archiva un bundle con:

• id del incidente + resumen
• controles implementados
• enlaces de evidencia de pruebas
• diffs de runbook/proceso
• owners + fechas de acciones residuales

Anti-patrones avanzados

Declarar “recuperado” sin backlog de hardening

Esto asegura repetición del incidente.

Controles agregados pero no ejercitados

Controles no ensayados fallan bajo presión real.

Documentación actualizada sin contrato de ownership

Existe el documento, pero no existe responsabilidad operativa.

Checklist rápido

Antes de cerrar hardening:

• 1 control automatizado mergeado
• 1 prueba de regresión mergeada
• actualización de runbook/proceso publicada
• confirmaciones de ownership registradas

Codex ayuda a recuperar rápido. Hardening hace que la recuperación mejore con cada ciclo.

Matriz de priorización de hardening

Prioriza acciones con dos ejes:

• Magnitud de reducción de riesgo
• Tiempo hasta adopción operativa

Cierra P0/P1 antes de optimizar redacción.

Diseño de experimentos de hardening

Gestiona cada acción como experimento:

1. Hipótesis: "Si añadimos X, la clase Y baja Z%."
2. Medida: métrica + ventana de observación.
3. Guardrail: condición de rollback del propio control.
4. Owner: uno de ejecución y otro de verificación.
5. Fecha de revisión: fecha fija.

Ejemplo

• hipótesis: rehearsal obligatorio de rollback reduce varianza de MTTR SEV-1
• medida: p95 MTTR en próximos 4 incidentes/simulacros
• guardrail: si lead time empeora >20% en 2 ciclos, recalibrar gate

Ritmo operativo de ownership

Standup semanal de confiabilidad (20 min)

• revisar items vencidos
• revisar items sin evidencia sólida
• reasignar bloqueados en la sesión
• prohibir cierre sin enlace de evidencia

Auditoría mensual de controles

• validar que controles siguen activos
• validar owners vigentes
• retirar controles sin impacto medible

Rúbrica de calidad de hardening (0–2)

Mínimo de aprobación: 7/10. Si no, el loop sigue abierto.

Plantilla de backlog

### Hardening Item
- Incident reference:
- Failure class:
- Proposed control:
- Priority band: P0/P1/P2/P3
- Execution owner:
- Verifier owner:
- Due date:
- Evidence link(s):
- Adoption check date:
- Status: open | in_progress | verified | retired

Fallos comunes del programa

• se cierran items sin efecto en métricas
• se agregan controles sin socialización operativa
• se actualiza runbook pero no checklist on-call
• ownership queda en persona no disponible

Resuélvelo con auditoría mensual explícita.

Mapeo hallazgo → diseño de control

Este mapeo mantiene hardening concreto.

Plantilla sprint de hardening (14 días)

• Día 1–2: priorizar por riesgo y reversibilidad
• Día 3–5: implementar controles P0/P1
• Día 6–8: añadir cobertura de verificación y links
• Día 9–11: validar adopción en flujo real
• Día 12–14: publicar resumen + owners de riesgo residual

Si hay retraso, reduce alcance pero no recortes verificación.

Formato de registro de riesgo residual

### Residual Risk
- Risk statement:
- Why not fully solved yet:
- Temporary control in place:
- Trigger for re-prioritization:
- Owner:
- Target resolution date:

Riesgo residual sin trigger/fecha es riesgo sin gestión.

Marco económico de controles

Cada control de hardening tiene costo. Haz explícitos los trade-offs.

Prioriza primero mejor relación riesgo-reducción/esfuerzo.

Checklist de adopción

Un control no termina al merge.

• owners pueden ejecutarlo sin conocimiento implícito
• ruta de fallo del propio control documentada
• checklist on-call actualizado
• logs/dashboard prueban ejecución real del control

Control mergeado pero no usado = confianza falsa.

Gate QA de hardening

Antes de verified, exige:

1. evidencia de implementación (diff + salida de comandos)
2. evidencia de comportamiento (señal en simulacro/replay)
3. evidencia de ownership (signoff de owner + verifier)

Si falta uno, permanece in_progress.

Protocolo de retiro de controles

No todos los controles deben vivir para siempre.

Retira cuando:

• no mejora métricas objetivo
• duplica un control más fuerte
• costo operativo supera reducción de riesgo medida

Retirar requiere nota de reemplazo o justificación.

Secuenciación de rollout de controles

Despliega controles en tres fases:

1. Shadow mode — observar sin bloquear
2. Warn mode — exponer violaciones con ownership
3. Enforce mode — bloquear en condiciones de alto riesgo

Esto eleva seguridad sin romper operación abruptamente.

Score de adopción de hardening

Gestiona adopción con score 0–5:

• control habilitado en entorno objetivo
• owners entrenados y confirmados
• runbook actualizado con pasos ejecutables
• señal de dashboard confirma ejecución real
• al menos un incidente/simulacro usó el control

Menos de 4 significa adopción incompleta.

Ledger de deuda de confiabilidad

Mantén ledger dedicado para trabajo diferido:

Trabajo diferido sin fecha de revisión se vuelve riesgo permanente.