Azure'da görev açısından kritik iş yükleri için dağıtım ve test

Başarısız dağıtımlar ve hatalı sürümler, uygulama kesintilerinin yaygın nedenleridir. Dağıtım ve test yaklaşımınız, görev açısından kritik bir uygulamanın genel güvenilirliğinde kritik bir rol oynar.

Görev açısından kritik iş yüklerinde tutarlı sonuçlar elde etmek için dağıtım ve test tüm uygulama ve altyapı işlemlerinin temelini oluşturmalıdır. Haftalık, günlük veya daha sık dağıtmaya hazır olun. Bu hedefleri desteklemek için sürekli tümleştirme ve sürekli dağıtım (CI/CD) işlem hatlarınızı tasarlayın.

Stratejinin uygulanması gerekenler:

• Zorlu yayın öncesi test. Güncelleştirmeler uygulama durumunu tehlikeye atabilecek hatalara, güvenlik açıklarına veya diğer faktörlere neden olmamalıdır.

• Saydam dağıtımlar. Kullanıcıları etkilemeden güncelleştirmeleri istediğiniz zaman kullanıma sunmanın mümkün olması gerekir. Kullanıcıların uygulamayla etkileşimlerine kesintisiz olarak devam edebilmesi gerekir.

• Yüksek oranda kullanılabilir işlemler. Genel uygulama güvenilirliğini desteklemek için dağıtım ve test süreçleri ve araçları yüksek oranda kullanılabilir olmalıdır.

• Tutarlı dağıtım işlemleri. Altyapıyı ve uygulama kodunu farklı ortamlara dağıtmak için aynı uygulama yapıtları ve işlemleri kullanılmalıdır. Uçtan uca otomasyon zorunludur. Güvenilirlik risklerine neden olabilecekleri için el ile müdahalelerden kaçınılmalıdır.

Bu tasarım alanı, kapalı kalma süresini en aza indirme ve uygulama sistem durumu ve kullanılabilirliğini koruma hedefiyle dağıtım ve test işlemlerini iyileştirmeye yönelik öneriler sağlar.

Önemli

Bu makale, Azure İyi Tasarlanmış Çerçeve görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir? ile başlamanızı öneririz.

Sıfır kapalı kalma süresi dağıtımı

Sıfır kapalı kalma süresi dağıtımına genel bakış için aşağıdaki videoyu görüntüleyin.

Sıfır kapalı kalma süresi dağıtımlarına ulaşmak, görev açısından kritik uygulamalar için temel bir hedeftir. Yeni sürümler iş saatlerinde kullanıma sunulduğunda bile uygulamanızın tüm gün, her gün kullanılabilir olması gerekir. Kaynakları kısa ömürlü olarak ele alıp almama gibi önemli tasarım kararları almak için dağıtım süreçlerini tanımlamak ve planlamak için çabalarınızı öne alın.

Sıfır kapalı kalma süresi dağıtımına ulaşmak için mevcut altyapının yanına yeni altyapı dağıtın, kapsamlı bir şekilde test edin, son kullanıcı trafiğini geçirin ve yalnızca önceki altyapının yetkisini alın. Ölçek birimi mimarisi gibi diğer uygulamalar da önemlidir.

Görev Açısından Kritik Çevrimiçi ve Azure Görev Açısından Kritik Bağlı başvuru uygulamaları, bu diyagramda gösterildiği gibi bu dağıtım yaklaşımını gösterir:

Uygulama ortamları

Uygulama ortamlarına yönelik önerilere genel bir bakış için aşağıdaki videoyu görüntüleyin.

Dağıtım işlemlerini doğrulamak ve hazırlamak için çeşitli ortam türlerine ihtiyacınız vardır. Türlerin farklı özellikleri ve yaşam döngüleri vardır. Bazı ortamlar üretim ortamını yansıtabilir ve uzun ömürlü olabilir, bazıları ise kısa ömürlü ve üretimden daha az özelliğe sahip olabilir. Geliştirme döngüsünün başlarında bu ortamların ayarlanması çeviklik, üretim ve üretim öncesi varlıkların ayrılması ve üretim ortamına bırakılmadan önce operasyonların kapsamlı test edilmesini sağlamaya yardımcı olur. Tüm ortamlar mümkün olduğunca üretim ortamını yansıtmalıdır, ancak gerektiğinde daha düşük ortamlara basitleştirmeler uygulayabilirsiniz. Bu diyagramda görev açısından kritik bir mimari gösterilmektedir:

Yaygın olarak dikkat edilmesi gereken bazı noktalar vardır:

• Bileşenler ortamlar arasında paylaşılmamalıdır. Olası özel durumlar, yapay test verileri için güvenlik duvarları ve kaynak konumları gibi aşağı akış güvenlik gereçleridir.

• Tüm ortamlar Terraform veya Azure Resource Manager (ARM) şablonları gibi kod olarak altyapı (IaC) yapıtlarını kullanmalıdır.

Geliştirme ortamları

Kısa ömürlü geliştirme ortamları ve otomatik özellik doğrulama hakkında bilgi için aşağıdaki videoyu görüntüleyin.

Tasarımla ilgili dikkat edilecek noktalar

• Özellikler. Güvenilirlik, kapasite ve güvenlik için daha düşük gereksinimler geliştirme ortamları için kabul edilebilir.

• Yaşam döngüsü. Geliştirme ortamları gerektiği gibi oluşturulmalı ve kısa bir süre için mevcut olmalıdır. Daha kısa yaşam döngüleri, kod tabanından yapılandırma kaymasını önlemeye ve maliyetleri azaltmaya yardımcı olur. Ayrıca geliştirme ortamları genellikle bir özellik dalının yaşam döngüsünü paylaşır.

• Yoğunluk. Ekiplerin paralel özellik geliştirmeyi desteklemek için birden çok ortam olması gerekir. Tek bir abonelikte birlikte bulunabilirler.

Tasarım önerileri

• Geliştirme amacıyla bağlam kümesiyle ortamı ayrılmış bir abonelikte tutun.

• Bir özellik dalından geliştirme ortamına kod dağıtmak için otomatik bir işlem kullanın.

Ortamları test veya hazırlama

Bu ortamlar test ve doğrulama için kullanılır. Üretime hatasız dağıtım sağlamak için birçok test döngüsü gerçekleştirilir. Görev açısından kritik bir iş yükü için uygun testler Sürekli doğrulama ve test bölümünde açıklanmıştır.

Tasarımla ilgili dikkat edilecek noktalar

• Özellikler. Bu ortamlar güvenilirlik, kapasite ve güvenlik için üretim ortamını yansıtmalıdır. Üretim yükü olmadığında, gerçekçi ölçümler ve değerli sistem durumu modelleme girişi sağlamak için yapay bir kullanıcı yükü kullanın.

• Yaşam döngüsü. Bu ortamlar kısa ömürlü. Test doğrulamaları tamamlandıktan sonra yok edilmelidir.

• Yoğunluk. Tek bir abonelikte birçok bağımsız ortam çalıştırabilirsiniz. Ayrıca, her birinin ayrılmış bir abonelikte olduğu gibi birden çok ortam kullanmayı da göz önünde bulundurmalısınız.

Not

Görev açısından kritik uygulamalar sıkı testlere tabi tutulmalıdır.

Tek bir ortamda farklı test işlevleri gerçekleştirebilirsiniz ve bazı durumlarda bunu yapmanız gerekir. Örneğin, anlamlı sonuçlar sağlamak için kaos testi için, uygulamanın eklenen hatalara nasıl yanıt verdiğini anlayabilmek için önce uygulamayı yük altına yerleştirmeniz gerekir. Bu nedenle kaos testi ve yük testi genellikle paralel olarak gerçekleştirilir.

Tasarım önerileri

• Üretim benzeri test ve doğrulamayı etkinleştirmek için en az bir hazırlama ortamının üretimi tamamen yansıtdığından emin olun. Bu ortamdaki kapasite, test etkinliklerinin yürütülmesine bağlı olarak esneebilir.

• Ortamlardan birinde yapılan değişiklikler için gerçekçi bir test çalışması sağlamak üzere yapay kullanıcı yükü oluşturun.

  Not

  Görev Açısından Kritik Çevrimiçi başvuru uygulaması, kullanıcı yük oluşturucusunun bir örneğini sağlar.

• Geliştirme ve yayın döngüsü içindeki hazırlama ortamlarının sayısını ve bunların amaçlarını tanımlayın.

Üretim ortamları

Tasarımla ilgili dikkat edilecek noktalar

• Özellikler. Uygulama için en yüksek güvenilirlik, kapasite ve güvenlik işlevselliği düzeyleri gereklidir.

• Yaşam döngüsü. İş yükünün ve altyapının yaşam döngüsü aynı kalırken, izleme ve günlüğe kaydetme dahil olmak üzere tüm verilerin özel yönetime ihtiyacı vardır. Örneğin, yedekleme ve kurtarma için yönetim gereklidir.

• Yoğunluk. Bazı uygulamalarda farklı istemcilere, kullanıcılara veya iş işlevlerine hizmet vermek için farklı üretim ortamları kullanmayı düşünebilirsiniz.

Tasarım önerileri

Üretim ve daha düşük ortamlar için net bir idare sınırına sahip olun. Bu hedefe ulaşmak için her ortam türünü ayrılmış bir aboneliğe yerleştirin. Bu segmentasyon, düşük ortamlarda kaynak kullanımının üretim kotalarını etkilememesini sağlar. Ayrılmış abonelikler de erişim sınırlarını ayarlar.

Kısa ömürlü mavi/yeşil dağıtımlar

Mavi/yeşil dağıtım modeli için en az iki özdeş dağıtım gerekir. Mavi dağıtım, üretimde kullanıcı trafiğine hizmet veren etkin dağıtımdır. Yeşil dağıtım, trafiği almak için hazırlanan ve test edilen yeni dağıtımdır. Yeşil dağıtım tamamlandıktan ve test edildikten sonra trafik yavaş yavaş maviden yeşile yönlendirilir. Yük aktarımı başarılı olursa yeşil dağıtım yeni etkin dağıtım olur. Eski mavi dağıtım daha sonra aşamalı bir işlemle kullanımdan kaldırılabilir. Ancak, yeni dağıtımda sorunlar varsa durdurulabilir ve trafik eski mavi dağıtımda kalabilir veya buna yönlendirilebilir.

Azure Görev Açısından Kritik, altyapı ve uygulamaların bir dağıtım damgasının parçası olarak birlikte dağıtıldığı mavi/yeşil bir dağıtım yaklaşımı önerir. Bu nedenle, altyapıda veya uygulamada yapılan bir değişikliğin dağıtımı her zaman her iki katmanı da içeren yeşil bir dağıtımla sonuç alır. Bu yaklaşım, kullanıcı trafiğini yeniden yönlendirmeden önce değişikliğin altyapı ve uygulama üzerindeki etkisini uçtan uca tam olarak test edip doğrulamanızı sağlar. Azure platformu, kaynak sağlayıcıları ve IaC modülleri gibi aşağı akış bağımlılıklarına yönelik uyumluluklar doğrulanabildiği için yaklaşım değişiklikleri yayınlamaya olan güveni artırır ve sıfır kapalı kalma süresi yükseltmelerine olanak tanır.

Tasarımla ilgili dikkat edilecek noktalar

• Teknoloji özellikleri. Azure hizmetlerindeki yerleşik dağıtım özelliklerinden yararlanın. Örneğin, Azure Uygulaması Hizmeti bir dağıtımdan sonra değiştirilebilen ikincil dağıtım yuvaları sağlar. Azure Kubernetes Service (AKS) ile her düğümde ayrı bir pod dağıtımı kullanabilir ve hizmet tanımını güncelleştirebilirsiniz.

• Dağıtım süresi. Damga yalnızca değiştirilen bileşen yerine altyapıyı ve uygulamayı içerdiğinden dağıtımın tamamlanması daha uzun sürebilir. Ancak, tüm bileşenlerin beklendiği gibi çalışmaması riski zaman sorunlarını geçersiz kıldığından bu kabul edilebilir bir durumdur.

• Maliyet etkisi. Yan yana iki dağıtım nedeniyle ek bir maliyet vardır ve bu da dağıtım tamamlanana kadar bir arada bulunması gerekir.

• Trafik geçişi. Yeni dağıtım doğrulandıktan sonra trafiğin mavi ortamdan yeşil ortama geçmesi gerekir. Bu geçiş, ortamlar arasındaki kullanıcı trafiğinin düzenlemesini gerektirir. Geçiş tamamen otomatik olmalıdır.

• Yaşam döngüsü. Görev açısından kritik dağıtım damgaları kısa ömürlü olarak değerlendirilmelidir. Kısa süreli damgaları kullanmak, kaynaklar sağlanmadan önce her seferinde yeni bir başlangıç oluşturur.

Tasarım önerileri

• Tüm üretim değişikliklerini yayınlamak için mavi/yeşil dağıtım yaklaşımını benimseyin. Tutarlı bir durum ve sıfır kapalı kalma süresi elde etmek için tüm altyapıyı ve uygulamayı her seferinde dağıtın. Ortamları yeniden kullanabilirsiniz ancak görev açısından kritik iş yükleri için bunu önermeyiz. Tek bir sürümün yaşam döngüsüyle her bölgesel dağıtım damgasını kısa ömürlü olarak değerlendirin.

• Mavi ve yeşil ortamlar arasında kullanıcı trafiğinin otomatik geçişini yönetmek için Azure Front Door gibi genel bir yük dengeleyici kullanın.

• Trafiği geçiş yapmak için, hacim ağırlığına düşük trafik kullanan yeşil bir arka uç uç noktası (örneğin, yüzde 10) ekleyin. Yeşil dağıtımdaki düşük trafik hacminin çalıştığını ve beklenen uygulama durumunu sağladığını doğruladıktan sonra trafiği kademeli olarak artırın. Bunu yaparken, hemen belirgin olmayabilecek hataları yakalamak için kısa bir artış süresi uygulayın.

  Tüm trafik geçirildikten sonra mavi arka ucu mevcut bağlantılardan kaldırın. Örneğin, arka ucu genel yük dengeleyici hizmetinden kaldırın, kuyrukları boşaltın ve diğer ilişkilendirmeleri ayırın. Bunun yapılması, ikincil üretim altyapısının bakımını yapma maliyetini iyileştirmeye ve yeni ortamların yapılandırma kaymasından arınmasını sağlamaya yardımcı olur.

  Bu noktada, eski ve şimdi etkin olmayan mavi ortamın yetkisini alın. Sonraki dağıtım için mavi ve yeşil ters çevrilmiş olarak işlemi yineleyin.

Abonelik kapsamlı dağıtım

Uygulamanızın ölçek gereksinimlerine bağlı olarak, ölçek birimi olarak hizmet vermek için birden çok üretim aboneliğine ihtiyacınız olabilir.

Görev açısından kritik bir uygulama için kapsam belirleme aboneliklerine yönelik önerilere genel bir bakış elde etmek için aşağıdaki videoyu izleyin.

Tasarımla ilgili dikkat edilecek noktalar

• Ölçeklenebilirlik. Önemli hacimli trafik içeren yüksek ölçekli uygulama senaryoları için çözümü birden çok Azure aboneliği arasında ölçeklendirilecek şekilde tasarlar, böylece tek bir aboneliğin ölçek sınırları ölçeklenebilirliği kısıtlamaz.

  Önemli

  Birden çok aboneliğin kullanılması, uygun şekilde yönetilmesi gereken ek CI/CD karmaşıklığını gerektirmektedir. Bu nedenle, yalnızca tek bir aboneliğin sınırlarının bir sınırlamaya dönüşeceği aşırı ölçekli senaryolarda birden çok abonelik öneririz.

• Ortam sınırları. Üretim, geliştirme ve test ortamlarını ayrı aboneliklere dağıtın. Bu uygulama, düşük ortamların ölçek sınırlarına katkıda bulunmamasını sağlar. Ayrıca net bir yönetim ve kimlik sınırı sağlayarak daha düşük ortam güncelleştirmelerinin üretimi kirletme riskini azaltır.

• İdare. Birden çok üretim aboneliğine ihtiyacınız olduğunda, ilke toplama sınırı aracılığıyla ilke atamasını basitleştirmek için ayrılmış bir uygulama yönetim grubu kullanmayı göz önünde bulundurun.

Tasarım önerileri

• Abonelik sınırlarının uygulama genelinde değil yalnızca tek bir dağıtım damgası bağlamında uygulandığından emin olmak için her bölgesel dağıtım damgasını ayrılmış bir abonelikte dağıtın. Uygun durumlarda, tek bir bölgede birden çok dağıtım damgası kullanmayı düşünebilirsiniz, ancak bunları bağımsız abonelikler arasında dağıtmanız gerekir.

• Tutarlı bölgesel abonelik dağıtımlarını etkinleştirmek için genel paylaşılan kaynakları ayrılmış bir aboneliğe yerleştirin. Birincil bölge için özelleştirilmiş bir dağıtım kullanmaktan kaçının.

Sürekli doğrulama ve test etme

Test, uygulama kodunuzun ve altyapınızın durumunu tam olarak doğrulamanızı sağlayan kritik bir etkinliktir. Daha açık belirtmek gerekirse test, güvenilirlik, performans, kullanılabilirlik, güvenlik, kalite ve ölçek standartlarınıza uymanızı sağlar. Test, uygulama tasarımınızın ve DevOps stratejinizin bir parçası olarak iyi tanımlanmış ve uygulanmalıdır. Test, yerel geliştirici işlemi ( iç döngü) sırasında ve tam DevOps yaşam döngüsünün ( dış döngü) bir parçası olarak, kodun yayın işlem hattı işlemlerinden üretim ortamına doğru yolda başladığı ana konudur.

Sürekli doğrulama ve teste genel bir bakış elde etmek için aşağıdaki videoyu görüntüleyin.

Bu bölüm dış döngü testlerine odaklanır. Çeşitli test türlerini açıklar.

Test etme	Açıklama
Birim testi	Uygulama iş mantığının beklendiği gibi çalıştığını onaylar. Kod değişikliklerinin genel etkisini doğrular.
Duman testi	Altyapı ve uygulama bileşenlerinin kullanılabilir olup olmadığını ve beklendiği gibi çalışıp çalışmadığını tanımlar. Genellikle yalnızca tek bir sanal kullanıcı oturumu test edilir. Sonuç, sistemin beklenen değerler ve davranışlarla yanıt vermesi olmalıdır. Yaygın duman testi senaryoları web uygulamasının HTTPS uç noktasına ulaşmayı, veritabanını sorgulamayı ve uygulamadaki bir kullanıcı akışının simülasyonunu oluşturmayı içerir.
Kullanıcı arabirimi testi	Uygulama kullanıcı arabirimlerinin dağıtıldığını ve kullanıcı arabirimi etkileşimlerinin beklendiği gibi çalıştığını doğrular. Otomasyonu yönlendirmek için UI otomasyon araçlarını kullanmanız gerekir. Kullanıcı arabirimi testi sırasında betik gerçekçi bir kullanıcı senaryosunu taklit etmeli ve eylemleri yürütmek ve hedeflenen bir sonuca ulaşmak için bir dizi adımı tamamlamalıdır.
Yük testi	Önceden belirlenmiş bir eşiğe ulaşılana kadar yükü hızla ve/veya aşamalı olarak artırarak ölçeklenebilirliği ve uygulama işlemini doğrular. Yük testleri genellikle uygulama gereksinimlerinin tanımlı bir yük altında karşılandığını doğrulamak için belirli bir kullanıcı akışı etrafında tasarlanmıştır.
Stres testi	Çözüm sınırlarını belirlemek ve sistemin düzgün bir şekilde kurtarılabilmesini doğrulamak için mevcut kaynakları aşırı yükleyen etkinlikleri uygular. Ana hedef, olası performans sorunlarını ve ölçek sınırlarını belirlemektir. Buna karşılık, sistemin bilgi işlem kaynaklarının ölçeğini küçültün ve yük altında nasıl davrandığını izleyin ve kurtarılıp kurtarılamayacağını belirleyin.
Performansı test etme	Yük altında performansı doğrulamak ve uygulama işlemi için karşılaştırma davranışları oluşturmak için yük ve stres testinin yönlerini birleştirir.
Kaos testi	Nasıl tepki verdigini değerlendirmek ve dayanıklılık önlemlerinin, operasyonel prosedürlerin ve risk azaltmaların etkililiğini doğrulamak için sisteme yapay hatalar ekler. Altyapı bileşenlerini kapatmak, performansı kasıtlı olarak düşürmek ve uygulama hatalarına giriş yapmak, senaryolar gerçekleştiğinde uygulamanın beklendiği gibi tepki verebileceğini doğrulamak için kullanılabilecek test örnekleridir.
Sızma testi	Bir uygulamanın ve ortamının beklenen güvenlik duruşunun gereksinimlerini karşılamasını sağlar. Amaç, güvenlik açıklarını belirlemektir. Güvenlik testi, bilinen Yaygın Güvenlik Açıkları ve Etkilenmeler (CVE) için tarama ve izleme ile uçtan uca yazılım tedarik zincirini ve paket bağımlılıklarını içerebilir.

Tasarımla ilgili dikkat edilecek noktalar

• Otomasyon. Otomatik test, uygulama veya altyapı değişikliklerini zamanında ve tekrarlanabilir bir şekilde doğrulamak için gereklidir.

• Test sırası. Çalışan bir uygulama ortamına sahip olmak gibi çeşitli bağımlılıklar nedeniyle testlerin yürütülürken dikkate alınması gereken sıra kritik önem taşır. Test süresi, sırayı da etkiler. Test verimliliğini artırmak için daha kısa çalışma sürelerine sahip testler mümkün olduğunda döngünün başlarında çalıştırılmalıdır.

• Ölçeklenebilirlik sınırları. Azure hizmetlerinin farklı geçici ve sabit sınırları vardır. Beklenen üretim yükü sırasında sistemin bunları aşıp aşmadığını belirlemek için yük testini kullanmayı göz önünde bulundurun. Yük testi, otomatik ölçeklendirme için uygun eşikleri ayarlamak için de yararlı olabilir. Otomatik ölçeklendirmeyi desteklemeyen hizmetler için yük testi, otomatik işlem yordamlarında ince ayarlamalar yapmanızı sağlayabilir.

  Etkin/pasif ağ bileşenleri veya veritabanları gibi sistem bileşenlerinin uygun şekilde ölçeklendirilememesi kısıtlayıcı olabilir. Stres testi, sınırlamaları belirlemeye yardımcı olabilir.

• Hata modu analizi. Uygulamaya ve temel altyapıya hata eklemek ve bunun etkisini değerlendirmek, çözümün yedeklilik mekanizmalarını değerlendirmek için gereklidir. Bu analiz sırasında etkinin riskini, etkisini ve genişliği (kısmi veya tam kesinti) belirleyin. Görev Açısından Kritik Çevrimiçi başvuru uygulaması için oluşturulan örnek bir analiz için bkz. Tek tek bileşenlerin kesinti riskleri.

• İzleme. Test sonuçlarını ayrı ayrı yakalayıp analiz etmeli ve ayrıca zaman içindeki eğilimleri değerlendirmek için toplamanız gerekir. Test sonuçlarını doğruluk ve kapsam açısından sürekli değerlendirmeniz gerekir.

Tasarım önerileri

Dayanıklılık testinin Azure DevOps CI/CD işlem hatları ile nasıl tümleştirilebileceğini görmek için aşağıdaki videoyu izleyin.

• Altyapı ve uygulama bileşenlerindeki tüm testleri otomatikleştirerek tutarlılığı sağlayın. Testleri uygun olduğunda düzenleyip çalıştırmak için CI/CD işlem hatlarında tümleştirin. Teknoloji seçenekleri hakkında bilgi için bkz . DevOps araçları.

• Tüm test yapıtlarını kod olarak değerlendirin. Bunların bakımı ve sürümü diğer uygulama kodu yapıtlarıyla birlikte denetlenmelidir.

• Test altyapısının SLA'sını dağıtım ve test döngüleri için SLA ile hizalayın.

• Her dağıtımın bir parçası olarak duman testleri çalıştırın. Ayrıca uygulama performansının ve çalışabilirliğinin korunduğunu doğrulamak için stres ve kaos testleriyle birlikte kapsamlı yük testleri çalıştırın.

  • Gerçek en yoğun kullanım desenlerini yansıtan yük profillerini kullanın.
  • Yük testleri ile aynı anda kaos denemeleri ve hata ekleme testleri çalıştırın.

  İpucu

  Azure Chaos Studio , yerel bir kaos deneme araçları paketidir. Araçlar, kaos denemeleri gerçekleştirmeyi ve Azure hizmetleri ile uygulama bileşenlerine hata eklemeyi kolaylaştırır.

  Chaos Studio, yaygın hata senaryoları için yerleşik kaos denemeleri sağlar ve altyapı ve uygulama bileşenlerini hedefleyen özel denemeleri destekler.

• Kayıt oluşturma gibi veritabanı etkileşimleri yük veya duman testleri için gerekliyse, azaltılmış ayrıcalıklara sahip test hesaplarını kullanın ve test verilerini gerçek kullanıcı içeriğinden ayrılabilir hale getirin.

• Bilinen CVE'ler için uçtan uca yazılım tedarik zincirini ve paket bağımlılıklarını tarayın ve izleyin.

  • Deponun bağlı olduğu paketlerin ve uygulamaların en son sürümleriyle otomatik olarak güncel olduğundan emin olmak için GitHub depoları için Dependabot'ı kullanın.

Kod olarak altyapı dağıtımları

Kod olarak altyapı (IaC), altyapı tanımlarını diğer uygulama yapıtlarıyla birlikte denetlenen sürümde kaynak kod olarak değerlendirir. IaC'nin kullanılması ortamlar arasında kod tutarlılığını teşvik eder, otomatik dağıtımlar sırasında insan hatası riskini ortadan kaldırır ve izlenebilirlik ve geri alma sağlar. Mavi/yeşil dağıtımlar için IaC'nin tam otomatik dağıtımlarla kullanılması zorunludur.

Görev açısından kritik bir IaC deposunda, genel ve bölgesel kaynaklara eşlenmiş iki ayrı tanım vardır. Bu tür kaynaklar hakkında bilgi için bkz . temel mimari düzeni.

Tasarımla ilgili dikkat edilecek noktalar

• Yinelenebilir altyapı. Görev açısından kritik iş yüklerini her seferinde aynı ortamı oluşturacak şekilde dağıtın. IaC birincil model olmalıdır.

• Otomasyon. Tüm dağıtımlar tamamen otomatik olmalıdır. İnsan işlemleri hataya açıktır.

Tasarım önerileri

• IaC'yi uygulayarak tüm Azure kaynaklarının bildirim temelli şablonlarda tanımlandığından ve bir kaynak denetimi deposunda tutulduğunu güvence altına alın. Şablonlar dağıtılır ve kaynaklar CI/CD işlem hatları aracılığıyla kaynak denetiminden otomatik olarak sağlanır. Kesinlik temelli betiklerin kullanılmasını önermiyoruz.

• Tüm ortamlarda el ile işlemleri yasaklayın. Tek istisna tamamen bağımsız geliştirici ortamlarıdır.

DevOps araçları

DevOps işlemleri genel işlevi ve uygulama tasarımını etkilediğinden dağıtım araçlarının etkili kullanımı genel güvenilirlik açısından kritik öneme sahiptir. Örneğin, yük devretme ve ölçeklendirme işlemleri DevOps araçları tarafından sağlanan otomasyona bağlı olabilir. Mühendislik ekipleri, genel iş yükü açısından bir dağıtım hizmetinin kullanılamama durumunun etkisini anlamalıdır. Dağıtım araçları güvenilir ve yüksek oranda kullanılabilir olmalıdır.

Microsoft, görev açısından kritik bir uygulamayı etkili bir şekilde dağıtabilen ve yönetebilen iki Azure yerel araç kümesi (GitHub Actions ve Azure Pipelines) sağlar.

Tasarımla ilgili dikkat edilecek noktalar

• Teknoloji özellikleri. GitHub ve Azure DevOps'un özellikleri çakışıyor. Her ikisini de en iyi şekilde elde etmek için bunları birlikte kullanabilirsiniz. Yaygın bir yaklaşım, dağıtım için Azure Pipelines'ı kullanırken kod depolarını GitHub.com veya GitHub AE'de depolamaktır.

  Birden çok teknoloji kullandığınızda eklenen karmaşıklığı unutmayın. Zengin bir özellik kümesini genel güvenilirlikle karşılaştırarak değerlendirin.

• Bölgesel kullanılabilirlik. En yüksek güvenilirlik açısından tek bir Azure bölgesine bağımlılık, operasyonel bir riski temsil eder.

  Örneğin, trafiğin iki bölgeye yayıldığını söyleyebilirdik: Bölge 1 ve Bölge 2. Bölge 2, Azure DevOps araç örneğini barındırıyor. Bölge 2'de bir kesinti olduğunu ve örneğin kullanılabilir olmadığını varsayalım. Bölge 1 tüm trafiği otomatik olarak işler ve iyi bir yük devretme deneyimi sağlamak için ek ölçek birimleri dağıtması gerekir. Ancak Bölge 2'deki Azure DevOps bağımlılığı nedeniyle mümkün olmayacaktır.

• Veri çoğaltma. Meta veriler, işlem hatları ve kaynak kodu gibi veriler bölgeler arasında çoğaltılmalıdır.

Tasarım önerileri

• Her iki teknoloji de tek bir Azure bölgesinde barındırılır ve bu da olağanüstü durum kurtarma stratejinizi kısıtlayıcı hale getirir.

  GitHub Actions, derleme görevleri (sürekli tümleştirme) için uygundur ancak karmaşık dağıtım görevleri (sürekli dağıtım) için özelliklere sahip olmayabilir. Azure DevOps'un zengin özellik kümesi göz önünde bulundurulduğunda, görev açısından kritik dağıtımlar için bunu öneririz. Ancak, dengeleri değerlendirdikten sonra bir seçim yapmalısınız.

• Dağıtım araçları için bir kullanılabilirlik SLA'sı tanımlayın ve daha geniş uygulama güvenilirliği gereksinimleriyle uyumlu olduğundan emin olun.

• Etkin/pasif veya etkin/etkin dağıtım yapılandırması kullanan çok bölgeli senaryolar için, dağıtım araç kümelerini barındıran birincil bölge kullanılamaz duruma gelse bile yük devretme düzenleme ve ölçeklendirme işlemlerinin çalışmaya devam ettiğinden emin olun.

Dallanma stratejisi

Dallanma için birçok geçerli yaklaşım vardır. En yüksek güvenilirliği sağlayan bir strateji seçmelisiniz. İyi bir strateji paralel geliştirme sağlar, geliştirmeden üretime net bir yol sağlar ve hızlı sürümleri destekler.

Tasarımla ilgili dikkat edilecek noktalar

• Erişimi en aza indirin. Geliştiriciler işlerini ve fix/* dallarında feature/* yapmalıdır. Bu dallar değişiklikler için giriş noktaları haline gelir. Dallanma stratejisi kapsamında dallara rol tabanlı kısıtlamalar uygulanmalıdır. Örneğin, yöneticilerin yalnızca yayın dalları oluşturmasına veya dallar için adlandırma kurallarını zorlamasına izin verin.

• Acil durumlar için hızlandırılmış süreç. Dallanma stratejisi, düzeltmelerin en kısa sürede birleştirilmesini main sağlamalıdır. Bu şekilde, gelecekteki sürümler düzeltmeyi içerir ve sorunun yinelenmemesi önlenir. Bu işlemi yalnızca acil sorunları ele alan küçük değişiklikler için kullanın ve kısıtlama ile kullanın.

Tasarım önerileri

• Kaynak denetimi için GitHub kullanımına öncelik verin.

  Önemli

  Özellik çalışmalarını ve yayınlarını en düşük düzeyde ayrıntılı olarak gösteren bir dallanma stratejisi oluşturun ve stratejinin uygun şekilde uygulandığından emin olmak için dal ilkeleri ve izinleri kullanın.

• Kod değişikliği katkılarını kabul etmeden önce doğrulamak için otomatikleştirilmiş bir test işlemini tetikleyin. Ekip üyelerinin de değişiklikleri gözden geçirmesi gerekir.

• Dalı main , öncelikle tümleştirme testi için kullanılan sürekli ileriye dönük ve kararlı bir dal olarak değerlendirin.

  • Yalnızca PR'ler aracılığıyla değişiklik yapıldığından main emin olun. Doğrudan işlemeleri yasaklama amacıyla bir dal ilkesi kullanın.
  • Bir çekme isteği ile mainbirleştirildiğinde, bir tümleştirme ortamına karşı otomatik olarak bir dağıtım başlatmalıdır.
  • Dalın main kararlı olduğu düşünülmelidir. Herhangi bir zamanda sürümünden main bir yayın oluşturmak güvenli olmalıdır.

• Daldan main oluşturulan ve üretim ortamlarına dağıtmak için kullanılan ayrılmış release/* dalları kullanın. release/* dalları depoda kalmalı ve yayına düzeltme eki uygulamak için kullanılabilir.

• Bir düzeltme işlemini belgeleyin ve yalnızca gerektiğinde kullanın. Yayın dalı ile daha sonra birleştirmek ve üretime dağıtım yapmak için bir fix/* dalda düzeltmeler oluşturun.

DevOps için yapay zeka

Geleneksel test yaklaşımlarını desteklemek için CI/CD işlem hatlarında AIOps yöntemleri uygulayabilirsiniz. Bunu yapmak olası regresyonların veya düşüşlerin algılanmasını sağlar ve olası olumsuz etkileri önlemek için dağıtımların önceden durdurulmasına olanak tanır.

Tasarımla ilgili dikkat edilecek noktalar

• Telemetri verilerinin hacmi. CI/CD işlem hatları ve DevOps işlemleri, makine öğrenmesi modelleri için çok çeşitli telemetri verileri sağlar. Telemetri, test sonuçlarından ve dağıtım sonuçlarından bileşik dağıtım aşamalarından test bileşenleriyle ilgili operasyonel verilere kadar değişir.

• Ölçeklenebilirlik. Ayıklama, Dönüştürme, Yükleme (ETL) gibi geleneksel veri işleme yaklaşımları, dağıtım telemetrisinin ve uygulama gözlemlenebilirlik verilerinin büyümesine ayak uydurmak için aktarım hızını ölçeklendiremeyebilir. AIOps modellerinin sürekli analizini etkinleştirmek için ETL ve veri sanallaştırma gibi veri taşıma gerektirmeyen modern analiz yaklaşımlarını kullanabilirsiniz.

• Dağıtım değişiklikleri. Dağıtımdaki değişikliklerin otomatik analiz ve dağıtım sonuçlarıyla bağıntı için depolanması gerekir.

Tasarım önerileri

• Toplanacağı DevOps işlem verilerini ve nasıl analiz yapılacağını tanımlayın. Test yürütme ölçümleri ve her dağıtımdaki değişikliklerin zaman serisi verileri gibi telemetri önemlidir.

  • AIOps modellerinde analiz ve bağıntı için hazırlama, test ve üretim ortamlarından uygulama gözlemlenebilirliği verilerini kullanıma sunma.

• MLOps iş akışını benimseyin.

• Şema ve davranış değişikliklerini ele almak üzere otomatik özellik mühendisliğiyle tahminler sağlamak için bağlama duyarlı ve bağımlılık kullanan analiz modelleri geliştirin.

• Dağıtım işlem hatlarında en iyi eğitilen modelleri kaydedip dağıtarak modelleri kullanıma hazır hale getirme.

Sonraki adım

Güvenlikle ilgili dikkat edilmesi gereken noktaları gözden geçirin.

Güvenlik