DevOps en la dirección correcta para la empresa

Por marzo 15, 2018

El alentar al DevOps en una organización se reduce a cuatro principios sencillos

Si usted es hombre, y tiene ganas de visitar los baños en el aeropuerto Schipol de Ámsterdam, observará una cosa extraña grabada en los recipientes del mingitorio, justo a la izquierda del drenaje, está la imagen de una mosca, parece ser que, si usted les da a los hombres un blanco durante sus incursiones en los baños, podrán apuntarle a ella.

El resultado de esta idea sencilla: los derrames disminuyeron en un 80 por ciento, lo que se traduce en ahorros de mantenimiento… y bueno, una importante mejora en la experiencia del pasajero.

La “mosca en el mingitorio” es un ejemplo de lo que comúnmente se conoce como un “impulso”; las intervenciones que intentan mover a la gente en direcciones que hacen que su vida sea mejor (o en el aeropuerto de Schipol, más seca). Como se sugiere en el best sellerNudge: Improving Decisions about Health, Wealth, and Happiness” (Impulso: Mejorando las Decisiones sobre Salud, Riqueza y Felicidad), el impulso altera el comportamiento de las personas de forma previsible, sin prohibir las opciones ni modificar significativamente sus incentivos económicos.

Pensando en la mosca del baño, ¿qué tiene que ver este comportamiento con DevOps? Bueno, probablemente más de lo que usted piensa.

“El usar conocimientos de las ciencias del comportamiento para alentar a los equipos de TI a tomar mejores decisiones para sí mismos, para sus colegas y para los negocios, no es tan descabellado como parece”.

– Peter Waterhouse, Estratega Sénior de CA Technologies

Preparen, apunten, fuego!

En el apuro para liberar el software, es de naturaleza humana ir tras el objetivo equivocado, apresurando el desarrollo, pero olvidando a las plantas operativas y de soporte. Por supuesto que esto no es intencional, pero el hacer lo correcto en un programa o nivel de múltiples equipos, tiene a menudo un papel secundario con respecto al frenesí de la entrega basada en proyectos.

Además, el empoderamiento del estilo ágil, implica que los equipos son alentados a tomar sus propias decisiones para acelerar la entrega. Todo está muy bien, pero ¿qué sucede cuando la organización termina con varias bases de datos, lenguajes de codificación, tecnologías de contenedor, métodos de comunicación, configuraciones, implementaciones y herramientas de monitoreo?

Está probablemente bien en las primeras etapas de un proyecto, ¿pero quién le brinda soporte cuando todas las prioridades cambian y la gente continúa? Y tengan lástima del “equipo de limpieza de TI”, que son los que acaban absorbiendo todo el “legado” y tratan de averiguar dentro de toda la complejidad adicional de dónde provienen los malos olores (interrupciones y problemas de rendimiento).

Impulse lecciones provenientes del Reino Unido

Sin importar qué tan empoderados estén los equipos, ellos no siempre son proclives a preocuparse por la compatibilidad y optimizar el rendimiento de las aplicaciones. En lugar de esperar lo mejor y prepararse para lo peor, el aplicar conocimientos de comportamiento y la teoría del impulso podría ayudar a convencer a cualquier equipo de desarrollo forajido a hacer lo que es mejor para el negocio.

Afortunadamente, esto no implica incorporar imágenes de moscas en su código, sino aplicar una infraestructura desarrollada por el Equipo de conocimiento del comportamiento del Reino Unido (o acertadamente denominado unidad de Impulso) para influir en el comportamiento.

Según la unidad de Impulso, si desea alentar un comportamiento, él debe ser Sencillo, Atractivo, Social y Oportuno (EAST, por sus siglas en inglés). A pesar de que el trabajo de la unidad utiliza conocimiento del comportamiento para conformar políticas de gobierno y entrega de servicios, los cuatro principios pueden ser aplicados bajo el contexto de DevOps.

1. Facilítelo

El esfuerzo requerido para monitorear el rendimiento de las aplicaciones a menudo desalienta a los desarrolladores. Muy frecuentemente tienen que abandonar un conjunto de herramientas y tomar otro, lo que genera retrasos en la construcción y la entrega. Para solucionar esto, cada equipo puede recurrir a sus propias herramientas que no son transferibles, o peor aún, descuidar el rendimiento.

Impulsar a los desarrolladores a hacer lo correcto cuando se trata de rendimiento y compatibilidad, debe de ser fácil. Esto implica servir al conocimiento de rendimiento inmediatamente y bajo el contexto de su trabajo diario. Por lo tanto, si los desarrolladores desean conocer el impacto en el rendimiento de su código en una construcción, la información debe ser presentada conforme realizan esa construcción, junto con conocimiento granular de qué cambios de infraestructura y aplicaciones están causando problemas de rendimiento.

2. Hágalo atractivo

Según la unidad de Impulso, somos más propensos a hacer algo que nos llama la atención, incluyendo imágenes, color y personalización. Esto es cierto para los desarrolladores, pero muy difícil de lograr con las herramientas tradicionales de monitoreo del rendimiento, especialmente aquellas que inundan con alertas de correo electrónico, falsos positivos y ruido.

Un impulso hacia el rendimiento de la aplicación implica atraer la atención de los desarrolladores a todo lo que afecta a la experiencia del cliente (buena y mala). Esto no sucederá con sistemas de alertas basadas en reglas y consolas que se desplazan, sino desde nuevos abordajes de análisis que puedan tanto predecir problemas como prescribir soluciones bajo el contexto de los resultados de negocios deseados.

3. Hágalo Social

Como la unidad de Impulso dice, estamos integrados en redes y aquellas con las que entramos en contacto pueden guiar de manera positiva nuestras acciones. Esto es cierto, pero muy frecuentemente los equipos operan en silos y raramente colaboran para impulsar mejoras sistémicas.

Al igual que los gobiernos, los líderes de TI pueden fomentar la creación de redes para alentar comportamientos altamente colaborativos para difundirlos en toda la organización. Para las personas que están al frente esto podría ser tan básico como administradores de sistemas que asisten a reuniones ágiles y retrospectivas, pero las herramientas también pueden ayudar. Por ejemplo, proporcionando una única aplicación de colaboración que integre todos los flujos de trabajo de equipos, y haga evidentes los problemas críticos de rendimiento para que los equipos interfuncionales tengan un punto para reaccionar, decidir y resolver problemas, de forma colectiva.

4. Hágalo Oportuno

El tiempo importa para los desarrolladores. La información sobre el rendimiento de los sistemas de producción que se presenta es importante, pero menos impactante que la información entregada bajo el contexto de la rutina diaria de un desarrollador. Por lo tanto, para fomentar mejores comportamientos, el monitoreo debe  “cambiar hacia la izquierda”; proporcionando orientación temprana al desarrollador sobre los impactos en el rendimiento, en su mundo, en su código y en sus propios términos. Haga esto de forma consistente y observe el comportamiento de cambio de mentalidad de prevención de los problemas, hacia el impulsar y compartir mejoras tanto en arquitectura como en diseño.

El usar conocimientos de las ciencias del comportamiento para alentar a los equipos de TI a tomar mejores decisiones para sí mismos, para sus colegas y para los negocios, no es tan descabellado como parece. Como el impulso de la mosca, una aplicación útil con las herramientas adecuadas, puede ayudar a los equipos de forma colectiva a que se enfoquen conjuntamente en ofrecer un rendimiento de TI elevado.

Es mejor esto a que el negocio se moje los pies.

Lea más en blog.

Escrito por Peter Waterhouse
Marketing Director at CA
LinkedIn: @peterwaterhouse