Plantilla de Checklist de Desmantelamiento

Descripción General

Los servicios antiguos nunca mueren en silencio. Sobreviven en registros DNS, confunden a los ingenieros nuevos, cuestan dinero y, de vez en cuando, rompen cosas cuando alguien cambia un certificado o rota un secreto. El desmantelamiento es el proceso disciplinado de apagar un servicio de forma definitiva: identificar cada dependencia, migrar a cada usuario, eliminar cada recurso y documentar qué se quitó. Bien hecho, reduce el coste y la complejidad. Mal hecho, provoca caídas en sistemas que creías que no tenían relación, normalmente semanas después, cuando por fin se ejecuta ese batch mensual.

Esta plantilla te da una checklist lista para copiar y ordenada por riesgo, un cronograma adaptable, un email de notificación, un script de verificación y una auditoría a los 30 días para que nada quede atrás.

Cuándo Usar

Usa esta plantilla cuando:

• Se ha reemplazado un servicio por un sistema nuevo y el tráfico ya migró
• Una funcionalidad se retira y la infraestructura que la soportaba ya no hace falta
• Se discontinúa una integración con un tercero
• Un experimento o prueba de concepto ha concluido
• Una auditoría exige evidencia de que se eliminaron los recursos sin uso

No la uses cuando el servicio solo esté siendo deprecado. Si los consumidores todavía necesitan tiempo para migrar, ejecuta primero la plantilla de cronograma de deprecación — el desmantelamiento es el último paso de ese proceso, no el primero. Tampoco aplica a infraestructura compartida de la que dependen otros equipos; en ese caso retira inquilino por inquilino en vez de apagar todo de golpe.

Requisitos Previos

Antes de desmantelar un sistema:

• El sistema de reemplazo está listo para producción y maneja todo el tráfico
• Se ha comunicado un cronograma de deprecación a todos los stakeholders
• Se han revisado todos los requisitos de retención de datos y cumplimiento
• Existe un plan de rollback por si el nuevo sistema falla tras el apagado — incorpóralo a tu plan de recuperación ante desastres
• El dueño del servicio y el responsable de facturación han aprobado la fecha de desmantelamiento

La Checklist

# Checklist de Desmantelamiento: `<Nombre del Sistema / Servicio>`

> Dueño del servicio: ______ | Fecha: ______ | Aprobado por: ______
> Sistema de reemplazo: ______ | Fecha objetivo de desmantelamiento: ______

## 1. Descubrimiento

- [ ] Lista todos los servicios upstream que llaman a este sistema
- [ ] Lista todos los servicios downstream que este sistema llama
- [ ] Lista todas las integraciones externas (vendors, partners, webhooks)
- [ ] Lista todas las entradas DNS, load balancers y configs de CDN que apuntan a este servicio
- [ ] Lista todos los certificados SSL ligados a este servicio
- [ ] Lista todas las bases de datos, caches, colas y buckets que posee el servicio
- [ ] Lista todos los jobs programados, tareas cron o workers en background
- [ ] Lista todos los feature flags o entradas de configuración que referencian este servicio

## 2. Manejo de Datos

- [ ] Confirma los requisitos de retención de datos (legales, compliance, negocio)
- [ ] Exporta y archiva los datos que deben conservarse
- [ ] Verifica la ubicación del archivo, el cifrado y los controles de acceso
- [ ] Migra los datos activos al sistema de reemplazo
- [ ] Documenta la ubicación del archivo de datos y el calendario de retención
- [ ] Confirma la eliminación de los datos que no deben conservarse

## 3. Eliminación de Dependencias

- [ ] Elimina el servicio de los load balancers y el DNS upstream
- [ ] Actualiza los servicios upstream para que dejen de llamar a este sistema
- [ ] Elimina referencias del servicio en API gateways y service meshes
- [ ] Elimina el servicio de monitorización, alertas y dashboards
- [ ] Elimina el servicio de pipelines de CI/CD y herramientas de despliegue
- [ ] Elimina el servicio de gestores de secretos y almacenes de credenciales
- [ ] Elimina el servicio de calendarios de backup y planes de recuperación

## 4. Apagado

- [ ] Redirige el tráfico (si aplica) al reemplazo o a una página de sunset
- [ ] Para el servicio en staging / pre-producción
- [ ] Monitoriza errores o tráfico inesperado durante 24-48 horas
- [ ] Para el servicio en producción
- [ ] Monitoriza de nuevo durante 24-48 horas
- [ ] Deshabilita el auto-restart o la recuperación por health check

## 5. Limpieza de Recursos

- [ ] Termina instancias de cómputo, contenedores o funciones serverless
- [ ] Elimina bases de datos (tras confirmar el archivo y la retención)
- [ ] Elimina caches, colas y topics
- [ ] Elimina buckets de almacenamiento y volúmenes
- [ ] Libera IPs estáticas e interfaces de red elásticas
- [ ] Elimina listeners de load balancer y target groups
- [ ] Elimina registros DNS (cuando expire el TTL)
- [ ] Revoca o elimina certificados SSL
- [ ] Elimina roles IAM, políticas y cuentas de servicio

## 6. Documentación

- [ ] Actualiza los diagramas de arquitectura para quitar el servicio
- [ ] Actualiza runbooks y documentación operativa
- [ ] Actualiza el catálogo de servicios o los documentos de ownership
- [ ] Escribe un postmortem o retrospectiva breve del desmantelamiento
- [ ] Notifica a los stakeholders que el servicio se ha retirado por completo

## 7. Verificación

- [ ] Confirma que no hay cargos de facturación del servicio en el siguiente ciclo
- [ ] Confirma que ninguna alerta ni error referencia el servicio
- [ ] Confirma que ningún repositorio referencia el servicio (salvo el historial)
- [ ] Confirma que ningún ingeniero nuevo se incorpora al servicio retirado

Explicación

La checklist está ordenada por riesgo, y el orden importa.

Primero el descubrimiento, porque no puedes retirar lo que no has mapeado. El documento de ownership del servicio es la forma más rápida de encontrar quién es dueño de cada consumidor. Espera que esta fase tarde más de lo previsto: el análisis de tráfico, grep sobre las configs de servicio y los logs de consultas DNS siempre revelan dependencias que nadie documentó.

Después el manejo de datos, porque las eliminaciones son irreversibles. Si los datos activos se mueven a un reemplazo, el runbook de migración de datos cubre la secuenciación y la validación. Si solo se archivan, elige un formato que no dependa del sistema que muere — un dump SQL o archivos Parquet sobreviven a una exportación propietaria.

Luego la eliminación de dependencias, porque cortar a los consumidores antes de parar el servicio hace aflorar errores mientras aún puedes reaccionar. Limpiar API gateways, meshes y CI/CD en este punto también evita el estado de “el servicio parece vivo pero no lo está” que confunde a quien esté de guardia.

El apagado va cuarto, y por etapas: primero staging, vigila 24-48 horas, luego producción. El tráfico que solo llega en calendarios mensuales o trimestrales es el fallo clásico aquí — por eso la auditoría espera un ciclo de facturación completo.

La limpieza va quinta, cuando se cierra la ventana de observación — borrar algo que un consumidor sorprendido todavía necesita es exactamente el fallo que este orden existe para prevenir.

La documentación va última pero no es opcional: actualiza el catálogo de servicios, deja una lápida en la wiki y escribe una retrospectiva breve — la estructura de la guía de postmortems funciona bien incluso cuando nada salió mal.

La fase de verificación existe porque los recursos olvidados siguen un patrón: un registro DNS con un TTL de una semana, un cron en un servidor que nadie recuerda, un rol IAM que en silencio da acceso a otra cosa. El script de más abajo automatiza la parte aburrida de esa comprobación.

Cronograma de Ejecución

Desmantelar es tanto un ejercicio de calendario como uno técnico. Un cronograma seguro por defecto para un servicio interno de tamaño medio:

Hito	Cuándo	Requisito para continuar
Descubrimiento y mapa de dependencias	T-60 días	Todos los consumidores identificados y con dueño asignado
Notificación enviada	T-30 días	Todos los consumidores confirmaron; canal de soporte de migración abierto
Exportación de datos y prueba de restauración	T-14 días	Un archivo del archive restaurado y leído de verdad
Servicio parado (staging, luego prod)	T-0	Cero peticiones o errores durante 24-48 horas
Eliminación de infraestructura	T+7 días	Sin eventos de rollback durante la observación
Auditoría post-desmantelamiento	T+30 días	Cero cargos, cero alertas, catálogo actualizado
Purga de artefactos	T+90 días	Política de retención y visto bueno legal

Comprímelo para experimentos y servicios de bajo riesgo; estíralo para cualquier cosa con consumidores de pago u obligaciones de cumplimiento. Si la migración es grande, la guía de migración de datos cubre la estrategia de cutover con más profundidad.

Retención de Artefactos y Rollback

Conserva una snapshot restaurable durante 90 días tras el apagado: el archivo del repositorio con su tag, la última exportación de configuración y un volcado de datos verificado. Esa ventana cubre la mayoría de las dependencias sorpresa sin convertirse en acumulación indefinida. Si un consumidor crítico aparece en el día 40, puedes reiniciar el servicio temporalmente, migrarlo y volver a apagar sin una reconstrucción de emergencia.

Hacer rollback no es un fracaso — es el coste de descubrir una dependencia tarde. Lo que lo hace barato o caro es la preparación: artefactos que puedes redesplegar frente a artefactos que borraste el primer día.

Script de Verificación de Recursos Restantes

#!/bin/bash
# Verifica recursos restantes tras el desmantelamiento
set -euo pipefail

SERVICE_NAME="legacy-auth-service"
AWS_REGION="us-east-1"

echo "=== Verificación de Recursos Restantes ==="
echo "Servicio: $SERVICE_NAME"
echo "Fecha: $(date)"
echo ""

# Comprueba registros DNS
echo "--- Registros DNS ---"
dig +short "$SERVICE_NAME.internal.example.com" && echo "AVISO: el registro DNS sigue existiendo" || echo "OK: sin registro DNS"

# Comprueba recursos de AWS
echo "--- Recursos de AWS ---"
aws ec2 describe-instances --region $AWS_REGION --filters "Name=tag:Service,Values=$SERVICE_NAME" --query 'Reservations[*].Instances[*].InstanceId' --output text 2>/dev/null | while read id; do
  [ -n "$id" ] && echo "AVISO: instancia EC2 encontrada: $id"
done

aws rds describe-db-instances --region $AWS_REGION --query 'DBInstances[?DBInstanceIdentifier.contains(@, `'$SERVICE_NAME'`)].DBInstanceIdentifier' --output text 2>/dev/null | while read id; do
  [ -n "$id" ] && echo "AVISO: instancia RDS encontrada: $id"
done

aws s3 ls --region $AWS_REGION 2>/dev/null | grep "$SERVICE_NAME" && echo "AVISO: bucket S3 encontrado" || echo "OK: sin buckets S3"

# Comprueba certificados
echo "--- Certificados ---"
aws acm list-certificates --region $AWS_REGION --query 'CertificateSummaryList[*].DomainName' --output text 2>/dev/null | tr '\t' '\n' | grep -i "$SERVICE_NAME" && echo "AVISO: certificado ACM encontrado" || echo "OK: sin certificados"

# Comprueba alarmas de CloudWatch
echo "--- Alarmas de CloudWatch ---"
aws cloudwatch describe-alarms --region $AWS_REGION --query 'MetricAlarms[?AlarmName.contains(@, `'$SERVICE_NAME'`)].AlarmName' --output text 2>/dev/null | while read alarm; do
  [ -n "$alarm" ] && echo "AVISO: alarma de CloudWatch encontrada: $alarm"
done

echo ""
echo "=== Verificación Completada ==="

Ejecútalo semanalmente durante la ventana de auditoría de 30 días. Extiéndelo con lo que añada tu stack — namespaces de Kubernetes, monitors de Datadog, políticas de Vault — porque las comprobaciones genéricas solo cubren los casos comunes.

Plantilla de Notificación de Desmantelamiento

=== Notificación de Desmantelamiento de Servicio ===

Para: engineering@example.com, stakeholders@example.com
De: platform-team@example.com
Fecha: [FECHA]
Asunto: Desmantelamiento de [NOMBRE_DEL_SERVICIO]

El servicio [NOMBRE_DEL_SERVICIO] se desmantelará el [FECHA_DE_APAGADO].

¿Qué significa esto?
- El servicio dejará de aceptar tráfico el [FECHA_DE_APAGADO]
- Los datos se archivarán y estarán disponibles durante [PERIODO_DE_RETENCION]
- Los endpoints devolverán 410 Gone tras el apagado
- Las dependencias upstream deben actualizarse antes del [FECHA_DE_APAGADO]

¿Qué necesitas hacer?
1. Comprueba si tu servicio depende de [NOMBRE_DEL_SERVICIO]
2. Si depende, migra a [SERVICIO_DE_REEMPLAZO] antes del [FECHA_DE_APAGADO]
3. Actualiza configuraciones, variables de entorno y documentación
4. Contacta con platform-team@example.com si necesitas soporte de migración

Cronograma:
- [HOY]: Notificación enviada
- [T-30]: Apagado del servicio (stop)
- [T-60]: Eliminación de infraestructura
- [T-90]: Eliminación de datos (según política de retención)

Contacto: platform-team@example.com

Envíala en T-30, reenvíala en T-14 y T-3, y publícala en los canales donde los equipos consumidores leen de verdad — un email que nadie abrió no cuenta como aviso.

Checklist de Auditoría Post-Desmantelamiento

=== Auditoría Post-Desmantelamiento (30 días) ===

Infraestructura:
  [ ] Ningún recurso cloud generando cargos
  [ ] Ninguna alerta activa referenciando el servicio
  [ ] Ningún dashboard obsoleto en Grafana/Datadog
  [ ] Ningún target en Prometheus/CloudWatch

Red y DNS:
  [ ] Registros DNS eliminados o redirigidos
  [ ] Certificados TLS revocados o eliminados
  [ ] Reglas de firewall/security groups eliminadas
  [ ] Load balancers y target groups eliminados

Código y CI/CD:
  [ ] Repositorio archivado (no eliminado)
  [ ] Pipelines de CI/CD deshabilitados
  [ ] Webhooks eliminados
  [ ] Variables de entorno de CI eliminadas

Datos:
  [ ] Backups archivados en almacenamiento barato
  [ ] Política de retención documentada
  [ ] Acceso a datos archivados restringido y auditado

Documentación:
  [ ] Lápida creada en wiki/documentación
  [ ] Catálogo de servicios actualizado
  [ ] Diagramas de arquitectura actualizados
  [ ] Runbooks que referenciaban el servicio actualizados

Variantes

Contexto	Ajustes	Notas
Reemplazo de servicio de terceros	Añade terminación de contrato, exportación de datos y revocación de API keys	No controlas la infraestructura
Retiro de base de datos	Enfócate en migración de esquema, integridad referencial y redirección de queries	Los datos sobreviven al código
Retiro de microservicio	Añade eliminación del service mesh, actualización de contratos y notificación a consumidores	Los consumidores pueden ser otros equipos
Cierre de región	Añade verificaciones de residencia de datos, migración de usuarios y evaluación de impacto en latencia	Las regiones tienen implicaciones de cumplimiento
Desmontaje de experimento	Checklist más corta; enfócate en eliminación de datos y confirmación de costes	Los experimentos deben limpiarse rápido

Lo Que Funciona

1. Nunca elimines el primer día — para el servicio, espera y observa. La eliminación va la última, cuando todo lo demás ha demostrado estar en silencio
2. Archiva antes de borrar. El almacenamiento es barato; explicar datos perdidos a un auditor no lo es
3. Comunica pronto y a menudo. La peor sorpresa del desmantelamiento es descubrir que otro equipo seguía usando el servicio
4. Documenta qué se eliminó. Los ingenieros del futuro buscarán el servicio; deja una lápida, no un misterio
5. Verifica la facturación. Los recursos cloud tienen la costumbre de seguir generando cargos aunque creas que ya no existen

Errores Comunes

1. Saltarse el descubrimiento. El servicio que estás apagando es la dependencia crítica de otro equipo
2. Eliminar datos demasiado pronto. Obligaciones legales, de auditoría o de negocio pueden exigir más retención de la que esperas
3. No esperar tras el apagado. Algunas cargas de trabajo solo despiertan en ciclos mensuales o trimestrales
4. Olvidar el DNS. Un registro DNS que apunta a una IP eliminada puede ser secuestrado o causar errores extraños
5. Ignorar los certificados. Los certificados caducados de servicios eliminados siguen disparando alertas de renovación y automatizaciones

Solución de Problemas

• Un consumidor sigue llamando al servicio tras el apagado: revisa los access logs del load balancer y las métricas del gateway en busca de hits a los endpoints retirados, identifica al dueño del llamante y dale una fecha límite de migración. Si ese tráfico sostiene operaciones reales, reinicia temporalmente desde los artefactos conservados mientras migran — para eso están.
• El registro DNS vuelve a aparecer: el Terraform, CDK o Ansible de otro equipo lo está recreando. Busca el registro en el estado del infrastructure-as-code y elimínalo ahí; borrarlo desde la consola solo aguanta hasta el siguiente apply.
• Siguen apareciendo cargos en la próxima factura: los sospechosos habituales son IPs elásticas, snapshots de EBS, buckets de S3 en regiones que olvidaste, health checks de Route 53 y log groups antiguos. Filtra el informe de costes por el tag del servicio y por región antes de dar la limpieza por terminada.
• Las alertas siguen disparando por el servicio muerto: las reglas viven en rule files de Prometheus, CloudWatch o Terraform — no en los dashboards que alguien borró. Elimina las definiciones de las reglas y cualquier política de silencio que mencione el servicio.
• Alguien necesita urgentemente los datos archivados: por eso el archivo usa un formato portable y un procedimiento de restauración documentado. Haz una restauración de prueba de un archivo en el hito T-14 para que la primera restauración real no ocurra bajo presión de incidente.

Lecturas Adicionales

• Archivar repositorios en GitHub — el flujo oficial para conservar código e historial sin mantener el repo activo.
• NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization — el estándar de referencia cuando hay que destruir datos, no solo archivarlos.
• Guía de migración de APIs deprecadas de Kubernetes — un ejemplo público de cómo un proyecto grande retira APIs sin romper a los consumidores.
• Colección de postmortems públicos — informes de incidentes reales; varios se remontan a “lo apagamos y se rompió otra cosa”.