Playbooks de operaciones

1) Qué es un playbook y en qué difiere de un runbook

Runbook es una instrucción lineal paso a paso para una operación/alerta tipo («haz una vez, dos, tres»).
El playbook es un árbol de soluciones para escenarios con horquillas: diferentes síntomas → diferentes hipótesis → diferentes ramas de acción. Incluye criterios de selección, condiciones de puerta y ramas fallback.
El propósito del playbook es reducir el MTTA/MTTR y el nivel de improvisación en la incertidumbre.

2) Donde se necesitan los playbooks en primer lugar

Incidentes: caída de SLO (availability/latency/success), fracaso de SLI empresarial (conversión/éxito de pago).
Cambios: lanzamientos, migraciones, banderas de fichas, confecciones (canary/rollback).
Ventanas de servicio: actualizaciones de BD/corredores, rotaciones de certificados.
Proveedores: PSP/KYC/CDN/IDP - degradación y swich over.
Seguridad: clave comprometida, actividad sospechosa.
DataOps: caducidad de la frescura, deriva del esquema, degradación de la paipline.

3) Estándares de Playbook (composición mínima)

1. Tarjeta: ID, Versión/Fecha, Propietario (equipo/rol), Servicios/regiones/tenantes, Políticas/estándares relacionados.
2. Objetivo y condiciones de inicio: qué SLO/SLI protegemos, qué alertas/disparadores son aplicables.
3. Síntomas ↔ Hipótesis: tabla de correspondencias, cómo cortar las hipótesis incorrectas rápidamente.
4. Árbol de soluciones: bifurcaciones, puertas de seguridad, criterios de parada/continuación.
5. Acciones: bloques paso a paso con comandos/enlaces a runbook 'y.
6. Comunicaciones: plantilla de apdate (Impakt→Diagnostika→Deystviya→Sled. apdate), canales y frecuencias.
7. Back/folback: plan de backout claro, límites y bandera de degradación UX.
8. Criterios de finalización: métricas, ventanas de observación temporal.
9. Evidence: qué guardar (registros, gráficos, capturas de pantalla, ID de tickets).
10. Historial de cambios: changelog, limitaciones conocidas.

4) Taxonomía de los playbooks (ejemplo de catálogo)

INC- - Incidentes (SLO/SLI, proveedores, infraestructura).
REL- - lanzamientos, retrocesos, confecciones/banderas.
MW - Ventanas de servicio (DB/queue/cert/OS).
SEC- - seguridad (accesos, claves, actividades sospechosas).
DATA- - frescura/calidad/circuitos.
PROV- - Proveedores externos (PSP/KYC/CDN/Email/SMS).

5) Ciclo de vida y posesión

1. Iniciación: según los resultados del incidente/simulación/cambio.
2. Borrador: autor = propietario del servicio; rugido: SRE/seguridad/datos (por dominio).
3. Piloto: tabletop/game-day; fijación del tiempo de paso y defectos.
4. Publicación: en repos (Docs-as-Code), versión, etiquetas, enlaces a dashboards.
5. Actualización: por RCA/CAPA, al menos una vez al trimestre; SLA de frescura.
6. Archivo/deprecación: cuando se reemplaza/pierde relevancia.

6) Integración con herramientas

Alert → Playbook: cada regla de Page hace referencia exactamente a un playbook básico.
ChatOps: '/play start <id> 'abre la tarjeta, registra la evidencia, pone los temporizadores de los apdates.
CMDB/catálogo: el servicio tiene una lista de playbooks relevantes, propietarios, SLO, dashboards.
GitOps: playbooks y runbook 'y viven en Git, pasan los rugidos de PR y los linderos.

7) Métricas de calidad de playbooks

Actionability: ≥ el 90% de los lanzamientos conducen a acciones específicas sin escalar «por desconocimiento».
Time-to-first-action: un minuto o dos desde Page hasta el primer paso significativo.
Cobertura:% de las alertas de página que tienen un playbook vinculado (objetivo 100%).
Freshness: la proporción de playbucks frescos es de 90 días.
Nota por defecto: comentarios sobre rugidos/simulaciones en 100 playbucks.
Reuse: cuántas veces se ha aplicado realmente el playbook (y a qué resultados ha dado lugar).

8) Anti-patrones

Una «enciclopedia de playbook» de 20 páginas sin árbol de soluciones.
Comandos sin expectativas de resultado («ejecutar X» - ¿y qué debe cambiar?).
No hay un plan de retroceso y los límites son el riesgo de que el problema se intensifique.
No se especifican los canales/intervalos de comunicación - aumento de los riesgos de PR.
Playbook sin propietario/fecha de actualización - nadie cree en su relevancia.
Docenas de playbooks similares en lugar de uno parametrizable.

9) Mini plantilla de playbook (idea YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Ejemplos terminados (fragmentos)

A) Pagos: «El proveedor se degrada en una región»

Síntomas: disminución de la success_ratio de la cohorte TR, crecimiento de los temporizadores PSP-A.
Soluciones: reducir el peso de PSP-A para TR, habilitar degrade-UX, reforzar los retiros con el presupuesto ≤ SLA, preparar la actualización del cliente.
Backout: recuperar los pesos con SLI verde 60 minutos.

B) DB: «Crecimiento p99 y connection errors»

Síntomas: p99↑, errores de conexión reset, crecimiento wait events.
Soluciones: habilite secuencias de comandos sólo read, limite la carga de escritura, escale la agrupación/réplicas y, si es necesario, haga failover en caliente.
Backout: reversión de parámetros, réplica prime.

C) Caché: «Miss rate ↑ carga → en la base de datos»

Síntomas: miss rate> 40%, aumento de la CPU DB.
Soluciones: equilibrar la política de eviction, aumentar la memoria/sharding, activar temporalmente la lectura a través de, restringir el RPS en las llaves calientes.
Backout: recuperar la política, volver a crear el shard problemático.

D) CDN: «Degradación regional de contenidos»

Síntomas: crecimiento latency/timeout en un país, quejas RUM.
Soluciones: cambiar el mapa de ruta/GSLB, eludir el POP problemático, reducir el TTL, habilitar el escudo de origen.
Commes: status-updates con geografía de influencia.

E) KYC: «El fracaso de las identificaciones»

Síntomas: caída de la tasa de approve, crecimiento de la vendor_error.
Soluciones: cambiar parte del tráfico a un proveedor alternativo, reducir el rigor de las reglas (dentro de la política), iniciar una revisión manual para VIP.
Compliance: registro de todos los cambios, notificaciones Risk/Legal si es necesario.

11) Comunicaciones (plantilla de apdate)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Lista de verificación del autor de playbook

• Objetivo especificado, propietarios, SLO/SLI y desencadenantes.
• Hay una tabla «Síntomas ↔ Hipótesis» y un árbol de decisiones.
• Pasos factibles con resultados esperados y gates de seguridad.
• backout/fallback y las condiciones de devolución están prescritas.
• Patrón de comunicaciones y frecuencia de los apdates.
• Enlaces a dashboards/alertas/búsquedas/tracks.
• La sección obligatoria de la evolución y los criterios de finalización.
• Versión, fecha, frescura SLA, historia de cambios.

13) Lista de verificación del revolver

• El playbook se reproduce en tabletop/game-day.
• Los pasos son seguros (límites/canario/auto-retroceso), los secretos no se revelan.
• Las funciones y las escaladas son claras; IC/Comms especificados.
• No hay duplicación con los playbooks adyacentes; parámetros emitidos.
• Está claro cuándo detener y pasar a fallback/rollback.
• El documento está disponible desde una alerta de 1 clic.

14) Parametrización y reutilización

Lleve las variables (región, proveedor, umbrales) a 'valores.'.
Los pasos comunes (por ejemplo, «reducir el peso del proveedor», «activar degrade-UX») se diseñan por separado runbook 'ami.
Mantenga los generadores de las plantillas: 'plb new --type = INC --service = payments'.

15) Hoja de ruta para la implementación (4-6 semanas)

1. El inventario de las alertas de Page → coincidir con cada playbook básico.
2. Plantillas: Aprobar la estructura YAML/Markdown, las hojas de comprobación y los linderos.
3. Los 5 escenarios principales (pagos/DB/CDN/KYC/caché) → escribir/volver a escribir en tabletop.
4. Integración: enlaces de alertas, comandos de ChatOps, bot de evidence.
5. Enseñanzas: mini-drill semanales de un playbook; AAR→uluchsheniya.
6. SLA de frescura y rugidos trimestrales; Informe de métricas de calidad.

16) Resultado

Los playbucks son escenarios operativos con bifurcaciones y barandillas que traducen el caos «¿y qué hacer?!» en una secuencia predecible de decisiones. Cuando los playbooks están estandarizados, integrados con alertas y entrenados regularmente, el equipo responde más rápido, los riesgos son controlados y el negocio ve la estabilidad y madurez de la operación.