Cerrar

DevOps: cómo romper la barrera entre Desarrollo y Operaciones

¿Qué es DevOps?

DevOps nos dio ventaja

“DevOps nos ha ayudado a realizar publicaciones muy frecuentes, dándonos ventaja en los plazos de comercialización. Ahora podemos realizar publicar productos a diario, comparado con las publicaciones semestrales, y brindar soluciones a nuestros clientes en cuestión de horas.”

— Hamesh Chawla, vicepresidente de Ingeniería de Zephyr

DevOps es un conjunto de prácticas que automatizan los procesos entre los equipos de desarrollo de software y TI para que puedan compilar, probar y publicar software con mayor rapidez y fiabilidad. El concepto de DevOps se basa en establecer una cultura de colaboración entre equipos que, tradicionalmente, trabajaban en grupos aislados. Entre las ventajas que promete, se incluyen el aumento de la confianza y de la velocidad de publicación de software, la capacidad de solucionar incidencias críticas rápidamente y una mejor gestión del trabajo imprevisto.

En Atlassian, DevOps es el compuesto de moda más famoso, después de Brangelina (Brad Pitt + Angelina Jolie), y une lo mejor del desarrollo de software y las operaciones de TI. Y, al igual que nuestras bromas, requiere cierta explicación. 

En esencia, DevOps es una cultura, un movimiento, una filosofía.

Es un firme apretón de manos entre Desarrollo y Operaciones que pone de relieve un cambio de mentalidad, una mejor colaboración y una integración más sólida. Aúna la metodología ágil, la entrega continua, la automatización, etc., etc., para que los equipos de desarrollo y operaciones sean más eficientes, innoven antes y aporten más valor a los negocios y los clientes.

Historia de DevOps

El movimiento DevOps empezó a fusionarse entre el 2007 y el 2008, cuando las comunidades de operaciones de TI y desarrollo de software manifestaron claramente lo que veían como un nivel fatal de disfunción del sector.

Se alzaron contra el modelo tradicional de desarrollo de software, que exigía que los que escribían el código se mantuvieran al margen, en términos de organización y operación, de los que desplegaban y mantenían tal código.

Los desarrolladores y profesionales de TI/Operaciones tenían objetivos distintos (y, a menudo, rivales), direcciones de departamento independientes, indicadores clave del rendimiento diferentes por los que se les evaluaba y, con frecuencia, trabajaban en plantas separadas o, incluso, en edificios separados. El resultado eran equipos aislados únicamente preocupados por sus propios dominios, largas jornadas, publicaciones chapuceras y clientes insatisfechos.

Tiene que haber un método mejor, dijeron. Así pues, las dos comunidades se juntaron y se pusieron a hablar, con gente como Patrick Dubois, Gene Kim y John Willis al frente de la conversación.

Lo que empezó en foros de internet y reuniones locales es ahora uno de los aspectos principales del ámbito del software actual, y seguramente lo que te ha traído hasta aquí. Tú y tu equipo estáis sufriendo el dolor causado por equipos encasillados y líneas de comunicación rotas dentro de la empresa.

Estás utilizando metodologías ágiles en la planificación y el desarrollo, pero te sigue costando sacar ese código sin montar un drama. Has oído hablar de DevOps y el efecto aparentemente mágico que puede causar en los equipos, y te has dicho: “Yo quiero un poco de esa magia”.

Lo malo es que DevOps no es mágico, y los cambios no se dan de la noche a la mañana. Lo bueno es que no hay que esperar a que la alta dirección lance una iniciativa a gran escala. Teniendo en cuenta el valor de DevOps e implantando pequeños cambios de forma gradual, tu equipo se puede embarcar en el viaje hacia DevOps inmediatamente. Veamos cada una de esas ventajas en profundidad.

La infraestructura como código nos permitió llevar a cabo 10 veces más compilaciones sin tener que añadir ni una sola persona al equipo. — Michael Knight, ingeniero de compilación de Atlassian

¿Y tú qué ganas?

Colaboración y confianza

La cultura es el principal factor de éxito de DevOps. Crear una cultura de responsabilidad compartida, transparencia y feedback más rápido es la base de los equipos de DevOps de alto rendimiento.

Normalmente, los equipos que trabajan en grupos aislados no se adhieren al 'pensamiento sistémico' de DevOps. El 'pensamiento sistémico' consiste en ser consciente de que tus acciones no solo afectan a tu equipo, sino a todos los equipos involucrados en el proceso de publicación. La falta de visibilidad y  objetivos compartidos se traduce en falta de planificación de dependencias, prioridades mal organizadas, acusaciones personales y una actitud de 'no es problema mío', provocando una disminución de la velocidad y la calidad. DevOps es ese cambio de mentalidad con el que se tiene una visión holística del proceso de desarrollo y se rompe la barrera entre Dev y Ops.

Publicaciones más rápidas y una forma de trabajar más inteligente

La velocidad lo es todo. Los equipos que practican el DevOps publican con mayor frecuencia, calidad y estabilidad.

La falta de automatización en las pruebas y los ciclos de revisión bloquea la publicación de producción, y un tiempo de respuesta insuficiente ante las incidencias fulmina la velocidad y la seguridad del equipo. Trabajar con herramientas y procesos variados aumenta el OPEX, provoca cambios de contexto y frena el ritmo. Gracias a la automatización y las herramientas y procesos unificados, los equipos pueden aumentar la productividad y publicar con más frecuencia y menos disgustos.

Acelerar el tiempo de resolución

El equipo con el ciclo de feedback más rápido es el equipo que prospera. Con una transparencia total y una comunicación fluida, los equipos de DevOps reducen al mínimo el tiempo de inactividad y resuelven las incidencias más rápido que nunca.

Si las incidencias críticas no se solucionan con rapidez, la satisfacción del cliente se viene abajo. Las incidencias clave se escapan entre las fisuras a falta de una comunicación abierta, provocando el aumento de la tensión y la frustración entre los equipos. Gracias a una comunicación abierta, los equipos de desarrollo y operaciones se vuelcan en las incidencias, corrigen los errores y desbloquean antes el canal de publicación.

Mejor gestión del trabajo imprevisto

El trabajo imprevisto es una realidad a la que se enfrentan todos los equipos: una realidad que casi siempre repercute en la productividad del equipo. Con procesos establecidos y una definición clara de las prioridades, los equipos de desarrollo y operaciones pueden gestionar mejor el trabajo imprevisto sin dejar de lado el trabajo planificado.

La transición y priorización del trabajo imprevisto entre distintos equipos y sistemas no es eficiente y distrae de las labores pendientes. Sin embargo, con una mayor visibilidad y una retrospectiva proactiva, los equipos pueden anticipar y compartir mejor el trabajo imprevisto.

Cultura

Si la cultura de DevOps se pudiera resumir en una palabra, esta sería “colaboración” y, mejor aún, “colaboración transversal”. (Vale, eso son más bien dos.)

Todas las herramientas y automatizaciones del mundo no sirven para nada si no van acompañadas de una voluntad real de trabajar juntos por parte de los profesionales de Desarrollo y TI/Operaciones, porque DevOps no soluciona los problemas relacionados con herramientas, sino los problemas humanos. Por lo tanto, sería raro que un día te asomaras desde el cubículo, miraras alrededor y descubrieras que los equipos de tu empresa reflejan la cultura de DevOps. Pero sí hay algunas cosas sencillas que puedes hacer para cultivarla.

Piensa en DevOps como una metodología ágil, pero con las operaciones incluidas. Formar equipos con una orientación hacia los proyectos o los productos que sustituyan equipos basados en funciones es dar un paso en la dirección correcta. Incluye desarrollo, control de calidad, gestión de productos, diseño, operaciones, gestión de proyectos y cualquier otro conjunto de aptitudes que requiera el proyecto. En Atlassian, incluso integramos el marketing en nuestros equipos de producto.

Pocas cosas fomentan tanto la colaboración como compartir un objetivo común y tener un plan para alcanzarlo juntos. En algunas compañías, cambiar de repente a equipos basados en proyectos resulta algo excesivo y precipitado. Así que mejor ir a paso lento. Los equipos de desarrollo pueden (y deben) invitar a los miembros adecuados del equipo de operaciones a unirse a las sesiones de planificación de sprints, las reuniones rápidas diarias y las demostraciones de sprints. Los equipos de operaciones pueden invitar a desarrolladores clave. Es una forma ágil y orgánica de estar al tanto de los proyectos, las ideas y las dificultades de los demás. El tiempo invertido en escuchar y enriquecer conocimientos de esferas temáticas se amortiza consiguiendo una gestión de publicaciones y una resolución de urgencias mucho más eficientes.

Y, hablando de urgencias, constituyen una prueba efectiva de la cultura de DevOps. ¿Se vuelcan Desarrollo, Operaciones y Atención al cliente en el problema y lo resuelven como equipo? ¿Empiezan todos dando por hecho que sus compañeros de equipo tomaron las mejores decisiones posibles con la información y los recursos con que contaban entonces? ¿La incidencia se trata a toro pasado corrigiendo procesos en lugar de señalando a alguien con el dedo? Si la respuesta es afirmativa, es una buena señal de que tu equipo trabaja con la cultura de DevOps en esencia.

Ten en cuenta que las empresas de mayor éxito aprueban la cultura de DevOps en todos los departamentos y a todos los niveles del organigrama. Cuentan con canales abiertos de comunicación y los emplean habitualmente. Se aseguran de que los objetivos de todos vayan a la par, y los ajustan según sea necesario. Asumen que mantener al cliente satisfecho es tanto responsabilidad de la gestión de productos como del equipo de desarrollo. Entienden que DevOps no es el trabajo de un solo equipo. Es el trabajo de todos.

Automatización

Invertir en automatización suprime el trabajo manual repetitivo, genera procesos reproducibles y crea sistemas fiables.

Compilar, probar, desplegar y automatizar son los puntos de partida típicos de los equipos que aún no la han puesto en práctica. Oye, ¿y qué mejor motivo para que Desarrollo, Pruebas y Operaciones trabajen juntos que construir sistemas que los beneficien a todos?

Los equipos que son nuevos en la automatización suelen empezar con la entrega continua: la práctica de ejecutar cada cambio en el código mediante un puñado de pruebas automatizadas, a menudo facilitadas por una infraestructura basada en la nube, a continuación empaquetar compilaciones satisfactorias y promoverlas hasta producción con despliegues automatizados. Como puedes imaginar, la entrega continua no es una tarea fácil y rápida de preparar, pero la rentabilidad de la inversión bien merece la pena.

¿Por qué? Los ordenadores ejecutan las pruebas con mayor rigor y exactitud que los seres humanos. Estas pruebas detectan antes los errores y los fallos de seguridad, por lo que los desarrolladores los pueden corregir más fácilmente. Y los despliegues automatizados alertan a TI y Operaciones de los “desajustes” del servidor entre entornos, lo cual reduce o acaba con las sorpresas cuando ha llegado la hora de publicar.

Otra de las contribuciones principales de DevOps es la idea de “configuración como código”. Los desarrolladores procuran crear aplicaciones modulares que admiten composición porque son más fiables y fáciles de mantener. La misma filosofía se puede aplicar a la infraestructura que las aloja, ya esté en la nube o en la red de la propia compañía.

Es verdad, los sistemas siempre están cambiando, pero podemos crear una facha de inmutabilidad utilizando código en el aprovisionamiento de modo que reaprovisionar un servidor dañado sea más rápido que repararlo, y no digamos más fiable. Además, reduce riesgos. Tanto Desarrollo como Operaciones pueden incorporar nuevos lenguajes o tecnologías mediante el código de aprovisionamiento y compartir las actualizaciones entre ellos. Las incidencias de compatibilidad resultan evidentes de forma inmediata, en lugar de manifestarse a media publicación.

La “configuración como código” y la “entrega continua” no son los únicos tipos de procesos automatizados que se observan en el mundo de DevOps, pero merecen una mención especial porque ayudan a derribar la barrera que hay entre el desarrollo y las operaciones. Y cuando DevOps utiliza despliegues automatizados para enviar código probado a conciencia a entornos de idéntica provisión, el “¡A mí me funciona!” deja de funcionar.

Infalible

Cuando nos dicen “infalible” en un contexto de software, solemos pensar en suprimir actividades de escaso valor y avanzar rápido: ser enérgico, ser ágil. Más oportunos aún para DevOps son los conceptos de mejora continua y aceptación de los errores.

Una mentalidad de DevOps ve oportunidades de mejora continua en todas partes. Algunas resultan obvias, como mantener retrospectivas periódicas para mejorar los procesos del equipo. Otras son más sutiles, como las pruebas A/B en distintos métodos de incorporación para nuevos usuarios del producto.

Al desarrollo ágil le agradecemos el haber convertido la mejora continua en una idea corriente. Los primeros en adoptar la metodología ágil demostraron que un producto sencillo en manos de los clientes hoy tiene más valor que un producto perfecto en manos de los clientes dentro de seis meses. Si el producto se mejora continuamente, los clientes no se marcharán.

¿Y sabes qué? Cometer errores es inevitable. Así que es como si prepararas al equipo para asumirlos, recuperarse y aprender de ellos (algunos lo llaman “ser antifrágil”). En Atlassian pensamos que, si no te equivocas de vez en cuando, es que no te estás esforzando lo suficiente.

Desafiamos a nuestros equipos con objetivos osados y peliagudos y nos aseguramos de que dispongan de la autonomía y los recursos necesarios para alcanzarlos. Contratamos a personas inteligentes y ambiciosas, y no esperamos que sean siempre infalibles.

En el contexto de DevOps, equivocarse no es un delito punible. Los equipos tienen asumido que las cosas están destinadas a torcerse en algún momento, así que trabajan para conseguir detecciones y recuperaciones rápidas. (Lee acerca del Chaos Monkey de Netflix para ver un buen ejemplo de ello.) Los análisis a toro pasado se centran en qué fallaron los procesos y cómo reforzarlos, no en qué miembro del equipo se cargó el código. ¿Por qué? Porque la mejora continua y el fracaso van de la mano.

DevOps ha evolucionado de modo que Desarrollo posee más operaciones, y así es como funciona Chef. No podemos seguir pasándonos la pelota. Nuestros ingenieros se encargan del control de calidad, la escritura de código y la ejecución de sus propias pruebas para sacar el software para los clientes. — Julian Dunn, gestor de productos de Chef

Medición

Sin datos, es difícil demostrar que su esfuerzo continuo por mejorar esté mejorando algo en efecto. Por suerte, hay un montón de herramientas y tecnologías para medir el rendimiento: cuánto tiempo pasan los usuarios con su producto, si esa entrada del blog ha generado alguna venta o con cuánta frecuencia aparecen alertas críticas en los registros.

Aunque se puede medir casi todo, eso no quiere decir que lo tengas que medir todo. Sigue el ejemplo del desarrollo ágil y empieza por lo básico:

  • ¿Cuánto tiempo llevó pasar del desarrollo al despliegue? 
  • ¿Con qué frecuencia tienen lugar errores o fallos?
  • ¿Cuánto se tarda en recuperarse tras un fallo del sistema?
  • ¿Cuántas personas utilizan su producto en este momento?
  • ¿Cuántos usuarios has ganado o perdido esta semana?

Sobre una base sólida implantada, cuesta menos detectar métricas más sofisticadas del uso de las funcionalidades, el recorrido de los clientes, y los SLA (acuerdos de nivel de servicio). La información que se obtiene viene muy bien a la hora de confeccionar hojas de ruta y especificar el siguiente gran paso.

Con todos estos datos jugosos, tu equipo puede tomar decisiones, pero resultan aún más útiles cuando se comparten con otros equipos, sobre todo si son de otros departamentos. Por ejemplo, el equipo de marketing quiere tener funcionalidades nuevecitas que vender. Mientras tanto, observas una alta rotación de clientes, porque el producto está plagado de deuda técnica. Al aportar datos de los usuarios útiles para la hoja de ruta, aunque no profundicen en funcionalidades y sí en correcciones, es más fácil lograr consenso y obtener adquisiciones de las partes interesadas.

DevOps no es el trabajo de una persona sola. Es el trabajo de todos. — Christophe Capel, gestor de productos principal, Jira Service Desk

Compartir

La antigua fricción entre los equipos de desarrollo y operaciones se debe en gran medida a una falta de puntos en común. Creemos que compartir responsabilidades y logros representará un importante avance para zanjar esa división. Los desarrolladores pueden aumentar su buena voluntad de manera instantánea ayudando a soportar una de las cargas más pesadas de Operaciones: el localizador. En DevOps gusta la idea de que las personas que compilan una aplicación se involucren también en su lanzamiento y ejecución.

Esto no quiere decir que contrates desarrolladores esperando directamente que también dominen las operaciones. Lo que significa es que Desarrollo y Operaciones se unan en todas las fases del ciclo de vida de la aplicación.

Los equipos que adoptan DevOps suelen tener una función rotativa en la que los desarrolladores tratan las incidencias detectadas por los usuarios finales, mientras que solucionan problemas de producción al mismo tiempo. Esta persona da respuesta a las incidencias urgentes que los clientes han notificado, creando parches cuando haga falta, y trabaja con el backlog de los defectos notificados por clientes. El “desarrollador de apoyo” aprende mucho sobre el uso que se le da a la aplicación en la vida real. Y gracias a su gran disponibilidad para con el equipo de operaciones, los equipos de desarrollo fomentan la confianza y el respeto mutuo.

Dejarse la piel juntos en los momentos difíciles hace disfrutar mucho más de los logros. Sabrás que la cultura de DevOps ha calado en tu empresa cuando veas que el equipo de desarrollo le lleva dónuts al de operaciones el día de publicación.

El feedback positivo de los compañeros nos motiva tanto como nuestras ambiciones profesionales o la nómina. Reconocer públicamente a un compañero de equipo que ha detectado un molesto error antes de que salga a la calle es muy importante. Si tu departamento tiene un presupuesto ilimitado para gratificar a los empleados, ¡no lo desaproveches!

¿Estás listo para emprender el viaje de DevOps?

Emprende el viaje