Bu makalede
Yeni sistem kendini kanıtlamadan eskisini kapatmazsanız işi durdurmadan geçersiniz: ikisini aynı gerçek işlemlerle çalıştırıp çıktılarını karşılaştırın, süreç sahiplerinin işaret ettiği nadir durumları test edin, her modül devreye girmeden önce insan onayı isteyin ve eski sistemi geri dönmeye hazır tutun. Microsoft, geçiş yürütme kılavuzunda, yeni sistemin geçişten sonraki ilk 24 ila 48 saat boyunca izlenmesini ve stabilizasyon süresince kaynak ortamın yedek olarak korunmasını önerir.
5. bölümde her sistem için bir yol seçtiniz. Bu bölüm, Eski sistemleri kesintisiz modernize etmek yazısında anlattığımız genel geçiş yöntemini tekrarlamıyor. Yeni olana odaklanıyor: yeni kodu yapay zekâ yazdığında ya da dönüştürdüğünde neyi test etmelisiniz?
Yapay zekânın dönüştürdüğü kod neden farklı test ister
Dönüştürme araçlarının ürettiği kod düzenli görünür ve ilk denemede çalışır; hatalarını görmeyi zorlaştıran da tam olarak budur. Hata günlük işlerde değil, ayda ya da yılda bir kez yaşanan durumda ortaya çıkar. Amazon, ana bilgisayar uygulamalarının dönüştürülmesi kılavuzunda, COBOL'dan Java'ya ilk dönüşümün aynı davranışı koruduğunu, ardından Reforge adlı bir adımın kodu modern Java tarzında yeniden düzenlemek için büyük dil modellerini kullandığını açıklar. COBOL, hâlâ pek çok banka ve ana bilgisayar sistemini çalıştıran eski bir programlama dilidir; ana bilgisayar (mainframe) ise büyük kuruluşların temel sistemlerinin çalıştığı büyük merkezi sunucudur.
Kodu yeniden yazan her adım küçük bir ayrıntıyı değiştirebilir. Bu yüzden bir geliştiricinin yeni kodu okuyup doğru göründüğünü söylemesi yetmez. Yönetimin tek bir sorusu vardır: yeni sistem aynı verilerle eskisiyle aynı sonucu veriyor mu? Cevap kodu okumaktan değil, çıktıları karşılaştırmaktan gelir.
Aynı gerçek işlemlerde çıktıları karşılaştırın
İşinizden kapanmış bir dönem alın, örneğin hesapları kapatılmış bir ay; o dönemin işlemlerini yeni sistemden geçirin ve çıkanı eskisinin ürettiğiyle karşılaştırın. Neyi karşılaştırmalı:
- Nihai rakamlar: dönem sonundaki fatura toplamları, bakiyeler ve stok.
- Raporlar: yönetimin dayandığı aylık raporlar, satır satır.
- Diğer sistemlere gidenler: bankaya, muhasebeye veya kamu portallarına gönderilen dosyalar ve mesajlar.
- Retler ve hatalar: eski sistemin reddettiği bir işlemi yeni sistem de aynı nedenle reddetmelidir.
Bazı araçlar karar vermeye değil, hazırlığa yardım eder. Örneğin ana bilgisayar için AWS Transform, kod özelliklerinden, iş karmaşıklığından ve zamanlayıcı yollarından 3 aşamada (yapılandırma, kapsam belirleme ve inceleme) bir test planı oluşturur, ardından ana bilgisayardan test verisi toplayan betikleri 4 aşamada üretir. Ancak Amazon aynı kılavuzda bu betiklerin sizin ana bilgisayarınızda ve ekibinizin yetkileriyle çalıştırılması gerektiğini belirtir. Araç hazırlar; ekibiniz çalıştırır ve karar verir. Verinin kendisini doğrulamak için Microsoft, hızlı kontrol olarak satır sayılarının, daha derin kontrol olarak da sağlama toplamlarının karşılaştırılmasını önerir: sağlama toplamı, verilerden hesaplanan ve tek bir karakter değişse bile değişen bir sayıdır.
Nadir durumlar: onları bilenlere sorun
Bir aylık gerçek işlem her şeyi içermez. Sistemleri bozan durumları geliştiriciler değil süreç sahipleri bilir: mali yıl sonu kapanışı, eski bir faturaya kısmi iade, özel fiyatlı bir müşteri, kayda alındıktan sonra iptal edilen bir fatura, ayın ortasında işe başlayan birinin maaşı. Her süreç sahibinden kendisini endişelendiren durumların listesini isteyin ve her birini, beklenen sonucu çalıştırmadan önce yazılmış bir teste dönüştürün.
Burada 4. bölümde doğruladığınız kurallar geri gelir: doğrulanan her kural en az bir test durumuna dönüşür. Testi olmayan bir kural, dönüşümden sağ çıktığını söyleyemeyeceğiniz bir kuraldır. Test türlerinin kendisi için yazılım testi ve kalite güvencesi rehberimize bakın.
Her modül için insan onayı
Bu ilkenin yayımlanmış en açık örneği, Thought Machine'in Amazon ile 29 Eylül 2026 tarihinde duyurduğu bankacılık geçiş hattıdır. Hat 4 aşamadan oluşur: AWS Transform ile eski uygulamalardan iş mantığının çıkarılması, yinelenen varyasyonların birleşik spesifikasyonlarda toplanması, yeni finansal ürünlerin ve test paketlerinin yapay zekâ ajanlarıyla üretilmesi ve hiçbir şey kabul edilmeden önce bankanın mühendislik ve risk ekiplerine açık onay yetkisi veren bir doğrulama aşaması. Onaydan sonra bile çıktı doğrudan canlıya değil, ek değerlendirme için yalıtılmış bir test ortamına gider.
Şirketiniz için ders ne banka ne de Amazon gerektirir: faturalama, bordro veya stok gibi sistemin her modülü devreye girmeden önce iki imza alır. Biri teknik, tüm testlerin çalıştırıldığını doğrular; diğeri süreç sahibinden, sonuçların iş açısından doğru olduğunu doğrular. Microsoft geçişten sonra aynısını ister: uygulama sahipleri tüm ana işlevlerin doğru çalıştığını teyit eder.
Paralel çalıştırma ve geri dönüş planı
Paralel çalıştırma, iki sistemin belirli bir süre yan yana çalışması ve eskisinin resmi referans olarak kalması demektir. Başlamadan önce bu sürenin ne zaman biteceğine ve hangi koşulun onu bitirmeye izin vereceğine karar verin; örneğin sonuçların işinizin tam bir döngüsü boyunca örtüşmesi. Ardından geçişi şöyle düzenleyin:
| Aşama | Ne yaparsınız | Kaynak |
|---|---|---|
| Geçişten önce | Geçiş planını, doğrulama prosedürlerini ve geri dönüş ölçütlerini gözden geçirmek için tüm destek ekipleriyle bir toplantı ve geçiş penceresi boyunca eski sistemde değişiklik dondurma | Microsoft |
| Geçiş günü | Trafiğin düşük olduğu bir saatte son senkronizasyon sırasında eski sisteme veri girişini durdurmak, herkese zamanlamayı bildirmek ve kullanıcıları yönlendirmeden önce verileri doğrulamak | Microsoft |
| Geçişten sonra | Temel süreçleri baştan sona test etmek, ilk 24 ila 48 saat boyunca performansı ve hataları izlemek ve eski sistemi geri dönüşe hazır tutmak | Microsoft |
Geri dönüş planı bir başarısızlık itirafı değil, bir sigortadır. Sizi geri döndürecek şeyi, örneğin faturalarda bir hata ya da temel bir sürecin durmasını, bu kararı kimin vereceğini ve kullanıcıların eski sisteme nasıl döneceğini önceden yazın. Stabilizasyon dönemi bitmeden eski sistemi kalıcı olarak kapatmayın. Bir geçişten sonraki ilk haftalarda genellikle neyin bozulduğunu Geçişten sonraki ilk otuz gün yazısında anlattık.
Origami'nin bakışı
Geçişi teknik bir olay olarak değil, bir yönetim kararı olarak ele alıyoruz. Bu yüzden iki sistem arasındaki karşılaştırmayı yeni sistemin kendisinden önce kuruyor, nadir durumları ve beklenen sonuçlarını süreç sahipleriyle erkenden kararlaştırıyoruz; böylece başarının tanımı, kimse sonuçları görmeden yazılı hâle geliyor.
Dönüşümü hızlandırmak ve test üretmek için yapay zekâ kullanıyoruz, ancak her modülün onayı ekibinizdeki isimleri belli kişilerde kalıyor. Nasıl çalıştığımızı görmek için hizmetlerimize göz atın.
Bu haftanın alıştırması: her modül için bir geçiş sayfası
5. bölümde dönüştürmeye veya yeniden kurmaya karar verdiğiniz her sistem için, herhangi bir geçiş tarihi belirlemeden önce bu sayfayı süreç sahipleriyle doldurun:
| Modül | Karşılaştırma dönemi | Nadir durumlar | Kim imzalar | Geri dönüş tetikleyicisi |
|---|---|---|---|---|
| Örnek: faturalama | Kapanmış bir ay | Kısmi iade, iptal edilmiş fatura | Finans müdürü ve teknik sorumlu | Fatura toplamlarında herhangi bir fark |
| Örnek: bordro | Tam bir bordro döngüsü | Ay ortasında işe giriş | İK müdürü ve teknik sorumlu | Bir net maaşta herhangi bir fark |
Bunlar açıklayıcı örneklerdir; sizin sayfanız farklı olacaktır. Önemli olan, her modülün isimleri belli iki imzacısı ve yazılı bir geri dönüş tetikleyicisi olmadan geçiş tarihinin belirlenmemesidir.
Sırada ne var
Her yöneticinin kodunu ve verisini bir yapay zekâ aracına göndermeden önce sorduğu bir soru kaldı: modernizasyon sırasında verilerim nereye gidiyor? Son bölüm olan 7. bölüm bu soruyu yanıtlıyor ve serinin tüm alıştırmalarını 90 günlük bir planda topluyor.
Kaynaklar
- Microsoft: Geçişi yürütme, Cloud Adoption Framework — geri dönüş ölçütleri toplantısı, değişiklik dondurma, veri doğrulama, 24 ila 48 saatlik izleme ve kaynak ortamın yedek olarak korunması.
- Amazon: AWS Transform'da ana bilgisayar uygulamalarının dönüştürülmesi — test planları, test verisi toplama betikleri ve Reforge adımı.
- Amazon: Thought Machine ve AWS'nin eski bankacılık sistemlerinin geçişine ilişkin duyurusu — dört aşama ve mühendislik ile risk ekiplerinin onayı.
- AWS Transform: resmi sayfa.
Sık sorulan sorular
İşi durdurmadan yeni bir sisteme nasıl geçerim?
İki sistemi belirli bir süre boyunca, eskisi referans olacak şekilde paralel çalıştırın, aynı işlemlerdeki çıktılarını karşılaştırın ve eskisini ancak süreç sahipleri onay verdikten ve stabilizasyon dönemi bittikten sonra, yazılı bir geri dönüş planıyla kapatın.
Yapay zekânın dönüştürdüğü kodu bir geliştiricinin incelemesi yeterli mi?
Hayır. Hatalar kodu okurken değil, nadir durumlarda ortaya çıkar. Ölçüt, yeni sistemin aynı verilerle eskisiyle aynı sonuçları vermesi ve bunun süreç sahibi tarafından onaylanmasıdır.
Geçişten sonra yeni sistemi ne kadar süre izlemeliyim?
Microsoft, geçişten sonraki ilk 24 ila 48 saat boyunca performansın, hata oranlarının ve kullanıcı erişiminin izlenmesini, stabilizasyon süresince kaynak ortamın yedek olarak hazır tutulmasını önerir.
Geri dönüş planı nedir ve neden gerekir?
Sizi eski sisteme döndürecek durumu, bu kararı kimin vereceğini ve kullanıcıların nasıl geri döneceğini önceden yazılı olarak belirleyen bir karardır. İş sürekliliği için bir sigortadır, başarısızlık itirafı değil.
Origami'yi Google'da takip edin
Origami'yi tercih ettiğiniz kaynak olarak ekleyin; makalelerimiz Google Arama'da ve öne çıkan haberlerde size önce görünsün.
