Aracılığıyla paylaş

Çok kiracılı çözümü güncelleştirme konusunda dikkat edilmesi gerekenler

  • Makale

Bulut teknolojisinin avantajlarından biri sürekli geliştirme ve evrimdir. Hizmet sağlayıcısı olarak çözümünüzde güncelleştirmeleri uygulamanız gerekir: Azure altyapınızda, kodlarınızda/uygulamalarınızda, veritabanı şemalarınızda veya diğer bileşenlerde değişiklik yapmanız gerekebilir. Ortamlarınızı nasıl güncelleştirdiğinizde planlama yapmak önemlidir. Çok kiracılı bir çözümde, bazı kiracılarınız ortamlarında değişikliklere izin vermek istemeyebileceği veya hizmetlerini güncelleştirebileceğiniz koşulları sınırlayan gereksinimleri olabileceğinden, güncelleştirme ilkeniz hakkında net olmanız özellikle önemlidir.

Çözümünüzü güncelleştirmek için bir strateji planlarken şunları yapmanız gerekir:

  • Kiracılarınızın gereksinimlerini belirleyin.
  • Hizmetinizi çalıştırmak için kendi gereksinimlerinizi netleştirin.
  • Hem sizin hem de kiracılarınızın kabul edebildiği bir bakiye bulun.
  • Stratejinizi kiracılarınıza ve diğer paydaşlara net bir şekilde iletin.

Bu makalede, teknik karar alıcılara kiracılarınızın yazılımını güncelleştirmek için göz önünde bulundurabileceğiniz yaklaşımlar ve ilgili dezavantajlar hakkında rehberlik sağlıyoruz.

Müşterilerinizin gereksinimleri

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

  • Beklentiler ve gereksinimler: Müşterilerinizin güncelleştirilebilecekleri zamanlarla ilgili beklentileri veya gereksinimleri var mı? Bunlar sözleşmelerde veya hizmet düzeyi sözleşmelerinde size resmi olarak iletilebilir veya resmi olmayabilir.
  • Bakım pencereleri: Müşterileriniz hizmet tanımlı, hatta kendi kendine tanımlanmış bakım pencereleri bekliyor mu? Olası kesintiler hakkında kendi müşterilerine iletişim kurmaları gerekebilir.
  • Yönetmelik: Müşterilerinizin güncelleştirmelerin uygulanabilmesi için 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 İlaç İdaresi'nden (FDA) onay almanız gerekebilir.
  • Duyarlılık: Müşterilerinizden herhangi biri güncelleştirmelerin uygulanmasına özellikle duyarlı veya dayanıklı mıdır? Nedenini anlamaya çalışın. Örneğin, fiziksel bir mağaza veya perakende web sitesi çalıştırıyorlarsa, riskler olası avantajlardan daha yüksek olduğundan Black Friday güncelleştirmelerinden kaçınmak isteyebilirler.
  • Geçmiş: Müşterilerinizi etkilemeden güncelleştirmeleri başarıyla tamamlama kaydınız nedir? Kesinti olasılığını azaltmak ve güncelleştirmelerin neden olduğu sorunları hızla tanımladığınızdan emin olmak için iyi DevOps, test, dağıtım ve izleme uygulamalarını izlemeniz gerekir. Müşterileriniz ortamlarını sorunsuz bir şekilde güncelleştiremediğinizi biliyorsa, itiraz etme olasılıkları daha düşüktür.
  • Geri alma: Hataya neden olan bir değişiklik olduğunda müşteriler güncelleştirmeleri geri almak ister mi?

Gereksinimleriniz

Ayrıca aşağıdaki soruları kendi bakış açınızdan da değerlendirmeniz gerekir:

  • Sağlamak istediğiniz denetim: Müşterilerinizin güncelleştirmelerin ne zaman uygulanacağını denetlemesi mantıklı mı? Büyük kurumsal müşteriler tarafından kullanılan bir çözüm oluşturuyorsanız yanıt evet olabilir. Ancak, tüketici odaklı bir çözüm oluşturuyorsanız, çözümünüzü yükseltme veya çalıştırma konusunda herhangi bir denetim verme olasılığınız düşüktür.
  • Sürüm: Çözümünüzün kaç sürümünü bir kerede makul bir şekilde koruyabilirsiniz? Bir hata bulursanız ve düzeltmeniz gerekirse, düzeltmeyi kullanımdaki tüm sürümlere uygulamanız gerekebileceğini unutmayın.
  • Eski sürümlerin sonuçları: Müşterilerin geçerli sürümün çok gerisinde kalmalarını sağlamak nasıl bir etki sağlar? Yeni özellikleri düzenli aralıklarla yayınlarsanız, eski sürümler hızla kullanımdan kalkacak mı? Ayrıca, yükseltme stratejinize ve değişiklik türlerine bağlı olarak, çözümünüzün her sürümü için ayrı altyapılar bulundurmanız gerekebilir. Bu nedenle, eski sürümler için destek sürdürürken hem operasyonel hem de finansal maliyetler olabilir.
  • Geri alma: Dağıtım stratejiniz önceki sürümlere geri almayı destekleyebilir mi? Bu etkinleştirmek istediğiniz bir şey mi?

Not

Güncelleştirmeler veya bakım için çözümünüzü çevrimdışına almanız gerekip gerekmediğini göz önünde bulundurun. Kesinti pencereleri genellikle 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 önlemenizi sağlar. Ancak sıfır kapalı kalma süresi dağıtımları tasarlamanız gerektiğinden, çözüm mimarinizi planlarken güncelleştirme sürecinizi göz önünde bulundurmanız önemlidir.

Güncelleştirme işleminiz sırasında kesintileri planlamasanız bile düzenli bir bakım penceresi tanımlamayı düşünebilirsiniz. Pencere, belirli zamanlarda değişikliklerin gerçekleştiğini müşterilerinizle iletişim kurmanıza yardımcı olabilir.

Sıfır kapalı kalma süresi dağıtımlarına ulaşma hakkında daha fazla bilgi için bkz. Sürümlü hizmet güncelleştirmeleri aracılığıyla kapalı kalma süresini ortadan kaldırma.

Bakiye bulma

Hizmet güncelleştirmelerinizin temposunu tamamen kiracılarınızın takdirine bırakırsanız, hiçbir zaman güncelleştirmemeyi tercih edebilir. Müşterilerinizin sahip olabileceği makul endişeleri veya kısıtlamaları dikkate alırken çözümünüzü güncelleştirmenize izin vermek önemlidir. Örneğin, bir müşteri haftanın en yoğun günü olduğu için Cuma günkü güncelleştirmelere özellikle duyarlıysa, çözümünüzü etkilemeden güncelleştirmeleri Pazartesi günlerine kadar kolayca erteleyebilir misiniz?

İyi çalışabilen yaklaşımlardan biri, aşağıda açıklanan yaklaşımlardan birini kullanarak güncelleştirmeleri kiracı temelinde kullanıma sunmadır. Müşterinize planlı güncelleştirmeler konusunda bildirimde bulunur. Müşterilerin geçici olarak geri çevirmesine izin verin, ancak sonsuza kadar geri çevirmesin; güncelleştirmenin uygulanmasını ne zaman gerektireceğini makul bir sınır koyabilirsiniz.

Ayrıca, en az önceden bildirimle veya hiç bildirimde bulunmadan güvenlik düzeltme eklerini veya diğer kritik düzeltmeleri dağıtma olanağını da göz önünde bulundurun.

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

Uyarı

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

Ne yapıyorsanız yapın, özellikle güncelleştirmeler uygulanmadan önce ve uygulandıktan sonra kiracılarınızın durumunu izleme işleminiz olduğundan emin olun. Kritik üretim olayları ( canlı site olayları olarak da adlandırılır) genellikle kod veya yapılandırma güncelleştirmelerinden sonra gerçekleşir. Bu nedenle, müşteri güvenini korumak için sorunları proaktif olarak izlemeniz ve yanıtlamanız önemlidir. İzleme hakkında daha fazla bilgi için bkz. DevOps için İzleme.

Müşterilerinizle iletişim kurma

Net iletişim, müşterilerinizin güvenini geliştirmenin anahtarıdır. Yeni özellikler, hata düzeltmeleri, güvenlik açıklarını çözme ve performans geliştirmeleri dahil olmak üzere düzenli güncelleştirmelerin avantajlarını açıklamak önemlidir. Modern bir bulutta barındırılan çözümün avantajlarından biri, özelliklerin ve güncelleştirmelerin sürekli teslim edilmesidir.

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

  • Müşterilere yaklaşan güncelleştirmeleri bildirecek misiniz?
  • Bunu yaparsanız, bir geri çevirme işlemi sağlayarak örtük olarak izin ister misiniz ve geri çevirmenin sınırları nelerdir?
  • Güncelleştirmeleri uygularken kullandığınız zamanlanmış bir bakım pencereniz var mı?
  • Kritik bir güvenlik yaması gibi bir acil durum güncelleştirmeniz varsa ne olur? Bu gibi durumlarda güncelleştirmeleri zorlayabilir misiniz?
  • Yaklaşan güncelleştirmeleri müşteriye proaktif olarak bildiremiyorsanız geçmişe dönük bildirimler sağlayabilir misiniz? Örneğin, web sitenizdeki bir sayfayı uyguladığınız güncelleştirmelerin listesiyle güncelleştirebilir misiniz?
  • Sisteminizin üretimde kaç ayrı sürümü olacak?

Müşteri destek ekibinizle iletişim kurma

Kendi destek ekibinizin her kiracıya uygulanmış güncelleştirmeleri tam olarak görünür durumda olması önemlidir. Müşteri destek temsilcileri aşağıdaki soruları kolayca yanıtlayabilmelidir:

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

Müşterilerinizden birinin güncelleştirme nedeniyle bir sorunu varsa, müşteri destek ekibinizin nelerin değiştiğini anlamak için gerekli bilgilere sahip olduğundan emin olmanız gerekir.

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

Altyapınıza güncelleştirmeleri nasıl dağıtabileceğinizi düşünün. Bu, kullandığınız kiracı modelinden büyük ölçüde etkilenir. Güncelleştirmeleri dağıtmaya yönelik üç yaygın yaklaşım dağıtım damgaları, özellik bayrakları ve dağıtım halkalarıdır. Bu yaklaşımları bağımsız olarak kullanabilir veya daha karmaşık gereksinimleri karşılamak için bir araya getirebilirsiniz.

Her durumda yeterli raporlama ve görünürlüğe sahip olduğunuzdan emin olun; böylece her kiracının hangi altyapı, yazılım veya özellik sürümünün üzerinde olduğunu, nelere geçirilmeye uygun olduklarını ve bu durumlarla ilişkili zaman ile ilgili verileri bilirsiniz.

Dağıtım Damgaları düzeni

Birçok çok kiracılı uygulama, uygulamanızın ve diğer bileşenlerin birden çok kopyasını dağıttığınız Dağıtım Damga 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 damgaları dağıtabilirsiniz.

Damga pulları, kiracılar arasında yalıtım sağlamanın harika bir yoludur. Güncelleştirmeleri diğer damgaları etkilemeden pullar arasında aşamalı olarak dağıtabildiğiniz için güncelleştirme işleminiz için de esneklik sağlar.

Özellik bayrakları

Özellik bayrakları , yalnızca müşterilerinizin veya kiracılarınızın bir alt kümesine bu işlevselliği gösterirken çözümünüz için işlevsellik eklemenize olanak tanır.

Bu durumlardan biri sizin için geçerliyse özellik bayraklarını kullanmayı göz önünde bulundurun:

  • Güncelleştirmeleri düzenli olarak dağıtırsınız ancak tam olarak uygulanana kadar yeni işlevlerin gösterilmesini önlemek istersiniz.
  • Müşteri kabul edene kadar davranış değişikliklerinin uygulanmasını önlemek istiyorsunuz.

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

Dağıtım halkaları

Dağıtım halkaları , güncelleştirmeleri bir kiracılar veya dağıtım damgaları kümesinde aşamalı olarak dağıtmanızı sağlar. Her kademeye bir kiracı alt kümesi atayabilirsiniz.

Kaç halka oluşturulacağını ve her halkanın kendi çözümünüz için ne anlama geldiğini belirleyebilirsiniz. Kuruluşlar genellikle aşağıdaki halkaları kullanır:

  • Kanarya: Kanarya halkası, kendi test kiracılarınızı ve kullanılabilir oldukları anda güncelleştirmeleri almak isteyen müşterileri, daha sık güncelleştirmeler alabileceklerini ve bu güncelleştirmelerin diğer konularda olduğu gibi kapsamlı bir doğrulama sürecinden geçmemiş olabileceğini anlayarak içerir.
  • Erken benimseyen: Erken benimseyen halka biraz daha riskli olan ancak hala düzenli güncelleştirmeleri almaya hazır olan kiracılar içerir.
  • Kullanıcı: Kiracılarınızın çoğu, daha az sık ve daha yüksek oranda test edilmiş güncelleştirmeler alan kullanıcı halkasına ait olacaktır.

API sürümleri

Hizmetiniz bir dış API'yi kullanıma sunarsa, uyguladığınız güncelleştirmelerin müşterilerin veya iş ortaklarının platformunuzla tümleştirme biçimini etkileyebileceğini göz önünde bulundurun. Özellikle API'lerinizdeki hataya neden olan değişikliklerin farkında olmanız gerekir. API'nizde güncelleştirme riskini azaltmak için bir API sürüm oluşturma stratejisi kullanmayı göz önünde bulundurun.

Katkıda Bulunanlar

Bu makale Microsoft tarafından korunur. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

  • John Downs | Baş Müşteri Mühendisi, Azure için FastTrack

Diğer katkıda bulunanlar:

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar