Retainer de soporte: paquete rollback por despliegue fallido (con IA)

En un retainer de soporte, al cliente le da igual cómo despliegas—hasta el viernes a las 17:58, cuando una release deja el botón de pago en gris y explotan los tickets. Un despliegue fallido no siempre es caída total, pero se come horas del retainer si nadie anotó la versión anterior, el rollback es “ya lo vemos” y el cliente pasa noventa minutos sin noticias.

Este pack es para autónomos y agencias pequeñas que ya hacen la revisión mensual del retainer y saben montar una ventana de mantenimiento programado. No es el paquete de incidente urgente P1 ante un apagón sin causa clara, no es la retrospectiva post-incidente tres días después, y no es la degradación P2 “lento pero vivo”. Es la ruta cuando una release o cambio de configuración concreto explica la regresión y necesitas decisión de rollback escrita, pruebas de humo y cadencia en Gmail mientras corre el reloj del retainer.

Cuándo usar este pack

Úsalo cuando se cumplan todas estas condiciones:

• El retainer está activo y tienes acceso al flujo de despliegue (CI/CD, panel de hosting, registro de contenedores o repo de infra que sea del cliente).
• Los síntomas empezaron después de un deploy, migración o push de config que tú o el cliente disparasteis (la correlación temporal importa).
• Volver a la última build o config estable es realista dentro del alcance del retainer.
• El cliente necesita trazabilidad visible: qué se rompió, a qué versión volvisteis y cómo verificasteis la recuperación.

Si la causa es desconocida y la gravedad es crítica, empieza por el pack P1 y vuelve aquí cuando confirmes que el disparador fue una release. Si el cliente quiere funcionalidad nueva de la release rota, encamina el alcance extra por solicitud de cambio cuando vuelva la estabilidad.

Qué vas a entregar

1. Un Rollback Brief en Google Docs (una página): ID de release, versión buena anterior, pasos de rollback, checklist de humo y condiciones de parada.
2. Un memo de triage con ChatGPT separando HECHO vs SUPOSICIÓN sobre timing del deploy, firmas de error y radio de impacto.
3. Una secuencia de tres emails en Gmail: acuse → rollback en curso → estable verificado (o escalado si el rollback falla).
4. Una fila en la revisión mensual que enlace incidentes de deploy para que la renovación refleje riesgo de releases.

Paso 1 — Captura hechos antes de tocar producción

Pega un snapshot estructurado en ChatGPT (redacta secretos, tokens y datos personales):

Eres mi asistente de ops en retainer. Separa HECHO vs SUPOSICIÓN.

HECHOS que sé:
- Hora deploy (UTC): …
- Versión / commit / build ID: …
- Última versión estable: …
- Síntomas (errores, URLs, segmento usuarios): …
- Señales de monitorización: …

SUPOSICIONES a cuestionar:
- El artefacto de rollback sigue existiendo
- Las migraciones de BD son compatibles hacia atrás
- CDN/caché no sirve assets rotos

Salida: go/no-go rollback, top 3 pruebas de humo y frase de estado para cliente (2 oraciones).

Guarda la salida en el Brief bajo Triage. Si no puedes nombrar una versión buena, la siguiente hora facturable es descubrimiento—no pulsar Redeploy.

Paso 2 — Arma el Rollback Brief de una página (Google Docs)

Sección	Contenido
Disparador	Qué cambió (tag, config, feature flag)
Impacto	Quién sufre qué (checkout, admin, APIs)
Última buena	ID versión, fecha deploy, enlace changelog
Plan rollback	Pasos ordenados + responsable (tú vs DevOps cliente)
Pruebas humo	5 comprobaciones de flujos críticos
Parada / escalar	Cuándo abortar rollback y abrir P1 o proveedor
Comms	Horarios Gmail alineados al huso del cliente

Comparte el doc con acceso a comentarios para quien aprueba. Rollback sin ACK escrito es cómo el retainer absorbe scope sorpresa.

Paso 3 — Consigue un ACK rápido del cliente

Envía un Gmail breve (envía un humano, redacta la IA):

Asunto: [Cliente] — recomendamos rollback tras el deploy de hoy

Correlacionamos el deploy de hoy (build …) con [síntoma]. Recomendamos volver al build … estable el [fecha].

Responde “ACK rollback” o llama si preferís parchear hacia delante. Ventana estimada: … minutos. Haremos humo en checkout y … antes del todo claro.

Si eligen parchear, documenta la decisión en el Brief y trata la ingeniería extra como fuera de alcance o CR salvo que el retainer incluya release engineering.

Paso 4 — Ejecuta rollback con time box

1. Congela nuevos deploys (bloquea pipeline o rama—queda en el Brief).
2. Rollback por la vía habitual del cliente (revert commit, redeploy artefacto anterior, apaga feature flag).
3. Purga cachés si CDN o estáticos pueden servir la build rota.
4. Humo en producción según el Brief (no solo staging).
5. Registra timestamps de cada paso—facturación y RCA los necesitan.

Time box de 90 minutos. Si el rollback no restaura flujos core, escala con el pack de incidente urgente y anota si un SaaS bloquea el camino.

Paso 5 — Cadencia Gmail (tres emails)

#	Cuándo	Objetivo
1	≤15 min desde la decisión	Acuse + enlace al plan
2	Rollback iniciado	ETA + qué estás probando
3	Humo en verde	Todo claro + Brief actualizado

Tono factual—sin culpar al dev del cliente que pulsó deploy. Tu trabajo es estabilidad y trazabilidad.

Paso 6 — Alimenta la revisión mensual

Añade una fila al log del retainer:

Mes	Incidente	Release	¿Rollback?	Seguimiento
…	Deploy checkout roto	v… → v…	Sí	Gate humo pre-prod

Esa fila reduce tickets recurrentes crónicos tras el próximo tren de releases.

Errores habituales

• Rollback sin versión buena nombrada — adivinas, no operas.
• Olvidar purgar caché — el usuario sigue viendo el JS roto.
• Rollback en silencio — el cliente se entera por usuarios finales.
• Héroe parcheando en horas de retainer — scope creep sin CR.

Checklist rápido

• Timestamp deploy correlaciona con síntomas
• Versión buena documentada
• ACK cliente por escrito
• Humo OK en producción
• Tres Gmail enviados
• Fila revisión mensual actualizada

Junto con renovación SSL y ventanas de mantenimiento, este pack evita que releases previsibles conviertan el retainer en imprevisible.