- 01Production altyapısı yalnız compute değil; database, network, security, monitoring, backup, deployment ve incident operasyonunun birlikte çalıştığı sistemdir.
- 02Altyapı boyutlandırması workload, peak trafik, RTO/RPO ve business impact üzerinden yapılmalıdır.
- 03Monitoring yalnız metric toplamak değil, actionable alert ve açık incident ownership modeli kurmaktır.
- 04Backup süreçleri düzenli restore testleriyle doğrulanmalıdır.
- 05Küçük ekipler gereksiz platform karmaşıklığı yerine operasyon kapasitesine uygun en basit güvenilir mimariyi seçmelidir.
Kısaca
Yazılım şirketleri için production altyapısı, yalnızca bir sunucu ve database kurmaktan ibaret değildir. Gerçek kullanıcı trafiğini taşıyan ortamın güvenli, izlenebilir, yedeklenebilir, deploy edilebilir ve gerektiğinde geri döndürülebilir olması gerekir.
Dynamis Teknoloji'de production altyapısını uygulama + database + network + güvenlik + monitoring + backup + deployment + incident operasyonu birlikte ele alarak tasarlıyoruz.
Production altyapısı nedir?
Production ortamı gerçek kullanıcıların kullandığı canlı sistemdir.
Minimum olarak şu katmanlar düşünülmelidir:
- application compute
- database
- network
- TLS ve erişim kontrolü
- storage
- backup
- monitoring ve alerting
- logging
- deployment
- recovery
Bu katmanlardan biri eksikse uygulama çalışıyor olabilir ama production operasyonu tamamlanmış sayılmaz.
1. Önce workload'u tanımlayın
Altyapı seçimine VM boyutuyla başlamayın.
Önce şunları netleştirin:
- kullanıcı sayısı
- trafik paterni
- peak saatler
- latency beklentisi
- database türü
- storage ihtiyacı
- kritik dependency'ler
- kabul edilebilir downtime
- RTO / RPO
- compliance veya veri konumu gereksinimleri
Bu bilgi olmadan seçilen altyapı ya gereğinden pahalı ya da yetersiz olabilir.
2. Uygulama compute katmanı
Uygulama şu modellerden biriyle çalışabilir:
- VM
- container
- managed container platform
- Kubernetes
- serverless
Doğru model ekip kapasitesine ve workload'a bağlıdır.
Küçük bir ekipte basit VM veya managed platform yeterliyken, Kubernetes operasyon yükünü gereksiz artırabilir.
3. Database'i application server'dan ayrı düşünün
Production database için şu konular ayrı değerlendirilmelidir:
- engine
- CPU / memory
- storage
- IOPS
- backup
- replication
- HA
- connection management
- monitoring
- recovery
Application ve database aynı VM üzerinde çalışabilir; ancak kritik production workload'larda failure domain ve bakım etkisi özellikle değerlendirilmelidir.
4. Private network ve erişim modeli
Production sisteminde her kaynak internete açık olmamalıdır.
Tipik yaklaşım:
- yalnız gerekli servisleri public erişime açmak
- database'i private network'te tutmak
- admin erişimini kontrollü hale getirmek
- firewall / security group kuralları kullanmak
- internal servisleri private endpoint veya private IP üzerinden konuşturmak
Network tasarımı sonradan eklenen bir detay değil, production mimarisinin temelidir.
5. TLS ve secret yönetimi
Public application trafiği TLS ile korunmalıdır.
Ayrıca:
- API key
- database password
- certificate private key
- token
gibi secret'lar source code veya düz metin config içinde tutulmamalıdır.
Secret lifecycle, erişim yetkisi ve rotation süreci tanımlanmalıdır.
6. Monitoring olmadan production yönetilemez
Production monitoring yalnız CPU grafiği değildir.
En az şu sinyalleri takip edin:
- request rate
- error rate
- latency
- saturation
- CPU / memory
- disk
- database health
- backup status
Google SRE yaklaşımı kullanıcı etkisini ölçen sinyaller ve anlamlı alert'ler üzerinden monitoring kurulmasını önerir.
Observability nedir? monitoring, logging ve tracing katmanlarını ayrıntılı açıklar.
7. Alarm geldiğinde kimin aksiyon alacağı belli olmalı
Monitoring tek başına yeterli değildir.
Her kritik alarm için:
- owner
- severity
- notification channel
- response expectation
- runbook
tanımlanmalıdır.
Alert üretip kimsenin sahiplenmediği sistem operasyonel olarak izlenmiyor demektir.
8. Backup var mı değil, restore çalışıyor mu?
Backup ancak geri yüklenebiliyorsa değerlidir.
Kontrol edin:
- son başarılı backup
- retention
- offsite / farklı failure domain
- encryption
- restore testi
- RPO
- RTO
Yedeğiniz var; geri dönüşünüz var mı? restore test yaklaşımını ayrıca ele alır.
9. Deployment sürecini standardize edin
Production deployment kişisel bilgisayardan manuel dosya kopyalama sürecine bağlı olmamalıdır.
İhtiyaca göre:
- CI/CD
- versioned artifact
- environment variables
- migration step
- health check
- rollback
standardize edilmelidir.
CI/CD nedir? deployment otomasyonunu detaylandırır.
10. Staging production'ın kopyası olmak zorunda değil
Staging'in amacı production davranışını deployment öncesinde doğrulamaktır.
Bu yüzden kritik bileşenler ve dependency'ler benzer olabilir; ancak kapasite aynı olmak zorunda değildir.
Örneğin:
- daha küçük VM
- daha küçük database
- daha az replica
- sınırlı çalışma saatleri
maliyet açısından daha doğru olabilir.
11. Yüksek erişilebilirlik her uygulama için zorunlu değil
HA ek kapasite, network ve operasyon maliyeti oluşturur.
Karar şu sorularla verilmelidir:
- 30 dakika downtime kabul edilebilir mi?
- 4 saat kabul edilebilir mi?
- müşteri SLA'sı var mı?
- revenue etkisi nedir?
- recovery süreci test edildi mi?
AWS Well-Architected yaklaşımı availability ve failure recovery kararlarının business requirement'lara göre tasarlanmasını önerir.
Basit bir uygulamada iyi test edilmiş backup + recovery planı, gereksiz karmaşık multi-zone mimariden daha doğru olabilir.
12. Single point of failure'ları bilin
Production sisteminde şu bileşenlerin her biri failure point olabilir:
- tek VM
- tek database
- tek network bağlantısı
- tek DNS provider
- tek deployment pipeline
- tek admin account
Her single point of failure mutlaka kaldırılmak zorunda değildir. Ancak bilinmeli ve business impact ile eşleştirilmelidir.
13. Patch ve vulnerability yönetimi
Production ortamında:
- operating system
- runtime
- database
- reverse proxy
- container image
- dependency
güncellemeleri planlı şekilde yönetilmelidir.
Patch işlemi doğrudan production üzerinde plansız yapılmamalı; test, bakım penceresi ve rollback yaklaşımı olmalıdır.
14. Access control ve least privilege
Admin erişimi minimum yetki prensibine göre tasarlanmalıdır.
Kontrol edin:
- kişisel hesaplar
- MFA
- role separation
- service accounts
- SSH / RDP erişimi
- audit log
Shared admin password production ortamı için zayıf bir operasyon modelidir.
15. Logging ne kadar tutulmalı?
Her log sonsuza kadar tutulmamalıdır.
Retention kararı:
- troubleshooting ihtiyacı
- security
- compliance
- maliyet
birlikte değerlendirilerek verilmelidir.
Gereksiz debug log ve yüksek cardinality telemetry hem gürültü hem maliyet üretir.
16. Capacity planning
Production kaynakları bugünkü ortalamaya göre değil, workload davranışına göre planlanmalıdır.
Takip edin:
- büyüme trendi
- peak
- campaign / release etkisi
- database growth
- storage growth
- network
Capacity review düzenli yapılmalıdır.
17. Maliyet production mimarisinin parçasıdır
Production altyapısı yalnız teknik olarak çalışmamalı, sürdürülebilir maliyet üretmelidir.
Kontrol edin:
- oversized VM
- idle resources
- dev/staging
- egress
- database
- backup
- logging
Yazılım Şirketleri Cloud Maliyetlerini Nasıl Düşürebilir? bu alanı FinOps açısından detaylandırır.
18. Incident response planı
Bir servis çöktüğünde ilk kez ne yapılacağını düşünmemelisiniz.
Minimum incident plan:
- olayı doğrula
- kullanıcı etkisini ölç
- owner belirle
- mitigation uygula
- gerekiyorsa rollback
- recovery doğrula
- postmortem çıkar
19. RTO ve RPO'yu yazılı hale getirin
RTO: servisin ne kadar sürede geri gelmesi gerektiğini ifade eder.
RPO: kabul edilebilir veri kaybı penceresini ifade eder.
Bu iki hedef backup, replication ve HA kararlarını doğrudan etkiler.
Disaster Recovery nedir? recovery planını ayrıntılı açıklar.
20. Infrastructure as Code ne zaman gerekli?
Tek VM'li küçük bir sistemde IaC ilk gün şart olmayabilir.
Ancak:
- birden fazla environment
- tekrar eden deployment
- birden fazla account
- büyüyen network
- sık infrastructure değişikliği
olduğunda IaC drift ve tekrar üretilebilirlik açısından değer kazanır.
Infrastructure as Code nedir? bu modeli detaylandırır.
Küçük yazılım şirketi için minimum production checklist
- workload inventory
- DNS ve TLS
- private network
- firewall
- application compute
- database
- backup
- restore testi
- monitoring
- alerting
- logging
- deployment
- rollback
- access control
- patch planı
- incident owner
- RTO / RPO
- cost review
Production altyapısını içeride mi yönetmeli?
Ekipte DevOps/SRE kapasitesi varsa içeride yönetilebilir.
Ancak geliştiriciler düzenli olarak:
- patch
- backup
- monitoring
- incident
- network
- database operations
ile uğraşıyorsa ürün geliştirme kapasitesi altyapı operasyonuna kayıyor olabilir.
Sistem yöneticisi işe almak mı, dış kaynak kullanmak mı? ve Bulut sunucu mu, yönetilen altyapı mı? bu kararı ayrıca ele alır.
Dynamis production altyapısında neyi yönetir?
Dynamis ihtiyaca göre:
- Windows / Linux sunucular
- AWS / Azure / Raff ortamları
- network
- backup
- monitoring
- patching
- security hardening
- performance
- capacity
- incident
- database operasyon koordinasyonu
- Kubernetes
katmanlarını yönetebilir.
Mevcut AWS veya Azure hesabınızı kullanmaya devam edebilirsiniz; Dynamis'e geçmek için Raff'a migration zorunlu değildir.
Yönetilen altyapı hizmeti, production ortamının mimari ve günlük operasyonunu tek sorumluluk modeli altında toplar.
Sık yapılan hatalar
Production'ı yalnız sunucu olarak görmek: Database, network, backup ve operations ayrı katmanlardır.
Monitoring var ama alert owner yok: Alarm aksiyona dönüşmüyorsa operasyon eksiktir.
Backup var ama restore testi yok: Recovery doğrulanmadan backup yeterli kabul edilmemelidir.
Staging'i production kadar büyük kurmak: Davranış benzer olabilir, kapasite olmak zorunda değildir.
Her sisteme Kubernetes kurmak: Platform karmaşıklığını workload ihtiyacıyla karşılaştırın.
HA'yı varsayılan kabul etmek: Availability hedefini business impact ile belirleyin.
Sonuç
İyi production altyapısı en fazla servisi kullanan değil, business gereksinimini en az gereksiz karmaşıklıkla karşılayan sistemdir.
Compute, database, network, güvenlik, monitoring, backup, deployment ve incident operasyonu birlikte tasarlandığında küçük bir yazılım ekibi de güvenilir production ortamı kurabilir.
Sırada ne var
- Bulut sunucu mu, yönetilen altyapı mı?
- Sistem yöneticisi işe almak mı, dış kaynak kullanmak mı?
- Observability nedir?
- Disaster Recovery nedir?
- Yazılım Şirketleri Cloud Maliyetlerini Nasıl Düşürebilir?
- Yönetilen altyapı hizmeti
Kaynaklar
Kaynaklar
- 1.AWS Well-Architected Framework — Reliability PillarAmazon Web Services · 2026-09-29
- 2.AWS Well-Architected Framework — Operational ExcellenceAmazon Web Services · 2026-09-29
- 3.Monitoring Distributed SystemsGoogle SRE · 2026-09-29
- 4.Alerting on SLOsGoogle SRE · 2026-09-29
Sık sorulan sorular
Production altyapısı nedir?
Production altyapısı, gerçek kullanıcı trafiğini taşıyan uygulama, database, network, storage, güvenlik, monitoring, backup ve deployment bileşenlerinin birlikte çalıştığı canlı ortamdır. Amaç yalnız uygulamayı çalıştırmak değil; erişilebilirlik, performans, güvenlik ve geri dönüş kabiliyetini sürdürülebilir hale getirmektir.
Küçük bir yazılım şirketinin production ortamında hangi bileşenler olmalı?
Minimum yapı uygulama compute katmanı, database, private network, TLS, backup, monitoring ve alerting, log yönetimi, erişim kontrolü, deployment süreci ve dokümante edilmiş recovery adımlarını kapsamalıdır. Yüksek erişilebilirlik ve ek servisler workload ihtiyacına göre eklenmelidir.
Production ortamında staging gerekli midir?
Çoğu yazılım ekibi için staging, deployment, migration ve konfigürasyon değişikliklerini production öncesinde doğrulamak için değerlidir. Ancak staging'in production ile birebir aynı kapasitede olması gerekmez; kritik bağımlılıklar ve davranışlar benzer tutulurken kaynak boyutu daha düşük olabilir.
Production altyapısında yüksek erişilebilirlik her zaman gerekli mi?
Hayır. Yüksek erişilebilirlik maliyet ve operasyon karmaşıklığı ekler. Karar, kabul edilebilir downtime, RTO/RPO, müşteri etkisi ve iş kritikliği üzerinden verilmelidir. Küçük bir uygulama için basit ama test edilmiş recovery planı, gereksiz multi-zone karmaşıklığından daha doğru olabilir.
Production altyapısını şirket içinde mi yönetmek gerekir?
Hayır. Ekipte yeterli DevOps/SRE kapasitesi varsa içeride yönetilebilir; aksi durumda monitoring, backup, patching, incident response ve capacity gibi sorumluluklar yönetilen hizmet modeliyle dışarıdan alınabilir. Karar toplam operasyon yükü ve ekip odağına göre verilmelidir.