SİZİN İŞİNİZDEN BAŞLAYALIM
Kurumsal Uygulama Modernizasyonu
Kritik uygulamanın bağımlılıklarını, geçiş riskini ve bakım yükünü değerlendirin. Pilot, veri mutabakatı ve geri dönüş planını birlikte kurun.
Kurumsal geçişte önce hangi sorunlar incelenir?
Modernizasyon kararı yalnızca yeni teknoloji seçmek değildir. İş birimlerinin beklentilerini, güvenlik bulgularını, bağımlılıkları ve işletim sorumluluğunu aynı plan içinde ele almak gerekir.
- Bağımlılıkların sahibi net değil. Bir bileşeni güncellemenin hangi uygulamayı veya veri alışverişini etkileyeceği sonradan ortaya çıkıyor.
- Güvenlik bulguları birikiyor. Açıkların önceliği, etkilenen varlıklar ve giderim kanıtları tek yerde izlenemiyor.
- Sürüm yayınlamak uzun bir koordinasyon işi. Manuel adımlar ve belirsiz geri dönüş koşulları değişiklik yapmayı zorlaştırıyor.
- Teknik borç bütçede somutlaşmıyor. Bakım yükü biliniyor, ancak hangi müdahalenin hangi iş sonucunu iyileştireceği açık değil.
Kritik sistem çalışırken nasıl geçiş yapılır?
Parça parça geçişte, uygun olduğunda strangler-fig yaklaşımıyla bir işlev mevcut sistemin çevresinden ayrılır. Sınırı; veri sahipliği, çağıran sistemler ve kullanıcı akışı belirler. İlk adımın boyutu, geri alınabilir olması ve ölçülebilir bir sonucu bulunmasıyla seçilir.
Paralel çalıştırma planı her iki sistemin sonuçlarını hangi kayıtlar üzerinde karşılaştıracağımızı açıklar. Yazma işlemlerinin sahibi, tutarsızlık çözümü ve geri dönüş kararı ayrıca tanımlanır. İki sistemin bir süre birlikte çalışması kendi başına doğruluk kanıtı değildir.
Pilotun kabul koşulları neler olmalı?
- Aynı ortam ve veri kümesinde ölçülen yanıt süreleri; gerekiyorsa medyan, p95 ve hata oranı.
- Önem derecesi ve tarama kapsamı belirtilmiş açık güvenlik bulguları; giderimden sonra yeniden kontrol.
- Sürümün hazırlanması ve yayınlanması için geçen süre, manuel adım sayısı ve geri dönüş denemesinin sonucu.
- Taşınan kayıtlarda mutabakat, yetki senaryoları ve işletim ekibine devredilecek belgeler.
Hedefler, sorumlular ve kabulü engelleyen durumlar işe başlamadan önce belirlenir. Pilotun sonuçları bir sonraki aşamanın kapsamına girdi sağlar; hedef tutmadığında ilerleme kararı yeniden değerlendirilir.
İnceleme ve uygulama kapsamı nasıl ayrılır?
Legacy Sağlık Raporu bağımlılık ve risk haritasını, uygulama modernizasyonu geçiş adımlarını, entegrasyon ve yapay zekâ ise sistem sınırlarındaki veri akışını ele alır.
.NET, Java ve veritabanı sayfalarındaki seçenekler keşif için başlangıçtır; teknolojiye özgü uygulama kapsamı inceleme ve pilotla doğrulanır. İş gerekçesini güvenlik, süreklilik ve maliyet başlıklarında ayrı izleyebilirsiniz.
Bakım yükünü görünür kılın
GAO’ya göre ABD federal kurumları, yıllık 100 milyar doları aşan BT ve siber yatırımlarının yaklaşık %80’ini mevcut BT sistemlerinin işletme ve bakımına ayırdıklarını bildiriyor.
Bu ABD federal verisi kendi şirketinizin maliyet oranı değildir.
%80
Tablo olarak göster
| Ölçüt | Değer | Üst sınır |
|---|---|---|
| GAO’ya göre ABD federal kurumları, yıllık 100 milyar doları aşan BT ve siber yatırımlarının yaklaşık %80’ini mevcut BT sistemlerinin işletme ve bakımına ayırdıklarını bildiriyor. | %80 | 100% |
Kaynak: Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems · U.S. Government Accountability Office · Yayın tarihi: · Erişim tarihi: ABD federal kurumlarının bildirimidir; yalnızca legacy sistemlere veya tüm şirketlere ait bir oran değildir.
Laboratuvardan
İndekssiz ay sonu raporu → Aynı rapor + kapsayan indeks
5 milyon kayıtta dönem sonu raporu
5.000.000 siparişten rapor: 1,22 dk → 175,5 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
5.000.000 siparişten rapor
↓ %99,8Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →Her satırda listeyi tara → Ürün koduyla Dictionary erişimi
.NET toplu aktarım: ürün koduyla eşleştirme
50.000 satırlık ürün aktarımı: 708,22 ms → 1,51 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
50.000 satırlık ürün aktarımı
↓ %99,8Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →Tüm eşleşmeleri ekrana ekle → Görünür satırları çiz
Ön yüz optimizasyonu: 50 bin faturalık liste
50.000 faturayı filtreleyip listeleme: 1,39 sn → 16,5 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
50.000 faturayı filtreleyip listeleme
↓ %98,8Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →Java 8 · sıralı çağrılar → Java 25 · sanal iş parçacıkları
Java 8 → 25: sipariş entegrasyonunu paralelleştirmek
256 siparişin tamamlanması: 2,95 sn → 380,91 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
256 siparişin tamamlanması
↓ %87,1Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →Her müşteri için tekrar tara → Tek geçişte özetle
PHP rapor optimizasyonu: tek geçişte hesaplama
200.000 siparişten rapor: 1,27 sn → 8,49 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
200.000 siparişten rapor
↓ %99,3Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →İndekssiz sorgu → Aynı sorgu + bileşik indeks
Veritabanı optimizasyonu: sorgu ve indeks
200.000 siparişten rapor: 1,13 sn → 7,19 ms. Sentetik laboratuvar; 10 tekrarın medyanı. Kod ve ham veri açık.
200.000 siparişten rapor
↓ %99,4Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →Corretto 8u432 → Corretto 25.0.3
Java 8 → 25: aynı sipariş raporu, iki runtime
Aynı bytecode ile bellekte 1 milyon sipariş raporu: 1,891 ms → 1,886 ms. Yedi veri boyutu ve 440 gerçek JVM koşusuyla sentetik runtime deneyi.
Bellekte 1 milyon sipariş raporu
↓ %0,3Düşük daha iyi · 10 ölçümün medyanı
Ölçüm yöntemi →