Ventanas de servicio

1) ¿Qué es una «ventana de servicio» y por qué se necesita

Ventana de servicio: intervalo de tiempo preconcebido para trabajos que puedan afectar a la disponibilidad/rendimiento. El objetivo es un cambio controlado con un riesgo predecible, comunicación transparente e informes probatorios.

• Planeado (planificado): lanzamientos, migraciones, rotaciones de certificados/claves, actualizaciones de BD/corredores.
• Emergencia (emergencia): fijos de seguridad urgentes/retrocesos de incidentes.
• Silent/Zero-impact: sin influencia del usuario (canarios ocultos, réplicas, entrada paralela).
• Provider-led: ventanas de proveedores externos (PSP/KYC/CDN/Cloud).

2) Principios

SLO-first: la decisión sobre el tiempo/formato de la ventana se toma en función del impacto en los presupuestos de SLI y error.
Radio mínimo explosivo: canario → escalonado → plena inclusión.
Reversibilidad: cada operación tiene un plan de retroceso y una reversión verificada.
Fuente única de la verdad: calendario de ventanas + ticket/RFC con el paquete de datos completo.
Probabilidad: Recopilación de evidencias (registros, gráficos, capturas de pantalla, hashes de artefactos).
Comunicaciones SLA: por adelantado, en el curso de las obras, una vez finalizadas.

3) Planificación: selección de tiempo y cobertura

Selección de la ventana: bajo tráfico, mínimo impacto para las cohortes clave (regiones/VIP/socios).
Zonas horarias: fijar en UTC + la hora local (por ejemplo, Europa/Kyiv).
Períodos de blacklout: prohibición de trabajar en temporadas altas/eventos (partidos, ventas, lanzamientos «ventanas de la muerte»).
Blast radius: identificar claramente a quién afectará (servicios, regiones, proveedores).

4) Proceso de negociación (lite RFC/CAF)

1. El iniciador crea un ticket/RFC con un análisis de riesgo y un plan (consulte la plantilla a continuación).
2. Evaluación de riesgos (Low/Med/High) y aprobación por el propietario del servicio + SRE/seguridad.
3. Calendario: reserva de ranura; verificación de conflictos (otras ventanas/proveedores).
4. Plan de Comm: notificaciones previamente acordadas y página de estado.
5. Go/No-Go-meet (24-48 h) para cambios de alto riesgo.

5) Preparación: Gates de seguridad

Comprobaciones previas al inicio: pruebas de stage exitosas, artefactos firmados, riesgos totales ≤ admisibles.
Canarias: 1%→5%→25% por cohorte/región; SLO-gardrailes automáticos y auto-retroceso.
Las banderas de ficha de la degradación y los límites están listos.
El plan Rollback/backout se verifica en la caja de arena; los comandos de reversión están documentados.
Alertas de Suppression: solo para el ruido esperado, las señales SLO no son insolentes.
Accesos: cuentas JIT/JEA para operaciones, auditoría de mandatos.

6) Comunicaciones (tiempo y contenido)

T-14/7/2 días (programados): heads-up para los clientes/los comandos internos (cuál/cuándo/impacto/contactos).
T-60/30/15 minutos: recordatorios dentro y en la página de estado.
Durante las obras: apdates cada 15-30 minutos (SEV-dependiente) por plantilla: Impacto → Etapa → Siguiente actualización.
Después: final «Completado/Completado/Rodado atrás», lista de cambios, validación de SLO.

7) Realización de obras (guión de referencia)

1. Freeze lanzamientos no relacionados.
2. En canario (cohorte limitada) → observamos SLI/métricas p95/p99.
3. Incrementando paso a paso la proporción de gardrailes verdes.
4. Validación de SLI empresarial (conversión, éxito de pagos/registros).
5. Verificación de la funcionalidad por check-list (happy path + scripts críticos).
6. Solución Release/No-release (IC/SRE/propietario del servicio).
7. Eliminación de suppression, devolución de alert policy.

8) Después de la ventana: verificación y presentación de informes

Ventana de observación (por ejemplo, 1-24 h): seguimiento de SLO y errores.
Informe por ventana: qué hicieron, métricas, desviaciones, evidence, total.
Si hubo problemas: AAR→RCA→CAPA (fix de reglas, pruebas, documentación).
Archivo: ticket, artefactos, firmas, sumas de comprobación.

9) Coordinación con proveedores externos

Ranuras confirmadas y contactos del proveedor; una ventana en su sistema de estado.
Folback/enrutamiento en un proveedor alternativo durante el período de trabajo.
Una única sala de guerra con proveedor (chat en vivo/bridge) y SLA de los apdates.

10) Métricas de madurez del proceso

Tasa en tiempo:% de las ventanas iniciadas/completadas a tiempo.
Change failure rate:% de ventanas con retrocesos/efectos en SLO.
Incident-during-MW: incidentes ocurridos durante la ventana.
Comunicación SLA: proporción de apdates oportunos.
Evidence completeness:% de ventanas con un paquete completo de pruebas.
Impacto del cliente: quejas/tickets en 1 ventana, tendencia.
Después de 7/30 días: estabilidad de SLO y ausencia de recaídas.

11) Hojas de cheques

Frente a la ventana

• RFC/ticket lleno; Evaluación del riesgo realizada; el propietario está asignado.
• Se ha verificado el plan canario y backout; los comandos de reversión se han probado.
• Accesos JIT emitidos; alertas sintonizadas (SLO no se silencian).
• Calendario/Página de estado y notificaciones preparadas.
• Lanzamientos/ventanas de la competencia - congelado/deslizado.
• Los proveedores están confirmados; contactos y SLA grabados.

Durante

• Los apdates están programados; war-room está activo.
• Se siguen los Gardrailes por SLO/pico de errores; en caso de infracción - auto-retroceso.
• Evidence se recopila (capturas de pantalla, gráficos antes/después, registro de acciones).

Después

• SLO en la zona verde durante la ventana de observación.
• Informe final con evidence; Página de estado actualizada.
• CAPA formalizados (si ha habido desviaciones); documentación actualizada.

12) Plantillas

Plantilla de RFC en la ventana de servicio

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

Plantilla de notificación de cliente (breve)

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

Reglas de suppression (idea)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) Características para dominios regulados

El registro de auditoría es inmutable: quién aprobó, quién ejecutó, qué comandos, hashes de artefactos.
PII/finanzas: enmascaramiento en la videncia, acceso restringido a los informes.
Plazos de notificación a clientes y socios - de acuerdo con los contratos.
Ventanas de proveedores: documentadas con SLAs externos y contactos.

14) Anti-patrones

Ventana sin plan de retroceso y reversión comprobada.
Silenciar las señales SLO «por si acaso».
Ventanas competitivas en el mismo dominio/región.
Silencio comm: no hay apdates «antes/durante/después».
Edición manual en venta sin auditorías ni scripts.
Ventanas «infinitas» debido a criterios de éxito inciertos.
La falta de evidencia no es nada para confirmar la calidad.

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

1. Ned. 1: introducir un calendario único y una plantilla RFC; definir períodos de blacklout.
2. Ned. 2: estandarizar las gatitas (canario, SLO-gardrailes, backout).
3. Ned. 3: automatizar suppression/anotaciones de lanzamientos y página de estado.
4. Ned. 4: informes y métricas de madurez; semanal MW-review.
5. Ned. 5-6: integración con proveedores y archivos de auditoría; simulación de ventana de alto riesgo.

16) Resultado

Las ventanas de servicio bien organizadas son cambios manejables, reversibles y probables. Con SLO-gardrailes, raskats canarios, comunicaciones rigurosas y un completo conjunto de evidence, la ventana se transforma de un «tiempo de inactividad terrible» a un mecanismo rutinario de mejoras sin sorpresas para usuarios y socios.