DevOps: fundamentos y terminología
DevOps une prácticas de desarrollo y operación para entregar cambios pequeños, confiables y observables. No es únicamente Docker ni el nombre de un cargo: implica responsabilidad compartida desde el código hasta su comportamiento en producción.
Aprende o consulta
Sección titulada «Aprende o consulta»Si empiezas, sigue el flujo real del cambio: Git → CI → artefacto → contenedor → entorno → despliegue → health checks → logs/métricas/trazas → incidente y recuperación. Docker es una pieza del recorrido, no su objetivo.
| Necesito recordar | Documento |
|---|---|
| etapas y gates de una pipeline | Fundamentos de CI/CD |
| workflow de GitHub Actions | Pipeline Node.js |
| rolling, canary, blue/green y rollback | Estrategias de despliegue |
| separar config y promociones | Entornos y releases |
| imagen, contenedor, red y volumen | Qué es Docker |
| servicios locales reproducibles | Docker Compose |
| logs, métricas y trazas | Observabilidad |
| responder y aprender de fallos | Incidentes |
Una guía de comandos enseña a operar una herramienta; una ruta DevOps debe explicar qué garantía obtiene el producto y cómo se revierte cuando esa garantía falla.
Del cambio a producción
Sección titulada «Del cambio a producción»Commit → revisión → CI → artefacto → entorno → despliegue → verificación → observabilidad → aprendizajeCI significa Continuous Integration o integración continua: integrar cambios con frecuencia y verificarlos automáticamente. CD puede significar Continuous Delivery —entrega continua con aprobación para publicar— o Continuous Deployment —despliegue automático de cada cambio aprobado—. El equipo debe aclarar cuál usa.
Pipeline, job y step
Sección titulada «Pipeline, job y step»Un pipeline es el flujo automatizado. Un job es una unidad de trabajo que suele ejecutarse en una máquina o contenedor. Un step es un paso dentro del job.
jobs: verify: steps: - checkout - install - lint - typecheck - test - buildUna etapa rápida debe fallar pronto para no gastar minutos en un build que ya tiene errores de tipos. Las etapas independientes pueden ejecutarse en paralelo cuando no comparten estado.
Artefacto, entorno y promoción
Sección titulada «Artefacto, entorno y promoción»Un artefacto es una salida versionada e inmutable: imagen de contenedor, paquete o carpeta compilada. Un entorno es un conjunto de configuración y servicios, como desarrollo, pruebas, staging y producción.
La promoción mueve el mismo artefacto verificado entre entornos. Recompilar por entorno puede producir resultados diferentes. La configuración específica se inyecta al ejecutar, sin incluir secretos en el artefacto.
Release y deploy
Sección titulada «Release y deploy»Deploy o despliegue instala una versión en un entorno. Release o publicación la habilita para usuarios. Se pueden separar con una bandera de funcionalidad, conocida como feature flag.
Estrategias comunes:
- Rolling: reemplaza instancias gradualmente.
- Blue-green: mantiene dos entornos y cambia el tráfico entre ellos.
- Canary: entrega primero a un porcentaje pequeño y observa.
- Feature flag: activa funcionalidad independientemente del despliegue.
Un rollback de código no siempre revierte datos. Las migraciones deben ser compatibles con la versión anterior durante el período en que ambas pueden ejecutarse.
Infraestructura como código
Sección titulada «Infraestructura como código»IaC significa Infrastructure as Code o infraestructura como código. Redes, permisos y servicios se declaran en archivos versionados para revisar y reproducir cambios.
La declaración no elimina riesgos: un cambio de permisos o un borrado sigue necesitando revisión, plan y respaldo. El drift o desviación ocurre cuando el estado real ya no coincide con lo declarado, normalmente por cambios manuales.
Contenedor, imagen y orquestación
Sección titulada «Contenedor, imagen y orquestación»Una imagen contiene capas de archivos y metadatos para ejecutar una aplicación. Un contenedor es una instancia de esa imagen con aislamiento de procesos y recursos. Un registry es el registro donde se almacenan imágenes.
Un orquestador programa instancias, redes, configuración y reemplazos. Kubernetes es un ejemplo, pero añade costo operativo. Si una plataforma gestionada resuelve el volumen y la disponibilidad necesarios, no es obligatorio operar un clúster propio.
Observabilidad
Sección titulada «Observabilidad»La observabilidad permite inferir el estado interno a partir de sus salidas:
- Logs: eventos con contexto.
- Métricas: valores agregables en el tiempo.
- Trazas: recorrido de una solicitud entre componentes.
- Perfiles: dónde se consumen CPU o memoria.
Una métrica sin contexto dice que algo cambió; una traza puede mostrar dónde; un log estructurado puede explicar la condición concreta.
SLI, SLO y SLA
Sección titulada «SLI, SLO y SLA»- SLI (Service Level Indicator): indicador medido, como porcentaje de solicitudes exitosas.
- SLO (Service Level Objective): objetivo interno para ese indicador.
- SLA (Service Level Agreement): compromiso contractual con consecuencias acordadas.
El error budget o presupuesto de error es la cantidad de incumplimiento permitida por el SLO. Ayuda a equilibrar velocidad de cambio y confiabilidad con una medida compartida.
Salud y disponibilidad
Sección titulada «Salud y disponibilidad»Una comprobación de liveness responde si el proceso está vivo y debe reiniciarse. Una de readiness responde si está listo para recibir tráfico. Mezclarlas puede crear bucles de reinicio cuando una dependencia externa falla.
La disponibilidad también requiere límites, caché, redundancia y degradación controlada. Escalar una aplicación con una consulta ineficiente puede trasladar el problema a la base de datos.
Incidentes y recuperación
Sección titulada «Incidentes y recuperación»Un incidente es una interrupción o degradación que requiere coordinación. Durante el incidente se prioriza estabilizar y comunicar; el análisis profundo llega después.
RTO (Recovery Time Objective) define cuánto puede tardar la recuperación. RPO (Recovery Point Objective) define cuánto dato se acepta perder. Ambos orientan arquitectura, copias y simulacros.
Un postmortem documenta impacto, línea de tiempo, causas y acciones sin buscar culpables individuales. Las acciones útiles cambian el sistema: alerta, automatización, límite, prueba o procedimiento verificable.
Flujo recomendado
Sección titulada «Flujo recomendado»- Automatiza formato, tipos, pruebas y build.
- Produce un artefacto identificable por commit.
- Promueve ese artefacto con configuración externa.
- Despliega gradualmente y verifica señales de usuario.
- Define rollback, migraciones compatibles y cierre ordenado.
- Mide SLIs vinculados con experiencia real.
- Practica restauración e incidentes antes de necesitarlos.