Despliegues: el miedo irracional a ellos

La ansiedad que generan los despliegues es real. Tratemos de comprender las emociones humanas relacionadas con los despliegues y aprendamos las mejores prácticas para minimizar el miedo.

Una reciente interrupción del servicio que afectó a CrowdStrike afectó a 8,5 millones de sistemas operativos Windows, lo que provocó interrupciones en varios servicios globales, incluidos aerolíneas y hospitales. Múltiples análisis han examinado la causa raíz de este incidente.

Sin embargo, como ingeniero de software, creo que nos estamos olvidando del aspecto de las emociones humanas relacionadas con las implementaciones, en concreto, el miedo a interrumpir la producción. Eso es lo que intentaremos abordar en este artículo. Trataremos lo siguiente:

• Comprender la función de la ingeniería de lanzamiento.
• Qué les importa a los ingenieros de software y qué no.
• Impacto de la entrega continua (CD).
• Una mirada a las implementaciones manuales.
• Problemas con la implementación manual y la solución a estos problemas.

Ingeniería de lanzamiento

Antes de profundizar en el miedo a las implementaciones desde la perspectiva de un ingeniero de software, primero comprendamos el papel de un ingeniero de lanzamiento. La ingeniería de lanzamiento ha evolucionado considerablemente en los últimos años, gracias a las herramientas modernas de CI y CD y la estandarización de Kubernetes. A pesar de estos avances, las responsabilidades principales siguen siendo las mismas:

• Implementaciones consistentes y repetibles: la estandarización de los procesos de lanzamiento reduce el riesgo de malas implementaciones en producción.

• Reducción de las interrupciones del servicio : los procesos estandarizados también garantizan que los equipos estén equipados para abordar incidentes dañinos en el entorno de producción; por ejemplo, una estrategia de reversión para escenarios en los que una versión causa problemas.

• Supervise y optimice el rendimiento: busque mejoras de rendimiento para lograr implementaciones más rápidas y confiables.

• Colaborar con ingeniería: trabajar en estrecha colaboración con desarrolladores, equipos de control de calidad y DevOps para garantizar que todos los servicios nuevos y existentes tengan un proceso de implementación bien definido.

Lo que les importa a los ingenieros de software

A diferencia de los ingenieros de lanzamiento, como ingenieros de software que trabajan en el equipo de producto, es posible que solo nos interesen ciertos aspectos de las implementaciones:

• Fusiones rápidas de código: la fusión rápida les permite validar su trabajo y pasar a nuevas tareas o desbloquear tareas dependientes.

• Incidentes de producción : si bien es posible que a los ingenieros no les importen todos los incidentes de producción, definitivamente les preocupan los cambios en su código que causan interrupciones en la producción.

• Cronograma de implementación : a los ingenieros también les gusta realizar un seguimiento de cuándo sus cambios se implementan o se han implementado para poder tener acceso a comentarios en tiempo real sobre sus cambios.

Lo que a los ingenieros de software no les importa

Si bien hay cosas que nos importan, también hay otras que no:

• Metodología de implementación : Aunque conocemos la necesidad de un proceso de implementación eficiente y confiable, no les importa cómo se realiza.

• Efecto de otros cambios : a menos que las cosas salgan mal, no nos preocupamos por cambios no relacionados de otros desarrolladores.

• Gestión de la implementación : a un ingeniero le da igual quién gestione la implementación en un equipo de software. Por ejemplo, solo nos preocuparíamos de gestionar la implementación si nos encargaran esa tarea.

Impacto de las Implementaciones Continuas (CD)

Entonces, ¿qué tiene que ver el miedo con las implementaciones continuas?

Mucho.

Los estudios han demostrado [varios beneficios](https://dora.dev/capabilities/continuous-delivery/#:~:text=DevOps%20Research%20and%20Assessment%20(DORA,as%20higher%20levels%20of%20availability) de la implementación continua (CD), y, como era de esperar, muchos de ellos son de naturaleza psicológica . Las implementaciones continuas eliminan la “intervención humana”, por lo tanto, requieren una fuerte confianza en la infraestructura de prueba.

En otras palabras, las pruebas automatizadas no solo garantizan la confiabilidad de la producción, sino que también brindan seguridad psicológica , a veces de manera irracional, reduciendo el miedo a las implementaciones. Como desarrollador, me siento más cómodo haciendo cambios en un proceso de CD que si me piden que verifique los cambios manualmente.

Sin embargo, a pesar de la popularidad de estas estrategias de CD, muchas empresas aún activan las implementaciones de forma manual (tienen un humano en el circuito), lo que indica un enfoque cauteloso en las implementaciones de CD. Este comportamiento sugiere que los equipos prefieren mantener la supervisión del proceso de lanzamiento e intervenir cuando sea necesario.

Es importante entender esto desde una perspectiva de seguridad psicológica. Las implementaciones manuales implican que alguien supervisa el proceso y se encarga de los problemas cuando las cosas salen mal. Si bien esto brinda una sensación de seguridad, también puede inducir miedo en la persona que realiza la implementación y es propenso a errores humanos.

Despliegues manuales

A pesar de los inconvenientes, la mayoría de los equipos gestionan las implementaciones de forma manual. Una implementación manual típica puede incluir algunos pasos:

Supervisión

Alguien supervisa todo el proceso de implementación antes de que se publique un lanzamiento. Esta persona tiene la tarea de intervenir cuando hay señales de problemas. Los equipos mantienen una persona de guardia que administra sus implementaciones y se ocupa de los problemas cuando surgen.

Equipos de lanzamiento dedicados

Algunos equipos cuentan con un equipo de ingeniería de lanzamiento dedicado, que garantiza que los lanzamientos se realicen sin problemas. Como esto implica un alto grado de especialización, el proceso de implementación podría ser más eficiente y confiable.

Hojas de cálculo

Algunas empresas mantienen una hoja de cálculo para validar los cambios realizados. Esto les permite revisar y aprobar sistemáticamente estos cambios, asegurándose de que cumplen con los estándares de calidad predefinidos.

Control de calidad manual

Además de las hojas de cálculo, el control de calidad manual es otra capa que las empresas añaden. El control de calidad manual prueba las nuevas versiones en entornos de prueba antes de implementarlas en producción. Sin embargo, un entorno de prueba no es infalible, por lo que no se tendrán en cuenta algunos escenarios de la vida real.

¿Dónde fallan las cosas con las implementaciones manuales?

Muchas cosas pueden salir mal para cualquier equipo de desarrollo de software que dependa únicamente de implementaciones manuales:

Dependencia de un grupo pequeño

Esto puede generar cuellos de botella que, en algunos casos, provoquen retrasos en la publicación y errores humanos. Además, un equipo podría tener problemas si esa persona en particular se va o no puede realizar las tareas requeridas.

No existe una estrategia de mitigación de riesgos

No existe una estrategia para dar seguimiento a un incidente de producción desfavorable. Cuando ocurre un incidente, el equipo de lanzamiento debe esforzarse para encontrar a las partes interesadas relevantes para ayudar a resolverlo y tomar decisiones.

Propenso a errores humanos

Errores tipográficos en comandos o scripts, u olvido de ejecutar los pasos previos o posteriores a la implementación.

Alto esfuerzo

Dado que las implementaciones requieren supervisión, se convierte en un esfuerzo que consume mucho tiempo. Además, hace que la frecuencia de las implementaciones disminuya significativamente. Por ejemplo, si se requiere una hora para supervisar toda la implementación, el equipo de lanzamiento puede decidir omitir las implementaciones en los días con cambios menores para ahorrar ese tiempo.

Falla de comunicación

Los equipos de productos no tienen claro cuál es el estado de las versiones ni cuándo sus cambios entrarán en producción.

Al observar estos desafíos, es fácil entender por qué los ingenieros temen las implementaciones. El riesgo de fallas en las implementaciones, los altos riesgos y la presión para mantener el tiempo de inactividad bajo también contribuyen a este temor.

Estos fallos se pueden minimizar aumentando la automatización de las pruebas. Sin embargo, dado que estas pruebas se llevan a cabo en un entorno de prueba, no se debe esperar que una prueba automatizada detecte todos los errores posibles. Es de esperar que se produzcan fallos, pero a una tasa reducida.

¿Qué podemos hacer al respecto?

¿Simplemente configurar implementaciones continuas? Es más fácil decirlo que hacerlo. A pesar de las desventajas, las implementaciones manuales siguen siendo aceptables si se gestionan bien. Los objetivos deberían ser:

• Proporcionar barandillas para evitar incidentes de producción.
• reducir los errores humanos
• Permitir que cualquier persona active implementaciones
• Asegúrese de que las implementaciones se realicen con frecuencia

Barandillas – Canary y Rollbacks

Las estrategias Canary y Rollback pueden ayudar a reducir el impacto de una interrupción y en muchos casos evitar la crisis automáticamente.

Una versión Canary expone su nueva versión a una pequeña parte del tráfico del entorno de producción. Esto brinda a los equipos información sobre problemas que podrían no haber surgido durante las pruebas.

Por otro lado, una estrategia de reversión ayuda a los ingenieros a revertir una versión a su estado estable anterior. Se lleva a cabo cuando surgen nuevos problemas después de las implementaciones en el entorno de producción.

Reducir los errores humanos: estandarización

Definir metodologías de implementación estándar que resulten en eficiencia, consistencia, confiabilidad y alta calidad de software. En su informe sobre el estado de DevOps , DORA muestra que la confiabilidad predice un mejor rendimiento operativo. Además, tener un proceso estandarizado permite la repetibilidad en los procesos de lanzamiento, que se pueden automatizar. La automatización de este proceso ayuda a un equipo a mantener bajos los costos de producción.

Democratizar el proceso de implementación

Democratizar el proceso de implementación elimina la dependencia de individuos específicos. Si le damos poder a cualquier ingeniero de software para que implemente, poco a poco se reduce el miedo. “Si cualquiera puede implementar, no debería ser demasiado difícil”. ¡Comparte tus legos!

Despliegues frecuentes

Para reducir la ansiedad por la implementación, debemos implementar con mayor frecuencia, no con menos frecuencia. El informe de DORA también destaca que las implementaciones en lotes más pequeños tienen menos probabilidades de causar problemas y ayudan a reducir la barrera psicológica para los desarrolladores.

Mejorar la experiencia del desarrollador

Aclarar qué se está implementando mejora la experiencia del desarrollador. Facilite a los desarrolladores saber cuándo se realizan las implementaciones y qué cambios se incluyen. Esta transparencia ayuda a los desarrolladores a realizar un seguimiento de cuándo se implementan sus cambios y simplifica las investigaciones de incidentes.

Estrategias definidas de mitigación de riesgos

Deben definirse los pasos a seguir para las reversiones y las correcciones urgentes, ya que esto ayuda a eliminar cualquier indecisión con los incidentes de producción. Por ejemplo, debe haber pasos de compilación e implementación separados que los equipos deben seguir para realizar reversiones sencillas.

De manera similar, estandarizar la forma de abordar las revisiones urgentes y las selecciones selectivas puede simplificar la operación cuando hay mucho en juego.

Banderas de características

Los indicadores de características son como interruptores de seguridad que pueden desactivar una nueva característica que haya provocado un incidente en la producción. Esto puede permitir a los ingenieros resolver los incidentes de producción rápidamente.

Conclusión

Los equipos de software deben tratar la ingeniería de lanzamiento como una prioridad desde el comienzo del desarrollo del producto para evitar errores costosos. Y no debemos permitir que incidentes como la interrupción del servicio de Crowdstrike paralicen nuestras prácticas de desarrollo. Para abordar el miedo a la implementación y prevenir incidentes de producción se requieren varias estrategias clave:

• Invertir en la estandarización de los procesos de implementación.
• Establezca estrategias de mitigación de riesgos bien definidas, como lanzamientos anticipados, implementaciones estratégicas, reversiones y revisiones.
• Simplifique la experiencia del desarrollador democratizando las implementaciones y aliente a todos a participar.

En Aviator, estamos creando herramientas de productividad para desarrolladores a partir de principios básicos para permitirles crear más rápido y mejor. Para conocer una forma moderna de gestionar las implementaciones, consulte Aviator Releases .