Yazılım modernizasyonu, bulut geçişi ve DevOps

Modernizasyon talebi genellikle bir olayla gelir: barındırma firması eski PHP sürümünü kaldıracağını duyurur, bir güvenlik taraması kırmızı satırlarla döner, sistemi yazan kişi ayrılır ya da ay sonu raporu artık sabaha kadar sürer. Sistem hâlâ işin merkezindedir. Bu yüzden amaç onu kapatmak değil, çalışırken dönüştürmektir.

Modernizasyon ne zaman gerekir?

Aşağıdakilerden biri varsa bir değerlendirme yapmanın zamanı gelmiştir:

• Çalışma ortamının güvenlik desteği bitmiş ya da bitmek üzere. PHP 7.4, 8.0 ve 8.1 artık desteklenmiyor; 8.2'nin güvenlik desteği 31 Aralık 2026'da bitiyor. Microsoft'a göre .NET 8 ve .NET 9'un desteği 10 Kasım 2026'da sona eriyor.
• Yayın, sunucuya FTP ile dosya kopyalayarak ya da canlıda elle yapılan değişikliklerle yapılıyor.
• Otomatik test yok; "bir şey bozuldu mu" sorusunu kullanıcı şikâyeti cevaplıyor.
• Sistemi yalnızca bir kişi tanıyor.
• Yedek alınıyor ama hiç geri yüklenip denenmedi.
• Bağımlılıklarda bilinen bir güvenlik açığı var ve güncelleme başka parçaları kırdığı için yapılamıyor.

İşe nasıl başlıyoruz: mevcut durum değerlendirmesi

Her modernizasyon işine, sistemin bugünkü hâlini ölçülebilir biçimde yazıya döken bir değerlendirmeyle başlarız. Adımlar:

1. Envanter. Sunucular; işletim sistemi, çalışma ortamı ve çerçeve (framework) sürümleri; bağımlılık listeleri (composer.lock, package-lock.json, requirements.txt); zamanlanmış görevler; dış bağlantılar. Belgelenmemiş bir cron işi çoğu zaman en kritik iş kuralını çalıştırır.
2. Bağımlılık açıkları. Bağımlılıklar bilinen açık veri tabanlarına karşı taranır; her bulgu "gerçekten sömürülebilir mi, güncelleme neyi kırar" diye ayrıca değerlendirilir. Tarama aracının kırmızı satır sayısı tek başına risk ölçüsü değildir.
3. Veri tabanı. Boyut, hızla büyüyen tablolar, yavaş sorgu kaydı, karakter seti ve saat dilimi ayarı.
4. Yayın ve yedek. Kodun sunucuya nasıl gittiği, yedeğin nerede durduğu. Yedekten bir test ortamına gerçekten geri dönüş yapılır ve süresi ölçülür.
5. Ölçüm. En çok kullanılan işlemlerin yanıt süreleri (ortalama değil, p95: isteklerin yüzde 95'inin altında kaldığı süre), hata oranı ve sunucu kaynak kullanımı. "Hızlandı mı" sorusunun cevabı sonradan bu ilk ölçüme göre verilir.

Çıktı, her bulgunun etkisi ve düzeltme maliyetiyle yer aldığı bir risk tablosu ve sıralı bir yol haritasıdır. Bu değerlendirme bir uyuşmazlık incelemesi değildir; teslim edilen yazılımın sözleşmeye uygunluğu tartışılıyorsa yöntem yazılım ve kaynak kod incelemesidir.

Baştan yazmak mı, adım adım dönüştürmek mi?

Çoğu durumda adım adım dönüştürmek. Baştan yazma projeleri kâğıt üzerinde kolay görünür; zorluk, eski sistemin yıllar içinde biriken ve hiçbir yerde yazılı olmayan davranışlarını yeniden keşfetmektir. Martin Fowler'ın "strangler fig" adını verdiği yaklaşımda yeni sistem, eskisinin çevresinde onun işlevlerini birer birer devralarak büyür.

Örnek: Eski bir PHP uygulamasının önüne bir ters vekil sunucu (reverse proxy) konur. İlk ay yalnızca /raporlar/ altındaki istekler yeni servise yönlendirilir, geri kalan her şey eski uygulamada kalır. Raporlar bir süre iki sistemde paralel üretilip karşılaştırılır; fark kalmayınca eski rapor kodu kapatılır ve bir sonraki modüle geçilir. Yönlendirme kuralını geri almak, her adımda sistemi bir önceki hâline döndürür.

Seçenekleri AWS'nin taşıma stratejileri sınıflandırmasından uyarlayarak değerlendiririz:

Veri taşımada nerede hata çıkar?

En sık hata, satır sayısı tuttuğu için işin bittiğini sanmaktır. Kontrollerimiz:

• Karakter kodlaması. Türkçe sistemlerde iki bozulma sık görülür: UTF-8 metnin Latin-1 sanılıp yeniden kodlanması ("ü" yerine "ü") ve Windows-1254 baytlarının Latin-1 tanımlı sütunda durması ("ş" yerine "þ", "ı" yerine "ý"). İkisinin düzeltmesi farklıdır; hangisi olduğunu önce örnek kayıtlarla belirleriz.
• Tarih ve saat. Eski sistemler zamanı çoğunlukla saat dilimi bilgisi olmadan, yerel saatle yazar. Türkiye 7 Eylül 2016'dan beri sürekli UTC+3 kullanıyor; öncesinde kışın UTC+2 geçerliydi ve bazı yıllarda yaz saati geçiş tarihleri Avrupa'dan farklıydı. 2016 öncesi kayıtlar güncel saat dilimi verisi olmadan UTC'ye çevrilirse bir saatlik kayma çıkar. Ayrıntısı zaman damgaları ve saat dilimi yazısında; tek tek değerleri zaman damgası dönüştürücü ile kontrol edebilirsiniz.
• Anlamı kaymış alanlar. Eski tabloda durum = 9 "iptal" demektir ama bunu yalnızca bir raporun kodu bilir. Taşımadan önce her kod değerinin anlamı kullanıcılarla doğrulanır.
• Doğrulama. Satır sayısının yanında tablo ve alan bazında toplamlar ve özet değerler (hash) iki tarafta hesaplanıp karşılaştırılır. Taşınan dosyaları karşılaştırmak için hash hesaplama aracını kullanabilirsiniz.
• Prova. Gerçek hacimle en az bir tam prova yapılır, süresi ölçülür; canlıya geçiş penceresi bu ölçüme göre planlanır.

Bulut geçişi ne kazandırır, neye dikkat edilir?

Bulut, altyapı bakımını sağlayıcıya devretmeyi ve kapasiteyi ihtiyaca göre büyütmeyi sağlar; kendiliğinden ucuzlatmaz. Sunucuyu olduğu gibi taşıyıp sürekli açık tutmak çoğu zaman eski barındırmadan pahalıdır. Maliyeti belirleyen kalemler sürekli açık kaynaklar, veri çıkış (egress) ücretleri, yönetilen veri tabanı ve yedek depolamadır; geçişten önce aylık tahmin çıkarır, bir bütçe alarmı kurarız.

Yedekleme için iki sayı yazılı olmalı: en fazla ne kadar veri kaybının göze alınabileceği (RPO) ve sistemin en geç ne kadar sürede geri gelmesi gerektiği (RTO). Yedeğin ayrı bir hesapta ya da bölgede durması, ana hesabın ele geçirildiği senaryoda tek çıkış yolu olabilir.

Kişisel veri içeren bir sistemi yurt dışındaki bir bulut bölgesine taşımak KVKK m.9 kapsamında yurt dışına aktarımdır. 7499 sayılı Kanunla değişen maddeye göre aktarım yeterlilik kararı, uygun güvenceler (örneğin Kurul'un ilan ettiği standart sözleşme; imzadan sonra beş iş günü içinde Kurum'a bildirilir) ya da arızi hâllerle mümkündür. Hangi dayanağın uygulanacağı hukukçunun değerlendirmesidir; biz bölge seçimini, şifrelemeyi ve erişim kayıtlarını bu karara göre kurarız.

Performans optimizasyonu nereden başlar?

Ölçümden. "Sistem yavaş" şikâyetinin arkasında çoğunlukla birkaç sorgu ya da tek bir uç nokta vardır. Sıramız:

1. En çok kullanılan ve en yavaş işlemleri p95 yanıt süresiyle sıralamak.
2. Veri tabanında yavaş sorgu kaydını açmak, sorgu planını EXPLAIN ANALYZE ile okumak; eksik indeksleri ve bir liste için yüzlerce ayrı sorgu atan döngüleri (N+1) bulmak.
3. Önbelleği en son düşünmek. Yanlış kurulan önbellek, eski veriyi hızlı göstermenin yoludur.
4. Değişiklikten sonra aynı ölçümü tekrarlamak ve farkı rapora yazmak.

Web arayüzünde ölçüt Core Web Vitals'tır: web.dev'e göre sayfa yüklemelerinin yüzde 75'inde LCP en fazla 2,5 saniye, INP en fazla 200 milisaniye, CLS en fazla 0,1 olmalı. Ön yüz hızının ayrıntıları kurumsal web sitesi sayfamızda.

Yazılım güvenliği modernizasyonun neresinde?

Başında. OWASP Top 10:2025'te erişim kontrolü hataları birinci sıradaki yerini koruyor; üçüncü sıradaki yazılım tedarik zinciri hataları ise 2021'deki "güvenlik açığı bulunan ve eskimiş bileşenler" başlığının genişletilmiş hâli. Eski sistemlerde ikisi birlikte görülür: yetki kontrolü ekranlara dağılmıştır, bağımlılıklar yıllardır güncellenmemiştir. Uyguladıklarımız:

• Bağımlılık güncellemelerini otomatik öneren bir araç ve her derlemede bilinen açık taraması; bileşen listesi (SBOM) teslimde verilir.
• Parola, API anahtarı ve bağlantı bilgileri koddan ve depodan çıkarılıp bir gizli bilgi yönetimi hizmetine taşınır. Depo geçmişinde kalmış anahtarlar değiştirilir; geçmişten silmek yetmez.
• Yetki kontrolünün tek bir katmanda toplanması ve bunun otomatik testleri.
• Geliştirme süreci için ölçüt olarak NIST'in Güvenli Yazılım Geliştirme Çerçevesi (SP 800-218, SSDF).

Sistemde bir saldırı ya da yetkisiz erişim şüphesi varsa önce kanıtı koruyacak biçimde bir siber olay incelemesi yapılmalıdır; iz taşıyan kayıtlar modernizasyon sırasında kolayca silinir. İlk saatlerde neyin korunacağını dijital delil nasıl korunur yazısında anlattık.

DevOps ve CI/CD hattı nasıl kurulur?

CI/CD, koddaki her değişikliğin otomatik test edilip derlendiği (sürekli entegrasyon) ve aynı yolla, tekrarlanabilir biçimde yayına alındığı (sürekli teslim ve dağıtım) düzendir. Kurduğumuz hattın adımları:

1. Her değişiklikte statik kontroller ve otomatik testler.
2. Derleme çıktısı bir kez üretilir ve sürüm numarasıyla saklanır; test ortamına da canlıya da aynı çıktı gider.
3. Veri tabanı değişiklikleri (migration) dağıtımın bir adımı olarak çalışır.
4. Test ortamında kısa bir duman testi (smoke test).
5. Canlıya geçiş onayla yapılır; ardından sağlık kontrolü, gerekirse tek komutla bir önceki sürüme dönüş.

GitHub Actions kullanılıyorsa GitHub'ın güvenlik önerilerini uygularız: üçüncü taraf eylemler tam uzunluktaki commit SHA'sına sabitlenir (GitHub'a göre bir eylemi değişmez sürüm olarak kullanmanın şu anki tek yolu budur), bulut hesabına uzun ömürlü anahtar yerine OpenID Connect ile bağlanılır, GITHUB_TOKEN varsayılan olarak yalnızca okuma yetkisiyle çalışır.

Sonucu DORA'nın yazılım teslim metrikleriyle ölçeriz:

Teslimde hattın tanımı depoda kod olarak durur: hangi adımın ne yaptığı, gizli bilgilerin nerede tutulduğu ve bir önceki sürüme nasıl dönüleceği yazılıdır. Hat iş sahibinin hesabında çalışır, bize bağımlı kalmaz. Sistemin API ve entegrasyon tarafı için backend, API ve entegrasyon sayfasına bakabilirsiniz.