Yönetilen Sunucu Kiralama: İzleme, Bakım ve SLA Rehberi

Yönetilen sunucu kiralama, işletmenin kullandığı fiziksel veya sanal sunucunun yalnızca barındırılmasını değil, sözleşmede belirtilen işletim sistemi yönetimi, izleme, bakım ve olay müdahalesi görevlerinin de hizmet sağlayıcı tarafından yürütülmesini kapsayan modeldir. Ancak her sağlayıcı aynı işleri üstlenmez. Bazıları yalnız sunucuyu izlerken bazıları yama yönetimi, yedek takibi ve mesai dışı mühendis desteğini ayrıca sunabilir.

Kısa cevap: Kurumsal yönetilen sunucu teklifi alırken CPU ve RAM'e ek olarak hangi servislerin izlendiğini, alarmlara kimin müdahale ettiğini, SLA'daki ilk yanıt ve çözüm hedeflerini, güncelleme ve yedekleme kapsamını yazılı olarak isteyin. Yönetilen sunucu hizmetlerini inceleyebilir, ihtiyaçlarınız netse kurumsal sunucu kiralama teklifi talep edebilirsiniz.

Bu rehber; işletim ekibi sınırlı KOBİ'ler, çok şubeli şirketler, SQL Server ve ERP kullanan kurumlar ile operasyonunu dış kaynakla yürütmek isteyen BT yöneticileri için hazırlandı. Anlatılan maddeler sözleşmede sorulması gereken kriterlerdir; belirli bir sağlayıcının bütün paketlerinde bu hizmetleri sunduğu veya garanti ettiği anlamına gelmez.

1. Yönetilen ve yönetilmeyen sunucu arasındaki fark nedir?

Yönetilmeyen (self-managed) sunucu modelinde hizmet sağlayıcı donanım, sanallaştırma, ağ ve veri merkezi kaynaklarını tanımlı kapsamda sunabilir; işletim sistemi, güvenlik yamaları, uygulama servisleri ve veritabanı yönetimi müşterinin sorumluluğunda kalabilir. Yönetilen modelde ise belirli operasyon işleri sağlayıcı tarafından üstlenilir. Teklifte görevlerin tek tek yazılması, yanlış beklentileri önler.

Örneğin Windows Server üzerinde çalışan bir SQL servisinin durmuş olduğunun izleme aracında görülmesi, sorgu optimizasyonunun da pakete dahil edildiği anlamına gelmez. Logo, Mikro veya SAP uygulamasındaki rapor hataları ise altyapı destek ekibinden çok yazılım üreticisinin görev alanına girebilir. Bu nedenle altyapı, işletim sistemi, veritabanı ve uygulama destek katmanları birbirinden ayrılmalıdır.

Kıyaslamada yalnız aylık hizmet bedelini değil, kurum içi sistem yöneticisinin harcadığı zamanı, mesai dışı çağrı ihtiyacını, değişiklik yönetimini ve olası arızaların iş süreçlerine etkisini de değerlendirin. Yönetilen sunucu, işin tüm teknik sorumluluğunu otomatik olarak hizmet sağlayıcısına devretmez.

2. 7/24 izleme hizmeti hangi metrikleri kapsamalı?

Kurumsal sunucunun açık olması, iş uygulamasının sağlıklı olduğu anlamına gelmez. İzleme planında işlemci ve bellek kullanımı, disk doluluğu ve gecikme, ağ paket kaybı, depolama hataları, Windows/Linux kritik servisleri, yedek işlerinin başarısı ve gerekiyorsa SQL veya web uygulaması sağlığı bulunabilir. Hangi verinin gerçekten izlendiği tekliften anlaşılmalıdır.

Microsoft'un Windows Server performans izleme eğitimi, performans sayaçlarıyla hem anlık durumu hem geçmiş eğilimleri değerlendirmenin önemini açıklar. Bu yaklaşım yalnız doluluk eşiği belirlemekten daha değerlidir: sürekli artan veri büyüklüğü veya belirli saatlerdeki gecikme, kapasite kararına zamanında dönüşebilir.

Her alarm için eşik, önem derecesi, bildirilecek ekip, mesai dışı takip ve raporlama kanalı tanımlayın. Yalnız ping yanıtına veya HTTP 200 sonucuna bakılan izleme, durmuş bir SQL hizmetini ya da işlevini kaybetmiş bir ERP uygulamasını gözden kaçırabilir. Alarmların yanlış pozitifleri de düzenli incelenmelidir.

3. İzleme ile gerçek olay müdahalesi arasındaki sınır

7/24 izleme, 7/24 mühendis müdahalesiyle aynı şey değildir. Bir sağlayıcı gece gelen alarmı e-posta ile iletebilir; diğeri olay kaydı açıp yetkili sistem mühendisiyle analiz başlatabilir. Destek seviyelerini karşılaştırırken tam bu ayrımın yazılı olmasına dikkat edin. “Alarm gönderimi” tek başına sorun çözme taahhüdü değildir.

NIST'in SP 800-61 Rev. 3 olay müdahalesi rehberi, güvenlik olayları için hazırlık, tespit, yanıt ve toparlanma süreçlerinin birlikte yönetilmesini önerir. Bu rehber genel olay disiplini için yararlıdır; bununla birlikte her disk veya performans alarmı bir güvenlik olayı değildir. İşletim ve güvenlik olayları farklı eskalasyon akışları gerektirebilir.

Satın alma toplantısında somut bir senaryo sorun: Pazar sabahı SQL servisi durduğunda kim haberdar olur, kim uzaktan bağlanır, kime onay sorulur ve yeniden çalıştığı nasıl doğrulanır? Hizmet sağlayıcısının mühendislik kapsamı ile ERP yazılımının üretici desteği ayrı görevler olarak gösterilmelidir.

4. Yama yönetimi ve planlı bakım nasıl olmalı?

Sunucu güvenlik güncellemeleri ertelendikçe risk büyüyebilir; ancak kritik bir üretim sunucusunun kontrolsüz biçimde yeniden başlatılması da iş kesintisine neden olabilir. Bu nedenle güncelleme önceliği, etkilenen uygulama, test ortamı, bakım penceresi, ön yedek, geri dönüş prosedürü ve bakım sonrası kabul kontrolü birlikte planlanmalıdır.

NIST'in SP 800-53 Release 5.2.0 duyurusu, yazılım yamalarının test edilmesi, güvenilir biçimde dağıtılması ve yönetilmesiyle ilgili kontrolleri vurgular. Özellikle muhasebe yazılımlarında Windows Server, SQL Server, .NET veya diğer bağımlılıkların sürüm uyumluluğunu üreticiyle doğrulamak gerekir.

Planlı aylık bakım ve acil kritik zafiyet müdahalesi farklı süreçlerdir. Hizmet kapsamına yama uygunluk kontrolü, değişiklik onayı, yeniden başlatma, uygulama testi, başarısız işlemde rollback ve bakım raporu dahil mi? Bunların hangilerinin müşterinin BT ekibi tarafından yapılacağı açıkça tanımlanmalıdır.

5. Yedekleme varsa geri yükleme de garanti mi?

Yedekleme başlığı, tek başına verinin geri döndürülebileceğini kanıtlamaz. Hangi sunucuların, veritabanlarının ve yapılandırmaların yedeklendiği; uygulama tutarlılığı; saklama süresi; şifreleme; ayrı güvenlik alanı; geri yükleme testi ve silme politikası birlikte değerlendirilmelidir. RAID ile snapshot bağımsız yedeklemenin yerine geçmez.

NIST'in 2026 fidye yazılımı risk yönetimi profili, koruma kadar toparlanma hazırlığını da risk yönetiminin bir parçası olarak ele alır. Silinen veya şifrelenen verinin farklı bir güvenlik alanındaki kopyadan döndürülebilmesi için yedeklerin erişim ve silinme yetkileri de ayrıştırılmalıdır.

RPO iş biriminin kabul edebileceği veri kaybı aralığı, RTO ise hizmetin geri gelmesi için hedef süredir. Bu hedefler iş yüküne göre değişir. Yedekleme ve felaket kurtarma hizmetleri teklifin içinde mi yoksa ayrı mı fiyatlanıyor; geri yükleme tatbikatının sonucunu kim onaylıyor, yazılı olarak netleştirin.

6. Firewall, VPN, MFA ve güvenlik kayıtlarını kim yönetir?

Yönetilen sunucu kullanılması bütün siber güvenlik sorumluluğunun otomatik olarak sağlayıcıya geçtiği anlamına gelmez. Bir taraf fiziksel ve sanal altyapıyı yönetirken şirket kullanıcıların iş uygulaması yetkilerini ve veri saklama kararlarını sürdürüyor olabilir. Erişim yönetimi ve operasyon sorumluluğu, sözleşme maddesi ve yetki matrisiyle açıklanmalıdır.

Yönetici bağlantıları için kişiye özel hesaplar, en az yetki, uygun çok faktörlü kimlik doğrulama, VPN veya ayrı yönetim ağı, erişim kaydı ve hizmet bitiminde hesap kapatma süreçleri belirlenmelidir. Ağ ve güvenlik hizmetleri kapsamındaki firewall, WAF veya VPN ayrıca fiyatlanabilir; pakette var olduğu varsayılmamalıdır.

Ayrıca logların nerede tutulduğu, kimin eriştiği, kaç süre saklandığı ve olası bir ihlal incelemesinde nasıl korunacağı sorulmalıdır. “Firewall kuruludur” ifadesi güvenlik yönetiminin tamamını tarif etmez. Kural güncelleme ve acil olay müdahalesi için yetkili onay noktası tanımlanmalıdır.

7. SLA: ilk yanıt, müdahale ve çözüm neden ayrı?

İlk yanıt talebin alındığının bildirilmesi, müdahaleye başlama teknik incelemenin başlaması, çözüm süresi ise sorun giderildiğinde veya tanımlı hizmet geri verildiğinde ortaya çıkan ölçüttür. Bu üç zamanı birbirine karıştırmak, hem BT hem satın alma ekibinin yanlış güvenceye dayanmasına yol açabilir.

Çalışma süresi yüzdesi de farklı bir konudur. Ölçülen hizmet, istisnalar, planlı bakım, ölçüm yöntemi ve olası ihlalde uygulanacak süreç sözleşmede yazılmalıdır. Veri merkezinin ağ geçidi çalışırken belirli ERP uygulaması erişilemez olabilir; altyapı erişilebilirliği ile iş uygulaması kullanılabilirliği aynı metrik değildir.

Teklifte olayın önceliği, saatlik kapsam, iletişim kanalı, yetkili kişi, eskalasyon zinciri ve rapor teslimi yer almalıdır. Doğrulanmamış “yüzde yüz kesintisiz” iddiasından çok işletmenin test edebileceği sorumlulukların tanımlanması önemlidir. SLA ve veri koruma maddeleri nihai sözleşme öncesi hukuk danışmanının incelemesine sunulmalıdır.

8. SQL Server ve ERP gibi uygulamalarda kimden destek alınır?

İşletim sistemi sağlığı ile uygulama performansı farklı uzmanlık alanlarıdır. SQL servisi çalışıyor olsa bile veritabanı sorguları yavaş, log dosyası dolu veya üreticiye özel entegrasyon hata veriyor olabilir. Yönetilen sunucu paketinde işletim sistemi takibi bulunabilir; ancak DBA sorgu optimizasyonu, indeks bakımı veya lisans danışmanlığı ayrıca tanımlanabilir.

Özellikle Logo, Mikro, Zirve ve SAP gibi uygulamalarda üretici sürümü, uzaktan erişim yöntemi, Windows ve SQL Server lisansları, yazıcı ve e-belge bağlantıları değişiklik öncesi doğrulanmalıdır. Uygulama üreticisinin destek sınırlarıyla sistem yönetim ekibinin görevleri aynı kişi veya kuruma otomatik olarak yüklenmez.

ERP ve muhasebe uygulamaları altyapısı için sözleşmede örnek olay akışı belirleyin: kullanıcı bağlantı kuramıyor, SQL servisi durdu veya e-belge işlemi hata verdi. Hangi durum altyapı sorunu, hangi durum uygulama desteği sayılacak? Yetkili üreticiye aktarım ve iletişim sorumluluğu net olsun.

9. Yönetilen sunucu fiyatını hangi kalemler etkiler?

Toplam aylık bedel; CPU, RAM, disk, trafik ve işletim sistemi veya SQL lisansları yanında izleme kapsamı, yama yönetimi, alarm müdahalesi, yedekleme, güvenlik ve periyodik raporlamayı içerebilir. İlk kurulum, sunucu taşıma, ek mühendislik ve mesai dışı özel operasyonlar bazı hizmetlerde ayrı bedellendirilir.

Self-managed ve managed teklifleri eşit karşılaştırırken şirket içindeki BT ekibinin nöbet yükü, düzenli bakım zamanı, yedek kontrolü ve olay çözüm kapasitesini de hesaba katın. En ucuz aylık kira, sözleşme dışında kalan hizmetler dahil edildiğinde en düşük toplam işletme maliyeti anlamına gelmeyebilir.

İş yükünüze göre VPS/bulut sunucu veya dedicated fiziksel sunucu altyapısı tercih edilebilir. Yönetim hizmetinin fiyatını donanım ve lisans kalemlerinden ayrı görmek, sonradan ortaya çıkan ek görevleri daha iyi yönetmeyi sağlar.

10. Satın alma için görev ve sorumluluk matrisi

“Tam yönetim” gibi genel ifadeler yerine aşağıdaki tabloyu teklif görüşmesinde doldurmak daha güvenilir bir karşılaştırma sağlar:

Tabloyu tek bir Windows Server için bile hazırlamak yararlıdır. Farklı şubelerin aynı veritabanına bağlandığı, muhasebe ve dosya servislerinin birlikte çalıştığı sistemlerde sorumluluk sınırları özellikle önem kazanır. Hizmet tanımının dışında kalan iş için ayrıca fiyat veya bakım anlaşması istenebilir.

11. Sunucu bakım anlaşması için 12 maddelik kontrol listesi

Aşağıdaki adımlar hem satın alma hem BT yöneticisinin aynı teklifi değerlendirmesini sağlar:

1. Sunucu sayısı, işletim sistemi, uygulamalar ve mevcut altyapı envanteri belli mi?
2. İzlenen metrikler, alarm eşikleri ve servis kontrolleri listelendi mi?
3. Mesai dışı alarm takibi ile teknik müdahale ayrı tanımlandı mı?
4. İlk yanıt, müdahale ve çözüm süreleri farklı ölçülüyor mu?
5. Yama planı, bakım penceresi ve değişiklik onayı yazıldı mı?
6. Kritik güncelleme öncesi test ve geri dönüş prosedürü var mı?
7. Yedek kapsamı, saklama, RPO/RTO ve geri yükleme testi açık mı?
8. ERP, SQL, AD, VPN ve özel uygulamalar için destek sınırı belli mi?
9. Yönetici erişiminde MFA, yetki yönetimi ve log sorumluluğu tanımlı mı?
10. Olay raporu, kapasite raporu ve düzenli toplantı kapsamı belli mi?
11. Ek mühendislik, lisans, kapasite artışı ve kurulum ücretleri ayrı mı?
12. Sözleşme bitiminde veri teslimi, erişim kapatma ve silme adımları yazılı mı?

Örnek bir durum üzerinden sağlayıcıyı değerlendirin: “Cumartesi gece SQL servisi durdu; yedekleme de hata verdi. Kim alarmı görür, kim teknik işlem yapar ve uygulama ne zaman test edilir?” Bu soruya roller ve ölçülebilir eylemlerle cevap verilemiyorsa kapsamın netleştirilmesi gerekir.

12. İşletmenize özel yönetilen sunucu teklifi nasıl alınır?

İhtiyaç analizi için mevcut sunucu sayısını, işletim sistemlerini, SQL/veritabanı kapasitesini, kullanılan ERP ve diğer uygulamaları, kullanıcı ve şube sayısını, internet/VPN yapısını, mevcut destek modelini ve yedekleme beklentisini hazırlayın. Mevcut sistemin CPU/RAM ve disk performansı ölçülmediyse tahmini kaynakları kesin sayı gibi sunmayın.

Netsun Bilişim ile görüşürken yalnız donanımı değil, izleme kapsamını, bakım takvimini, olay müdahalesini, ayrı güvenlik ve yedekleme katmanlarını da değerlendirmeniz gerekir. Doğru teklif işletmenize uygun sorumluluk matrisi ve test edilebilir hizmet hedefleriyle oluşturulur; doğrulanmamış uptime veya fiyat vaadine dayanmaz.

Kurumsal sunucunuzun altyapısını ve işletim desteğini birlikte planlamak için yönetilen sunucu kiralama ve bakım hizmeti teklifi alın. Böylece BT ekibinin hangi görevi üstlendiği, sağlayıcıdan hangi müdahalenin beklenebileceği ve kritik hizmetlerin nasıl korunacağı daha baştan açık olur.

Sık sorulan sorular

1. Yönetilen sunucu kiralama nedir?

Kiralık sunucuya ek olarak sözleşmede tanımlanan izleme, yama, bakım, olay yönetimi ve bazı destek işlerinin sağlayıcıya devredildiği hizmet modelidir. Kapsam sağlayıcıya ve pakete göre değişir.

2. Yönetilen sunucu 7/24 teknik destek sağlar mı?

Otomatik olarak değil. 7/24 alarm takibi, 7/24 talep alımı ve 7/24 mühendis müdahalesi farklı hizmet düzeyleridir. Hangi hizmetin dahil olduğu sözleşmede doğrulanmalıdır.

3. Yönetilen sunucuda yedekleme zorunlu olarak dahil midir?

Hayır. Yedek oluşturma, saklama, geri yükleme testi ve felaket kurtarma farklı kalemler olabilir. Kapsam ile RPO/RTO hedeflerini ayrıca tanımlayın.

4. SQL ve ERP destek hizmeti yönetilen sunucuya dahil mi?

İşletim sistemi ve servis izleme dahil olabilir; ancak özel ERP uygulama hatası, sorgu optimizasyonu veya lisans desteği ayrı uzmanlık gerektirebilir. Ürün ve sürüm bazında sorumluluk belirlenmelidir.

5. SLA'da ilk yanıt ile çözüm süresi aynı mıdır?

Hayır. İlk yanıt talebin alındığını, müdahale teknik çalışmanın başladığını, çözüm ise tanımlı sorunun giderildiğini ifade eder. Ölçüm ve istisnalar sözleşmede açık olmalıdır.

6. Yönetilen sunucu kullanmak otomatik olarak daha güvenli midir?

Garanti değildir. Gerçek güvenlik kullanılan kontroller, yetki yönetimi, izleme, bakım ve kurtarma testlerine bağlıdır. Yönetilen model bunlara yönelik operasyon sorumluluğunu sözleşmeyle düzenleyebilir.

7. Yönetilen sunucu kiralama fiyatı nasıl belirlenir?

CPU/RAM ve depolama gibi kaynaklarla birlikte lisans, alarm ve müdahale kapsamı, yedekleme, güvenlik, ilk kurulum ve ek mühendislik kalemleri maliyeti belirler.

8. Yönetilen sunucu teklifi almak için ne paylaşmalıyım?

Sunucu envanteri, işletim sistemi, iş uygulamaları, kullanıcı sayısı, veri boyutu, izleme ve yedekleme beklentisi ile hedef geçiş tarihini paylaşın. Yönetilen sunucu teklif talebinizi iletin.