Tu playbook de DevOps nativo para IA

Llevamos cinco artículos. SDD para el flujo. GOTCHA para el feedback. Modo tutor para el aprendizaje. Comparación honesta. Las ideas están todas ahí.

Ahora la última milla: ¿cómo lo pones todo en un playbook que tu equipo pueda usar el lunes? No un libro. No un framework de frameworks. Un archivo corto, con plantillas, métricas y reglas de decisión. Este artículo es ese archivo.

El Problema

Una caja de herramientas abierta sobre un banco de trabajo con las piezas de la serie desperdigadas alrededor — un documento de spec, un pergamino con un prompt GOTCHA, una learning note, un checklist pequeño, un gráfico de métricas. Un developer mira las piezas, tratando de averiguar cómo empaquetarlas — ilustración editorial plana

Conocimiento sin playbook es solo lectura.

He visto equipos leerse los mejores libros de DevOps, marcar cada post, ir a cada conferencia — y seguir trabajando igual el lunes. Porque el salto entre “entiendo esto” y “hago esto” es un playbook. Un artefacto corto, concreto, que vive en el repo y te dice exactamente qué hacer cuando se abre una PR, cuando hay un incidente, cuando entra un junior.

Un buen playbook tiene cuatro propiedades:

Cabe en una página
Enlaza a las plantillas pesadas, no las mete inline
Te dice cuándo aplicar cada pieza, no solo cómo
Está versionado con el código, no en Confluence

El equipo de QuantumAPI construyó el suyo a lo largo de 6 meses de prueba y error. Se quedaron con lo que funcionaba, tiraron lo que no. Lo que queda está abajo. Cópialo, ajústalo, entrega.

La Solución

Un diagrama limpio mostrando cuatro capas apiladas etiquetadas de abajo arriba: "Capa de rituales", "Capa de métricas", "Capa de plantillas", "Capa de decisión". Flechas laterales muestran dependencias — las decisiones dependen de las métricas, las métricas siguen a las plantillas, las plantillas habilitan los rituales — ilustración editorial plana

El playbook tiene cuatro capas, cada una responde una pregunta distinta:

Capa	Pregunta que responde	Artefacto
Decisión	¿Cuándo usamos qué framework?	Framework Selector
Plantillas	¿Cómo son cada uno de los artefactos?	Spec, prompt GOTCHA, learning note, postmortem
Métricas	¿Cómo sabemos que funciona?	DORA + específicas de IA
Rituales	¿Qué ceremonias se quedan? ¿Qué se van?	Lista keep/drop

Necesitas las cuatro. Plantillas sin decisiones se convierten en ceremonia. Métricas sin plantillas son adivinanzas. Rituales sin métricas son teatro.

Ejecutar

Capa 1 — Métricas (DORA + IA)

El equipo se quedó con las cuatro métricas DORA y añadió cuatro específicas de IA:

DORA clásica	Objetivo	Añadido específico de IA	Objetivo
Frecuencia de despliegue	Diario o más	PRs de IA mergeadas sin rework	> 70%
Lead time de cambios	< 1 día	Señal-a-ruido del review IA	> 80%
Tasa de fallo de cambios	< 15%	Incidentes trazables a código IA	Medir, no fijar objetivo
Tiempo medio de recuperación	< 1 hora	Cobertura de learning notes en PRs IA	> 90%

Las ocho son medibles desde Azure DevOps + Application Insights + datos del repo. Sin tooling nuevo.

Una regla: no persigas demasiado las métricas específicas de IA. Si aprietas “PRs IA sin rework” muy fuerte, los devs rechazarán código generado por IA que deberían haber usado. Las métricas son un termómetro, no un dashboard para hacer trampa.

Capa 2 — Plantillas (un archivo, referencias a todo)

El equipo creó un archivo: .ai/playbook.md. Es un índice, no un libro:

# AI-Native DevOps Playbook — Equipo QuantumAPI

## Antes de empezar una tarea
- Framework Selector → .ai/decisions/framework-selector.md
- Plantilla de spec → .ai/templates/spec.md
- Specs del sprint actual → specs/

## Durante el desarrollo
- Prompt GOTCHA de code review → .ai/review-prompt.md
- Prompt de learning note → .ai/learning-note-prompt.md
- Prompt de modo tutor → .ai/tutor-prompt.md

## Después de mergear
- Learning note por PR IA → .ai/learning-notes/<spec-id>.md
- Plantilla corta de postmortem → .ai/templates/postmortem.md

## Dashboards de métricas
- DORA → Azure DevOps Analytics
- Específicas de IA → workbook de Application Insights "AI Engineering"

## Quién posee qué
- Framework Selector: @tech-lead
- Prompts GOTCHA: @security-guild (revisados trimestralmente)
- Learning notes: quien mergea la PR
- Dashboards de métricas: @devops-lead

25 líneas. Cada enlace apunta a un archivo que ya está en el repo. Cuando entra un dev nuevo, se lo lee una vez. Cuando sale una duda en Slack, la respuesta es “mira .ai/playbook.md”.

Todas las plantillas reales viven en los artículos que las introdujeron:

Capa 3 — Rituales (qué se queda, qué se va)

Tras 6 meses, el equipo había probado 14 ceremonias distintas. Se quedaron con 4 y tiraron 10.

Se quedan:

Ritual	Frecuencia	Por qué
Tick de learning note en cada PR IA	Por PR	Transferencia de conocimiento al menor coste
Retro de IA (15 min)	Semanal	Los prompts caducan; aquí es donde se afinan
Auditoría de framework	Trimestral	¿Usamos SDD/GOTCHA/ATLAS donde ayudan?
Postmortem corto en incidentes con IA	Por incidente	Las learning notes lo bajan a 90min, no 2 días

Se van:

Ritual	Por qué se cortó
Recap diario de tareas IA en el standup	Ruido
Write-up ATLAS por PR	Overhead > beneficio por debajo de la escala de sprint
Spec para cada bug fix	Spec ceremony
Comité de aprobación de prompts	Bottleneck sin señal
Auditoría mensual de framework	Demasiado frecuente; trimestral es suficiente
Hueco obligatorio de “AI assistant” en 1:1	Performativo

La lista de “se quedan” es corta a propósito. Cada ritual cuesta foco. El listón para mantener uno es: ¿produce esto información que el equipo use?

Capa 4 — El estado final del equipo de QuantumAPI

Una pantalla de dashboard limpia mostrando métricas — "Frecuencia de despliegue: 12/día", "Lead time: 4h", "Tasa de fallo: 3%", "PRs IA sin rework: 78%", "Bus factor en código IA: 3,2", "Juniors debugeando código IA solos: 75%". Iconos del equipo alrededor del dashboard con cara de concentrados, no celebrando — ilustración editorial plana

Tras 6 meses ejecutando el playbook:

Métrica	Baseline (Artículo 1)	Tras el playbook
Frecuencia de despliegue	1/día	12/día
Lead time	2 días → 6 días (IA roto)	4 horas
Tasa de fallo de cambios	10% → 30% (IA roto)	3%
PRs IA mergeadas sin rework	—	78%
Señal-a-ruido del review IA	14%	87%
Incidentes trazables a código IA	5/mes	1/mes
Bus factor en código escrito por IA	1	3,2
Juniors debugeando código IA solos	10%	75%

Fíjate qué pasó. El lead time empeoró cuando se añadió IA sin estructura, de 2 días a 6. Tras el playbook está en 4 horas. Esa brecha de 36x entre “IA con estructura” e “IA sin estructura” es la historia entera de esta serie.

Lo que NO está en el playbook (y por qué)

Ningún consejo de gobierno de IA. Se probó. Se convirtió en bottleneck sin valor medible. El security guild posee los prompts GOTCHA para dominios de alto riesgo. Listo.
Ningún SLA para el review de IA. El pipeline ya lo ejecuta en 70 segundos. Un SLA sería ceremonia sobre un sistema que funciona.
Ningún comité de aprobación de prompts. Los prompts viven en el repo. Pasan por code review como todo lo demás.
Ninguna métrica separada de “uso de IA” en las revisiones de performance. La IA es una herramienta. La performance va de resultados.

Cada uno se probó y se tiró. El hilo común: si una ceremonia no produce información que el equipo use, córtala. Los anti-patrones del Artículo 5 — Framework Tower, Checklist Theatre, Spec Ceremony — siempre están esperando para volver.

Plantilla

Copia esto en .ai/playbook.md en tu repo hoy:

# AI-Native DevOps Playbook — <tu equipo>

## Antes de empezar una tarea
- Framework Selector → .ai/decisions/framework-selector.md
- Plantilla de spec → .ai/templates/spec.md
- Specs del sprint actual → specs/

## Durante el desarrollo
- Prompt GOTCHA de code review → .ai/review-prompt.md
- Prompt de learning note → .ai/learning-note-prompt.md
- Prompt de modo tutor → .ai/tutor-prompt.md

## Después de mergear
- Learning note por PR IA → .ai/learning-notes/<spec-id>.md
- Plantilla corta de postmortem → .ai/templates/postmortem.md

## Métricas
- DORA: frecuencia despliegue, lead time, tasa fallo, MTTR
- IA: PRs mergeadas sin rework, señal-a-ruido del review,
  incidentes trazables a IA, cobertura de learning notes

## Rituales
Se quedan: tick de learning note en cada PR IA, retro IA de 15 min
semanal, auditoría de framework trimestral, postmortem corto en
incidentes con IA.
Se van: todo lo demás.

## Quién posee qué
- Framework Selector: <rol>
- Prompts GOTCHA: <rol o guild>
- Learning notes: quien mergea la PR
- Dashboards de métricas: <rol>

Ajusta los dueños. Rellena los enlaces a medida que los crees. Ese es todo el playbook.

El Reto

Esta semana: crea .ai/playbook.md en tu repo. Aunque sea un esqueleto vacío. Que el archivo exista es lo que convierte las ideas en hábito. La semana que viene: rellena una sección. La siguiente: otra. En 6 semanas tienes lo que tiene el equipo de QuantumAPI.

Una caja de herramientas ordenada cerrándose al final del día, todas las piezas de la serie en sus compartimentos — spec, prompt, learning note, checklist, gráfico de métricas — la mano de un developer cerrando la tapa, tranquilo y satisfecho. Tonos cálidos de atardecer — ilustración editorial plana

El DevOps Handbook cumplió 10 años este año. Los Tres Principios siguen en pie. La IA no los rompió. Amplificó lo que ya haces. Los equipos buenos con estructura entregan más rápido con IA. Los equipos sin estructura entregan deuda técnica vestida de esmoquin.

Ya tienes la estructura. Capa de decisión, plantillas, métricas, rituales. Un archivo en el repo. La parte difícil no es aprenderlo. La parte difícil es mantenerlo simple cuando llega el siguiente framework brillante.

Entrega bien.

Si esta serie te ayudó, considera patrocinarme en GitHub o invitarme a un café.

Esta es la parte 6 de 6 — el último artículo de la serie “Los Tres Principios en la Era de la IA”. Anterior: SDD, ATLAS, GOTCHA: cuándo usar cuál. Índice de la serie: Los Tres Principios en la Era de la IA.