Talagang naisip mo kung magkano ang gastos sa imprastraktura ng iyong proyekto. Sa parehong oras, ito ay nakakagulat: ang paglago ng mga gastos ay hindi linear na may paggalang sa mga naglo-load. Maraming mga may-ari ng negosyo, mga istasyon ng serbisyo at mga developer ang lihim na nauunawaan na sila ay labis na nagbabayad. Ngunit para saan nga ba?
Karaniwan, ang pagbabawas ng mga gastos ay bumababa lamang sa paghahanap ng pinakamurang solusyon, isang AWS plan, o, sa kaso ng mga pisikal na rack, pag-optimize sa configuration ng hardware. Hindi lang iyon: sa katunayan, ginagawa ito ng sinuman, ayon sa kagustuhan ng Diyos: kung ang pinag-uusapan natin ay tungkol sa isang startup, malamang na ito ay isang nangungunang developer na maraming sakit ng ulo. Sa mas malalaking opisina, ito ay tinatalakay ng CMO/CTO, at kung minsan ang pangkalahatang direktor ay personal na nasangkot sa isyu kasama ang punong accountant. Sa pangkalahatan, ang mga taong may sapat na "pangunahing" alalahanin. At lumalabas na ang mga bayarin sa imprastraktura ay tumataas, ngunit ang mga walang oras upang harapin ito ay nakikitungo dito.
Kung kailangan mong bumili ng toilet paper para sa opisina, ito ay gagawin ng tagapamahala ng suplay o isang responsableng tao mula sa kumpanya ng paglilinis. Kung pag-uusapan natin ang tungkol sa pag-unlad - mga lead at CTO. Benta - malinaw din ang lahat. Ngunit mula noong unang panahon, kapag ang isang "server room" ay isang pangalan para sa isang cabinet kung saan mayroong isang ordinaryong sistema ng tore na may kaunting RAM at ilang mga hard drive sa pagsalakay, lahat (o hindi bababa sa marami) ay hindi pinansin ang katotohanan na ang pagbili ng kapasidad ay dapat ding hawakan ng isang espesyal na sinanay na tao.
Sa kasamaang palad, ang makasaysayang memorya at karanasan ay nagpapahiwatig na sa loob ng mga dekada ang gawaing ito ay inilipat sa "random" na mga tao: kung sino ang pinakamalapit na kinuha ang tanong. At kamakailan lamang nagsimulang magkaroon ng hugis sa merkado ang propesyon ng FinOps at magkaroon ng konkretong hugis. Ito ang parehong espesyal na sinanay na tao na ang gawain ay kontrolin ang pagbili at paggamit ng kapasidad. At, sa huli, sa pagbabawas ng mga gastos ng kumpanya sa lugar na ito.
Hindi kami nagsusulong na talikuran ang mga mahal at epektibong solusyon: ang bawat negosyo ay dapat magpasya para sa sarili nito kung ano ang kailangan nito para sa isang komportableng pag-iral sa mga tuntunin ng hardware at cloud tariffs. Ngunit ang isang tao ay hindi maaaring makatulong ngunit bigyang-pansin ang katotohanan na ang walang pag-iisip na pagbili "ayon sa listahan" nang walang kasunod na pagsubaybay at pagsusuri ng paggamit para sa maraming mga kumpanya sa huli ay nagreresulta sa napaka, napakalaking pagkalugi dahil sa hindi epektibong pamamahala ng "mga asset" ng kanilang backend.
Sino ang FinOps
Sabihin nating mayroon kang isang kagalang-galang na negosyo, na pinag-uusapan ng mga nagbebenta tungkol sa "enterprise" sa isang humihingang tono. Malamang, "ayon sa listahan" bumili ka ng isang dosenang o dalawang server, AWS at ilang iba pang "maliit na bagay". Alin ang lohikal: sa isang malaking kumpanya ang ilang uri ng paggalaw ay patuloy na nangyayari - ang ilang mga koponan ay lumalaki, ang iba ay naghiwa-hiwalay, ang iba ay inilipat sa mga kalapit na proyekto. At ang kumbinasyon ng mga paggalaw na ito, kasama ang mekanismo ng pagbili na "nakabatay sa listahan", sa huli ay humahantong sa mga bagong kulay-abo kapag tinitingnan ang susunod na buwanang bayarin sa imprastraktura.
Kaya kung ano ang gagawin - matiyagang magpatuloy sa kulay abo, pintura sa ibabaw nito, o alamin ang mga dahilan para sa paglitaw ng maraming kakila-kilabot na mga zero sa pagbabayad?
Maging tapat tayo: ang pag-apruba, pag-apruba at direktang pagbabayad ng isang aplikasyon sa loob ng kumpanya para sa parehong taripa ng AWS ay hindi palaging (sa katotohanan, halos hindi kailanman) mabilis. At dahil mismo sa patuloy na paggalaw ng korporasyon, ang ilan sa mga parehong pagkuha na ito ay maaaring "nawala" sa isang lugar. At ito ay walang halaga na tumayo nang walang ginagawa. Kung napansin ng isang matulungin na tagapangasiwa ang isang walang-ari na rack sa kanyang silid ng server, kung gayon sa kaso ng mga tariff ng ulap ang lahat ay mas malungkot. Maaari silang ilagay sa loob ng ilang buwan - binayaran, ngunit sa parehong oras ay hindi na kailangan ng sinuman sa departamento kung saan sila binili. Kasabay nito, ang mga kasamahan mula sa susunod na opisina ay nagsisimulang mapunit ang kanilang hindi pa kulay-abo na buhok hindi lamang sa kanilang mga ulo, kundi pati na rin sa iba pang mga lugar - hindi nila nabayaran ang humigit-kumulang sa parehong taripa ng AWS para sa ika-na linggo, na ay lubhang kailangan.
Ano ang pinaka-halatang solusyon? Tama, ibigay ang renda sa mga nangangailangan, at lahat ay masaya. Ngunit ang mga pahalang na komunikasyon ay hindi palaging maayos. At ang pangalawang departamento ay maaaring hindi lamang alam ang tungkol sa yaman ng una, na sa paanuman ay hindi talaga kailangan ng yaman na ito.
Sino ang dapat sisihin dito? - Sa totoo lang, walang tao. Iyan ay kung paano ang lahat ay naka-set up sa ngayon.
Sino ang naghihirap mula dito? - Iyon lang, ang buong kumpanya.
Sino ang maaaring ayusin ang sitwasyon? - Oo, oo, FinOps.
Ang FinOps ay hindi lamang isang layer sa pagitan ng mga developer at ng kagamitan na kailangan nila, ngunit isang tao o koponan na makakaalam kung saan, ano at gaano ito "namamalagi" sa mga tuntunin ng parehong mga taripa sa ulap na binili ng kumpanya. Sa katunayan, ang mga taong ito ay dapat na makipagtulungan sa DevOps, sa isang banda, at ang departamento ng pananalapi sa kabilang banda, na gumaganap sa papel ng isang epektibong tagapamagitan at, higit sa lahat, isang analyst.
Medyo tungkol sa pag-optimize
Mga ulap. Medyo mura at napaka-convenient. Ngunit ang solusyon na ito ay hihinto sa pagiging mura kapag ang bilang ng mga server ay umabot sa doble o triple digit. Bilang karagdagan, ginagawang posible ng mga ulap na gumamit ng higit at higit pang mga serbisyo na dati nang hindi magagamit: ito ay mga database bilang isang serbisyo (Amazon AWS, Azure Database), mga serverless na application (AWS Lambda, Azure Functions) at marami pang iba. Lahat sila ay napaka-cool dahil ang mga ito ay madaling gamitin - bumili at pumunta, walang problema. Ngunit ang mas malalim na kumpanya at ang mga proyekto nito ay bumagsak sa mga ulap, mas malala ang pagtulog ng CFO. At mas mabilis na nagiging kulay abo ang heneral.
Ang katotohanan ay ang mga invoice para sa iba't ibang mga serbisyo ng cloud ay palaging lubhang nakakalito: para sa isang item maaari kang makatanggap ng tatlong pahinang paliwanag kung ano, saan at paano napunta ang iyong pera. Ito, siyempre, ay kaaya-aya, ngunit halos imposibleng maunawaan ito. Bukod dito, ang aming opinyon sa isyung ito ay malayo sa isa lamang: upang mailipat ang mga cloud account sa mga tao, mayroong mga buong serbisyo, halimbawa o . Kung ang isang tao ay nag-abala na lumikha ng isang hiwalay na serbisyo para sa pag-decipher ng mga singil, kung gayon ang laki ng problema ay lumampas sa halaga ng pangulay ng buhok.
Kaya ano ang ginagawa ng FinOps sa sitwasyong ito:
- malinaw na nauunawaan kung kailan at sa anong dami ang binili ng mga solusyon sa ulap.
- alam kung paano ginagamit ang mga kapasidad na ito.
- muling ipinamamahagi ang mga ito depende sa mga pangangailangan ng isang partikular na yunit.
- ay hindi bumili ng "upang ito ay maaaring".
- at sa huli, nakakatipid ka ng pera.
Ang isang magandang halimbawa ay ang cloud storage ng isang malamig na kopya ng isang database. Halimbawa, ini-archive mo ba ito upang mabawasan ang dami ng espasyo at trapikong natupok kapag ina-update ang storage? Oo, mukhang mura ang sitwasyon - sa isang partikular na kaso, ngunit ang kabuuan ng gayong murang mga sitwasyon ay nagreresulta sa napakalaking gastos para sa mga serbisyo sa cloud.
O ibang sitwasyon: bumili ka ng reserbang kapasidad sa AWS o Azure para hindi mahulog sa peak load. Makatitiyak ka ba na ito ang pinakamainam na solusyon? Pagkatapos ng lahat, kung ang mga pagkakataong ito ay idle 80%, kung gayon nagbibigay ka lang ng pera sa Amazon. Bukod dito, para sa mga ganitong kaso, ang parehong AWS at Azure ay may mga burstable na pagkakataon - bakit kailangan mo ng mga idling server, kung maaari kang gumamit ng tool upang malutas ang mga problema ng mga peak load? O, sa halip na On Premise instance, dapat kang tumingin sa Reserved - mas mura ang mga ito at nag-aalok din sila ng mga diskwento.
Sa pamamagitan ng paraan, tungkol sa mga diskwento
Tulad ng sinabi namin sa simula, ang pagkuha ay madalas na isinasagawa ng sinuman - natagpuan nila ang huli, at pagkatapos ay ginagawa niya ito mismo. Kadalasan, ang mga taong abala na ay nagiging "matinding", at bilang isang resulta nakakakuha tayo ng isang sitwasyon kung saan ang isang tao ay mabilis at mahusay, ngunit ganap na nakapag-iisa, nagpapasya kung ano at sa kung anong dami ang bibilhin.
Ngunit kapag nakikipag-ugnayan sa isang salesperson mula sa cloud service, maaari kang makakuha ng mas kanais-nais na mga kondisyon pagdating sa pakyawan na pagbili ng kapasidad. Malinaw na hindi ka makakakuha ng gayong mga diskwento mula sa isang kotse na may tahimik at isang panig na pagpaparehistro - ngunit pagkatapos makipag-usap sa isang tunay na tagapamahala ng benta, maaari kang masunog. O maaaring sabihin sa iyo ng mga taong ito kung saan sila kasalukuyang may mga diskwento. Maaari rin itong maging kapaki-pakinabang.
Kasabay nito, kailangan mong tandaan na ang ilaw ay hindi nagtagpo tulad ng isang wedge sa AWS o Azure. Siyempre, walang tanong sa pag-aayos ng iyong sariling silid ng server - ngunit may mga alternatibo sa dalawang klasikong solusyon na ito mula sa mga higante.
Halimbawa, dinala ng Google ang platform ng Firebase sa mga kumpanya, kung saan maaari nilang i-host ang parehong proyekto sa mobile sa turnkey na batayan, na maaaring mangailangan ng mabilis na pag-scale. Ang storage, real-time na database, hosting at cloud data synchronization gamit ang solusyon na ito bilang isang halimbawa ay available sa isang lugar.
Sa kabilang banda, kung hindi natin pinag-uusapan ang isang monolitikong proyekto, ngunit tungkol sa kanilang kabuuan, kung gayon ang isang sentralisadong solusyon ay hindi palaging kapaki-pakinabang. Kung ang proyekto ay mahaba ang buhay, ay may sariling kasaysayan ng pag-unlad at isang kaukulang halaga ng data na kinakailangan para sa imbakan, kung gayon ito ay nagkakahalaga ng pag-iisip tungkol sa mas pira-pirasong pagkakalagay.
Kapag nag-o-optimize ng mga gastos para sa mga serbisyo sa cloud, maaari mong biglaang mapagtanto na para sa mga application na kritikal sa negosyo maaari kang bumili ng mas malakas na mga taripa na magbibigay sa kumpanya ng walang patid na mga kita. Kasabay nito, ang pag-iimbak ng "legacy" ng pag-unlad, mga lumang archive, database, atbp. sa mga mamahaling ulap ay isang solusyon. Pagkatapos ng lahat, para sa naturang data, ang isang karaniwang data center na may mga regular na HDD at medium-power na hardware na walang anumang mga kampanilya at sipol ay angkop.
Dito muli, maaari mong isipin na "ang kaguluhan na ito ay hindi katumbas ng halaga," ngunit ang buong problema ng publikasyong ito ay batay sa katotohanan na sa iba't ibang yugto ay pinababayaan ng mga responsableng tao ang maliliit na bagay at ginagawa ang mas maginhawa at mas mabilis. Na, sa huli, pagkalipas ng ilang taon ay nagreresulta sa mga nakakatakot na account na iyon.
Ang resulta?
Sa pangkalahatan, ang mga ulap ay cool, nalulutas nila ang maraming problema para sa mga negosyo sa anumang laki. Gayunpaman, ang pagiging bago ng hindi pangkaraniwang bagay na ito ay nangangahulugan na wala pa rin tayong kultura ng pagkonsumo at pamamahala. Ang FinOps ay isang organizational lever na tumutulong sa iyong gamitin ang cloud power nang mas epektibo. Ang pangunahing bagay ay hindi upang gawing analogue ang posisyon na ito ng isang firing squad, na ang gawain ay upang mahuli ang mga hindi nag-iingat na mga developer sa pamamagitan ng kamay at "sawayin" sila para sa downtime.
Dapat bumuo ang mga developer, hindi bilangin ang pera ng kumpanya. Kaya dapat gawing simple at kasiya-siya ng lahat ng partido ang proseso ng pagbili at ang proseso ng pag-decommission o paglilipat ng kapasidad ng cloud sa iba pang mga team ng FinOps.
Pinagmulan: www.habr.com