Anatomía de un billete de nube
Este capítulo examina los fundamentos de la facturación de los servicios de nube pública y cómo estos cargos se reflejan en los datos de facturación. Comprender las facturas de la nube es clave para la posterior asignación de costos y la optimización de los aspectos de la nube del ciclo de vida de Fin Ops. La estructura organizativa asociada con el gasto en la nube determina quién realiza operaciones de optimización específicas y a quién se delega el trabajo relacionado con FinOps.
No nos ceñimos a un solo elemento de facturación, sino que comparamos los matices de la facturación de las empresas entre los recursos de la nube. Solo con esta mentalidad en mente, los profesionales de FinOps pueden escribir informes efectivos que ayuden a todos los equipos a comprender su factura de la nube.
La complejidad de la facturación en la nube
Los datos de facturación en la nube son complejos. Solo AWS tiene más de 200 000 unidades de almacenamiento de productos (SKU), algunas de las cuales incluso se facturan por segundo. Estos datos se actualizan varias veces al día y existe una relación compleja con el tiempo de ejecución de la instancia, el tamaño del almacenamiento y el costo de la transmisión de datos. Algunos de los clientes de nube más grandes que hemos visto están gastando miles de millones de dólares por mes.
Hay algunas plataformas en el mercado que pueden manejar la facturación compleja en la nube en lugar de las empresas, y se necesita al menos un profesional de Fin Ops que tenga un conocimiento profundo de los datos en el equipo. Esto no solo ayuda a otros equipos de la empresa a comprender y analizar la información contable, sino que también facilita que los equipos interpreten los datos y las recomendaciones relacionadas de la plataforma FinOps.
Los datos de la factura que ve Finanzas pueden diferir de la información de facturación detallada que se analiza, como los informes de costos y uso de AWS. Los profesionales en una plataforma Fin Ops bien diseñada pueden conciliar los dos datos en las conciliaciones de facturas mensuales, pero el nivel de granularidad de las cuotas, las tarifas combinadas o los descuentos por uso comprometido aplicados a las facturas aún pueden ser consistentes con el servicio o la cuenta / La facturación detallada los datos son diferentes para el nivel de suscripción. Por lo tanto, los equipos deben establecer expectativas desde el principio de que solo se utilizan las facturas para registrar los datos de las cuentas por pagar, en lugar de analizar el gasto en la nube.
Usando los detalles mensuales que se muestran en la factura y el nivel del servicio en la nube, pudimos identificar los factores de costo detrás del servicio.
AWS, GCP y Azure vienen con sólidas herramientas de costos de nivel de entrada para un análisis de alto nivel del gasto en la nube, que es un primer paso fundamental para obtener visibilidad. Sin embargo, estas herramientas a menudo no funcionan una vez que una empresa implementa la computación en múltiples nubes, personaliza las tarifas negociadas, expone los datos de gastos y establece la responsabilidad del equipo o entra en la asignación de costos del contenedor.
Formato básico de los datos de facturación
Comenzaremos con el formato básico de la mayoría de los datos de facturación de los tres principales proveedores de servicios en la nube. En estos archivos, cada línea enumera el uso de un tipo particular de recurso. Los programas de facturación en la nube a menudo tienen la propiedad de conservar instantáneas de uso durante un período de tiempo específico. Los siguientes factores se agregarán a la fila Uso:
● período de tiempo.
● Uso de recursos.
● Detalles de tarifas (a efectos de facturación) para este período de tiempo.
●Información de ubicación dividida por región.
● Identificación del recurso.
• Atributos de metadatos para asignar gastos a cuentas de productos o artículos, etc.
En el Capítulo 9, explicaremos qué son las etiquetas y cómo se pueden usar para impulsar la rendición de cuentas. Antes de hacerlo, debemos analizar instancias de datos de facturación de cada uno de los principales proveedores de la nube para comprender los elementos sin procesar que sustentan los programas FinOps.
La Figura 5-1 muestra una fila de los cientos de millones de datos de facturación que se reciben todos los días. Los datos pueden parecer incoherentes en la superficie, pero puede descubrir algunas propiedades importantes, como:
● Tiempo para utilizar los recursos.
● Tarifas y comisiones aplicadas a la factura.
● Recursos que se están cargando.
●Si existe una solicitud de pedido y, de ser así, cuál.
● Información de anotación (metadatos) para la asignación de costos.
●Zonas de carga y servicios.
Estos proyectos de ley granulares empoderan a los equipos de FinOps cuando comienzan una práctica de FinOps. Pero esta información detallada también aumenta la complejidad de los datos, lo que da como resultado datos de facturación finales de una escala tan grande que ya no se pueden registrar en hojas de cálculo. Hay que recurrir a sistemas de gestión informatizados.
Figura 5-1 Fila de muestra de datos de facturación de AWS CUR
Comprender esta complejidad le permite probar algunas cosas realmente geniales en el camino de FinOps, como la introducción de mecanismos automáticos de detección de anomalías cuando ocurren algunos cambios "pequeños". La razón para decir cambios "pequeños" es que los comentarios sobre la eficiencia de la nube tienden a reducirse varias veces. Imagine una empresa que gasta $1,000,000 al mes en computación en la nube y un equipo en
Ejecutar 50 instancias de cómputo en un clúster que no se está utilizando es desperdiciar $5000 por día. Dada la diferencia de tamaño, ni siquiera notará ningún cambio al revisar el resumen del nivel de servicio o el resumen mensual; sin embargo, estas dos sumas "pequeñas" suman más de $150 000 por mes. Eso es el 15 % del costo mensual total. . Debe utilizar el aprendizaje informático para analizar pequeños cambios en los datos para evitar una gran pérdida de costos. Afortunadamente, los proveedores de la nube brindan datos de facturación detallados que pueden ayudarlo a obtener información sobre los cambios en el uso y abordar este problema antes de que los pequeños desperdicios se conviertan en costos irreversibles.
¡Déjame en paz, tiempo!
En la década de 1990, Hootie and the Blowfish lanzaron una canción llamada "Time", en la que cantaban cómo el tiempo "te lleva a ver el mañana y todo su dolor y tristeza" "Mañana es solo otro hoy... No creo en tiempo".
En vista de esto, se puede adivinar que Hooty and the Blowfish Band probablemente no estén interesados en Fin Ops. Después de todo, la esencia de la facturación en la nube es cuestión de tiempo. Cada cargo tiene un límite de tiempo, incluso los programas de tarifa plana se facturan mensual o anualmente. La situación más común es que debe pagar tarifas informáticas por segundo, tarifas mensuales de almacenamiento y tarifas por el tiempo que lleva completar una consulta.
Por supuesto, hay excepciones a esta regla. La transferencia de datos y sin servidor no se basan en el tiempo, sino en el uso. Ambos siguen perteneciendo al mismo modelo de facturación uso x tarifa. Por ejemplo, una tasa de transferencia de datos de 720 GB podría costar 0,02 USD/GB y 235 000 llamadas de función serían 0,001 USD/hora. Sin embargo, los ejemplos también se basan en el caso de uso. ¿lo has usado? Pague cuando lo use, y no tenga que pagar si no lo usa. Esto también refleja la diferencia entre el modelo de gasto variable de la computación en la nube y el modelo de gasto fijo de las implementaciones privadas.
¿Cómo cobran los proveedores de servicios en la nube por instancias/máquinas virtuales/informática? Generalmente basado en el tiempo de ejecución del recurso. Si bien la mayoría de los proveedores facturan por segundo, aquí usamos la hora como ejemplo para simplificar el concepto. Cada mes tiene 30 días, o 720 horas, o 31 días, o 744 horas (hablaremos de febrero más adelante).
Por lo tanto, si el costo de cómputo de un recurso se calcula por hora en enero, verá una fila de datos que muestra que el tiempo de uso de cómputo de este recurso es de 744 horas. Por supuesto, también incluye la tarifa de 744 horas. De las 744 horas, la tarifa de facturación puede ser la misma para cada hora, o 200 de las horas se facturan mediante instancias reservadas y las 544 horas restantes no se utilizan. En este último caso, aparecerán dos filas de datos, una con 544 horas bajo demanda y la otra con 200 horas para la instancia reservada.
Si no hay acumulación de pequeñas corrientes, no habrá ríos ni mares
Sume cada pequeño gasto para crear un costo total por servicio o por mes. Pero cada pequeño gasto tiene sus matices y atributos, y si lo mira más de cerca, puede encontrar una gran cantidad de datos de uso útiles. Recuerde cobrar de acuerdo con el tiempo de ejecución real del uso del recurso, no para ver si el recurso se usa, sino para observar cuándo comienza a ejecutarse.
A menudo le explicamos a la empresa de esta manera: "No se apegue a los recursos. Lo que compra no es el recurso real, sino el derecho de uso parcial del recurso por un cierto período de tiempo". entender, pero se vuelve claro en la práctica. En la década de 1990, el Observatorio Keck en Hawái nombró a cada servidor con el nombre de una playa local: Hapuna, Kiholo, Kaunaua, Maumee. Pero ahora los recursos informáticos no se gestionan de forma independiente.
Como explicaremos más adelante, incluso las instancias reservadas no están vinculadas al servidor al que están conectadas, simplemente están conectadas a un servidor de objetos que coincide con sus atributos específicos. Cuando aplica el mismo pensamiento a la facturación en la nube, se da cuenta de que está comprando tiempo, no objetos físicos. Si bien esto puede parecer obvio para algunos, este concepto es clave para comprender y administrar la facturación en la nube para los equipos financieros.
Un breve historial de datos de la facturación en la nube
Francamente, no sabemos nada sobre los datos de gasto en la nube. Es posible que nos vea publicando en AWS re:Invent o Google Next, revisando las diversas iteraciones del archivo de facturación de AWS durante la última década y las características que cada iteración ha desbloqueado. A riesgo de repetir los mismos errores, estas iteraciones reflejan perfectamente el proceso clásico mediante el cual una empresa comienza una práctica de Fin Ops. Cada paso de la iteración refleja la madurez de los usuarios de la nube más avanzados de esta era. Si otras empresas no han seguido el ritmo de los desarrollos de Fin Ops durante ese tiempo, es probable que ahora estén en un camino similar. Por lo tanto, debemos mantener la actitud de aplicar la estrategia de gatear, caminar y correr para comprender rápida y profundamente la situación de actualización de los archivos de facturas de AWS en los últimos diez años.
2008: Factura
Aqui es donde todo empezó. A través de las facturas, vemos las facturas mensuales y las facturas de servicios, sin metadatos autogestionados, como etiquetas, y sin granularidad para ayudar a comprender los factores de cambio o los impulsores. Basado en esto,
Los equipos de finanzas a menudo preguntan: "¿Hay algún problema con los datos de esta factura?" Para responder a esa pregunta, deben observar la siguiente iteración de los datos de facturación.
2012: Informe de asignación de costos (CAR)
Ya en 2012, los usuarios de AWS intentaban responder a la pregunta: "Sé que voy a gastar $100 000 este mes, pero ¿qué equipos los gastarán y en qué productos?" Aquí, el diseño del documento del informe de asignación de costos se separa filas de datos entre cada valor de token y su cuenta vinculada. En ese momento, fue un gran paso adelante y finalmente pudimos hacer la asignación de gastos. Pero la desventaja del informe de asignación de costos es que, dado que los gastos se informan mensualmente, es imposible saber cuándo se produce el gasto y cuándo alcanza su punto máximo. También hay líneas totales para gastos no marcados en el archivo del informe de asignación de costos, pero no se puede consultar la fuente de estos gastos.
2013: Informe de facturación detallado (DBR)
Los informes de facturación detallados presentan series de tiempo para cada gasto de servicio. No solo puede buscar cuánto gastó un servicio en un mes en particular, sino que también puede ver cuándo se pagó el servicio en ese mes, y puede ver cómo su elasticidad y cambios dentro del mes retroalimentan el gasto. Pero, alerta de spoiler, al informe de facturación detallado le falta un dato clave que revolucionaría la gestión de costos en el pasado.
2014: Informe de facturación detallado (DBR-RT) con elementos de recursos y llamadas
El informe de facturación detallado con elementos de recursos y llamadas cambia el modo de operación al tener filas separadas para los recursos utilizados para cada período de tiempo y columnas separadas para cada clave de llamada. El crecimiento de datos desde entonces ha sido asombroso: los informes de facturación detallados para grandes clientes rara vez superan los megabytes, mientras que sus informes de facturación detallados con elementos de recursos y llamadas abarcan cientos de gigabytes de datos CSV (delimitados por comas). Algunos grandes clientes pueden tener miles de millones de comas en un solo archivo. A través de estos archivos, sabemos en qué período de tiempo específico, qué ID y etiqueta de recursos específicos causaron el gasto de costos y si se aplicaron instancias reservadas durante ese período de tiempo, y no hay ningún lugar para ocultar cambios sutiles. Los primeros practicantes de FinOps proporcionaron mejores recomendaciones de optimización basadas en esto.
2017: Informe de Costo y Uso (CUR)
Con el nombre en código de "Origami" en la evolución del archivo de facturación, el archivo de informes de uso y costo altera el modelo de facturación del pasado. Este es un nuevo intento de AWS, en lugar de delimitadores de coma, se reemplaza en formato JSON, que es fácil de leer para los programas. Durante la evolución, ciertos datos, como las tarifas, se dividieron en archivos JSON separados. Anteriormente, en busca de un formato simplificado para los informes de facturación detallados, todos creaban sus propios lectores de datos de facturación y un solo archivo JSON dificultaba la lectura de los datos. Sin embargo, el informe de costo y uso tiene una ventaja sutil: muestra en el archivo si se aplicó una Instancia reservada y qué instancia específica (o parte de la instancia) se aplicó durante ese período de tiempo. Aquí, obtendrá una comprensión más clara de las Instancias reservadas y cómo informan las compras de recursos adicionales y las modificaciones en la toma de decisiones.
Después de comprender esta breve historia, puede encontrar que sigue el concepto de gatear, caminar y correr, que se puede resumir de la siguiente manera:
1. Antes de pagar al proveedor de servicios en la nube, puede ver el gasto total de su servicio. (factura)
2. Qué equipos o qué productos le gustaría ver responsables del servicio para impulsar la presentación de costos o el costo compartido. (Informe de asignación de costos)
3. Comienza a preocuparse por el tiempo específico de uso de los recursos. (Informe de facturación detallado)
4. La lista detallada existente no puede satisfacer sus necesidades y comienza a darse cuenta de que necesita ubicar con precisión las tendencias de recursos específicos y las solicitudes de tarifas, y determinar dónde hay una brecha en la asignación. (Informe de facturación detallado con elementos de recursos y llamadas)
5. Eventualmente (al menos por ahora, porque Fin Ops está en constante evolución), comienza a tratar de programar más y más de su trabajo de FinOps y trata de responder preguntas sobre el ROI y el valor de los compromisos de uso como Instancias reservadas. (Informe de uso y costo)
Esta evolución también se ha producido en la empresa Apptio Cloudability. En 2011, su plataforma era solo un grupo de inicios de sesión en AWS (con credenciales de raíz, porque IAM, también conocido como "Modelo de gestión de identidad y acceso", aún no existía), buscaba información de facturación, analizaba elementos de gasto en la nube y enviaba los números. diariamente al script de correo. Hasta el día de hoy, la función de correo electrónico diario "sigue siendo el núcleo de la plataforma, impulsando el circuito de retroalimentación del equipo. Pero para que coincida con los datos de facturación cada vez más complejos, todas las plataformas de FinOps han desarrollado funciones relacionadas".
El historial presentado anteriormente se basa en los datos de facturación de AWS porque, en el momento de escribir este artículo, AWS es el más maduro. Pero tenga la seguridad de que otros proveedores están pasando (o han pasado) por ciclos de facturación similares.
La importancia de los datos horarios
Es posible que se pregunte por qué debe preocuparse por los datos de nivel por hora (o incluso por segundo) y la granularidad del nivel de recursos. ¿No es suficiente la granularidad diaria o semanal en el nivel de la etiqueta? No es suficiente. Y una vez que su práctica de Fin Ops supere la etapa de la infancia (ascenso), esta insuficiencia será aún más pronunciada.
Los datos por hora son necesarios para realizar tareas de operaciones financieras de nivel superior, como la planificación de instancias reservadas. El acto de comprar una Instancia reservada depende de la cantidad de un tipo particular de recurso que esté ejecutando en un momento dado, lo que está estrechamente relacionado con el punto de equilibrio del recurso reservado. Si está calculando los recursos en meses, se está perdiendo este importante detalle. Para determinar exactamente cuántos recursos se necesitan, es necesario observar la cantidad de recursos que se ejecutan por hora (o incluso por segundo) y la marca de agua de uso.
Dado que nuestra introducción aún se encuentra en la etapa primaria (ascendente), no repetiremos el contenido anterior aquí. Pero tenga en cuenta que la visibilidad detallada que brindan AWS, GCP y Azure es fundamental para acceder a los recursos variables que viven en los servidores y se facturan por segundos o minutos.
un mes ya no es un mes
Imagine una empresa que comenzó el año con un nuevo plan de optimización de costos, efectivo el 1 de enero, que enumera una serie de medidas de reducción de costos: "Eliminamos las 'instancias zombis', ajustamos algunas especificaciones inadecuadas, compramos instancias reservadas". El mes siguiente, la factura de la nube mostró una caída del 10% en los costos. ¡Gran victoria!
Pero cuando lo piensas, la cantidad de días en febrero es solo el 90% de la de enero. Esto parece obvio, pero comparando los datos de febrero con otros meses, la reducción de costos ha hecho pensar al equipo que "la estrategia de reducción de costos es eficaz" ilusión. Luego, inevitablemente, el 31 de marzo, todos entraron en pánico porque los costos subían a una tasa del 10% mensual.
Vale la pena enfatizar nuevamente que la facturación en la nube está fuertemente ligada al tiempo. A diferencia del modelo de facturación mensual del centro de datos al que está acostumbrado el equipo de finanzas, la granularidad de la facturación en la nube es mucho más fina. Por ejemplo, si desea comparar dos recursos del mismo tipo, ambos deben compararse en el mismo período de tiempo, ya sea 10 días o 10 horas.
Rechazar el plan de cuotas en cascada, donde el gasto de un año simplemente se divide entre 12 meses, puede ser un gran paso adelante para usted. Pero los viejos hábitos son difíciles de morir. Hemos encontrado una desviación del 10% en los datos de cálculo precisos asignados a la hora del departamento de finanzas y finalmente descubrimos que se debe a que el departamento de finanzas simplemente divide el monto de la cuota por 12, y el método de cálculo correcto es usar por segundo ( o por segundo) horas) multiplicado por el número de horas utilizadas. Este ejemplo también muestra que el desarrollo de FinOps requiere un nuevo concepto.
un dólar ya no es un dólar
Mientras analizamos las comparaciones de recursos similares, es importante recordar que la tarifa para un tipo de recurso en particular en una fila en particular puede ser diferente que el mismo tipo de recurso para un período de tiempo diferente. En las instalaciones, puede establecer la misma tarifa para los recursos durante un período de tiempo seleccionado; las tarifas de la nube pueden variar ampliamente según las reservas de recursos o los descuentos por volumen aplicados por el proveedor de la nube.
Además, las cuotas iniciales anticipadas de Instancias reservadas o los descuentos por uso comprometido pueden cambiar aún más los resultados anteriores, dependiendo de si los tiene en cuenta en la visibilidad del usuario. Nuestra recomendación es incluir, ya que la cantidad que se muestra representa lo que puede recuperar más adelante. Pero estos supuestos presuponen que la empresa ya se encuentra en la fase de distribución.
Si elige no incluir los pagos por adelantado a plazos, especialmente porque AWS y Azure brindan ejemplos de pagos por adelantado, el equipo puede subestimar el gasto real. Si no se tuvieran en cuenta, la fila de los datos de facturación utilizados por la sección de la aplicación mostraría 0,00 y el equipo pensó que sus medidas de reducción de costos eran efectivas, pero esta tasa era demasiado "eficiente".
Tenga en cuenta que incluso si el equipo no cambia la infraestructura, las tarifas y los gastos siguen siendo variables.
Fórmula de cálculo de gastos
La fórmula para calcular las facturas de la nube es muy sencilla:
Gasto = Uso × Tasa
El uso puede ser la cantidad de horas (en segundos para las nubes de AWS y GCP) que se utiliza el recurso. Una tarifa es la cantidad que paga por hora (o por segundo) para usar ese recurso o un tipo específico de almacenamiento. Con solo mirar la fórmula es muy simple, un aumento en la tasa o tasa de uso dará lugar a un aumento en el gasto, si ambos aumentan, el gasto aumentará significativamente.
Esta sencilla fórmula es la clave para decidir cómo optimizar y en quién delegar la optimización. A continuación, en orden, primero discutiremos cómo optimizar y luego estudiaremos quién debe optimizar.
Dos palancas que afectan a la factura
Con base en la fórmula anterior, FinOps propone dos palancas fundamentales que afectan el gasto en la nube.
La primera palanca es reducir el uso de recursos. Esto se conoce como evitación de costos y, específicamente, puede terminar los recursos inactivos, ajustar los recursos sobredimensionados, reducir la cantidad de recursos que se ejecutan durante las horas de menor actividad o detener por completo el uso de recursos por la noche (o los fines de semana).
La segunda palanca es pagar menos por los recursos utilizados. Esto se conoce como reducción de tarifas y se puede lograr aprovechando la estructura de facturación de la nube.
(por ejemplo, Instancias reservadas (AWS o Azure) y descuentos por compromiso de uso) para implementar (GCP). Otros enfoques incluyen descuentos por volumen basados en el uso (como el descuento por uso sostenible de GCP) y algunos proveedores de la nube también ofrecen planes de precios personalizados para usuarios a gran escala. Algunas empresas también utilizan instancias puntuales o instancias prioritarias.Estas dos instancias pueden ayudar eficazmente al equipo de ingeniería a recuperarse rápidamente de los posibles impactos en el sistema empresarial cuando se produce una pérdida repentina de recursos en el sistema de producción. Independientemente de cuál de los métodos anteriores se utilice, se puede reducir el costo del uso de recursos.
Quién debe evitar costos y quién debe bajar las tarifas
Al subdividir las tareas de optimización, a menudo se debate quién es responsable de qué proceso. Después de ocho años de hablar con cientos de empresas y la pequeña cantidad de empresas que ingresaron en operaciones avanzadas que no lograron ejecutar bien el proceso Fin Ops, tenemos una opinión firme al respecto:
Las más exitosas de estas empresas han llevado a cabo una optimización de uso descentralizada (es decir, evitar costos) y una optimización de tarifa centralizada (es decir, reducir tarifas).
Los responsables de la toma de decisiones descentralizados que controlan la mayor parte del gasto en la nube suelen ser los propietarios de las aplicaciones. Saben mejor cuándo desactivar el uso de recursos, ajustar las especificaciones de recursos o cambiar los requisitos. Debido a que están muy familiarizados con los requisitos de la carga de trabajo, pueden usar el informe de optimización de especificaciones para decidir si mantener o cerrar las instancias aparentemente inactivas. Las decisiones de infraestructura centralizadas no pueden ser eficientes y deben estar facultadas para permitir que los ingenieros o propietarios de aplicaciones tomen las decisiones correctas desde una perspectiva empresarial.
El problema es que estos propietarios de aplicaciones a menudo se olvidan de comprar Instancias reservadas o descuentos por compromiso de uso. Además, confunde cómo funcionan. En este momento, el equipo central de FinOps puede analizar la situación general y buscar oportunidades para reducir costos en toda la industria de la nube. No solo eso, sino que también poseen habilidades de adquisición y análisis financiero y comprenden los matices del análisis de flujo de caja.
Métricas para medir la eficacia del trabajo del equipo de Fin Ops: si la cobertura de instancias reservadas/uso comprometido está aumentando, si las tasas de vacantes están disminuyendo, si se están utilizando descuentos por volumen o precios negociados.
Reducción de tarifas centralizada
Los productos de Markdown, como las instancias reservadas y los descuentos por compromiso de uso, son complejos y los proveedores de servicios en la nube actualizan constantemente sus ofertas (es posible que aparezcan nuevos productos en el momento de la publicación de este libro). Por lo tanto, es ineficiente que cada equipo dedique tiempo a aprender cómo aplicar, rastrear, optimizar y operar estos programas de descuento existentes.
Los recursos en la nube que su organización quiere ejecutar a precios reducidos a menudo provienen de diferentes equipos. Los productos y proyectos operados por grandes empresas requieren cientos o incluso miles de recursos en la nube, y la gestión y el control centralizados de todas las instancias reservadas significa un aumento de la cobertura compartida.
Se puede aplicar un único descuento de Instancia reservada o Uso comprometido a varios recursos.Tomando como ejemplo a AWS, moverse entre varios clientes y permitir que un solo equipo administre proyectos de reducción de tarifas a menudo da como resultado una cobertura general baja y una cobertura individual excesiva. desperdiciar. En este momento, si hay un equipo central con una comprensión integral del contenido relevante, se pueden lograr importantes ahorros de costos. Como veremos en el Capítulo 14 sobre las estrategias de RI, hay muchas consideraciones más allá del tipo de recursos con los que se compromete un RI. También discutiremos cómo la empresa distribuirá los fondos para comprar estos productos y cómo involucrar al equipo de finanzas.
Por ejemplo, un equipo tiene un alto uso de recursos durante el día, mientras que otro equipo tiene un alto uso de recursos durante la noche. Dependiendo de su uso respectivo, sería una pérdida de dinero para ambos equipos comprar instancias reservadas de forma independiente. Pero al observar el uso a lo largo del día, las empresas deben tener recursos disponibles las 24 horas. En este punto, es el turno del equipo central de desempeñar un papel mediante la compra de instancias reservadas para reducir las tasas de pago de recursos para ambos equipos.
Durante la fase de ejecución, mantener el crecimiento de los pedidos anticipados y el despilfarro de datos requiere una gestión coherente y continua. Además, hay tantos factores involucrados en una compra inicial que puede ser difícil tomar la decisión correcta (un pedido anticipado incorrecto puede costar millones de dólares, como se ha demostrado). Los equipos de FinOps reducen el potencial de desperdicio de recursos mientras optimizan la cobertura de recursos.
Advertencia: la centralización no tiene sentido para algunos equipos por algún motivo (p. ej., tienen necesidades de recursos muy específicas). Esta situación se discutirá en detalle en el Capítulo 14.
¿Por qué no centralizar y optimizar el uso?
Con el avance estratégico de la reducción de la tasa de centralización, evitar costos (reducir el uso) se ha convertido en un plan de actividad en el que todos los equipos de la empresa deben participar activamente. A nivel de toda la empresa, los costos de la nube por día pueden provenir de cientos o miles de operaciones en diferentes equipos y diferentes ingenieros. Estos servicios respaldan el funcionamiento de la empresa. Son los motores centrales de la máquina de innovación.
Para impulsar la máquina de innovación para que funcione más rápido, las empresas deben generar recomendaciones de optimización de uso de manera uniforme. Primero, la empresa recopila el uso de recursos a través de sistemas de monitoreo y, con la ayuda de una plataforma FinOps, genera alternativas para que los recursos coincidan con la carga de trabajo en la que se ejecuta. Luego, de acuerdo con los pasos habituales, este plan se envía a cada equipo sobre la base de una advertencia de umbral (para empresas en etapa intermedia), o ingresa al ciclo de iteración de desarrollo de software a través de JIRA (para empresas en etapa avanzada). Los criterios específicos para estos esquemas se describen en detalle en el Capítulo 11.
Este modelo garantiza a los propietarios de los recursos la oportunidad de revisar las propuestas antes de cambiarlas en tiempo real. Porque el propietario del recurso sabe mejor que otros cómo se usa el recurso, quién depende de él, si cambiar el recurso afectará el servicio en ejecución y las posibles razones detrás de esto.
Los profesionales de FinOps brindan a los equipos de ingeniería visibilidad de los recursos y acceso a los datos, lo que les permite tomar las mejores decisiones técnicas casi en tiempo real. Al mismo tiempo, trajeron posibles ahorros de costos, impacto en los gastos y otros elementos que el equipo de ingeniería ya estaba rastreando como métricas de costos.
Resumir
La facturación en la nube es compleja, pero es a través de esa complejidad que podemos analizar qué impulsa el gasto y los equipos obtienen sus propios informes sobre las decisiones de optimización. Incluso si la plataforma FinOps se usa para generar informes y visualizaciones automáticos, es necesario comprender el formato de datos del proveedor de la nube para sacar conclusiones correctas de los datos. Además, también debemos establecer un formato de indicador de costos estándar para estandarizar la documentación y los informes en toda la empresa. Es probable que "estandarizado" sea una tasa amortizada no prestada dados los descuentos personalizados, los costos de soporte que cobran las empresas y los proveedores de la nube. Para evitar desviaciones en la comprensión de los datos entre equipos y causar confusión, la estandarización es un proceso necesario.
Resumido de la siguiente manera:
• Los datos de facturación casi siempre se basan en elementos de eventos.
●Un análisis detallado de los datos de facturación solo se puede llevar a cabo si se tiene un conocimiento profundo de los mismos. Aprender de los datos sin procesar lo ayudará a convertirse en un verdadero experto en FinOps.
● Los pequeños cambios en la facturación en la nube pueden convertirse rápidamente en cambios cualitativos, por lo que es necesario realizar un seguimiento de los cambios en tiempo real a través de la detección automática de anomalías y los informes de discrepancias para identificar tendencias.
●Fórmula de cálculo simple para facturas en la nube: gasto = uso × tasa, entre los cuales, la factura se puede optimizar cambiando los dos factores de apalancamiento de "uso" y "tasa", es decir, reduciendo la cantidad de recursos utilizados y reduciendo la tasa de recursos
● Descentraliza el problema de reducción de uso (reducción de uso de recursos), mientras que centraliza el problema de reducción de tarifas (reducción de gasto).
● Las instancias facturables y los descuentos por compromiso de uso deben ser administrados por un equipo central, ya que tienen visibilidad de la distribución completa de los activos de la nube y la capacidad de administrar grandes compromisos de uso.
●Después de obtener las sugerencias de optimización proporcionadas por el equipo central, cada equipo debe escuchar las sugerencias y optimizar el uso. El propietario de la aplicación decide cómo operar.
Lo anterior es el contenido de la primera parte del libro. Hemos sentado las bases para la investigación posterior al presentar qué es Fin Ops, por qué se necesita Fin Ops, cómo hacer cambios culturales y el contenido de la facturación en la nube. La segunda parte es interesante, ya que lo explicamos cómo una empresa implementó la gestión del ciclo de vida de FinOps.
Este artículo está seleccionado de "FinOps Cloud Cost Optimization", autorizado por la editorial.
Los autores son JR Stormen y Mike Fuller.
Este libro recopila una gran cantidad de casos prácticos de la comunidad de la Fundación FinOps, lo que permite a los lectores comprender historias exitosas de optimización de costos en la nube y las razones detrás del éxito. Además, se analizan las capacidades técnicas proporcionadas por los principales proveedores de nube, para que los lectores puedan consultarlas al elegir tecnologías de nube para resolver problemas de optimización de costos.
"FinOps Cloud Cost Optimization" es el primer libro que explica sistemáticamente qué es FinOps y cómo implementar FinOps: define muchos términos técnicos y financieros en el campo de la optimización de costos de la nube y comparte lo que las empresas necesitan para promover la optimización de costos de la nube. ajuste completo de la estructura organizativa, promoción de procesos, división de responsabilidades y los medios técnicos comunes en los que se debe confiar, etc. Este libro recopila una gran cantidad de casos prácticos de la comunidad de la Fundación FinOps, lo que permite a los lectores comprender historias exitosas de optimización de costos en la nube y las razones detrás del éxito. Además, se analizan las capacidades técnicas proporcionadas por los principales proveedores de nube, para que los lectores puedan consultarlas al elegir tecnologías de nube para resolver problemas de optimización de costos.
Escanee el código QR para comprar libros con descuentos especiales (limitado a 100 personas).
Consejos: Deje un mensaje debajo de este artículo, y los amigos a los que les gusten los 3 mejores en el área de comentarios obtendrán un libro del editor. (dentro de las 36 horas)