Anda pasti tertanya-tanya berapa banyak kos infrastruktur projek anda. Pada masa yang sama, adalah mengejutkan: pertumbuhan kos tidak linear berkenaan dengan beban. Ramai pemilik perniagaan, stesen servis dan pemaju diam-diam memahami bahawa mereka membayar lebih. Tetapi untuk apa sebenarnya?
Lazimnya, pemotongan kos hanya datang untuk mencari penyelesaian termurah, pelan AWS, atau, dalam kes rak fizikal, mengoptimumkan konfigurasi perkakasan. Bukan itu sahaja: malah, sesiapa sahaja melakukan ini, mengikut kehendak Tuhan: jika kita bercakap tentang permulaan, maka ini mungkin pembangun terkemuka yang mengalami banyak pening kepala. Di pejabat yang lebih besar, perkara ini diuruskan oleh CMO/CTO, dan kadangkala pengarah besar secara peribadi terlibat dalam isu itu bersama ketua akauntan. Secara umum, mereka yang mempunyai kebimbangan "teras" yang mencukupi. Dan ternyata bil infrastruktur semakin meningkat, tetapi mereka yang tidak mempunyai masa untuk menanganinya sedang menanganinya.
Jika anda perlu membeli kertas tandas untuk pejabat, ini akan dilakukan oleh pengurus bekalan atau orang yang bertanggungjawab daripada syarikat pembersihan. Jika kita bercakap tentang pembangunan - petunjuk dan CTO. Jualan - semuanya juga jelas. Tetapi sejak zaman dahulu, apabila "bilik pelayan" adalah nama untuk kabinet di mana terdapat sistem menara biasa dengan lebih sedikit RAM dan beberapa cakera keras dalam serbuan, semua orang (atau sekurang-kurangnya ramai) mengabaikan hakikat bahawa pembelian kapasiti harus dikendalikan juga seorang yang terlatih khas.
Malangnya, ingatan dan pengalaman sejarah menunjukkan bahawa selama beberapa dekad tugas ini dialihkan kepada orang "rawak": sesiapa yang paling rapat menjawab soalan itu. Dan baru-baru ini profesion FinOps mula terbentuk di pasaran dan mengambil beberapa bentuk konkrit. Ini adalah orang yang sama terlatih khas yang tugasnya mengawal pembelian dan penggunaan kapasiti. Dan, akhirnya, dalam mengurangkan kos syarikat dalam bidang ini.
Kami tidak menganjurkan untuk meninggalkan penyelesaian yang mahal dan berkesan: setiap perniagaan mesti memutuskan sendiri perkara yang diperlukan untuk kewujudan yang selesa dari segi perkakasan dan tarif awan. Tetapi seseorang tidak boleh tidak memberi perhatian kepada fakta bahawa pembelian yang tidak bertimbang rasa "mengikut senarai" tanpa pemantauan dan analisis penggunaan berikutnya untuk banyak syarikat akhirnya mengakibatkan kerugian yang sangat, sangat besar disebabkan oleh pengurusan "aset" yang tidak berkesan dari bahagian belakang mereka.
Siapa FinOps
Katakan anda mempunyai perusahaan yang bereputasi, yang mana orang jualan bercakap tentang "perusahaan" dalam nada yang menarik. Mungkin, "mengikut senarai" anda membeli sedozen atau dua pelayan, AWS dan beberapa "perkara kecil" lain. Yang logik: dalam syarikat besar beberapa jenis pergerakan sentiasa berlaku - beberapa pasukan berkembang, yang lain hancur, yang lain dipindahkan ke projek jiran. Dan gabungan pergerakan ini, bersama-sama dengan mekanisme perolehan "berasaskan senarai", akhirnya membawa kepada uban baharu apabila melihat bil infrastruktur bulanan seterusnya.
Jadi apa yang perlu dilakukan - dengan sabar teruskan kelabu, cat di atasnya, atau fikirkan sebab munculnya banyak sifar yang mengerikan ini dalam pembayaran?
Sejujurnya: kelulusan, kelulusan dan pembayaran terus permohonan dalam syarikat untuk tarif AWS yang sama tidak selalu (sebenarnya, hampir tidak pernah) cepat. Dan tepat kerana pergerakan korporat yang berterusan, beberapa pengambilalihan yang sama ini mungkin "hilang" di suatu tempat. Dan ia adalah remeh untuk berdiri terbiar. Sekiranya pentadbir yang prihatin melihat rak tanpa pemilik di dalam bilik pelayannya, maka dalam hal tarif awan semuanya lebih menyedihkan. Mereka boleh disimpan selama berbulan-bulan - dibayar, tetapi pada masa yang sama tidak lagi diperlukan oleh sesiapa di jabatan yang mana mereka dibeli. Pada masa yang sama, rakan sekerja dari pejabat seterusnya mula mencabut rambut mereka yang belum uban bukan sahaja di kepala mereka, tetapi juga di tempat lain - mereka tidak dapat membayar lebih kurang tarif AWS yang sama untuk minggu ke-n, yang amat diperlukan.
Apakah penyelesaian yang paling jelas? Betul, serahkan tampuk kepada mereka yang memerlukan, dan semua orang gembira. Tetapi komunikasi mendatar tidak selalu mantap. Dan jabatan kedua mungkin tidak tahu tentang kekayaan yang pertama, yang entah bagaimana ternyata tidak benar-benar memerlukan kekayaan ini.
Siapa yang patut dipersalahkan dalam hal ini? - Sebenarnya, tiada siapa. Begitulah segala-galanya disediakan buat masa ini.
Siapa yang mengalami ini? - Itu sahaja, seluruh syarikat.
Siapa yang boleh membetulkan keadaan? - Ya, ya, FinOps.
FinOps bukan sekadar lapisan antara pembangun dan peralatan yang mereka perlukan, tetapi seseorang atau pasukan yang akan tahu di mana, apa dan sejauh mana ia "berbohong" dari segi tarif awan yang sama yang dibeli oleh syarikat. Malah, mereka ini mesti bekerja seiring dengan DevOps, di satu pihak, dan jabatan kewangan di pihak yang lain, memainkan peranan sebagai perantara yang berkesan dan, yang paling penting, penganalisis.
Sedikit tentang pengoptimuman
awan. Agak murah dan sangat selesa. Tetapi penyelesaian ini berhenti menjadi murah apabila bilangan pelayan mencapai dua atau tiga digit. Selain itu, awan memungkinkan untuk menggunakan lebih banyak perkhidmatan yang sebelum ini tidak tersedia: ini adalah pangkalan data sebagai perkhidmatan (Amazon AWS, Pangkalan Data Azure), aplikasi tanpa pelayan (AWS Lambda, Azure Functions) dan banyak lagi. Kesemuanya sangat keren kerana ia mudah digunakan - beli dan pergi, tiada masalah. Tetapi semakin dalam syarikat dan projeknya terjun ke awan, semakin teruk CFO tidur. Dan semakin cepat jeneral bertukar kelabu.
Hakikatnya ialah invois untuk pelbagai perkhidmatan awan sentiasa sangat mengelirukan: untuk satu item anda mungkin menerima penjelasan tiga halaman tentang apa, ke mana dan bagaimana wang anda pergi. Ini, tentu saja, menyenangkan, tetapi hampir mustahil untuk memahaminya. Selain itu, pendapat kami tentang isu ini jauh dari satu-satunya: untuk memindahkan akaun awan kepada manusia, terdapat keseluruhan perkhidmatan, contohnya atau . Sekiranya seseorang bersusah payah membuat perkhidmatan berasingan untuk mentafsir bil, maka skala masalahnya telah melebihi kos pewarna rambut.
Jadi apa yang FinOps lakukan dalam situasi ini:
- memahami dengan jelas bila dan dalam jumlah berapa penyelesaian awan dibeli.
- tahu bagaimana kapasiti ini digunakan.
- mengagihkannya semula bergantung pada keperluan unit tertentu.
- tidak membeli "supaya ia boleh".
- dan akhirnya, ia menjimatkan wang anda.
Satu contoh yang baik ialah penyimpanan awan salinan sejuk pangkalan data. Sebagai contoh, adakah anda mengarkibkannya untuk mengurangkan jumlah ruang dan trafik yang digunakan semasa mengemas kini storan? Ya, nampaknya keadaan itu murah - dalam satu kes tertentu, tetapi keseluruhan situasi murah tersebut kemudiannya mengakibatkan kos yang terlalu tinggi untuk perkhidmatan awan.
Atau situasi lain: anda membeli kapasiti rizab pada AWS atau Azure agar tidak jatuh di bawah beban puncak. Bolehkah anda yakin bahawa ini adalah penyelesaian yang optimum? Lagipun, jika keadaan ini terbiar 80%, maka anda hanya memberi wang kepada Amazon. Lebih-lebih lagi, untuk kes sedemikian, AWS dan Azure yang sama mempunyai keadaan boleh pecah - mengapa anda memerlukan pelayan melahu, jika anda boleh menggunakan alat untuk menyelesaikan masalah beban puncak? Atau, bukannya contoh Di Premis, anda harus melihat ke arah Reserved - ia jauh lebih murah dan ia juga menawarkan diskaun.
Dengan cara ini, mengenai diskaun
Seperti yang kita katakan pada mulanya, perolehan sering dilakukan oleh sesiapa sahaja - mereka mendapati yang terakhir, dan kemudian dia entah bagaimana melakukannya sendiri. Selalunya, orang yang sudah sibuk menjadi "melampau", dan akibatnya kita mendapat situasi di mana seseorang dengan cepat dan mahir, tetapi sepenuhnya bebas, memutuskan apa dan dalam kuantiti apa yang hendak dibeli.
Tetapi apabila berinteraksi dengan jurujual daripada perkhidmatan awan, anda boleh mendapatkan keadaan yang lebih baik apabila melibatkan pembelian borong kapasiti. Sudah jelas bahawa anda tidak akan dapat mendapatkan diskaun sedemikian daripada kereta dengan pendaftaran senyap dan berat sebelah - tetapi selepas bercakap dengan pengurus jualan sebenar, anda mungkin kehabisan tenaga. Atau lelaki ini boleh memberitahu anda apa yang mereka adakan diskaun pada masa ini. Ia juga boleh berguna.
Pada masa yang sama, anda perlu ingat bahawa cahaya tidak menumpu seperti baji pada AWS atau Azure. Sudah tentu, tidak ada persoalan untuk mengatur bilik pelayan anda sendiri - tetapi terdapat alternatif kepada dua penyelesaian klasik ini dari gergasi.
Sebagai contoh, Google membawa platform Firebase kepada syarikat, di mana mereka boleh mengehoskan projek mudah alih yang sama secara turnkey, yang mungkin memerlukan penskalaan pantas. Storan, pangkalan data masa nyata, pengehosan dan penyegerakan data awan menggunakan penyelesaian ini sebagai contoh tersedia di satu tempat.
Sebaliknya, jika kita tidak bercakap tentang projek monolitik, tetapi mengenai keseluruhannya, maka penyelesaian terpusat tidak selalu bermanfaat. Sekiranya projek itu bertahan lama, mempunyai sejarah pembangunannya sendiri dan jumlah data yang sepadan yang diperlukan untuk penyimpanan, maka adalah wajar memikirkan penempatan yang lebih berpecah-belah.
Apabila mengoptimumkan kos untuk perkhidmatan awan, anda mungkin tiba-tiba menyedari bahawa untuk aplikasi kritikal perniagaan anda boleh membeli tarif yang lebih berkuasa yang akan memberikan syarikat pendapatan tanpa gangguan. Pada masa yang sama, menyimpan "warisan" pembangunan, arkib lama, pangkalan data, dll dalam awan mahal adalah penyelesaian. Lagipun, untuk data sedemikian, pusat data standard dengan HDD biasa dan perkakasan kuasa sederhana tanpa sebarang loceng dan wisel adalah agak sesuai.
Di sini sekali lagi, anda mungkin berfikir bahawa "kekecohan ini tidak berbaloi," tetapi keseluruhan masalah penerbitan ini adalah berdasarkan fakta bahawa pada pelbagai peringkat orang yang bertanggungjawab mengabaikan perkara kecil dan melakukan apa yang lebih mudah dan lebih cepat. Yang, pada akhirnya, selepas beberapa tahun menghasilkan akaun yang sangat seram itu.
Hasilnya?
Secara umum, awan adalah sejuk, ia menyelesaikan banyak masalah untuk perniagaan dalam sebarang saiz. Namun, kebaruan fenomena ini bermakna kita masih belum mempunyai budaya penggunaan dan pengurusan. FinOps ialah tuas organisasi yang membantu anda memanfaatkan kuasa awan dengan lebih berkesan. Perkara utama bukanlah untuk mengubah kedudukan ini menjadi analog skuad penembak, yang tugasnya adalah untuk menangkap pemaju yang lalai dengan tangan dan "memarahi" mereka untuk masa henti.
Pemaju harus membangunkan, bukan mengira wang syarikat. Oleh itu, FinOps harus menjadikan kedua-dua proses pembelian dan proses penyahtauliahan atau pemindahan kapasiti awan kepada pasukan lain sebagai acara yang mudah dan menyeronokkan untuk semua pihak.
Sumber: www.habr.com