Altyapı ve Güvenlik

Uygulama Altyapısı Kurarken Alınması Gereken 7 Karar

15.07.2026 · 3 dk okuma · 1 okunma

Uygulama Altyapısı Kurarken Alınması Gereken 7 Karar

Uygulama altyapısı, yazılımın üzerinde durduğu zemindir. Kod her gün değişir; altyapı kararları ise bir kez verilir ve yıllarca taşınır. Bu yazıda, projenin ilk haftasında verilmesi gereken ve sonradan düzeltilmesi en pahalıya patlayan yedi kararı ele alıyoruz.

Altyapı kurulumunda verilmesi gereken temel kararların özeti
Bu yedi başlık ilk hafta netleşmezse, ilerideki her sorun bunlardan birine dayanır.

1. Ortam ayrımı

Geliştirme, test ve canlı ortamların ayrılması pazarlık konusu değildir. Aynı veritabanını paylaşan bir test ortamı, er ya da geç canlı veriyi bozar. Klasik senaryo: test amacıyla çalıştırılan toplu güncelleme sorgusu canlı tabloya çarpar ve binlerce kayıt yanlış duruma geçer.

Asgari kurulum şudur: geliştiricinin kendi makinesi, ortak bir test ortamı ve canlı ortam. Test ortamı canlının kopyası olmalı ama kişisel veriler maskelenmelidir. Gerçek müşteri e-postalarının bulunduğu bir test ortamından yanlışlıkla toplu e-posta gönderilmesi, sık yaşanan ve itibar zedeleyen bir kazadır.

2. Yapılandırma ve sırların yönetimi

Veritabanı parolası, ödeme sağlayıcısı anahtarı, e-posta sunucusu bilgisi gibi sırlar hiçbir zaman kod deposuna girmemelidir. Depo bir gün paylaşılır, bir gün yedeklenir, bir gün bir stajyerin makinesine kopyalanır; o andan itibaren sır sır olmaktan çıkar.

Doğru yöntem, bu değerleri ortam değişkenlerinde tutmak ve depoya yalnızca örnek bir şablon dosyası koymaktır. Sır bir kez yanlışlıkla depoya girdiyse, dosyayı silmek yetmez; anahtar mutlaka değiştirilmelidir çünkü geçmiş kayıtlarda durmaya devam eder.

3. Yedekleme ve geri dönüş provası

Yedekleme konusunda tek gerçek şudur: geri yükleme denenmemişse yedek yoktur. Sahada en sık karşılaşılan durum, yıllardır düzenli yedek alan ama yedek dosyalarının bozuk olduğunu felaket anında öğrenen şirketlerdir.

  • Yedek en az iki farklı yerde tutulmalı; biri sunucunun kendisinde olmamalı.
  • Otomatik alınmalı, elle çalıştırılan hiçbir yedek düzenli kalmaz.
  • Ayda bir kez test ortamına geri yükleme denemesi yapılmalı.
  • Yedeklerin şifreli olması, dosya sunucusu ele geçirilse bile veriyi korur.
  • Saklama süresi belirlenmeli: günlük yedekler 30 gün, aylık yedekler bir yıl gibi.

4. Dağıtım (deployment) yöntemi

Dosyaları FTP ile sürükleyip bırakmak, yarım kalmış bir aktarımda sitenin bozulması demektir. Sürüm kontrolü üzerinden yapılan, tek komutla çalışan ve geri alınabilir bir dağıtım akışı kurulmalıdır. Bu akışta göç (migration) dosyaları da otomatik çalışmalı, ancak geri alma planı elinizde olmalıdır.

Basit ölçüt: Yayın yapmaktan korkuyorsanız, dağıtım süreciniz yeterince otomatik değil demektir.

5. İzleme ve kayıt (logging)

Kullanıcı "sistem çalışmıyor" dediğinde bakılacak bir yer olmalıdır. Asgari izleme seti şudur: uygulama hata kayıtları, web sunucusu erişim kayıtları, yavaş sorgu kaydı, disk ve bellek kullanımı, sertifika bitiş tarihi uyarısı.

Kayıtların saklanma süresi ve kişisel veri içeriği de düşünülmelidir. Hata kaydına kullanıcı parolasının veya tam kart numarasının düşmesi, denetimlerde doğrudan bulgu olarak yazılır.

6. Erişim yönetimi

Sunucuya kimin, hangi yetkiyle eriştiği yazılı olmalıdır. Ortak kullanılan tek bir root parolası, kimin ne yaptığını izlenemez hâle getirir. Bunun yerine kişiye özel hesaplar, anahtar tabanlı erişim ve yalnızca gereken yetkiler verilmelidir. İşten ayrılan kişinin erişiminin aynı gün kapatılması, çoğu şirkette atlanan basit ama kritik bir adımdır.

7. Ölçeklenme planı (henüz uygulamadan)

Baştan devasa bir mimari kurmak gereksizdir; ancak büyümenin hangi noktada ne gerektireceğini bilmek gerekir. Genellikle sıralama şudur: önce veritabanı sorguları ve indexler, sonra önbellek katmanı, sonra statik dosyaların ayrılması, en sonda uygulama sunucusunun çoğaltılması. Bu sırayı bilmek, sorun çıktığında panik kararlarını önler.

Kurulum sonrası kontrol listesi

  1. HTTPS zorunlu mu, sertifika otomatik yenileniyor mu?
  2. .env ve yedek klasörleri web üzerinden erişilebilir durumda mı? (Doğrudan adres yazarak test edin.)
  3. Hata sayfaları ayrıntı sızdırıyor mu? Canlıda yığın izi (stack trace) gösterilmemelidir.
  4. Dizin listeleme kapalı mı?
  5. Yedekten geri dönüş son 30 gün içinde denendi mi?
  6. Sunucu güvenlik güncellemeleri güncel mi?

Sunucu sertleştirme adımları için CIS Benchmarks belgeleri, işletim sistemi ve web sunucusu bazında ayrıntılı kontrol listeleri sunar.

Sonuç

Altyapı, görünmediği sürece iyi çalıştığı sanılan bir katmandır. Ortamları ayırın, sırları koddan çıkarın, yedeği düzenli alıp geri dönüşü deneyin, dağıtımı otomatikleştirin, izlemeyi kurun ve erişimi kişiselleştirin. Bu yedi karar doğru verildiğinde, geriye kalan sorunların çoğu sadece kod sorunudur; ki onlar en kolay çözülenlerdir.

Paylaş:

Sık Sorulan Sorular

Başlangıçta tek sunucu yeterlidir; ancak canlı ile test ortamının aynı veritabanını paylaşmaması şarttır. Trafik arttığında ilk ayrılacak bileşen genellikle veritabanıdır.

Kabul edilebilir veri kaybı süresine göre belirlenir. Günlük yedek, en kötü durumda bir günlük veri kaybı demektir. Finansal işlem varsa saatlik yedek veya sürekli günlük (binlog) tutulması gerekir.

Veritabanı parolası, API anahtarı gibi bilgiler kod deposuna girerse, depoya erişen herkes o sırlara erişir. Ortam değişkenleri bu bilgileri koddan ayırır ve ortama göre değiştirilebilir kılar.

Güvenlik yamaları çıktığı hafta uygulanmalıdır. Büyük sürüm yükseltmeleri için ise önce test ortamında deneme yapılmalı ve geri dönüş planı hazırlanmalıdır.