Kısa cevap: Bağımlılık haritası, bir uygulamanın çalışması için gerekli veri, kimlik, ağ ve dış servisleri gösterir. Yalnızca sunucu listesini taşımak, arka plandaki görevleri ve kullanıcı akışlarını hedef ortama taşımaya yetmeyebilir.
Bu çalışma ne zaman gerekli?
Geçiş kapsamını uygulama sahibiyle birlikte oluşturun. Sunucu adını değil giriş, sipariş, rapor ve dosya erişimi gibi tamamlanan iş akışını başlangıç noktası yapın.
Geçiş bağlamında değerlendirme
Geçiş planının odağında çalışan bir iş akışının korunması bulunur. Sunucunun açılması, kullanıcının giriş yapabildiği, verinin doğru göründüğü ve gece görevlerinin tamamlandığı anlamına gelmez. Teknik uygulayıcıyla iş sahibinin kabulü ayrı kaydedilmelidir. Pilotun veri kapsamı, kullanılan sürüm ve erişim yolu yazılırsa sonuçların nerede geçerli olduğu anlaşılır. Kaynak ve hedef aynı anda değişiyorsa son doğrulamanın hangi zamana ait olduğu özellikle belirtilmelidir. Eski ortamın ne zaman kapatılacağı, yeni verinin nasıl korunacağı ve sorun halinde kararın kimde olduğu önceden belli olsun. Parola ve hassas kayıtları geçiş belgesine eklemeyin; güvenli erişim kaynağına referans verin. Küçük bir teknik belirsizliği geçiş gününe bırakmak yerine açık iş olarak sahiplenin.
Somut kontrol tablosu
| Başlık | İnceleme ve beklenen çıktı |
|---|---|
| Veri bağlantısı | Veritabanı, dosya paylaşımı ve arşivin adresini, yetki modelini ve erişim yönünü kaydedin. |
| Kimlik akışı | Kullanıcı oturumu, servis hesabı ve zaman eşitleme bağımlılıklarını ayrı gösterin. |
| Zamanlanmış işler | Gece çalışan rapor, aktarım ve entegrasyon görevlerini normal kullanım testine ekleyin. |
| Dış servis | API, lisans ve e-posta bağlantılarında adres veya çıkış IP kısıtı olup olmadığını sorun. |
Çalışmayı hangi sırayla yürütmelisiniz?
- Başlangıcı kaydedin. Etkilenen sistem, sürüm, iş akışı ve sorumluları belirleyin. Varsayımları ölçülmüş veriyle karıştırmayın.
- Küçük kapsamla deneyin. Gerekli onayları aldıktan sonra temsili pilot seçin. Üretim verisi ve erişimlerini kurumun güvenli yöntemleriyle koruyun.
- Sonucu karşılaştırın. Aynı işi önce ve sonra değerlendirin. Tek bir başarılı denemeyi bütün koşullar için garanti saymayın.
- Açık işleri devredin. Eksik kalan başlığa sorumlu ve hedef tarih verin. Geçici istisnaları görünmez hale getirmeyin.
Örnek karar senaryosu
Örnek bir stok uygulaması gündüz doğru çalışırken gece dosya paylaşımından veri alıyor olsun. Pilot sadece kullanıcı girişini denerse bu görev gözden kaçar. Harita, dosya kaynağıyla gece görevini aynı kabul senaryosuna bağlar.
Bu senaryo açıklama amacıyla oluşturulmuştur; gerçek müşteri projesi veya ölçülmüş başarı iddiası değildir.
Hangi yanılgıdan kaçınmalısınız?
Güvenlik gerekçesiyle bütün bağlantıları geçiş günü açmak yerine, gerekli akışları önceden çıkarın. Parolaları diyagrama eklemeyin; erişimlerin güvenli kaynağına ve sorumlusuna referans verin.
Kabul ölçütü ve teslim kaydı
Haritadaki her kritik bağlantının hedef ortamda sahibi, gerekli erişimi ve doğrulama işlemi tanımlı olmalıdır.
Teslim notunda ölçüm tarihi, kullanılan veri kapsamı, yapılan değişiklik, doğrulanan iş ve kapsam dışında kalan durumlar bulunsun. Başarısız veya denenmemiş adımları başarılı gibi göstermeyin. Aynı konu başka ekip tarafından ele alındığında tekrar başlangıç araştırması yapılmaması için ilgili talep ve belge bağlantılarını koruyun. Kontrolün ne zaman yeniden yapılacağı da belli olsun.
İlgili araç ve sonraki adım
İlgili ücretsiz CieloSync aracı ile başlangıç bilgilerinizi düzenleyebilirsiniz. Araç sonucu teknik uygunluk veya fiyat teklifi yerine geçmez. Kapsam için ilgili CieloSync çözümünü inceleyin; mevcut yapınızı değerlendirmek için bizimle iletişime geçin.
Teknik başvuru
Microsoft Cloud Adoption Framework. Resmî başvuru kavram ve ürün çerçevesini sağlar; bu rehberdeki örnekler ve işletim kontrol listesi CieloSync için özgün olarak hazırlanmıştır. Uygulamadan önce kullandığınız ürünün tam sürümüne ait belgeleri doğrulayın.