Çok kullanıcılı çözümü güncelleştirmek için dikkat edilmesi gerekenler

Bulut teknolojisinin avantajlarından biri sürekli geliştirme ve gelişmedir. Hizmet sağlayıcısı olarak çözümünüze güncelleştirmeler uygulamanız gerekir: Azure altyapınız, kodunuz/uygulamalarınız, veritabanı şemanız veya başka herhangi bir bileşende değişiklik yapmak gerekebilir. Ortamlarınızı nasıl güncelleştirin planlayabilirsiniz? Çok kiracılı bir çözümde, kiracılardan bazıları ortamlarında değişikliklere izin verme konusunda isteksiz olabileceği veya hizmetini güncelleştirebilirsiniz zamanlarını sınırlayıcı gereksinimlere sahip olabileceği için güncelleştirme ilkenizin net olması özellikle önemlidir. Kiracıların gereksinimlerini tanımlamanız, hizmetinizi çalıştırmak için kendi gereksinimlerinizi netleştirmeniz, herkese uygun bir denge bulmanız ve bunu net bir şekilde iletişim kurmanız gerekir. Bu sayfada, teknik karar verenlere kiracı yazılımlarınızı güncelleştirmeyi düşünebilirsiniz yaklaşımlar ve ilgili takaslar hakkında rehberlik sağlarsınız.

Müşterilerin gereksinimleri

Aşağıdaki soruları göz önünde bulundurun:

  • Müşterileriniz ne zaman güncelleştirilebilir beklentilerine veya gereksinimlerine sahip? Bunlar sözleşmelerde veya hizmet düzeyi sözleşmelerde size resmi olarak iletildi veya resmi olmayan olabilir.
  • Müşterileriniz hizmet tanımlı veya kendi kendine tanımlanmış bakım pencerelerini bekliyor mu? Olası kesintiler hakkında kendi müşterilerine iletişim kurmaları gerekiyor olabilir.
  • Güncelleştirmelerin uygulanamadan önce ek onay gerektiren mevzuatla ilgili endişeleri var mı? Örneğin, IoT bileşenlerini içeren bir sağlık çözümü sağlarsanız, bir güncelleştirme uygulamadan önce Birleşik Devletler Gıda ve Ilaç Yönetimi'nin (XP) onayını alasınız.
  • Müşterilerinizden herhangi biri güncelleştirmelerin uygulanmasına özellikle duyarlı veya dayanıklı mı? Bunun neden olduğunu anlamaya çalış. Örneğin, fiziksel mağaza veya perakende web sitesi çalıştırıyorsa riskler olası avantajlardan daha yüksek olduğu için Efsane Cuma güncelleştirmelerden kaçınmak istiyor olabilir.
  • Güncelleştirmeleri müşterileriniz üzerinde herhangi bir etkisi olmadan başarıyla tamamlamayla ilgili kayıt kaydınız nedir? Kesinti olasılığını azaltmak DevOps, test etme, dağıtım ve izleme uygulamalarına iyi bir şekilde uymanız ve güncelleştirmelerin ortaya çıkarması gereken sorunları hızla tanımlamanız gerekir. Müşterileriniz ortamlarını sorunsuz bir şekilde güncelleştirenin, buna karşı daha az nesne oluşturma olasılığına sahip olduğunu biliyorsa.
  • Müşteriler, yeni bir değişiklik olursa güncelleştirmeleri geri almak ister mi?

Gereksinimleriniz

Ayrıca aşağıdaki soruları kendi bakış açınıza da düşünmeniz gerekir:

  • Güncelleştirmelerin ne zaman uygulanıyor olduğu müşterileriniz tarafından kontrol edilebilir mi? Büyük kurumsal müşteriler tarafından kullanılan bir çözüm inşa ediyorsanız, yanıt evet olabilir. Ancak, tüketici odaklı bir çözüm inşa ediyorsanız, çözüm yükseltme veya çalışma hakkında denetim verme ihtimaliniz düşük olabilir.
  • Tek bir anda çözümle ilgili kaç sürüme sahip olursunuz? Bir hata bulursanız ve düzeltmeniz gerekirse, düzeltmeyi kullanımda olan tüm sürümlere uygulamalısınız.
  • Müşterilerin geçerli sürümün çok gerisinde kalmalarına izin vermenin sonuçları nedir? Düzenli aralıklarla yeni özellikler yayımlarsanız eski sürümler hızla kullanılamaz mı? Ayrıca, yükseltme stratejinize ve değişiklik türlerine bağlı olarak, çözümle ilgili her sürüm için ayrı altyapılar sürdürmeniz gerekir. Bu nedenle, eski sürümler için destek sağlarken hem operasyonel hem de finansal maliyetler olabilir.
  • Dağıtım stratejiniz önceki sürümlere geri alma desteği sağlar mı? Etkinleştirmek istediğiniz bir şey mi?

Not

Güncelleştirmeler veya bakım için çözümlerinizi çevrimdışı duruma getirmeniz gerekip gerek olmadığını göz önünde bulundurabilirsiniz. Genel olarak, kesinti pencereleri eski bir uygulama olarak görülür ve modern DevOps uygulamaları ve bulut teknolojileri, güncelleştirmeler ve bakım sırasında kapalı kalma süresini önlemeye olanak sağlar. Bunun için tasarlamanız gerekir, bu nedenle çözüm mimarinizi tasarlarken güncelleştirme işleminizi göz önünde bulundurarak önemlidir. Kesintileri planlamasanız bile düzenli bir bakım penceresi tanımlamayı göz önünde bulundurabilirsiniz, böylece müşterileriniz değişikliklerin belirli zamanlarda olduğunu anlar. Sıfır kapalı kalma süresine sahip dağıtımlar elde etmek hakkında daha fazla bilgi için bkz. Sürüme alınan hizmet güncelleştirmeleri ile kapalı kalma süresine neden olmaz.

Bakiye bulma

Hizmet güncelleştirmelerinizi tamamen kiracıların takdirine bırakırsanız, hiçbir zaman güncelleştirmeyi seçebilirler. Bir yandan çözümlerinizi güncelleştirirken diğer yandan da müşterilerinizle ilgili makul endişeleri veya kısıtlamaları dikkate alamanıza olanak sağlamak önemlidir. Örneğin, bir müşteri Cuma günü yapılan güncelleştirmelere özellikle duyarlı ise (haftanın en yoğun günü olduğu için), çözümlerinizi etkilemeden güncelleştirmeleri Pazartesi günleri kolayca erteleyebiliyor musunuz?

İyi çalışebilecek yaklaşımlardan biri, aşağıda açıklanan yaklaşımlardan birini kullanarak güncelleştirmeleri kiracı bazında yapmaktır. Müşterinize planlı güncelleştirmeler hakkında bildirim verme. Müşterilerin geçici olarak devre dışı bırakmasına izin verme, ancak sonsuza kadar geri bırakmama; güncelleştirmenin ne zaman uygulanması gerektirecek? için makul bir sınır koymak.

Ayrıca, en az ön bildirimle veya hiç ön bildirimle kendinize güvenlik düzeltme ekleri veya diğer kritik düzeltmeleri dağıtma olanağı vermenizi de göz önünde bulundurabilirsiniz.

Bir diğer yaklaşım da kiracıların kendi güncelleştirmelerini seçtiklerinde başlatmalarına izin vermek olabilir. Bir kez daha son tarih sağlamanız gerekir. Bu noktada güncelleştirmeyi onların adına uygulayabileceksiniz.

Uyarı

Kiracıların kendi güncelleştirmelerini başlatmalarını sağlarken dikkatli olun. Bu uygulama karmaşıktır ve teslim etmek ve bakımını yapmak için önemli geliştirme ve test çalışmaları gerektirir.

Ne olursa olsun, özellikle güncelleştirmeler uygulanmadan önce ve uygulandıktan sonra kiracıların durumunu izleme işleminin olduğundan emin olun. Kritik üretim olayları (canlı site olayları olarak da adlandırılan)genellikle kod veya yapılandırma güncelleştirmeleri sonrasında meydana gelen olaylardır. Bu nedenle, müşterinin güvenini korumak için sorunları proaktif olarak izlemek ve yanıtlamak önemlidir. İzleme hakkında daha fazla bilgi için bkz. DevOps

Müşterilerinizle iletişim kurma

Net iletişim, müşterilerin güvenini sağlamak için çok önemli. Yeni özellikler, hata düzeltmeleri, güvenlik açıklarını çözme ve performans geliştirmeleri gibi düzenli güncelleştirmelerin avantajlarını açıklamanız önemlidir. Modern bir bulutta barındırılan çözümün avantajlarından biri, özelliklerin ve güncelleştirmelerin sürekli teslimidir.

Aşağıdaki soruları göz önünde bulundurun:

  • Yaklaşan güncelleştirmeleri müşterilere bildirecek misiniz?
  • Bunu yaparsanız, bir geri almayı geri almayı sağlayarak örtülü olarak izin mi talep ediyor olursunuz?
  • Güncelleştirmeleri uygulamak için kullanabileceğiniz zamanlanmış bir bakım pencereniz var mı?
  • Kritik bir güvenlik düzeltme eki gibi bir acil durum güncelleştirmeniz varsa ne olur? Bu gibi durumlarda güncelleştirmeleri zorlar mısınız?
  • Müşteriye gelecek güncelleştirmeleri proaktif olarak bildire değil, geçmişe dönük bildirimler smusunuz? Örneğin, web sitenize uygulanan güncelleştirmelerin listesiyle bir sayfayı güncelleştirebilirsiniz.

Müşteri destek takımıyla iletişim kurma

Kendi destek takımınız, her kiracıya uygulanmış güncelleştirmelere tam görünürlük sahibi olmak önemlidir. Müşteri destek temsilcileri aşağıdaki soruları kolayca yanıtlayaabiliyor olmalı:

  • Güncelleştirmeler yakın zamanda kiracının altyapısına uygulandı mı?
  • Bu güncelleştirmelerin doğası nedir?
  • Önceki sürüm nedir?
  • Güncelleştirmeler bu kiracıya ne sıklıkta uygulanır?

Bir güncelleştirmeden dolayı müşterilerinizden biri soruna sahipse, müşteri destek takımınıza nelerin değiştiğini anlamak için gereken bilgilere sahip olduğundan emin olun.

Güncelleştirmeleri desteklemek için dağıtım stratejileri

Altyapınıza güncelleştirmeleri nasıl dağıtacaklarını göz önünde bulundurabilirsiniz. Bu, sizin kullanmakta olduğu kira modelinden büyük ölçüde etkilenir. Güncelleştirmeleri dağıtmak için üç yaygın yaklaşım dağıtım damgaları, özellik bayrakları ve dağıtım halkalarıdır.

Her durumda, her kiracının hangi altyapı sürümünün, yazılımların veya özelliğin üzerinde olduğunu, nelere geçiş için uygun olduğunu ve bu durumlarla ilişkili zaman ile ilgili verileri bilmek için yeterli raporlama/görünürlük sahibi olduğundan emin olun.

Dağıtım damgaları

Bazı çok müşterili uygulamalar, uygulamanızın ve diğer bileşenlerinbirden çok kopyasını dağıtarak Dağıtım Damgaları düzenine uygundur. Yalıtım gereksinimlerinize bağlı olarak, her kiracı için bir damga pulu veya birden çok kiracının iş yükünü çalıştıran paylaşılan damga pulları dağıtebilirsiniz.

Damga pulları, kiracılar arasında yalıtım sağlamanın harika bir yolu. Ayrıca, güncelleştirmeleri başkalarını etkilemeden damgalar arasında aşamalı olarak dışarı çıkarabilirsiniz, çünkü güncelleştirme işleminiz için size esneklik sağlar.

Özellik bayrakları

Özellik bayrakları, yalnızca müşterileriniz veya kiracılar için bir alt kümeyi açığa çıkararak çözümünüze işlevsellik eklemenize olanak sağlar. Güncelleştirmeleri düzenli olarak dağıtırken yeni işlevleri göstermekten kaçınmak veya müşteri kabul olana kadar davranış değişiklikleri uygulamaktan kaçınmak için özellik bayraklarını kullanabilirsiniz.

Uygulamanıza kod yazarak veya uygulamanıza gibi bir hizmet kullanarak özellik bayrağı desteğini Azure Uygulama Yapılandırması.

Dağıtım halkaları

Dağıtım halkaları, güncelleştirmeleri bir dizi kiracı veya dağıtım damgası arasında aşamalı olarak dağıtmanızı sağlar. Her halkaya kiracıların bir alt kümesini attayın. Kanarya halkası, kendi test kiracılarınızı ve güncelleştirmeleri kullanılabilir olduğu anda almak isteyen müşterileri içerir. Daha sık güncelleştirmeler almayacaklarını ve güncelleştirmelerin diğer şeyler gibi kapsamlı bir doğrulama işlemiyle karşılanmayacaklarını anları. Erken benimseyen halka, biraz daha riskli olan ancak hala düzenli güncelleştirmeleri almaya hazırlanan kiracılar içerir. Kiracıların çoğu, daha az sıklıkta ve daha yüksek oranda test edilmiş güncelleştirmeler alan kullanıcı halkasına ait olur.

API sürümleri

Hizmetiniz bir dış API 'yi kullanıma sunarsa, uyguladığınız tüm güncelleştirmelerin müşterilerin veya iş ortaklarının Platformunuzla tümleştirilmesine yönelik olduğunu göz önünde bulundurun. Özellikle, API 'lerinizin üzerindeki değişiklikleri önemli bir şekilde bilmeniz gerekir. API 'niz için güncelleştirmelerin riskini azaltmak için BIR API sürüm oluşturma stratejisi kullanmayı düşünün.

Sonraki adımlar