VMware’in nasıl kurumsal BT’nin kontrol düzlemi haline geldiğinin sade bir özeti ve Broadcom mülkiyetiyle bütçeler, araçlar ve ekipler için nelerin değişebileceğine dair pratik bakış.
Bir hipervizör VM'leri çalıştırır. Bir kontrol düzlemi ise karar ve yönetişim katmanıdır ve şunları belirler:
Birçok işletmede vCenter “ilk tıklanan yer” haline gelir; bu yüzden sadece sanallaştırma aracı değil, kontrol düzlemi gibi davranır.
Çünkü operasyonel değer standartlaşma ve tekrarlanabilirlik üzerinde yoğunlaşır; yalnızca konsolidasyon değil. vSphere/vCenter genellikle ortak bir yüzey sağlar:
Bu alışkanlıklar yerleştiğinde, platformu değiştirmek sadece VM'lerin nerede çalıştığını değiştirmekle kalmaz, günlük operasyonları da etkiler.
Day‑2 operasyonlar, ilk dağıtımdan sonra takvimleri dolduran yinelenen görevlerdir. VMware merkezli bir ortamda tipik olarak şunları içerir:
Eğer çalışma rehberleriniz bu iş akışlarını varsayıyorsa, yönetim katmanı fiilen operasyonel sisteminizin bir parçasıdır.
Değişen varsayımlar ilk bozulduğunda bunlar genelde ilk başarısız olanlardır. Yaygın gizli bağımlılıklar şunlardır:
Bunları erken envantere alın ve yükseltmeler ya da pilotlar sırasında test edin—yenileme baskısı altındayken değil.
Genellikle önce teknoloji bozulmaz; ticari paketleme değişir. Ekiplerin en çok hissettiği değişiklikler şunlardır:
Bunu iki parçada ele alın: ürün değerini operasyonel olarak koruyun, ticari belirsizliği sözleşmesel olarak azaltın.
Müzakere konuşmalarının tahmin yürütmeden ibaret olmaması için bir gerçek taban oluşturun:
Kontrol düzlemi, kurtarmada görünürlük, izinler ve denetlenebilirlik sağlar. Bunlar değişirse iyileşme süresi uzayabilir çünkü müdahale edenler kontrol düzlemine güvenir:
Araçlar, roller veya iş akışları değişirse, MTTR'nin aynı kalmasını beklemeyin—yeniden eğitim, rol tasarımı ve güncellenmiş olay rehberleri planlayın.
Hayır, her zaman kötü değildir. Paketler satın almayı sadeleştirebilir ve dağıtımları standartlaştırabilir, ama değiş tokuşlar vardır:
Pratik adım: her paketle gelen bileşeni gerçek bir operasyonel ihtiyata (veya onu benimseme planına) eşleyin before kabul etmeden önce.
Belirsizseniz kısa vadede riski azaltıp zaman kazanın:
Bu adımlar kalın ya da ince politikaya bakmaksızın riski azaltır—kalıcı strateji ne olursa olsun.
Kontrollü bir pilot yapın ve sadece taşıma mekaniğini değil operasyonları da test edin:
Pilotu bir kezlik demo olarak değil, Day‑2 operasyonlarının provası olarak kabul edin—patching, izleme, yedekleme ve erişim kontrolü dahil.
Görünürlük: uyarılar, olay zaman çizelgeleri ve performans geçmişi.\n- İzinler: kim bir VM'yi güç döngüsüne sokabilir, iş yüklerini taşıyabilir veya ağı değiştirebilir.\n- Denetim izleri: ne değişti, ne zaman ve kim tarafından değiştirildiğini kanıtlama.\n\nBu iş akışları değişirse, ortalama onarım süresi de değişebilir.\n\n### Sadece bozulduğunda fark ettiğiniz gizli bağımlılıklar\n\nSanallaştırma nadiren yalnız çalışır. Yedekleme, izleme, felaket kurtarma, konfigürasyon yönetimi ve ticketing sistemleri vCenter ve API'larıyla sıkı entegredir. DR planları belirli replikasyon davranışlarını varsayabilir; yedekleme işleriniz anlık görüntülere dayanıyor olabilir; izleme etiketlere ve klasörlere bağımlı olabilir. Kontrol düzlemi değiştiğinde bu entegrasyonlar genellikle en erken “sürpriz” veren şeylerdir ve envanter ve test gerektirir.\n\n## Sahiplik Değişiklikleri: Önce Genellikle Neler Değişir\n\nVMware gibi merkezi bir platform sahipliği değiştiğinde, teknoloji bir gecede bozulmaz. İlk değişen genellikle etrafındaki ticari paketleme olur: nasıl satın aldığınız, nasıl yenilediğiniz ve bütçe ve destekte “normal” görünümün nasıl olduğu.\n\n### Ürün değerini ticari terimlerden ayırın\n\nBirçok ekip hala vSphere ve vCenter'dan operasyonel olarak büyük fayda sağlar—standartlaştırılmış sağlama, tutarlı operasyonlar ve tanıdık araç zinciri. Bu değer ticari terimler hızla değişse bile sabit kalabilir.\n\nBu ikisini ayrı konuşmalar olarak ele almak yardımcı olur:
Ürün değeri: platformun sağladığı faydalar (istikrar, otomasyon, yönetişim).\n- Ticari terimler: lisanslama metrikleri, paketler, destek seviyeleri, yenileme mekanikleri ve indirimler.\n\n### Neden sahiplik değişiklikleri fiyatlandırma ve paketlemeyi tetikler\n\nYeni sahiplik genellikle katalogu basitleştirme, ortalama sözleşme değerini artırma veya müşterileri daha az bundle'a kaydırma hedefi getirir. Bu şunlara dönüşebilir:
lisans metrikleri ve minimumlarındaki değişiklikler\n- bundle içeriğinin değişmesi (neyin “dahil” olduğu vs. eklenti olduğu)\n- destek hakları ve yanıt seviyeleri\n- yenileme zaman çizelgeleri ve sözleşme yapıları\n\n### Kurumsal kaygılar: yenilemeler ve öngörülebilirlik\n\nEn pratik endişeler genellikle sıkıcı ama gerçektir: “Gelecek yıl bunun maliyeti ne olacak?” ve “Çok yıllık öngörü elde edebilir miyiz?” Finans istikrarlı tahminler ister; BT ise yenilemenin aceleye getirilmiş mimari kararları zorlayıp zorlamayacağını bilmek ister.\n\n### Yenileme konuşmalarından önce toplanacaklar\n\nRakam konuşmadan önce temiz bir gerçek taban oluşturun:\n\n- Envanter: kümeler, hostlar, çekirdekler, editionlar ve hangi ortamların en önemli olduğu.\n- Kullanım gerçeği: gerçekten kullandığınız özellikler vs. sadece hak sahibi olduğunuz şeyler.\n- Sözleşmeler ve geçmiş: mevcut SKU'lar/bundle'lar, yenileme tarihleri, destek seviyesi, true-up şartları ve önceki tavizler.\n\nBunlarla müzakereye netlikle girebilirsiniz—kalma, çeşitlendirme veya taşınma planınız ne olursa olsun.
Böylece müzakereye netlikle girebilir ve alternatifleri gerçekçi bir kapsamla değerlendirebilirsiniz.
