Definitivamente te preguntas canto custa a infraestrutura do teu proxecto. Ao mesmo tempo, é sorprendente: o crecemento dos custos non é lineal con respecto ás cargas. Moitos empresarios, estacións de servizo e desenvolvedores entenden en segredo que están pagando de máis. Pero para que exactamente?
Normalmente, reducir custos simplemente se reduce a atopar a solución máis barata, un plan AWS ou, no caso dos racks físicos, optimizar a configuración do hardware. Non só iso: de feito, calquera está a facer isto, como Deus quere: se estamos a falar dunha startup, probablemente este sexa un desenvolvedor líder que teña moitos dores de cabeza. Nas oficinas máis grandes, isto encárgase o CMO/CTO e, ás veces, o director xeral intervén persoalmente no problema xunto co xefe de contabilidade. En xeral, aquelas persoas que teñen bastantes preocupacións "fundamentais". E resulta que as facturas das infraestruturas están subindo, pero quen non ten tempo para afrontalo está a tratar con iso.
No caso de que necesites mercar papel hixiénico para a oficina, farao o responsable de subministración ou un responsable da empresa de limpeza. Se estamos a falar de desenvolvemento - leads e CTO. Vendas: tamén está todo claro. Pero desde os vellos tempos, cando unha "sala de servidores" era un nome para un gabinete no que había un sistema de torre común cun pouco máis de RAM e un par de discos duros na incursión, todos (ou polo menos moitos) ignoran o feito de que a compra de capacidade debe ser xestionada tamén por unha persoa especialmente formada.
Por desgraza, a memoria histórica e a experiencia indican que durante décadas esta tarefa foi trasladada a persoas "aleatorias": quen estaba máis preto recolleu a pregunta. E só hai pouco que a profesión FinOps comezou a tomar forma no mercado e a tomar forma concreta. Trátase da mesma persoa especialmente formada que ten como tarefa controlar a compra e o uso da capacidade. E, en definitiva, na redución dos custos da empresa neste ámbito.
Non avogamos por abandonar solucións caras e eficaces: cada empresa debe decidir por si mesma o que necesita para unha existencia cómoda en termos de tarifas de hardware e nube. Pero non se pode deixar de prestar atención ao feito de que as compras irreflexivas "segundo a lista" sen un seguimento e análise posterior do uso para moitas empresas orixinan finalmente perdas moi, moi substanciais debido á xestión ineficaz dos "activos" do seu backend.
Quen é FinOps
Digamos que tes unha empresa respectable, que os vendedores falan de "empresa" nun ton tranquilo. Probablemente, "segundo a lista" compraches unha ducia ou dous servidores, AWS e algunhas outras "cousas pequenas". O que é lóxico: nunha gran empresa está a suceder constantemente algún tipo de movemento: algúns equipos crecen, outros se desintegran, outros son trasladados a proxectos veciños. E a combinación destes movementos, xunto co mecanismo de contratación "baseado en listas", leva finalmente a novas canas cando se mira a próxima factura mensual de infraestruturas.
Entón, que facer: continúa con paciencia gris, pinta sobre el ou descubre as razóns da aparición destes numerosos ceros terribles no pago?
Sexamos honestos: a aprobación, aprobación e pago directo dunha solicitude dentro da empresa para a mesma tarifa de AWS non sempre (en realidade, case nunca) é rápida. E precisamente por mor do constante movemento corporativo, algunhas destas mesmas adquisicións poden "perderse" nalgún lugar. E é trivial estar ocioso. Se un administrador atento nota un rack sen propietario na súa sala de servidores, entón no caso das tarifas na nube todo é moito máis triste. Pódense deter durante meses: pagos, pero ao mesmo tempo xa non os necesita ninguén do departamento para o que foron adquiridos. Ao mesmo tempo, os compañeiros da próxima oficina comezan a arrincar o seu cabelo aínda non canoso non só da cabeza, senón tamén noutros lugares: non puideron pagar aproximadamente a mesma tarifa de AWS durante a enésima semana, que é desesperadamente necesario.
Cal é a solución máis obvia? Así é, dálle as rendas aos necesitados, e todos contentos. Pero as comunicacións horizontais non sempre están ben establecidas. E o segundo departamento pode simplemente non saber sobre a riqueza do primeiro, que de algunha maneira resultou que realmente non necesitaba esta riqueza.
Quen ten a culpa disto? - En realidade, ninguén. Así está todo configurado polo de agora.
Quen sofre isto? - Iso é, toda a compañía.
Quen pode arranxar a situación? - Si, si, FinOps.
FinOps non é só unha capa entre os desenvolvedores e os equipos que necesitan, senón unha persoa ou equipo que saberá onde, que e como de ben "está" en canto ás mesmas tarifas de nube adquiridas pola compañía. De feito, estas persoas deben traballar en conxunto con DevOps, por unha banda, e co departamento de finanzas por outra, desempeñando o papel de intermediario eficaz e, o máis importante, de analista.
Un pouco sobre a optimización
Nubes. Relativamente barato e moi cómodo. Pero esta solución deixa de ser barata cando o número de servidores chega a dobre ou triplo díxitos. Ademais, as nubes permiten utilizar cada vez máis servizos que antes non estaban dispoñibles: trátase de bases de datos como servizo (Amazon AWS, Azure Database), aplicacións sen servidor (AWS Lambda, Azure Functions) e moitas outras. Son todos moi chulos porque son fáciles de usar: compra e listo, sen problemas. Pero canto máis se mergullan a empresa e os seus proxectos nas nubes, peor dorme o CFO. E canto máis rápido se volve gris o xeneral.
O feito é que as facturas de varios servizos na nube son sempre moi confusas: por un artigo podes recibir unha explicación de tres páxinas de que, onde e como foi o teu diñeiro. Isto, por suposto, é agradable, pero é case imposible entendelo. Ademais, a nosa opinión sobre este tema dista moito de ser a única: para transferir contas na nube ás humanas, hai servizos enteiros, por exemplo ou . Se alguén se molestou en crear un servizo separado para descifrar facturas, entón a escala do problema superou o custo da tintura para o cabelo.
Entón, que fai FinOps nesta situación:
- comprende claramente cando e en que volumes se compraron solucións na nube.
- sabe como se utilizan estas capacidades.
- redistribúeos en función das necesidades dunha determinada unidade.
- non compra "para que sexa".
- e ao final, aforrache cartos.
Un gran exemplo é o almacenamento na nube dunha copia fría dunha base de datos. Por exemplo, arquivao para reducir o espazo e o tráfico que se consumen ao actualizar o almacenamento? Si, parece que a situación é barata, nun único caso específico, pero a totalidade de tales situacións baratas despois resulta en custos desorbitados para os servizos na nube.
Ou outra situación: adquiriu capacidade de reserva en AWS ou Azure para non caer na carga máxima. Podes estar seguro de que esta é a solución óptima? Despois de todo, se estes casos están inactivos nun 80%, entón simplemente estás dando diñeiro a Amazon. Ademais, para tales casos, o mesmo AWS e Azure teñen instancias explosivas: por que necesitas servidores inactivos, se podes usar unha ferramenta para resolver problemas de pico de carga? Ou, en lugar de instancias On Premise, deberías mirar cara a Reservado: son moito máis baratos e tamén ofrecen descontos.
Por certo, sobre descontos
Como dixemos ao principio, a adquisición adoita levar a cabo calquera persoa: atoparon o último e, dalgunha maneira, faino el mesmo. Na maioría das veces, as persoas que xa están ocupadas convértense en "extremas" e, como resultado, obtemos unha situación na que unha persoa de forma rápida e habil, pero de forma totalmente independente, decide que comprar e en que cantidades.
Pero ao interactuar cun vendedor do servizo na nube, pode obter condicións máis favorables cando se trata de compra por xunto de capacidade. Está claro que non poderás obter tales descontos cun coche cun rexistro silencioso e unilateral, pero despois de falar cun verdadeiro xestor de vendas, podes esgotar. Ou estes rapaces poden dicirche en que teñen descontos actualmente. Tamén pode ser útil.
Ao mesmo tempo, cómpre lembrar que a luz non converxeu como unha cuña en AWS ou Azure. Por suposto, non hai cuestión de organizar a túa propia sala de servidores, pero hai alternativas a estas dúas solucións clásicas dos xigantes.
Por exemplo, Google trouxo a plataforma Firebase ás empresas, nas que poden aloxar o mesmo proxecto móbil de forma chave en man, o que pode requirir unha escalada rápida. Almacenamento, base de datos en tempo real, hospedaxe e sincronización de datos na nube usando esta solución como exemplo están dispoñibles nun só lugar.
Por outra banda, se non falamos dun proxecto monolítico, senón da súa totalidade, non sempre é beneficiosa unha solución centralizada. Se o proxecto é de longa duración, ten o seu propio historial de desenvolvemento e a correspondente cantidade de datos necesarios para o almacenamento, entón paga a pena pensar nunha colocación máis fragmentada.
Ao optimizar os custos dos servizos na nube, de súpeto podes entender que para aplicacións críticas para a empresa podes mercar tarifas máis potentes que proporcionarán á empresa ganancias ininterrompidas. Ao mesmo tempo, almacenar o "legado" do desenvolvemento, arquivos antigos, bases de datos, etc. en nubes caras é unha solución. Despois de todo, para tales datos, un centro de datos estándar con discos duros habituais e hardware de potencia media sen ningún tipo de asubíos e asubíos é bastante axeitado.
Aquí de novo, podes pensar que "este alboroto non paga a pena", pero todo o problema desta publicación baséase no feito de que en varias etapas os responsables descoidan as pequenas cousas e fan o que é máis cómodo e rápido. O que, ao final, despois dun par de anos resulta nesas contas de terror.
O resultado?
En xeral, as nubes son xeniais, resolven moitos problemas para empresas de calquera tamaño. Porén, a novidade deste fenómeno fai que aínda non teñamos unha cultura de consumo e xestión. FinOps é unha panca organizativa que che axuda a aproveitar o poder da nube de forma máis eficaz. O principal é non converter esta posición nun análogo dun pelotón de fusilamento, cuxa tarefa será atrapar pola man aos desenvolvedores desatentos e "reprendelos" polo tempo de inactividade.
Os desenvolvedores deben desenvolver, non contar o diñeiro da empresa. Por iso, FinOps debería facer que tanto o proceso de compra como o proceso de desmantelamento ou transferencia de capacidade da nube a outros equipos sexa un evento sinxelo e agradable para todas as partes.
Fonte: www.habr.com