DevOps es una cultura de trabajo que junta desarrollo (Dev) y operaciones (Ops) para entregar software con más velocidad y menos fricción, apoyada en prácticas concretas —integración y entrega continuas o CI/CD, infraestructura como código, observabilidad— y en herramientas que las hacen posibles, como Docker, Kubernetes, Terraform o GitHub Actions. No es un puesto que «instala Jenkins» ni una herramienta que se compra: es una forma de trabajar que reparte la responsabilidad de que el software funcione en producción entre quien lo escribe y quien lo opera. Para trabajar en el área conviene aprender por etapas, en orden: primero contenedores, después CI/CD, luego infraestructura como código, más tarde observabilidad, y por último la seguridad de la cadena de suministro de software. Cada etapa se apoya en la anterior, y esta guía enlaza la guía del portal que cubre cada paso.
Ver índice de contenidos
Qué es DevOps (y qué no es)
DevOps combina las palabras inglesas development (desarrollo) y operations (operaciones). Amazon Web Services (AWS) lo define como «una combinación de filosofías culturales, prácticas y herramientas que aumenta la capacidad de una organización de entregar aplicaciones y servicios a alta velocidad». Esa definición importa porque ordena tres capas distintas que conviene no confundir entre sí: la cultura (cómo trabajan juntas las personas), las prácticas (qué se hace de forma sistemática) y las herramientas (con qué se hace).
Un error frecuente es reducir DevOps a una sola de esas capas. No es un puesto que «instala Jenkins» y ya está: instalar una herramienta de integración continua sin cambiar cómo colaboran desarrollo y operaciones no es «hacer DevOps». Tampoco es solo automatizar el despliegue: montar un pipeline de CI/CD (integración continua y entrega continua, del inglés continuous integration/continuous delivery) es una práctica valiosa, pero es una pieza, no «todo DevOps». Y no es una herramienta que se compra: Docker, Kubernetes o Terraform hacen posibles ciertas prácticas, pero ninguna es DevOps por sí sola.
Qué es, entonces
Es una forma de trabajar en la que desarrollo y operaciones comparten la responsabilidad de que el software funcione en producción, en lugar de que un equipo entregue el código y otro se ocupe en soledad de que no se caiga. Esa responsabilidad compartida es la que habilita, después, integrar y entregar cambios seguido y en partes chicas, en lugar de en tandas grandes y espaciadas.
Qué problema vino a resolver
Antes de que se popularizara DevOps, era habitual que un equipo de desarrollo entregara software cada varias semanas o meses a un equipo de operaciones separado, que lo desplegaba y lo mantenía. Cada entrega era un evento grande y arriesgado, porque acumulaba muchos cambios a la vez, y cuando algo fallaba en producción era difícil saber cuál lo había causado. Desarrollo quería moverse rápido; operaciones quería estabilidad; y como cada equipo medía el éxito de forma distinta, el conflicto era estructural, no una cuestión de personas.
DevOps propone resolver ese conflicto con cambios chicos y frecuentes, automatización que reduzca el trabajo manual y el margen de error, y métricas compartidas entre desarrollo y operaciones para que ambos midan lo mismo. Ahí entran las métricas de DORA (DevOps Research and Assessment), un programa de investigación de Google Cloud que desde hace más de una década estudia qué distingue a los equipos de alto rendimiento.
Consultamos la documentación vigente de DORA en dora.dev en julio de 2026: hoy el sitio presenta cinco métricas, no las «cuatro métricas clave» (four keys) del marco histórico que difundieron los informes State of DevOps entre 2014 y 2021. Si en otro material ves una referencia a «las cuatro métricas DORA», corresponde a esa versión anterior; la página vigente sumó una quinta.
| Métrica | Qué mide |
|---|---|
| Frecuencia de despliegue | Con qué asiduidad el equipo pone cambios en producción. |
| Tiempo de entrega de cambios | Cuánto tarda un cambio desde que se confirma en el repositorio hasta que corre en producción. |
| Tiempo de recuperación ante un despliegue fallido | Cuánto tarda el equipo en restablecer el servicio tras un incidente causado por un despliegue. |
| Tasa de fallos de cambios | Qué porcentaje de los despliegues provoca una falla en producción que requiere corrección. |
| Tasa de retrabajo de despliegue | Qué porción del trabajo de despliegue es retrabajo en lugar de avance nuevo. Es la incorporación más reciente. |
Estas métricas no están pensadas para evaluar personas, sino para ver si el proceso de entrega mejora con el tiempo. Perseguir un número aislado sin mirar el conjunto —por ejemplo, desplegar muy seguido a costa de una tasa de fallos alta— desvirtúa por completo lo que intentan medir.
Las tres capas de DevOps
Para que la definición de AWS no quede abstracta, conviene mirarla como tres capas que se apoyan una en otra. La cultura es la base: colaboración entre quien desarrolla y quien opera, responsabilidad compartida sobre lo que pasa en producción, y mejora continua que busca causas y no culpables. Sin esta capa, cualquier herramienta que se sume termina siendo un parche.
Las prácticas son lo que esa cultura permite hacer de forma sistemática: integración y entrega continuas (CI/CD), infraestructura como código (describir servidores y redes en archivos versionados en lugar de configurarlos a mano), observabilidad (ver qué pasa adentro de un sistema en producción con métricas, logs y trazas) y gestión de incidentes con foco en aprender de cada corte de servicio.
Las herramientas son lo que permite ejecutar esas prácticas a escala: Docker y Kubernetes para contenedores y su orquestación, Terraform y Ansible para infraestructura como código y automatización de servidores, GitHub Actions o Jenkins para pipelines de CI/CD, Prometheus y Grafana para observabilidad. Ninguna herramienta sola resuelve DevOps: cada una atiende una práctica concreta, que solo tiene sentido si la cultura la sostiene.
DevOps y SRE: una distinción discutida
Es habitual toparse con el término SRE (site reliability engineering, ingeniería de confiabilidad de sitios) y preguntarse en qué se diferencia de DevOps. No encontramos una fuente primaria que trace esa distinción con precisión, así que la tratamos con prudencia: es una distinción que se discute en la industria, no un consenso cerrado. En términos generales, DevOps son los principios culturales y de colaboración que venimos desarrollando en esta guía, sin prescribir una implementación concreta; SRE suele presentarse como una forma particular de aplicarlos, con foco en la confiabilidad de los sistemas en producción, apoyada en objetivos de nivel de servicio y presupuestos de error. Muchos equipos usan ambos términos sin una frontera nítida, algo que conecta con la gestión de incidentes y postmortems. Para quien está aprendiendo, no debería ser un obstáculo: los fundamentos de contenedores, CI/CD, infraestructura como código y observabilidad son la misma base, sin importar cómo termine llamándose el puesto.
La ruta de aprendizaje por etapas
Con la cultura y las prácticas más claras, queda la pregunta práctica: por dónde empezar. El portal tiene una guía para cada etapa, y conviene recorrerlas en este orden, porque cada una da por sentado lo que enseña la anterior.
- 1. Contenedores. Empaquetar una aplicación de forma reproducible: Docker desde cero: imágenes, contenedores y volúmenes, y Kubernetes para principiantes: pods, deployments y services cuando un solo servidor ya no alcance.
- 2. Integración y entrega continuas (CI/CD). Automatizar cómo se prueba y se despliega cada cambio: Cómo crear pipelines CI/CD con GitHub Actions, el punto de entrada más directo del portal.
- 3. Infraestructura como código. Describir la infraestructura donde corre el pipeline: Infrastructure as Code con Terraform para aprovisionarla, y Automatización de servidores con Ansible para configurarla.
- 4. Observabilidad. Ver qué pasa adentro de lo que ya se despliega solo: Observabilidad con OpenTelemetry, Prometheus y Grafana cubre métricas, logs y trazas.
- 5. Seguridad de la cadena de suministro. Con todo el camino andando, verificar de dónde viene cada dependencia y cada imagen: Seguridad de la cadena de suministro de software.
Dos guías más completan el mapa, sin ser parte de la secuencia lineal: Despliegues blue-green, canary y rolling update explica cómo entregar cambios sin cortar el servicio, y Gestión de incidentes, postmortems y mejora continua cubre qué hacer cuando algo se rompe. Y la base de todo esto está en Git y GitHub desde cero: sin control de versiones, ni el pipeline ni la infraestructura como código tienen sentido.
Consejos para el camino
La mayoría de los puestos de entrada piden solvencia en contenedores y en CI/CD, y el resto se aprende en el camino. Tampoco hace falta venir de un perfil de administración de sistemas: hay gente que llega desde el desarrollo y gente que llega desde operaciones. Lo que sí conviene es practicar sobre un proyecto real, porque automatizar un pipeline que nunca se rompe enseña poco comparado con uno que falla y hay que arreglar. Y participar de una comunidad ayuda: acorta bastante la curva de aprendizaje.
Errores frecuentes
- Confundir DevOps con un puesto. Es cultura y prácticas; el título «DevOps engineer» nombra a quien las aplica, no es la disciplina en sí.
- Creer que un pipeline de CI/CD ya es «DevOps completo». Automatizar el despliegue es una práctica entre varias; sin cultura compartida, el pipeline no alcanza.
- Saltar a las herramientas sin entender el problema. Instalar Kubernetes o Terraform sin resolver antes contenedores básicos, o sin necesitar esa escala, complica más de lo que resuelve.
- Confundir DevOps con SRE sin matices. Se superponen, pero no está saldado que sean lo mismo; tratá la diferencia con cautela.
- Citar «las cuatro métricas DORA» sin aclarar la fecha. La documentación vigente presenta cinco; el marco de cuatro es de 2014 a 2021.
- Medir por medir. Adoptar las métricas de DORA como un número para exhibir, sin usarlas para mejorar el proceso de entrega.
Preguntas frecuentes
¿DevOps es un puesto de trabajo o una cultura?
DevOps nació como una cultura de trabajo, no como un puesto, aunque hoy conviven las dos cosas. AWS lo define como una combinación de filosofías culturales, prácticas y herramientas que aumenta la capacidad de una organización de entregar software a alta velocidad, y esa definición pone la cultura primero: colaboración, responsabilidad compartida, mejora continua. Con el tiempo aparecieron puestos llamados «DevOps engineer», y ese rol es real. El problema es invertir la lógica: instalar una herramienta de integración continua y dar por hecho que ya «se hace DevOps», sin cambiar cómo colaboran los equipos ni quién responde cuando algo falla en producción. Un pipeline automatizado sin esa cultura de fondo sigue siendo útil, pero es una pieza aislada: el puesto tiene sentido solo si se apoya en ella, no al revés.
¿Qué diferencia hay entre DevOps y SRE?
Es una distinción que se discute en la industria, sin una fuente primaria única que la trace con precisión, así que conviene tomarla con prudencia. SRE son las siglas de site reliability engineering, ingeniería de confiabilidad de sitios, un término popularizado por cómo Google organizó la operación de sus sistemas. DevOps suele entenderse como el conjunto de principios culturales y de colaboración entre desarrollo y operaciones, sin prescribir una implementación concreta. SRE suele presentarse como una forma particular de aplicar esos principios, con foco en la confiabilidad de los sistemas en producción, apoyada en objetivos de nivel de servicio y presupuestos de error. Muchos equipos usan ambos términos sin una frontera nítida: «cultura DevOps» para cómo trabajan en general, y «rol de SRE» para quien se especializa en confiabilidad. Para quien recién empieza, no debería ser un obstáculo: los fundamentos de contenedores, CI/CD, infraestructura como código y observabilidad son la misma base, se llame como se llame el puesto.
¿Qué aprendo primero: contenedores, CI/CD o infraestructura como código?
El orden que rinde mejor es contenedores primero, CI/CD segundo, e infraestructura como código tercero, porque cada etapa da por sentado lo que enseña la anterior. Los contenedores resuelven lo más básico: empaquetar una aplicación con todo lo que necesita para correr, de forma que se comporte igual en tu máquina, en pruebas y en producción; sin esa unidad reproducible, automatizar el resto tiene mucho menos sentido. Con la aplicación en un contenedor, el paso siguiente es automatizar cómo se prueba y se despliega cada cambio con un pipeline de CI/CD, en vez de hacerlo a mano. Recién con ese pipeline funcionando conviene extender la automatización a la infraestructura donde corre todo —servidores, redes, bases de datos— describiéndola en archivos versionados, lo que se conoce como infraestructura como código. Saltar este orden es un error frecuente: automatizar infraestructura sin resolver antes los contenedores, o armar CI/CD sin contenedores, deja pasos de despliegue frágiles y distintos por entorno. Después siguen la observabilidad y la seguridad de la cadena de suministro, que se apoyan en que las tres anteriores ya estén andando.
¿Cómo se mide si un equipo hace bien DevOps?
La referencia más usada para medir el desempeño de la entrega de software son las métricas de DORA (DevOps Research and Assessment), un programa de investigación de Google Cloud. Consultamos la documentación vigente en dora.dev en julio de 2026, y hoy el sitio presenta cinco métricas, no las «cuatro métricas clave» que difundieron los informes State of DevOps entre 2014 y 2021: si en otro material encontrás una referencia a cuatro métricas DORA, corresponde a esa versión histórica. Las cinco vigentes son: frecuencia de despliegue; tiempo de entrega de cambios, desde que se confirma un cambio hasta que corre en producción; tiempo de recuperación ante un despliegue fallido; tasa de fallos de cambios, qué porcentaje de despliegues provoca una falla; y tasa de retrabajo de despliegue, la incorporación más reciente. Lo importante no es perseguir un número aislado, sino usarlas para ver si el proceso de entrega mejora con el tiempo, nunca para evaluar personas.
¿Necesito saber programar para trabajar en DevOps?
No hace falta ser desarrollador para entrar al área, pero sí conviene sumar scripting y lectura de configuración a medida que se avanza. En las primeras etapas —contenedores, seguir un pipeline ya armado, leer infraestructura como código— alcanza con comprender la lógica general y la sintaxis de archivos de configuración, típicamente en YAML, sin que eso sea programar en el sentido de escribir la lógica de una aplicación. Con más experiencia, resulta cada vez más útil escribir scripts en bash o en Python para automatizar tareas puntuales, y comprender el código que se está desplegando aunque no lo hayas escrito vos. Herramientas como Terraform o Ansible usan lenguajes declarativos, pensados para describir un estado deseado más que para programar paso a paso, lo que baja la barrera de entrada frente a desarrollar software desde cero. No es un requisito tan estricto como en otras áreas técnicas, pero sí una habilidad para ir sumando en paralelo.
¿Qué rutas de estudio y certificaciones existen?
A diferencia de áreas como el testing, donde existe una certificación de referencia ampliamente reconocida, en DevOps no hay una certificación única y neutral que funcione como punto de partida obligado; conviene desconfiar de cualquier afirmación tajante al respecto. Lo que sí existe, y rinde más que perseguir un certificado puntual, es una ruta basada en la documentación oficial de cada herramienta —Docker, Kubernetes, Terraform, GitHub Actions— y en la práctica sobre proyectos reales, propios o de código abierto, que es donde se nota si alguien entiende lo que hace. Cada herramienta mantiene su propia documentación y, en varios casos, sus propios programas de certificación; como cambian con frecuencia, lo más confiable es revisar el sitio oficial de cada una en el momento de rendir algo. Mientras tanto, la ruta de esta guía —contenedores, CI/CD, infraestructura como código, observabilidad y seguridad de la cadena de suministro— funciona como una progresión verificable con proyectos propios, que es lo que se pide en la mayoría de las entrevistas técnicas del área.
Fuentes
Documentación oficial y material de la comunidad. Fecha de consulta: 29 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección GNU/Linux. No hay un hilo específico sobre DevOps como concepto; esta sección es donde la comunidad discute de forma dispersa temas de contenedores, servidores y despliegue.
Documentación oficial
- AWS. What is DevOps?. Definición de referencia de DevOps como filosofías culturales, prácticas y herramientas.
- DORA (Google Cloud). DORA's software delivery metrics. Las cinco métricas vigentes para medir el desempeño de la entrega de software, consultado en julio de 2026.
- Google Cloud. DevOps solutions. Panorama general de soluciones y prácticas de DevOps.
- Kubernetes. Overview. Documentación oficial de orquestación de contenedores.
- Docker. Get started. Documentación oficial para empaquetar aplicaciones en contenedores.
- GitLab. Get started with GitLab CI/CD. Referencia de una plataforma de integración y entrega continuas.