Paquete de ventana de mantenimiento programado en retainer de soporte (con IA)

Un retainer de soporte paga por mantener sistemas sanos—not por sorprender al cliente con downtime. Cuando el trabajo es planificado (migración de base de datos, major de plugin, corte DNS, renovación TLS, lote de reglas firewall), necesitas un playbook de ventana de mantenimiento: horarios en la zona horaria del cliente, impacto esperado, disparadores de rollback, quién da go/no-go y checklist de verificación posterior. No es un P1 urgente (caída imprevista) ni una escalación a proveedor tercero (esperas fuera de tu control). Este pack cubre cambios programados que tú ejecutas con retainer activo.

Si te saltas el documento y confías en un Slack de “esta noche lo hacemos”, heredas la culpa cuando el checkout falla doce minutos—or cuando el cliente tiene junta de dirección en pleno corte. Un Brief de Ventana de Mantenimiento de una página más una secuencia corta en Gmail deja horas facturables, límites claros y el log de revisión mensual honesto.

Cuándo usar este pack (y cuándo no)

Úsalo cuando:

• Acordasteis un cambio planificado dentro del alcance del retainer (patch, paso staging→prod, rebuild de índices).
• Puede haber degradación acotada (solo lectura, colas lentas, 503 breve).
• Necesitas confirmación escrita antes de tocar producción.

No sustituye:

• Respuesta P1 en vivo — ver pack de incidente urgente.
• Proveedor externo — ver pack escalación terceros.
• Desarrollo nuevo fuera de alcance — deriva a solicitud de cambio.

Más guías en Guías.

Qué vas a entregar

1. Snapshot FACT / ASSUMPTION (ChatGPT) desde tickets, monitorización y notas de calendario.
2. Brief de Ventana de Mantenimiento (Google Doc): inicio/fin, impacto, rollback, verificación, política de horas.
3. Secuencia de tres emails Gmail: anuncio → recordatorio → cierre con all-clear (más go/no-go opcional).
4. Fila en el log de revisión mensual con enlace al doc y horas reales.

Herramientas: ChatGPT, Google Docs, Gmail.

Paso 1 — Snapshot del cambio con ChatGPT (FACT vs ASSUMPTION)

Pega un bloque sanitizado: texto del ticket, descripción de alertas, resumen de release notes y TZ del cliente. Pide etiquetar FACT (verificado) vs ASSUMPTION (confirmar antes de la ventana).

Prompt (copia y adapta):

Eres SRE senior redactando un brief de mantenimiento para cliente con retainer.

Entrada:
- Cambio: [ej. upgrade menor PostgreSQL en prod]
- TZ cliente: [Europe/Madrid]
- Ventana propuesta: [fecha/hora local + UTC]
- Dependencias: [CDN, workers, webhooks pago]

Tareas:
1) FACT vs ASSUMPTION en impacto, duración y rollback.
2) Tres disparadores de rollback medibles.
3) Checks de verificación post-ventana.
4) Señala lo que debería ir a CR en lugar de retainer.

Tono: calmado, concreto, sin marketing.

No pegues secretos ni datos personales sensibles. Si hay muchos ASSUMPTION, para y confirma con el cliente antes de agendar.

Paso 2 — Brief en Google Doc

Duplica tu plantilla de retainer. Secciones:

Sección	Contenido
Resumen	Una frase: qué cambia y por qué ahora
Ventana	Inicio/fin en hora local del cliente + UTC; responsable
Impacto usuario	Qué verán (errores, lentitud, banner solo lectura)
Rollback	Tres triggers + quién decide + tiempo máximo de revert
Verificación	Smoke tests ordenados
Comms	Quién recibe Gmail; espejo Slack/Teams si aplica
Horas	Qué incluye retainer vs top-up/CR
Ok	Checkbox: cliente aprueba ventana tal cual

Comparte en solo comentarios hasta el ok; luego solo lectura para el enlace de archivo en el email.

Paso 3 — Flujo en una vista

Paso 4 — Secuencia Gmail (lista para pegar)

Email 1 — Anuncio (≥72h antes, o mínimo contractual)

Asunto: [Retainer] Ventana mantenimiento planificada — [sistema] — [fecha local]

Hola [Nombre],

Programamos una ventana de mantenimiento para [sistema/cambio].

Ventana (tu hora): [inicio] – [fin] ([zona horaria])
Impacto esperado: [lenguaje claro]
Rollback: revertimos si [trigger 1/2/3]

Revisa el Brief y confirma antes de [fecha límite]:
[Enlace Google Doc]

Las horas incluidas cubren [X]. Lo demás requiere [top-up/CR] según acuerdo.

Responde "aprobado" o deja preguntas en el doc.

Gracias,
[Tu nombre]

Email 2 — Recordatorio (24h antes)

Confirma que la ventana sigue vigente, repite impacto y pide go/no-go si en su lado hay lanzamiento de campaña, nómina, etc.

Email 3 — All-clear (≤2h tras verificación)

Asunto: Completado: ventana mantenimiento — [sistema] — resumen

Viñetas: qué se desplegó, resultados de verificación, tickets de seguimiento, horas plan vs real.

Si revertiste, envía variante corta y enlaza retrospectiva post-incidente si el cliente pide RCA formal.

Paso 5 — Política de horas en la ventana

Escríbela en el doc para evitar renegociación en pleno corte:

• Incluido: snapshot, doc, comunicaciones, ejecución y verificación dentro de la ventana acordada.
• Extra: scope creep (“ya que estás, ¿puedes…?”), rollback largo, retrasos de terceros después de cerrar la ventana.

Ante extras, pausa y usa derivación fuera de alcance o recarga de horas—no absorbas una migración de seis horas como “parte del martes”.

Paso 6 — Ejecutar, verificar, registrar

Durante la ventana:

1. Estado de una línea en el canal acordado al inicio y fin (espejo Gmail para auditoría).
2. Checklist de verificación en orden; enlaza logs o capturas en el ticket.
3. Si salta un trigger de rollback, revertir antes de seguir depurando hacia delante.

Después, fila en la hoja de revisión mensual del retainer: fecha, id cambio, URL doc, horas plan/real, ok cliente (S/N). Alimenta el pack de revisión mensual.

Errores frecuentes

• Solo UTC en lo que ve el cliente—hora local primero.
• Sin go/no-go—silencio tras recordatorio = no aprobado.
• Sin verificación—“parece bien” no es checklist.
• Mezclar cambios—una ventana, una historia de rollback; lo extra va a CR.

Checklist rápido

• Snapshot FACT/ASSUMPTION guardado (sin secretos)
• Brief compartido; aprobación escrita capturada
• Tres Gmail enviados o programados
• Verificación hecha y enlazada en ticket
• Horas y URL doc en log mensual

El trabajo planificado merece comunicación planificada. Este pack mantiene el mantenimiento dentro del retainer para que las urgencias sigan siendo raras—and facturables cuando no lo sean.