Eski (legacy) sistem modernizasyonu: stratejiler, maliyetler ve güvenli geçiş planı

Eski sistem modernizasyonu, işi halen yürüten ancak değiştirilmesi zor, barındırılması pahalı veya tutulması riskli hale gelen yazılımın güncellenmesi anlamına gelir. Bu, testleri olmayan bir PHP 5 uygulaması, özel eklentilere sahip eski bir CRM, paylaşılan bir veritabanıyla konuşan bir masaüstü aracı veya yalnızca bir kişinin anlayabileceği bir monolit olabilir. Amaç, kendi iyiliği için yeni teknoloji değildir. Amaç işletmenin tekrar güvenle değiştirebileceği bir sistemdir.

Faturalandırma platformlarından çok dilli e-ticarete kadar müşterilerimiz için üretim sistemlerini devralıyor ve modernize ediyoruz. Aşağıdaki yaklaşım bizim kullandığımız yaklaşımdır: her biri kendi masrafını çıkaran küçük, geri döndürülebilir adımlar.

Modernleştirmeniz gereken işaretler

Yaş tek başına bir sebep değildir. On yıllık, istikrarlı, güvenli ve değiştirilmesi ucuz bir sistem olduğu gibi kalabilir. Yatırımı haklı çıkaran sinyaller şunlardır:

• Her değişim yavaş ve korkutucudur. Küçük bir özellik haftalar sürer, sürümler geceleri gerçekleşir ve her dağıtımdan sonra alakasız bir şey kesintiye uğrar.
• Desteklenmeyen çalışma zamanı veya çerçeve. PHP 7.x veya daha eski bir sürüm, kullanım ömrünün sonuna gelmiş bir çerçeve, eski bir veritabanı sürümü veya güvenlik güncellemeleri olmayan bir işletim sistemi. PHP 8 yükseltme kılavuzumuz bu durumu ayrıntılı olarak ele almaktadır.
• Anahtar kişi riski. Dağıtımların, cron işlerinin ve entegrasyonların nasıl çalıştığını yalnızca bir geliştirici, çoğunlukla da dışarıdan biri biliyor.
• Entegrasyonlar engellendi. Sistemde temiz API bulunmadığından yeni bir ödeme sağlayıcısı, CRM veya AI hizmeti bağlayamazsınız.
• Maliyetler artmaya devam ediyor. Büyük boyutlu sunucularda barındırma, pahalı lisanslar, eksik özelliklerin manuel olarak çözülmesi ve tekrarlanan olaylar.
• Güvenlik ve uyumluluk boşlukları. Düz metin şifreler, bilinen güvenlik açıklarına sahip güncel olmayan kütüphaneler, denetim kaydı yok, olması gereken yerde olmaması gereken veriler.

Bunlardan iki veya daha fazlası geçerliyse, modernizasyon genellikle gizli maliyetleri ödemeye devam etmekten daha ucuzdur.

6 Rs: modernizasyon stratejileri

6 Rs bir strateji seçmenin basit bir yoludur. Önemli olan tüm sistem için değil, bileşen başına seçim yapmaktır.

• Sürdürmek. Bileşeni olduğu gibi bırakın ve yalnızca izleyin. Eski bir raporlama modülü gibi nadiren değişen sabit parçalar için iyidir.
• Yeniden barındırma (kaldırma ve kaydırma). Uygulamayı, kodu değiştirmeden yeni bir altyapıya (örneğin eski bir fiziksel sunucudan modern bir VPS veya bulut üzerindeki Docker) taşıyın. Hızlı ve ucuz; donanım riskini ortadan kaldırır ancak kod sorunlarını ortadan kaldırmaz.
• Yeniden platform. Daha iyi bir platformda çalışacak küçük değişiklikler: desteklenen bir PHP sürümü, yönetilen bir veritabanı, cron döngüleri yerine bir kuyruk. Çoğu zaman paranın karşılığını en iyi şekilde verir.
• Yeniden düzenleme. Davranışı değiştirmeden iç yapıyı iyileştirin: testler ekleyin, hizmetleri çıkarın, ölü kodu kaldırın, kademeli olarak bir çerçeve katmanı ekleyin.
• Yeniden mimarlık. Sistemin bir bölümünün mimarisini değiştirin; örneğin, faturalandırmayı bir API ile ayrı bir hizmete taşımak veya doğrudan veritabanı paylaşımını etkinliklerle değiştirmek.
• Yeniden oluşturun (yeniden yazın) veya değiştirin. Bileşeni yeniden yazın veya bir SaaS ürünüyle değiştirin. İş mantığı basit ve iyi anlaşıldığında ya da hazır bir ürün bunu kapsadığında haklı çıkar. Karmaşık, belgelenmemiş mantık açısından risklidir.

Tipik bir plan bunları birleştirir: altyapı riskini ortadan kaldırmak için önce yeniden barındırma, çekirdeği yeniden düzenleme, bir veya iki sorunlu alanı yeniden tasarlama ve e-posta gönderme veya arama gibi ticari parçaları kanıtlanmış hizmetlerle değiştirme. Özellikle yeniden yazma ile kademeli iyileştirme arasında karar veriyorsanız, eski kodun ne kadar belgelenmemiş iş mantığı içerdiğini değerlendirin; Kopyalamayı unuttuğunuz her kural yeni sistemde bir hataya dönüşüyor.

Önce denetim ve risk haritası

Denetimsiz modernizasyon tahmindir. Bir denetimin bir ila iki hafta içinde şu sorulara yanıt vermesi gerekir: üretimde tam olarak neyin çalıştığı, verilerin nerede bulunduğu, neyin kırılgan olduğu ve işletmenin neyi kaybedemeyeceği. Kod denetimi kontrol listemiz soruları ayrıntılı olarak listeler. Minimum çıktı:

• Envanter. Sunucular, etki alanları, depolar, cron işleri, kuyruklar, üçüncü taraf hizmetleri, kimlik bilgileri ve her hesabın kime ait olduğu.
• Mimarlık haritası. Kod ve günlüklerde bulunan belgelenmemiş olanlar da dahil olmak üzere ana modüller, veritabanları, entegrasyonlar ve veri akışları.
• Risk haritası. Her riskin kendi olasılığı, iş etkisi ve çözümü vardır: yedekleme yok, ödeme mantığı üzerinde test yok, veri havuzundaki sırlar, desteklenmeyen bir çalışma zamanı.
• Hızlı kazanır. Günler süren ve en büyük riskleri ortadan kaldıran düzeltmeler: doğrulanmış yedeklemeler, izleme, sırların koddan çıkarılması, tekrarlanabilir bir dağıtım.
• Yol haritası. Tahminler, bağımlılıklar ve her adımın işletmeye kazandırdığı modernizasyon adımlarının sırası.

Sistemi başka bir geliştiriciden devralıyorsanız, denetimi eski PHP devir kılavuzumuzdaki adımlarla birleştirin: önce erişimi ve yedeklemeleri güvenli hale getirin, ardından kodu değiştirin.

Artımlı bir geçiş planı

Çalışan bir sistemi modernleştirmenin en güvenli yolu strangler fig modelidir: eski uygulamanın önüne bir proxy yerleştirin ve rotaları, modülleri veya işlevleri teker teker yeni koda taşıyın. Kullanıcılar tek bir sistem görür; arkasında eski kısım kapatılabilene kadar küçülür.

# nginx: new code serves /billing and /api/v2, everything else stays on the legacy app
location /billing/ { proxy_pass http://new_app; }
location /api/v2/  { proxy_pass http://new_app; }
location /         { proxy_pass http://legacy_app; }

1. Stabilize edin. Test edilmiş bir geri yükleme, çalışma süresi ve hata izleme, merkezi günlükler, koddaki sırlar ile yedeklemeler. Bundan önce başka hiçbir şey başlamaz.
2. Tekrarlanabilir hale getirin. Uygulamayı Docker veya başka bir tekrarlanabilir ortama yerleştirin, anonimleştirilmiş verilerle bir hazırlama kopyası ve birkaç dakika içinde geri alınabilecek bir dağıtım ayarlayın.
3. Bir güvenlik ağı ekleyin. Kritik akışlar için karakterizasyon testleri yazın: oturum açma, ödeme, faturalama, finansın bağlı olduğu raporlar. Hatalar da dahil olmak üzere sistemin bugün ne yaptığını belgeliyorlar.
4. Platformu yükseltin. Desteklenen dil ve çerçeve sürümleri, güncel kütüphaneler, modern bir veritabanı sürümü. Mümkün olduğunda otomatik araçları kullanın ve testlerin yakaladığı şeyleri düzeltin.
5. Ağrılı kısımları hareket ettirin. En yüksek değişim maliyetine veya en büyük riske sahip modülü seçin, yenisini oluşturun, trafiğin bir kısmını ona yönlendirin, sonuçları karşılaştırın ve ardından tamamen geçiş yapın.
6. Verileri dikkatlice taşıyın. Şema değişikliklerini, eski ve yeni kodun aynı anda çalışabileceği, gruplar halinde geçiş yapabileceği, sayıları ve toplamları doğrulayabileceği ve eski kod bitene kadar bir geri alma yolu tutabileceği şekilde planlayın.
7. Eski kodu kaldırın. Artık kullanılmayanların kullanımdan kaldırılması. Hiçbir şeyi silmeyen modernizasyon, yalnızca bakımı yapılacak ikinci bir sistem ekler.

Her adım kendi başına uygulanabilmeli ve gözle görülür bir sonuç getirmelidir: daha az olay, daha hızlı sürüm veya daha düşük fatura. Bu, projeyi finanse ediyor ve klasik "iki yıllık, gösterilecek hiçbir şey olmadan yeniden yazma" sürecini ortadan kaldırıyor.

Maliyet, zaman çizelgesi ve yatırım getirisi

Sayılar boyuta, kodun kalitesine ve ne kadarının bilinmediğine bağlıdır, ancak bu aralıklar küçük, deneyimli bir Avrupalı ekip için yararlı bir akıl sağlığı kontrolüdür:

• Mimari analizi veya denetimi: €200-3k, 1-2 hafta. Riskleri, öncelikleri ve yol haritasını içeren yazılı bir rapor.
• İstikrar: €3k-15k, 2-6 hafta. Yedeklemeler, izleme, Docker, tekrarlanabilir dağıtımlar, sırlar, en acil güvenlik düzeltmeleri.
• Platform yükseltmesi: €5k-40k, 1-3 ay. Örneğin, kritik akışlara yönelik çerçeve güncellemeleri ve testleri ile PHP 5 veya 7'den PHP 8'e.
• Kademeli modernizasyon: €15k-150k, 3-12 ay. Anahtar modüllerin yeniden tasarlanması, yeni API'ler, veri geçişi ve eski parçaların kullanımdan kaldırılması.
• Tam yeniden yazma: genellikle ilk tahminin 1,5-3 katı. Gizli iş kuralları, veri geçişi ve eski sistemin paralel bakımı genellikle hafife alınır.

ROI için eski sistemin mevcut maliyetini hedef durumla karşılaştırın. Yavaş değişiklikler, olaylar ve bunların iş üzerindeki etkileri nedeniyle kaybedilen geliştirici saatlerini, eksik özelliklerin manuel olarak çözülmesini, barındırma ve lisans maliyetlerini ve bugün oluşturamayacağınız özelliklerin gelirini hesaba katın. Modernizasyon genellikle üç etkiyle karşılığını verir: Değişiklikler birkaç kat daha hızlı hale gelir, olaylar azalır ve altyapı daha ucuz hale gelir. Bütçelemeye daha geniş bir bakış açısı için özel yazılım geliştirme maliyeti kılavuzumuza bakın.

Yaygın hatalar

• Büyük patlama yeniden yazıldı. Yeni sistem kurulurken eski sistemin bir yıl süreyle dondurulması. İş değişmeye devam ediyor ve yeni sistem lansman sırasında güncelliğini yitiriyor.
• Değişikliklerden önce test yapılmaz. Karakterizasyon testleri olmadan hiç kimse yeniden düzenlemenin davranışı değiştirip değiştirmediğini bilemez.
• Verileri göz ardı etmek. Kod haftalar içinde yeniden yazılabilir; Yıllar süren tutarsız verilerin temizlenmesi ve taşınması çok daha uzun sürüyor.
• Teknoloji öncelikli kararlar. Ölçülü bir sorunu çözdüğü için değil, moda olduğu için mikro hizmetleri veya yeni bir çerçeveyi seçmek.
• Ticari tarafta sahibi yok. Birinin önceliklere karar vermesi ve taşınan özelliklerin beklendiği gibi çalıştığını onaylaması gerekir.

Nasıl yardımcı olabiliriz?

Canlı PHP ve web sistemlerini adım adım modernleştiriyoruz: işi durdurmadan denetim, Docker ve güvenli dağıtımlar, PHP ve çerçeve yükseltmeleri, yeni API'ler ve entegrasyonlar. İyi bir ilk adım, bir mimari analizidir ( €200): sisteminizin riskler, öncelikler ve her modernizasyon adımı için bir tahminle birlikte yazılı olarak gözden geçirilmesi. Önce durumunuzu görüşmek istiyorsanız, bir danışma randevusu alın (saat başına €50). Ayrıca entegrasyon hizmetimize ve PebbleHost faturalandırma örnek olay incelemesine de bakın.