Cerrando brechas: la importancia de la comunicación DevOps

Aunque la metodología DevOps ha estado con nosotros durante bastante tiempo, sigue siendo el centro de acaloradas discusiones. Las empresas lo quieren pero no están seguras de cómo abordarlo.

DevOps está en todas partes. Y si bien es una tendencia interesante, debe adaptarse a los productos, no al revés.

Pero algunas personas no lo ven así. A menudo me hacen preguntas como "¿Crees que deberíamos comenzar a usar Docker o saltar directamente a Kubernetes?" Tales preguntas no tienen sentido sin siquiera saber de qué se trata el producto.

Todos esos términos sofisticados (nube, Kubernetes, contenedores, gestión de configuración, infraestructura como código) prometen algunas mejoras. Pero son para DevOps al igual que los telescopios para la astronomía. Pueden ser útiles, pero no son necesarios.

En esencia, DevOps tiene como objetivo cerrar la brecha entre lo que pidió el cliente y lo que entregó el equipo de desarrollo. Hay un énfasis en los ciclos de lanzamiento cortos, el enfoque iterativo del diseño y la automatización de pasos repetitivos. ¿Qué crees que es más importante para llevarlos a la realidad?

Si dijiste “gran comunicación”, tienes razón. Las herramientas están todas bien. Pero solo valen el dinero invertido en ellos cuando mejoran la comunicación.

Un aspecto de la comunicación es saber qué es necesario para hacer el trabajo. Y el trabajo no significa que "el código esté comprometido con el repositorio". Piénselo más bien como "el cliente vio el cambio en la producción y lo aceptó".

Tan pronto como se determina este primer paso, y todos saben lo que debe suceder, ese es el mejor momento para escribirlo. ¿Donde? Bueno, soy un gran defensor de mantener un README.md . Cada persona en un equipo siempre puede mirar dentro y conocer el estado de un proyecto, y es una opción natural para los recién llegados al proyecto.

La automatización, el siguiente paso después de escribir un LÉAME, es opcional. Sin embargo, es una consecuencia natural de la documentación del proceso. Y sí, la automatización es lo que a menudo viene a la mente cuando se piensa en DevOps.

Un momento... ¿la automatización es opcional cuando se trata de DevOps? ¿No es DevOps el departamento de la persona que realiza las implementaciones?

Lo que la gente suele entender bajo el término "ingeniero DevOps" es un ingeniero de confiabilidad de software, un ingeniero de plataforma o un ingeniero de automatización de operaciones. Todos estos son roles válidos que permiten practicar DevOps, pero usar el término colectivo "ingeniero de DevOps" puede ser un poco ambiguo.

Así que echemos un vistazo más de cerca a DevOps en sí.

DevOps explicado

Primero, déjame mostrarte lo que DevOps no es:

1. No es solo un prefijo de título de trabajo
2. No es un equipo (pero "Dev" y "Ops" sí lo son)
3. no es una tecnologia
4. No significa "un administrador del sistema que puede codificar"
5. No significa "automatizar cosas"
6. No significa "ahora no hay equipo de operaciones"

Sabiendo esto, ahora es consciente de que no puede simplemente "contratar a un ingeniero de DevOps" o "crear un equipo de DevOps" en una empresa para asegurarse de que está preparado para el futuro. DevOps es similar al desarrollo Agile. ¿Contratarías a un desarrollador Agile como tal ? Probablemente no. O desarrollas un producto de forma ágil o no lo haces.

Entonces, ¿cómo se puede describir DevOps? Es una metodología. O tal vez una cultura. Tal vez incluso un espíritu. Hacer un producto de acuerdo con los principios de DevOps significa que todos, ya sea desarrollador, ingeniero de operaciones o gerente de producto, comparten una visión común y la mantienen a través de la comunicación. En menor medida, también significa que todos usan las mismas herramientas. Estas herramientas no están destinadas a ayudar a un solo grupo de personas. Están destinados a impulsar el producto.

Ir con este concepto requiere un serio cambio de mentalidad, que es el principal obstáculo. ¿Porqué es eso? Es porque las personas tienen que salir de su zona de confort y comenzar a colaborar con personas que tienen diferentes competencias. Los desarrolladores de repente necesitan aprender cómo funciona la nube y comenzar a implementar su propio código. El personal de operaciones debe abandonar las configuraciones manuales y comenzar a codificar. Todo el mundo necesita aprender nuevos conceptos. Todo el mundo tiene nuevas responsabilidades .

Esto no es fácil, pero con una buena comunicación y un objetivo común, es bastante factible. Esta comunicación implica establecer una cultura, configurar procesos livianos y mantener la documentación adecuada.

La automatización de DevOps es documentación

Probablemente nunca lo pensaste de esa manera. Pero la mayoría de las herramientas comúnmente asociadas con DevOps son herramientas de documentación :

• Los scripts de compilación escritos para facilitar la lectura sirven para documentar el proceso de compilación
• Las canalizaciones de integración continua documentan el proceso de integración, desde la construcción de piezas individuales hasta un producto completo
• Las canalizaciones de implementación continua van más allá al documentar cómo implementar un producto que su cliente puede usar
• Los archivos de gestión de configuración documentan el proceso de instalación y configuración
• Las especificaciones de infraestructura como código documentan la infraestructura necesaria (¡bastante formalmente, de hecho!)
• Los contenedores vienen con sus propios Dockerfile que documentan cómo crear y configurar un microservicio determinado.

Todos estos conceptos sofisticados hacen básicamente una cosa: ayudan a los miembros del equipo a comunicarse mejor al documentar los procesos. Estos procesos pueden ejecutarse manualmente o automatizarse. Lo importante es que todos los interesados ​​en un proyecto puedan seguirlos.

Documentar sus procesos como código tiene una gran ventaja sobre los manuales de instrucciones habituales. El código se puede verificar y se comporta de manera predictiva. Dada la misma entrada, produce la misma salida.

Con instrucciones escritas, tendrás tantas interpretaciones como lectores. Si escribe documentación ambigua o vaga, la persona que la lea completará los espacios en blanco. El punto es que no tienes control de lo que pasa en los huecos.

Es mucho más simple con código. Sin pasos concretos, el programa dejará de funcionar. Estos pasos concretos son un aspecto clave de la comunicación DevOps.

Comunicación DevOps: la única forma de cerrar la brecha entre el desarrollo y las operaciones

En el libro The Phoenix Project somos testigos de los problemas de un gerente recién ascendido encargado de implementar un gran proyecto. Como nadie sabe lo que está pasando, todo el mundo está apagando incendios sin mucho progreso. El subtítulo del libro menciona que es una historia de DevOps. Estoy de acuerdo con eso.

Pero lo interesante es que a lo largo del libro no se presenta ninguna herramienta nueva. ¿Se puede alcanzar un estado de DevOps solo mejorando la comunicación? Los protagonistas del libro lo hicieron, ¡así que también hay esperanza para ti!

Aunque el enfoque de los protagonistas puede considerarse de la "vieja escuela" (usando tarjetas de papel reales en lugar de un sistema de seguimiento de errores adecuado), las cosas comienzan a mejorar solo una vez que todas las partes involucradas comienzan a hablar entre sí.

Puede pensar que solo es posible mejorar la colaboración entre el desarrollo y las operaciones mediante la creación de mejores interfaces entre ellos, como acuerdos de nivel de servicio o acumulación de incidentes. Pero lo contrario es cierto. Al derribar las interfaces e introducir la empatía y una causa común, tendrás un equipo que trabaja hacia un objetivo común.

Estructura del equipo DevOps: ¿Quién está en un equipo?

Idealmente, cada producto debería tener solo un equipo: el equipo de producto.

Una vez estuve en un equipo de desarrollo donde no había un objetivo común con otros equipos. El equipo de desarrollo quería impulsar tantos cambios como fuera posible. El equipo de validación se encargó de prevenir la introducción de defectos. Tuvieron diferentes gerentes y fueron evaluados individualmente.

¿El resultado? Desarrollo y Validación jugaron al ping-pong con informes de defectos. Cuando Validación encontró una prueba que no pasaría, Desarrollo estaba más interesado en encontrar fallas en el código de prueba en sí que en tratar de hacer su propio código libre de errores.

El ciclo de lanzamiento se disparó, por supuesto, ya que se requería una enorme sobrecarga para completar correctamente los informes, los contrainformes, etc. Lo que la mayoría parecía no reconocer era que, en términos de producto, ambos equipos deberían compartir un objetivo común y trabajar juntos para lograrlo. Pero la falta de cooperación adecuada y la mentalidad de silo hicieron que fuera muy difícil darse cuenta.

La lucha contra los residuos es un esfuerzo conjunto

La mentalidad de producción esbelta que inspiró el Manifiesto para el desarrollo ágil de software (que a su vez nos presentó a DevOps) tenía que ver con la lucha contra el desperdicio. Por desperdicio, nos referimos a todo lo que no está directamente relacionado con lo que ordenó el cliente. El trabajo en curso apilado es un desperdicio. Cada paso de un proceso que no conduce claramente a la liberación es un desperdicio.

Pero los desechos solo se pueden ver desde un nivel alto. En el ámbito de un equipo, algunos procedimientos pueden parecer esenciales. Sin embargo, desde la perspectiva del producto, bien pueden ser inútiles.

Para averiguar qué esfuerzos se desperdician, debe unir fuerzas y considerar el ciclo de vida de un producto enviado. También es necesario pensar desde la perspectiva del cliente. ¿Es esta característica algo que el cliente quería? Si no es así, también puede omitirlo en este momento. ¿Son sus procesos simples y ágiles? Eche un vistazo más profundo, especialmente a aquellos que cruzan los límites del equipo.

¿Quiere asegurarse de que el desarrollo de un producto sea lo más eficiente posible? Invita a un extraño a ver cómo trabajas. Una persona que no sea parte de su equipo podrá hacer preguntas perspicaces y detectar nuevas áreas de mejora.

Principios de DevOps: Mantenga su(s) CALM(S)

CALMS es una descripción muy precisa de cómo se debe practicar DevOps:

• C ultura
• automatización
• magro
• M edición
• compartir

Fíjate que tiene la forma de un sándwich. Los tres valores intermedios son más técnicos, mientras que los externos se relacionan con las habilidades interpersonales. Pero la base de toda cultura es la comunicación: intercambiamos nuestros valores y creencias con otros miembros del equipo hasta llegar a un consenso sobre cómo deben comportarse las cosas.

Lo mismo ocurre con compartir. Compartir algo básico como la comida no requiere comunicación. El gesto mismo, sin embargo, también puede verse como un acto de comunicación. “Me preocupo por ti, así que comparto contigo”. No queremos limitar el alcance solo a la comunicación verbal.

Sin embargo, compartir ideas y herramientas requiere comunicación. ¿Cómo debemos compartirlos? ¿Dónde vamos a ponerlos? ¿Son útiles para todas las personas de un equipo o solo para un grupo más pequeño?

Si se enfoca solo en los aspectos más técnicos (Automatización, Lean y Medición), se está perdiendo el punto de DevOps. ¿Qué tiene de bueno tener un script de implementación automatizado que nadie usa además del autor? Si el guión le ahorra algo de tiempo, entonces podría estar justificado. Pero imagina cuánto tiempo se podría ahorrar si todos compartieran este guión. ¡Esto dice algo sobre la lucha contra el desperdicio!

DevOps acerca las empresas al desarrollo

Algunos dicen que DevOps acerca las operaciones al desarrollo. Esto es cierto, pero no es toda la verdad. Cuando se hace bien, DevOps acerca cada unidad. Permite que las empresas y los clientes vean lo que está haciendo el desarrollo, casi en tiempo real.

Este circuito de retroalimentación más corto beneficia a todas las partes interesadas. El trabajo es generalmente más visible y los desarrolladores también pueden ver fácilmente cómo los clientes usan el código que producen. Con la implementación tradicional, puede esperar varios meses antes de que alguien detecte errores o requisitos incumplidos. Con la implementación continua, todos pueden reaccionar ante cualquier problema a medida que surja. Los desarrolladores, las operaciones, los negocios y los clientes pueden sentarse en una habitación y modificar la aplicación de trabajo de acuerdo con las necesidades actuales.

¿Herramientas DevOps primero? Piensa otra vez

Por supuesto, se necesitan todas las herramientas para hacerlo posible.

Pero ninguna cantidad de herramientas puede ser un sustituto de una buena comunicación y empatía dentro de la empresa. Una vez observé un producto en el que el proceso de compilación era propiedad de un equipo, mientras que el código proporcionado era propiedad de otro.

Los problemas con el sistema de compilación eran comunes. Los desarrolladores no estaban seguros de cómo usarlo. Se basaba en herramientas estándar, pero se personalizaron hasta el punto de que toda la documentación disponible en la web resultó inútil.

Todos querían mejorar la situación, pero no había entendimiento entre los dos equipos. Esto significó que ambas partes introdujeron nuevas herramientas sin consultar con la otra parte. Esto solo amplió la brecha, en lugar de cerrarla.

Si desea iniciar una transformación de DevOps dentro de su organización, comience por mejorar la forma en que se comunica. No asuma simplemente una solución: Primero haga una lluvia de ideas con una mente abierta. Entonces puede encontrar que, por ejemplo, el soporte de herramientas es insuficiente para sus necesidades. Ahí es cuando puede considerar modificar sus herramientas actuales o introducir algunas nuevas; de lo contrario, es probable que se sume al problema original.

¿La forma más rápida de establecer DevOps? ¡Mejor comunicación!

En la introducción, mencioné la pregunta que los clientes me hacen a menudo: "¿Debería ir con Docker o debería saltar directamente a Kubernetes?" Después de leer este artículo, puede ver que esa pregunta se responde mejor después de hacer un trabajo de preparación, con una mentalidad de DevOps.

Si sabe que su equipo de producto comprende los beneficios de DevOps para sí mismo y para el cliente, el equipo y el cliente pueden comenzar estableciendo sus expectativas. Luego, los ingenieros pueden descubrir el modelo de desarrollo e implementación. Finalmente, puede determinar qué herramientas se necesitan.

Una vez que todos los requisitos están documentados, las opciones de tecnología son mucho más fáciles de hacer.

Soy un defensor de todas las excelentes herramientas de automatización de DevOps que hacen que nuestro trabajo sea más fácil y manejable. Pero nuestro trabajo diario es trabajar con personas . Invirtamos algo de tiempo para mejorar este aspecto de las mejores prácticas de DevOps en lugar de obtener otro certificado de tecnología.