Cutover Planı: Canlıya Geçişi Saat Saat Yönetmek

Cutover planı nedir ve neden ayrı bir belgedir?

Yeni bir sistem testten geçmiş olabilir; ama canlıya geçiş ayrı bir iştir. Veri taşınır, kullanıcılar eski sistemden çıkarılır, entegrasyonlar yeni uç noktalara yönlendirilir, erişimler açılır. Bunların hepsi belirli bir sırayla ve çoğunlukla dar bir zaman penceresinde yapılır. Cutover planı bu sırayı, sorumluları ve kontrol noktalarını yazıya döker.

İyi bir plan şu soruları yanıtlar. Hangi adım kimin? Hangi adım bitmeden diğeri başlayamaz? Her adım ne kadar sürer? Adımın başarılı olduğu nasıl anlaşılır? Sorun çıkarsa kime haber verilir ve kim karar verir? Bu cevaplar tek bir çalışma çizelgesinde birleşir. Geçiş gecesi ekip bu çizelgeyi izler, her adımın bitişini işaretler.

Plan, proje planından ayrıdır, çünkü ayrıntı düzeyi çok farklıdır. Proje planı geçiş tarihini gösterir; cutover planı o tarihin gece yarısından sabaha kadar olan saatlerini adım adım gösterir. Planı yazan kişi genellikle proje yöneticisi ya da geçiş koordinatörüdür, ancak her adımı o adımın uygulayıcısı onaylar.

Geçişin evreleri: hazırlıktan hiperbakıma

Canlıya geçiş tek bir an değil, birbirine bağlı bir dizi evredir.

Hazırlıkta kapsam, bağımlılıklar ve riskler belirlenir; kullanıcılar bilgilendirilir, eğitimler ve erişimler hazırlanır. Prova evresinde geçiş canlıya benzer bir ortamda denenir ve plan düzeltilir. Dondurma evresinde kaynak sistemde değişiklik durdurulur ve son veri alınır. Geçiş evresi asıl devirdir: veri taşınır, yapılandırma uygulanır, entegrasyonlar açılır, doğrulama testleri çalışır. Hiperbakım evresinde ekip canlı sistemi yakından izler, gelen sorunlara öncelikli yanıt verir.

Her evrenin çıkış ölçütü olmalıdır. Prova başarısız olduysa dondurmaya geçilmez. Doğrulama testleri geçmeden kullanıcılara erişim açılmaz. Hiperbakım, sorun akışı normale döndüğünde ve destek ekibi devralmaya hazır olduğunda kapanır.

Prova: planı gerçekten sınamak

Cutover planlarının en büyük zayıflığı yalnızca kâğıtta var olmalarıdır. Prova, geçişi canlıya olabildiğince yakın bir ortamda ve gerçek veriye benzer bir hacimle uygulamaktır. Bu sırada üç şey ortaya çıkar.

Birincisi süreler: veri aktarımının planlanandan uzun sürdüğü ancak provada anlaşılır. İkincisi bağımlılıklar: bir adımın başka bir adımı beklediği unutulmuşsa prova bunu gösterir. Üçüncüsü eksik izinler, betik hataları ve belirsiz sorumluluklar gibi küçük ama geçişi durdurabilecek sorunlardır.

Prova sonrası sonuçlar plana yansıtılır ve gerekirse prova tekrarlanır. Provada ölçülen süre, geçiş penceresinin yeterli olup olmadığını belirler; sığmıyorsa pencere genişletilir ya da işin bir kısmı önceden yapılır. Prova ekibi geçiş ekibiyle aynı olmalıdır, çünkü insanlar planı uygulayarak öğrenir.

Provanın bir diğer çıktısı doğrulama listesidir. Hangi testlerin hangi sırayla çalıştırılacağı, başarı ölçütlerinin ne olduğu ve kimin onaylayacağı provada netleşir.

Go/no-go ve geri dönüş noktası

Geçiş gecesi iki karar önceden yazılı olmalıdır. Birincisi go/no-go: geçişe başlanacak mı? Karar, hazırlık kontrol listesine bakılarak verilir: prova başarılı mı, kritik hatalar kapandı mı, kullanıcılar ve destek ekibi hazır mı, geri dönüş planı sınandı mı?

İkincisi geri dönüş noktasıdır. Geçişin belirli bir anından sonra eski sisteme dönmek ya veri kaybına ya da tutarsızlığa yol açar. Örneğin yeni sistemde gerçek işlem girilmeye başlandıktan sonra eski sisteme dönmek, o işlemleri geri taşımayı gerektirir. Bu nokta önceden belirlenir ve ondan önce geri dönüş planı eksiksiz hazır tutulur.

Geri dönüş noktasından önce kritik sorun çıkarsa plan basittir: geri dön, nedenini incele ve yeniden planla. Noktadan sonra ise eski sisteme dönmek yerine ileriye doğru düzeltmek gerekir; bunun için hızlı düzeltme yetkisi ve ekibi baştan belirlenmelidir. Her iki yolda da kararı kimin vereceği ve ne kadar süre bekleneceği yazılı olmalıdır, çünkü gece yarısı yorgun bir ekip kararı tartışarak veremez.

Hiperbakım: canlıya geçişten sonra

Sistem canlıya alındığında iş bitmez. İlk günlerde gerçek kullanıcılar, test edilmemiş veri kombinasyonları ve beklenmeyen kullanım biçimleri sorun çıkarır. Hiperbakım, bu dönemi yönetmek için planlanan yoğun destek evresidir.

Bu dönemde proje ekibinin bir kısmı hâlâ hazırdır, destek talepleri öncelikli ele alınır ve sistem izlenir. Sorunlar bir listede toplanır: kimin, ne zaman, hangi önceliğe göre çözeceği yazılıdır. Kullanıcılara duyuru, kısa kullanım notları ve sık sorunlar için hızlı yanıtlar hazırlanır.

Hiperbakımın kapanış ölçütü önceden belirlenmelidir: yeni sorun akışının azalması, kritik sorunların kapanması, destek ekibinin süreçleri devralmaya hazır olması gibi. Kapanışta açık işler destek ekibine, bilinen sorunlar listesiyle birlikte devredilir. Devir yapılmazsa proje ekibi dağıldığında sorunlar sahipsiz kalır.

Geçişin sonunda toplanan dersler bir sonraki projeye taşınır: hangi adımlar planlanandan uzun sürdü, hangi riskler yaşandı, hangi iletişim eksikti?

Sık hatalar ve kontrol listesi

Cutover planlarında sık görülen hatalar şunlardır.

• Provayı atlamak ya da yalnızca bir parçasını denemek.
• Geri dönüş noktasını belirlememek; sorun çıkınca ne yapılacağı tartışmaya açık kalır.
• Süreleri iyimser tahmin etmek ve pencerede tampon bırakmamak.
• İletişim planını unutmak; kullanıcılar ve paydaşlar geçişin ne zaman olduğunu, ne beklemeleri gerektiğini bilmez.
• Kritik rolleri tek kişiye bağlamak; o kişi o gece ulaşılamazsa süreç durur.
• Hiperbakımı planlamamak ve proje ekibini geçişten hemen sonra dağıtmak.

Kısa bir kontrol listesi: adımların sahibi ve süresi yazılı mı, prova yapıldı mı, go/no-go ölçütleri belli mi, geri dönüş noktası ve planı hazır mı, iletişim hazır mı, hiperbakım ve devir planlandı mı? Yanıtlardan biri hayırsa geçiş tarihi yeniden düşünülmelidir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

IT Proje Yönetimi Sertifika Programı, yazılım geliştirmeye yönelik proje yönetimi ilkelerini, kalite güvence ve test yönetimini, IT proje planlama ve takvimlendirme uygulamasını kapsar. Canlıya geçiş planı bu birikimin son halkasıdır: test sonuçlarını, riskleri ve takvimi tek bir geçiş çizelgesinde birleştirmek proje yöneticisinin işidir.