Las reuniones causadas por despliegues lentos (2015)
(tidyfirst.substack.com)- En situaciones donde los ingenieros sienten que “no pueden sacar código por culpa de las reuniones”, la causa real podría ser la capacidad lenta de despliegue que genera overhead organizacional
- Chuck Rossi de Facebook considera que la cantidad de cambios que un despliegue puede soportar parece estar casi fija, y que para aumentar el volumen de cambios hay que incrementar la frecuencia de despliegue
- Facebook aumentó los despliegues de código PHP de semanales a diarios, luego a 3 veces al día, y también redujo el ciclo de despliegue de apps móviles de 6 semanas a 4 y luego 2; principalmente el equipo de release engineering impulsó estos cambios
- Cuando la producción de cambios supera el límite de despliegue, la cantidad de cambios por despliegue no aumenta fácilmente, y la organización se adapta bajando el volumen total de cambios mientras aumenta el overhead como reuniones, revisiones y handoffs
- Para hacer pasar más cambios, no basta con reducir reuniones: hay que mejorar el ciclo de despliegue, las pruebas, el monitoreo, el aislamiento y las relaciones sociales dentro del equipo para ampliar la capacidad de despliegue
Las reuniones podrían no ser la causa, sino el resultado
- La queja común de que “hay demasiadas reuniones y por eso no podemos desplegar código” podría tener la causalidad al revés
- Agregar o quitar overhead organizacional es relativamente fácil, pero aumentar la capacidad de despliegue de código de una organización es más difícil
- Las reuniones y revisiones pueden ser el resultado de una adaptación organizacional para evitar que el sistema de despliegue se sobrecargue
- Chuck Rossi observó en Facebook que la cantidad de cambios que un despliegue puede procesar parece estar más o menos fijada
- Si se quieren más cambios, se necesitan más despliegues
- Los despliegues de código PHP pasaron de semanales a diarios, y luego a 3 veces al día
- El ciclo de despliegue de apps móviles se redujo de 6 semanas a 4 y luego a 2
- Esta mejora fue impulsada principalmente por el equipo de release engineering
Si no aumenta la capacidad de despliegue, el overhead crece
- La “cantidad de cambios por despliegue” parece ser una métrica inelástica que no aumenta fácilmente y solo mejora con un gran esfuerzo
- Si la cantidad de cambios generados supera el límite actual, aparece una presión para reducir el volumen total de cambios en vez de aumentar la cantidad de cambios por despliegue
- Aumentan las reuniones, revisiones, handoffs y otros overheads
- Con el tiempo, también pueden disminuir el entusiasmo y la iniciativa
- El aumento del overhead puede crear un bucle de retroalimentación positiva
- Se procesa menos trabajo
- Aumenta la presión
- Crecen los errores
- Disminuye aún más la cantidad de cambios por despliegue
- El overhead vuelve a aumentar
- Los intentos aislados de reducir solo el overhead pueden elevar la presión y terminar aumentando otra vez el overhead
- Para hacer pasar más cambios, hay que ensanchar la capacidad de despliegue, el “extremo lejano de la manguera”
- La vía difícil: reducir el ciclo de despliegue y manejar el caos que eso implica
- La vía aún más difícil: aumentar la cantidad de cambios por despliegue con mejores pruebas, monitoreo, aislamiento entre componentes y relaciones sociales dentro del equipo
- Intentar solo reducir reuniones puede terminar en “una reunión para discutir cómo reducir las reuniones”
- Puede verse como un ejemplo de Thinkie de causalidad inversa, que plantea una idea que al principio parece equivocada
2 comentarios
Esta opinión está bien.
Opiniones de Hacker News
Lamentablemente, creo que la conclusión de este artículo está un poco al revés. Es importante reducir el riesgo de despliegue mejorando las pruebas y las propiedades organizacionales, pero no es el único enfoque que funciona.
El autor dice que la cantidad de cambios por despliegue es fija y difícil de aumentar, pero creo que el “Reversie Thinkie” aquí sería más bien reducir la cantidad de cambios por despliegue. Las reuniones de despliegue existen por el riesgo, y mientras más cambios haya en un despliegue, mayor será la probabilidad de introducir bugs o problemas operativos. Si se despliegan cambios pequeños con frecuencia, se puede entregar valor más rápido y hacer que los fallos sean más pequeños.
Si a esto se le combinan despliegues canary y lanzamientos graduales, el despliegue deja de ser un asunto de prender un interruptor y ver si se rompe o no, y pasa a ser un mundo donde las fallas se convierten en degradaciones de rendimiento o impactos limitados. Este enfoque está bien tratado en la investigación de DORA[0], en Accelerate[1], The Phoenix Project[2] y su antecesor espiritual, The Goal[3].
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
El punto central es cuánto tiempo y recursos invierte la organización en pruebas automatizadas. Las reuniones de release aparecen porque no existe la infraestructura para validar antes y después del despliegue ni para revertir cambios fallidos, y la falta de validación automática se tapa con revisiones manuales improvisadas. Si la organización de QA no tiene suficiente capacidad técnica, empuja procedimientos manuales por autopreservación.
Peor aún, a veces se presenta el hecho de pasar por estas reuniones como una señal de excelencia y buenas prácticas. Porque quien fue contratado para mitigar un problema no tiene incentivos para eliminarlo de raíz. Si un bug se cuela a producción, pasa a ser “un problema creado por desarrolladores que QA no pudo detectar por tal o cual razón”, pero con pruebas automatizadas sería difícil que siquiera pasara desapercibido en la etapa de PR.
Las reuniones no surgen por el riesgo, sino porque dentro de la organización hay roles que necesitan que exista riesgo para justificar su existencia y que carecen de las capacidades técnicas para reducirlo. Si se puede automatizar una verificación mínima de que los cambios se ejecutan y funcionan después del despliegue, y hacer rollback automático en caso de falla, las reuniones dejan de ser necesarias.
Veo muchos de estos procesos como respuestas razonables, aunque no técnicas, para soportar una mala situación lo mejor posible cuando no hay una solución de fondo. Dicho eso, no son completamente inocuos. En algunas organizaciones, incluso en proyectos nuevos o en proyectos para eliminar ineficiencias existentes, quienes tomaban decisiones seguían proponiendo procesos centrados en personas como solución.
Es un caso de falta de imaginación técnica o de estar atrapados en el marco del problema existente, así que quienes sí tienen esa imaginación deben intervenir y decir que, donde sea posible, hay que minimizar los procesos humanos mediante cambios técnicos. No todos los procesos humanos pueden eliminarse con tecnología, pero tampoco quiero dispersarme en cosas innecesarias.
Se podría estimar que cambiar más del 2% de todos los procesos en un periodo determinado es “demasiado”, y ese valor sería ajustable. También variará por área, así que el equipo del código de procesamiento de pagos y el equipo del código de RR. HH. deberían tener criterios distintos, y podría tener sentido rotar releases o equipos.
En este periodo a este equipo le toca hacer lo difícil y, cuando salga en vivo, se lo rota de nuevo hacia algo fácil. El mismo principio aplica a ataques de trinchera, avances de batallón y operaciones de armas combinadas.
Por supuesto, esto es un problema de gestión, pero se puede automatizar en gran parte, y también serían útiles señales sensoriales como qué equipo hizo commits recientemente en un módulo sensible. Por último, esta perspectiva vuelve extraños los sprints de Agile/Scrum. Sabemos que no se puede correr un maratón entero a toda velocidad; entonces, ¿cómo se preparan los sprints de forma rotativa?
Se pueden usar feature flags, pero entonces se genera un “backlog de funciones no activadas”. Al final, las funciones generalmente las consumen personas, y las personas necesitan capacitación para los cambios.
Él ya trataba el flujo, traducía los principios del Toyota Production System y aplicaba la física a procesos de negocio mucho antes de que alguien escribiera The Phoenix Project. También me gusta The Phoenix Project, pero comparado con The Goal se parece más a una adaptación barata hecha para que la gente de IT no leyera una historia sobre líneas de producción y saliera corriendo diciendo “soy PrOgrAmmEr, así que el trabajo creativo no se puede optimizar como una fábrica”.
Por lo tanto, The Phoenix Project es el sucesor espiritual de The Goal, no al revés.
Intento explicar el concepto de “alfabetización en software”. Así como hoy una empresa puede operar con oraciones en inglés, como documentos de políticas y correos electrónicos, la idea es que un negocio también puede operar con código.
De ahí salen conclusiones como “si la GPU hace el trabajo, el coder es el nuevo gerente”, o que se necesita un dispositivo de pruebas para toda la empresa para que el impacto de los cambios sea claro. También parece estar directamente relacionado con este excelente artículo. Si todos los tomadores de decisiones no ven el código, y no Jira ni un plan de proyecto, como un objeto de primera clase del proceso de cambios, entonces esos tomadores de decisiones no tienen alfabetización en software.
A menudo aparece el problema de “cómo discutir esto con ejecutivos no técnicos”, y la respuesta es que no se puede. Esos ejecutivos tienen que cambiar. Es una enorme brecha generacional que yo ya consideraba un problema hace 30 años, pero ingenuamente pensé que desaparecería a medida que los coders crecieran. Pero como no hace falta saber programar para “operar” una empresa, será difícil superarla hasta que no saber programar sea tan vergonzoso como que un editor de periódico no sepa escribir.
El punto central no son los SOP, las pruebas ni las reuniones, sino que necesitamos empresas que puedan operar con un nuevo conjunto de conceptos que se refuercen entre sí, como sistemas entendidos como comunicación.
Dicho eso, no sé por qué llamarlo “alfabetización”. El término autopoiesis de Maturana & Varela se acerca más al núcleo, y Autopoietic Systems de Stafford Beer también podría dar una buena base intelectual.
Pero llegado cierto punto, ¿un “negocio” de software puro no termina pareciéndose simplemente a un SaaS?
Las organizaciones van a bloquear activamente cualquier intento de mejorar el despliegue. Dicen con cara seria cosas como “Jenkins no debe estar cerca del entorno de producción”, “no se puede salir en vivo sin QA”, “necesitamos este tiempo para garantizar suficientemente la calidad del software”.
Mientras tanto, hay millones de bugs en producción y el producto apenas satisface los requisitos de los usuarios. Al final, en la mayoría de las organizaciones, luchar contra la burocracia es prácticamente imposible. Especialmente si no formas parte de las 200 capas de management que generan esas reuniones.
Me gustaría dejar solo a un par de programadores y diseñadores, despedir a todos los demás, y que se las arreglen sin coaches ágiles, product owners, scrum masters ni expertos de producto. Los despliegues lentos son un problema, pero no son el problema en sí.
Si sigues terminando en lugares que parecen imposibles de cambiar, deberías preguntar más sobre esto en las entrevistas. En empresas pequeñas he encontrado muchas que no tenían una burocracia demente, acorde a mis preferencias, y ahora estoy en una empresa grande, pero si uno se mueve de forma consistente y convincente, muchas cosas también avanzan lentamente en la dirección correcta.
Hay que entender que las cosas toman tiempo, comprender por qué la gente las hizo así y luego encontrar argumentos persuasivos para mejorarlas. También hay lugares realmente malos, y ahí lo correcto es no quedarse, pero la desesperanza no ayuda mucho.
Habría mucho que desentrañar, pero mi sesgo está del lado de esta afirmación.
Jenkins es el Wordpress del desarrollo de software. Es un enorme bucle con estado que ejecuta plugins sin separación de privilegios. Darle credenciales de administrador de producción a una instancia de Jenkins puede equivaler a darle las llaves de root a una persona cualquiera en Rumania que hizo un plugin que nunca auditaste. Se entiende perfectamente que no todos quieran eso.
“No se puede salir en vivo sin QA” es similar. Si despliegas en producción algo que nunca pasó por QA, ¿para qué existe QA? ¿Para arreglarlo después? Si no les das autoridad, QA no tiene oportunidad de hacer bien su trabajo ni de sentir orgullo por él.
En cualquier iniciativa, desde el primer día Jenkins llegaba hasta producción, a menudo directamente con desarrollo basado en trunk, y la calidad era responsabilidad de todos los desarrolladores. A nivel de contribuidor individual no había “lucha contra la burocracia”, aunque cuando había socios externos y stakeholders muy involucrados, probablemente el liderazgo sí tenía discusiones intensas de vez en cuando.
Dejar solo programadores y diseñadores me suena bien, pero no escala. Como mínimo tiene que haber un “dueño”, “experto” o “gerente” de producto que encole las prioridades de los stakeholders. Ese rol puede ser un “sombrero” que desarrolladores y diseñadores se turnen para usar, pero hay personas que son especialmente buenas en esa habilidad.
También entiendo que muchas organizaciones no operan así. Al transformar una empresa en esta dirección, ha ayudado crear un único equipo experimental, basado en voluntarios comprometidos con estas prácticas, protegido por autoridad desde arriba pero sin que se le dicte qué hacer. Claro que esto es California.
Algo un poco relacionado: trabajé en un lugar donde el pipeline de CI tardaba unos 25 minutos, y de eso, más de 3000 pruebas unitarias/de integración consumían 18 minutos.
Cada vez que había un problema en producción, agregábamos más pruebas, y por supuesto, cuando algo se rompía, recuperarse requería al menos 50 minutos. Después de pensarlo mucho decidimos enfocarnos en la recuperación: relajamos y simplificamos algunas pruebas para que todo tomara menos de 5 minutos, y usamos despliegues canary en lugar de actualizaciones rolling.
Para nosotros fue una experiencia realmente fresca, aunque en cierto sentido también se sentía equivocada.
Por supuesto, dentro de esa velocidad de despliegue se mezclan todo tipo de factores, pero casi todos son factores positivos.
Es un poco tangencial, pero ¿por qué CloudFormation es tan lento?
Hubo un caso en el que se eliminó una Lambda dentro de una VPC y conectada a EFS; el despliegue en sí fue bastante rápido, pero CloudFormation tardó unos 20 minutos en limpiar y terminar.
Cada vez que despliegas cambios de estado como una transacción, tienes que verificar precondiciones y poscondiciones en cada etapa. Para lanzar un conjunto de cambios con aunque sea un poco de dependencia entre sí, no queda más que desplegar cada cambio como una etapa secuencial. Cada etapa hace varias llamadas de red para aplicar el cambio, autenticar y sondear el estado; cada una toma unos 50–200 ms, y eso se acumula rápido.
Si despliegas la misma app en otro proveedor de nube con Terraform o Ansible, obtienes resultados parecidos. Si despliegas los mismos cambios manualmente, algo de unos minutos se convierte en una tortura de un día.
El mayor problema de IaC es que es de un nivel demasiado alto y hace demasiadas cosas internamente, de modo que termina habiendo gente que no sabe qué cambios se están aplicando realmente ni qué está haciendo. Y luego se quejan de que tarda mucho.
Me pasó algo personalmente en el trabajo. Antes de las vacaciones de Navidad hubo un cambio grande y había mucho miedo. La organización respondió aumentando las pruebas, es decir, incrementando las pruebas de regresión y con ello el overhead.
Esto aumentó el riesgo de que cambios en dev rompieran los cambios de mi rama. No era un riesgo de conflictos al fusionar código, sino desde la perspectiva de un sistema adaptativo complejo. Para responder a ese riesgo, creé reuniones y, al presentar el cronograma del proyecto, les expliqué a mis colegas las expectativas: si dejaban comentarios de estilo de código en un PR, se pospondrían para un PR posterior y al final se ignorarían.
Lo que hacía falta eran pruebas granulares con mejor aislamiento entre componentes. El problema es que la gerencia solo mira desde un nivel demasiado alto y ve las reuniones no como un medio, sino como un objetivo valioso en sí mismo. Si hay muchas reuniones, hay mucha colaboración, y eso es bueno, según esa lógica. Me gustaría ver consejos sobre cómo impulsar cambios técnicos junto con gerentes no técnicos.
Artículo relacionado: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - noviembre de 2015, 26 comentarios
Si usas microservicios, también puedes escalar horizontalmente la frecuencia de despliegues.
Con una app monolítica compuesta por módulos independientes también puedes desplegar con la misma frecuencia sin microservicios, y evitar los principales inconvenientes: la complejidad de infraestructura/CI·CD y convertir las llamadas a funciones de la app en problemas de comunicación de un sistema distribuido inestable. Hay que resistirse a la complejidad accidental innecesaria.
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
Y aparece el divertido problema nuevo de coordinar el plan de despliegue con el lanzamiento de funcionalidades.
Si no, obtienes al mismo tiempo problemas de datos distribuidos y más capas de complejidad; es decir, más reuniones que con un monolito.
En un monolito existe el riesgo de terminar en un enorme enredo de SOLID, DRY y demás estupideces de “código limpio”, donde nadie se anima a cambiar nada por miedo a romper algo. No significa que los principios de orientación a objetos sean obviamente falsos en sí mismos, pero son tan extremadamente ambiguos que muchas veces nadie logra aplicarlos bien.
Siempre me da risa ver a Uncle Bob esquivar las críticas diciendo que “ellos entendieron mal los principios”. Si tanta gente se equivoca, ¿no será que los principios son malos? Los microservicios tampoco te protegen de la mala gobernanza; solo hacen que los problemas aparezcan de otra forma. Creo que es muy fácil y común terminar con varios microservicios y que nadie sepa qué impacto tendrá un cambio en otros servicios.
Al final es un problema de gestión de equipos y, por experiencia, es el área que peor se nos da en nuestra industria. Mejorará cuando entren nuevas generaciones con ideas como “Team Topologies”, pero aunque eso realmente termine pasando, llevará décadas. Si la organización ve “IT” solo como un centro de costos y no formula sus necesidades de una forma que pueda integrarse a procesos de buenas prácticas de ingeniería de software, muchas veces queda fuera del alcance de los departamentos de digitalización.
Una de las razones por las que me gusta Go como lenguaje de propósito general es que, por diseño, es simple, y eso suele llevar a bases de código fáciles de cambiar. Vi a algunos bancos en línea y plataformas de alquiler/gestión de activos pasar a Go y crecer porque por fin podían entregar lo que el negocio necesitaba. En cambio, sus competidores estaban atrapados en bases de código Java o C# difíciles de manejar y, con suerte, sacaban una funcionalidad llena de bugs cada seis meses.
Esto no es un problema de Go, Java o C# en sí, sino de que las arquitecturas y diseños orientados a objetos de la vieja escuela son demasiado fáciles de arruinar. En un lugar donde trabajé había más de mil interfaces de C#, y ninguna era consumida por más de una clase. Decenas de miles de interfaces estaban todas en la misma carpeta y namespace, y encontrar lo que necesitabas era cuestión de suerte. Puedes hacer eso en Go o en cualquier lenguaje, pero es menos probable si no estás dentro de la vieja cultura de lenguajes de código limpio orientados a objetos. Especialmente en C#, la abstracción por defecto está tan profundamente arraigada en la cultura que es más difícil no hacerlo.
Personalmente, tengo un cariño secreto por las organizaciones Python. Siempre entregan rápido y el código es terrible. Encantador.
En general es correcto, pero también es igual de irrelevante
En resumen, lo único que importa es el rendimiento del software y, por lo tanto, el rendimiento humano. La gestión del riesgo y la aceptación del riesgo se pueden medir con números. En software es mucho más simple que en otras profesiones, porque los ingenieros de software solo pueden aceptar riesgos dentro de restricciones operativas conocidas, y todo lo demás se posterga
Si quieres ser más rápido, antes que nada debes maximizar la frecuencia de iteración humana. Si no puedes iterar porque estás esperando permisos, estás bloqueado; si estás esperando una compilación o que se refresque la pantalla, te estás volviendo más lento. Esto también se puede medir con números
Si A puede iterar 100 veces más rápido que B, la exactitud pasa a ser secundaria. B, por ser lento, tiene que maximizar la exactitud. A tiene una flexibilidad extrema para aprender, fallar y mejorar, de modo de volverse más rápido y más exacto
Parte de reducir el riesgo mientras se itera más rápido es la automatización rápida de pruebas. Si A puede ejecutar más del 90% de cobertura de pruebas en el tiempo de 4 iteraciones humanas, esa automatización de pruebas sigue siendo 25 veces más rápida que una sola iteración de B, y el riesgo de regresión es más de 90% menor
Los despliegues rápidos crean war rooms para responder a incidentes
Mucho más importante que esa reducción fue que, cuando aparecía un problema, la causa se encontraba mucho más rápido. Como los cambios que se revertían eran muy pequeños, revertirlos también era mucho más seguro y fácil. Nadie quiere revertir 3 semanas de trabajo. Eso es caos