Definitivament, us heu preguntat quant costa la infraestructura del vostre projecte. Al mateix temps, és sorprenent: el creixement dels costos no és lineal respecte a les càrregues. Molts propietaris d'empreses, estacions de servei i desenvolupadors entenen secretament que estan pagant de més. Però per a què exactament?
Normalment, reduir costos només es redueix a trobar la solució més barata, un pla AWS o, en el cas dels bastidors físics, optimitzar la configuració del maquinari. No només això: de fet, qualsevol ho està fent, com Déu vol: si estem parlant d'una startup, probablement aquest és un desenvolupador líder que té molts maldecaps. A les oficines més grans, el CMO/CTO s'encarrega d'això i, de vegades, el director general s'involucra personalment en el tema juntament amb el comptable en cap. En general, aquelles persones que tenen prou preocupacions "bàsiques". I resulta que les factures d'infraestructures estan pujant, però els que no tenen temps d'afrontar-s'hi s'encarreguen.
Si necessiteu comprar paper higiènic per a l'oficina, ho farà el responsable de subministrament o un responsable de l'empresa de neteja. Si estem parlant de desenvolupament - leads i CTO. Vendes: també està tot clar. Però des dels vells temps, quan una "habitació de servidors" era un nom per a un gabinet en el qual hi havia un sistema de torre normal amb una mica més de memòria RAM i un parell de discs durs a la incursió, tothom (o almenys molts) ignorava el fet que la compra de capacitat s'ha de gestionar també una persona especialment capacitada.
Per desgràcia, la memòria històrica i l'experiència indiquen que durant dècades aquesta tasca es va traslladar a persones "atzars": qui estigués més proper va recollir la pregunta. I només fa poc que la professió de FinOps va començar a prendre forma al mercat i a prendre forma concreta. Es tracta de la mateixa persona especialment formada que té com a tasca controlar la compra i l'ús de la capacitat. I, en definitiva, en reduir els costos de l'empresa en aquest àmbit.
No advoquem per abandonar solucions cares i efectives: cada empresa ha de decidir per si mateixa què necessita per a una existència còmoda en termes de maquinari i tarifes al núvol. Però no es pot deixar de prestar atenció al fet que la compra irreflexiva "d'acord amb la llista" sense un seguiment i anàlisi posterior de l'ús per a moltes empreses, en última instància, provoca pèrdues molt i molt importants a causa d'una gestió ineficaç dels "actius" del seu backend.
Qui és FinOps
Suposem que teniu una empresa de bona reputació, de la qual els venedors parlen d'"empresa" amb un to tranquil. Probablement, "segons la llista" heu comprat una dotzena o dos servidors, AWS i algunes altres "cosetes". El que és lògic: en una gran empresa es produeix algun tipus de moviment constantment: alguns equips creixen, d'altres es desintegren, d'altres es traslladen a projectes veïns. I la combinació d'aquests moviments, juntament amb el mecanisme de contractació "basat en llistes", en última instància, condueix a nous cabells grisos quan es mira la propera factura mensual d'infraestructura.
Llavors, què fer: continuar amb paciència en gris, pintar-lo o esbrinar els motius de l'aparició d'aquests nombrosos zeros terribles al pagament?
Siguem sincers: l'aprovació, l'aprovació i el pagament directe d'una sol·licitud dins de l'empresa per a la mateixa tarifa AWS no sempre (en realitat, gairebé mai) és ràpida. I precisament a causa del moviment corporatiu constant, algunes d'aquestes mateixes adquisicions es poden "perdre" en algun lloc. I és trivial quedar-se inactiu. Si un administrador atent nota un bastidor sense propietari a la seva sala de servidors, en el cas de les tarifes al núvol tot és molt més trist. Es poden deixar durant mesos, pagats, però al mateix temps ja no els necessita ningú del departament per al qual es van comprar. Al mateix temps, els companys de la següent oficina comencen a arrencar-se els cabells encara no grisos no només del cap, sinó també en altres llocs: no han pogut pagar aproximadament la mateixa tarifa d'AWS per a la enèsima setmana, que es necessita desesperadament.
Quina és la solució més evident? Així és, passa les regnes als més necessitats, i tothom està content. Però les comunicacions horitzontals no sempre estan ben establertes. I és possible que el segon departament simplement no conegui la riquesa del primer, que d'alguna manera va resultar que no necessitava realment aquesta riquesa.
Qui té la culpa d'això? - De fet, ningú. Així està tot configurat de moment.
Qui pateix això? - Això és tot, tota la companyia.
Qui pot arreglar la situació? - Sí, sí, FinOps.
FinOps no és només una capa entre els desenvolupadors i l'equip que necessiten, sinó una persona o equip que sabrà on, què i com de bé "es troba" pel que fa a les mateixes tarifes de núvol adquirides per l'empresa. De fet, aquestes persones han de treballar conjuntament amb DevOps, d'una banda, i el departament financer de l'altra, fent el paper d'intermediari eficaç i, sobretot, d'analista.
Una mica sobre l'optimització
Núvols. Relativament barat i molt còmode. Però aquesta solució deixa de ser barata quan el nombre de servidors arriba a dos o tres dígits. A més, els núvols permeten utilitzar cada cop més serveis que abans no estaven disponibles: es tracta de bases de dades com a servei (Amazon AWS, Azure Database), aplicacions sense servidor (AWS Lambda, Azure Functions) i moltes altres. Són tots molt xulos perquè són fàcils d'utilitzar: compra i surt, sense problemes. Però com més s'enfonsen l'empresa i els seus projectes als núvols, pitjor dorm el CFO. I com més ràpid el general es torna gris.
El fet és que les factures de diversos serveis al núvol sempre són extremadament confuses: per a un article, podeu rebre una explicació de tres pàgines sobre què, on i com van anar els vostres diners. Això, per descomptat, és agradable, però és gairebé impossible d'entendre-ho. A més, la nostra opinió sobre aquest tema dista molt de ser l'única: per transferir comptes al núvol a comptes humans, hi ha serveis sencers, per exemple o . Si algú es va molestar a crear un servei separat per desxifrar factures, llavors l'escala del problema ha superat el cost del tint de cabell.
Aleshores, què fa FinOps en aquesta situació:
- entén clarament quan i en quins volums es van comprar les solucions al núvol.
- sap com s'utilitzen aquestes capacitats.
- els redistribueix en funció de les necessitats d'una unitat concreta.
- no compra "perquè ho sigui".
- i al final, t'estalvia diners.
Un bon exemple és l'emmagatzematge al núvol d'una còpia en fred d'una base de dades. Per exemple, l'arxiveu per tal de reduir la quantitat d'espai i el trànsit consumit en actualitzar l'emmagatzematge? Sí, sembla que la situació és barata, en un únic cas concret, però la totalitat d'aquestes situacions barates després comporta costos exorbitants per als serveis al núvol.
O una altra situació: heu comprat capacitat de reserva a AWS o Azure per no caure sota la càrrega màxima. Pots estar segur que aquesta és la solució òptima? Al cap i a la fi, si aquests casos estan inactius en un 80%, simplement esteu donant diners a Amazon. A més, per a aquests casos, els mateixos AWS i Azure tenen instàncies explosives: per què necessiteu servidors inactius, si podeu utilitzar una eina per resoldre problemes de pics de càrrega? O, en comptes de les instàncies On Premise, hauríeu de mirar cap a Reservat: són molt més barats i també ofereixen descomptes.
Per cert, sobre descomptes
Com dèiem al principi, l'adquisició sovint la porta a terme qualsevol persona: van trobar l'última i, d'alguna manera, ho fa ell mateix. Molt sovint, les persones que ja estan ocupades esdevenen "extremes", i com a resultat ens trobem en una situació en què una persona decideix de manera ràpida i hàbil, però de manera totalment independent, què comprar i en quines quantitats.
Però quan interactueu amb un venedor del servei al núvol, podeu obtenir condicions més favorables pel que fa a la compra majorista de capacitat. Està clar que no podreu obtenir aquests descomptes amb un cotxe amb un registre silenciós i unilateral, però després de parlar amb un gerent de vendes real, podeu esgotar-vos. O aquests nois us poden dir en què tenen descomptes actualment. També pot ser útil.
Al mateix temps, cal recordar que la llum no va convergir com una falca a AWS o Azure. Per descomptat, no es tracta d'organitzar la vostra pròpia sala de servidors, però hi ha alternatives a aquestes dues solucions clàssiques dels gegants.
Per exemple, Google va portar la plataforma Firebase a les empreses, on poden allotjar el mateix projecte mòbil clau en mà, cosa que pot requerir una escala ràpida. L'emmagatzematge, la base de dades en temps real, l'allotjament i la sincronització de dades al núvol utilitzant aquesta solució com a exemple estan disponibles en un sol lloc.
D'altra banda, si no parlem d'un projecte monolític, sinó de la seva totalitat, aleshores una solució centralitzada no sempre és beneficiosa. Si el projecte té una llarga vida, té el seu propi historial de desenvolupament i la quantitat corresponent de dades necessàries per a l'emmagatzematge, val la pena pensar en una col·locació més fragmentada.
Quan optimitzeu els costos dels serveis al núvol, de cop us adoneu que per a aplicacions crítiques per a l'empresa podeu comprar tarifes més potents que proporcionaran a l'empresa guanys ininterromputs. Al mateix temps, emmagatzemar el "llegat" del desenvolupament, arxius antics, bases de dades, etc. en núvols cars és una solució. Al cap i a la fi, per a aquestes dades, un centre de dades estàndard amb discs durs normals i maquinari de potència mitjana sense cap mena de campanes i xiulets és molt adequat.
Una vegada més, podríeu pensar que "aquest enrenou no val la pena", però tot el problema d'aquesta publicació es basa en el fet que en diverses etapes les persones responsables descuiden les petites coses i fan allò que és més convenient i més ràpid. El que, al cap i a la fi, després d'un parell d'anys es tradueix en aquells relats de terror.
El resultat?
En general, els núvols són genials, resolen molts problemes per a empreses de qualsevol mida. Tanmateix, la novetat d'aquest fenomen fa que encara no tinguem una cultura de consum i gestió. FinOps és una palanca organitzativa que us ajuda a aprofitar el poder del núvol de manera més eficaç. El més important és no convertir aquesta posició en un anàleg d'un esquadró d'afusellament, la tasca del qual serà agafar de la mà els desenvolupadors poc atents i "renyar-los" pel temps d'inactivitat.
Els desenvolupadors haurien de desenvolupar, no comptar els diners de l'empresa. Per tant, FinOps hauria de fer que tant el procés de compra com el procés de desmantellament o transferència de la capacitat del núvol a altres equips siguin un esdeveniment senzill i agradable per a totes les parts.
Font: www.habr.com