Her projeye aynı dört adımı uyguluyoruz. Ölçek ve iş türü değişse de akış aynı kalıyor. Bu sayfada adımların ne olduğunu değil, her adımda gerçekte ne yapıldığını ve nerede tökezlendiğini yazdık; çünkü geçiş planlarını çökerten şey adımların sırası değil, atlanan ayrıntılar oluyor.
Dört adım
1. Keşif görüşmesi
Mevcut altyapıyı, iş hedefini ve kısıtları birlikte tarıyoruz. Kritik iş yükleri, uyum gereksinimleri ve zaman baskısı bu adımda yazılı hale geliyor. Ücretsiz ve bir taahhüt doğurmuyor.
Bu adımın en değerli çıktısı envanter. Hangi sistem hangi sistemle konuşuyor, hangi veri nerede duruyor, hangi bağımlılık belgelenmemiş. Deneyimimize göre her kurumda yıllar içinde eklenmiş ve kimsenin haritasında olmayan bağlantılar bulunuyor; geçişi tökezleten şey genelde bunlar oluyor.
2. Teklif ve mimari önerisi
Ölçek, hizmet kapsamı, tahmini süre ve maliyet birlikte, tek belgede sunuluyor. Teknik yaklaşım ve varsayımlar açıkça yazılıyor. Onay bu belgenin imzalanmasıyla veriliyor.
Varsayımların yazılı olması önemli: teklif "şu veri hacmi, şu bağlantı hızı ve şu kapsam" varsayımıyla veriliyor. Bunlardan biri gerçekte farklı çıkarsa süre ve maliyet değişiyor, ve bunun neden değiştiği belgeye bakılarak gösterilebiliyor. Önerilen mimarinin nasıl göründüğünü referans mimariler bölümünde görebilirsiniz.
3. Kurulum ve geçiş
Test ortamında uçtan uca doğrulama, kesim penceresinin planlanması, geri alma planının yazılması. Canlıya geçiş ekipçe koordine ediliyor ve her adımın kaydı tutuluyor.
Test ortamı bu adımın atlanmaması gereken kısmı. Amacı yeni ortamın çalıştığını görmek değil, hangi ayrıntının farklı davrandığını bulmak. Karakter kodlaması, saat dilimi, dosya izinleri ve dış servis erişimleri en sık burada yakalanıyor; geçiş gecesinde yakalanmaları istenmeyen türden şeyler.
4. İşletim ve iyileştirme
SLA'lı 7 gün 24 saat izleme, düzenli olay raporu, kapasite ve maliyet trendinin takibi. Ay sonu raporunda ne yapıldığı, ne beklediği ve öneriler yazılı olarak paylaşılıyor. İşleyişin ayrıntısı destek ve hizmet seviyeleri sayfasında.
Kesim penceresi nasıl planlanıyor
Kesim penceresi, canlı trafiğin eski ortamdan yeni ortama geçtiği zaman aralığı. Uzunluğunu belirleyen asıl kalem taşınacak veri hacmi ve bağlantı hızı; bu ikisi baştan hesaplanmazsa plan tutmuyor.
Yaygın yaklaşım, verinin büyük kısmını önceden taşımak ve kesim gecesinde yalnızca aradaki farkı senkronlamak. Böylece pencere saatlerden dakikalara iniyor. Bu, veri tabanı gibi sürekli değişen sistemlerde ek hazırlık gerektiriyor ama kesinti süresini belirgin biçimde kısaltıyor.
Pencerenin ne zaman açılacağı işinize göre değişiyor. Yirmi dört saat çalışan bir tesiste pencere bulmak, mesai saatiyle çalışan bir ofisten çok daha zor; bunu üretim ve lojistik sayfasında ele aldık. Sağlık tarafında pencere genelde hafta sonu ve gece saatlerine denk geliyor.
Geri dönüş planı
Geri dönüş planı, geçiş planının ayrılmaz parçası ve yazılı olarak önceden paylaşılıyor. İçinde şunlar bulunuyor: hangi koşulda geri dönüleceği, kararı kimin vereceği, geri dönüşün kaç dakika süreceği ve o sırada üretilen verinin ne olacağı.
Son madde en çok atlanan kısım. Yeni ortamda birkaç saat çalışıldıktan sonra geri dönülürse, o saatlerde girilen veri eski ortamda yok. Bu yüzden geri dönüş kararının bir son kullanma tarihi oluyor: belirlenen süre geçtikten sonra geri dönmek yerine ileriye doğru düzeltmek tercih ediliyor.
Geri dönüş yolunun açık kalması, geçişin kademeli yapılmasının da temel gerekçesi. Taşınan iş yükünün eski ortamda bir süre daha ayakta bırakılması maliyet gibi görünüyor ama beklenmedik bir noktada tökezlendiğinde tek çıkış yolu o oluyor.
Geçişte neler ters gidiyor
Belgelenmemiş bağımlılıklar. Taşınan sistemin, kimsenin hatırlamadığı bir başka sisteme bağlı olduğu geçiş gecesinde ortaya çıkıyor. Envanter çalışmasının varlık sebebi bu.
Veri hacminin küçümsenmesi. Taşınacak verinin gerçek boyutu genelde tahmin edilenden büyük çıkıyor; log arşivleri ve eski yedekler hesaba katılmıyor. Bu, kesim penceresini doğrudan uzatıyor.
Adres çakışması. Hybrid kurulumlarda iki taraftaki ağ adreslemesi çakıştığında çözüm bir tarafı yeniden adreslemek oluyor, o da ayrı bir kesinti demek. Bu yüzden adresleme planı bağlantı kurulmadan önce yapılıyor; ayrıntısı hybrid cloud bağlantı sayfasında.
Ölçülmemiş taban çizgisi. Eski ortamda yanıt sürelerinin ne olduğu bilinmiyorsa, yeni ortam yavaş mı hızlı mı olduğu tartışma konusu oluyor. Geçiş öncesi ölçüm almak bu tartışmayı baştan bitiriyor.
Geçiş bitince ne oluyor
Geçişin bittiği gün işin bittiği gün değil. İlk hafta yakın izleme yapılıyor, alarm eşikleri yeni ortamın gerçek davranışına göre yeniden ayarlanıyor. Eski ortamdan taşınan eşikler çoğu zaman ya çok gürültülü ya çok sessiz kalıyor.
Eski ortamın kapatılması ayrı bir karar ve acele edilmiyor. Geri dönüş yolunun kapanması, geçişin gerçekten oturduğundan emin olunduktan sonra oluyor.
Sonrasında hangi katmandan kimin sorumlu olduğu sorumluluk paylaşımı sayfasındaki tabloya göre işliyor. Daha önce yaptığımız iş türlerini yaptığımız işler sayfasında, kesintisiz sürüm yükseltmenin nasıl yürüdüğünü bu yazıda bulabilirsiniz. Sektörünüze özel kısıtlar için çözümler sayfasına bakın.