Gemini Bucle de Hardening Post-Incidente

Referencias oficiales: Get Started · CLI Commands · Sub-agents · Skills

Por qué importa este bucle

Un incidente puede resolverse en horas y repetirse la semana siguiente. El hardening es el bucle que evita la recurrencia.

Ventanas de hardening

Ventana	Prioridad	Resultado obligatorio
0–24h	preservar calidad de evidencia	timeline + decisiones por lane
24–72h	bloquear el fallo dominante	1 guardrail automatizado + 1 prueba de regresión
3–14d	fortalecer el contrato operativo	actualización de runbook/proceso + verificación de adopción

Buckets del backlog de control

Detección: reglas de alerta, visibilidad de triage, ruteo de ownership
Prevención: checks de política, checks estáticos, cobertura de pruebas
Recuperación: confiabilidad de rollback, plantillas de handoff, mapas de escalación

Cada ítem necesita owner, fecha límite y condición de verificación.

Arquitectura de lanes

Lane de controles: guardrails y enforcement de políticas
Lane de calidad: regresión y mejoras de reproducibilidad
Lane de operaciones: actualización de runbook/comunicación

Evita colisiones en archivos compartidos salvo que haya merge owner explícito.

Scorecard de confiabilidad

Registra 0/1 por control:

clase raíz cubierta por pruebas
rehearsal de rollback completado
ownership de escalación documentado
alertas/dashboard ajustados
runbook actualizado + confirmado

5/5 es ideal. 4/5 es el umbral mínimo para cierre.

Gate de cierre

Cierra hardening solo cuando:

se alcanza el umbral del scorecard
los controles están activos en el flujo real
owners de seguimiento confirman adopción
no queda acción de alto riesgo sin resolver

Bundle de evidencia

Guarda un bundle de cierre:

id del incidente + resumen corto
controles implementados
enlaces de evidencia de pruebas
referencias de diff de runbook
owners + fechas de acciones residuales

Anti-patrones avanzados

“Ya arreglamos producción”

Arreglar producción es recovery, no hardening.

Controles sin ownership

Un guardrail sin owner se degrada sin aviso.

Cierre sin evidencia de adopción

Si el equipo no usa el cambio, el riesgo permanece.

Checklist rápido

Antes de cerrar:

1 control automatizado mergeado
1 prueba de regresión mergeada
actualización de runbook compartida
adopción por owners registrada

Gemini CLI acelera la recuperación. El hardening vuelve confiable esa velocidad.

Matriz de priorización de hardening

Prioriza acciones con dos ejes:

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

Banda	Reducción de riesgo	Velocidad de adopción	Acción típica
P0	alta	rápida	policy check bloqueante, gate de validación de rollback
P1	alta	media	suite de regresión por clase raíz
P2	media	rápida	mejoras de runbook y plantillas de handoff
P3	media/baja	lenta	limpieza estructural

Cierra P0/P1 antes de optimizar redacción.

Diseño de experimentos de hardening

Gestiona cada acción como experimento:

Hipótesis: "Si añadimos X, la clase Y baja Z%."
Medida: métrica + ventana de observación.
Guardrail: condición de rollback del propio control.
Owner: uno de ejecución y otro de verificación.
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)

Dimensión	0	1	2
Claridad	vaga	parcial	precisa con límites
Evidencia	nula	visual parcial	comandos/logs enlazados
Ownership	ausente	un owner	owner+verifier+fecha
Adopción	no verificada	anecdótica	observada en flujo real
Impacto	desconocido	asumido	medido en tendencia

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

Tipo de hallazgo	Control candidato	Estilo de verificación
detección fallida	regla de alerta + ruteo	replay sintético de alertas
decisión tardía	SLA de checkpoint + script de commander	auditoría de tiempos de simulacro
recuperación lenta	gate de rehearsal de rollback	rollback cronometrado
regresión repetida	harness de pruebas + policy check	tendencia de suite de regresión

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.

Tipo de control	Horizonte de mejora	Costo operativo	Uso recomendado
Gate de policy bloqueante	inmediato	medio	fallos repetidos de alta severidad
Expansión de suite de regresión	corto/medio	medio/alto	recurrencia por clase raíz
Mejora de runbook/plantillas	corto	bajo	ambigüedad de ownership
Simplificación arquitectural	medio/largo	alto	cadenas de fallo complejas crónicas