Bulut, Sunucu ve Yönetilen BT
Yönetilen BT Hizmeti Seçiminde SLA Nasıl Değerlendirilir
Yönetilen BT sağlayıcılarını seçerken SLA’yı yalnızca bir sözleşme maddesi değil, ölçülebilir operasyon modeli olarak değerlendirin.
Yayınlandı: 4 Ağustos 2026 · Güncellendi: 4 Ağustos 2026

Yönetilen BT hizmetinde SLA neden belirleyicidir
Yönetilen BT hizmeti seçerken SLA, yalnızca sözleşmede yer alan bir madde değil, hizmetin nasıl işleyeceğini tarif eden operasyon çerçevesidir. Hangi hizmetlerin kapsama girdiği, hangi performans beklentilerinin geçerli olduğu ve tarafların hangi durumda sorumluluk alacağı bu çerçevede netleşir. Bu nedenle sağlayıcı seçerken ilk bakılması gereken unsur fiyat değil, SLA’nın ne kadar açık ve uygulanabilir tanımlandığıdır.
SLA belirsiz olduğunda destek talebinin ne zaman alındığı, ne zaman ele alındığı ve ne zaman kapatıldığı gibi temel ayrımlar bile yoruma açık kalır. Yönetilen BT tarafında asıl fark, sorun çıktığında kimin neyi, hangi sırayla ve hangi ölçüte göre yapacağının önceden belirlenmesidir. Bu yaklaşım, hizmeti kişilere değil sürece bağlar ve iş sürekliliği açısından daha sağlıklı bir yapı oluşturur.
SLA’yı değerlendirirken amaç yalnızca bir taahhüdün varlığını görmek değildir. Önemli olan, bu taahhüdün işletmenizin çalışma biçimiyle uyumlu olup olmadığını anlamaktır. Kapsam, önceliklendirme, izleme ve raporlama başlıkları birlikte okunmadığında, tek tek güçlü görünen maddeler bir araya geldiğinde zayıf bir operasyon resmi ortaya çıkabilir. Bu yüzden sözleşmeyi bütün olarak değerlendirmek gerekir.

Öne çıkanlar
SLA değerlendirirken bakılması gereken temel noktalar
Bir yönetilen BT sağlayıcısını karşılaştırırken SLA metninin uzunluğu değil, hangi operasyonel sorulara cevap verdiği önemlidir. İlk aşamada kapsamın net olup olmadığına, hangi hizmetlerin destek dışında bırakıldığına ve olayların nasıl sınıflandırıldığına bakın. Böylece sözleşmenin gerçek hayatta nasıl işleyeceğini daha baştan öngörebilirsiniz. Özellikle destek sonrası süreçlerin tanımı, hizmetin yalnızca kurulum anına değil, işletim sürecine de odaklanıp odaklanmadığını gösterir. İkinci olarak yanıt ve çözüm sürelerinin birbirinden ayrılıp ayrılmadığını kontrol edin. Bir talebin alınması ile sorunun tamamen kapanması aynı şey değildir. Bu ayrım yapılmadığında sağlayıcı sorunu erken alıp geç kapatsa bile SLA kağıt üzerinde sağlanmış görünebilir. Oysa işletme açısından önemli olan, iş akışının ne kadar sürede normale döndüğüdür. Bu nedenle süre tanımlarının birbirine karışmaması gerekir. Üçüncü olarak hizmet saatleri, iletişim kanalları ve eskalasyon yolu açık olmalıdır. Kimin hangi durumda devreye girdiği, hangi kanaldan bildirim yapıldığı ve kritik olaylarda hangi ekibin sorumluluk aldığı net değilse, teknik olarak güçlü bir ekip bile organizasyonel gecikme yaşayabilir. Özellikle uzaktan yönetim ve bulut tabanlı operasyonlarda bu detaylar daha da önem kazanır. Son olarak raporlama ve periyodik gözden geçirme mekanizmasına bakın. SLA’nın sahada çalışıp çalışmadığını anlamanın yolu, düzenli ölçüm sonuçlarını görmekten geçer. Raporlar yalnızca arıza listesinden ibaret olmamalı; tekrar eden sorunları, iyileştirme alanlarını ve sorumluluk paylaşımını da göstermelidir. Böylece sağlayıcı, yalnızca olayı kapatan değil, hizmeti geliştiren bir yapıda olduğunu gösterebilir.
Kapsam net mi?
Hangi sistemlerin, ekiplerin ve olayların kapsama girdiği açık olmalı.
Yanıt ve çözüm ayrı mı?
Talebi görme süresi ile sorunu kapatma süresi farklı ele alınmalı.
Hizmet saatleri yazıyor mu?
Mesai içi ve dışı destek ayrımı operasyonel beklentiyi belirler.
Eskalasyon tanımlı mı?
Kritik olaylarda kimin devreye gireceği önceden yazılmalı.
Raporlama düzenli mi?
SLA yalnızca olay anında değil, periyodik ölçümle anlam kazanır.
Karşılaştırma
Sözleşmede açık tanımlanması gereken başlıklar
Yazılı kapsam aranır. 4 classes?
Varsayıma yer kalmaz. 4 classes?
Tek tip yaklaşım olmaz. 4 classes?
Etki ve aciliyet dikkate alınır. 4 classes?
Proaktif görünürlük gerekir. 4 classes?
Sürpriz kesintiler azalır. 4 classes?
Düzenli ölçüm önemlidir. 4 classes?
Tek seferlik kontrol yeterli değildir. 4 classes?
Uygulama süreci
SLA’yı teknik açıdan nasıl okumalısınız
İyi bir değerlendirme için SLA metnini, hizmet akışını izleyen bir süreç dokümanı gibi okuyun. Önce hangi sistemlerin kapsandığını belirleyin. Ardından olayın nasıl açıldığına, nasıl sınıflandırıldığına ve nasıl kapatıldığına bakın. Bu sırada yanıt ve çözüm tanımlarının birbirine karışmadığından emin olun. Eğer bu adımlar net değilse, sağlayıcı ile gerçekçi bir karşılaştırma yapmak zorlaşır. Yönetilen BT’de asıl değer, akışın ölçülebilir olmasıdır. Sonra izleme kapsamını inceleyin. Hangi bileşenlerin gözlemlendiği, hangi alarmların kritik sayıldığı ve bildirimlerin kime gittiği açık olmalıdır. Sadece sunucu sağlığı değil, bağlantı, uygulama bağımlılıkları ve destek eskalasyonları da görünür olmalıdır. Bu açıdan ağ ve bulut katmanını birlikte ele alan bir yapı, tek başına sunucu yönetiminden daha anlamlı olabilir. Kurumsal ağ ve Wi-Fi altyapısı gibi bileşenler de bu zincirin parçasıdır. Son adımda raporlama ve periyodik gözden geçirme beklentisini kontrol edin. SLA’nın sahada çalışıp çalışmadığını anlamanın yolu, düzenli ölçüm sonuçlarını görmekten geçer. Raporlar sadece arıza listesi olmamalı; tekrar eden sorunları, iyileştirme alanlarını ve sorumluluk paylaşımını da göstermelidir. Bu bölüm, sağlayıcının olayı kapatmakla yetinmeyip hizmeti iyileştirme yaklaşımını da ortaya koyar.
- 01
1. Kapsamı ayırın
Yönetilecek sistemleri, ekipleri ve hizmet dışı alanları listeleyin.
- 02
2. Süre tanımlarını kontrol edin
Yanıt, çözüm, eskalasyon ve bilgilendirme kavramlarını ayrı değerlendirin.
- 03
3. İzleme mantığını inceleyin
Alarm, gözlem ve bilgilendirme zincirinin nasıl kurulduğunu anlayın.
- 04
4. Raporlama sıklığını sorun
Düzenli raporların içeriğini ve paylaşım ritmini teyit edin.
Kontrol listesi
Teklif karşılaştırırken kullanabileceğiniz kontrol listesi
Aynı hizmeti sunuyor görünen iki sağlayıcı, aslında çok farklı operasyon modellerine sahip olabilir. Bu yüzden teklifleri yan yana koyarken yalnızca toplam rakama değil, sözleşme detaylarına da bakın. Aşağıdaki liste, görüşme sırasında eksik kalabilecek başlıkları hızlıca kontrol etmeniz için hazırlanmıştır. Özellikle sunucu yönetimi, bulut geçişi ve teknik destek birlikte sunuluyorsa bu sorular daha da önem kazanır. Kontrol listesindeki her madde, sağlayıcının hizmeti ne kadar tanımlı yönettiğini anlamanızı sağlar. Yanıt aradığınız soru basittir: Bu hizmet, sorun çıktığında ne kadar öngörülebilir davranıyor? Öngörülebilirlik ne kadar yüksekse, iç ekiplerin planlaması ve iş birimlerinin beklentisi o kadar rahat yönetilir. Sözleşmede netlik arttıkça operasyonel sürprizler azalır. İç bağlantılar arasında karar verirken ihtiyaç odaklı ilerlemek en sağlıklı yoldur. Eğer ana problem destek yoğunluğundaysa BT Bakım ve Teknik Destek Hizmetleri sayfasına, altyapı dönüşümü düşünüyorsanız Bulut Altyapı ve Buluta Geçiş Hizmetleri sayfasına bakabilirsiniz. Ağ katmanı da kritikse Kurumsal Ağ ve Wi‑Fi Altyapısı hizmetini incelemek faydalı olur. Böylece SLA’yı yalnızca belge olarak değil, mimari bütünün parçası olarak okursunuz.
- ✓
Kapsam yazıyor mu?
Yönetilen sistemler ve hariç tutulan alanlar açık mı?
- ✓
Yanıt ve çözüm ayrılmış mı?
İki süre tanımı ayrı ayrı tanımlanmış mı? 4 classes?
- ✓
İzleme kapsamı belirtilmiş mi?
Hangi bileşenlerin izlendiği ve bildirim sınırları net mi?
- ✓
Raporlama düzeni tanımlı mı?
Periyodik rapor, toplantı ve iyileştirme döngüsü var mı?
- ✓
Yaptırım mekanizması var mı?
Servis kredileri veya benzeri maddeler açıkça yazılmış mı?
Sonuç: SLA, doğru yönetilen hizmetin temel göstergesidir
Yönetilen BT hizmeti seçerken SLA’yı teknik ekibin diliyle okumak gerekir. Kapsam netliği, yanıt ve çözüm ayrımı, hizmet saatleri, izleme düzeyi, raporlama düzeni ve sorumluluk paylaşımı birlikte değerlendirilmeden sağlıklı karar verilemez. Fiyat, bu resmi tamamlayan bir unsur olabilir; ama tek başına yeterli değildir. Asıl hedef, iş sürekliliğini destekleyen ve büyüdükçe yönetilebilir kalan bir hizmet modelidir.
İyi hazırlanmış bir SLA, sağlayıcı ile işletme arasında ortak bir operasyon dili kurar. Bu dil, arıza anında tartışmayı azaltır; normal zamanda da beklentiyi şeffaflaştırır. Eğer ihtiyaçlarınız sunucu yönetimi, bulut geçişi veya sürekli teknik destek çevresinde şekilleniyorsa, bu başlıkları birbirinden bağımsız değil, aynı hizmet zincirinin parçaları olarak değerlendirin. Böylece seçtiğiniz model, bugünkü ihtiyaçlar kadar yarınki büyümeyi de taşıyabilir.
Bu konuyla ilişkili hizmetleri incelemek için BT Bakım ve Teknik Destek Hizmetleri, Bulut Altyapı ve Buluta Geçiş Hizmetleri ve Felaket Kurtarma ve Yedekleme Çözümleri sayfalarına göz atabilirsiniz. Doğru SLA, yalnızca daha iyi destek değil, daha öngörülebilir bir BT operasyonu demektir. Böyle bir yapı kurulduğunda, yönetilen hizmet gerçekten yönetilebilir hale gelir.
Öne çıkanlar
İlgili hizmetler
SLA değerlendirmesini, yalnızca destek paketi değil, uçtan uca operasyon modeli olarak düşünmek daha doğru sonuç verir. Aşağıdaki hizmetler, bu rehberi tamamlayan pratik başlangıç noktalarıdır. BT operasyonu, destek ve altyapı başlıkları çoğu zaman birlikte çalıştığı için seçim de birlikte yapılmalıdır. Bu sayede sözleşme ile gerçek ihtiyaç arasında daha tutarlı bir bağ kurarsınız. İhtiyacınızın ağırlığına göre teknik destek, bulut geçişi veya yedekleme tarafında ilerleyebilirsiniz. Tek bir hizmete odaklanmak yerine, bağımlılıkları birlikte ele almak çoğu zaman daha doğru bir başlangıç sağlar. Özellikle canlı sistemler, bağlantı katmanı ve veri koruma gereksinimleri olan yapılarda bu yaklaşım daha güvenlidir. Böylece SLA’nın etkisini sadece kağıt üzerinde değil, operasyon içinde de görürsünüz. Aşağıdaki bağlantılar, değerlendirme sürecinde doğrudan bakabileceğiniz sayfalardır. Gereksiniminize göre biri ana odak, diğerleri tamamlayıcı olabilir. Karar verirken önce hangi katmanda riskiniz olduğunu belirlemeniz, sonra uygun hizmeti seçmeniz en sağlıklı yöntemdir. Böylece yönetilen BT hizmeti SLA nedir sorusu, doğrudan satın alma kararına dönüşür. 4 classes?
BT Bakım ve Teknik Destek Hizmetleri
Kurumsal süreklilik ve müdahale süreçlerini SLA ile birlikte ele alır.
Bulut Altyapı ve Buluta Geçiş Hizmetleri
Altyapı dönüşümünde izleme ve yönetim beklentilerini düzenler.
Felaket Kurtarma ve Yedekleme Çözümleri
İş sürekliliği ve veri koruma tarafını tamamlar. 4 classes?
Kurumsal Ağ ve Wi‑Fi Altyapısı
Bağlantı katmanında görünürlük ve yönetim ihtiyacını destekler.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
