Capítulo 4. El lenguaje de las FinOps El lenguaje de las FinOps

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Es probable que cada equipo de tu organización utilice términos específicos de una disciplina, vea los datos de facturación en la nube desde una perspectiva diferente y tenga motivaciones distintas para lo que les gustaría conseguir. Este capítulo trata de cómo puedes hacer que los equipos colaboren más eficazmente educando al personal sobre los términos específicos que utiliza cada uno y definiendo un léxico común para fomentar la alineación y la confianza.

Una empresa en fase inicial suele empezar con una simple visibilidad del gasto diario que muestra a los equipos sus respectivos gastos. Sin embargo, el léxico común es importante no sólo para los que se inician en FinOps, sino incluso para las prácticas FinOps más versadas. A medida que aumenta tu madurez en la nube, se amplía la cantidad de terminología utilizada en tus informes de gastos. A medida que sigues añadiendo áreas de capacidad en tu práctica de FinOps, aumentas el consumo de servicios adicionales en la nube y te vuelves más granular en tus informes, acabas con una terminología aún más específica de cada disciplina. Esto aumenta la posibilidad de utilizar términos ambiguos (o duplicados), lo que puede crear confusión y falta de confianza en los datos. La coherencia se vuelve aún más importante en etapas posteriores, para proporcionar una mejor comprensión de cómo se relacionan todos los informes entre sí e impulsar la responsabilidad de los respectivos equipos. Intenta evitar el uso de términos esotéricos propios de disciplinas como las finanzas o la ingeniería, y procura acordar un léxico estandarizado.

Definir un léxico común

Es fácil poner de manifiesto la necesidad de un léxico común: basta con pedir a un equipo financiero y a un equipo de ingenieros que describan cada uno un servicio en . Un equipo de finanzas suele pensar en los costes y tarifas de los servicios, mientras que los ingenieros pensarán más en la disponibilidad, fiabilidad y capacidad disponible de su servicio. Ambos son correctos. La desconexión se produce cuando estos equipos intentan comunicarse entre sí, lo que la nube les obliga a hacer mucho más a menudo de lo que era habitual en la época de los centros de datos. En aquel pasado no tan lejano, los equipos de operaciones sólo interactuaban con los costes cuando proponían nuevas compras de equipos. Después de eso, su trabajo diario se centraba en la eficiencia y el rendimiento de sus servicios. Los equipos de finanzas, alternativamente, se centraban en qué gastos estaban comprometidos y con cargo a qué presupuestos debían amortizarse.

Cuando distribuyes el poder de compra de tecnología por toda tu organización, tienes que asegurarte de que todos los equipos utilizan el mismo vocabulario para describir los costes, y de que no sobrecargas los términos para que signifiquen cosas distintas para personas distintas. El lenguaje se vuelve más complejo cuando añades términos específicos de los proveedores de servicios en la nube, y se acerca rápidamente a la incoherencia cuando cambias entre varios proveedores de servicios en la nube y su nomenclatura específica de vendedor.

Si cada informe que generas también tiene que venir acompañado de un diccionario de términos -o peor aún, alguien tiene que sentarse y enseñar a un equipo cómo leer un informe-, eso impide la colaboración entre equipos que constituye el núcleo de las FinOps. La gente se negará a dedicar a los informes el tiempo necesario para entenderlos, mientras que el profesional de FinOps se quedará rápidamente sin ancho de banda para mantener a todo el mundo informado.

Para construir un lenguaje común en toda la organización, los informes deben utilizar sistemáticamente términos específicos, y los equipos deben haber aprendido a interpretarlos correctamente. Aunque una persona pueda entender que costes divididos significa lo mismo que asignación de costes, eso no será de conocimiento común en los inicios de FinOps.

Siempre que sea posible, es mejor utilizar construcciones lingüísticas existentes en lugar de crear términos totalmente nuevos que los equipos deban aprender. Y si un proveedor de servicios en la nube utiliza una terminología que no se ajusta al lenguaje empresarial existente, es mejor traducirla antes de informar a los equipos.

Definición de los términos básicos

Por supuesto, hacer que todos lean este libro también ayudará a construir una comprensión común de los términos utilizados en FinOps. Definamos algunos términos utilizados en el sector:

Imputación de costes (o atribución de costes)
El proceso de dividir una factura de nube y asociar los costes a cada centro de coste. El capítulo 12 trata este proceso con más detalle. Es importante que los equipos comprendan cómo se asignan los costes, y que tengan una estrategia de asignación de costes centralizada, controlada y coherente.
Uso desaprovechado
Uso de recursos que una organización no utiliza activamente . Si se aprovisiona un recurso, un proveedor de servicios en la nube seguirá cobrando por él, aunque no se utilice.
Sobredimensionado/infradimensionado
Cuando se aprovisiona un recurso en la nube mayor de lo necesario, como tener demasiada memoria o potencia de cálculo, se considera sobredimensionado. Cabe señalar que lo contrario también puede ser cierto. En el caso de los recursos sobredimensionados, puedes aumentar el tamaño si obtiene más valor empresarial de la potencia adicional.
Redimensionamiento
El Rightsizing es el acto de cambiar el tamaño de los recursos aprovisionados a uno que se ajuste mejor a las necesidades.
Gestión de la carga de trabajo
La práctica de garantizar que los recursos que se ejecutan en la nube sólo lo hacen en los momentos en que se necesitan. Es una de las prácticas que permite a los ingenieros optimizar el uso.
Tarifa a la carta
La tarifa normal o base que se paga por un recurso en la nube. Es el precio público de un recurso en la nube.
Reducción de tasas
Utilizar descuentos basados en compromisos como Planes de Ahorro (SP), Instancias Reservadas (RI), Descuentos por Uso Comprometido (CUD), CUD Flexibles, o acuerdos comerciales entre una organización y un proveedor de servicios en la nube para recibir una tarifa más baja por los recursos utilizados.
Evitación de costes
Al reducir el uso de recursos, ya sea eliminando un recurso por completo o redimensionándolo, puedes evitar pagar por recursos que habrían supuesto un gasto. Este método de reducir el gasto en la nube se tratará en el Capítulo 15. Ten en cuenta que no habrá nada en los datos de facturación que haga un seguimiento real de la evitación de costes; a menudo se mide como una reducción del importe del coste del ciclo de facturación del mes en curso.
Ahorro de costes
Al reducir la tarifa que pagas por los recursos, generas ahorros. A diferencia de la reducción del uso, en la que evitas costes, el ahorro de costes se representa en tus datos de facturación. El uso está ahí, pero pagas una tarifa más baja por él. Normalmente puedes hacer un seguimiento del ahorro en los datos de facturación, ya sea directamente monitoreando los créditos aplicados a una factura o comparando la tarifa pagada por un recurso frente al precio público normal. Sin embargo, los ingenieros deben confirmar con sus departamentos financieros el significado de cualquier uso de la palabra "ahorro", ya que algunos departamentos financieros interpretan el ahorro como la capacidad de reducir el presupuesto.
Ahorro realizado
Cuando se aplica un ahorro a los datos de facturación de , puedes hacer un seguimiento de la cantidad de ahorro que has generado en tu factura en la nube. Al hacer un seguimiento de los ahorros realizados frente a los esfuerzos para generarlos y mantenerlos, puedes determinar la eficacia general de tus prácticas FinOps.
Potencial de ahorro
Al mirar las previsiones de tu factura en la nube , puedes predecir la cantidad de ahorro utilizando tus compromisos y acuerdos comerciales existentes. Pero hasta que este ahorro no se aplique a tus cuentas, sólo se trata de un potencial de ahorro.
Descuentos por compromiso
Al precomprometerte con un proveedor de servicios en la nube una cantidad determinada de uso de recursos mediante SPs, RIs o CUDs, recibes una reducción en la tarifa que normalmente pagas por esos recursos.
Compromisos no utilizados/no utilizados
Por cada hora que hayas comprometido en el uso de un recurso de que no utilices, esa reserva queda sin usar, o sin utilizar. Otro término para esto es reserva vacante.
Residuos de compromiso
Tener una reserva con cierta infrautilización no es un problema siempre que el descuento que recibas sea mayor que el coste de la reserva no utilizada. Cuando la reserva te cuesta más de lo que te ahorrarías -es decir, no se utiliza en una cantidad que te ahorre más que el coste de la reserva- a esto se le llama despilfarro de compromiso.
Uso cubierto
Cuando se descuenta el cargo de un recurso mediante una reserva, se dice que está cubierto. El uso está siendo cubierto por la reserva, y el resultado es una tasa de carga menor.
Uso cubierto
No todo el uso en la nube es cubrible con un compromiso. Por ejemplo, si tienes un uso de recursos que se dispara durante el horario laboral y luego se elimina después de dicho horario, hacer un compromiso podría dar lugar a un despilfarro de compromisos y no ahorraría dinero. Sin embargo, también es posible que algún trabajo por lotes nocturno se inicie a medida que el uso diurno desaparece y un compromiso cubriría ambas cargas de trabajo, lo que supondría un ahorro para ambas. Cuando cubrir el uso con un compromiso suponga un ahorro, clasifícalo como cubrible. Lo importante es que un conjunto de recursos proporcione un uso lo suficientemente constante como para que un compromiso pueda utilizarse para ahorrar dinero, no si un único recurso funciona de forma constante.
Tasas no mezcladas (específicas de AWS)
Algunos recursos se cobran en tarifas decrecientes cuanto más los utilices. (Para más información sobre los descuentos por volumen, consulta el Capítulo 16.) Esto significa que se te facturan tarifas diferentes por los recursos a medida que los utilizas más, o durante periodos más largos a lo largo del mes. Examinando tu factura, puedes ver que algunos costes de recursos son mayores que otros, incluso para el mismo tipo de recurso o un recurso idéntico. Cuando las tarifas se presentan de este modo, se denominan no mezcladas en la jerga de AWS.
Tasas mixtas (específicas de AWS)
AWS ofrece una tarifa combinada en sus datos de facturación de . Esta tarifa combinada estandariza la tarifa que pagas por el mismo tipo de recurso distribuyendo uniformemente los cargos a cada recurso, excepto cuando el uso está cubierto por descuentos basados en compromisos. Aunque AWS ofrece esta tarifa combinada en sus datos de facturación detallados, la forma en que se combinan los costes a menudo no es perfectamente uniforme, o algunos costes de recursos no se combinan porque están cubiertos por compromisos, lo que puede llevar a confusión sobre el verdadero coste de un recurso. Todavía existe un caso de uso específico para las tarifas combinadas en la conciliación de facturas cuando se utilizan archivos de datos del Informe de Costes y Usos (CUR), pero más allá de esto las tarifas combinadas rara vez son útiles.
Costes amortizados
Algunos recursos en nube y descuentos por compromiso pueden adquirirse con un pago inicial. El coste amortizado de un recurso tiene en cuenta este pago inicial y lo divide, atribuyendo el coste prorrateado por cada hora (o segundo, o milisegundo) de facturación. Por ejemplo, un vehículo de compromiso inicial de un año (SPs, RIs o Reservas) se dividirá entre todos los periodos de tiempo en los que se aplicó ese compromiso a un recurso.
Costes con carga completa
Los costes totalmente cargados se amortizan, reflejan en las tarifas reales con descuento que paga una empresa por los recursos de la nube, tienen en cuenta equitativamente los costes compartidos y se asignan a la estructura organizativa de la empresa. En esencia, muestran los costes reales de tu nube y lo que los impulsa. Tu organización puede optar por definir los costes totalmente cargados de forma diferente en función de los descuentos y componentes de coste que desee incluir. O puedes definir otro término para representar esto en los informes de tu organización.

Definir los términos financieros para los profesionales de la nube

Algunos términos que proceden de la disciplina financiera y que son útiles para que los ingenieros los comprendan son:

Principio de concordancia
Los gastos deben registrarse en el periodo en el que se recibió el valor, no necesariamente durante el periodo en el que el proveedor de la nube les facturó o cuando se realizó el pago. El principio de correspondencia se aplica a la contabilidad de devengo y es la principal diferencia con la contabilidad de caja. En la facturación de IaaS, la factura (normalmente mensual) que recibes del proveedor de la nube puede incluir pagos por adelantado que aplicarán beneficios -descuentos- a los recursos durante el plazo más largo (12 ó 36 meses) del compromiso; la mayor parte del beneficio del pago por adelantado no se produce en este periodo contable. Esto significa que debes calcular los gastos utilizando los datos de facturación (por ejemplo, Informes de Coste y Uso en AWS, Archivo de Facturación de Azure en Azure) en lugar de utilizar las facturas del proveedor.
Coste del capital/WACC/ICC
El coste del capital se refiere al coste que supone para una empresa destinar su dinero a una inversión. A veces se denomina coste interno del capital (ICC). En la nube, el coste del capital es una consideración importante cuando se trata de pagar por adelantado descuentos adicionales en compromisos como las IR. Por ejemplo, si una empresa pide prestado dinero al 8%, entonces su coste de capital es del 8%. Ese 8% se convierte en el listón que la empresa necesita superar en su rendimiento de la inversión. Sin embargo, este ejemplo del 8% está muy simplificado. En realidad, la mayoría de las empresas tienen diversas fuentes a través de las cuales acceden al capital. Los distintos tipos de financiación mediante deuda y capital pueden aportar tipos muy diferentes. Al calcular el coste del capital en una situación así, las empresas deben utilizar una mezcla de esos tipos, denominada coste medio ponderado del capital (CCMP ). La mayoría de los equipos financieros sabrán cuál es su WACC y deberán tenerlo en cuenta al realizar las compras iniciales de RI.
Coste de las mercancías vendidas (COGS)

El COGS mide cuántos dólares de desembolso se necesitan para generar ingresos en un periodo concreto. Por ejemplo, si una empresa eléctrica está transportando carbón en camiones desde el almacén hasta la central eléctrica, registraría el coste del carbón quemado. Ese coste no tiene ningún beneficio futuro, por lo que será un gasto directamente relacionado con los ingresos de ese periodo, lo que lo convierte en un gasto COGS. La prueba del COGS es: ¿son gastos directamente relacionados con los ingresos en el mismo periodo?

Los costes de alojamiento gastados en I+D pueden recibir un tratamiento fiscal más favorable que los gastados en COGS, por lo que la capacidad de distinguir claramente entre ambos es una capacidad potencialmente valiosa del esfuerzo de FinOps.

Jason Rhoades, Intuit

Para una empresa de software, el COGS sería la factura mensual de la nube para hacer funcionar su software, las comisiones de los vendedores y los costes de soporte. En particular, la nube es lo más variable y lo que tiene más potencial de optimización. Dado que no suele ser una buena práctica empresarial bajar las comisiones de ventas o despedir al personal de asistencia, esto arroja luz sobre la optimización del gasto en la nube sin reducir los ingresos.

EBITDA
Los beneficios antes de intereses, impuestos, depreciación y amortización (EBITDA) son una métrica muy utilizada de la rentabilidad empresarial. Esta métrica también excluye los gastos asociados a la deuda, al sumar a los beneficios los gastos por intereses y los impuestos. No obstante, es una medida más precisa del rendimiento empresarial, ya que puede mostrar los beneficios antes de la influencia de las deducciones contables y financieras. El EBITDA puede utilizarse para comparar empresas entre sí y con las medias del sector. El EBITDA es una buena medida de las tendencias de los beneficios básicos porque elimina algunos factores ajenos y proporciona una comparación más precisa entre empresas.

La abstracción ayuda a comprender

Los seres humanos tendemos a tener problemas con números muy grandes y muy pequeños. Por ejemplo, si algo cuesta 1 $ por hora, calcular cuántas horas obtendrías por 10 $ es relativamente sencillo. Sin embargo, si un recurso cuesta 0,0034 $ por hora, calcular cuántas horas obtendrías por 10 $ requerirá una calculadora. El formato de los números también es importante. Sin formato, 100000000 es difícil de leer. La mayoría de la gente necesitaría contar los ceros y añadir comas para determinar la cantidad que significa.

Otro problema humano con los números grandes es que tendemos a perder el sentido de la escala. Esto puede ser un problema con los equipos que trabajan con grandes cantidades de dinero, como miles, millones, decenas de millones o más. Como señala Hans Rosling en su libro Factfulness (Flatiron Books), el instinto del tamaño entra en acción cuando los humanos tratamos con números muy grandes o muy pequeños, y tienes que identificar formas de lidiar con ello.

En una reunión de la Fundación FinOps, uno de los miembros mostró cómo el uso de la abstracción puede ayudar a las FinOps. Reforzó su argumento señalando que la diferencia entre mil millones y dos mil millones no parece mucho, pero en realidad es un cambio enorme.

Muchas organizaciones con un gran gasto en la nube luchan por dar a sus ingenieros métricas significativas sobre el gasto. Imagina que una organización va a gastar 100 millones de dólares al año en la nube. A esa escala, a todos los humanos les costará entender la escala de las cifras implicadas. Y cuando tienes problemas con la escala, se hace difícil responder a preguntas como éstas:

  • ¿Una optimización de 30.000 $ al mes es poco o mucho?

  • ¿Cuánto esfuerzo merece la pena realizar para conseguir el ahorro?

  • ¿Realmente importa a la empresa?

  • ¿Hay prioridades más importantes?

Mantener una cultura de responsabilidad, tan vital para el éxito de una práctica de FinOps, se hace cada vez más difícil cuando las cifras se hacen demasiado grandes para relacionarlas.

Para ayudar al contexto y a la comprensión, a veces es útil no utilizar el léxico común, porque el número concreto de dólares gastados o ahorrados puede no ser lo más importante. Si el impacto para la empresa del gasto o el ahorro puede articularse utilizando otras unidades de medida, el mensaje llega con mucha más claridad.

Por ejemplo, un miembro de la Fundación FinOps correlacionó la cantidad de ahorro de costes con la cerveza. Si el equipo emprendía un determinado conjunto de acciones, demostraba que podían ahorrar el equivalente a mil cervezas. En los años transcurridos desde la primera edición de este libro, ese mismo profesional de la métrica de la cerveza ha podido hacer evolucionar sus informes para incluir métricas empresariales tangibles, como solicitudes atendidas, ingresos entregados y clientes atendidos a su oferta.

Este alejamiento de la presentación de informes sólo en dólares es importante, porque cada equipo implicado en el gasto en la nube tiene un conjunto diferente de motivadores. Utilizar las motivaciones de los equipos para encontrar un ejemplo adecuado es una forma de situar el gasto en la nube en un contexto más significativo. Por ejemplo, un motivador prometedor de los equipos de ingeniería es la introducción de métricas de sostenibilidad como las emisiones de carbono. Consulta el Capítulo 19 para saber más sobre sostenibilidad y FinOps.

Para los líderes empresariales, ver los costes de la nube vinculados a una importante métrica de valor empresarial, como un porcentaje de los ingresos del producto soportado o el rendimiento de alguna actividad clave, ofrece una imagen más comprensible de la eficiencia general de tu gasto en la nube. A continuación, una organización puede establecer límites objetivo para el porcentaje de gasto y utilizarlo para impulsar proyectos de optimización mediante una serie de técnicas para reducir el crecimiento del gasto en la nube en relación con el crecimiento de los ingresos. En la Parte III se tratan los métodos de optimización.

Pero esa estrategia empresarial global no está directamente relacionada con las motivaciones de los equipos. Los equipos de ingeniería, por ejemplo, convierten sus esfuerzos en funcionalidad para los usuarios, por lo que sus motivaciones giran en torno al crecimiento de su equipo de ingeniería y la entrega de más funcionalidad. Un miembro de la Fundación FinOps descubrió que informando del gasto en la nube en términos del coste mensual del equipo de ingeniería, había dado con una forma significativa de implicar a los ingenieros. Al evaluar una acción de ahorro de costes, podían decir que una acción de optimización podría dar lugar a una cantidad específica de personal adicional, o podían decir con qué rapidez una acción de ahorro de costes podría pagar el salario de un equipo.

Conocer las motivaciones de los equipos te ayuda a encontrar una forma eficaz de implicarlos. Para los gestores de servicios, informar en unidades alternativas como el coste por usuario activo diario (DAU) es una buena táctica. Dividiendo el gasto en la nube por el número de DAU de sus servicios, pueden mostrar la cantidad de valor empresarial que esos servicios están generando por dólar gastado.

A medida que una práctica de FinOps madura y empiezas a adoptar métricas unitarias, puedes asociar un coste real a una función empresarial y empezar a dirigir las conversaciones sobre costes hacia conversaciones sobre valor. Para una empresa de transportes, tu métrica unitaria podría ser paquetes entregados, o podrías empezar con una métrica más sencilla como el coste por solicitud o llamada a la API. Cuando puedes equiparar un coste en la nube a cada entrega empresarial, puedes informar sobre optimizaciones de costes en términos de cuántos envíos más puedes hacer a partir del ahorro que generas. Toda esta contextualización ayuda a crear un entendimiento común entre los equipos.

El lenguaje de la nube frente al lenguaje empresarial

A medida que creas informes que se alejan de las personas que operan los recursos de la nube, o del equipo de FinOps que está operando los programas de ahorro de costes, tiene sentido abstraerse de los términos específicos de la nube. Cuando cambias esos términos por otros más genéricos de negocio, puedes resumir los informes sin dejar de ser preciso.

Como ejemplo, veamos las reservas en la nube para recursos informáticos. Se tratarán con más detalle en el Capítulo 17, pero en general la idea es que si te comprometes con un proveedor de servicios en la nube y utilizas esos compromisos eficazmente, puedes ahorrar dinero. Si no lo haces, pierdes dinero. AWS los llama Planes de Ahorro o Instancias Reservadas, con varias opciones que ahorran diferentes cantidades.

Si tu equipo de FinOps crea un informe para sí mismo, necesita los detalles sobre los compromisos individuales adquiridos. Pero cuando empiezas a informar a finanzas y luego a la empresa en general, el mensaje importante cambia. En lo que te centras aquí es en el éxito global: ¿has ahorrado dinero o lo has perdido? Cuando pasas de informar con términos específicos de la nube, como utilización de compromisos, a términos empresariales más genéricos, como ahorro realizado, creas claridad.

Reducir el número de personas que necesitan profundos conocimientos sobre la nube, especialmente a medida que te alejas de la tecnología y te acercas a la elaboración de informes y el monitoreo más generales del negocio, reduce la barrera del conocimiento. Y centrar tus informes en el resultado empresarial real del que se informa sigue fomentando más confianza, credibilidad y comprensión.

Crear un traductor universal entre tus equipos de DevOps y Finanzas

Anteriormente nos habíamos referido a este utilizando el concepto de pez Babel de la obra maestra de Douglas Adams La Guía del Autoestopista Galáctico (Harmony Books). Sin embargo, era una referencia que no todo el mundo entendía. En su lugar, vamos a utilizar una referencia de Star Trek a una idea similar llamada Traductor Universal. En Star Trek, el Traductor Universal se utiliza para interpretar lenguas alienígenas a la lengua materna del usuario. Es exactamente el tipo de cosa que todo equipo de FinOps desearía poder dar a los equipos financieros, técnicos y de producto para que todos pudieran entenderse perfectamente.

Por ejemplo, hemos asistido a reuniones en las que el equipo técnico hablaba de los valores concretos que utilizan para etiquetar los recursos de la nube, mientras que el equipo financiero hablaba más ampliamente de la necesidad de asignar costes. Ambos equipos estaban describiendo lo mismo, pero había matices en los informes que estaban revisando, como los detalles de cómo se utilizaba un valor de etiqueta para asignar costes, que impedían que estos dos equipos se entendieran.

Podrían haber utilizado un traductor para evitar la confusión.

Pero si tanto el equipo financiero como el técnico tienen claro cómo funcionan las prácticas FinOps, como la asignación de costes, dentro de la organización, la conversación partirá siempre de un nivel común de entendimiento, sin necesidad de un traductor universal.

Los equipos de finanzas e ingeniería son muy inteligentes. Sin embargo, deben recordar que tienen prácticas y terminología diferentes. Las FinOps deben ayudar a los equipos financieros a entender el lenguaje de la nube, abstrayendo la terminología específica de la nube para quienes entienden de dólares y céntimos, y deben simplificar los requisitos financieros para los equipos de ingeniería.

Los profesionales de FinOps crean informes y procesos que reducen la necesidad de que los equipos financieros y de ingeniería dediquen grandes cantidades de tiempo a aprender y trabajar fuera de sus áreas de especialización. Construir esos informes con un lenguaje coherente permite a los equipos familiarizarse con un conjunto común de términos y luego utilizar esos informes comunes para mantener conversaciones sobre las ventajas y los costes de la nube.

Necesitas FinOps para que los equipos puedan comunicarse eficazmente. Lo ideal es que no se necesite a nadie del equipo de FinOps en la sala. La presencia de esa persona se hace menos necesaria cuando todos comparten un vocabulario. Sin embargo, el equipo de FinOps siempre está ahí para ayudar a crear estos informes, de modo que la confianza, la comprensión y la claridad sigan creciendo.

La necesidad de educar a todas las disciplinas

A continuación, los equipos de FinOps pueden ayudar a recopilar y definir los términos empleados por una organización que se utilizarán para describir el gasto y el ahorro en la nube. Los términos específicos de cada disciplina, los términos del sector y las variaciones utilizadas por los distintos proveedores de servicios en la nube deben adoptarse y/o adaptarse a un léxico común.

No debe esperarse que nadie de finanzas, tecnología, producto, aprovisionamiento o gestión intente aprender todos los idiomas comunes de todos los demás equipos. Lo ideal es que todos se reúnan en un punto intermedio, donde las finanzas aprendan los términos necesarios para describir los recursos de la nube, la ingeniería aprenda los términos utilizados para describir los costes, y los equipos de producto aprendan a comunicarse con ambos. Cuando los equipos aprenden más del lenguaje utilizado por otros equipos, las conversaciones conducen más rápidamente a resultados satisfactorios.

Evaluación comparativa y gamificación

Cuando se utilizan informes comunes construidos en torno al mismo lenguaje para medir el gasto y la optimización de cada equipo, se hace posible comparar los equipos, e incluso crear cierta rivalidad amistosa. El Capítulo 22 profundiza en las métricas utilizadas para comparar grupos, pero de momento piensa en cómo la posibilidad de comparar equipos puede conducir a la gamificación.

Por ejemplo, se pueden conceder insignias virtuales de logros por la gestión satisfactoria del gasto en la nube del equipo. Celebrar a los equipos que realizan el mayor número de optimizaciones, y destacar el efecto positivo específico sobre el gasto y la optimización generales de la nube, es una forma estupenda de implicar y animar a los equipos.

Alternativamente, disponer de informes que destaquen a los peores infractores -aquellos que han mostrado falta de acciones de optimización, han ignorado el gasto en la nube de su equipo o han sido lentos en responder a anomalías inesperadas en el gasto- puede ser eficaz e incluso divertido, si se hace bien. Según nuestra experiencia, a los equipos no les gusta figurar en la lista de los peores infractores y a menudo se esforzarán más para cambiar su posición en la lista. Analizaremos más a fondo lo que llamamos "listas de vergonzosos/peores infractores" en el Capítulo 11, cuando lleguemos a las prácticas que te ayudarán a alcanzar tus objetivos de FinOps.

Conclusión

En última instancia, utilizáis vuestro léxico común para construir una comprensión compartida de vuestros costes en la nube y de las oportunidades de optimización.

Resumiendo:

  • Ten en cuenta que los distintos equipos utilizan términos específicos de cada disciplina.

  • Ayuda al personal a aprender un vocabulario común y a ser coherente con los términos utilizados en los informes, lo que ayudará a eliminar la confusión.

  • Un equipo de FinOps no tiene que ser un traductor constante en las reuniones, sino que debe ayudar a aprender y permitir que los equipos se comuniquen cada vez más por sí mismos.

  • Considera la posibilidad de añadir informes que utilicen unidades de medida abstractas para comunicar de forma más significativa para tus equipos.

  • Dividir los costes y el ahorro entre alguna unidad de valor empresarial te permite calibrar la eficiencia de tu gasto en la nube.

Antes de que puedas optimizar tu gasto en la nube, tienes que entender tus costes en la nube. En el próximo capítulo veremos la anatomía de una factura en la nube.

Get Cloud FinOps, 2ª Edición now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial