Yaygın bulut işletim modellerini gözden geçirme ve karşılaştırma

İşletim modelleri, geçerli gereksinimlerine ve kısıtlamalarına göre benzersizdir ve destekledikleri işletmeye özeldir. Ancak operasyon modelleri kar taneleri değildir. Müşteri operasyon modellerinde çeşitli yaygın desenler vardır; Bu makalede en yaygın dört desen özetlenmiştir.

İşletim modeli karşılaştırması

Aşağıdaki görüntü, en az karmaşık (merkezi olmayan) ve en karmaşık (küresel operasyonlar) arasında karmaşıklık aralığına göre ortak operasyon modellerini eşler. Aşağıdaki tablolarda, diğer birkaç özniteliğin göreli değerine göre aynı işletim modelleri karşılaştırmaktadır.

Öncelikler veya kapsam

Bulut çalışma modeli öncelikli olarak iki faktör tarafından yönlendirilir:

• Stratejik öncelikler veya motivasyonlar
• Yönetilecek portföyün kapsamı

	Merkezi olmayan işlemler (ops)	Merkezi işlemler (ops)	Kurumsal işlemler (ops)	Dağıtılmış işlemler (ops)
Stratejik öncelikler veya motivasyonlar	Yenilik	Denetim	Demokratikleşme	Tümleştirme
Portföy kapsamı	İş Yükü	Giriş bölgesi	Bulut platformu	Tam portföy
İş yükü ortamı	Yüksek karmaşıklık	Düşük karmaşıklık	Orta karmaşıklık	Orta veya değişken karmaşıklık
Giriş bölgesi	Yok	Yüksek karmaşıklık	Orta ve düşük karmaşıklık	Düşük karmaşıklık
Temel yardımcı programlar	Yok	Yok veya düşük destek	Merkezi ve daha fazla destek	Çoğu destek
Bulut temeli	Yok	Yok	Karma, sağlayıcıya özgü veya bölgesel temeller	Dağıtılmış ve eşitlenmiş

• Stratejik öncelikler veya motivasyonlar: Her operasyon modeli , bulutu benimsemeye yönelik tipik stratejik motivasyonları sunar. Ancak bazı operasyon modelleri belirli motivasyonları basitleştirir.

• Portföy kapsamı: Portföy kapsamı, belirli bir işletim modeli tasarımının desteklediği en büyük kapsamı tanımlar. Örneğin, merkezi işlemler birkaç giriş bölgesi için tasarlanmıştır. Ancak işletim modeli kararı bir kuruluş için operasyonel riskler oluşturabilir. Operasyonel riskler, büyük bir karmaşık portföyü yönetmeye çalışırken ortaya çıkan sonuçlardır. Bu portföyler, giriş bölgesi tasarımında birçok giriş bölgesi veya değişken karmaşıklık gerektirebilir.

Önemli

Bulutu benimsemek genellikle geçerli işletim modelinde yansımayı tetikler ve bir ortak işletim modelinden diğerine geçişe yol açabilir. Ancak tek tetikleyici bulut benimseme değildir. İş öncelikleri ve bulut benimseme kapsamı, portföyün desteklenme şeklini değiştirebilir. Ayrıca, en uygun şekilde hizalanmış işletim modelinde başka vardiyalar da olabilir. Yönetim kurulu veya diğer yönetici ekipler 5-10 yıllık iş planları geliştirirken, bu planlar genellikle çalışma modelini ayarlamak için bir gereksinim (açık veya zımni) içerir. İşletim modelleri, yol gösteren kararlar için iyi bir başvuru olur. Bu modeller değişebilir veya gereksinimlerinizi ve kısıtlamalarınızı karşılayacak şekilde özelleştirilmesi gerekebilir.

Sorumluluk uyumluluğu

Birçok ekip ve kişi farklı işlevleri desteklemekle sorumludur. Ancak her ortak operasyon modeli, karar sonuçları için son sorumluluğu bir ekibe veya bireye atar. Bu yaklaşım, işletim modelinin nasıl fonlandığını ve her işlev için hangi destek düzeyinin sağlandığını etkiler.

	Merkezi olmayan operasyonlar	Merkezi operasyonlar	Kurumsal operasyonlar	Dağıtılmış operasyonlar
İş uyumluluğu	İş yükü ekibi	Merkezi bulut stratejisi	CCoE	Değişken - geniş bir bulut stratejisi ekibi mi oluşturacak?
Bulut işlemleri	İş yükü ekibi	Merkezi BT	CCoE	Portföy analizine göre - bkz . İş uyumluluğu ve İş taahhütleri
Bulut idaresi	İş yükü ekibi	Merkezi BT	CCoE	Birden çok idare katmanı
Bulut güvenliği	İş yükü ekibi	Güvenlik işlemleri merkezi (SOC)	CCoE + SOC	Karma - bkz. Güvenlik stratejisi tanımlama
Bulut otomasyonu ve DevOps	İş yükü ekibi	Merkezi BT veya YOK	CCoE	Portföy analizine göre - bkz . İş uyumluluğu ve İş taahhütleri

Azure'da işletim modeli uygulamasını hızlandırma

İşletim modelinizi tanımlama bölümünde açıklandığı gibi, Bulut Benimseme Çerçevesi her metodolojisi işletim modelinizi geliştirmek için yapılandırılmış bir yol sağlar. Bu yöntemler, bulut çalışma modelini benimsemedeki boşluklardan kaynaklanan engelleri aşmanıza yardımcı olabilir.

Aşağıdaki tabloda, işletim modeli uygulamanızı hızlandırmanın yolları özetlenmiştir.

	Merkezi olmayan operasyonlar	Merkezi operasyonlar	Kurumsal operasyonlar	Dağıtılmış operasyonlar
Başlangıç noktası	Azure Well-Architected Framework (WAF)	Azure giriş bölgeleri: küçük başlangıç seçenekleri	Azure giriş bölgeleri: CAF kurumsal ölçekli	İş uyumluluğu
Yinelemeler	İş yüklerine odaklanmak, ekibin WAF içinde yineleme yapmasını sağlar.	Küçük başlangıç seçeneği her metodolojide daha fazla yineleme gerektirir, ancak bulut benimseme çalışmaları olgunlaştıkça yapılabilir.	Başvuru uygulamalarında gösterildiği gibi, gelecekteki yinelemeler genellikle küçük yapılandırma eklemelerine odaklanır.	İşlem temelinize en uygun seçenekle başlamak için Azure giriş bölgesi uygulama seçeneklerini gözden geçirin. Bu seçeneğin tasarım ilkelerinde tanımlanan yineleme yolunu izleyin.

Merkezi olmayan operasyonlar

İşlemler her zaman karmaşıktır. İşlemlerinizin kapsamını bir iş yüküyle veya küçük bir iş yükü koleksiyonuyla sınırlandırıyorsanız karmaşıklığı denetleyebilirsiniz. Merkezi olmayan operasyonlar, ortak operasyon modellerinin en az karmaşık olanıdır. Bu işlem biçiminde, tüm iş yükleri ayrılmış iş yükü ekipleri tarafından bağımsız olarak çalışır.

• Öncelikler: Ekibiniz, birden çok iş yükünde merkezi denetim veya standartlaştırma üzerinden yenilikleri ölçer.
• Ayrı bir avantaj: İş yükü ve iş ekiplerini tasarım, derleme ve operasyonlar için tam denetime yerleştirerek yenilik hızını en üst düzeye çıkarın.
• Ayrı dezavantajlar: İş yükleri arası standartlaştırmanın azaltılması, paylaşılan hizmetler aracılığıyla ölçek ekonomisi ve tutarlı idare merkezi uyumluluk çalışmaları.
• Risk: Bu yaklaşım, bir iş yükü portföyünü yönetirken risk oluşturur. İş yükü ekiplerinin merkezi BT işlevlerine ayrılmış özel ekipleri olabilir. Bu operasyon modeli, özellikle üçüncü taraf uyumluluk gereksinimlerini karşılaması gereken şirketler olmak üzere bazı kuruluşlar tarafından yüksek riskli bir seçenek olarak kabul edilir.
• Rehberlik: Merkezi olmayan işlemler iş yükü düzeyinde kararlar ile sınırlıdır. Microsoft Azure Well-Architected Framework, bu kapsamda alınan kararları destekler. Bulut Benimseme Çerçevesi içindeki işlemler ve yönergeler merkezi olmayan işlemler için gerekli olmayan ek yüke neden olabilir.

Merkezi olmayan operasyonların avantajları

• Maliyet yönetimi: Operasyon maliyeti tek bir iş birimiyle kolayca eşlenir. İş yüküne özgü işlemler daha fazla iş yükü iyileştirmeyi destekler.
• Sorumluluklar: Bu işlem biçimi genellikle ek yükü en aza indirmek için otomasyona bağımlıdır. Sorumluluklar, sürüm yönetimi için DevOps ve işlem hatlarına odaklanma eğilimindedir. Bu tür işlemler geliştirme sırasında daha hızlı dağıtımları ve daha kısa geri bildirim döngülerini destekler.
• Standartlaştırma: Ortamı yayından yayına standartlaştırmak için bir kaynak kodu ve dağıtım işlem hattı kullanın.
• İşlem desteği: İşlemleri etkileyen kararlar yalnızca bu iş yükünün gereksinimleriyle ilgilenir ve operasyon kararlarını basitleştirir. DevOps topluluğunun üyeleri, operasyon kapsamının daha dar olması nedeniyle operasyon desteğinin en saf işlem biçimi olduğunu söylüyor.
• Uzmanlık: DevOps ve geliştirme ekipleri bu yaklaşımdan en çok güç alır ve pazar değişikliğini yönlendirmeye karşı en az direnci yaşar.
• Giriş bölgesi tasarımı: Belirli bir operasyonel avantaj yoktur.
• Temel yardımcı programlar: Belirli bir operasyonel avantaj yoktur.
• Görev ayrımı: Belirli bir operasyonel avantaj yoktur.

Merkezi olmayan operasyonların dezavantajları

• Maliyet yönetimi: Kurumsal maliyetlerin hesaplanması zordur. Merkezi idare ekiplerinin olmaması, tekdüzen maliyet denetimleri veya iyileştirme uygulamayı zorlaştırır. Dağıtılan varlıklarda ve personel atamalarında her iş yükünün yinelemesi olabileceği için bu model büyük ölçekte maliyetli olabilir.
• Sorumluluklar: Merkezi desteğin olmaması, iş yükü ekibinin idare, güvenlik, operasyon ve değişiklik yönetiminden tamamen sorumlu olduğu anlamına gelir. Kod gözden geçirme ve yayın işlem hatlarında bu görevler otomatik hale alınmadığında destek eksikliği sorunludur.
• Standartlaştırma: Bir iş yükü portföyünde standartlaştırma değişken ve tutarsızdır.
• İşlem desteği: Birden çok iş yükünde en iyi yöntemler oluşturulurken ölçek verimlilikleri genellikle kaçırılır.
• Uzmanlık: Ekip üyelerinin uygulama tasarımı ve yapılandırması içinde idare, güvenlik, operasyonlar ve değişiklik yönetimi hakkında akıllıca ve etik kararlar alma sorumluluğu daha yüksektir. Gerekli uzmanlığı geliştirmek için sık sık Microsoft Azure Well-Architected İncelemesi ve Azure Well-Architected Çerçevesi'ne başvurun.
• Giriş bölgesi tasarımı: Giriş bölgeleri iş yüküne özgü değildir ve bu yaklaşımda dikkate alınmaz.
• Temel yardımcı programlar: İş yükleri arasında birkaç temel hizmet paylaşılarak ölçek verimlilikleri azaltılır.
• Görev ayrımı: DevOps ve geliştirme ekipleri için daha yüksek gereksinimler, bu ekiplerden yükseltilmiş ayrıcalıkların kullanımını artırır. Görev ayrımı gerekiyorsa, bu yaklaşımla çalışmak için DevOps olgunluğuna yoğun yatırım yapmanız gerekebilir.

Merkezi operasyonlar

Kararlı durum ortamları, mimariye veya tek tek iş yüklerinin farklı operasyonel gereksinimlerine odaklanma gerektirmeyebilir. Merkezi operasyonlar, öncelikli olarak kararlı durum iş yüklerinden oluşan teknoloji ortamları için norm olma eğilimindedir. Kararlı durum işlemlerine örnek olarak ticari kullanıma açık (COTS) uygulamalar veya yavaş yayın temposu olan iyi kurulmuş özel uygulamalar verilebilir. Değişiklik hızı düzenli güncelleştirmeler ve düzeltme ekleri tarafından belirlenirse, işlemlerin merkezileştirilmesi portföyünüzü yönetmenin etkili bir yolu olabilir.

• Öncelikler: Öncelikler, yenilikler üzerindeki merkezi denetimdir ve modern bulut operasyonlarına yönelik kültürel değişim üzerinde mevcut operasyonel süreçleri ölçer.
• Ayrı bir avantaj: Merkezileştirme ölçek ekonomisi, en iyi tür denetimleri ve standartlaştırılmış operasyonlar sunar ve bulut ortamıyla en iyi şekilde çalışır. Bu ortamlar, bulut işlemlerini mevcut operasyonlar ve süreçlerle tümleştirmek için belirli yapılandırmalara ihtiyaç duyar. Merkezileştirme, mimari karmaşıklığı ve uyumluluk gereksinimleri mütevazı olan birkaç yüz iş yükü portföyüyle en avantajlıdır.
• Ayrı dezavantajlar: Büyük bir iş yükü portföyünün taleplerini karşılamak için ölçeklendirme yapmak, üretim iş yükleri için operasyonel kararlar alan merkezi ekipleri önemli ölçüde zorlayabilir. Teknik varlıklar 1.000 VM, uygulama veya veri kaynağının ötesine ölçeklendirmeyi bekliyorsa, 18-24 ay içinde kurumsal bir model kullanmayı düşünebilirsiniz.
• Risk: Bu yaklaşım merkezileştirmeyi daha az sayıda abonelikle (genellikle bir üretim aboneliği) sınırlar. Bulut yolculuğunuzun ilerleyen bölümlerinde yeniden düzenleme yaparken önemli riskler söz konusudur ve benimseme planlarınızı etkileyebilir. Yeniden çalışmayı önlemek için segmentlere, ortam sınırlarına, kimlik araçlarına ve diğer temel öğelere odaklanmayı deneyin.
• Rehberlik: "Küçük başlat ve genişlet" geliştirme hızına uygun Azure giriş bölgesi uygulama seçenekleri, bir ses başlangıç noktası oluşturur. Benimseme çalışmalarını hızlandırmak için bu seçenekleri kullanabilirsiniz. Ancak başarılı olmak için, kabul edilebilir risk toleransları içinde erken benimseme çabalarına yol gösterecek net ilkeler oluşturun. Yöntemlerin yönetilmesi ve yönetilmesi, işlemleri paralel olarak olgun hale getirmek için süreçler oluşturulmasına yardımcı olur. Bu adımların izlenmesi, operasyonlar olgunlaştıkça riskin artmasına izin vermeden önce tamamlanması gereken aşama kapıları görevi görür.

Merkezi işlemlerin avantajları

• Maliyet yönetimi: Paylaşılan hizmetlerin birçok iş yükünde merkezileştirilmesi ölçek ekonomisi oluşturur ve yinelenen görevleri ortadan kaldırır. Merkezi ekipler, kuruluş genelindeki boyutlandırma ve ölçek iyileştirmeleri aracılığıyla maliyet azaltmalarını hızla uygulayabilir.
• Sorumluluklar: Merkezi uzmanlaşma ve standartlaştırma daha yüksek kararlılık, daha iyi operasyonel performans ve değişiklikle ilgili minimum kesintilere yol açabilir. Bu yaklaşım, iş yükü odaklı ekipler üzerindeki geniş beceri baskılarını azaltır.
• Standartlaştırma: Genel olarak, daha az yinelenen sistem veya görev olduğundan merkezi bir modelde standartlaştırma ve işlem maliyeti en düşük değerdir.
• İşlem desteği: Karmaşıklığı azaltmak ve işlemleri merkezileştirmek, daha küçük BT ekiplerinin operasyonları desteklemesini kolaylaştırır.
• Uzmanlık: Destekleyici ekiplerin merkezileştirilmesi, güvenlik, risk, idare ve operasyon uzmanlarının iş açısından kritik kararlar almalarını sağlar.
• Giriş bölgesi tasarımı: Merkezi BT, giriş bölgesi ve abonelik sayısını en aza indirerek karmaşıklığı azaltır. Giriş bölgesi tasarımları, geçiş süresini kısaltan önceki veri merkezi tasarımlarını taklit etme eğilimindedir. Benimseme ilerledikçe, paylaşılan kaynaklar ayrı bir aboneliğe veya platform temeline taşınabilir.
• Temel yardımcı programlar: Mevcut veri merkezi tasarımlarını buluta taşırken şirket içi araçları ve operasyonları taklit eden temel, paylaşılan hizmetler elde edilir. Şirket içi işlemler birincil operasyon modeliniz olduğunda, bu bir avantaj olabilir, ancak bazı dezavantajlara dikkat edin. Şirket içi operasyonlar geçiş süresini kısaltarak ölçek ekonomilerinden yararlanmakta ve şirket içi ile bulutta barındırılan iş yükleri arasında tutarlı operasyonel süreçleri desteklemektedir. Bu yaklaşım kısa vadeli karmaşıklığı ve çabayı azaltabilir ve daha küçük ekiplerin daha az öğrenme eğrisiyle bulut operasyonlarını desteklemesine olanak tanır.
• Görev ayrımı: Merkezi operasyonlarda görev ayrımı açıktır. Merkezi BT, üretim ortamlarının denetimini korur ve diğer takımların yükseltilmiş izinlerine olan ihtiyacı azaltır. Bu yaklaşım, yükseltilmiş ayrıcalıklara sahip hesap sayısını sınırlayarak ihlalleri azaltır.

Merkezi işlemlerin dezavantajları

• Maliyet yönetimi: Merkezi ekipler her zaman iş yükü düzeyinde etkili iyileştirmeler üretmek için iş yükü mimarilerini anlamaz. Bu anlayış eksikliği, iyi ayarlanmış iş yükü işlemlerinden kaynaklanan maliyet tasarrufu miktarını sınırlar. İş yükü mimarisinin tam olarak anlaşılmaması, iyi tasarlanmış bir iş yükünün performansını, ölçeğini ve diğer yapılarını etkileyen merkezi maliyet iyileştirmelerini etkileyebilir. Kurumsal maliyet değişikliklerini yüksek profilli iş yüklerine uygulamadan önce merkezi BT ekibinizin Microsoft Azure Well-Architected Gözden Geçirmesi'ni anlaması ve tamamlaması gerekir.
• Sorumluluklar: Üretim desteğini ve erişimini merkezileştirmek, birkaç kişiye yüksek operasyonel yük ve her birey üzerinde daha fazla baskı oluşturur. Bu kişilere yapılan baskılar, ayrıntılı güvenlik idaresi ve uyumluluk gereksinimlerine uygunluğu doğrulayan dağıtılan iş yükleri üzerinde daha derin incelemeler gerçekleştirme gereksinimine neden olur.
• Standartlaştırma: Merkezi BT yaklaşımları, merkezi BT personelinin doğrusal ölçeklendirmesi olmadan standartlaştırmayı ölçeklendirmeyi zor hale getirir.
• Operasyon desteği: Bu yaklaşımın en büyük dezavantajları, yenilikleri ölçen önemli ölçek ve vardiyalarla ilişkilidir.
• Uzmanlık: Geliştirici ve DevOps uzmanları, bu tür bir ortamda düşük değere veya çok kısıtlanmış olma riskiyle karşılanır.
• Giriş bölgesi tasarımı: Veri merkezi tasarımları, bulutla her zaman ilgili olmayan önceki yaklaşımların kısıtlamalarına dayanır. Bu yaklaşımın takip edilmesi, ortam segmentasyonunu yeniden düşünme ve yenilik fırsatlarını güçlendirme fırsatlarını azaltır. Giriş bölgesi segmentasyonunun olmaması ihlalin olası etkisini, idare ve uyumluluk uyumluluğunun karmaşıklığını artırır ve bulut yolculuğunda benimsemeyi engelleyebilir. Yukarıdaki riskler bölümüne bakın.
• Temel yardımcı programlar: Dijital dönüşüm sırasında bulut birincil çalışma modeli olabilir. Şirket içi operasyonlar için oluşturulan merkezi araçlar, operasyonları modernleştirme ve operasyonel verimlilikleri artırma fırsatlarını azaltır. Benimseme sürecinin erken aşamalarında operasyonları modernleştirmemek de bir seçenektir. Modernleştirme, bulut benimseme yolculuğunda bir platform temeli aboneliği oluşturularak elde edilebilir. Bu efor, gelişmiş planlama olmadan karmaşık, maliyetli ve zaman alıcı olabilir.
• Görev ayrımı: Merkezi operasyonlar genellikle iki yoldan birini izler ve her ikisi de yeniliği engelleyebilir.
  • 1. Seçenek: Merkezi BT dışındaki takımlara üretimi taklit eden geliştirme ortamlarına sınırlı erişim verilir. Bu seçenek denemeleri engeller.
  • 2. Seçenek: Ekipler desteklenmeyen ortamlarda geliştirir ve test eder. Bu seçenek dağıtım işlemlerini engeller ve dağıtım sonrası tümleştirme testlerini yavaşlatıyor.

Kurumsal operasyonlar

Kurumsal operasyonlar, tüm bulut işlemleri için önerilen hedef durumlardır. Kurumsal operasyonlar, karar ve sorumlulukları basitleştirerek denetim ve yenilik ihtiyacını dengeler. Merkezi BT, iş yükü ekiplerini destekleyen daha kolay bir bulut mükemmellik merkezi veya CCoE ekibiyle değiştirilir. CCoE ekibi, eylemlerini denetlemek veya sınırlamak yerine iş yükü ekiplerini kararlar konusunda sorumlu tutar. İş yükü ekiplerine, iyi tanımlanmış korumalar içinde yenilikleri yönlendirmek için daha fazla güç ve daha fazla sorumluluk verilir.

• Öncelikler: Öncelikler, teknik kararların demokratikleştirilmesidir. Teknik kararların demokratikleştirilmesi, daha önce merkezi BT tarafından tutulan sorumlulukları iş yükü ekiplerine kaydırır. Önceliklerde bu değişimi sağlamak için kararlar insan tarafından çalıştırılacak gözden geçirme süreçlerine daha az bağımlı hale gelir. Bu yaklaşım buluta özel araçları kullanarak otomatik gözden geçirmeyi, idareyi ve zorlamayı destekler.
• Ayrı bir avantaj: Ortamların segmentlere ayrılması ve görev ayrımı, denetim ve yenilik arasında denge sağlar. Merkezi işlemler, daha fazla uyumluluk ve kararlı durum işlemleri gerektiren veya daha büyük güvenlik risklerini temsil eden iş yüklerini korur. Buna karşılık, bu yaklaşım daha fazla yenilik gerektiren iş yüklerinin ve ortamların merkezi denetimini azaltmayı destekler. Daha büyük portföyler, denetim ve yenilik arasındaki dengede sorun yaşayabilir. Bu esneklik, operasyonel sorunlarda azalma ile binlerce iş yükünü ölçeklendirmeyi kolaylaştırır.
• Ayrı dezavantaj: Şirket içinde çalışan şeyler kurumsal bulut operasyonlarında iyi çalışmayabilir. İşlemlere yönelik bu yaklaşım birçok cephede değişiklik yapılmasını gerektirir. Denetim ve sorumluluktaki kültürel değişimler genellikle en büyük zorluk olarak karşı karşıyadır. Kültürel değişimleri izleyen operasyonel değişimler zaman alır ve uygulama, olgunlaşıp kararlı hale getirme çabalarını benimsemektedir. Mimari vardiyalar kararlı iş yüklerinde, araç vardiyaları ise kültürel, operasyonel ve mimari vardiyaları güçlendirmek ve desteklemek için gerekli olabilir. Bu vardiyalar için birincil bulut sağlayıcısına yönelik taahhütler gerekebilir. Bu değişikliklerden önce yapılan benimseme çalışmaları, tipik yeniden düzenleme çalışmalarının ötesine geçerek önemli bir yeniden çalışma gerektirebilir.
• Risk: Bu yaklaşım, değişiklik stratejisine yönetici taahhüdü gerektirir. Ayrıca teknik ekiplerden öğrenme eğrilerinin üstesinden gelme ve gerekli değişikliği sunma taahhüdü gerektirir. uzun vadeli avantajları görmek için iş, CCoE ve merkezi BT ile iş yükü ekipleri arasında uzun vadeli işbirliği yapılması gerekir.
• Rehberlik: Azure giriş bölgesi seçenekleri kurumsal ölçekli olarak tanımlanır. Bu seçenekler, Teknik değişikliklerin Azure'da buluta özel araçları kullanarak nasıl teslim olduğunu göstermek için başvuru uygulamaları sağlar. Kurumsal ölçekli yaklaşım, ekiplere bu uygulamalardan tam olarak yararlanmak için gereken operasyonel ve kültürel değişimlerde yol gösterir. Aynı yaklaşım, benimseme stratejinizi ve uyumluluk kısıtlamalarınızı karşılamak için ortamı yapılandırmak için başvuru mimarisini uyarlayabilir. Kurumsal ölçek uyguladığınızda, İdare ve Yönetme yöntemleri süreçlerin tanımlanmasına yardımcı olabilir. Bu süreçler, operasyonel gereksinimlerinizi karşılamak için uyumluluk ve operasyon özelliklerinizi genişletebilir.

Kurumsal operasyonların avantajları

• Maliyet yönetimi: Merkezi ekipler, portföyler arası iyileştirmeler üzerinde hareket eder ve daha derin iş yükü iyileştirmesi için tek tek iş yükü ekiplerini sorumlu tutar. İş yükü odaklı ekipler, bu kararların olumsuz bir maliyet etkisine sahip olduğunda karar verme ve netlik sağlama yetkisine sahiptir. Merkezi ekipler ve iş yükü ekipleri, maliyet kararları için doğru düzeyde sorumluluk paylaşır.
• Sorumluluklar: Merkezi ekipler, korumaları tanımlamak, zorunlu kılmak ve otomatikleştirmek için buluta özel araçlar kullanır. CCoE otomasyonu ve uygulamaları aracılığıyla iş yükü ekibi çalışmaları hızlandırılır. İş yükü ekipleri, yenilikleri teşvik etme ve bu korumalar içinde kararlar verme yetkisine sahip.
• Standartlaştırma: Merkezi korumalar ve temel hizmetler, tüm ortamlarda tutarlılık oluşturur.
• İşlem desteği: Merkezi operasyon desteği gerektiren iş yükleri, kararlı durum denetimleri olan ortamlara segmentlere ayrılmıştır. Segmentlere ayırma ve görev ayrımı, iş yükü ekiplerinin kendi özel ortamlarında operasyonel destek için sorumluluk almalarını sağlar. Otomatik buluta özel araçlar, merkezi operasyonel destek ile tüm ortamlar için en düşük işlem temelini sağlar.
• Uzmanlık: Güvenlik, risk, idare ve operasyon gibi temel hizmetleri merkezileştirmek, doğru merkezi uzmanlığı sağlar. Net süreçler ve korumalar, iş yükü ekiplerini daha ayrıntılı kararlar vermeleri için eğitir ve güçlendirir. Bu kararlar, personeli teknoloji ölçeğiyle doğrusal olarak ölçeklendirmeye gerek kalmadan merkezi uzmanların etkisini genişletir.
• Giriş bölgesi tasarımı: Giriş bölgesi tasarımı, portföyün gereksinimlerini çoğaltarak net güvenlik, idare ve sorumluluk sınırları oluşturur. Bu sınırlar, iş yüklerini bulutta çalıştırmak için gereklidir. Segmentasyon uygulamalarının, önceki veri merkezi tasarımlarının oluşturduğu kısıtlamalara benzemesi pek olası değildir. Kurumsal operasyonlarda giriş bölgesi tasarımı daha az karmaşıktır ve self servis talebinin daha hızlı ölçeklendirilmesine ve engellerin azaltılmasına olanak sağlar.
• Temel yardımcı programlar: Temel yardımcı programlar, platform temeli olarak bilinen ayrı merkezi denetimli aboneliklerde barındırılır. Merkezi araçlar daha sonra her giriş bölgesine hizmet hizmetleri olarak aktarılır. Temel yardımcı programların giriş bölgelerinden ayrılması, tutarlılığı ve ölçek ekonomisini en üst düzeye çıkarır. Bu yardımcı programlar ayrıca merkezi olarak yönetilen sorumluluklar ile iş yükü düzeyi sorumlulukları arasında net ayrımlar oluşturur.
• Görev ayrımı: Temel hizmetler ve giriş bölgeleri arasında net görev ayrımı, operasyon yaklaşımının en büyük avantajlarından biridir. Buluta özel araçlar ve süreçler, merkezi ekiplerle iş yükü ekipleri arasında erişimi ve uygun denetim dengesini destekler. Bu yaklaşım, giriş bölgesi segmentlerinde barındırılan tek tek giriş bölgelerinin ve iş yüklerinin gereksinimlerini temel alır.

Kurumsal operasyonların dezavantajları

• Maliyet yönetimi: Merkezi ekipler, giriş bölgelerinde üretim değişiklikleri yapmak için iş yükü ekiplerine daha bağımlıdır. Bu değişiklik olası bütçe taşması ve gerçek harcamaların daha yavaş doğru boyutlandırılması için bir risk oluşturur. Maliyet sürprizlerinden kaçınmak için maliyet denetimi süreçleri, net bütçeler, otomatik denetimler ve düzenli incelemeler erken yapılmalıdır.
• Sorumluluklar: Kurumsal operasyonlar daha fazla kültürel ve operasyonel gereksinim gerektirir. Bu gereksinimler, merkezi ekipler ile iş yükü ekipleri arasında sorumlulukların ve sorumluluğun net olmasını sağlar.
• Geleneksel değişiklik yönetimi süreçleri veya değişiklik danışma panoları (kabinler), bu çalışma modelinde gereken hızı ve dengeyi korumayabilir. Bu süreçler, bulut benimsemeyi güvenli bir şekilde ölçeklendirin süreçleri ve yordamları otomatikleştirmeye yansıtılır.
• Değişiklik taahhüdü eksikliği, sorumlulukların müzakere ve uyum içinde önce gerçekleştirilmesine neden olabilir. Sorumluluktaki vardiyalara uyum sağlayamama, merkezi BT çalışma modellerinin kısa vadeli bulut benimseme çalışmaları sırasında gerekli olabileceğinin bir göstergesidir.
• Standartlaştırma: Merkezi korumalara veya otomasyona yatırım yapılmaması, el ile gözden geçirme süreçleriyle üstesinden gelmek daha zor olan standartlaştırma riskleri oluşturur. Giriş bölgelerindeki iş yükleri ile paylaşılan hizmetler arasındaki operasyonel bağımlılıklar daha fazla risk oluşturur. Bu riskler, yükseltme döngüleri veya temel yardımcı programların gelecekteki sürümleri sırasında standartlaştırmanın kapsamını genişletir. Platform temeli düzeltmeleri sırasında, desteklenen tüm giriş bölgeleri ve barındırdıkları iş yükleri için geliştirilmiş ve hatta otomatikleştirilmiş test gereklidir.
• İşlem desteği: Otomasyon ve merkezi işlemler aracılığıyla sağlanan işlem temeli, düşük etki veya düşük kritikliğe sahip iş yükleri için yeterli olabilir. Ancak iş yükü ekipleri veya diğer ayrılmış işlem biçimleri karmaşık veya yüksek öneme sahiptir iş yükleri için gerekli olabilir. Bu durumda, operasyon bütçelerinde bir değişime neden olabilir ve iş birimlerinin bu gelişmiş operasyon biçimlerine işletim giderleri vermesini gerektirir. Operasyon maliyetinden tek sorumluluğu korumak için merkezi BT gerekiyorsa kurumsal işlemlerin uygulanması zor olabilir.
• Uzmanlık: Merkezi BT ekibi üyelerinin daha önce el ile gerçekleştirilen işlemler aracılığıyla teslim edilen merkezi denetimleri otomatikleştirme konusunda uzmanlık geliştirmeleri gerekebilir. Ayrıca bu ekipler ortamı tanımlamaya yönelik kod olarak altyapı yaklaşımları geliştirebilir ve dallanma, birleştirme ve dağıtım işlem hatlarını anlayabilir. Platform otomasyonu ekibinin en azından bulut mükemmellik merkezi veya merkezi operasyon ekipleri tarafından alınan kararları anlamak için karar alma becerilerine ihtiyacı olabilir. İş yükü ekiplerinin kararlarını yöneten denetimler ve süreçlerle ilgili daha fazla bilgi geliştirmeleri gerekebilir.
• Giriş bölgesi tasarımı: Giriş bölgesi tasarımı temel yardımcı programlara bağlıdır. İş yükü ekipleri tasarımda neler olduğunu ve nelerin dahil edilmesi yasak olduğunu anlamalıdır. Bu anlayış, çabaların, hataların veya çakışmaların çoğaltılmasını önlemeye yardımcı olabilir. Esneklik oluşturmak için giriş bölgesi tasarımlarınızda özel durum işlemlerini dikkate alabilirsiniz.
• Temel yardımcı programlar: Temel yardımcı programların merkezileştirilmesi zaman alır. Bu yardımcı programlar sonunda seçenekleri dikkate alır ve çeşitli benimseme planlarını karşılayacak şekilde ölçeklendirilebilecek çözümler geliştirir. Erken benimseme çabalarında gecikmeler mümkündür. İşlemin ilerleyen bölümlerinde ivmelenmeler ve engelleyici kaçınma nedeniyle gecikmeler uzun vadede dengelenebilir.
• Görev ayrımı: Görevlerin net bir şekilde ayrılmasını sağlamak için olgun kimlik yönetimi süreçleri gerekir. Kullanıcıların, grupların, ekleme ve çıkarma etkinliklerinin düzgün hizalanmasıyla ilişkili daha fazla bakım olabilir. Yükseltilmiş ayrıcalıklar aracılığıyla tam zamanında erişim sağlamak için yeni işlemleri benimsemeniz gerekebilir.

Dağıtılmış operasyonlar

Mevcut işletim modeli, kuruluşun tamamı için yeni bir işletim modeline geçemeyecek kadar fazla oyulabilir. Diğerleri için, genel operasyonlar ve çeşitli uyumluluk gereksinimleri belirli iş birimlerinin değişiklik yapmasını engelleyebilir. Bu durumda, dağıtım işlemleri yaklaşımı gerektirebilir. Daha önce bahsedilen işletim modellerinden birinin veya daha fazlasının tümleştirilmesi gerektiğinden bu yaklaşım açık ara en karmaşık yaklaşımdır.

Bu işlem yaklaşımı bazı kuruluşlar için büyük ölçüde önerilmez. Yaklaşım temel olarak, farklı iş birimleri, farklı müşteri segmentleri tabanı veya bölgesel operasyonlardan oluşan gevşek bir koleksiyona sahip olan kuruluşlarla ilgilidir.

• Öncelikler: Birden çok mevcut işletim modeli tümleştirin.
• Kuruluşun tamamını daha önce bahsedilen işletim modellerinden birine taşımaya odaklanan geçiş durumu.
• Kuruluş tek bir çalışma modeliyle uyumlu hale getirmek için çok büyük veya çok karmaşık olduğunda uzun vadeli operasyonel yaklaşım.
• Ayrı bir avantaj: Her bir iş biriminden ortak çalışma modeli öğelerini tümleştirin. Bu yaklaşım, operasyon birimlerini tutarlı tekrarlanabilir işlemler kullanarak olgun hale getirmelerine yardımcı olan bir hiyerarşide gruplandırmak için bir araç oluşturur.
• Ayrı dezavantaj: Birden çok işletim modeli arasında tutarlılık ve standartlaştırmanın uzun süreler boyunca sürdürülmesi zordur. Bu operasyonel yaklaşım, portföyün ve teknoloji portföyünün çeşitli segmentlerinin nasıl çalıştığı hakkında derin bir farkındalık gerektirir.
• Risk: Birincil operasyon modeline bağlılık eksikliği takımlar arasında karışıklığa yol açabilir. Tek bir işletim modeline hizalamanın hiçbir yolu olmadığında bu işletim modelini kullanın.
• Rehberlik: İş hizalama makalelerinde açıklanan yaklaşımı kullanan portföyün kapsamlı bir incelemesiyle başlayın. Portföyü durum çalışma modeline (merkezi olmayan, merkezi veya kuruluş) göre gruplandırmayı deneyin.
• İşletim modeli gruplandırmalarını yansıtan bir yönetim grubu hiyerarşisi geliştirin. Bu düzenleme, iş yükü kümelerini en az ortak olandan en yaygın demetlere eşleyen bölge, iş birimi veya diğer ölçütler için diğer kuruluş desenlerini içerir.
• başlangıç olarak en uygun işletim modeli kümesini bulmak için iş yüklerinin işletim modellerine hizalamasını değerlendirin. Düğüm ve yönetim grubu hiyerarşisi altındaki tüm iş yükleri için işletim modeline eşlenen yönergeleri izleyin.
• Hiyerarşinin çeşitli noktalarında gerekli operasyonel yönetim uygulamaları da dahil olmak üzere ortak şirket ilkelerini bulmak için İdare ve Yönetim yöntemlerini kullanın. Paylaşılan şirket ilkelerini otomatikleştirmek için yaygın Azure ilkeleri uygulayın.
• Azure ilkelerini çeşitli dağıtımlarla test ettikçe, bunları yönetim grubu hiyerarşisinde daha yükseğe taşımayı denersiniz. İlkeler birçok iş yüküne uygulanabilir ve bu da yaygınlıkları ve farklı işlem gereksinimlerini bulabilir.
• Zaman içinde, bu yaklaşım çeşitli işletim modellerinde ölçeklendirilen bir model tanımlamanıza yardımcı olabilir. Bu yaklaşım, bir dizi ortak ilke ve yordam aracılığıyla ekipleri de bir hale getirebilir.

Bu yaklaşımın avantajları ve dezavantajları kasıtlı olarak boş. Portföyünüzün iş hizalamasını tamamladıktan sonra avantajları ve dezavantajları netleştirmek için yukarıdaki baskın çalışma modeli bölümüne bakın.

Sonraki adımlar

İşletim modelleriyle ilişkili terminolojiyi öğrenin. Terminoloji, bir operasyon modelinin kurumsal planlamanın daha büyük temasına nasıl uyduğunu anlamanıza yardımcı olur.

İşlem modeli terminolojisi

Giriş bölgelerinin her türlü bulut benimseme ortamında temel yapı taşlarını nasıl sağladığını öğrenin.

Giriş bölgesi nedir?