Los ingenieros de Yahoo ahora pasan su código a Producción directamente, y son responsables de su impacto vía @IEEE Spectrum

Qué les parece este cambio de paradigma?

Más información en

2 Me gusta

Tengo entendido que amazon, netflix, y otras empresas llevan tiempo haciendo lo mismo… Lo que significa que yahoo llega tarde a la fiesta.

Hasta donde entiendo cada desarrollador debe escribir los scripts necesarios para poder hacer “back out” de su código en producción.

Usando la imaginación me imaginó que esto se prueba inicialmente ene una ambiente de staging para ver si funciona, incluyendo el backout, antes de pasarlo “directamente a producción”.

Además tienen la práctica de primero probarlo en el 10% de los usuarios, luego en el 30% y finalmente el 100%. Si sale malo, lo más probable es que cuando esta siendo usado por el 10% de los usuarios falle estrepitosamente y se haga el back out semiautomático.

Para ser bien honesto, el título es un poco misleading.

Dice coding without a net… Pero en realidad existe una net, las pruebas automatizadas.

Lo que no existe es un equipo de QA.

En teoría la idea suena bien, pero alguien debe entrenar a los developers en técnicas de QA para que el equipo ande bien…

Si, el título es bien amateur, por eso en este hilo lo expresé de otra forma
El dic. 14, 2015 12:59 AM, “Guillermo Schwarz” no-responder@chileagil.cl
escribió:

Si, porque tampoco se trata de remover el QA, sino de integrar el QA en el proceso de desarrollo.

Indican que exigen excelencia desde el comienzo, entregándoles responsabilidad a los ingenieros sobre su código. Esto para mi es clave, ya que fomenta el profesionalismo y la preocupación por el usuario final, y se alinea con las ideas del Software Craftmanship.

Lo que indica el artículo, que parte de lo más complejo fue desbandar los equipos de QA y re-integrarlos dentro de otros equipos, como automatización y performance. Mi interpretación de eso es que pasaron de ser barreras entre el código y producción, a ser habilitadores del desarrollo, haciendo tareas de plataforma que luego los devs utilizan o a mejorar el rendimiento.

puros :heart: a las empresas que se atreven por esto :smile:

“Indican que exigen excelencia desde el comienzo, entregándoles
responsabilidad a los ingenieros sobre su código. Esto para mi es clave, ya
que fomenta el profesionalismo y la preocupación por el usuario final, y se
alinea con las ideas del Software Craftmanship.”

Súper bien, estamos de acuerdo.

Si te mandas un condoro, tu mismo lo arreglas.

Eso significa varias cosas:

  1. Es fácil identificar quién, cuando y como (con que código) alguien se
    mando un condoro.

  2. Como todo es transparente todo el mundo sabe que tu te mandaste un
    condoro.

  3. Más que esperar a que el ingeniero venga y lo arregle… Imagina amazon,
    por cada hora que el sistema no funciona, pierden varios millones de
    dólares… Tienen que rápidamente volver atrás… Como ningún ingeniero
    gana un millón de dólares al año, ningún incentivo monetario hará que ese
    ingeniero reaccione tan rápido como para justificar su sueldo…
    Necesariamente tanto el proceso de deploy como el proceso de back out
    requiere ser automatizado.

A mi me ha pasado harto en chile que el gerente le dice a sus colaboradores
"lo importante es venderse"… Lo que se traduce en “manten tu
prestigio”… Lo que se traduce en “pon cara de circunspecto y miente
descaradamente”…

Entonces imagina cuando instalas estos sistemas que los ingenieros llaman
cariñosamente “el acusete”… Como jenkins, junit, sonar, selenium, etc.
?que pasa? Los ingenieros quedan con, perdonando la expresión, diarrea con
cólicos…

Hay que relajar los ambientes, borrar de la mente de los ingenieros todas
esas tonteras acerca de la imagen… Porque perjudican los proyectos…

Si, no creo que “la imagen” o el “orgullo” sean características a cultivar para un ingeniero, por los motivos que expones, más algunos otros como shared code ownership, sin embargo, creo que el prestigio debiera cultivarse más, en el sentido de tener un registro validado de un trabajo responsable, en la misma manera que un médico tiene un prestigio y está vinculado a su permiso de ejercer la profesión.

Me refiero que no sean un atributo vanidoso orientado a la venta, sino un reflejo de tu actuar hasta ahora. Para dejar de lado la parte vanidosa/vendedora del asunto, el ambiente de desarrollo tiene que estar orientado a reducir la culpa. Apuntar con el dedo a alguien que ha cometido un error solo lo reprime y genera esta toxicidad profesional.

En el caso de lo que estamos hablando, continuous deploy, el pipeline automatizado ataja errores hasta cierto punto, pero aun si el equipo publica un defecto a producción que no fue atajado, deben suceder varias cosas: desactivación (o rollback), análisis postmortem, mejorar el check automático para que no vuelva a suceder y finalmente, reparar el error y publicar corrección. Minimizar la culpa viene de la mano con minimizar el impacto, por esto creo que trabajar en feature flags es mucho más sano que utilizar estrategias de rollback, así como también, las arquitecturas más desacopladas entre servicios a la microservices ayudan en reducir el impacto (aunque aumentan la complejidad total)

En realidad, yo no veo tanto el asunto como “el que lo rompe lo arregla”, que es muy de cultura de culpa, sino más del lado “te vamos a evaluar según el uptime/bugs/metricas de tu producto” lo que habla más de una cultura de responsabilidad, mejora continua y accountability.

100% de acuerdo, me leiste la mente.

Sin embargo, hay una pequeña cosa que me gustaria agregar…

No hay mucha diferencia en que una persona te apunte con el dedo y que una
máquina te apunte con el dedo (o publique tu username como la causa del
problema).

La diferencia viene dada por las consecuencias. Tu mencionas la
evaluación… Aquella bendita evaluación en la que el 10% superior de los
empleados son ascendidos y reciben aumentos, el 10% es despedido y el 80%
se queda donde esta.

Si algo tiene consecuencias inmediatas, es peor que un reto o amonestacion.
Si algo en mi trabajo impacta mi vida privada, lo más probable es que lo
evite a toda costa. Y cuando digo a toda costa, me refiero a que la gente
esta dispuesta a mentir para conseguir su objetivo.

Un aumento, una promoción de cargo y evitar un despido hace que la gente
mienta descaradamente. Además que los buenos en su trabajo se
desconcentran, porque el foco de atención esta en el bono y no en el
proyecto mismo.

Por el contrario, que la única pena o castigo sea que todo el mundo sepa
que te equivocaste y no hay consecuencias reales de ningún tipo, es mucho
mejor. Hace que te concentres en el trabajo. Porque todo el mundo se
equivoca, pero si el feedback es inmediato, lo corriges inmediatamente y no
hay consecuencias de ningún tipo.

Para variar esto se lo escuche a uno de los proponentes de XP y cuando lo
puse en práctica, la gente reclamó que no le gustaba el acusete
(jenkins)… Pero quien se lo saltaba (inventaron maneras de saltárselo)
recibia a todo el resto del equipo reclamándole que el proyecto ya no
compilaba… De modo que se lo saltaban sólo para que nadie se diera cuenta
que se habían equivocado, pero el resultado era el mismo porque jenkins se
ejecutaba de todas maneras… Sólo que no quedaba registro de que se habían
equivocado… A alguien le importa eso?.. A nadie, pero ellos se
esforzaban igual…

En otras palabras, una vez que los programadores se acostumbran al sistema,
se controlan entre ellos mismos…

No es necesario poner elementos externos para que el sistema funcione, como
los bonos, ya que eso distrae y genera malos comportamientos. Basta con que
el programador tenga feedback directo e inmediato de lo que esta
haciendo… Eso le da un sentido de control.

Respecto de los feature toggles es una excelente manera de hacer backout
rápido. ;-). Sin embargo ese dead code debe ser removido eventualmente…
Si el backout no lo hace una máquina, lo tendrá que hacer una persona, no
se si es el mejor uso de tu tiempo…

Saludos,
Guillermo.

(el resto del post lo respondí en otro hilo porque es más de gestión)

No creo que un feature desactivado sea código muerto en el sentido antiguo de la palabra, ya que no será código sin mantención, sino que en desuso. Eventualmente, lo antes posible, se emitirá una corrección que permitirá activarlo nuevamente (backout+roll-forward). Obviamente, si hay motivos de negocio que lo requieran o defectos demasiado serios, se podría remover completamente el código.

Sin ánimo de matar el tema, sino más bien ponerlo en discusión…

Twitter perdió parte significativa del valor de su acción por estar abajo varias horas en varias partes del mundo, debido a que subieron a los servidores código incorrecto. Le echan la culpa al CEO… al parecer perdió el control…

Y la acción hace años que viene bajando porque además el modelo de negocio no tiene sentido. ¿Qué es Twitter realmente? ¿Un facebook reducido? ¿Reemplaza a CNN? ¿Un juego de niños? ¿Porqué tantos bugs y tantos outages?

Entiendo que se quiera sacar rápido código a producción y que si el proceso es rápido, si cometo un error, puedo subir rápido la corrección… Y ojalá nadie se de cuenta…

Pero en la práctica cuando un servicio ya lo usa mucha gente, se vuelve como decir: se cayó internet. O se cayó gmail (hay empresas en que todo el correo corporativo está en gmail).

A menos que la empresa sea seca en planes de contingencia, sitios redundantes, clusters con máquinas redundantes y el software sea probado hasta el último bit antes de hacer upgrade… y que las vueltas atrás tomen menos de 5 minutos… Pero en la práctica son horas sin el servicio.

Cuando hablamos de Scrum o Kanban es muy entretenido desarrollar así. Pero si yo soy el encargado de operaciones, no creo que esté muy feliz de que suban código a producción los desarrolladores a las 3 am entre medio de tomarse unas cervezas…

Toma el caso de Amazon: Estar una hora abajo significa varios millones de dólares menos en ventas. Algo así como el sueldo mensual de unos 300 desarrolladores, o el sueldo anual de un equipo de 30 desarrolladores.

O tu sueldo de 10 años.

La empresa no tiene como recuperarlo.

La única manera de evitar este problema es tener ambientes de prueba que ejecuten rápido, es decir, muchas máquinas que ejecuten todas las pruebas en paralelo y paren la salida a producción. Es decir, probarlo todo. Eso que suena tan extraño. Pero que en la práctica no es tan dificil.

Piensa en el bug del Pentium que calculaba mal en punto flotante y eso generó un bug en Excel… y lo descubrió un físico que usaba Excel para hacer cálculos… Eso sí que es raro… Ahora imagina cuántos cálculos de sueldo, cuantas facturas, etc. estuvieron malas en todo el mundo… Y todo porque Intel no hizo pruebas ni Microsoft tampoco. Por suerte estas empresas se protegen en sus EULAs…

En Amazon se hace devops, cada programador pasa su código directo a producción… pero para eso se hacen pruebas automatizadas antes de pasar a producción. Es decir, tu código, una vez que pasa la aprobación normal para subir al repositorio, está durante horas ejecutando pruebas para pasar a producción… y pasa automáticamente…

Y aparte de eso, en Amazon, la salida a producción se hace con A/B testing, de modo que sólo un 1% de los usuarios se ven afectados. Luego de una hora de operación impecable, 5%… luego 10%… luego 30%… luego 50%… luego 100%.

De esa manera, si tu código está realmente malo, se va a notar cuando pase al 1%… entonces será irrelevante… o cuando pase al 5% (pero no afectará al 5%, sino a lo más al 0.5%, sino el 1% no hubiera pasado)… etc.

¿Se comprende?

El paso hacia atrás también es automático.

Aún así, a veces en Amazon alguien se pitea algo… Porque no tienen 100% de los tests. ¿Cuántos millones de dólares dijimos que costaba el outage? Porque con esa plata te pongo las máquinas para que no haya outage.

2 Me gusta