Mejorar el canal DevOps: Empleando técnicas de aprendizaje.

Aprender de los éxitos y los fracasos permite mejorar en todos los aspectos de la vida. Emplear esta filosofía es aplicable a los equipos que realizan las actividades en el canal DevOps para conseguir gestionar el ciclo de vida de los sistemas, las aplicaciones, los micro-servicios, las apps, las bases de datos, los sistemas operativos, las redes y demás componentes que conforman la plataforma tecnológica de la información en las organizaciones.

En “The DevOps handbook” de Jez Humble, John Willis, Patrick Debois y Gene Kim publicado por IT Revolution Press en 2016 se proponen tres formas para mejorar el canal DevOps. La primera forma está resumida en el post “Cómo mejorar el canal DevOps. Primeros pasos.” de este blog. La segunda forma está resumida en el post “Mejorar el canal DevOps: Manejando el feedback.” La tercera y última es la que se va a resumir en este post. 

Los autores de este libro recomiendan para mejorar el canal DevOps empleando técnicas de aprendizaje:

•  Facilitar e inyectar aprendizaje en el día a día 
•  Inyectar fallos en producción para crear resistencia a fallos
• Convertir descubrimientos locales en mejoras globales
•  Reservar tiempo para conseguir aprender y mejorar

Facilitar e inyectar aprendizaje en el día a día

Para que los equipos puedan aprender de sus errores hay que implantar una cultura de “no búsqueda de culpables”.  Es decir, cuando las respuestas a incidentes y accidentes se gestionan principalmente con la búsqueda de culpables se dificulta la realización de las investigaciones adecuadas, promoviendo más bien el miedo que la atención plena de las personas que están realizando trabajos. Teniendo en cuenta que estos trabajos suelen ser críticos para la organización, que los ejecutores de los mismos vivan atemorizados no es útil. Que las personas estén atemorizadas promueve organizaciones más burocráticas que resolutivas, cultivando el secretismo, la evasión de responsabilidades y la auto-protección.”

En lugar de buscar culpables es mejor recopilar información tras los fallos, se pueden realizar reuniones post-morten. Es importante difundir los detalles del  motivo y resolución del fallo para que cualquiera pueda consultarlos.

Se debe fomentar la investigación constante analizando el motivo de cada fallo por pequeño que este sea. A medida que se van solucionando fallos se deben investigar fallos más leves actuando de esta manera de forma sostenida y tratando cada vez fallos de más bajo nivel.

Los fallos son inevitables, cuantos más cambios se hacen más probable es cometer fallos. Esto no quiere decir que no debamos hacer cambios, al revés los cambios son la única forma de mejorar pero pueden tener efectos colaterales. Entonces lo más cabal es promover los cambios y actuar calibrando el riesgo que hay que asumir. Cómo ejemplo:

“Hubo una gran caída en Netflix  que fue causada por un error francamente tonto.  El error fue provocado por un ingeniero que había tirado Netflix 2 veces en los últimos 18 meses. Pero este ingeniero es de mucha utilidad para Netflix. En estos 18 meses había trasformado el estado de las operaciones mejorando la automatización de los procesos. Su trabajo ha permitido hacer despliegues más seguros en producción”. Es decir el ingeniero provocó problemas pero por qué estaba haciendo cambios que finalmente han reportado muchos beneficios.

Inyectar fallos en producción para crear resistencia a fallos

Otras técnicas que pueden ayudar a aprender son: provocar errores a propósito para aprender a resolverlos e institucionalizar días de trabajo dedicados a experimentar fallos. A este propósito existe una herramienta llamada Chaos Monkey construida por Netflix que simula caídas de servidores sobre sistemas en producción. Trabajando en los problemas generados  las instalaciones consiguen sistemas más robustos preparados para cualquier eventualidad.

Convertir descubrimientos locales en mejoras globales

Cuando se descubre algo de interés en un punto de la organización, es importante hacerlo llegar al resto. Para ello es mejor buscar medios que sirvan para que todos los miembros de la organización puedan acceder a la información. Por ejemplo, es mejor utilizar un chat que la utilización del email para compartir información acerca de la resolución de incidentes. De esta forma todo el mundo está al tanto de los incidentes que han acaecido y aprenden de su solución.

Otra forma de difundir conocimiento es automatizar procesos que sean exitosos. De esta manera es más fácil hacerlos llegar a todos los rincones de la organización.

Utilizar un solo repositorio de código para toda la organización consigue que todos los equipos compartan el código. Google lo hace para más 25.000 desarrolladores. Para que el trabajo fluya de forma consistente es necesario establecer políticas de uso del repositorio. Por ejemplo, para el uso de ramas, para la gestión de dependencias, la gestión de versiones, etc.

También las pruebas automatizadas son útiles para transmitir información.  Las pruebas unitarias sirven de documentación del código. Usar TDD entre otras ventajas consigue que las pruebas automatizadas existan y estén al día respecto al código que testean

.

Por otra parte, los desarrolladores deberían acompañar a operaciones en el despliegue y puesta en marcha del software. Cuando los desarrolladores conocen la problemática del área de operaciones, diseñan sistemas que colaboran en su puesta en producción.

Disponer de herramientas de automatización que  por ejemplo extraigan el código del repositorio, lo desplieguen en el entorno de pre-producción, ejecuten las pruebas unitarias, realicen un análisis de código estático y marquen cómo disponible el código para producción o no. Estas herramientas facilitan que los desarrolladores puedan tener un self-service de puesta en producción, es decir ellos mismos liberan software en producción.

También es interesante acordar un marco arquitectónico entre desarrollo y operaciones. Este marco no debe ser rígido, pero si marcar los límites a no traspasar si los desarrolladores quieren acogerse a las áreas soportadas por operaciones. El marco arquitectónico se refiere a las tecnologías empleadas para desarrollar: lenguajes, bases de datos, frameworks, sistemas operativos, etc. Para ilustrar mejor esta idea, considerar que respecto al uso de distintas tecnologías ponemos las que actualmente están soportadas separadas por una boyas de las que no. Los desarrolladores son libres de traspasar la boya, pero ahí tendrán menos soporte que dentro del perímetro señalizado. La metáfora de las boyas sirve para indicar que entre las tecnologías soportadas y las no soportadas no hay un muro in-traspasable.

Reservar tiempo para conseguir aprendizaje y mejorar

Blitz improvement proviene del ciclo Kaizen cuyo objetivo es la mejora. El término Blitz improvement se puede traducir como “bombardeo de mejoras”. Aplicar esta técnica, consiste en reservar un tiempo para que los equipos ideen mejoras para problemas conocidos. Existen muchos casos de éxito asociados al uso de esta técnica.

También se puede dedicar un tiempo periódicamente a eliminar deuda técnica, se trata de dedicar cierto tiempo a trabajar en los sistemas sin ampliar ni modificar funcionalidades. 

Formas de aprender también se pueden conseguir organizando eventos en los que los profesionales enseñen lo que saben a otros y escuchen lo que otros les puedan enseñar. Además es interesante participar en eventos DevOps externos a la organización, compartir experiencias con otros será enriquecedor.

Difundir las buenas prácticas que se hayan puesto en funcionamiento en algún lugar de la organización a todos los demás se puede hacer asignando consultores internos especializados a equipos que necesiten aplicar dichas prácticas. También se pueden contratar consultores externos con especialidad en alguna técnica en la que los equipos no tengan experiencia.

Conclusiones

La tercera forma, explora prácticas que ayudan a crear una cultura de aprendizaje y experimentación. Aprender de los incidentes, crear repositorios únicos para todos los desarrolladores y compartir los descubrimientos entre todos es esencial cuando se trabaja en sistemas complejos, ayudando a caminar hacia una cultura más justa de trabajo en las cuales no se busquen culpables y hacer sistemas más seguros y robustos.