La charla de Flickr sobre 'más de 10 despliegues al día' pone fin a la guerra entre desarrolladores y operaciones

En 2009, Flickr, el sitio para compartir fotos dentro de Yahoo, actualizaba su servicio constantemente, y la división por defecto del sector —los desarrolladores publican funcionalidades, operaciones mantiene el sitio estable— convertía cada cambio en una pelea. El cambio es la causa raíz de la mayoría de las caídas, así que los equipos que 'protegen' el sitio con más ahínco son los que despliegan más despacio.

Hacer que el cambio sea seguro en lugar de escaso: herramientas compartidas —indicadores de funcionalidad, despliegues en un solo paso, métricas compartidas, robots de chat— más una cultura sin culpabilización hacen rutinarios más de 10 despliegues al día.

El gerente del lado de operaciones, John Allspaw, y el gerente del lado de ingeniería, Paul Hammond, reconstruyeron las publicaciones en torno a la propiedad conjunta: infraestructura automatizada, un único tronco compartido de control de versiones, compilación y despliegue en un solo paso, indicadores de funcionalidad, paneles de métricas compartidos y robots de chat en IRC —junto con una lista explícita de cultura: respeto, confianza, una actitud sana ante el fallo y evitar la culpabilización.

Su sesión en Velocity de junio de 2009 atrajo más atención que cualquier otra charla de la conferencia, y el planteamiento de herramientas más cultura se convirtió en el núcleo del manual de DevOps: meses después, el movimiento se puso nombre en el primer devopsdays en Gante, y 'despliegues por día' se convirtió en un referente del sector.

En 2009, Flickr, el sitio de fotos dentro de Yahoo, publicaba constantemente: en un día normal hacía diez o más despliegues completos del sitio web a producción. En la conferencia Velocity de O'Reilly en San José ese junio, los dos gerentes que dirigían los lados de operaciones e ingeniería de Flickr, John Allspaw y Paul Hammond, explicaron cómo lo hacían en una charla titulada '10+ Deploys Per Day: Dev and Ops Cooperation at Flickr'. El reportaje de Data Center Knowledge desde la conferencia la calificó como la presentación que generó más expectación del evento.

Su argumento atacaba el organigrama por defecto del sector. El estereotipo —los desarrolladores añaden funcionalidades, operaciones mantiene el sitio estable y rápido— convierte el cambio en el enemigo, ya que el cambio causa la mayoría de las caídas. Allspaw y Hammond lo invirtieron: el trabajo de operaciones es habilitar el negocio, el negocio requiere cambio, así que el verdadero trabajo es reducir el riesgo del cambio mediante herramientas y cultura. El conjunto de herramientas: infraestructura automatizada, un tronco compartido de control de versiones, compilación y despliegue en un solo paso, indicadores de funcionalidad que publican código oculto, métricas compartidas y robots de IRC que permiten a cualquiera ver cómo ocurren las publicaciones.

La otra mitad era cultural: respeto, confianza, una actitud sana ante el fallo y evitar la culpabilización —incluidos simulacros para que incluso los ingenieros junior hayan practicado incidentes en producción antes de uno real, porque los fallos ocurrirán. Ese octubre, Patrick Debois organizó el primer devopsdays en Gante, Bélgica; el movimiento que tomó su nombre de ese evento llevó el planteamiento de la charla de Flickr —publicaciones pequeñas, seguras y frecuentes por equipos que comparten herramientas y no culpan a nadie— a las organizaciones de ingeniería de todo el mundo.

Nombró la restricción real: en un negocio web, el tren de publicaciones es el negocio, y un equipo que puede desplegar con seguridad diez veces al día simplemente aprende más rápido que uno que publica mensualmente.

Las herramientas compartidas fabricaron un destino compartido —un tronco, un panel, un botón de despliegue—, de modo que ningún lado podía ganar haciendo perder al otro.

Redefinió operaciones de guardián de la estabilidad a habilitador del cambio, permitiendo juzgar la automatización y la cultura con una sola pregunta: ¿con qué frecuencia podemos publicar con seguridad?

Trató la culpabilización como un defecto de ingeniería, no como un defecto de carácter: si las personas ocultan errores, el riesgo se acumula en silencio; los simulacros y las revisiones sin culpabilización mantienen la información en movimiento.

El rendimiento proviene de hacer que el cambio sea seguro, no escaso. Las herramientas compartidas crean un destino compartido; la culpabilización enseña a los ingenieros a ocultar el riesgo; operaciones habilita el negocio, no protege el tiempo de actividad frente al negocio.

La grabación de la sesión sigue en línea y todavía se muestra como un artefacto fundacional de DevOps. Ese octubre, el primer devopsdays de Debois en Gante dio nombre al movimiento, y '¿cuántos despliegues al día?' se convirtió tanto en un referente como en un desafío. Allspaw llevó el enfoque a Etsy, donde sus primos —las autopsias sin culpabilización y el despliegue continuo— se hicieron famosos por derecho propio. Una década y media después, la frecuencia de despliegue es una métrica estándar de ingeniería, y 'desarrollo frente a operaciones' sobrevive sobre todo como el hombre de paja que esta charla demolió.