Llegamos a ustedes gracias a:



Reportajes y análisis

Fracasos de DevOps en el mundo real -y cómo evitarlos

DevOps

[24/07/2016] Todo sobre DevOps suena muy bien. Es una práctica centrada en la colaboración y la comunicación entre los desarrolladores de software y otros miembros del personal de TI y de gestión, mientras automatizan tareas tales como actualizaciones de entrega de software y de infraestructura.

Con DevOps, el desarrollo, prueba y lanzamiento del software se puede acelerar y hacer más fiable, y eso es de vital importancia para las empresas que buscan sobrevivir en un mercado ultra competitivo.

Hay muchos ejemplos de cómo funciona DevOps de manera adecuada, y cómo ofrece mejoras tangibles para las empresas en una variedad de industrias. Pero a veces no funciona bien. Las cosas con DevOps pueden salir mal al igual que con cualquier otro aspecto de TI.

A continuación, presentamos algunos ejemplos de iniciativas DevOps que fallaron en por lo menos un nivel, y lo que hicieron las organizaciones implicadas para hacer frente a los problemas o evitar que vuelvan a suceder.

La falta de una visión de proyecto

IBM comenzó lo que se convertiría en la incursión de la compañía en DevOps en el 2003 -años antes de que se acuñe el término- cuando se puso en marcha una iniciativa de desarrollo Agile de software para uno de sus nuevos productos. La empresa invirtió en Agile, un conjunto de principios para el desarrollo de software que estimula una respuesta rápida y flexible a los cambios, ya que quería acelerar sus versiones de software para los clientes.

Fue una tarea menos que exitosa. "El problema con Agile es que solo te lleva un poco más allá", anota Mustafa Kapadia, líder de la línea de DevOps y de nube para América del Norte de Global Business Services en IBM. "La parte de desarrollo fue muy rápida, pero las operaciones respondieron de forma lenta, por lo que en realidad no importaba. Los clientes no obtuvieron productos más rápido".

La empresa, como parte de un movimiento hacia DevOps, decidió automatizar el despliegue de código, además de adherirse a la metodología Agile. Pero eso tampoco hizo que el ciclo de entrega de software fuera más rápido. IBM llevó a cabo un "análisis de la cadena de valor", y encontró que el mayor impedimento no era Agile o la automatización, sino el desarrollo y el medio ambiente operacional en general. Incluso, con estos diversos esfuerzos para acelerar el desarrollo del producto, todavía hubo mucho tiempo de retraso en la finalización del proyecto.

En última instancia, la debacle de DevOps de IBM se debió a una falta de visión por aquellos que pusieron estos esfuerzos en su lugar, señala Kapadia. "Hubo que responder algunas preguntas básicas y determinar los problemas que estábamos tratando de resolver. Ahí es donde fallamos", añade. "Si no sabe cómo se hace realmente el trabajo, no sabe cuáles son los problemas que valen la pena resolver. Nos aferramos a problemas imaginarios que vinieron de la charlatanería del proveedor, no de ver lo que realmente nos desaceleraba".

Una vez que los gerentes tuvieron una mejor comprensión de los flujos de trabajo y donde estaban los procesos lentos, fueron capaces de hacer cambios y obtener valor real de DevOps.

Demasiado acceso - educación insuficiente

Ya en el 2006, cuando el sitio web para compartir contenido SlideShare (ahora parte de LinkedIn) era un pequeño emprendimiento con menos de 20 empleados, se puso en marcha un modelo DevOps para acelerar los procesos y mantenerse por delante de su competencia.

"El equipo de desarrollo fue dividido entre San Francisco y Nueva Delhi, y la infraestructura era bastante complicada", comenta Sylvain Kalache, co-fundadora de la Holberton School, una institución que forma a ingenieros de software, y que trabajaba con SlideShare en el momento.

Los objetivos de DevOps eran lograr la máxima eficacia en el equipo de ingeniería, y difundir conocimientos técnicos tanto como sea posible; de modo que, si alguien se iba de vacaciones o dejaba la compañía, habría un impacto limitado.

"Trabajar en un ambiente DevOps impulsa a que cada colaborador trabaje y contribuya a las diferentes partes del producto", explica Kalache. "Tener un equipo cohesionado es súper importante, y esto pasa por hacer que las personas interactúen y se ayuden unos a otros".

Una de las ideas principales detrás de DevOps es un mayor sentido de la propiedad de las responsabilidades del trabajo", y para eso se necesita dar acceso a parte de la infraestructura que por lo general no es accesible a los trabajadores", anota Kalache. Mientras trabajaba en SlideShare, los ingenieros tuvieron acceso a los servidores de producción y bases de datos de producción.

Un ingeniero de software trabajó en un proyecto relacionado con la base de datos y probó una herramienta que ofrece la posibilidad de explorar una base de datos MySQL de forma gráfica. "Él decidió reorganizar las columnas de base de datos" en la herramienta para que los datos tengan más sentido para él", indica Kalache. "Lo que él no sabía era que en realidad también cambiaba el orden de las columnas en la producción en la base de datos real, bloqueándola, lo que hizo caer SlideShare.net".

Cuando eso pasó, la persona responsable no se dio cuenta de que la herramienta estaba ejecutando acciones. Pasaron 15 minutos de esfuerzo colectivo para averiguar el origen del problema.

"Aprendimos dos lecciones de este fracaso", indica Kalache. "En primer lugar, mientras que DevOps presiona para que todos tengan un impacto en cualquier etapa del ciclo de producto/servicio, es una buena práctica dar un paso atrás cada vez que da acceso a algo y asegurarse de que es realmente valioso. En esta situación específica de la interrupción de la base de datos, nos dimos cuenta de que dar acceso a los datos de producción en realidad no era útil en absoluto y era muy peligroso. El desarrollador podría haber extraído el mismo valor exacto mediante el uso de una base de datos provisional, pero con un impacto de mucho menor importancia en la empresa".

La segunda lección es educar mejor a los desarrolladores sobre el funcionamiento de la infraestructura. "Muchos de ellos nunca han estado expuestos a la infraestructura de producción", explica Kalache. "DevOps se basa en una forma de trabajar, lo que obviamente es más acerca de la interacción humana. No se puede esperar que todos sepan naturalmente 'las reglas ocultas'. Por eso la capacitación es obligatoria y fundamental".

Cobertura insuficiente de DevOps

A veces, el fracaso proviene de la forma en que se aplica a un proyecto DevOps en particular.

Una empresa dedicada a la renta de vehículos tiene un gran número de socios repartidos por todo Estados Unidos. Cualquier cliente que entra en una ubicación afiliada y quiere arrendar vehículos tendrá su información y solicitud procesada a través de una aplicación personalizada. Una gran parte de esta información tiene que ser verificada a través de los servicios de terceros, ya que esta es una operación financiera y ninguna de las empresas financieras que participan quiere ser atrapada celebrando un mal arrendamiento.

"La configuración DevOps para este software se centra en las medidas del servidor, sobre todo los tiempos de respuesta y averías para diversas solicitudes, junto con las estadísticas de implementación y automatización", señala Nathaniel Rowe, un consultor de software que trabajó con la compañía de arrendamiento, quien se negó a identificarse.

"Hace unas semanas tuvimos lo que equivalía a un corte total del sistema, debido a un agujero en el seguimiento", anota Rowe. "Un servicio de validación de terceros necesario tuvo un corte en la red que hizo caer a toda su infraestructura".

Esto no debió haber sido un problema, explica Rowe. Sin embargo, debido a la construcción mediocre inicial del software -que se hizo offshore por un precio de ganga- todos los procesos de presentaciones de arrendamiento estaban vinculados estrechamente con el servicio que se cayó. "En una empresa como ésta, eso significa que el dinero deja de fluir", añade.

El problema era la completa falta de cobertura DevOps, debido a la dependencia en las medidas del sistema; en lugar de añadir vigilancia activa de los recursos externos que fueron necesarios para que las operaciones continuasen. "Ese fue un agujero de baja visibilidad en nuestra cobertura, que fue enmascarada por el hecho de que el 99% de los problemas están basados explícitamente en código en lugar de una interferencia exterior", anota Rowe.

Una vez que la interrupción se dio a conocer, el equipo de desarrollo entró en juego y desacopló el código de validación particular e insertó procedimientos para prescindir de ello, lo que permitió a los socios de la compañía guardar la información que habían ingresado al sistema.

"Identificamos la causa poniéndonos en contacto con el proveedor del servicio y recibiendo la información sobre lo que pasó", indica Rowe. "Para protegernos de eso en el futuro, cada vez que ocurre una falla en la red como la acontecida, se dispara una configuración global para reencaminar el proceso de envío, y salvar con éxito y notificar a los socios que el servicio correspondiente se ha caído."

Una ventaja importante de este fracaso fue que el tiempo y el dinero ahora se dedica a parchar los agujeros en el seguimiento y la recuperación automática de otros puntos débiles en el sistema, agrega Rowe.

Olvidarse de las personas y los procesos

Cuando Brian Dawson, ahora evangelista de DevOps en CloudBees, estaba trabajando como consultor de procesos para un vendedor que tenía un contrato con una agencia del gobierno de Estados Unidos hace varios años, tuvo una de sus primeras experiencias con DevOps. Y no fue buena.

La agencia estaba lanzando un proyecto importante para construir una aplicación web. "Como proveedor responsable del proceso ALM [gestión del ciclo de vida de la aplicación, por sus siglas en ingles], nos propusimos establecer herramientas y procesos que abarcaban definición y planificación, el código y el compromiso, y la construcción y liberación, todo hecho inspirado en el código abierto y colaborativo", indica Dawson.

El despliegue y la configuración de las herramientas DevOps de soporte se hizo correctamente, añade Dawson. "Desafortunadamente, los DevOps no pueden ser aplicados estrictamente solo con las herramientas", advierte. "DevOps requiere la misma atención que la gente o la cultura, procesos y herramientas".

En el proyecto involucraba varios equipos en un plazo fijo, y apretado, de gestión para buscar una solución rápida y se centraba principalmente en la plataforma de herramientas. "Hemos sido capaces de construir una plataforma que incluye herramientas robustas de planificación Agile, SMC [gestión de configuración de software, por sus siglas en inglés] moderna, y Jenkins para la integración continua, todo desplegado en una plataforma algo elástica, escalable".

Sin embargo, la agencia ignoró a las personas y parte del proceso de DevOps, y no pudo ganar la aceptación por parte de los desarrolladores y otras partes interesadas que se necesitan para construir una estrategia DevOps.

"Esto quiere decir que a pesar de que tuvimos una 'plataforma DevOps', se utilizó con eficacia para apoyar las mismas viejas prácticas heredadas", indica Dawson. "Los desarrolladores difirieron, fundieron e integraron; automatizaron el control de calidad y liberaron lo que aún no se aplicaba plenamente; las build rotas no fueron gran problema, y las cargas de producción en entornos de producción nunca fueron probadas".

Cuando el cliente liberó la aplicación web, inmediatamente experimentó fallos críticos y muy públicos, ya que no había sido probada con regularidad en un entorno de producción o por usuarios reales. Además, una vez que los problemas se hicieron evidentes, solucionar los problemas y hacer que el sitio funcione, tomó varias semanas y ciclos de desarrollo. Los tiempos de respuesta lentos sirven para exagerar el impacto de los fracasos iniciales.

Los problemas técnicos se repararon en pocos meses, pero reparar la causa raíz -incluyendo clarificar a los propietarios del proyecto para asegurarse de que se abordaron los procesos culturales y las facetas de DevOps- fue multifacética y abarcó muchos meses más, indica Dawson.

Solo entonces la agencia fue "capaz de completar adecuadamente DevOps en todos los planos de personas, procesos y herramientas", indica Dawson.

DevOps sin duda ofrece una gran promesa en la aceleración de los ciclos de entrega de software, pero le toca a usted y a su equipo cumplir esa promesa con una cultura y prácticas cohesivas de DevOps.

Bob Violino, InfoWorld (EE.UU.)