Dağıtım hatası azaltma stratejisi tasarlama önerileri

Bu Azure Well-Architected Framework Operasyonel Mükemmellik denetim listesi önerisi için geçerlidir:

Bu kılavuzda, dağıtım hatalarını etkili bir şekilde işlemek için standartlaştırılmış bir strateji tasarlamaya yönelik öneriler açıklanmaktadır. Diğer iş yükü sorunları gibi dağıtım hataları da iş yükü yaşam döngüsünün kaçınılmaz bir parçasıdır. Bu düşünce yapısıyla, dağıtım hatalarıyla başa çıkmak için iyi tasarlanmış, kasıtlı bir stratejiye sahip olarak proaktif olabilirsiniz. Böyle bir strateji, iş yükü ekibinizin son kullanıcılarınız üzerinde mümkün olduğunca az etkiyle hataları verimli bir şekilde azaltmasını sağlar.

Böyle bir planın olmaması, sorunlara kaotik ve potansiyel olarak zarar verici yanıtlara yol açabilir ve bu da takım ve kurumsal uyumu, müşteri güvenini ve finansı önemli ölçüde etkileyebilir.

Temel tasarım stratejileri

Bazen, geliştirme uygulamalarınızın olgunluğuna rağmen dağıtım sorunları oluşur. Güvenli dağıtım uygulamalarını kullanmak ve güçlü bir iş yükü tedarik zinciri çalıştırmak, başarısız dağıtımların sıklığını en aza indirmenize yardımcı olabilir. Ancak, başarısız dağıtımları gerçekleştiğinde işlemek için standartlaştırılmış bir strateji de tasarlamanız gerekir.

Standart uygulama olarak aşamalı pozlama dağıtım modeli kullandığınızda:

• Dağıtımlar başarısız olduğunda müşterileriniz veya iç kullanıcılarınız üzerindeki etkileri en aza indirmek için doğru temele sahipsiniz.
• Sorunları verimli bir şekilde azaltabilirsiniz.

Dağıtım hatası azaltma stratejisi beş geniş aşamadan oluşur:

1. Algılama: Başarısız bir dağıtıma yanıt vermek için önce hatayı algılamanız gerekir. Algılama başarısız duman testleri, kullanıcı tarafından bildirilen sorunlar veya izleme platformunuzun oluşturduğu uyarılar gibi çeşitli biçimlerde olabilir.

2. Karar: Belirli bir hata türü için en iyi azaltma stratejisinin ne olduğuna karar vermelisiniz.

3. Azaltma: Tanımlanan azaltma eylemini gerçekleştirirsiniz. Azaltma, sorunlu işlevi atlamak için bir geri dönüş, geri alma, ileri alma veya çalışma zamanı yapılandırmasının kullanılması biçiminde olabilir.

4. İletişim: Acil durum yanıt planınız gereği sorunu algılayıp bu sorunu incelerken paydaşların ve etkilenen son kullanıcıların durumun farkında olması gerekir.

5. Postmortem: Blameless postmortems, iş yükü ekibinin geliştirme alanlarını belirlemesi ve öğrenmeleri uygulamak için planlar oluşturması için fırsatlar sunar.

Aşağıdaki bölümlerde bu aşamalar için ayrıntılı öneriler sağlanmaktadır. Bu bölümlerde, değişikliklerinizi bir veya daha fazla kullanıcı veya sistem grubuna dağıttıktan sonra ancak dağıtım planınızdaki tüm grupları güncelleştirmeden önce bir sorun algıladığınız varsayılır.

Algılama

Dağıtımlarla ilgili sorunları hızla belirlemek için, dağıtımlarla ilgili güçlü test ve gözlemlenebilirlik uygulamalarına ihtiyacınız vardır. Anomalileri hızla algılamaya yardımcı olmak için aşağıdaki adımları uygulayarak iş yükü izleme ve uyarılarınızı tamamlayabilirsiniz:

• Uygulama performans yönetimi aracı kullanın.
• İzleme aracılığıyla günlüğe kaydetmeyi etkinleştirin.

Duman testi ve diğer kalite testleri, dağıtımınızın her aşamasında gerçekleşmelidir. Bir dağıtım grubundaki başarılı testler, sonraki gruplarda test etme kararlarını etkilememelidir.

Dağıtım aşamasıyla ilgili kullanıcı sorunlarını ilişkilendiren telemetri uygulayabilirsiniz. Ardından, belirli bir kullanıcının hangi dağıtım grubuyla ilişkili olduğunu hızla belirleyebilirsiniz. Dağıtımın belirli bir noktasında kullanıcı tabanınızda çalışan birden çok yapılandırmanız olabileceğinden bu yaklaşım özellikle aşamalı kullanıma açık dağıtımlar için önemlidir.

Kullanıcı tarafından bildirilen sorunlara hemen yanıt vermeye hazır olmanız gerekir. Pratik olduğunda, tam destek ekibiniz olduğunda dağıtım aşamanızı çalışma saatleri içinde dağıtın. Doğru yönlendirme için dağıtım sorunlarının nasıl yükseltilmesi konusunda destek personelinin eğitildiğinden emin olun. Yükseltmeler iş yükü acil durum yanıt planınızla uyumlu olmalıdır.

Karar

Belirli bir dağıtım sorunu için uygun bir risk azaltma stratejisine karar vermek için aşağıdakiler gibi birçok faktör dikkate alınır:

• Kullandığınız aşamalı pozlama modelinin türü. Örneğin, mavi-yeşil model veya kanarya modeli kullanabilirsiniz.

  Mavi-yeşil model kullanıyorsanız, geri dönmek geri dönmekten daha pratiktir. Trafiği, güncelleştirilmeyen yapılandırmayı çalıştıran yığına kolayca geri kaydırabilirsiniz. Daha sonra sorunu sorunlu ortamda düzeltebilir ve dağıtımınızı uygun bir zamanda yeniden deneyebilirsiniz.

• Sorunu atlamak için kullanabileceğiniz yöntemler. Örnek olarak özellik bayraklarının, ortam değişkenlerinin veya açıp kapatabileceğiniz başka türde çalışma zamanı yapılandırma özelliğinin kullanılması verilebilir.

  Bazen bir özellik bayrağını kapatarak veya ayarı değiştirerek sorunu kolayca atlayabilirsiniz. Bu durumda şunları yapabileceksiniz:

  • Dağıtıma devam edin.
  • Geri düşmekten kaçının.
  • Sorunlu kodu düzeltirken geri alın.

• Kodda bir düzeltme uygulamak için gereken çaba düzeyi.

  Kodu düzeltme çaba düzeyi düşükse, sık erişimli düzeltme uygulayarak ileriye doğru ilerlemek belirli senaryolar için doğru seçimdir.

• Etkilenen iş yükü için kritiklik düzeyi.

  İş açısından kritik iş yükleri, sıfır kapalı kalma süresi dağıtımlarına ulaşmak için her zaman mavi-yeşil modelde olduğu gibi yan yana dağıtılmalıdır. Sonuç olarak, geri dönmek bu tür iş yükleri için tercih edilen azaltma stratejisidir.

• İş yükünün kullandığı altyapı türü (değişebilir veya sabit).

  İş yükünüz değiştirilebilir altyapıyı kullanacak şekilde tasarlandıysa, altyapının güncelleştirilmesini içerdiği için ileriye doğru ilerlemek mantıklı olabilir. Buna karşılık, sabit altyapı kullandığınızda geri dönmek veya geri dönmek mantıklı olabilir.

Hangi seçimleri yaparsanız yapın, karar verme sürecinize uygun onayları dahil etmeli ve karar ağacınızda bunları codify yapmalısınız.

Risk azaltma

• Geri Alma: Geri alma senaryosunda, güncelleştirilmiş sistemleri bilinen son iyi yapılandırma durumuna geri döndürebilirsiniz.

  İş yükü ekibinin tamamının bilinen son iyiliğin anlamı konusunda hemfikir olması önemlidir. Bu ifade, iş yükünün dağıtım başlamadan önce iyi durumda olan son durumunu ifade eder ve bu durum her zaman önceki uygulama sürümü değildir.

  Geri almak, özellikle veri değişiklikleriyle ilgili olduğu için karmaşık olabilir. Şema değişiklikleri geri dönmenin riskli olmasını sağlayabilir. Bunları güvenli bir şekilde uygulamak önemli bir planlama gerektirebilir. Genel bir öneri olarak, şema güncelleştirmeleri eklenebilir olmalıdır. Değişiklikler değiştirilmemelidir; kayıtlar yeni kayıtlarla değiştirilmemelidir. Bunun yerine, eski kayıtlar kullanım dışı bırakılmalıdır ve kullanım dışı bırakılan kayıtların kaldırılması güvenli olana kadar yeni kayıtlarla birlikte bulunmalıdır.

• Geri dönüş: Bir geri dönüş senaryosunda, güncelleştirilmiş sistemler üretim trafiği yönlendirmesinden kaldırılır. Tüm trafik güncelleştirilmeyen yığına yönlendirilir. Bu düşük riskli strateji, kodunuzdaki sorunları daha fazla kesintiye neden olmadan çözmeniz için bir yol sağlar.

  Kanarya dağıtımlarında altyapınıza ve uygulama tasarımınıza bağlı olarak geri dönmek kolay ve hatta mümkün olmayabilir. Güncelleştirilmeyen sistemlerde yükü işlemek için ölçeklendirme gerçekleştirmeniz gerekiyorsa, geri dönmeden önce bu ölçeklendirmeyi gerçekleştirin.

• Sorunlu işlevi atlama: Özellik bayraklarını veya başka bir çalışma zamanı yapılandırma özelliğini kullanarak sorunu atlayabilirseniz, dağıtıma devam etme işleminin belirli bir sorun için doğru strateji olduğuna karar vekleyebilirsiniz.

  İşlevi atlamanın dezavantajını net bir şekilde anlamalısınız ve bu dengeyi paydaşlara iletebilmelisiniz. Proje katılımcıları ileriye dönük planı onaylamalıdır. Paydaşların, düzeyi düşürülmüş bir durumda çalışma için tolere edilebilecek süreyi belirlemesi gerekir. Ayrıca bu kararlılığı, sorunlu kodu düzeltmek ve dağıtmak için gereken süreyle ilgili tahmininize göre değerlendirmeleri gerekir.

• Acil durum dağıtımı (sık erişimli düzeltme):Dağıtımın ortasında sorunu giderebiliyorsanız, sık erişimli düzeltme en pratik azaltma stratejisi olabilir.

  Diğer kodlarda olduğu gibi sık erişimli düzeltmelerin de güvenli dağıtım uygulamalarınızdan geçmesi gerekir. Ancak sık erişimli düzeltme ile zaman çizelgesi önemli ölçüde hızlandırılır. Ortamlarınız genelinde bir kod yükseltme stratejisi kullanmanız gerekir. Ayrıca tüm kalite kapılarında sık erişimli düzeltme kodunu kontrol etmeniz gerekir. Ancak, pişirme sürelerini önemli ölçüde kısaltmanız ve testleri hızlandırmak için değiştirmeniz gerekebilir. Dağıtımdan sonra güncelleştirilmiş kod üzerinde en kısa sürede tam testler çalıştırabildiğinize emin olun. Kalite güvencesi testlerinin yüksek düzeyde otomatikleştirilmesi, bu senaryolarda testin verimli olmasına yardımcı olur.

Dezavantajlar:

• Geri dönebilmek genellikle iş yükü yapılandırmanızın iki sürümünü aynı anda işlemek için yeterli altyapı kapasitesine ihtiyacınız olduğu anlamına gelir. İş yükü ekiplerinizin aynı anda üretimde iki sürümü de destekleyebilmesi gerekir.

• Geri alma işlemini etkili bir şekilde yapabilmek için iş yükünüzün öğelerini yeniden düzenlemeniz gerekebilir. Örneğin, işlevleri ayırmanız veya veri modelinizi değiştirmeniz gerekebilir.

İletişim

Olaylar sırasında kaosu en aza indirmeye yardımcı olmak için açıkça tanımlanmış iletişim sorumluluklarına sahip olmak önemlidir. Bu sorumluluklar, iş yükü ekibinin destek ekipleri, paydaşlar ve acil durum yanıt ekibi personeliyle (acil durum yanıt yöneticisi gibi) nasıl etkileşim kurduğunu belirlemelidir.

Durum güncelleştirmeleri sağlamak için iş yükü ekibinin izlediği tempoyu standartlaştırın. Proje katılımcılarının güncelleştirmeleri ne zaman beklediklerini bilmeleri için bu standardın farkında olduğundan emin olun.

İş yükü ekibinin doğrudan son kullanıcılarla iletişim kurması gerekiyorsa, kullanıcılarla paylaşmaya uygun bilgi türünü ve ayrıntı düzeyini netleştirin. Ayrıca bu durumlar için geçerli olan diğer gereksinimleri iş yükü ekibine iletin.

Son durum gözden geçirmesi

Son durumların istisnasız tüm başarısız dağıtımları izlemesi gerekir. Başarısız olan her dağıtım, öğrenme için bir fırsattır. Postmortems, dağıtım ve geliştirme süreçlerinizdeki zayıf noktaları belirlemenize yardımcı olabilir. Ayrıca, altyapınızdaki yanlış yapılandırmaları ve diğer birçok olasılığı da belirleyebilirsiniz.

Otopsiler her zaman suçsuz olmalıdır, böylece olaya dahil olan kişiler geliştirebilecekleri bakış açılarını paylaştıklarında kendilerini güvende hissederler. Postmortem liderleri, tanımlanan iyileştirmeleri uygulama ve bu planları iş yükü kapsamına ekleme planlarını izlemelidir.

Dikkat edilmesi gerekenler ve genel öneriler

Dağıtım işlem hattınızın, bilinen son iyi yapılandırmaları kolayca dağıtabilmeniz için ayrı sürümleri parametre olarak kabul edebilmesini sağlayın.

Geri alınırken veya ileriye doğru ilerlerken yönetim ve veri düzlemleriyle tutarlılığı koruyun. Kaynaklara ve ilkelere özgü anahtarların, gizli dizilerin, veritabanı durumu verilerinin ve yapılandırmaların kapsama alınması ve hesaba alınması gerekir. Örneğin, bilinen son iyi dağıtımda altyapı ölçeklendirmenizin tasarımına dikkat edin. Kodunuzu yeniden dağıtırken bu yapılandırmayı ayarlamanız gerekip gerekmediğini belirleyin.

Yeni ve bilinen son iyi dağıtımlarınız arasındaki deltanın küçük olması için seyrek ve büyük değişiklikler yerine küçük, sık yapılan değişiklikleri tercih edin.

Risk azaltmaları karmaşık hale getirebilecek sorunların belirlenmesine yardımcı olmak için sürekli tümleştirme ve sürekli teslim (CI/CD) işlem hatlarınızda hata modu analizi (FMA) gerçekleştirin. bir bütün olarak iş yükünüz gibi işlem hatlarınız da belirli bir risk azaltma türünü denediğinizde sorunlu olabilecek alanları belirlemek için analiz edilebilir.

Otomatik geri alma işlevini yargısal olarak kullanın:

• Azure DevOps gibi bazı CI/CD araçları yerleşik olarak otomatik geri alma işlevlerine sahiptir. Size somut değer sağlıyorsa bu işlevi kullanmayı göz önünde bulundurun.
• Otomatik geri alma işlevini yalnızca işlem hattınızı kapsamlı ve düzenli olarak test ettikten sonra benimsemeniz gerekir. Otomatik geri alma tetiklendiğinde işlem hattınızın ek sorunlara neden olacak kadar olgun olduğundan emin olun.
• Otomasyonun yalnızca gerekli değişiklikleri dağıttığına ve yalnızca gerektiğinde tetiklendiğinden emin olmanız gerekir. Bu gereksinimleri karşılamak için tetikleyicilerinizi dikkatli bir şekilde tasarlayın.

Geri alma işlemleri sırasında platform tarafından sağlanan özellikleri kullanın. Örneğin, yedeklemeler ve belirli bir noktaya geri yüklemeler depolama ve veri geri alma işlemlerine yardımcı olabilir. Uygulamanızı barındırmak için sanal makineler (VM) kullanıyorsanız, ortamınızı bir olaydan hemen önce gelen bir denetim noktasına geri yüklemek yararlı olabilir.

Dağıtım hatası azaltma stratejinizin tamamını sık sık test edin. Acil durum yanıt planları ve olağanüstü durum kurtarma planları gibi, dağıtım hata planınız da ancak ekibiniz bu konuda eğitildiğinde ve düzenli olarak uygulandığında başarılı olur. Kaos mühendisliği ve hata ekleme testi, dağıtım azaltma stratejinizi test etmede etkili teknikler olabilir.

Dezavantaj: Destek ekibi üyelerinin normal görevlerini yerine getirebilmeleri ve acil durumları destekleyebilmeleri gerekir. Destek ekibinin düzgün bir şekilde personele sahip olduğundan ve tüm gerekli görevleri yerine getirebildiğinden emin olmak için baş sayısını artırmanız gerekebilir. Daha düşük geliştirme ortamlarına dağıtım yaptığınızda dağıtımları kapsamlı bir şekilde test edin. Bu uygulama, üretime geçmeden önce hataları ve yanlış yapılandırmaları algılamanıza yardımcı olur.

Azure kolaylaştırma

• Azure Pipelines , uygulamalarınızın CI/CD'sini desteklemek için derleme ve yayın hizmetleri sağlar.

• Azure Test Plans, kullanımı kolay tarayıcı tabanlı bir test yönetimi çözümüdür. Bu çözüm planlı el ile test, kullanıcı kabul testi ve keşif testi için gereken özellikler sunar. Azure Test Plans ayrıca paydaşlardan geri bildirim toplamanız için bir yol sağlar.

• Azure İzleyici , bulut ve şirket içi ortamlarınızdan izleme verilerini toplamak, analiz etmek ve yanıtlamak için kapsamlı bir izleme çözümüdür. İzleyici, güçlü bir uyarı platformu içerir. Bu sistemi otomatik bildirimler ve otomatik ölçeklendirme ve diğer kendi kendini düzeltme mekanizmaları gibi diğer eylemler için yapılandırabilirsiniz.

• Application Insights , uygulama performansı izleme (APM) özellikleri sağlayan bir İzleyici uzantısıdır.

• Azure Logic Apps uygulamaları, verileri, hizmetleri ve sistemleri tümleştiren otomatik iş akışlarını çalıştırmaya yönelik bulut tabanlı bir platformdur. Logic Apps'i kullanarak her güncelleştirme yapıldığında uygulamanızın yeni bir sürümünü oluşturabilirsiniz. Azure, sürümlerin geçmişini tutar ve önceki sürümleri geri döndürebilir veya yükseltebilir.

• Birçok Azure veritabanı hizmeti, geri almanız gerektiğinde size yardımcı olabilecek belirli bir noktaya geri yükleme işlevi sağlar:

  • Azure SQL Veritabanı

  • Azure SQL Yönetilen Örnek

  • Azure Cosmos DB

  • MySQL için Azure Veritabanı

  • PostgreSQL için Azure Veritabanı

• Azure Chaos Studio Önizlemesi , bulut uygulamanızın ve hizmet dayanıklılığınızı ölçmenize, anlamanıza ve geliştirmenize yardımcı olmak için kaos mühendisliği kullanan yönetilen bir hizmettir.

İlgili bağlantılar

• Özellik bayraklarıyla aşamalı deneme
• Gözlemlenebilirlik çerçevesi tasarlama ve oluşturma önerileri
• Acil durum yanıt stratejisi tasarlama önerileri
• Güvenilirlik testi stratejisi tasarlamaya yönelik öneriler
• İş yükü geliştirme tedarik zinciri tasarlama önerileri
• Hata modu analizi gerçekleştirmeye yönelik öneriler
• Güvenli dağıtım uygulamaları için öneriler

Operasyonel Mükemmellik denetim listesi

Önerilerin tamamına bakın.