Azure Otomasyonu güvenilirliği

Azure Otomasyonu, sizin adınıza yönetim görevlerini çalıştıran bir hizmettir. Çalıştırmak istediğiniz runbook'lar olarak adlandırılan betikleri tanımlarsınız ve Azure Otomasyonu bu betikleri yürütmek için altyapı sağlar. Bu makale, hizmetin temel özelliği olan süreç otomasyonuna odaklanır. Müşteri tarafından yönetilen altyapıda çalışan hibrit runbook çalışanları, bu makalenin kapsamı dışındadır.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı Azure Otomasyonu nasıl dayanıklı hale getirilmeye başlandığı açıklanır. Ayrıca yedekleme ve geri yükleme seçeneklerini ve Azure Otomasyonu hizmet düzeyi sözleşmesi (SLA) hakkındaki önemli bilgileri açıklar.

Güvenilirlik için üretim dağıtımı önerileri

İşlem otomasyonu kullanan üretim iş yükleri için şu önerileri izleyin:

  • Betiklerinize uygun yeniden deneme mantığı ekleyerek, runbook’larınız Azure hizmetleri ve API’leriyle etkileşime girdiğinde oluşan geçici hataları ele alın.

  • Runbook’larınızı kesintilere karşı dayanıklı olacak şekilde tasarlayın. İş yeniden başlatmalarında ilerleme durumunu korumak için denetim noktalarını kullanın ve durum depolamanız gerekiyorsa dış depolamayı kullanın.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

Azure Otomasyonu dağıttığınızda, otomasyonunuzu çalıştıran kaynaklar için mantıksal bir kapsayıcı olan bir otomasyon hesabı oluşturursunuz.

  • Yapılacak işi temsil eden runbook'lar. Metin tabanlı runbook'lar, PowerShell veya Python ile yazılmış betiklerdir. Grafiksel runbook’lar grafiksel bir düzenleyici kullanılarak oluşturulur.
  • Modüller, bağlantılar, kimlik bilgileri, sertifikalar ve değişkenler dahil olmak üzere runbook'ların paylaştığı kaynaklar.
  • Zamanlamalar ve izleyiciler dahil, runbook’ların yürütülmesini başlatan kaynaklar.

Bu kaynaklar hakkında daha fazla bilgi için bkz. Azure Otomasyonu'de Runbook yürütme.

Bu makale, Azure Otomasyonu işlem otomasyonunun bir parçası olan bu özelliklerin güvenilirliğini ve dayanıklılığını kapsar.

Fiziksel mimari

Runbook’lar bilgi işlem altyapısında yürütülür. İşlem otomasyonu için iki dağıtım modeli vardır:

  • Bulut işleri (Microsoft yönetilen): Runbook'lar varsayılan olarak sağlanan Microsoft bulut altyapısında çalışır. Microsoft, bu altyapının yüksek kullanılabilirlik ve yönetiminden sorumludur. Bir runbook işi gönderdiğinizde, Azure Otomasyonu kullanılabilir işlem kaynakları havuzundan bir bulut işi ayırır, runbook'u yürütür ve ardından kaynağı havuza döndürür.

    Bulut işleri bazen çalışırken kesintiye uğrayabilir. Runbook'larınızı, bir işin farklı altyapıda yeniden başlatılabileceği ve önceki örnekte geçici depolama alanına yazılan verilerin artık erişilebilir olmadığı varsayımı üzerine tasarlayabilirsiniz.

  • Karma runbook çalışanları: Runbook'ları çalıştırmak için, Azure’daki, diğer bulutlardaki veya şirket içindeki sanal makinelerden oluşan kendi işlem altyapınızı isteğe bağlı olarak yapılandırabilirsiniz. Hibrit Runbook Worker'larını kullandığınızda, bunları güvenilirlik gereksinimlerinizi karşılayacak şekilde yapılandırmak sizin sorumluluğunuzdadır. Hibrit runbook çalışanları bu makalenin kapsamı dışındadır.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Etkileşimde bulundukları hizmet ve API'lerdeki geçici hataları işleyen runbook'lar yazmaktan siz sorumlusunuz. Metin runbook'ları için döngüleri ve hata işlemeyi kullanarak yeniden deneme mantığını uygulayın. Yönergeler ve örnekler için bkz. Zamana bağlı betikteki geçici hataları işleme. Grafik runbook’lar için, iş akışınızdaki etkinliklerin yeniden deneme davranışını yapılandırın. Yapılandırma ayrıntıları için bkz: Grafik runbook’larında Yeniden Deneme etkinliği.

Altyapı bakımı veya diğer platform olayları runbook işlerini kesintiye uğratabilir. Runbook’larınızı bu kesintileri yönetecek şekilde tasarlayın:

  • Denetim noktaları uygulayın. PowerShell iş akışı runbook'larında, iş akışınızdaki önemli noktalarda ilerlemeyi kaydetmek için denetim noktalarını kullanın. Bir iş kesintiye uğrar ve yeniden başlatılırsa, baştan başlamak yerine son denetim noktasından devam edebilir. Daha fazla bilgi için bkz. İş akışında denetim noktalarını kullanma.

  • İş sınırlarını anlama. Bulut işlerinin çalışma zamanı süresinde eşit paylaşım sınırları vardır. İş yürütme sınırları ve bunların nasıl zorunlu kılındıkları hakkında ayrıntılı bilgi için bkz. Runbook yürütme.

  • Kalıcı durumu harici olarak depolayın. İşler, çalıştırmalar arasında durumlarını korumaz. Bir iş kesintiye uğrar ve başka bir örnekte yeniden başlatılırsa, ilk çalıştırmada geçici depolamaya yazılan veriler kaybolabilir. İş çalıştırmaları arasında verileri kalıcı hale getirmek istiyorsanız, verileri Azure Blob Depolama veya veritabanı gibi dış depolama alanında depolayın.

Kullanılabilirlik alanı hatalarına dayanıklılık

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Desteklenen bölgelerde Otomasyon hesapları ve bulut işleri alanlar arası yedeklidir; bu da hizmetin kaynaklarınızı birden çok kullanılabilirlik alanına yaydığı anlamına gelir. Microsoft alanlar arası yedekliliği otomatik olarak etkinleştirir ve herhangi bir yapılandırma gerektirmez.

Bölge yedekli runbook'lar ve diğer kaynaklar dahil olmak üzere, otomatik olarak bölge yedekli olan bir Otomasyon hesabını gösteren diyagram.

Gereksinimler

Bölge desteği: Otomasyon hesabını aşağıdaki bölgelerden birine dağıttığınızda otomatik olarak alanlar arası yedekli olur:

Americas Europe Orta Doğu Africa Asia Pacific
Brazil South France Central Israel Central Güney Afrika - Kuzey Australia East
Canada Central Almanya Batı Merkez Qatar Central Central India
Central US Italy North Kuzey Çin 3
East US North Europe East Asia
Doğu ABD 2 Norway East Japan East
ABD'nin Güney Merkez Bölgesi Poland Central Korea Central
USGov Virginia, ABD Sweden Central Southeast Asia
Batı ABD 2 UK South
Batı ABD 3 West Europe

Desteklenen bölgelerin geçerli listesi için bkz. Azure Otomasyonu için kullanılabilirlik alanları desteği.

Cost

Alanlar arası yedeklilik için ek ücret alınmaz. İşlem otomasyonu için faturalama, işlerinizin ve izleyicilerinizin çalışma süresine dayanır. Daha fazla bilgi için bkz. Azure Otomasyonu fiyatlandırma.

Kullanılabilirlik alanı desteğini yapılandırma

Desteklenen bir bölgede bir otomasyon hesabı oluşturduğunuzda, hesap otomatik olarak bölge yedekli olarak oluşturulur. Alanlar arası yedekliliği devre dışı bırakamazsınız. Daha fazla bilgi için bkz. Azure Otomasyonu için kullanılabilirlik alanları desteği.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, otomasyon hesabınız alanlar arası yedekli olduğunda ve bölgedeki tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arası işlem: Otomasyon hesabı yönetim işlemleri ve bulut işleri, bölgedeki kullanılabilirlik alanları arasında otomatik olarak dağıtılır. Bir istek veya iş, herhangi bir kullanılabilirlik alanında bulunan herhangi bir örnek tarafından işlenebilir.

  • Bölgeler arası veri çoğaltma: Otomasyon hesabı yapılandırması, runbook betikleri ve otomasyon hesabınıza dağıttığınız diğer kaynaklar birden çok kullanılabilirlik alanında zaman uyumlu olarak çoğaltılır.

Bölge hatası sırasındaki davranış

Bu bölümde, otomasyon hesabınız alanlar arası yedekli olduğunda ve bölgedeki kullanılabilirlik alanlarından birinde kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Algılama ve yanıt: Azure Otomasyonu platformu, kullanılabilirlik alanındaki bir hatayı algılamaktan sorumludur. Bölge yük devretmesini başlatmak için herhangi bir işlem yapmanız gerekmez.
  • Notification: Microsoft bir bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Bununla birlikte, bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

  • Aktif istekler: Sağlıksız bölgedeki devam eden tüm iş çalıştırmaları kesintiye uğrayabilir. Azure Otomasyonu, iyi durumdaki bölgelerdeki altyapıyı kullanarak otomatik olarak yeni bir iş çalıştırması başlatır. Runbook'larınızı geçici hatalara ve kesintilere karşı dayanıklı olacak şekilde tasarlayın, böylece güvenli bir şekilde yeniden başlatılabilirler.

  • Beklenen veri kaybı: İş çalıştırmaları durumu kalıcı olarak saklamaz; bu nedenle bir bölgedeki arızanın devam eden işler için veri kaybına neden olması beklenmez. Bir işin denetim noktaları gibi kesintiden kurtarmak için kullanabileceği verileri depolaması gerekiyorsa, bu bilgileri Azure Depolama veya veritabanı gibi kalıcı bir bulut depolama hizmetinde depolayın.

    Otomasyon hesabı yapılandırması ve runbook verileri bölgeler arasında çoğaltılır ve bir bölge kullanılamadığında bile erişilebilir durumda kalır.

  • Beklenen kapalı kalma süresi: Bölge kesintisi sırasında, hizmet hatayı algılayıp iş yükünü sağlıklı bölgelere yeniden dağıtırken Otomasyon hesabınız kısa bir kesintiyle karşılaşabilir.

  • Yeniden dağıtım: Hizmet, kalan iyi durumdaki bölgelerde kapasiteyi otomatik olarak yeniden dengeler. Yeni iş çalıştırmaları, izleyiciler ve zamanlanmış görevler, sağlıklı bölgelerdeki altyapıda çalışmaya devam eder. Kurtarma, arızalı bölgenin yeniden hizmete dönmesine bağlı değildir.

Bölge kurtarma

Arızalı bir bölge yeniden hizmete girdiğinde, Azure Otomasyonu bu bölgeyi otomatik olarak bölge rotasyonuna yeniden dahil eder. Hiçbir işlem yapmanız gerekmez. Hizmet, bölgenin durumunu izler ve normal işlemler devam ettikçe iş yükünü tüm bölgeler arasında yeniden dağıtır.

Bölge hataları için test

Azure Otomasyonu alanlar arası yedekli kaynaklar için trafik yönlendirme, yük devretme ve bölge kurtarmayı yönetir. Hiçbir şey başlatmanız ve kullanılabilirlik alanı hata işlemlerini doğrulamanız gerekmez. Kesintilere dayanıklı olduklarını onaylamak için runbook'larınızı test edin.

Bölge genelindeki hatalara dayanıklılık

Azure Otomasyonu tek bölgeli bir hizmettir. Bölge kullanılamaz duruma gelirse Otomasyon hesabınız da kullanılamaz.

Dayanıklılık için özel çoklu bölge çözümleri

Farklı Otomasyon hesaplarını birden çok bölgeye dağıtabilir ve gerektiğinde bunlar arasında geçiş yapabilirsiniz. Hesapları her bölgeye dağıtmak, uygun şekilde yapılandırmak, istekleri hesaplar arasında dağıtmak ve bir bölge kullanılamıyorsa yük devretmeyi işlemek sizin sorumluluğundadır. Göz önünde bulundurabileceğiniz yaklaşımlar hakkında ayrıntılı bilgi için bkz. Azure Otomasyonu için olağanüstü durum kurtarması.

Yedekleme ve geri yükleme

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

Azure Otomasyonu, Otomasyon hesabı yapılandırmanız veya runbook içeriğiniz için yerleşik yedekleme sağlamaz. Gerekirse yeniden dağıtabilmeniz için kendi kopyalarınızı hizmetin dışında tutun.

  • Otomasyon hesabı yapılandırması için kod olarak altyapı (IaC) kullanın. Bicep dosyalarında, ARM şablonlarında veya Terraform'da otomasyon hesaplarını ve ilgili kaynakları tanımlayın. Şablonları kaynak denetiminde depolayın ve ortamı aynı veya başka bir bölgede yeniden oluşturmak için dağıtım işlem hattınızı kullanın. Artefaktlarınıza ve dağıtım süreçlerinize sertifikalar, değişkenler, zamanlamalar ve kimlik bilgisi referansları dahil edin. Değerleri doğrudan runbook koduna eklemek yerine Azure Key Vault gibi hizmetlerde gizli dizileri depolayın.

  • Runbook betiklerini sürüm denetiminde depolayın. PowerShell ve Python runbook'larının kaynağını Git gibi bir kaynak denetim sisteminde tutun. Betik kalitesini korumak ve kararlı olduğu bilinen sürümlere geri dönmeyi mümkün kılmak için sürüm kontrolü, dallanma ve pull request incelemesini kullanın.

  • Durumu uygun veri deposundan yedekleyin. İşler durumlarını korumaz. Ayrıntılı iş günlüklerini veya runbook'larınızın oluşturduğu diğer verileri tutmanız gerekiyorsa, bunu başka bir Azure depolama alanında veya veritabanı hizmetinde depolayın ve oradan yedekleyin.

Yanlışlıkla silmeye dayanıklılık

Otomasyon hesabını yanlışlıkla silerseniz, sınırlı bir süre içinde geri yükleyebilirsiniz. Daha fazla bilgi için bkz. Silinmiş otomasyon hesabını geri yükleme.

Hizmet bakımına dayanıklılık

Microsoft düzenli olarak hizmet güncelleştirmeleri uygular ve başka bakımlar gerçekleştirir. Azure platformu bu etkinlikleri otomatik olarak işleyerek bakımın sizin için sorunsuz ve şeffaf olmasını sağlar. Azure Hizmet Durumu planlı bakım aracılığıyla size bildirilmedikçe, bakım olayları sırasında kapalı kalma süresi olmayacağı öngörülmektedir.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA’lar.

İlgili içerik

  • Last updated on