Sampeyan mesthi kepingin weruh pira biaya infrastruktur proyek sampeyan. Ing wektu sing padha, nggumunake: wutah biaya ora linear babagan beban. Akeh pamilik bisnis, stasiun layanan lan pangembang kanthi rahasia ngerti yen dheweke mbayar luwih. Nanging kanggo apa persis?
Biasane, biaya pemotongan mung mudhun kanggo nemokake solusi sing paling murah, rencana AWS, utawa, ing kasus rak fisik, ngoptimalake konfigurasi hardware. Ora mung iku: nyatane, sapa wae sing nindakake iki, kaya sing dikarepake dening Gusti Allah: yen kita ngomong babagan wiwitan, mula iki bisa uga dadi pangembang utama sing duwe akeh ngelu. Ing kantor sing luwih gedhe, iki ditangani dening CMO / CTO, lan kadhangkala direktur umum dhewe melu masalah kasebut bebarengan karo kepala akuntan. UmumΓ©, wong-wong sing duwe keprihatinan "inti" cukup. Lan pranyata tagihan infrastruktur mundhak, nanging sing ora duwe wektu kanggo ngatasi masalah kasebut.
Yen sampeyan kudu tuku kertas jamban kanggo kantor, iki bakal ditindakake dening manajer pasokan utawa wong sing tanggung jawab saka perusahaan reresik. Yen kita ngomong babagan pembangunan - timbal lan CTO. Sales - kabeh uga cetha. Nanging wiwit jaman biyen, nalika "kamar server" minangka jeneng kanggo kabinet sing ana sistem menara biasa kanthi RAM sing luwih cilik lan sawetara hard drive ing serangan kasebut, kabeh wong (utawa paling ora akeh) ora nglirwakake. nyatane yen tuku kapasitas kudu ditangani uga wong sing dilatih khusus.
Sayange, memori lan pengalaman sajarah nuduhake yen sawetara dekade tugas iki dipindhah menyang "acak" wong: sapa sing paling cedhak njupuk pitakonan. Lan mung bubar profesi FinOps wiwit njupuk wangun ing pasar lan njupuk sawetara wangun konkrit. Iki minangka wong sing dilatih khusus sing tugase ngontrol tuku lan nggunakake kapasitas. Lan, pungkasane, nyuda biaya perusahaan ing wilayah kasebut.
Kita ora nyengkuyung kanggo ninggalake solusi sing larang lan efektif: saben bisnis kudu mutusake dhewe apa sing dibutuhake kanggo eksistensi sing nyaman babagan tarif hardware lan awan. Nanging siji ora bisa bantuan nanging mbayar manungsa waΓ© kanggo kasunyatan sing mundhut thoughtless "miturut dhaftar" tanpa ngawasi sakteruse lan analisis saka nggunakake kanggo akeh perusahaan wekasanipun nyebabake banget, losses substansial amarga manajemen ora efektif saka "aset" backend sing.
Sapa sing FinOps
Contone, sampeyan duwe perusahaan sing biso dipercoyo, sing diomongake wong dodolan babagan "perusahaan" kanthi nada ambegan. Mbokmenawa, "miturut dhaptar" sampeyan tuku rolas utawa rong server, AWS lan sawetara "barang cilik" liyane. Sing logis: ing perusahaan gedhe sawetara gerakan terus-terusan - sawetara tim tuwuh, liyane disintegrasi, liyane ditransfer menyang proyek tetanggan. Lan kombinasi gerakan kasebut, bebarengan karo mekanisme pengadaan "basis dhaptar", pungkasane nyebabake rambut abu-abu anyar nalika ndeleng tagihan infrastruktur saben wulan sabanjure.
Dadi, apa sing kudu ditindakake - kanthi sabar terus werna abu-abu, nglukis, utawa ngerteni sebab-sebab munculΓ© nol sing nggegirisi iki ing pembayaran?
Ayo dadi jujur: persetujuan, persetujuan lan pembayaran langsung saka aplikasi ing perusahaan kanggo tarif AWS padha ora tansah (ing kasunyatan, meh ora tau) cepet. Lan amarga gerakan perusahaan sing terus-terusan, sawetara akuisisi sing padha bisa uga "ilang" nang endi wae. Lan ora pati penting kanggo nganggur. Yen administrator sing ati-ati ngelingi rak sing ora duwe duwe ing kamar server, mula yen tarif awan kabeh luwih sedhih. Padha bisa glethakaken munggah kanggo sasi - mbayar, nanging ing wektu sing padha ora perlu maneh ing departemen sing padha dituku. Ing wektu sing padha, kolega saka kantor sabanjure wiwit nyuwek rambute sing durung werna abu-abu ora mung ing sirahe, nanging uga ing panggonan liya - padha ora bisa mbayar tarif AWS sing padha kanggo minggu ke-n, sing dibutuhake banget.
Apa solusi sing paling jelas? Bener, pasrahake kendhali marang sing butuh, kabeh wong seneng. Nanging komunikasi horisontal ora tansah mapan. Lan departemen liya bisa uga ora ngerti babagan kasugihan pisanan, sing ora mbutuhake kasugihan kasebut.
Sapa sing kudu disalahake kanggo iki? - Bener, ora ana wong. Mangkono kabeh wis diatur kanggo saiki.
Sapa sing ngalami iki? - Mekaten, kabeh perusahaan.
Sapa sing bisa ndandani kahanan? - Ya, ya, FinOps.
FinOps ora mung lapisan antarane pangembang lan peralatan sing dibutuhake, nanging wong utawa tim sing bakal ngerti ing ngendi, apa lan kepiye "ngapusi" babagan tarif awan sing padha sing dituku dening perusahaan. Nyatane, wong-wong iki kudu kerja bareng karo DevOps, ing sisih siji, lan departemen keuangan ing sisih liyane, main peran minangka perantara sing efektif lan, sing paling penting, analis.
A sethitik babagan optimasi
awan-awan. Relatif murah lan trep banget. Nanging solusi iki mandheg dadi murah nalika jumlah server tekan kaping pindho utawa telung digit. Kajaba iku, awan bisa nggunakake layanan liyane lan liyane sing sadurunge ora kasedhiya: iki minangka basis data minangka layanan (Amazon AWS, Azure Database), aplikasi tanpa server (AWS Lambda, Azure Functions) lan liya-liyane. Kabeh iku keren banget amarga gampang digunakake - tuku lan lunga, ora ana masalah. Nanging luwih jero perusahaan lan proyeke terjun menyang awan, luwih elek CFO turu. Lan luwih cepet umum dadi abu-abu.
Kasunyatane yaiku invoice kanggo macem-macem layanan awan tansah mbingungake: kanggo siji item sampeyan bisa nampa panjelasan telung kaca babagan apa, ing ngendi lan kepiye dhuwit sampeyan. Iki, mesthi, nyenengake, nanging meh ora bisa dingerteni. Kajaba iku, panemu kita babagan masalah iki ora mung siji: kanggo nransfer akun maya menyang manungsa, ana kabeh layanan, umpamane. utawa . Yen ana sing keganggu nggawe layanan sing kapisah kanggo deciphering tagihan, mula ukuran masalah wis ngluwihi biaya pewarna rambut.
Dadi apa sing ditindakake FinOps ing kahanan iki:
- jelas ngerti kapan lan ing volume apa solusi awan dituku.
- ngerti carane kapasitas iki digunakake.
- redistributes mau gumantung ing kabutuhan unit tartamtu.
- ora tuku "supaya bisa".
- lan ing pungkasan, iku nyimpen dhuwit.
Conto sing apik yaiku panyimpenan maya saka salinan database sing adhem. Contone, apa sampeyan arsip kanggo ngurangi jumlah spasi lan lalu lintas sing digunakake nalika nganyari panyimpenan? Ya, kayane kahanan kasebut murah - ing kasus tartamtu, nanging totalitas kahanan sing murah kasebut bakal nyebabake biaya sing akeh banget kanggo layanan awan.
Utawa kahanan liyane: sampeyan tuku kapasitas cadangan ing AWS utawa Azure supaya ora tiba ing beban puncak. Apa sampeyan bisa yakin manawa iki minangka solusi sing paling optimal? Sawise kabeh, yen kedadeyan kasebut ora aktif 80%, mula sampeyan mung menehi dhuwit menyang Amazon. Kajaba iku, kanggo kasus kaya mengkono, AWS lan Azure padha duwe kedadean burstable - apa sampeyan kudu idling server, yen sampeyan bisa nggunakake alat kanggo ngatasi masalah beban puncak? Utawa, tinimbang On Premise instans, sampeyan kudu katon menyang Reserved - iku luwih murah lan uga menehi diskon.
Miturut cara, babagan diskon
Kaya sing wis dakkandhakake ing wiwitan, pengadaan asring ditindakake dening sapa wae - dheweke nemokake sing pungkasan, banjur dheweke nindakake dhewe. Paling asring, wong sing wis sibuk dadi "nemen", lan minangka asil, kita entuk kahanan ing ngendi wong kanthi cepet lan trampil, nanging kanthi mandiri, mutusake apa lan apa jumlah sing bakal dituku.
Nanging nalika sesambungan karo salesperson saka layanan maya, sampeyan bisa njaluk kahanan sing luwih sarujuk nalika nerangake tuku Grosir kapasitas. Cetha yen sampeyan ora bakal bisa entuk diskon saka mobil kanthi registrasi sing bisu lan siji-sisi - nanging sawise ngomong karo manajer penjualan sing nyata, sampeyan bisa uga kobong. Utawa wong lanang iki bisa ngomong apa sing saiki duwe diskon. Uga bisa migunani.
Ing wektu sing padha, sampeyan kudu ngelingi yen cahya ora converge kaya wedge ing AWS utawa Azure. Mesthi, ora ana pitakonan babagan ngatur kamar server sampeyan dhewe - nanging ana alternatif kanggo rong solusi klasik iki saka raksasa.
Contone, Google nggawa platform Firebase menyang perusahaan, sing bisa dadi tuan rumah proyek seluler sing padha kanthi basis turnkey, sing mbutuhake skala cepet. Panyimpenan, database wektu nyata, hosting lan sinkronisasi data awan nggunakake solusi iki minangka conto kasedhiya ing sak panggonan.
Ing sisih liya, yen kita ora ngomong babagan proyek monolitik, nanging babagan totalitas, mula solusi terpusat ora mesthi migunani. Yen proyek wis suwe, duwe riwayat pangembangan dhewe lan jumlah data sing cocog kanggo panyimpenan, mula kudu dipikirake babagan penempatan sing luwih akeh.
Nalika ngoptimalake biaya kanggo layanan maya, sampeyan bisa tiba-tiba nyadari yen kanggo aplikasi kritis bisnis sampeyan bisa tuku tarif sing luwih kuat sing bakal nyedhiyakake perusahaan kanthi penghasilan tanpa gangguan. Ing wektu sing padha, nyimpen "warisan" pembangunan, arsip lawas, database, lan liya-liyane ing awan sing larang minangka solusi. Sawise kabeh, kanggo data kasebut, pusat data standar kanthi HDD biasa lan hardware medium-daya tanpa lonceng lan whistles cukup cocog.
Ing kene maneh, sampeyan bisa uga mikir yen "kacilakan iki ora ana gunane," nanging kabeh masalah publikasi iki adhedhasar kasunyatan manawa ing macem-macem tahapan wong sing tanggung jawab nglirwakake perkara-perkara cilik lan nindakake apa sing luwih trep lan luwih cepet. Sing, ing pungkasan, sawise sawetara taun nyebabake akun sing medeni banget.
Apa ing pungkasan?
Umume, awan pancen keren, dheweke ngrampungake akeh masalah kanggo bisnis kanthi ukuran apa wae. Nanging, kedadean anyar iki tegese kita isih durung duwe budaya konsumsi lan manajemen. FinOps minangka tuas organisasi sing mbantu sampeyan nggunakake kekuwatan awan kanthi luwih efektif. Wangsulan: Bab ingkang utama - ora kanggo nguripake posisi iki minangka analog saka regu tembak, kang tugas bakal nyekel tangan pangembang inattentive lan "ngomong" kanggo downtime.
Pengembang kudu berkembang, ora ngitung dhuwit perusahaan. Dadi FinOps kudu nggawe proses tuku lan proses decommissioning utawa transfer kapasitas awan menyang tim liyane dadi acara sing gampang lan nyenengake kanggo kabeh pihak.
Source: www.habr.com