Mi error hizo que la empresa ahorrara 500 mil dólares

• Un ingeniero redujo la configuración de inactividad de 10 minutos después de las consultas en Snowflake, y con eso el costo anual estimado de la base de datos bajó de alrededor de 1 millón de dólares a 500 mil dólares
• La Advanced Analytics Platform, retrasada durante años, incluso después de salir seguía dependiendo de una cadena ETL compleja enredada entre hojas de cálculo, S3, Lambda, MongoDB, Snowflake y procedimientos almacenados en JavaScript
• La clave del desperdicio era una estructura donde se procesaba menos de 1 TB de datos al día, pero el cómputo permanecía encendido mucho tiempo después de consultas de 2 segundos en promedio
• El cambio se aplicó primero solo a parte del cómputo, y aunque el gerente reconoció el ahorro, quiso retrasar su adopción total; en PowerPoint se presentó como una optimización basada en análisis de patrones de uso
• Incluso después de recortar 500 mil dólares, la recompensa seguía siendo incierta y solo aumentaron las reuniones y la carga de reportes, en otro ejemplo de cómo la ineficiencia organizacional puede generar un costo político mayor que una acción individual de pocos minutos

---

Una plataforma de analítica retrasada durante años

• La empresa decidió crear una plataforma de analítica con la idea de trabajar de forma más data-driven y contrató personal relacionado
• El ingeniero, que entró como científico de datos, no pudo hacer trabajo real de ciencia de datos, y cada vez que pedía cómputo para machine learning o pipelines de datos le respondían que esperara hasta el despliegue de Advanced Analytics Platform, es decir, AAP
• Al principio AAP estaba prevista para lanzarse en enero, luego se movió a marzo, y después quedó en pausa con Covid como motivo
• Tres años después de que él dejara la empresa, AAP por fin estaba lista para salir, pero resultó que las funciones que realmente necesitaban ni siquiera estaban en el plan original
• Esa misma semana, cuatro ingenieros dejaron la empresa, y él se unió al equipo de AAP después de poner ciertas condiciones

La deuda técnica que se hizo visible justo después del lanzamiento

• Aunque AAP acababa de lanzarse, ya tenía mucha deuda técnica y riesgos operativos
• Un colega recién contratado descubrió en su primer día un archivo con el que, si alguien entraba a la carpeta equivocada del repositorio del proyecto, podía borrar producción a través del pipeline de CI/CD
  • Ese archivo también incluía las claves y contraseñas necesarias para una cuenta de administrador
• Cambiar permisos de acceso a la base de datos implicaba subir un CSV de apenas unos 2 KB, pero aun así pasaba por un flujo excesivamente largo
  • Python parseaba la hoja de cálculo
  • El resultado se enviaba a S3
  • Lambda lo convertía otra vez y lo dejaba en S3
  • MongoDB tomaba el archivo desde S3
  • Otra Lambda enviaba los registros de MongoDB a S3
  • Snowpipe importaba los datos de S3 a Snowflake
  • Un procedimiento almacenado en JavaScript pivotaba los datos de Snowflake a formato relacional
• El equipo de seguridad pidió un formato fácil de escanear para contenido malicioso, así que todo se convirtió a CSV, pero la supuesta herramienta de escaneo nunca se desplegó
• Las funciones Lambda empezaban con un counter = 1, vestigio de una implementación anterior, y esa línea se había seguido copiando
• Las pruebas de CI/CD quedaron fallando durante meses porque al depurar con el comando tee se sobrescribió el código de error de fallo
• La obtención de contraseñas para la API también estaba enredada en dos pasos
  • Si buscabas una clave como service-password en un servicio de AWS, el valor devuelto también era service-password
  • Luego ese valor se usaba para buscar la contraseña real en otro servicio
• El script que generaba el archivo de configuración del pipeline empezaba con 600 líneas comentadas, “por si luego hacían falta”

La configuración de Snowflake que disparó los costos

• La plataforma era varias veces más cara que el modelo operativo anterior y se pasó por mucho del presupuesto de costos de base de datos
• Al parecer el costo operativo anual original estaba pensado en alrededor de 200 mil dólares, pero la proyección real se acercaba a 1 millón de dólares
• La base de datos era Snowflake, y Snowflake cobra según el tamaño de las computadoras que ejecutan las consultas
• El cómputo solo genera costo mientras está encendido
• El equipo ejecutaba miles de consultas por semana, y la mayoría eran consultas de prueba de desarrolladores que iban ajustando poco a poco reportes de PowerBI que nadie leía
• El tiempo promedio de ejecución de las consultas era de unos 2 segundos, pero el cómputo estaba configurado para quedarse inactivo durante 10 minutos después de cada consulta
• Cerca de un mes después de unirse, él detectó esa configuración y propuso cambiarla, pero la conversación se fue solo por el lado procedimental de que antes había que hacer trabajo de discovery, y nunca se ejecutó

Un cambio de 5 minutos y su validación

• Meses después, le asignaron una tarjeta de “Discovery: Optimise Costs”, y como necesitaba tener algo que contar en el siguiente standup, decidió comprobar por su cuenta su hipótesis previa
• Quiso pedir acceso de administrador para dárselo a un ingeniero nuevo de otro equipo que parecía competente, pero el gerente no lo permitió
• En su lugar compartió credenciales de base de datos de menor nivel, sin privilegios de administrador, y ese ingeniero hizo una validación de sentido común del potencial de ahorro
• El último día de la semana a las 4 de la tarde, él verificó en un chat de ingenieros sin administradores que no hubiera problema y luego cambió la configuración
• Por seguridad, lo aplicó primero no a todo el cómputo, sino solo a parte del cómputo

El efecto del ahorro y la reacción de la organización

• El lunes siguiente, la factura estimada cayó de alrededor de 1 millón de dólares a 500 mil dólares
• El equipo presentó esto como un gran logro de ahorro, pero desde su punto de vista se parecía más a simplemente detener un gasto que ya venía siendo absurdo
• Otros equipos cuestionaron que un ingeniero recién incorporado hubiera llegado justo cuando apareció ese ahorro, y preguntaron por qué antes nadie lo había detectado
• El gerente estaba contento, pero también pensaba que si aplicaban el cambio de inmediato a todo el cómputo el departamento iba a llamar demasiada atención y surgirían preguntas no deseadas
• Quedó implícita la idea de aplicarlo poco a poco para que pareciera un trabajo que había tomado mucho tiempo
• Él tuvo que preparar un PowerPoint, y el mensaje terminó redactado en términos como: “Un análisis estadístico cuidadoso de los patrones de uso mostró oportunidades para una asignación de recursos más eficiente”
• En la práctica, el cambio real fue solo ajustar una configuración para que el cómputo caro no se quedara inactivo todo el día

La carga que quedó después del logro

• Él concluyó que, moviéndose de manera informal y encontrando a unos pocos buenos ingenieros, logró un resultado mayor con más facilidad que todo el departamento
• Pensó que sí había gente competente dentro de la organización, pero que la estructura misma no les permitía ejercer influencia
• Después de ahorrar 500 mil dólares, pidió un aumento de 30 mil dólares, pero su mensaje quedó sin leer y espera no recibir nada o, con suerte, unos 5 mil dólares
• Empezaron a aparecer más reuniones para hablar del ahorro de costos, y además quedó la carga de hacer PowerPoints
• Cierra diciendo que quizá le habría convenido más no hacer nada: con 5 minutos de acción logró el mayor impacto de su carrera, pero de inmediato terminó cargando más trabajo

[GN⁺]

Opiniones de Hacker News

• Todo este artículo me resulta demasiado familiar.
  En la US Navy, mi historial profesional por reducción de costos fue de más de 50 millones de dólares. Cada vez que hacía algo tenía que armar un PowerPoint y presentarlo ante oficiales de alto rango, y una vez casi me castigaron duramente porque no dejé que mi jefe se llevara el mérito. Eso a pesar de que mi jefe ni siquiera sabía qué había hecho yo, así que tampoco tenía intención de llevarse el mérito.
  Parte de eso fue durante una época en la que trabajé en proyectos de toda la organización como Lean Six-Sigma Black Belt, y llegué a odiar toda esa expresión. Literalmente mi trabajo era reducir al máximo los costos del DOD, y fue la peor etapa de mi carrera. Ese fue el premio por haber resuelto por mi cuenta problemas que ahorraron millones de dólares.
  Estoy de acuerdo con la parte final del artículo. Hay que tener cuidado con hacer bien las cosas en el trabajo. La recompensa casi nunca es dinero, sino más trabajo por el mismo sueldo.

  • Eso pasa cuando te tocan el trabajo equivocado y el jefe equivocado. Siento que tuve mala suerte porque ahora estoy en un lugar malo de esos.
    Antes estuve en un lugar mucho mejor, y si yo tomaba la iniciativa para ahorrar millones de dólares, realmente me felicitaban y mi jefe también me reconocía el mérito.
    Nunca hay que quedarse en un trabajo con una cultura tóxica. Aunque pague mejor. No hay nada que te desgaste más el alma que estar aplastado por arribistas incompetentes y mezquinos, y fanáticos del control.
  • Tuve un profesor de ingeniería industrial que había hecho carrera en eficiencia energética dentro del ejército.
    La idea era: “Lo bueno del gobierno de Estados Unidos es que es tan grande que, si el óptimo es ahorrar 30% y con la segunda mejor solución ahorras solo 29%, igual sigues ahorrando decenas o cientos de millones de dólares, así que nadie se da cuenta”.
    Uno de los proyectos grandes fue la eficiencia energética de campamentos militares remotos. Llevar combustible a algunas zonas de Afganistán costaba alrededor de 100 dólares por galón, y había montones de generadores móviles funcionando al 20–40% de su capacidad. Si no recuerdo mal, alrededor de 70% era el punto más eficiente; construyendo edificios pequeños o conectando varias carpas a un solo generador, se podía reducir mucho el consumo de combustible y además mejorar la calidad del servicio.
  • A veces pienso en entrar a alguna agencia gubernamental de tres letras para buscar dónde mejorar la eficiencia de costos, o contribuir directamente como forma de agradecerle a Estados Unidos por haberme aceptado como inmigrante.
    Como ingeniero en FAANG trabajé en cosas directamente relacionadas con el flujo de dinero, y también tengo experiencia en varias áreas donde podría ser útil.
    Pero luego pienso que encontrar a la persona adecuada y el área adecuada para trabajar probablemente sería el 95% del trabajo, y termino desistiendo.
  • Con solo ver la expresión Six-Sigma Black Belt ya me pongo tenso. La peor empresa en la que trabajé contrataba SSBB como loca, y ellos en realidad no hacían nada ni lograban resultados.
    Pero si tomabas el curso, el sistema te impulsaba rápidamente para ascender.
  • Esto es una gran fuente de desesperanza para mí, y lo viví directamente en dos trabajos.
    Quiero un empleo estable de asalariado, pero sé que, si soy bueno, los gerentes lo verán como tiempo libre y me encajarán más trabajo hasta el límite. La gente codiciosa nunca aceptará repartir ingresos ni compartir ganancias; simplemente te dan un aumento anual de 5% y esperan que te calles y trabajes.
    Hace algunos trabajos, en la empresa me pidieron que anotara los nombres de los proyectos que mantenía activamente, y la lista llenó dos pantallas completas en Excel con el tamaño de fuente predeterminado. Terminé tan quemado que caí en una depresión severa.
    Lo peor es que también odio esa estupidez tipo ritual de sumisión que es buscar trabajo.

• Me recuerdan a los artículos de Dan Luu: https://danluu.com/nothing-works/
  Con las herramientas de software para chips pasaba algo parecido. Lo estándar era tercerizar las herramientas con grandes proveedores de EDA, pero vimos un gran impacto con herramientas a medida que habíamos creado nosotros, normalmente hechas o mantenidas por una sola persona.
  Durante el tiempo que estuve allí, la mayoría de los ciclos de simulador corrían en un simulador personalizado mantenido por una sola persona, y gracias a eso se ahorraban millones de dólares al año en costos de simulador. En ese momento, el precio estándar era de varios miles de dólares al año por una licencia de simulador, y la granja de máquinas de simulación tenía alrededor de mil equipos.
  Si una sola persona puede crear o mantener una herramienta que vale millones de dólares al año para una empresa, uno pensaría que la competencia haría lo mismo, pero en la práctica la mayoría no lo hacía. Es lo mismo que pasaba con contratar a alguien que supiera abrir y analizar wafers: permitiría lanzar más rápido y más barato, pero los competidores no lo hacían.

  • Trabajé en EDA, y sí, el software es malo, pero los compradores son conservadores. Es un negocio así de riesgoso y caro.
    Dan Luu habla de la “versión de cóctel de la hipótesis del mercado eficiente”, pero la versión económica de “nada funciona” se parece más a https://en.wikipedia.org/wiki/The_Market_for_Lemons. Es un texto sobre el papel de la información y la asimetría de información en los mercados.
    La hipótesis del mercado eficiente falla porque el conocimiento perfecto es imposible y la selección adversa existe de verdad.
  • Pienso seguido en ese artículo y en el de cultura (https://danluu.com/culture/).
    Hay empresas que son exactamente lo contrario de lo que describe el artículo original. Una vez que trabajas en una empresa así, se vuelve imposible volver a conformarte con un mal lugar.

• Todo el artículo es oro puro.
  Los gerentes preguntaron cómo había sido posible ahorrar tanto sin su ayuda, pidieron preparar diapositivas, preguntaron varias veces qué había pasado, hubo que desplegarlo lentamente para que pareciera algo gradual con el tiempo y no cosa de un pequeño toggle, y aunque pidió un aumento acorde al impacto, no se concretó.
  Por su propio bien, le convendría postularse a un lugar como FAANG. Como mínimo, hay más probabilidades de que lo cuiden mejor.
  Y si agrega metadatos de Twitter Card al blog, probablemente se verá mejor en Twitter.

  • Si yo no hubiera recibido un aumento, habría aceptado todo y luego habría empezado la presentación diciendo algo así:
    “Hola, voy a explicar cómo fue posible ahorrar 500.000 dólares. Básicamente, durante un día revisé lo mal desplegada que estaba la infraestructura original y eliminé la función de prueba de código que estaba causando el problema. Fue un oversight total en todos los aspectos: desarrollo, gestión y pruebas. En general, este código estaba lo más cerca posible de ser lo peor, y aun así se lanzó. Y me dijeron que no dijera esto porque deja mal a todos, y que lo desplegara de forma gradual para que pareciera que los gerentes habían hecho algo”.
    Después habría soltado el micrófono y me habría bajado del escenario.
    Sinceramente, creo que se me habrían ido casi todas las ganas de preocuparme. Y eso que llevo casi 20 años en esto, y soy de los que sí se preocupan por el trabajo porque hay que pagar cuentas y alimentar a los hijos.
  • Hace tiempo, en un proyecto financiado con impuestos, encontré una forma de ahorrar unos 250.000 dólares al año.
    Armé una hoja de cálculo con el modelo de costos, la documenté y se la entregué a mi jefe; me dijo que “la iba a revisar”. Dos semanas después le pregunté si la había visto y me dijo: “Parece correcto. Buen trabajo”. Le pregunté si lo íbamos a probar, y su respuesta fue una joya:
    “No, a nosotros no nos pagan por ahorrar dinero; nos pagan por gastarlo”.
    Ahí fue cuando de verdad entendí los contratos gubernamentales de Cost+Award Fee.
  • No sé si todos mis amigos son malos desarrolladores, pero últimamente no he escuchado que en FAANG traten bien a la gente. Sobre Netflix no he escuchado nada reciente.
  • Al menos en FAANG casi puedes usar documentos de texto plano en lugar de PowerPoint.
    La desventaja es que probablemente tengas que escribir ese documento antes de hacer el cambio, someterlo a revisión de todo el equipo y lograr que todos queden “alineados”.
  • ¿Xitter no eliminó hace poco la visualización de metadatos de sitios externos, salvo las imágenes?

• No ahorró 500.000 dólares por accidente; ahorró 500.000 dólares de forma intencional y ahora se arrepiente. No es lo mismo.
  Las organizaciones grandes son tan ineficientes que sorprende que puedan competir, pero tienen mucho dinero, economías de escala y cosas por el estilo. En el proceso pueden quemar millones de dólares en despilfarros e ineficiencias absurdas sin que a nadie le importe demasiado.

  • Es fácil de entender. Las organizaciones grandes compiten con otras organizaciones grandes igualmente ineficientes. La eficiencia en organizaciones grandes es un problema humano realmente, realmente, realmente difícil, y todavía no lo hemos resuelto.
    Aun así, siguen ofreciendo servicios o productos valiosos. Por ineficientes que sean, son más eficientes que si no existieran en absoluto. Por eso esas organizaciones existen incluso sin competencia.
    Uno podría preguntar qué pasa con la competencia de organizaciones pequeñas. Las organizaciones pequeñas tienen menos eficiencia de escala, pero si son eficientes en otros aspectos, a veces pueden competir eficazmente con las grandes empresas. Pero cuando crecen y se convierten en organizaciones grandes, terminan adquiriendo las ineficiencias de las organizaciones grandes.
    Así es como funciona. No es que a nadie le importe; al contrario, a los dueños de las empresas les importa muchísimo. El problema es que, literalmente, nadie sabe cómo resolverlo.
  • La competencia normalmente se elimina con uno o más fosos defensivos: enormes inversiones iniciales de capital, patentes, contratos de bloqueo de mercado (por ejemplo, la forma en que Windows se vende a los OEM), integración vertical (por ejemplo, Apple), cumplimiento regulatorio (en la práctica es difícil crear un banco o un hospital desde cero), compra de competidores, contratación de personal de competidores (por eso en FAANG hay tanta gente con sueldos altos trabajando en cosas que se cancelan), o medios menos legítimos.
    Las grandes empresas tienden a terminar con patrones de fracaso parecidos a los de empresas bajo control estatal autoritario. También es interesante cómo China ha logrado caminar la cuerda floja entre control y crecimiento en este aspecto.
  • Por lo general no compiten. Si el gobierno no hace cumplir sus propias reglas, estas empresas simplemente compran a sus competidores.
    Estrangulan el mercado y, al mismo tiempo, se vuelven más ineficientes.
  • La única razón por la que existe el 99% de las grandes empresas es que crecieron antes que los demás, y ese tamaño les da la fuerza para mantener a todos los demás abajo.
    La competencia es un cuento de hadas que les cuentan a los MBA para que inicien nuevos negocios y parezca que existe competencia. Para empezar, nunca tuvieron oportunidad.
  • De verdad creo que la inflación sale de ahí. Cada vez que se pagan sueldos que no aportan utilidad, el resultado se vuelve más caro o menos rentable.
    Si pudiéramos eliminar todo el desperdicio mediante optimización, creo que habríamos tenido deflación mientras las computadoras y los procesos de negocio seguían volviéndose más eficientes.

• Hace tiempo encontré un bug y recuperé 4 millones de dólares de ingresos anuales
  Lo enterraron para proteger al equipo y a los ejecutivos que habían dejado que ese error siguiera tanto tiempo. No recibí un aumento, pero me hice algunos aliados y pude tomármela con calma por un tiempo

  • Muy al inicio de mi carrera, cuando trabajaba en un hedge fund, encontré un equipo de red crítico para la misión que habría provocado un loop de red si se reiniciaba
    Dos servidores estaban relacionados con ciertos datos de feed y noté que los cables estaban conectados de forma extraña, distinto de la descripción funcional que me habían dado
    El costo estimado de downtime de ese sistema era de unos 7 millones de dólares por minuto. Planteé el problema a varias personas a cargo y al equipo de redes, pero me ignoraron por completo con el argumento de que “no es posible que lo hayamos conectado así” y porque yo era nuevo
    Como parecía importante, volví a plantearlo en la reunión semanal del grupo, y alguien fue a revisarlo en persona y volvió diciendo que era exactamente como yo había dicho. Era un problemón, y el equipo de redes tuvo que hacer trabajo urgente durante unas 2 semanas para resolverlo prolijamente
    Todos se enojaron conmigo. Aunque había evitado una catástrofe para la empresa, al hacerlo hice quedar mal a todos, sobre todo porque mi posición dentro del equipo era baja. Fue una lección importante
  • Al inicio de mi carrera hice algo parecido, y eso sí llamó bastante la atención
    El sistema que construí para corregir un bug era, en la práctica, un ataque de intermediario contra el envío de recetas a farmacias. Como las farmacias nunca aplicaban las actualizaciones de precios, revaluábamos el precio justo antes de que la receta llegara al sistema de la aseguradora. Trabajaba en una pequeña cadena de farmacias independientes y no había un sistema central de dispensación
    En ese momento, con una genialidad infinita, le puse al sistema el nombre de la persona que me gustaba. A la oficina central le encantó tanto que creó un premio anual con el nombre de mi sistema, que terminó siendo un premio con el nombre de esa persona, pero me daba demasiada vergüenza contar el verdadero origen
    Aunque esto fue hace 25 años, hasta hoy todos los años se fabrica y se entrega un trofeo con el nombre de mi antiguo amor platónico. Creo que si esa persona se enterara se horrorizaría

• Este tipo de cosas ha existido desde siempre
  Hace mucho entré a una sala llena de terminales VT100; era un fin de semana de fin de semestre y había estudiantes de CS aburridos esperando a que terminaran sus compilaciones. Miré el sistema y vi que todas las compilaciones estaban en una cola batch, cuya prioridad predeterminada era menor que la de los trabajos interactivos. Así que cualquier pulsación de tecla, desde cualquier lado, tenía mayor prioridad, y mientras más revisaba la gente en qué posición estaba su compilación, más lento se volvía todo
  Durante los siguientes 15 minutos seguí subiendo la prioridad del trabajo al inicio de la cola, y una hora después todos habían terminado sus trabajos y se fueron a casa. La sala quedó para mí. Victoria del administrador de sistemas no autorizado ;-)

• Hace unos meses encontré un bucket de S3 que no dejaba de crecer y consumía 80 mil dólares al mes, con lo que le ahorré a la empresa 1 millón de dólares al año
  Al revisarlo, un sistema que ya no se usaba estaba copiando archivos a ese bucket. Contacté a los stakeholders, y ellos lo apagaron y borraron los archivos
  A los de arriba no pareció importarles mucho. El jefe de mi jefe me dijo que contactara a otro equipo que originalmente debería haber detectado esto, y eso fue todo

  • A un proveedor SaaS que usamos le está pasando lo mismo. Se lo dijimos y no le dieron importancia. Supongo que será dinero de VC :D

• “Por ejemplo, ejecutaron 234,745 INSERT en [table name deleted]_HOURLY, y todos tenían menos de 1000 filas”
  Eso se dijo literalmente en el Slack de soporte de Snowflake de nuestra organización, y era casi el mismo problema. Pequeñas transacciones distribuidas en el tiempo que mantenían el clúster despertándose. Este producto no fue diseñado para un caso de uso tan común como la ingesta continua de bajo volumen
  Soy administrador de data warehouses con experiencia real, así que estoy viendo cómo la gente redescubre mi descripción de puesto a medida que sufre sobrecostos uno por uno. Dicen en serio cosas como “es autogestionado, pero hay que monitorear los costos y reescribir las ingestas y las consultas para que sean más eficientes”. Me da miedo preguntar qué creen que hago todo el día

• Hace mucho tiempo, en una galaxia muy, muy lejana, reemplacé algo que requería N × (licencias de Oracle + servidores Sun) por un script Perl de menos de 100 líneas y un solo servidor Sun, ahorrando más de 300 millones de dólares al año
  En el proceso también inventé MapReduce. Antes que Google
  El problema era calcular varias estadísticas a partir de los logs de servidores web. Por ejemplo, las 10 páginas más populares. La solución original era, como los logs eran enormes, cargarlos todos en bases de datos Oracle que corrían en varios servidores, ejecutar varias consultas SQL y repetirlo todos los días

• La galería de comentarios destacados de HN sobre los textos del autor es excelente: https://ludic.mataroa.blog/compliments/

  • Algunos son válidos. A veces el autor parece un poco egocéntrico. Parece partir de la premisa de que “todos los demás son incompetentes y yo soy el salvador”
    También es muy posible que muchas personas dentro de la organización estuvieran mucho más adelantadas que el autor. Es más probable que un ingeniero o manager del mismo grupo estuviera guardando esa ineficiencia para usarla en una época de recortes de costos, y que el autor haya arruinado esa oportunidad. Entonces, cuando no haya nada que recortar, pueden volverse inevitables un dolor enorme y malas evaluaciones de desempeño
  • Me recuerda a @shit_hn_says, lamentablemente inactiva [1]
    Probablemente esté inactiva porque el nivel del discurso en HN cayó tanto que ahora casi todos los comentarios podrían ser candidatos
    [1] https://twitter.com/shit_hn_says