La historia de DevOps

Este texto retoma gran parte de las ideas del libro The DevOps Handbook.

DevOps ha sido un movimiento que tomó gran fuerza a mediados de la década de 2010. En cualquier organización tecnológica de prestigio hay, al menos, una vacante de «DevOps» abierta. Muchos desarrolladores creen que DevOps es un rol de nivel arquitecto; otros, que son quienes únicamente gestionan servidores e infraestructura; y algunos sostienen que no deben programar. Pero ¿son reales estos mitos?

El ping-pong entre operaciones y desarrollo

Antes de analizar la fusión de ambos mundos, conviene recordar cómo era el trabajo en el sector tecnológico previo a DevOps. Antes de la llegada de la agilidad (Agile), dominaba el desarrollo en «cascada» (Waterfall). Cuando las empresas lanzaban un proyecto —y nótese el uso de «proyecto» en lugar de «producto», un síntoma de falta de visión a largo plazo—, arriesgaban demasiados recursos sin ninguna garantía de retorno de inversión. Eran desarrollos titánicos que tardaban meses o años en ver la luz; para cuando salían al mercado, las necesidades de los clientes ya habían cambiado.

Los desarrolladores trabajaban en sus funcionalidades de forma aislada para, al final, intentar integrar sus partes (un proceso tortuoso antes de la adopción masiva de Git). Esto resultaba en fases de integración interminables. Proveer la infraestructura —servidores físicos, pues no existían AWS ni Azure, y las escasas soluciones de nube carecían de la flexibilidad actual—, instalar dependencias y configurar entornos era una tarea lenta y propensa a fallos. Era común compilar binarios con las credenciales de producción incrustadas. No existían los microservicios; eran aplicaciones monolíticas que contenían plataformas completas. Además, las pruebas eran manuales y limitadas. El despliegue era un juego de ensayo y error porque se solían olvidar las dependencias locales al transferir el código a producción.

Tras semanas de pruebas, se generaba una solicitud de servicio (Service Request): el equipo de desarrollo pedía al de operaciones desplegar la aplicación. Operaciones actuaba como la «policía». Tenían el mandato de mantener los sistemas estables, lo que significaba que si un desarrollador cometía un error, el operador era el responsable de detectarlo y contener el daño. Esta disociación de incentivos —desarrollo empujando el cambio y operaciones defendiendo la estabilidad— creó una maquinaria burocrática asfixiante. Al no haber responsabilidad compartida, no había libertad de acción. La presión aumentaba conforme se acercaban los plazos de entrega, y la fricción entre departamentos se volvía insostenible.

Por un momento ponte a pensar en este escenario. Eres un programador con cierta reputación. Tienes un proyecto en el que has estado trabajando los últimos 6 meses. Las últimas 2 semanas las pasaste en llamada con tu compañero del equipo de QA, con quien, después de haber peleado intensamente por 2 o 3 días, se dieron cuenta de que era mejor hacer las paces y trabajar juntos. No has dormido bien. Le quedaste mal a tus hijos, pareja, sobrinos, amigos, etc., sobre algún plan que era muy importante. El cuerpo duele y huele mal. No tuviste tiempo de ir a casa la noche anterior. Te has alimentado solo con comida chatarra las últimas 24 horas. Ese plato especial de tu infancia nunca había sido más necesario. Tu cama nunca había sido extrañada de semejante manera.

La fecha de salida a producción es el lunes próximo. Hoy es jueves a las 10:51 de la mañana. Pasaste los últimos 15 minutos escribiendo las instrucciones para la instalación de la aplicación en los servidores de producción. La última noche dormiste 4 horas en el coche. No has logrado dormir más de 6 horas ningún día de la semana. Es más, no recuerdas cuándo fue la última vez que dormiste 8 horas continuas. Acabas de mandar tu Service Request a revisión por el equipo de ops. Echas tu cabeza hacia atrás en frustración. Tus manos cuelgan al lado de la silla. Miras el techo unos segundos. Cierras los ojos. Tus párpados logran dar vueltas. Tu sien punza. Das un largo bostezo. De pronto escuchas ese sonido de notificación en tu equipo. Tu ticket fue marcado como cerrado. La razón, solo dice que hay instrucciones que no son correctas. Lo único que piensas es “¿cómo demonios logró revisar algo que me tomó 15 minutos escribir en tan solo unos segundos?”.

…

El de operaciones es un idiota, ¿verdad? Bueno, no tan rápido…

…

Son las 6:23 de la mañana. Debes estar a las 9 am en la oficina. Para llegar debes recorrer toda la ciudad porque tus padres están enfermos y no había nadie más que los cuidara. El despertador lleva ya varios minutos sonando. Observas el techo; no solo no te sientes motivado de ir a trabajar, además tienes pavor porque sabes que un error más y te podría costar tu trabajo. Las medicinas de mamá no las podrías pagar más allá de 6 meses si te quedas sin trabajo. El coche necesita arreglar los frenos. Te has estado jugando la vida los últimos 3 meses. La bicicleta ha sido tu cesto de la ropa sucia más caro que has comprado. Repasas las palabras de tu jefe de la última semana y cómo te miró con preocupación y fe, asegurando que sabía que no volverías a meter la pata porque ya habías aprendido de las últimas 2 incidencias en que tuviste que quedarte trabajando hasta las 5 de la mañana porque un idiota de desarrollo introdujo un error que le costó a la compañía varios meses de tu sueldo. No sabes si interpretar esas palabras como motivacionales o como amenaza. Pues a uno de tus compañeros lo despidieron luego de un par de incidencias.

La cafetera ya no huele. El café es más negro que nunca y ya no te quita el sueño. Toda la comida del refrigerador se ve igual. Tomas una pieza de pan y llenas el termo de café. Miras el auto y crees que hoy sería tentar demasiado a la muerte. Sales al transporte público. Tu cuerpo sale de casa pero es como si anduviera sin ti. Pagas el pasaje. Va demasiado lleno. Miras la ciudad pero ella no te mira a ti. El camino se vuelve eterno. El café quema pero no te quita el sueño.

Llegas a la oficina, la gente te da los buenos días. O a lo que queda de ti. Respondes con una sonrisa. Llegas a tu cubículo. Hay demasiada tensión en la bandeja de entrada. Reportes de los últimos incidentes. Hay 4 proyectos en puerta, de los cuales tu jefe te pidió ayuda con 2. Los de marketing te han estado presionando para liberar el proyecto que prometen que será la nueva joya de la corona, así como los últimos 2 proyectos que lo prometían.

Atiendes un par de solicitudes de permisos y accesos. Tu jefe te pide ser un poco más flexible con el proyecto estrella. A las 10:51 llega un correo de la solicitud del susodicho. Apenas lo empiezas a leer te das cuenta de que no tiene pies ni cabeza. Los paquetes que te piden instalar están mal escritos. Hay puertos que te piden dejar abiertos en los equipos, pero sabes que seguridad limitó el uso de estos. Y lo único que piensas es que si así vienen las instrucciones, probablemente el resto de acciones sean un riesgo mucho mayor. Recuerdas que debes defender los servidores como un perro para que la empresa logre las metas de estabilidad necesarias. Solo te limitas a escribir “Hay instrucciones que no son correctas.” y das clic en enviar.

Solo te limitas a pensar: “¿Cómo mandaron estos datos? ¿Para qué contrataron a tantos idiotas en esta empresa?”.

Estas dos perspectivas ilustran un problema sistémico real: la organización diseña una estructura donde dos áreas están destinadas a chocar. En términos de salud organizacional (un tema clave que detalla Patrick Lencioni en The Advantage), esto es una alerta roja. Se gastan recursos valiosos en conflictos internos en lugar de alinear procesos para crear valor.

Tenemos dos fuerzas opuestas: desarrollo, cuyo incentivo es la velocidad de cambio, y operaciones, cuyo incentivo es la estabilidad (evitar el cambio). Si la aplicación falla en producción, el costo recae sobre operaciones. Si el código no se despliega, el impacto es para desarrollo. Tratarlos como islas es un error conceptual grave; al final del día, si el servicio se cae o no se entrega, es la organización entera la que pierde viabilidad.

Tradicionalmente, los desarrolladores operaban en la ignorancia del entorno real. Escribían código en sus estaciones locales sin entender las restricciones de red, el almacenamiento persistente o el balanceo de carga. Un error clásico consistía en almacenar estado en la sesión local del servidor, provocando caídas masivas al escalar horizontalmente. ¿De quién era la culpa? ¿De operaciones por no preverlo o de desarrollo por no documentarlo? Mientras los equipos se culpan mutuamente para eludir su responsabilidad, la empresa pierde dinero y credibilidad. La falta de responsabilidad compartida destruye la libertad operativa del negocio.

Paralelamente, el desarrollo tecnológico global comenzó a catalizar lo que hoy conocemos como DevOps. De todas las hipótesis planteadas en la industria, la más disruptiva fue: «¿Y si hacemos a los desarrolladores responsables de operar sus propias aplicaciones en producción?».

Esta premisa no buscaba simplemente sobrecargar al programador, sino devolverle el control y, con ello, la obligación de responder por sus decisiones. Al asumir esta responsabilidad, los desarrolladores se vieron obligados a resolver problemas operativos reales, haciéndose preguntas clave:

• Trabajamos varios ingenieros en paralelo en este repositorio; ¿cómo integramos los cambios sin generar conflictos masivos?
• El despliegue falló en producción; ¿cómo realizamos un retorno rápido (rollback) a la última versión estable?
• Si incrementamos la frecuencia de integración, ¿cómo aseguramos automáticamente que no rompemos funcionalidad existente?
• El servicio se satura durante los picos de facturación; ¿cómo monitoreamos el tráfico en tiempo real?
• La infraestructura física se queda sin recursos; ¿cómo escalamos horizontalmente de forma automática ante la demanda?
• El costo del centro de datos es muy alto fuera de las horas pico; ¿cómo liberamos recursos no utilizados para optimizar el presupuesto?
• La discrepancia de entornos genera errores inexplicables; ¿cómo garantizamos que el entorno de desarrollo sea idéntico al de producción?

Para responder a estas inquietudes surgieron herramientas y metodologías: Integración Continua (CI), Entrega Continua (CD), contenedores (Docker), orquestadores de clústeres (Kubernetes), nubes públicas (AWS, GCP, Azure), telemetría avanzada y automatización de pruebas (Selenium, Cypress).

Estas prácticas confluyeron en el término DevOps, acuñado por Patrick Debois (coautor de The DevOps Handbook). El objetivo de fondo era desactivar la guerra fría entre desarrollo y operaciones. La solución fue simple pero radical: alinear la autoridad para realizar cambios con la responsabilidad de mantenerlos estables. Cuando el equipo que programa es el mismo que responde a las alertas de producción, la calidad del código aumenta drásticamente por una simple cuestión de supervivencia y responsabilidad profesional.

¿Qué es DevOps en la práctica?

DevOps no es un simple cargo; es una cultura de trabajo. Nace cuando los desarrolladores asumen la responsabilidad directa sobre la disponibilidad y rendimiento de sus aplicaciones en producción. Si bien hoy existen especialistas con el título de «Ingeniero DevOps», su propósito no debe ser actuar como un nuevo silo o policía de despliegues, sino diseñar plataformas de autoservicio (Platform Engineering) que habiliten y empoderen a los desarrolladores.

Es una fantasía pensar que un desarrollador de software dominará con maestría las decenas de herramientas de infraestructura existentes. Por ello, el especialista en DevOps debe estructurar las herramientas para que los equipos de desarrollo tomen decisiones informadas y autónomas. La verdadera libertad de desarrollo requiere infraestructura como servicio interno: desde el despliegue automático de una versión o la consulta de logs y métricas, hasta la provisión segura de bases de datos y accesos.

En resumen: DevOps es el marco cultural que otorga libertad a los desarrolladores a cambio de que asuman la responsabilidad de sus sistemas en el mundo real.

¿Pero sí deben saber programar o no?

Esta duda se responde casi sola al observar el acrónimo: ¿qué significa la sílaba «Dev» (Development) si no es desarrollo de software? Sin embargo, en el mercado existen profesionales de infraestructura excelentes que, aunque no dominen la escritura de código de aplicación (el software que ve el usuario), poseen conocimientos muy profundos en redes, administración de sistemas operativos, bases de datos y seguridad. Su labor de desarrollo no se enfoca en la lógica del negocio, sino en la automatización de la infraestructura (escribiendo scripts en Bash o Python, o configurando herramientas como Terraform y Kubernetes). Su valor radica en la consultoría interna, diseñando arquitecturas y colaborando con programadores para agilizar el flujo de trabajo.

A pesar de ello, en mi experiencia, los mejores resultados provienen de dos perfiles específicos: desarrolladores que se interesaron por la infraestructura y el despliegue de sus sistemas, o ingenieros de operaciones tradicionales que aprendieron a programar con solidez. El factor común de su éxito es la empatía. Al haber estado en ambos lados de la trinchera, entienden perfectamente los dolores de cada rol.

La automatización no es solo técnica; es la eliminación de la fricción humana mediante acuerdos claros y herramientas confiables. La libertad de desplegar software a voluntad no es un regalo gratuito: se gana asumiendo la responsabilidad técnica de su ejecución.

---

¿Qué opinas sobre este choque cultural en tu organización? ¿Has visto cómo la falta de responsabilidad envenena la colaboración entre equipos?

Si quieres profundizar en cómo construir organizaciones más sanas y responsables, te recomiendo leer mi artículo sobre ¿Cómo conseguir talento para mi organización?.