Aracılığıyla paylaş

İş yükü geliştirme tedarik zinciri tasarlama önerileri

  • Makale

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

OE:06 Tahmin edilebilir, otomatikleştirilmiş işlem hatları aracılığıyla önerilen değişiklikleri yönlendiren bir iş yükü tedarik zinciri oluşturun. İşlem hatları bu değişiklikleri ortamlar arasında test eder ve yükseltebilir. İş yükünüzü güvenilir, güvenli, uygun maliyetli ve performanslı hale getirmek için tedarik zincirini iyileştirin.

Bu kılavuzda, sürekli tümleştirme ve sürekli teslim (CI/CD) işlem hatlarını temel alan bir iş yükü geliştirme tedarik zinciri tasarlama önerileri açıklanmaktadır. İş yükünüzü korumak için öngörülebilir, standartlaştırılmış bir yönteme sahip olduğunuzdan emin olmak için bir tedarik zinciri geliştirin. CI/CD işlem hatları tedarik zincirinin tezahürüdür, ancak tek bir tedarik zincirine sahip olmanız gerekir. Ayrıca aynı işlemleri izleyen ve aynı araçları kullanan birkaç işlem hattınız olabilir.

İş yükünüzü iş yükü değişikliklerini düzgün bir şekilde yönetmediğinizde oluşabilecek zararlardan korumak için bir tedarik zinciri dahil edin. İş yükünüzün durumunu her zaman unutmayın, bu nedenle öngörülemeyen davranışlar yaşama riskiniz olmaz. Bu risk, sorunlar ortaya çıktığında hesaba katılmayan değişiklikleri geri çekmek için kritik zaman harcamanız gerekiyorsa daha da artar. Bu riskleri en aza indirmek için tedarik zincirinizi tanımlayan süreçleri ve araçları standartlaştırın ve iş yükü ekibinizin kullanımlarına tam olarak bağlı olduğundan emin olun.

Tanım

Süre Tanım
Tedarik zinciri Bulut iş yüklerinde tedarik zinciri, ortamlar arasında altyapı ve uygulama değişikliklerini etkilemek için kullandığınız standartlaştırılmış bir araç ve süreç paketidir.

Temel tasarım stratejileri

Not

Bu kılavuzdaki öneriler, bir kod yükseltme zincirindeki iş yükü ortamlarına başvurur. Korumalı alan veya diğer keşif ve kavram kanıtı ortamları daha az sıkı ve yapı gerektirir.

Çekirdek tenetler

Aşağıdaki öneriler tedarik zincirinizin temel ilkelerini tanımlamanıza yardımcı olabilir.

Tedarik zinciri süreçleri ve araçları aracılığıyla önerilen iş yükü değişikliklerini yapın. Otomatik şablon tabanlı dağıtımların katı bir ilkesini zorunlu kılma. Bu yöntem, iş yükünüzün tüm ortamlardaki yapılandırmasının standartlaştırılmış, iyi tanımlanmış ve sıkı bir şekilde denetlendiğinden emin olunmasını sağlar. Kod yükseltme zincirindeki ortamlar için, el ile işlemler veya bulut platformunun kontrol düzlemi (örneğin portal veya API) ile insan etkileşimi kullanarak güncelleştirmeler gerçekleştirmayın. Tanımladığınız dağıtım uygulamalarını izleyerek bir işlem hattı aracılığıyla ortamdaki tüm değişiklikleri birleştirin. Bu ilkenin uygulanmasına yardımcı olmak için, erişimi varsayılan olarak salt okunur ile sınırlamayı ve yazma erişimine izin vermek için erişim yetkilendirme geçidi kullanmayı göz önünde bulundurun.

Bu ağın önemli bir yönü, tüm değişikliklerin üretime dağıtılana kadar önerilendeğişiklikler olmasıdır. Tümleştirme ve duman testi gibi otomatikleştirilmiş testlerle tedarik zincirinizin değişiklikleri otomatik olarak reddetmesini sağlarsınız.

Kod olarak yinelenebilir ve sabit altyapı (IaC) dağıtın. IaC, kaynak kodu yansıtan bir sürüm oluşturma sistemi kullanan açıklayıcı bir modelde altyapı yönetimidir. Bir uygulama oluşturduğunuzda, aynı kaynak kodu her derlendiğinde aynı ikiliyi oluşturmalıdır. Benzer şekilde, bir IaC modeli her uygulandığında aynı ortamı oluşturur.

Ekibinizin standart, iyi belirlenmiş bir süreç izlediğini güvence altına almak için IaC'yi dahil edin. Bazı kuruluşlar, altyapıyı dağıtmak ve yapılandırmak için tek bir bireyi veya küçük bir grup birey olarak belirleyebilir. Tam otomatik bir işlem uyguladığınızda, altyapı dağıtımları bireylerden daha az yönetim gerektirir. Sorumluluk otomasyon sürecine ve araçlarına aktarılır. Ekip üyeleri tutarlılığı ve kaliteyi korumak için altyapı dağıtımları başlatabilir.

İş yükünüzü, dağıtımları kolay ve tekrarlanabilir hale getirmek için tek bir şablonda paketleyebileceğiniz mantıksal bir bileşen grubu olarak tasarlayın. Bu paketleri pul veya ölçek birimi olarak düşünebilirsiniz. Daha fazla bilgi için bkz . Dağıtım DamgaLarı düzeni. Aynı bölge içindeki başka bir bölgeye veya bölgeye ölçeği genişletmek için iş yükünüzü dağıtmanız gerektiğinde, işlem hattı kullanarak bir damga pulu dağıtın. Damgalarınızı nasıl tasarladığınıza bağlı olarak, iş yükünün tamamı yerine iş yükünüzün bir alt kümesini dağıtabilirsiniz. Dağıtım damgalarınızın mevcut kaynaklara otomatik olarak bağlandığından emin olmak için IaC işlem hatlarınıza ağ bileşenlerini ekleyin.

Tutarlılık ve verimlilik için IaC işlem hattınızı iyileştirmek için, değişebilir altyapı yerine sabit bir altyapı tasarlayın. Kapsamdaki tüm sistemlerin güncelleştirilmiş yapılandırmayla aynı anda ve her dağıtımla aynı şekilde değiştirildiğinden emin olmak için sabit bir altyapı uygulayın.

Tüm ortamlarda ve işlem hatlarında tek bir kod varlığı ve yapıt kümesi kullanın. Kuruluşlar için yaygın bir sorun, üretim dışı ortamların üretim ortamlarından farklı olmasıdır. Üretim ve üretim dışı ortamların el ile oluşturulması, ortamlar arasında eşleşmeyen yapılandırmalara neden olabilir. Bu uyuşmazlık testi yavaşlatır ve değişikliklerin üretim sistemine zarar verme olasılığını daha yüksektir. IaC yaklaşımı bu sorunları en aza indirir. IaC otomasyonunu kullandığınızda, neredeyse aynı ortamları üretmek için tüm ortamlar için aynı altyapı yapılandırma dosyalarını kullanabilirsiniz. Altyapı yapılandırma dosyalarına parametreler ekleyebilir ve bunları her ortamın gereksinimlerini karşılayacak şekilde ayarlayabilirsiniz.

Maliyetleri denetlemek için genellikle üretim ve üretim dışı ortamlar arasında bir varyans vardır. Üretim dışı ortamlarda genellikle üretim ortamındakiyle aynı düzeyde yedekliliğe ve performansa ihtiyacınız yoktur. Kaynaklarınızın sayısı ve SKU'su ortamlar arasında farklılık gösterebilir. Değişiklik yaparken öngörülebilirliği korumanıza yardımcı olmak için standartlaştırılmış parametreler kullanarak varyansı denetlediğinizden ve anladığınızdan emin olun.

Tedarik zincirinizde ve işlem hattı tasarımlarınızda kurumsal yapınızı yansıtabilirsiniz. Kuruluşunuz ekipler arasında silolanmış olabilir. Her ekip tedarik zincirinin bir bölümünü yönetebilir. Örneğin, birçok kuruluşun ağ, veri ve işlem kaynakları gibi altyapı etki alanlarını yöneten ekipleri vardır. Bu ekipler uygulama geliştirme, test ve dağıtımları yöneten geliştirme ekiplerinden ayrıdır. Bazı kuruluşlarda geliştirme ve altyapı ekipleri, tüm altyapı ve uygulama dağıtımlarını topluca yöneten DevOps ekiplerine dahil edilir. Tedarik zincirinde yer alan ekipleri düzenlemenin birçok yolu vardır. Tedarik zinciriniz, tüm ekiplerin sorunsuz bir şekilde birlikte çalışmasını sağlar. Tüm ekiplerin standart süreçleri izlediğinden ve tedarik zincirini mümkün olduğunca verimli hale getirmek için standart araçlar kullandığından emin olun.

İş yükü yaşam döngüsünün bazı bölümlerini dış kaynak olarak kullanırsanız tedarik zinciriniz üçüncü taraf satıcılara güvenebilir. Bu satıcılar, tedarik zincirinizin başarısı için iç kaynaklar kadar kritik öneme sahiptir. Kullandığınız süreçler ve araçlar hakkında tüm ekipler arasında karşılıklı bir anlaşma olduğundan emin olun.

Dağıtım yönteminizi standartlaştırma. İş yükünüz için kabul edilebilir üretim kapalı kalma süresi miktarı hakkında ürün sahibiyle görüşün. Kapalı kalma süresinin ne kadar kabul edilebilir olduğuna bağlı olarak gereksinimlerinize uygun dağıtım yöntemini seçebilirsiniz. İdeal olarak, karmaşıklığı ve riski azaltmak için dağıtımları bakım penceresi sırasında gerçekleştirmeniz gerekir. Kapalı kalma süresi kabul edilebilir değilse mavi-yeşil dağıtım yöntemini kullanın.

Müşterilerinize algılanmayan hataların ortaya çıkarılma riskini azaltmak için aşamalı maruz kalma yaklaşımını kullanın. Kanarya dağıtımları olarak da bilinen bu yöntem, denetimli kullanıcı gruplarına aşamalı bir sırayla dağıtılır. Daha fazla kullanıcıyı etkilemeden önce sorunları yakalar. İlk dağıtım grubu, müşterilerinizin dağıtım stratejisini bilen bir alt bölümü olabilir. Müşterilerin bu alt bölümü, bazı beklenmeyen davranışları tolere edebilir ve geri bildirim sağlayabilir. Veya dağıtım sırasında hataların patlama yarıçapını kapsamaya yardımcı olan bir grup iç kullanıcı olabilir.

Dağıtım yönteminizi tanımlarken, her dağıtımda yalnızca en küçük uygulanabilir değişikliği dağıtmaya yönelik standart bir ilke benimseyin. İş yükünün kritikliği ve bileşenlerin karmaşıklığı gibi faktörlere bağlı olarak, en küçük uygulanabilir değişikliği belirleyin. Sabit bir altyapı kullanıyorsanız, en küçük uygulanabilir değişiklik genellikle kaynakların önceki sürümü çalıştıran kaynakları değiştirmek için en son yapılandırmaya sahip dağıtımıdır. Değiştirilebilir bir altyapı kullanıyorsanız, en küçük uygulanabilir değişikliğin kapsamdaki kaynak grubunda yalnızca tek bir güncelleştirme olduğuna karar verebilirsiniz.

Farklı yaşam döngülerini yansıtmak için katmanlı bir yaklaşımı izleyin. Temel katmanlar, iş yükü yaşam döngüsünün çoğu boyunca statik kalmalı ve uygulama katmanları sık sık değişmelidir. Bu farklılıkları hesaba katmak için, her katmandaki değişiklikleri etkili hale getirmek için farklı işlem hatlarınız olmalıdır.

Giriş bölgesi en düşük katmandadır. Giriş bölgesi abonelikler, yönetim grupları, kaynak grupları, idare işlevleri ve ağ topolojisi gibi temel öğelerin mantıksal bir gruplandırmasıdır. Giriş bölgesi, iş yükünüzü kolayca dağıtmanıza ve yönetmenize olanak tanır ve merkezi operasyon ekiplerine veya platform ekiplerine ortam yapılandırmasına tekrarlanabilir bir yaklaşım sunar. Tutarlı ortamlar sunmak için tüm Azure giriş bölgeleri bir dizi ortak tasarım alanı, başvuru mimarisi, başvuru uygulaması ve dağıtımı tasarım gereksinimlerinize uyacak şekilde değiştirme işlemi sağlar. Azure giriş bölgesi tasarım ilkeleri, abonelik demokratikleştirmesinin yanı sıra ilke temelli idareyi temel alan önerilen uygulamalar sağlar. Giriş bölgesi, iş yükü yaşam döngünüz boyunca çok az değişiklik gerektirmelidir. Giriş bölgesi örneğini görmek için bkz. Azure giriş bölgesi nedir? Bu kavramsal mimari, Azure için önerilen bir dizi görüş sağlar.

Giriş ve çıkış ağ denetleyicileri, yük dengeleme, ağ yönlendirme çözümleri, DNS yönetimi ve çekirdek sunucular gibi temel altyapınız ve işlevleriniz de seyrek büyük değişiklikler gerektirmelidir. Ancak bunlar sık sık yapılandırma güncelleştirmeleri gerektirebilir.

Uygulamanız ve veri katmanınız için sık sık yapılandırma güncelleştirmeleri ve sık altyapı değişiklikleri gerekir. Bu bileşenler en dinamik işlem hatlarına sahip olmalıdır.

Bütünsel bir test stratejisi planlama. Sistem güvenilirliğinin temel tenetlerinden biri , sola kaydırma ilkesidir. Uygulama geliştirme ve dağıtma, soldan sağa doğru bir dizi adım olarak gösterilen bir işlemdir. Testi sürecin sonuna kadar sınırlamamalısınız. Mümkün olduğunca, vardiya testini başa veya sola doğru yapın. Hataları erken yakaladığınızda onarmak daha ucuz olur. Uygulama yaşam döngüsünün ilerleyen bölümlerinde bunları düzeltmek pahalı veya imkansız olabilir.

Uygulama kodu, altyapı şablonları ve yapılandırma betikleri dahil olmak üzere tüm kodları test edin. Uygulamaları çalıştıran ortam, sürüm denetiminden geçirilmeli ve uygulama koduyla aynı mekanizmalar aracılığıyla dağıtılmalıdır. Ekiplerinizin uygulama kodu için zaten kullandığı test paradigmalarını kullanarak ortamı test edebilir ve doğrulayabilirsiniz.

Tutarlılığı sağlamak için mümkün olduğunda otomatik testi kullanın. Tedarik zinciri tasarımınıza aşağıdaki test türlerini ekleyin.

  • Birim testi: Birim testleri genellikle sürekli tümleştirme yordamının bir parçası olarak çalıştırılır. Birim testleri kapsamlı ve hızlı olmalıdır. İdeal olarak kodun yüzde 100'ünün kapsaması ve 30 saniyeden kısa bir süre içinde çalıştırılması gerekir.

    Tek tek kod modüllerinin söz diziminin ve işlevselliğinin olması gerektiği gibi çalıştığını doğrulamak için birim testi uygulayın; örneğin, bilinen bir giriş için tanımlı bir çıkış oluşturun. IaC varlıklarının geçerli olduğunu doğrulamak için birim testlerini de kullanabilirsiniz.

    Şablonlar ve betikler dahil olmak üzere tüm kod varlıklarına birim testleri uygulayın.

  • Duman testi: Duman testleri, bir iş yükünün bir test ortamında bekletilebildiğini ve beklendiği gibi çalıştığını doğrular. Duman testleri bileşenlerin birlikte çalışabilirliğini doğrulamaz.

    Duman testleri, altyapı ve uygulama için dağıtım metodolojisinin çalıştığını ve sistemin işlem tamamlandıktan sonra istenen şekilde yanıt verdiğini doğrular.

  • Tümleştirme testi: Tümleştirme testleri, uygulama bileşenlerinin ayrı ayrı çalışmasını sağlar ve sonra bileşenlerin birbirleriyle olması gerektiği gibi etkileşime girip çalışamayacağını belirler.

    Büyük bir tümleştirme test paketini çalıştırmak çok uzun sürebilir. Bu nedenle, en iyisi sola kaydırma ilkesini dahil etmek ve yazılım geliştirme yaşam döngüsünün erken aşamalarında test gerçekleştirmektir. Tümleştirme testlerini, duman testi veya birim testiyle test edemediğiniz senaryolar için ayırın.

    Gerekirse, uzun süre çalışan test işlemlerini düzenli aralıklarla çalıştırabilirsiniz. Düzenli aralıklar iyi bir güvenlik açığı sunar ve uygulama bileşenleri arasındaki birlikte çalışabilirlik sorunlarını kullanıma sunulduğundan en geç bir gün sonra algılar.

    Bazı test senaryoları el ile çalıştırmalardan yararlanılır. Testlere insan etkileşim öğeleri eklemeniz gerektiğinde el ile testi kullanın.

  • Kabul testi: Bağlama bağlı olarak, kabul testini el ile gerçekleştirebilirsiniz. Kısmen veya tamamen otomatikleştirilebilir. Kabul testi, yazılım sisteminin gereksinim belirtimlerini karşılayıp karşılamadığını belirler.

    Bu testin temel amacı, sistemin iş gereksinimleriyle uyumluluğunu değerlendirmek ve sistemin son kullanıcılara teslim için gerekli ölçütleri karşılayıp karşılamadığını belirlemektir.

Test yoluyla kod yükseltme sürecinizde kalite geçitleri uygulayın. Kodunuzu geliştirme ve test gibi daha düşük ortamlara ve hazırlama ve üretim gibi daha yüksek ortamlar aracılığıyla dağıtın. Dağıtımınız kalite kapılarından geçerken, değişiklikler üretime geçmeden önce kalite hedeflerinizi karşıladığından emin olun. İş gereksinimleriniz, kalite kapılarınızın odak noktasını belirler. Ayrıca temel Well-Architected Çerçevesi ilkelerini de göz önünde bulundurun: Güvenlik, Güvenilirlik ve Performans Verimliliği.

Ayrıca onay iş akışlarını kalite kapılarınızla tümleştirin. Uygun olduğunda onay iş akışlarını net bir şekilde tanımlayın ve otomatikleştirin. Kalite kabul ölçütlerini otomasyonunuzda tanımlayın, böylece kapılarınızdan verimli ve güvenli bir şekilde geçebilirsiniz.

Azure kolaylaştırma

Azure DevOps , işbirliğine dayalı, verimli ve tutarlı bir geliştirme uygulaması oluşturmanıza yardımcı olan bir hizmet koleksiyonudur.

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

Azure için GitHub Actions, dağıtımları basitleştirmek için Azure ile tümleşir. CI/CD işlemlerini otomatikleştirmek için GitHub Actions kullanın. Deponuzdaki her çekme isteğini derleyip test eden iş akışları oluşturabilir veya birleştirilmiş çekme isteklerini üretim ortamına dağıtabilirsiniz.

IaC dağıtımları için Terraform, Bicep ve Azure Resource Manager kullanabilirsiniz. Gereksinimlerinize ve ekibinizin araçlarla ilgili bilgisine bağlı olarak, dağıtımlarınız ve kaynakların yönetimi için bu araçlardan birini veya daha fazlasını kullanabilirsiniz.

Örnek

Ci/CD işlem hattı oluşturmak için Azure Pipelines'ın nasıl kullanılacağını gösteren bir örnek için bkz. Azure Pipelines temel mimarisi.

Operation Excellence denetim listesi

Önerilerin tamamına bakın.

Operasyonel Mükemmellik denetim listesi