- 01Bulut sunucu compute, bellek, disk ve ağ sağlar; yönetilen altyapı bunun üzerine patching, monitoring, backup, güvenlik ve incident ownership ekler.
- 02AWS EC2 gibi IaaS modellerinde guest işletim sistemi, security patch'leri ve uygulama yapılandırmasının önemli bölümü müşterinin sorumluluğunda kalır.
- 03Yalnız VM fiyatı ile managed service bedelini karşılaştırmak eksik TCO üretir; mühendislik zamanı ve incident maliyeti de hesaba katılmalıdır.
- 04Küçük ekipte production operasyonunu net sahiplenen kişi varsa self-managed model sürdürülebilir olabilir; sahiplik dağınıksa yönetilen hizmet daha anlamlı hale gelir.
- 05Managed service'e geçmek cloud provider değiştirmek anlamına gelmez; mevcut AWS, Azure veya başka cloud ortamı üzerinde de operasyon dış kaynak kullanılabilir.

Kısaca
Bulut sunucu satın almak ile yönetilen altyapı hizmeti almak aynı karar değildir. Bulut sunucu size compute, bellek, disk ve ağ kaynağı sağlar; yönetilen altyapı ise bunun üzerine patching, monitoring, backup kontrolü, güvenlik, incident müdahalesi ve kapasite yönetimi gibi sürekli operasyon sorumluluğunu ekler. Dynamis Teknoloji, küçük yazılım ekiplerinde bu kararı yalnız aylık VM fiyatına göre değil, toplam operasyon yükü ve sahiplik modeline göre verir.
Bulut sunucu ile yönetilen altyapı arasındaki fark
Bir IaaS bulut sunucu satın aldığınızda altyapının fiziksel katmanını sağlayıcı işletir. Ancak guest işletim sistemi, güncellemeler, uygulama bileşenleri ve yapılandırmanın önemli bir bölümü hâlâ sizin sorumluluğunuzda kalır.
AWS'nin güncel shared responsibility modelinde EC2 müşterisi guest işletim sistemi, security patch'leri, uygulama yazılımları ve security group yapılandırmasından sorumludur.
Yönetilen altyapı hizmeti bu müşteri tarafındaki operasyonların bir bölümünü dışarıdan üstlenir.
| Alan | Yalnız bulut sunucu | Yönetilen altyapı |
|---|---|---|
| VM sağlama | Sağlayıcı | Sağlayıcı / yönetilen ekip |
| İşletim sistemi | Siz | Yönetilen hizmet kapsamında olabilir |
| Patching | Siz | Hizmet kapsamında |
| Monitoring | Siz kurarsınız | Sürekli izleme sağlanabilir |
| Backup | Siz planlarsınız | Politika ve doğrulama yönetilebilir |
| Security hardening | Siz | Hizmet kapsamında olabilir |
| Incident müdahalesi | Siz | 7/24 operasyon modeli kurulabilir |
| Kapasite planlama | Siz | Periyodik analiz yapılabilir |
| Uygulama kodu | Siz | Siz |
Dynamis uygulama kodunu geliştirmez; production altyapısının kurulumu ve operasyonunu yönetir.
Bulut sunucu satın almak ne zaman yeterlidir?
Yalnız bulut sunucu almak şu durumda mantıklıdır:
- Ekipte Linux veya Windows sunucu operasyonunu sahiplenen biri varsa
- Patching takvimi tanımlıysa
- Monitoring ve alerting kurulmuşsa
- Backup düzenli test ediliyorsa
- Incident olduğunda kimin müdahale edeceği belliyse
- Kapasite ve maliyet takibi yapılıyorsa
- Production değişiklikleri runbook ile ilerliyorsa
Bu yapıda dışarıdan yönetilen hizmet almak zorunlu değildir.
Özellikle küçük ancak teknik olarak güçlü ekipler birkaç VM'i kendi içinde verimli şekilde yönetebilir.
Yönetilen altyapı ne zaman anlamlı hale gelir?
Yönetilen model şu sinyaller ortaya çıktığında daha güçlü adaydır.
Geliştiriciler production operasyonuna bölünüyorsa
Backend veya full-stack geliştiriciler düzenli olarak:
- sunucu patch
- disk doluluk
- SSL yenileme
- log temizleme
- backup kontrolü
- CPU/RAM problemi
- erişim sorunu
çözüyorsa yazılım geliştirme zamanı altyapı operasyonuna kayıyor demektir.
Tek kişi kritik bilgi taşıyorsa
Bir kurucu veya senior geliştirici:
- SSH anahtarlarını
- firewall kurallarını
- backup yapısını
- deployment sürecini
- monitoring sistemini
tek başına biliyorsa operational bus factor düşüktür.
7/24 müdahale ihtiyacı varsa
Production sistem gece veya hafta sonu da müşteri etkiliyorsa "mesai başlayınca bakarız" modeli yeterli olmayabilir.
Altyapı sayısı büyüyorsa
Bir VM kolay yönetilebilir.
Ancak sistem:
- web sunucuları
- database
- worker
- load balancer
- backup
- VPN
- monitoring
gibi bileşenlere ayrıldıkça koordinasyon maliyeti artar.
Bulut sunucunun görünmeyen operasyon maliyeti
Bulut sunucu aramalarında genellikle aylık VM fiyatı karşılaştırılır.
Gerçek toplam maliyet ise:
Altyapı ücreti + mühendislik zamanı + monitoring + backup + incident + güvenlik + bakım
şeklindedir.
Örnek olarak küçük bir production ortamında her ay:
- 2 saat patching
- 2 saat monitoring ve alert tuning
- 2 saat backup kontrolü
- 3 saat incident/troubleshooting
- 1 saat kapasite ve maliyet kontrolü
harcanıyorsa toplam 10 saat teknik zaman oluşur.
Bu saatlerin her ay sabit olması gerekmez. Ama karar verirken "VM 100 dolar, managed service 300 dolar" gibi yalnız servis fiyatı karşılaştırması yapmak eksik olur.
Asıl soru, yönetilen hizmetin hangi teknik zamanı ve hangi operasyon riskini devraldığıdır.
Yönetilen altyapı hangi işleri kapsamalı?
Her sağlayıcının kapsamı farklı olabilir.
Dynamis yaklaşımında yönetilen production altyapısı şu operasyonları kapsayabilir:
- Linux ve Windows sunucu yönetimi
- OS ve security update
- Monitoring ve alerting
- Backup kontrolü
- Restore testleri
- Firewall ve erişim yönetimi
- Performance troubleshooting
- Resource optimization
- Capacity planning
- Incident response
- Cloud provider operasyonu
- Migration sonrası sürekli yönetim
Bu liste sözleşme kapsamında netleştirilmelidir.
"Managed" kelimesi tek başına hangi operasyonun dahil olduğunu garanti etmez.
Yönetilen hizmet uygulama kodunu da yönetir mi?
Her zaman değil.
Dynamis modelinde sınır production altyapısıdır.
Örneğin:
Dynamis yönetebilir:
- VM
- Kubernetes
- network
- CI/CD altyapısı
- monitoring
- backup
- işletim sistemi
- database altyapısı
- deployment operasyonu
Müşteri yönetir:
- business logic
- uygulama kodu
- product feature
- uygulama içi bug
- veri modeli değişikliği
Bu sorumluluk sınırının baştan yazılması incident sırasında "bu kimin problemi?" tartışmasını azaltır.
Küçük yazılım ekibi için karar modeli
5-20 kişilik yazılım şirketinde şu tablo işe yarar:
| Soru | Evet | Hayır |
|---|---|---|
| Production sunucularının net sahibi var mı? | Self-managed mümkün | Managed değerlendirin |
| 7/24 incident sorumluluğu tanımlı mı? | Self-managed mümkün | Managed değerlendirin |
| Backup restore test ediliyor mu? | Devam | Managed/iyileştirme değerlendirin |
| Patching düzenli mi? | Devam | Operasyon açığı |
| Monitoring aktif mi? | Devam | Operasyon açığı |
| Dev'ler sık sık altyapı sorunu çözüyor mu? | Managed daha anlamlı | Self-managed sürdürülebilir olabilir |
| Altyapı büyüyor mu? | Managed veya DevOps ownership | Basit model yeterli olabilir |
Bu tablo otomatik karar vermez; eksik operasyon sahipliğini görünür kılar.
Bulut sağlayıcısının managed service olmasıyla altyapı yönetimi aynı şey değildir
RDS gibi managed database servisleri belirli platform operasyonlarını sağlayıcıya devredebilir.
Ama şirketin tüm production altyapısı yine:
- IAM
- network
- monitoring
- backup policy
- cost
- incident coordination
- application deployment
gibi operasyonlar gerektirir.
Yönetilen altyapı hizmeti tek bir cloud ürününü değil, sistemin tamamındaki operasyon sahipliğini hedefler.
AWS veya Azure kullanmak operasyon ihtiyacını ortadan kaldırmaz
Hyperscaler kullanmak fiziksel altyapı işletme yükünü azaltır.
Ancak IaaS modelinde guest OS, application configuration, identity ve birçok security kontrolü müşteride kalır.
Bu nedenle "AWS kullanıyoruz, altyapı zaten yönetiliyor" ifadesi EC2/VM tabanlı sistemlerde tam doğru değildir.
Managed service yoğunluğu arttıkça müşterinin operasyon kapsamı azalabilir; fakat veri, erişim ve uygulama tarafındaki sorumluluk devam eder.
Kendi DevOps ekibi ile yönetilen altyapı arasındaki fark
Yönetilen altyapı hizmeti, tam zamanlı DevOps/SRE ekibinin birebir alternatifi değildir.
İç ekip şu avantajları sağlar:
- Şirkete özel derin bağlam
- Ürün ekibiyle yakın çalışma
- Platform roadmap kontrolü
- Internal tooling geliştirme
Dış kaynak model ise:
- Daha hızlı operasyon sahipliği
- Birden fazla uzmanlığa erişim
- Nöbet/continuity modelinin dışarıdan kurulması
- Küçük ekipte sabit headcount ihtiyacını azaltma
gibi avantajlar sağlayabilir.
Bu kararı daha ayrıntılı olarak Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi içeriğinde karşılaştırıyoruz.
Managed service seçerken kapsamı nasıl kontrol edin?
Teklifte şu alanları açıkça arayın:
- 7/24 mü, mesai saatleri mi?
- Incident response süresi nedir?
- Patching dahil mi?
- Backup dahil mi?
- Restore testi dahil mi?
- Monitoring kimde?
- Cloud faturası kimde?
- Change management nasıl?
- Security hardening kapsamı ne?
- Uygulama kodu dahil mi?
- Migration dahil mi?
- Aylık raporlama var mı?
Bu maddeler yoksa "managed" ifadesi yoruma açık kalır.
Yönetilen altyapıya geçiş nasıl yapılır?
Mevcut ortamın tamamen taşınması her zaman gerekmez.
Dynamis müşterinin mevcut AWS, Azure veya başka cloud hesabını da yönetebilir.
Onboarding tipik olarak:
- Altyapı envanteri
- Erişim ve yetki düzenleme
- Monitoring kurulumu
- Backup ve restore kontrolü
- Security baseline
- Patch durumu
- Incident runbook
- Kapasite ve maliyet baseline
- Sürekli operasyon
şeklinde ilerler.
Yani managed service'e geçmek mutlaka cloud provider değiştirmek anlamına gelmez.
Hangi durumda sağlayıcı değiştirmek gerekir?
Mevcut sağlayıcı:
- maliyet hedefini karşılamıyorsa
- gerekli region yoksa
- workload için uygun değilse
- operasyonel kısıt yaratıyorsa
migration ayrıca değerlendirilebilir.
Ancak provider değişikliği ile managed operations kararını ayrı tutmak gerekir.
AWS alternatifi: hangi iş yükü nerede kalmalı? bu placement kararını workload bazında ele alır.
Backup operasyonu managed hizmet kararında kritik testtir
Bir şirket "sunucularımız yönetiliyor" diyorsa şu soruyu sorun:
Son restore testi ne zaman yapıldı?
Backup'ın alınması ile geri dönüşün doğrulanması farklı operasyonlardır.
Yedek geri yükleme testi gerçek RPO/RTO ölçümünü ve restore runbook'unu detaylandırır.
Dynamis'te managed infrastructure yaklaşımı
Dynamis'in kurumsal altyapı hizmeti, yalnızca sunucu sağlamaya değil production operasyonunu sürekli yönetmeye odaklanır.
İlk değerlendirmede:
- mevcut cloud/provider
- VM ve servis envanteri
- deployment süreci
- monitoring
- backup
- incident geçmişi
- security
- kapasite
- ekip sahipliği
incelenir.
Sonra iki sonuçtan biri çıkabilir:
Self-managed devam: Ekip mevcut ortamı sağlıklı şekilde yönetebiliyorsa yalnızca belirli iyileştirmeler yapılır.
Managed operations: Operasyon sahipliği dağınıksa Dynamis sürekli yönetim sorumluluğunu devralabilir.
Amaç her bulut sunucu müşterisine managed service satmak değil; production operasyonunda gerçek sahiplik boşluğu varsa bunu kapatmaktır.
Sık yapılan hatalar
VM fiyatını toplam maliyet sanmak: Mühendislik ve incident zamanı da maliyettir.
Cloud provider her şeyi yönetiyor sanmak: IaaS'ta guest OS ve uygulama sorumluluğu müşteride kalır.
Managed hizmetin kapsamını yazmamak: Patching, backup ve monitoring dahil olup olmadığı net olmalıdır.
Provider değişikliği ile operasyon outsourcing'i karıştırmak: Mevcut cloud üzerinde de managed service verilebilir.
Geliştiriciyi varsayılan sysadmin yapmak: Küçük ekipte kısa vadede çalışabilir, uzun vadede product velocity'yi etkileyebilir.
Sırada ne var
- Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: internal ekip ile dış kaynak operasyon modelini karşılaştırın.
- Observability nedir? Monitoring, logging ve tracing farkları: yönetilen altyapı kapsamındaki monitoring, log, tracing ve incident visibility sorumluluklarını değerlendirin.
- Sistem yöneticisi işe almak mı, dış kaynak kullanmak mı?: managed infrastructure kararını headcount, 7/24 coverage ve operasyon sahipliği açısından karşılaştırın.
- Active Directory nedir? Şirketlerde nasıl kullanılır?: Windows Server, Domain Controller, DNS ve Group Policy operasyonlarının yönetim kapsamını görün.
- Disaster Recovery nedir? Şirketler için felaket kurtarma planı: yönetilen altyapı kapsamındaki RPO/RTO, failover ve kurtarma sorumluluğunu planlayın.
- Yedek geri yükleme testi: managed service kapsamındaki recovery sorumluluğunu ölçün.
- AWS alternatifi: hangi iş yükü nerede kalmalı?: cloud provider kararını operasyon modelinden ayrı değerlendirin.
- Kurumsal altyapı hizmeti: production altyapınız için sürekli operasyon modelini değerlendirin.
Kaynaklar
Kaynaklar
- 1.AWS Shared Responsibility ModelAmazon Web Services · 2026-09-19
- 2.Shared Responsibility - AWS Well-Architected Security PillarAmazon Web Services · 2026-09-19
Sık sorulan sorular
Bulut sunucu ile yönetilen altyapı arasındaki fark nedir?
Bulut sunucu compute, bellek, disk ve ağ kaynağını sağlar. Yönetilen altyapı ise bu kaynakların üzerine işletim sistemi güncellemeleri, monitoring, backup kontrolü, güvenlik, incident müdahalesi ve kapasite yönetimi gibi sürekli operasyon sorumluluğunu ekler.
Küçük yazılım ekibi için yalnız bulut sunucu yeterli mi?
Ekipte sunucu güncelleme, izleme, yedek doğrulama, güvenlik ve incident müdahalesini düzenli sahiplenen biri varsa yeterli olabilir. Bu operasyonlar geliştiriciler arasında dağınık kalıyorsa yönetilen altyapı daha uygun olabilir.
Yönetilen bulut altyapısı hangi işleri kapsar?
Kapsam sağlayıcıya göre değişir. Tipik olarak sunucu kurulumu, patching, monitoring, alerting, backup kontrolü, güvenlik hardening, performans takibi, kapasite planlama ve incident troubleshooting gibi operasyonlar yönetilen hizmet kapsamına alınabilir.
Yönetilen altyapı bulut sunucudan daha pahalı mı?
Aylık hizmet bedeli nedeniyle yalnız VM maliyetinden daha yüksek görünebilir. Doğru karşılaştırma; altyapı ücretine ek olarak mühendislik zamanı, 7/24 müdahale, monitoring, backup, patching ve incident maliyetini de içeren toplam operasyon maliyetidir.
Bulut sağlayıcısı sunucunun işletim sistemini de yönetir mi?
IaaS modelinde genellikle hayır. Örneğin AWS EC2 shared responsibility modelinde müşteri guest işletim sistemi, güncellemeler, uygulama yazılımları ve güvenlik grubu yapılandırmasından sorumludur. Yönetilen hizmet bu müşteri tarafındaki operasyonların bir bölümünü üstlenebilir.