DevOps y observabilidad (51-60)

Este capítulo va de las herramientas que normalmente das por hechas: el CI, las trazas, la página de estado. Construir una versión pequeña de cada una cambia cómo depuras las de verdad. Cuando has escrito tu propio recolector de trazas, los paneles de Grafana dejan de ser magia y pasan a ser algo que entiendes.

51. Servidor de integración continua mínimo#

Escucha un webhook, clona el repositorio, ejecuta los tests en un contenedor y reporta el resultado. Cien líneas que te explican Jenkins entero, o al menos la parte que importa.

Construye un servidor de CI mínimo.

- Recibe webhooks de push de GitHub (con verificación de firma).
- Clona el commit exacto y ejecuta los pasos de un .ci.yml en un contenedor Docker.
- Registro en vivo por Server-Sent Events y almacenado por ejecución.
- Reporta el estado al commit vía API (pendiente, éxito, fallo).
- Cola con concurrencia limitada y cancelación de ejecuciones obsoletas
  de la misma rama.

52. Recolector y visor de trazas distribuidas#

Contexto que se propaga entre servicios, spans anidados y una vista en cascada. Después de esto la observabilidad deja de ser una palabra de marketing.

Implementa trazado distribuido de extremo a extremo.

- Librería cliente que crea spans, los anida y propaga traceparent (W3C)
  por cabeceras HTTP.
- Colector que recibe spans por HTTP y los guarda en SQLite.
- Interfaz web con vista de cascada: duración, servicio, atributos y errores.
- Muestreo configurable, con muestreo siempre activo para trazas con error.

Demo: tres servicios encadenados, uno de ellos lento. La cascada debe
señalar el culpable de un vistazo.

53. Analizador de logs con detección de anomalías#

Millones de líneas de log, patrones agrupados automáticamente y una alerta cuando algo se sale de lo normal. El algoritmo de agrupación es la parte bonita.

Haz un analizador de logs para ficheros grandes.

- Parseo de formatos comunes (JSON, logfmt, Apache) y detección automática.
- Agrupación de mensajes por plantilla: "user 42 not found" y "user 77 not found"
  son el mismo patrón. Implementa el algoritmo (estilo Drain) y explícalo.
- Línea temporal de frecuencia por patrón y detección de picos anómalos.
- Consulta interactiva: filtros por campo, rango temporal y patrón.

Debe procesar un fichero de 5 GB con memoria acotada. Mídelo.

54. Panel de estado con comprobaciones sintéticas#

Una página de estado honesta, que comprueba de verdad los servicios, guarda el histórico y calcula un uptime real en lugar del 99,99 % decorativo.

Construye una página de estado con comprobaciones activas.

- Comprobaciones configurables: HTTP (código, latencia, contenido esperado),
  TCP, DNS y certificado TLS a punto de caducar.
- Historial de 90 días con uptime calculado por servicio.
- Incidencias con línea temporal de actualizaciones, en Markdown.
- Notificaciones cuando un servicio cambia de estado, con antirrebote para
  evitar avisos por un fallo aislado.

Genera la página como HTML estático: debe seguir funcionando si tu
infraestructura está caída.

55. Herramienta de despliegue con vuelta atrás#

deploy y rollback, y poco más. Releases con enlaces simbólicos, comprobación de salud tras arrancar y vuelta atrás automática si algo falla. Lo que hacía Capistrano hace quince años, y sigue funcionando.

Escribe una herramienta de despliegue por SSH, estilo Capistrano pero mínima.

- Estructura releases/<timestamp> con enlace simbólico "current".
- Pasos configurables: build, subida, migraciones, recarga del servicio.
- Comprobación de salud tras el arranque; si falla, vuelve al release anterior
  automáticamente y avisa.
- "rollback" manual y limpieza de releases antiguos conservando los últimos 5.
- Ficheros compartidos (uploads, .env) enlazados entre releases.

Modo --dry-run que imprima todos los comandos remotos sin ejecutarlos.

56. Inyector de fallos para probar resiliencia#

Latencia, errores y cortes provocados a propósito, para descubrir qué se rompe antes de que se rompa solo un domingo. Después de usarlo contra un servicio tuyo cambias de opinión sobre unas cuantas cosas.

Crea un proxy de inyección de fallos para pruebas de resiliencia.

- Proxy TCP/HTTP configurable en caliente.
- Fallos: latencia añadida con distribución, tasa de errores 5xx, corte de
  conexión a mitad de respuesta, respuestas truncadas, ancho de banda limitado.
- Escenarios reproducibles con semilla y un fichero de configuración.
- Informe de qué hizo el cliente ante cada fallo (reintentos, timeouts).

Úsalo contra un servicio tuyo y documenta los tres fallos que descubras.

57. Gestor de secretos con cifrado por fichero#

Secretos dentro del repositorio, cifrados con clave pública y que solo puede descifrar quien debe. Un sops casero, básicamente.

Implementa un gestor de secretos para ficheros en el repositorio.

- Cifrado por valor (no del fichero entero) para que los diffs sean legibles.
- Varias claves destinatarias: cada persona o entorno descifra con la suya.
- "edit" abre el editor con el contenido descifrado y vuelve a cifrar al guardar.
- Rotación de claves y re-cifrado masivo.
- Hook de pre-commit que impide subir un secreto en claro.

Usa criptografía estándar y documenta el esquema: nada de inventar primitivas.

58. Cuadro de mando de costes de nube#

Descarga la facturación, la agrupa por etiquetas y te enseña qué recurso se ha comido el presupuesto este mes. Suele ser uno que nadie recordaba haber creado.

Haz un panel de análisis de costes de nube.

- Importa el informe de costes (CUR de AWS o el equivalente) desde CSV.
- Agrupa por servicio, etiqueta, entorno y equipo; detecta recursos sin etiquetar.
- Detección de anomalías: coste diario que se sale de la tendencia.
- Recomendaciones simples: recursos parados, discos huérfanos, snapshots viejos.
- Exporta un informe mensual en Markdown listo para enviar.

Empieza con datos de ejemplo generados: no necesito conectarme a nada real.

59. Módulo de infraestructura como código propio#

Un Terraform en miniatura. Lee un estado, calcula el plan, aplica los cambios. La palabra clave es idempotencia, y aquí la vas a entender de verdad.

Escribe un motor de infraestructura declarativa mínimo.

- Recursos definidos en HCL o YAML, con dependencias entre ellos.
- Fichero de estado con lo aplicado; "plan" muestra las diferencias con colores
  (+ crear, ~ modificar, - destruir) sin tocar nada.
- "apply" ejecuta en orden topológico y actualiza el estado tras cada recurso.
- Proveedor de ejemplo: contenedores Docker locales (crear, modificar, destruir).
- Bloqueo del estado para evitar dos "apply" simultáneos.

Demuestra que aplicar dos veces seguidas la misma configuración no cambia nada.

60. Orquestador de contenedores mínimo#

Un Kubernetes de bolsillo. Un plano de control, agentes en los nodos y un bucle de reconciliación. Cuando escribes ese bucle entiendes por qué Kubernetes es como es.

Construye un orquestador de contenedores muy simplificado.

- API que acepta "despliegues": imagen, réplicas, puertos, variables.
- Agente por nodo que arranca y para contenedores vía la API de Docker.
- Bucle de reconciliación: si el estado real no coincide con el deseado, actualiza.
- Comprobaciones de salud y reinicio de contenedores caídos.
- Despliegue progresivo: sustituye réplicas de una en una sin cortar el servicio.

El bucle de reconciliación es el corazón: escríbelo primero y explícalo bien.