Soru geçmişi: Kurumsal modernizasyon girişimlerinde, İş Analistleri sıklıkla bilgi erozyonu ile karşılaşır; bu, kritik iş mantığının yalnızca okunamaz eski kodda hayatta kaldığı bir fenomen. Bu soru, orijinal mimarların on yıllar önce emekli olduğu ve ardında mükemmel bir şekilde çalışan ama yorumlanamaz COBOL programları bıraktığı ana çerçeveden buluta göçlerden doğmuştur. Tarihsel bağlam, monolitik toplu işlemden dağıtılmış mikro hizmetlere geçişi içerir; burada örtük durum yönetimi açık API sözleşmeleri haline gelmelidir.
Sorun epistemik opaklıkta merkezi: sistem çalışıyor, ama kimse nedenini bilmiyor. COBOL kod tabanı örtük iş kurallarını, kenar durumlarını, düzenleyici yamanmaları ve asla belgelenmeyen manuel geçersiz kılmaları barındırır; çünkü orijinal geliştiriciler bu bilgiyi hafızalarında tutuyorlardı. Mevcut operasyon personeli girdileri ve çıktıları anlıyor, ancak karar mantığını bilmiyor. Bu arada, yeni bulut yerel mimari, bu kuralların ayrıştırılması, belgelenmesi ve gerçek zamanlı tüketim için REST uç noktaları aracılığıyla açığa çıkarılmasını gerektiriyor. Sabit bir düzenleyici son tarih, çok yıllı arkeolojik bir keşfe izin vermiyor; ancak kural çıkarımındaki hatalar GDPR veri işleme görevlerini ihlal edebilir veya finansal raporlama doğruluğunu etkileyebilir.
Çözüm, üçgen ters mühendislik yaklaşımını kullanır. İlk olarak, operasyon personeli ile Olay Fırtınası atölyeleri düzenleyerek gözlemlenebilir iş davranışlarını haritalayın ve "kara kutu" süreçlerini tanımlayın. İkincisi, COBOL programlarının kontrol akış grafikleri oluşturmak için statik kod analizi araçları kullanın, değişken mutasyonlarını iş sonuçlarıyla karşılaştırın. Üçüncüsü, yeni mikro hizmet işlemlerinin üretim etkisi olmadan eski sisteme karşı işlemleri eşleştirdiği paralel koşu gölge modu uygulayın, inceleme için tutarsızlıkları işaretleyin. Bu, kod arkeolojisinin paydaş anılarını doğruladığı ve paydaş bağlamının kod anormalliklerini açıkladığı bir geri bildirim döngüsü oluşturur.
Bir bölgesel sigorta şirketi, 1980'lerin eski COBOL poliçe derecelendirme motorunu Python/FastAPI mikro hizmetleriyle değiştirerek gerçek zamanlı mobil alıntılar sağlamak istedi. Orijinal hesaplama mantığı, karmaşık toprak risk ağırlıkları, mevsimsel ayarlama faktörleri ve kırk yılı aşkın süredir yamalanmış reasürans anlaşması maddelerini içeriyordu. Üç kalan COBOL geliştiricisi emekli olmuştu ve mevcut BT personeli sistemi, doğru primler üreten ama belirli kenar durumlar için matematiksel çıkarımları açıklayamayan bir "sihirli kutu" olarak görüyordu. Düzenleyici otorite, desteklenmeyen altyapı cezalarından kaçınmak için taşınmanın sekiz ay içinde tamamlanmasını zorunlu kılmıştı.
Gereksinimleri karşılamak için birkaç yaklaşım değerlendirildi. İlk seçenek, geliştiricilerin COBOL kaynak kodundaki her IF ifadesini ve MOVE işlemini elle belgelendireceği bir koddan-şartlara yazım önerdi. Artıları teorik bütünlük ve tam mantığın korunmasıydı. Eksileri ise şiddetliydi: Kod tabanı, belgelenmemiş global değişkenlerle iki milyondan fazla satır spagetti kodu içeriyordu; bu, çok yıllık bir çaba gerektirecek ve son tarihi kaçıracak ve muhtemelen yazım hataları yaratacak bir durumdu.
İkinci seçenek, kuralların istatistiksel regresyon ile çıkarılmasına yol açan girdi (poliçe özellikleri) ve çıktıları (prim tutarları) gözlemlemeyi önerdi. Artıları hız ve teknik borç yerine mevcut iş değerine odaklanmaktı. Eksileri, nadir talepler senaryoları için uyku halinde kod yollarını tespit edememe ve hataların özellikler olarak kodlanma riskiydi.
Üçüncü seçenek, paralel doğrulama ile davranışsal arkeoloji, beş yıl süresince üretim günlüklerinden örnek veri çıkarmayı, gerçek işlemlerden karar ağaçları inşa etmeyi ve bunları otomatik şekilde karşılaştırarak COBOL kaynağı ile doğrulamayı içeriyordu.
Ekip, hız ve doğruluğu dengelediği ve kapsamlı belgeler yerine çalışır yazılımın önceliklendirilmesi çevik ilkesini onurlandırdığı için üçüncü çözümü seçti. Aktif iş kurallarının doğru bir şekilde yakalandığından emin olurken, uygulanabilir kod yollarına odaklanarak kapsamı %60 oranında azalttılar. Anonimleştirilmiş tarihi işlemler içeren bir veri göleti kurdular ve bunları hem eski JCL işleri hem de yeni FastAPI hizmetleri üzerinden çalıştırarak %0.01'den daha büyük prim hesaplama uyuşmazlıklarını otomatik olarak işaretlediler. Bu, 1992'den önceki Florida poliçeleri için bir kasırga muafiyetinin aşılması, emekli ajanlar için özel komisyon hesaplaması ve yıllardır manuel hesap tablosu ayarlamaları ile "düzeltilen" çeyrek vergi raporlamasında bir yuvarlama hatası da dahil olmak üzere üç kritik belgelenmemiş durumu ortaya çıkardı. Mikro hizmetler, bu kenar durumları, sabit kodlu sabitler yerine yapılandırılabilir iş kuralları olarak açık bir şekilde ele almak üzere yeniden tasarlandı.
Eski kodu tersine mühendislik yaparken, bir kritik iş kısıtlaması ile göç sırasında güvenle ortadan kaldırılabilecek bir teknik çözüm yolu arasındaki farkı nasıl ayırt edersiniz?
Adaylar genellikle mevcut tüm mantığın güncel bir iş amacına hizmet ettiğini varsayıyor ve eski korumanın batık maliyet yanılgısı içine düşüyorlar. Doğru yaklaşım, zamansal bağlam analizi gerçekleştirmektir: kod değişikliklerinin tarih damgalarını inceleyerek bilinen düzenleyici değişikliklerle, birleşmelerle veya artık var olmayan teknoloji kısıtlamalarıyla ilişkilendirmek. Örneğin, bir COBOL veri kesme rutini, yalnızca orijinal DB2 şemasının sabit genişlikte alanlar kullanmasından dolayı var olabilirken, modern PostgreSQL değişken uzunlukta dizeleri desteklediği için kesme kuralına tamamen ihtiyaç kalmaz. İş analistleri, iş paydaşlarıyla amaca doğrulama oturumları düzenlemelidir; şüpheli çözüm yollarını "Bunu X'i kaldırarak basitleştirebiliriz; bu sizin uyumunuzu etkiler mi?" şeklinde sunarak, "X'i korumalı mıyız?" sorusunu sormamalıdır. Bu, kanıt yükünü koruma yerine gerekliliğe kaydırır.
Yeni sistemin, COBOL monolitinde mevcut olduğu için verimsiz toplu işleme iş akışlarını tekrarladığı "cargo cult" anti-patternini nasıl önlersiniz?
Birçok aday, işlevsel eşdeğerliğe odaklanırken, işleme yeniden mühendislik yerine geçer. Hata, iş analistlerinin mevcut durumu (örneğin, "Sistem her gece 2 AM'de bir toplu işlem çalıştırıyor") gelecekteki durum için bir gereklilik olarak belgelediklerinde ortaya çıkar; oysa Apache Kafka veya RabbitMQ ile etkinlik odaklı mimarilerin gerçek zamanlı işleme sağlamasına olanak tanır. Çözüm, yetkinlik haritalama gerektirir: "ne"nin (risk hesaplaması yapılmalıdır) "nasıl"dan (toplu işleme ve akış) ayrılması. İş analistleri, toplam zamanın iş kurallarından ziyade operasyonel kolaylık sağlamak için bekleme sürelerini belirlemek üzere değer akış haritalama gerçekleştirmelidir. REST uç noktalarının, tekliften bağlama süresini 24 saatten 30 seconde kadar azaltarak, aktüerler için anlık geri bildirim sağlayabileceğini göstererek, aksi takdirde "eski sistemle çok farklı" olduğu reddedilecek olan mimari değişiklikleri gerekçelendirebilirler.
Belirsiz belirsizlerin riskini - gözlemleriniz sırasında tetiklenmeyen örtük kuralların - nicelendirip iletişim kurma metodolojiniz nedir ve bunlar göç sonrası felakete sebep olabilir?
Adaylar genellikle paydaşlara %100 test geçiş oranlarıyla sahte bir güven sunar. Kapsamlı cevap, eski verilerde örnekleme yanlılığı tanır ve sentetik senaryolar karşısında stres testine öncülük eder. Bu, eski günlüklerde görünmeyen sınır koşullarını harekete geçirmek için bulanık giriş verisi oluşturmayı ve ardından COBOL ve yeni sistem çıktılarının karşılaştırılmasını içerir. Ayrıca, iş analistleri yeni mimaride bir devre kesici modeli oluşturmalıdır: eğer mikro hizmet, işleyemediği bir işlem yapısı ile karşılaşırsa (bir eksik kuralı işaret ediyorsa), eski SOAP sarmalayıcıyı (mevcutsa) çağırarak ya da insan incelemesi için işaretleyerek nazikçe gerileyerek, sessizce başarısız olmak ya da null değerlerine defaultlama yerine işlem yapmalıdır. İletişim stratejisi, %95 oranında kuralların doğrulandığını gösterirken, %5'lik bir kalan belirsizliğin üç aylık bir hiper bakım dönemini gerektirdiğini gösteren olasılıksal risk matrislerini içerir.