Buluta Taşıma Kontrol Listesi: Değerlendirmeden Geçişe Hangi Adımlar Sırayla Atılır?

Buluta taşıma kontrol listesi hazırlamadan başlayan göç projeleri çoğu zaman aynı yerde tıkanır. Hangi sunucunun hangi uygulamaya hizmet ettiği bilinmez, bağımlılıklar geçiş gecesinde ortaya çıkar, geri dönüş planı yazılı değildir. Sorun çoğunlukla teknolojiden değil sıradandır: adımlar yanlış sırayla atıldığında maliyet, kesinti ve güvenlik riski birlikte büyür. Bu yazıda BT yöneticileri için envanter, değerlendirme, geçiş planı ve geçiş sonrası doğrulama adımlarını sırayla özetliyoruz.

Her adımın ayrıntılı sürümü için Buluta Taşıma Kontrol Listesi: Değerlendirmeden Geçişe bilgi bankası yazısına da göz atabilirsiniz.

01Buluta taşıma kontrol listesi envanterle başlar

Envanter çıkarılmadan yapılan her plan tahmine dayanır. İlk hafta teknik bir araca değil, doğru soruları sormaya ayrılmalıdır. Aşağıdaki başlıkları her sistem için kayıt altına alın:

• Varlık listesi: sunucular, sanal makineler, veritabanları, depolama alanları, ağ cihazları ve her birinin sorumlusu.
• Bağımlılık haritası: hangi uygulama hangi veritabanına, hangi dış servise, hangi zamanlanmış göreve bağlı.
• Veri sınıfı: kişisel veri, özel nitelikli veri, finansal veri ve herkese açık veri ayrımı.
• Lisans durumu: mevcut lisansların bulut ortamında geçerli olup olmadığı.
• Kapasite ve yük: işlemci, bellek, disk ve ağ kullanımının ortalama ve tepe değerleri.
• Sahipsiz kaynaklar: kimsenin sahiplenmediği, ama çalışmaya devam eden sunucular.

Somut bir örnek: Ay sonunda yalnızca bir kez çalışan bir raporlama betiği, gündelik izlemede görünmez. Kapasite verisini en az bir tam iş döngüsü boyunca, ay sonu kapanışı dahil toplamazsanız bu betiği envanterde kaçırabilirsiniz. Geçişten sonra raporlar boş gelir ve sorun ancak kapanış günü fark edilir.

02Değerlendirme: Her iş yükü için doğru stratejiyi seçin

Envanter tamamlandıktan sonra her iş yükü için bir taşıma stratejisi belirlenir. Büyük bulut sağlayıcılarının benimseme çerçeveleri, bu karar için benzer adlandırmalar kullanır. Ayrıntılar için AWS Cloud Adoption Framework ve Microsoft Cloud Adoption Framework göç bölümü belgelerine bakabilirsiniz. Genel yaklaşımı aşağıdaki tablo özetler:

Stratejiyi seçerken şu soruları yazılı yanıtlayın:

• İş yükü ne kadar kritik ve duruş hâlinde iş ne kadar etkilenir?
• Her sistem için kabul edilebilir veri kaybı (RPO) ve geri dönüş süresi (RTO) nedir?
• Kişisel veri içeriyorsa hangi bulut bölgesi uygundur?
• Bulut maliyeti, mevcut işletme maliyetiyle aynı kalemler üzerinden karşılaştırıldı mı?

Kişisel veri içeren iş yüklerinde bölge seçimi, Kişisel Verileri Koruma Kurumu yayınlarında yer alan, verilerin yurt dışına aktarımına ilişkin hükümlerle birlikte değerlendirilmelidir. Bu değerlendirmeyi hukuk danışmanınızla birlikte yapmanızı öneririz. Mimari karar için genel çerçeve olarak Google Cloud Architecture Center göç rehberi de başvuru kaynağı olabilir.

03Geçiş planı: Sıra, geri dönüş ve sorumluluklar

Değerlendirme çıktısı bir listeye değil, bir takvime dönüşmelidir. Aşağıdaki sıra çoğu proje için işleyen bir iskelet sunar:

1. Hedef ortamı hazırlayın: hesap yapısı, ağ, kimlik ve yetkilendirme, günlük kaydı ve bütçe uyarıları taşımadan önce kurulur. Mümkünse altyapıyı kodla tanımlayın; böylece ortam tekrarlanabilir olur.
2. Küçük bir pilot seçin: iş etkisi düşük, bağımlılığı az bir sistemle süreci deneyin. Pilot, ekibin eksik yetkilerini ve ağ kurallarını erken gösterir.
3. Dalgalara bölün: birbirine bağlı sistemleri aynı dalgada taşıyın. Bağımlılık haritası bu gruplamanın temelidir.
4. Veri senkronizasyonunu planlayın: ilk kopyalama ile son kesme arasındaki farkın nasıl kapatılacağını belirleyin. Kesme penceresi ne kadar kısa olacaksa senkronizasyon o kadar özenli kurgulanmalıdır.
5. Geri dönüş kriterini önceden yazın: hangi testin başarısız olması hâlinde eski ortama dönüleceğini, kim tarafından ve hangi adımlarla yapılacağını geçiş gününden önce belirleyin.
6. İletişimi ve rolleri netleştirin: geçiş penceresi boyunca kimin karar verdiği, kullanıcıların nasıl bilgilendirileceği ve iş birimi onayının kimden alınacağı yazılı olsun.

Geçiş sürecinde dağıtımların elle değil, bir CI/CD hattı üzerinden yapılması hata riskini azaltır ve her adımı izlenebilir kılar. Hat henüz yoksa göçle birlikte kurmak mantıklı bir fırsattır.

04Geçiş sonrası doğrulama: Taşıdık demek yeterli değildir

Sistemin açılması, göçün tamamlandığı anlamına gelmez. Doğrulama aşamasını da planın bir parçası olarak takvime koyun:

• İşlevsel doğrulama: kritik iş akışlarını (sipariş, fatura, raporlama, entegrasyonlar) iş birimleriyle birlikte uçtan uca deneyin.
• Performans karşılaştırması: yanıt süreleri ve kaynak kullanımını envanter aşamasında topladığınız referans değerlerle kıyaslayın.
• Yedekten geri dönüş testi: yedek alındığını görmek yetmez, bir yedeği gerçekten geri yükleyip çalıştığını doğrulayın. Yedekleme stratejisi için 3-2-1 kuralı rehberine bakabilirsiniz.
• Güvenlik gözden geçirmesi: yetkilerin gereğinden geniş olmadığını, gereksiz açık portların bulunmadığını ve günlük kayıtlarının toplandığını kontrol edin. Bulut güvenliği için sağlayıcıların yayımladığı mimari ilkeler iyi bir başlangıçtır; örneğin AWS Well-Architected Framework güvenlik, dayanıklılık ve maliyet başlıklarını ayrı ayrı ele alır.
• Maliyet izleme: ilk faturayı beklemeden bütçe uyarılarını ve etiketlemeyi kontrol edin. Kullanılmayan kaynakları erken kapatmak kolaydır.
• Eski ortamın kapatılması: eski sistemleri hemen silmek yerine, doğrulama tamamlanana kadar salt okunur bırakın ve kapatma tarihini yazılı onayla belirleyin.
• Dokümantasyon: yeni mimari şemasını, erişim yetkilerini ve olay anında izlenecek adımları güncelleyin.

Başarılı bir göç, canlıya geçiş gününde değil, geçişten sonraki ilk iş döngüsünün sorunsuz kapanmasıyla anlaşılır.

05Sık sorulan sorular

Buluta taşıma ne kadar sürer?

Süre, sistem sayısına, bağımlılıkların karmaşıklığına ve seçilen stratejiye göre değişir. Envanter ve değerlendirme tamamlanmadan gerçekçi bir takvim çıkarmak mümkün değildir; bu nedenle önce kapsamı netleştirmenizi öneririz.

Tüm iş yüklerini buluta taşımak zorunda mıyım?

Hayır. Bazı sistemler düzenleyici, performans veya maliyet nedenleriyle şirket içinde kalabilir. Değerlendirme aşamasında her iş yükü için taşımak, dönüştürmek, kapatmak ya da yerinde tutmak seçeneklerinden biri gerekçesiyle seçilir. Karma yapı da geçerli bir sonuçtur.

Geçiş sırasında kesinti kaçınılmaz mı?

Her iş yükü için farklıdır. Veri senkronizasyonu ve kısa bir kesme penceresiyle kesinti azaltılabilir; ancak hiç kesinti olmayacağını önceden söylemek doğru olmaz. Pencerenin süresi, geri dönüş kriteri ve iş birimi onayı geçişten önce yazılı hâle getirilmelidir.

06Sonuç

Buluta taşıma kontrol listesi dört adımda özetlenebilir: envanteri ve bağımlılıkları çıkarın, her iş yükü için strateji seçin, geri dönüş kriteriyle birlikte dalgalı bir plan yapın ve geçişten sonra işlevi, güvenliği, yedeği ve maliyeti doğrulayın. OPEIS Teknoloji bulut göç stratejisi, AWS, Azure ve Google Cloud altyapı yönetimi, DevOps ve CI/CD hattı kurulumu ile maliyet optimizasyonu konularında destek verir. Hizmet kapsamını incelemek için Bulut Çözümleri sayfasını ziyaret edebilirsiniz.