Projenizin altyapı maliyetinin ne kadar olduğunu mutlaka merak etmişsinizdir. Aynı zamanda şaşırtıcıdır: Maliyetlerdeki artış yüklere göre doğrusal değildir. Birçok işletme sahibi, servis istasyonu ve geliştirici gizlice fazla ödeme yaptıklarını anlıyor. Ama tam olarak ne için?
Tipik olarak maliyetleri azaltmak, en ucuz çözümü, bir AWS planını bulmaktan veya fiziksel raflar söz konusu olduğunda donanım yapılandırmasını optimize etmekten geçer. Sadece bu da değil: Aslında, Tanrı'nın istediği gibi herkes bunu yapıyor: Eğer bir startup'tan bahsediyorsak, o zaman bu muhtemelen baş ağrısı çeken lider bir geliştiricidir. Daha büyük ofislerde bu durum CMO/CTO tarafından ele alınır ve bazen genel müdür baş muhasebeciyle birlikte konuya bizzat müdahil olur. Genel olarak, yeterince "temel" endişeleri olan insanlar. Görünüşe göre altyapı faturaları artıyor ama bununla uğraşacak vakti olmayanlar bununla uğraşıyor.
Ofis için tuvalet kağıdı almanız gerekiyorsa bu, malzeme müdürü veya temizlik firmasından sorumlu bir kişi tarafından yapılacaktır. Geliştirmeden bahsediyorsak - potansiyel müşteriler ve CTO. Satışlar - her şey de açık. Ancak eski günlerden beri, "sunucu odası", biraz daha fazla RAM ve birkaç sabit disk içeren sıradan bir kule sistem biriminin bulunduğu bir kabine verilen isim olduğundan, herkes (veya en azından birçoğu) Satın alma kapasitesinin de özel eğitimli bir kişi tarafından ele alınması gerektiği gerçeğini göz ardı edin.
Ne yazık ki, tarihsel hafıza ve deneyimler, onlarca yıldır bu görevin "rastgele" insanlara kaydırıldığını gösteriyor: soruyu en yakında kim yanıtladıysa. Ve son zamanlarda FinOps mesleği piyasada şekillenmeye ve somut bir şekil almaya başladı. Bu, görevi kapasitenin satın alınmasını ve kullanımını kontrol etmek olan aynı özel eğitimli kişidir. Ve sonuçta şirketin bu alandaki maliyetlerini azaltmak.
Pahalı ve etkili çözümlerden vazgeçmeyi savunmuyoruz: Her işletme, donanım ve bulut tarifeleri açısından rahat bir yaşam için neye ihtiyacı olduğuna kendisi karar vermelidir. Ancak, birçok şirket için daha sonra kullanım izlemesi ve analizi yapılmadan "listeye göre" düşüncesiz satın almanın, arka uçlarının "varlıklarının" etkisiz yönetimi nedeniyle sonuçta çok, çok önemli kayıplarla sonuçlandığı gerçeğine dikkat etmeden geçilemez.
FinOps kimdir?
Diyelim ki satış elemanlarının nefes nefese "girişim"den bahsettiği saygın bir işletmeniz var. Muhtemelen, "listeye göre" bir düzine veya iki sunucu, AWS ve diğer bazı "küçük şeyler" satın aldınız. Mantıklı olan: Büyük bir şirkette sürekli olarak bir tür hareket oluyor - bazı ekipler büyüyor, diğerleri dağılıyor, diğerleri komşu projelere aktarılıyor. Ve bu hareketlerin "liste bazlı" satın alma mekanizmasıyla birlikte birleşimi, bir sonraki aylık altyapı faturasına bakıldığında sonuçta yeni gri saçlara yol açıyor.
Peki ne yapmalı - sabırla grileştirmeye devam edin, üzerini boyayın veya ödemede bu çok sayıda korkunç sıfırın görünmesinin nedenlerini mi anlayın?
Dürüst olalım: Şirket içindeki bir başvurunun aynı AWS tarifesi için onaylanması, onaylanması ve doğrudan ödemesinin yapılması her zaman (gerçekte neredeyse hiçbir zaman) hızlı olmuyor. Ve tam da sürekli kurumsal hareket nedeniyle, aynı satın almalardan bazıları bir yerlerde "kaybolabilir". Ve boş durmak önemsizdir. Özenli bir yönetici, sunucu odasında sahipsiz bir raf fark ederse, bulut tarifeleri söz konusu olduğunda her şey çok daha üzücü olur. Aylarca saklanabilirler; parası ödenir, ancak aynı zamanda satın alındıkları departmandaki hiç kimse tarafından artık ihtiyaç duyulmaz. Aynı zamanda, yan ofisteki meslektaşlar henüz grileşmemiş saçlarını sadece başlarından değil, başka yerlerde de yolmaya başlıyorlar - yaklaşık olarak aynı AWS tarifesini n'inci hafta için ödeyemediler. şiddetle ihtiyaç duyulmaktadır.
En bariz çözüm nedir? Doğru, dizginleri ihtiyacı olanlara verin, herkes mutlu olsun. Ancak yatay iletişim her zaman iyi kurulmamaktadır. Ve ikinci departman, bir şekilde bu servete gerçekten ihtiyaç duymadığı ortaya çıkan birincinin zenginliğini bilmiyor olabilir.
Bunun için kim suçlanacak? - Aslında hiç kimse. Şimdilik her şey bu şekilde ayarlandı.
Kim bundan muzdarip? - İşte bu kadar, tüm şirket.
Durumu kim düzeltebilir? - Evet, evet, FinOps.
FinOps yalnızca geliştiriciler ile ihtiyaç duydukları ekipman arasında bir katman değil, aynı zamanda şirket tarafından satın alınan aynı bulut tarifeleri açısından nerede, ne ve ne kadar iyi "yattığını" bilen bir kişi veya ekiptir. Aslında bu kişilerin bir yanda DevOps, diğer yanda finans departmanı ile birlikte çalışması ve etkili bir aracı ve en önemlisi analist rolünü oynaması gerekiyor.
Optimizasyon hakkında biraz
Bulutlar. Nispeten ucuz ve çok uygun. Ancak sunucu sayısı çift veya üç haneli rakamlara ulaştığında bu çözüm ucuz olmaktan çıkıyor. Ayrıca bulutlar, daha önce kullanılamayan daha fazla hizmetin kullanılmasını mümkün kılar: bunlar hizmet olarak veritabanları (Amazon AWS, Azure Database), sunucusuz uygulamalar (AWS Lambda, Azure Functions) ve diğerleridir. Hepsi çok havalı çünkü kullanımı kolay; satın al ve git, sorun yok. Ancak şirket ve projeleri bulutlara ne kadar derin düşerse, CFO'nun uykusu da o kadar kötü olur. Ve general ne kadar hızlı griye döner.
Gerçek şu ki, çeşitli bulut hizmetlerine ilişkin faturalar her zaman son derece kafa karıştırıcıdır: Bir öğe için paranızın neye, nereye ve nasıl gittiğine dair üç sayfalık bir açıklama alabilirsiniz. Bu elbette hoş ama bunu anlamak neredeyse imkansız. Üstelik bu konudaki görüşümüz tek olmaktan çok uzak: Bulut hesaplarını insanlara aktarmak için tüm hizmetler var, örneğin veya . Birisi faturaların şifresini çözmek için ayrı bir hizmet oluşturma zahmetine girdiyse, sorunun boyutu saç boyasının maliyetini aşmış demektir.
Peki FinOps bu durumda ne yapar:
- bulut çözümlerinin ne zaman ve hangi hacimlerde satın alındığını açıkça anlar.
- Bu kapasitelerin nasıl kullanıldığını bilir.
- bunları belirli bir birimin ihtiyaçlarına göre yeniden dağıtır.
- “Olsun diye” satın almaz.
- ve sonuçta paradan tasarruf etmenizi sağlar.
Harika bir örnek, bir veritabanının soğuk bir kopyasının bulutta depolanmasıdır. Örneğin, depolamayı güncellerken tüketilen alan miktarını ve trafiği azaltmak için arşivliyor musunuz? Evet, durum ucuz gibi görünüyor - tek bir özel durumda, ancak bu tür ucuz durumların toplamı daha sonra bulut hizmetleri için fahiş maliyetlerle sonuçlanıyor.
Veya başka bir durum: Yoğun yük altına girmemek için AWS veya Azure'da yedek kapasite satın aldınız. Bunun en uygun çözüm olduğundan emin olabilir misiniz? Sonuçta, eğer bu bulut sunucuları %80 boştaysa, o zaman sadece Amazon'a para veriyorsunuz demektir. Üstelik bu gibi durumlarda, aynı AWS ve Azure'un patlamaya hazır örnekleri vardır; yoğun yük sorunlarını çözecek bir araç kullanabiliyorsanız neden boş sunuculara ihtiyacınız olsun ki? Veya Şirket İçi bulut sunucuları yerine Rezerve bulut sunucularına bakmalısınız; çok daha ucuzdurlar ve aynı zamanda indirimler de sunarlar.
Bu arada, indirimler hakkında
Başlangıçta söylediğimiz gibi, satın alma genellikle herkes tarafından gerçekleştirilir - sonuncuyu buldular ve sonra bir şekilde bunu kendisi yapıyor. Çoğu zaman, zaten meşgul olan insanlar "aşırı" hale gelir ve sonuç olarak, bir kişinin hızlı ve ustaca, ancak tamamen bağımsız olarak neyi ve hangi miktarlarda satın alacağına karar verdiği bir durumla karşılaşırız.
Ancak bulut hizmetinden bir satış elemanı ile etkileşime geçtiğinizde, kapasitenin toptan satın alınması söz konusu olduğunda daha uygun koşullar elde edebilirsiniz. Sessiz ve tek taraflı kayıt olan bir arabadan bu tür indirimler alamayacağınız açıktır - ancak gerçek bir satış müdürüyle konuştuktan sonra tükenebilirsiniz. Veya bu adamlar size şu anda hangi indirimlerin olduğunu söyleyebilirler. Aynı zamanda faydalı da olabilir.
Aynı zamanda AWS veya Azure'da ışığın bir kama gibi birleşmediğini de hatırlamanız gerekir. Elbette kendi sunucu odanızı organize etmeniz söz konusu değil - ancak devlerin sunduğu bu iki klasik çözüme alternatifler var.
Örneğin Google, hızlı ölçeklendirme gerektirebilecek aynı mobil projeyi anahtar teslim olarak barındırabilecekleri Firebase platformunu şirketlere getirdi. Bu çözümü örnek olarak kullanarak depolama, gerçek zamanlı veritabanı, barındırma ve bulut veri senkronizasyonu tek bir yerde mevcuttur.
Öte yandan yekpare bir projeden değil de bunların bütünlüğünden bahsediyorsak, o zaman merkezi bir çözüm her zaman faydalı değildir. Proje uzun ömürlüyse, kendi geliştirme geçmişine ve depolama için gereken miktarda veriye sahipse, daha parçalı yerleşimi düşünmeye değer.
Bulut hizmetlerinin maliyetlerini optimize ederken, iş açısından kritik uygulamalar için şirkete kesintisiz kazanç sağlayacak daha güçlü tarifeler satın alabileceğinizi birdenbire fark edebilirsiniz. Aynı zamanda geliştirmenin “mirasını”, eski arşivleri, veritabanlarını vb. pahalı bulutlarda depolamak da bir çözümdür. Sonuçta, bu tür veriler için, normal HDD'lere ve herhangi bir zil ve ıslık sesi olmayan orta güçlü donanıma sahip standart bir veri merkezi oldukça uygundur.
Burada yine “bu yaygaraya değmez” diye düşünebilirsiniz, ancak bu yayının tüm sorunu, sorumlu kişilerin çeşitli aşamalarda küçük şeyleri ihmal etmesi, daha rahat ve daha hızlı olanı yapması gerçeğine dayanmaktadır. Bu da sonuçta birkaç yıl sonra o korkunç hikayelerle sonuçlanıyor.
Sonuç?
Genel olarak bulutlar harikadır, her büyüklükteki işletmenin birçok sorununu çözerler. Ancak bu olgunun yeni olması, hâlâ bir tüketim ve yönetim kültürüne sahip olmadığımız anlamına geliyor. FinOps, bulut gücünden daha etkili bir şekilde yararlanmanıza yardımcı olan organizasyonel bir kaldıraçtır. Önemli olan, bu pozisyonu, görevi dikkatsiz geliştiricileri elinden yakalamak ve kesinti nedeniyle onları "azarlamak" olacak bir idam mangası analoguna dönüştürmek değil.
Geliştiriciler şirket parasını saymamalı, geliştirmeli. Dolayısıyla FinOps'un hem satın alma sürecini hem de bulut kapasitesinin kullanımdan kaldırılması veya diğer ekiplere aktarılması sürecini tüm taraflar için basit ve eğlenceli bir olay haline getirmesi gerekiyor.
Kaynak: habr.com