Amazon Web Services'ten (AWS) Azure'a iş yükü geçişinizi planlama

Bu makale, iş yükünü Amazon Web Services'ten (AWS) Azure'a geçirme hakkında bir serinin bir parçasıdır.

Planlama aşaması şu adımlardan oluşur:

• İş yükünüzü değerlendirin.
• Benzer bir mimari tasarla.
• Geçiş planı geliştirin ve belgeleyin.

Planlama aşamasının amacı, mevcut AWS iş yükünüzü teknik ve iş açısından anlamaktır. Böylece Azure'da güvenle çoğaltacak bir plan oluşturabilirsiniz.

Önemli

Planlama aşamasında zamanınızı alın ve adımları sırayla izleyin. Eksik bulma veya belirsiz geçiş hedefleri yanlış hizalanmış beklentileri ve eksik bağımlılıkları riske atar.

AWS iş yükünüzü değerlendirme

Azure'da benzer bir sistem oluşturmak için öncelikle geçerli sisteminizi tam olarak anlamanız gerekir. Kullanıcıların, operatörlerin, geliştiricilerin, uyumluluk ve iş paydaşlarının ihtiyaçlarını eşit şekilde karşılayan bir Azure uygulaması tasarlamanızı sağlamak için bunu birden çok perspektiften değerlendirin.

1. Mevcut iş yükü mimarisini belgeleyin: İş yükü mimarinizi tam olarak belgeleyin ve doğrulayın. Ağ yapılandırmaları, veri akışları ve dış tümleştirmeler gibi tüm iş yükü bağımlılıklarını dahil edin.

2. Belge kimlik doğrulaması ve yetkilendirme: Değerlendirmenize kimlik ve erişim yönetimi (IAM) yapılandırmalarını ekleyin. AWS'nin kimlik doğrulaması ve yetkilendirmeyi nasıl işlediğine ilişkin kapsamlı belgeler, güvenli ve işlevsel bir Azure eşdeğeri tasarlama açısından kritik öneme sahiptir.

3. Bulma araçlarını kullanın: AWS iş yükünüzü görselleştirmek için AWS'de İş Yükü Bulma gibi AWS'ye özgü araçları kullanın. Bu araç iş yükünüzün bileşenlerini, bağımlılıklarını ve ilişkilerini tanımlamaya yardımcı olmak için AWS Config ve AWS Systems Manager verilerini kullanır. Daha fazla AWS iş yükü bileşenini keşfetmenize ve Azure'a özgü önerilerde bulunmanıza yardımcı olması için Azure Geçişi gibi Azure araçlarını kullanın.

4. Kritik akışları tanımlama: Temel kullanıcı ve sistem etkileşimlerini ve iş akışlarını eşleyin. Sonraki bölümde hedef mimariyi tasarlarken, bu bilgiler güvenilirlik çalışmalarını önceliklendirmenize ve en önemli ve etkili bileşenleri hataya karşı korumanıza yardımcı olur.

5. Ayrıntılı envanter oluşturma: Tüm sunucular, depolama bileşenleri, veritabanları ve hizmetler dahil olmak üzere iş yükünü çalıştırmak için geçerli AWS ortamınızın neye ihtiyacı olduğunu listeleyin. Ayrıca kullanım desenlerini, performans ölçümlerini ve lisanslama gereksinimlerini de içerir.

6. Konu uzmanlarını (KOBİ'ler) dahil edin: Otomatik bulma araçlarına ek olarak, gizli bağımlılıkları, karmaşık bileşen ilişkilerini ve hassas durumu ortaya çıkarmak için iş yükü ekibi genelinde uzmanlarla etkileşime geçin. Araçlar genellikle zamanlanmış betikler, belgelenmemiş tümleştirmeler veya eski yapılandırmalar gibi kritik bileşenleri kaçırır. KOBİ'lerle yapılan bir konuşma bu nüansları ortaya çıkararak geçiş sırasında beklenmeyen davranışları önleyebilir. Onların girdisini geçiş planına veya işletim kitabına ekleyin.

7. Ekibinizin becerilerini değerlendirin: Benzer özellik eşlemeye odaklanın. Ekibinizin AWS'de zaten kullandığı becerileri belirleyin ve bunları eşdeğer Azure hizmetleri ve araçlarıyla uyumlu hale getirme. İş yükü ve operasyon ekiplerinizi hazırlamak için proje zaman çizelgenize Azure eğitimi ekleyin. AWS'deki mevcut deneyim doğrudan yeni ortama aktarılabildiği için, bu yaklaşım sürtünmeyi azaltır ve Azure ile güven oluşturur.

8. Mevcut taahhütleri belgele: aktarım hızı, gecikme süresi, hata oranları ve kaynak kullanımı dahil olmak üzere iş yükünüzün tanımlı performans temelini belgeleyin. Bu temel performans göstergeleri (KPI) kullanılamıyorsa bu temeli oluşturmak için AWS ortamınızdan bu ölçümleri toplayın. Azure'daki iş yükünün AWS'deki gibi performans sergilediğini doğrulamak için bu KPI'leri geçiş sonrasında değerlendirme aşamasında kullanırsınız.

   İş yüküyle ilişkili hizmet düzeyi sözleşmeleri (SLA' lar) veya hizmet düzeyi hedefleri (SLO) olup olmadığını öğrenin. Kullanıcılara veya paydaşlara yönelik bu taahhütler bulut platformunuza göre değişmez. Örneğin AWS'deki kurtarma süresi hedefiniz (RTO) 45 dakikaysa Azure'da iş yükünü 45 dakikalık bir RTO'ya sahip olacak şekilde tasarlamanız gerekir.

9. Geçerli izleme ve uyarıyı belgele: AWS'de iş yükünü şu anda nasıl izlediğinizi belgeleyebilirsiniz. Örneğin CloudWatch ölçümlerini, alarmlarını veya panolarını kullanabilirsiniz. Hedef ortam için eşdeğer Azure izlemesini planlayın. Azure İzleyici günlüklerini, ölçümlerini veya Application Insights panolarını kullanabilirsiniz. Azure tabanlı izleme ve uyarıları uygulamaya ve yönetmeye hazır olmaları için bu değerlendirmede operasyon ekibinizle etkileşime geçin.

Azure'da benzer mimari tasarlama

Birçok bulut tabanlı modern iş yükü, işlevlerinin çoğu için sanal makineler (VM) yerine yönetilen veya sunucusuz hizmetler kullanır. AWS iş yükünüz Amazon Elastic Kubernetes Service (EKS) veya Amazon Elastic Container Service (ECS) gibi yönetilen hizmetler kullanıyorsa azureda kullanım örneğine uygun en iyi eşleşmeyi bulmanız gerekir. Bazı durumlarda Azure'da kapsayıcılı uygulamalar gibi seçebileceğiniz birden çok hizmet olabilir. En benzer hizmeti seçin. Örneğin, geçiş sırasında kapsayıcı düzenleme platformları arasında geçiş yapmayın.

Aşağıdaki diyagramda AWS ve Azure'da kubernetes iş yüküne benzer bir mimari gösterilmektedir.

Diyagramda AWS ile Kubernetes iş yükleri için Azure bulutları arasındaki benzer mimari gösterilmektedir. Sol tarafta AWS bulutu Amazon ECR, AWS IAM, AWS KMS ve Amazon CloudWatch içerir. Sanal özel bulutun (VPC) içindeki bir Amazon EKS kümesi, işlem düğümlerine ve ağ yük dengeleyicisine bağlanır. Sağ tarafta Azure bulutu Azure Container Registry, Microsoft Entra ID, Azure Key Vault ve Azure İzleyici'yi içerir. Sanal ağ içindeki Azure Kubernetes Service (AKS) kümesi özel uç noktaları, uygulama ağ geçidini ve düğüm havuzlarını içerir. Merkezde yöneticiler ve mühendisler altyapı otomasyonu için Terraform kullanır. AWS ile Azure arasında bağlantı, siteden siteye VPN, AWS Direct Connect ve Azure ExpressRoute aracılığıyla kurulur. Kullanıcılar diyagramın en üstünden etkileşim kurar.

Benzer mimarinizi eşlemeye başlamak için önce sağlam bir temel oluşturun.

Ağ iletişimi ile başlayın. İş yükünüzün ağ gereksinimlerini platform ekibiyle tartışın. Bu tartışmada hedef mimari ve geçiş bağlantısı ele alınmalıdır. AWS Transit Gateway, uç ağı olarak Amazon Virtual Private Cloud (VPC) ile ağ hub'ı görevi görür. Azure uygulama iniş alanı tasarımında platform ekibi, iş yükü ekiplerine bağlantılı sanal ağlar sağlar. Bu konuşma ağları, merkez veya Azure Sanal WAN ağı üzerinden diğer iç ve dış ağlarla iletişim kurar.

Geçiş sırasında veri alışverişi yapmak için, AWS Direct Connect ile siteden siteye sanal özel ağ (VPN) veya Azure ExpressRoute kullanabilirsiniz. Daha küçük veya kavram kanıtı (POC) geçişleri için siteden siteye VPN'ye güvenebilirsiniz. Üretim ölçeğinde geçişler veya büyük veri aktarımları için AWS Direct Connect ile ExpressRoute'u öneririz. Daha yüksek güvenilirlik için her iki seçeneği de kullanıyorsanız yük devretme için siteden siteye VPN kullanın.

Diyagramda AWS ile Azure bulutları arasındaki ağ bağlantısı gösterilmektedir. Etki Alanı Adı Sistemi (DNS) simgesi, solda VPC ile AWS buluta ve sağda bir sanal ağ ile Azure buluta bağlanır. Bulutlar arasındaki çift yönlü ok, siteden siteye VPN veya AWS Direct Connect ve ExpressRoute gibi güvenli bağlantı seçeneklerini gösterir.

Daha fazla bilgi için bkz. Ağı AWS'den Azure'a geçirme.

Ağınızı planladıktan sonra şu adımları izleyin:

1. Azure hizmetlerini tanımlama. İş yükünüzün Azure bileşenlerini seçmenize yardımcı olması için AWS-Azure kaynak karşılaştırma kılavuzunu kullanın. Güven kazanmak veya bileşenleri ve bunların yapılandırmasını seçmenize yardımcı olmak için POC'ler oluşturun. Benzer mimarinizin, platform özellikleri ve Azure'da en iyi yöntemler için işlevsel olarak eşdeğer ve iyileştirilmiş olduğundan emin olmak için Azure Well-Architected Framework hizmet kılavuzlarını kullanın.

2. Kimlik yönetimini planlama. Kullanıcılar ve iş yükü işlemleri için Azure'da kimlik ve erişimin nasıl işleneceğini planlayın. İş yükünüz AWS IAM rollerini veya federasyon kimlik sağlayıcılarını kullanıyorsa, bu rollerin Microsoft Entra Id rollerine, yönetilen kimliklere veya hizmet sorumlularına nasıl çevrildiğini belirleyin. Uygulamadaki sabit kodlanmış Amazon Kaynak Adlarını (ARN), IAM ilkelerini veya kimlik tümleştirmelerini gözden geçirin. Kimlik eşlemeyi göz ardı ederseniz geçiş sonrası erişim sorunları veya bozuk tümleştirmelerle karşılaşabilirsiniz. İş ortağı kimlik sağlayıcılarıyla tümleştirme, geçişler sırasında zorlu bir işlemdir. Mümkünse, Microsoft Entra Id'ye geçerek kimlik yönetimini birleştirin.

3. Geçiş kararlarınızı belgeleyin. Geçirmediğiniz kaynakları ve yaptığınız mimari kararları belgeleyin.

4. Riskleri azaltın. Yüksek riskli bileşenleri veya akışları belirleyin ve bu riskleri test etmek ve azaltmak için gerektiğinde POC'ler oluşturun. Olası hata noktalarını proaktif olarak bulmak ve bunların iş yükü güvenilirliğini nasıl etkilediğini değerlendirmek için bileşenlerde hata modu analizi (FMA) yapın. Azure bileşenleriniz yeni hata modlarına sahip olabilir veya AWS'deki karşılıklarından farklı başarısız olabilir.

5. Kullanılabilirliği denetleyin. Özellikle özel kaynak türlerini kullanmayı planlıyorsanız tercih ettiğiniz bölgede Azure hizmet kullanılabilirliğini ve kapasitesini denetleyin. Hedef bölgenizi seçtiğinizde, bölgenizi geçerli AWS bölgenizle yakın bir şekilde hizalayın. Coğrafi olarak benzer bir Azure bölgesine geçiş, tutarlı gecikme süresinin korunmasına yardımcı olur.

6. Gereksinimleri doğrulayın. Azure Geçişi'ni kullanmaya karar verirseniz AWS örneklerinizin işletim sistemi (OS) ve yapılandırma gereksinimlerini karşıladığından emin olmak için Azure Geçişi destek matrisini gözden geçirin. Azure Geçişi'ni kullanmıyorsanız iş yükünüzün Azure hizmetleriyle uyumluluğunu el ile denetleyin. Bu denetim desteklenen işletim sistemi sürümlerini, VM boyutlarını, disk yapılandırmalarını ve ağ bağımlılıklarını doğrulamayı içerir.

7. Uyumluluk ve güvenlik gereksinimlerini karşılayın. İş yükünüzde aynı güvenlik duruşu sağlayın. Azure uygulamanızın işletim sistemi güvenlik düzeltme eki uygulama, ağ yalıtımı, giriş ve çıkış denetimi, en az ayrıcalıklı erişim, statik kod analizi ve sızma testi zamanlamaları gibi güvenlik beklentileriyle eşleştiğinden emin olun.

   Geçişi kolaylaştırmak için oluşturduğunuz geçici altyapı, ağ bağlantıları ve işlemlerin de güvenlik beklentilerini karşıladığından emin olun. Geçişler kaotik olabilir ve geçiş sırasında güvenlikle ilgili bir gözetim veya kısayol bir olaya yol açabilir.

   AWS'nin kullandığı güvenlik modeli, Azure güvenlik modelinden önemli ölçüde farklıdır. Daha fazla bilgi için bkz . AWS'den güvenlik hizmetlerini geçirme.

Geçiş planı geliştirme ve belgele ve runbook oluştur

Bir geçiş planı geliştirin ve AWS'nizden Azure'a geçişiniz için bir runbook oluşturun. Geçiş stratejisini seçin, kurtarma noktası hedefi (RPO) gereksinimlerinize göre veri geçişi yaklaşımlarını seçin ve ayrıntılı bir runbook'ta belgeleme prosedürlerini yazın. Riski en aza indiren ve denetimli bir geçiş sağlayan kapsamlı, paydaş onaylı bir plan oluşturun.

Kesintisiz geçiş stratejiniz

AWS ortamından Azure ortamına üretim trafiğinin nasıl kesildiğini planlayın. Aşağıdaki yaklaşımlar en yaygın yaklaşımlardır:

• Big Bang geçişi: Bakım penceresi sırasında her şeyi aynı anda taşıyıp değiştirirsiniz.
• Aşamalı geçiş: İş yükü bileşenlerini aşamalı olarak geçirirsiniz.
• Mavi-yeşil geçiş (önerilir): İki ortam paralel olarak çalışır ve doğrulamadan sonra trafik üzerinden geçiş yapabilirsiniz.

Bir bakışta önemli farklar

Strateji	Kesinti süresi	Risk düzeyi	Maliyet etkisi	Geri alma kolaylığı
Büyük Patlama	High	High	Low	Zor
Aşamalı	Low	Orta	Orta	Orta
Mavi-yeşil	Low	Low	High	Easy

Riski düşük tutmak ve geri alma işlemini kolaylaştırmak için mavi-yeşil bir yaklaşım seçin. Bu senaryoda iki ortamı yönetirsiniz. Mavi, geçerli ortamdır (AWS), yeşil ise yeni ortamdır (Azure).

Mavi-yeşil senaryosunda bir geçiş penceresi planlayın, geçiş boyunca iş yükünüzü AWS'de çalıştırın ve başarılı bir kuru çalıştırmadan sonra trafiği Azure'a taşıyın. Her iki ortam da geçiş boyunca paralel olarak çalıştırıldığından, Azure ortamında sorun çıkması durumunda trafiği AWS'ye geri kaydırabilirsiniz. Bu senaryoda, değişebilecek durum için bir geri alma stratejisine de ihtiyacınız vardır. İleti kuyruklarındaki işlenmemiş öğeler gibi veritabanlarını ve daha az belirgin durumu göz önünde bulundurun.

İş yükünüz daha karmaşıksa ve riski en aza indirmek istiyorsanız mavi-yeşil stratejisini trafik üzerinden geçiş yapmak için bir kanarya yaklaşımıyla birleştirebilirsiniz. Kanarya yaklaşımı, trafiğin küçük bir yüzdesini yeni ortama yönlendirir ve ardından trafik akışını aşamalı olarak artırır. Geçiş sırasında hem AWS hem de Azure'da canlı durumun mevcut olması gerektiğinden kanarya yaklaşımı geçiş karmaşıklığını artırır.

AWS üzerinde herhangi bir bileşen Azure'da çalışan bileşenlerle birlikte bulunuyorsa, denetimli bir tam geçiş stratejisinin parçası olarak Strangler Fig cephesi gibi tasarım desenlerini uygulamayı göz önünde bulundurun. Geçişin sonraki aşamasında bu ek dolaylı katmanları uygularsınız.

Mavi-yeşil yaklaşımı, bir maliyet takası sağlar. Geçiş sırasında her iki bulut sağlayıcısı için de maliyetler doğurabilirsiniz. Çoğu ekip için, mavi-yeşil stratejisi riski ve operasyonel yükü azalttığı için ek maliyetler değerlidir.

Bakım penceresi planla

Hangi tam geçiş stratejisini kullanırsanız kullanın planlama aşamasında cömert bir bakım penceresi oluşturmanızı öneririz. Yeterli bir pencere, geçiş etkinliklerinin hassas doğasını göz önünde bulundurur ve geçiş sırasında işlevsellik kaybını hesaba katar. Veri kaybı, veri bozulması veya tutarsız kullanıcı deneyimleri riskini azaltan planlar geliştirmek için bu planlı kapalı kalma süresini kullanın. Örneğin, Amazon Simple Queue Service (SQS) iletilerini boşaltmak için bu zamanı kullanın.

İş yükünüzde bir kesinti bütçesi varsa, geçiş penceresini bu bütçenin dışında tutarak geçiş sonrası sorunlar için ayırmayı göz önünde bulundurun. Bu kararın sözleşme SLA'larını nasıl etkilediğini düşünün.

Veri geçiş stratejinizi seçin

Veri geçiş stratejiniz veri miktarına, veri depolama türüne ve kullanım gereksinimlerine bağlıdır. Çevrimdışı geçiş (yedekleme ve geri yükleme) ile canlı çoğaltma arasında karar verin.

Stratejiyi iş yükünüzün RPO'sununkiyle uyumlu hale getirme. Kullanımdan çıkarma aşamasında ve veritabanı geçiş stratejisini seçtiğinizde kararlara yol göstermek için iş yükünüzün RPO'suna bakın. RPO, geçiş sırasında kabul edebileceğiniz maksimum veri kaybı miktarıdır. Örneğin, RPO tam geçiş sırasında beş dakikadan fazla veri kaybına izin vermeyebilir. Kesmeden önce iş yükündeki durum değişikliği işlemlerini kapatarak veri kaybı riskini en aza indirin.

RPO ne kadar düşük olursa, sürekli çoğaltmayı veya son yedeklemeleri ve bakım pencerelerini o kadar dikkate almanız gerekir. Daha düşük GPO'lar, verilerinizi geçirme maliyetini ve çabasını da artırabilir.

Veritabanınızı taşıyın. Veritabanı geçişiniz için AWS ve Azure araçlarını değerlendirin. Örneğin, Sql Server için Amazon Relational Database Service'i (Amazon RDS) Azure SQL Veritabanı'na çoğaltmak için Azure Data Studio'yu kullanabilirsiniz. Bu özellik Amazon RDS'den SQL Veritabanı'na sürekli çoğaltmayı destekler. Alternatif olarak, kesme işlemi gerçekleştirilene kadar sürekli çoğaltma ve değişiklik verisi yakalama sağlayan AWS Veritabanı Geçiş Hizmeti'ni (AWS DMS) de kullanabilirsiniz.

Çoğu senaryoda, veri geçişi birden çok aşamada gerçekleşir. Örneğin, test ve doğrulama için bir ilk geçiş, ardından veri güncelliğini sağlamak için son tam geçiş veya sürekli eşitleme yapabilirsiniz. Bu yaklaşım, ekiplerin son tam geçiş öncesinde Azure'daki uygulama davranışını doğrulamasını sağlar. Ayrıca veri kaybı riskini azaltır ve geri alma planlamayı destekler.

Depolama verilerini aktarma. Depolama verilerini Amazon Simple Storage Service'ten (Amazon S3) Azure'a aktarmak için aşağıdaki seçenekleri göz önünde bulundurun.

Tool	Amaç
AzCopy	CLI kullanarak verileri toplu olarak hızla aktarır.
Azure Data Factory	Kurumsal düzeyde düzenleme ve dönüşüm ağırlıklı veri aktarımı sağlar.
AWS DataSync	Aws'den Azure'a dosya aktarımını ve yapılandırılmamış verilerin çoğaltmasını otomatikleştirir.

Tavsiye

AWS DataSync'i seçerseniz hazırlama aşamasında DataSync aracısını Azure'a dağıtmanız gerekir.

Bir bakım penceresi planlayın. Son sistem geçişi ve devre dışı bırakma adımlarınız için ayrılmış bir zaman dilimi planlayın. Geçişe başlamadan önce belgeleyin ve paydaşlarınızla iletişim kurun. Olası bir geri döndürme ve DNS değişikliği için zaman ekleyin.

Runbook'taki belge

Geçişe katılan tüm ekipler ve paydaşlarla paylaşmak için runbook'ta aşağıdaki bilgileri belgeleyin.

Adım dizisi: Adım dizisini üst düzeyde belgeleyin. Tam adımları, bunların sırasını ve geçiş zamanlamasını tanımlayın. Planlı bakım penceresini belgelerinize ekleyin. Özellikle karmaşık tam geçişler için bir kuru çalıştırma dahil etmeyi göz önünde bulundurun. Geri alma stratejinizi, DNS yaşam süresi (TTL) ve başarı ölçümlerini test etme adımlarını belgele.

Güvenlik ve ağ yapılandırması: Azure bağlantısını desteklemek için gereken tüm güvenlik duvarı kuralı değişikliklerini, gerekli bağlantı noktası açmalarını ve ağ güvenlik gruplarına (NSG' ler) veya uygulama güvenlik gruplarına (ASG) yönelik güncelleştirmeleri ekleyin. Sistem geçişi sırasında gereken geçici özel durumları veya geçersiz kılmaları belgeleyin ve geri alma yordamlarının bu değişikliklere uygun hale getirilmesini sağlayın.

Tamamlama onay kriterleri:Kararlı bir operasyonun ne anlama geldiğini tanımlayın ve bunu ölçülebilir hale getirin. Örneğin, tam geçişten sonra Azure'ın belirli bir dakika veya saat boyunca hatasız çalışması gerektiğini ve iş yükünün tüm testlerden geçtiğini kabul edin.

Geri alma tetikleyicisi ölçütleri ve adımları: AWS ortamına geri almayı tetikleyen koşulları tam olarak belgeleyin. Örneğin, herhangi bir kritik işlev devre dışıysa veya sistem belirli bir dakika sayısından daha uzun süre boyunca taban çizgisinin altındaki belirli bir yüzde kadar degradasyona uğramışsa, geri alma işlemi başlatın. Geri alma adımlarını belgeleyin.

Durum değişikliklerine bağlı olarak, geri alma işlemleri Azure'daki sorunu azaltmaktan daha karmaşık olabilir. Başarısız azaltma girişimleri de geri alma işlemini karmaşıklaştırabilir. Geçiş sırasında riski azaltmaya yardımcı olmak için bir sorunu ne zaman düzeltmeniz gerektiğini ve değişiklikleri ne zaman geri döndürmeniz gerektiğini anlayın.

İstemci yapılandırma değişiklikleri: İş yükü geçişinin etkilediği tüm istemciye yönelik yapılandırma öğelerini tanımlayın ve belgeleyin. Bu öğeler DNS uç noktalarını, kimlik doğrulama akışlarını ve bağlantı dizelerini içerir. İstemci ekiplerini erken dahil edin ve yaklaşan değişiklikleri, zaman çizelgelerini ve sorumlulukları iletin.

Trafik ve yönlendirme değişiklikleri: Trafik yönlendirme değişikliklerinizi ayrıntılı olarak planlayın ve belgelenin. Trafiği Azure'a yönlendirmek için DNS kayıtlarını, yük dengeleyici yapılandırmasını ve yönlendirme kurallarını tam olarak nasıl güncelleştirileceğini tanımlayın. DNS değişikliklerinin yayılması ne kadar süreceğini belirlediğinden yapılandırdığınız TTL değerlerini göz önünde bulundurun.

Birçok uygulama ve betik, uç noktalar, API'ler ve hizmetler için tam nitelikli etki alanı adları (FQDN) kullanır. Geçiş sırasında FQDN'ler beklenmedik şekilde değişirse tümleştirmeler bozulabilir. Yönlendirme ve tam geçiş planlamanızın bir parçası olarak, iş yükünüzün kullandığı tüm FQDN'lerin envanterini alın. YENI Azure FQDN'lerini kullanmak için DNS iletme veya uygulama yapılandırmalarını güncelleştirme yoluyla mevcut adların korunup tutulmayacağına karar verin. Genel kullanıma yönelik hizmetler için, kapalı kalma süresini en aza indirmek ve sorunsuz bir geçiş sağlamak için DNS tam geçişi dikkatle planlayın.

Dikkat

Trafik yönlendirmesini açıkça planlamayı ihmal etmek, beklenmeyen kapalı kalma süresine neden olabilecek yaygın bir tuzaktır.

Planı paydaşlarla gözden geçirin ve farklı beklentileri uzlaştırın. BT güvenlik ve risk yönetimi ekiplerini baştan dahil edin ve planı onayladıklarından emin olun. Bu aşamadaki bir ortak atölye, sonraki aşamalardaki gecikmeleri en aza indirmeye yardımcı olabilir.

Proje katılımcıları ve karar alıcılar plan ve runbook'u gözden geçirip üzerinde anlaşmaya vardıktan sonra hazırlama aşamasına geçin.

Çıkışlar ve üretilen ürünler

Planlama aşamasının sonunda aşağıdaki öğelere sahip olmanız gerekir:

• Hedef mimari diyagramı
• Mimari karar kayıtları (ADR)
• Bütçe ve maliyet tahminleri
• Geçiş kılavuzu ve zaman çizelgesi
• Geçiş planının paydaş onayı

Checklist

	Teslim edilebilir görevler
☐	Mevcut iş yükü mimarisini belgele
☐	Belge kimlik doğrulaması ve yetkilendirme
☐	Bulma araçlarını kullanma
☐	Kritik akışları tanımlama
☐	Ayrıntılı envanter oluşturma
☐	Uygulama ekibini dahil edin
☐	Becerileri değerlendirme
☐	Belge KPI'leri
☐	İzleme planı ve operasyon devretme
☐	Ağ adresleme
☐	Eşleşen Azure hizmetlerini tanımlama
☐	Kimlik yönetimini planlama
☐	Belge geçişi kararları
☐	Riskleri azaltma
☐	Kaynak kullanılabilirliğini denetleme
☐	Azure Migrate'i kullanıyorsanız gereksinimleri doğrulayın
☐	Uyumluluk ve güvenlik gereksinimlerini karşılama
☐	Kesintisiz geçiş stratejisini seçin
☐	Veritabanı geçiş stratejisini seçme
☐	Depolama geçiş stratejisini seçme
☐	Bakım penceresi planla
☐	Adımlardan oluşan belge sırası
☐	Belge güvenliği ve ağ yapılandırması
☐	Belge onay kabul kriterleri
☐	Belge geri alma tetikleyicisi ölçütleri ve adımları
☐	İstemci yapılandırma değişikliklerini belgeleyin ve iletin
☐	Trafik ve yönlendirme değişikliklerini belgele

Sonraki adım

İş yükü geçişi için hazırlanma