DevOps en la gran empresa: por qué deberías operar lo que desarrollas

Es una situación, desgraciadamente, demasiado común: estás con tu familia cuando, de repente, el móvil roba tu atención. Esa tan temida alerta que nos avisa de un fallo de SEV1. Nuestra aplicación, esa que periódicamente sufre fugas de memoria y que el departamento de Operaciones “soluciona” reiniciándola, está agotando los recursos de los servidores, apenas unos minutos después de haberla puesto en marcha. A efectos prácticos, la aplicación resulta inservible. El equipo de Operaciones no cuenta con los medios para hacer nada que no sea reiniciar la aplicación o revertirla a una versión anterior. Pero la última copia útil es de hace ya meses. Quién sabe qué ha cambiado dese entonces. Te correspondería a ti solventar las pérdidas de memoria, pero estás a miles de kilómetros de la oficina y de tu ordenador.

Incidentes de este tipo se producían con demasiada frecuencia en las empresas que seguían modelos informáticos tradicionales, en los que Desarrollo y Operaciones trabajaban separadamente. Sin embargo, las cosas no tienen por qué ser así. DevOps no es algo exclusivo de las start-ups. También las grandes empresas pueden valerse de este concepto. Como sucede con la automatización y la atención al cliente, “operar lo que desarrollas” puede ser un principio igualmente válido a la hora de mejorar la actuación de un departamento informático, empleando el modelo DevOps.

En los entornos tradicionales, los desarrolladores diseñan y programan la solución, para luego delegársela a Operaciones. En ocasiones, Desarrollo tiene la deferencia de ofrecer asesoramiento a la hora de lidiar con problemas de producción, mientras que en otros casos tienen poco o ningún conocimiento del entorno de producción como para poder ayudar. Cuando estos equipos se mantienen separados, ninguno de ellos cuenta con la información necesaria sobre cómo el otro trabaja y cuáles son sus necesidades. El equipo de Operaciones suele contar con documentación y manuales, procedimientos operativos estándar  y otros recursos para responder a los posibles problemas que puedan surgir en la producción. Este tipo de recursos pueden resultar muy efectivos cuando el problema debe solucionarse de forma rápida y sencilla. Sin embargo, cuando no es posible identificar las causas del problema para solucionarlo, usar estos materiales es como intentar reparar la fuga de un barco usando chicles. Con el tiempo, el barco se va a hundir.

DevOps puede ofrecer una manera mejor de hacer las cosas...

La nube ha contribuido a derribar estos muros porque en la nube la infraestructura pasa a ser una cuestión de software. La propia esencia de la nube, tan centrada en APIs, nos permite tratar nuestras infraestructuras como si fueran código, algo que los desarrolladores entienden de forma instintiva. Cuando todo el equipo está mucho más cerca de la infraestructura, Operaciones pasa a convertirse en un requisito clave, en un proceso natural.

Además el software se ofrece cada vez más como un servicio (SaaS), y los clientes piden mejoras de forma constante. Los clientes pueden tolerar pequeños problemas aquí y allá, pero solo cuando estos se solucionan rápidamente y no vuelven a producirse. Para poder seguir el ritmo del cambio, deberemos estar atentos a las pistas y señales que los clientes no nos estén comunicando directamente. Como tú, ellos están atareados con otras cuestiones por lo que, cuando te llaman para darte sus impresiones, lo más probable es que lo hagan porque no están satisfechos. Aunque toda interacción con un cliente es una oportunidad para aprender, lo más conveniente es que estas interacciones sean siempre en tus términos. Estas señales resultan mucho más difíciles de identificar cuando hay un muro separando Desarrollo y Operaciones. Suele darse el caso de que Operaciones esté dando carpetazo a problemas menores mediante soluciones de urgencia, y los desarrolladores, por su parte, no suelen aspirar a los mismos estándares de excelencia operativa si se sienten con demasiada seguridad.

Todas estas cuestiones son buenas razones para abandonar el modelo informático tradicional y realizar la transición a una cultura de DevOps, en la que Desarrollo y Operaciones se unen con un objetivo común. Personalmente, suelo animar a los ejecutivos a hacer de la filosofía “opera lo que desarrollas” un pilar fundamental de sus organizaciones basadas en paradigmas DevOps. Estas son algunas de las ventajas y comportamientos que he visto florecer en las organizaciones que han adoptado esta filosofía:

• Diseños pensados para la producción. “Opera lo que desarrollas” fuerza a los equipos de desarrollo a plantearse cómo va a funcionar el software una vez esté en producción, desde el momento en que el software entra en fase de diseño. Esto ayuda a los equipos a evitar las prisas de última hora que suelen producirse cuando los equipos intentan llevar software a entornos de producción de forma forzada, con tal de cumplir sus plazos. He perdido la cuenta de las veces que he visto esta actitud ir en detrimento de la calidad del software. Por ejemplo, es habitual realizar cambios de última hora durante el despliegue, buscando paliar las diferencias entre los entornos de producción y de desarrollo y llevar a cabo las pruebas que uno considera relevantes, para luego descubrir que estos cambios han dado pie a bugs en otra parte del sistema.

• Una mayor autonomía para los empleados. La mentalidad “opera lo que desarrollas” fomenta la responsabilidad sobre el proyecto lo que, a su vez, redunda en empleados más independientes y responsables, y en un mayor desarrollo profesional en la organización. 

• Una mayor transparencia. Nadie quiere verse interrumpido en su tiempo personal. Quien sea que reciba todas las llamadas hará cuanto esté en su mano para evitarlas. Es por ello que es natural que tus equipos quieran contar con una mayor transparencia en el entorno, e implementen sistemas de monitorización proactiva con los que identificar posibles problemas o patrones preocupantes antes de que se conviertan en problemas generalizados. Además de permitir identificar y resolver problemas antes de que se produzcan, esta transparencia hace mucho más sencillo identificar las causas últimas de los problemas que se acaban produciendo.

• Más automatización. Los desarrolladores odian las tareas manuales repetitivas, por lo que si descubren que tienen que hacer algo una y otra vez en producción para resolver un problema, hay más probabilidades de que den con la causa última del problema y automaticen las cosas en el proceso.

• Una mayor calidad en las operaciones. Conceptos como la transparencia y la automatización harán tus equipos más eficientes y seguirán elevando el listón de tu excelencia operativa.

• Más clientes satisfechos. La filosofía “opera lo que desarrollas” fuerza a todo el departamento de informática a entender mejor al cliente. Así, su conocimiento ya no se verá limitado a equipos de ventas o de gestión de productos, y será de increíble utilidad, pues contribuirá a crear un ciclo constante de mejora de los productos.

El artículo ha sido realizado por Stephen Orban, Director de estrategia para empresas de Amazon Web Services