Veri Merkezi Seçerken Nelere Bakılmalı? 12 Kritik Kriter

Veri merkezi seçimi, yalnız sunucunun hangi şehirde bulunduğunu veya aylık kabin bedelini karşılaştırmak değildir. ERP, SQL Server, Active Directory, dosya sunucuları ya da e-ticaret sistemleri çalıştıran kurumlar için elektrik sürekliliği, soğutma, ağ bağlantıları, fiziksel güvenlik, kurtarma planı ve destek sorumluluğu birlikte değerlendirilmelidir. İyi bir teklifin amacı en fazla teknik terimi sıralamak değil, şirketin hangi olayda nasıl çalışmaya devam edeceğini anlaşılır biçimde açıklamaktır.

Kısa cevap: Veri merkezi seçerken 12 kriteri inceleyin: konum ve riskler; Tier/sertifika kapsamı; elektrik ve jeneratör; soğutma; fiziksel güvenlik; operatör ve ağ çeşitliliği; sunucu performansı; yedekleme ve felaket kurtarma; operasyon ekibi; SLA; ölçeklenebilirlik; toplam maliyet ve çıkış. Sağlayıcının yalnız beyanını değil, uygun olduğu ölçüde güncel belge, topoloji, prosedür ve test kanıtını isteyin.

Bu rehber Türkiye'deki BT müdürleri, CTO'lar, sistem yöneticileri ve satın alma ekipleri için hazırlandı. Bir veri merkezinin belirli bir sertifikaya veya kesintisizlik oranına sahip olduğunu iddia etmiyoruz. Anlatılan kriterler teklif öncesi denetim soruları olup her tesis ve hizmet için ayrıca doğrulanmalıdır. Mevcut veri merkezi hizmetlerimizi incelerken de bu kontrol listesini kullanabilirsiniz.

1. Konum, ulaşılabilirlik ve bölgesel riskleri değerlendirin

Veri merkezinin coğrafi konumu, şirketinizin ihtiyaç duyduğu gecikme kadar fiziksel müdahale süresini ve olağanüstü durum planını etkiler. Ofisinize yakın bir tesis cihaz değişiminde yararlı olabilir; ancak şirketin tüm sistemleriyle aynı bölgesel riski paylaşan konum, felaket kurtarma açısından her zaman ideal olmayabilir.

Deprem, taşkın, çevresel tehlikeler, ulaşım kısıtları ve enerji altyapısı gibi riskleri tesis bazında sorgulayın. Sadece şehir adından güvenli veya güvensiz sonucu çıkarmayın. Kritik hizmetlerde birincil lokasyonun yanında başka bir fiziksel bölgede kurtarma seçeneği düşünün.

Verinin Türkiye'de tutulması gibi sözleşmesel veya düzenleyici gereksinimleri de tasarıma dahil edin. Fiziksel konum, tek başına KVKK'ya veya sektörel düzenlemelere uyum kanıtı değildir; veri işleme rolleri, erişim, sözleşmeler ve teknik kontroller ayrıca değerlendirilmelidir.

2. Tier III, Tier IV ve TIA-942 ifadelerini doğru okuyun

“Tier III standartlarında” ifadesi ile resmî Tier Certification belgesi aynı şey değildir. Uptime Institute'un Tier Certification açıklamasına göre değerlendirme; tasarım dokümanları, inşa edilmiş tesis ve operasyonel sürdürülebilirlik gibi ayrı aşamalar içerebilir. Bu yüzden yalnız “Tier III” yazan bir tanıtım sayfasına dayanmayın; belgenin düzenleyicisini, kapsamını ve tesise ait olup olmadığını doğrulayın.

Tier III sınıfının önemli özelliği, planlı bakım sırasında ilgili kapasite bileşenleri ve dağıtım yollarının hizmeti kesmeden bakıma alınabilmesidir. Bu, hiçbir zaman arıza yaşanmayacağı anlamına gelmez. Tier IV ise farklı bir hata toleransı seviyesini tarif eder; hangisinin gerekli olduğu iş sürekliliği hedeflerine bağlıdır.

TIA-942, farklı bir standart ve derecelendirme çerçevesidir. TIA'nın resmî derecelendirme sayfasında Rated-1 ile Rated-4 düzeyleri ve ayrı sertifikasyon kapsamları açıklanır. Bir sağlayıcının TIA-942 derecesini Uptime Institute Tier sertifikasıyla aynı belgeymiş gibi göstermemesi gerekir. Sertifikayı seçim sürecinin başlangıcı olarak kullanın; iş yükü, operasyon ve SLA incelemesinin yerine koymayın.

3. Elektrik beslemesi, UPS ve jeneratör mimarisini sorun

Kesintisiz hizmet iddiasının temelinde güç altyapısı bulunur. Şebeke girişleri, UPS kapasitesi, batarya grupları, jeneratör, yakıt yönetimi ve dağıtım yollarının her biri sorgulanmalıdır. “Jeneratör var” ifadesi, uzun süreli bir enerji olayında sürdürülebilir çalışmanın tek başına kanıtı değildir.

Kritik sistemlerde A/B güç beslemesi teklif ediliyorsa iki yolun gerçekten bağımsız olup olmadığını öğrenin. İki priz bulunması, bunların aynı dağıtım panosunda veya aynı tek hata noktasında birleşmediğini göstermez. Çift güç kaynağı olan donanımların doğru bağlandığı ayrıca kontrol edilmelidir.

Planlı bakım sırasında güç yolunun nasıl korunacağı, yük testi ve jeneratör bakım kayıtları ile kapasite artırma prosedürü önemli kanıtlardır. Colocation senaryosunda ayrılan kW kapasitesi, ölçüm ve aşım şartları sözleşmede açıkça tanımlanmalıdır.

4. Soğutma, sıcaklık izleme ve kapasiteyi inceleyin

Sunucu kabinleri güç çekerken ısı üretir. Soğutma tasarımının yalnız ortam sıcaklığını değil, yoğun kabinlerdeki sıcak noktaları, hava akışını ve tek bileşen arızası durumunu da yönetmesi gerekir. Bu nedenle “klima yedekli” ifadesinden daha ayrıntılı bir teknik açıklama isteyin.

Soğuk ve sıcak koridor yerleşimi, sensör noktaları, bakım senaryoları ve kabin başına izin verilen yük kapasitesi sorgulanabilir. Ağır işlemci ve depolama yoğunluğu olan sistemler, başlangıçta boş görünen bir kabinde sonradan soğutma sınırına takılabilir.

Soğutma altyapısına ilişkin kapasite artırma planını, alarm eşiklerini ve müdahale sürecini yazılı isteyin. Enerji verimliliği göstergeleri yararlıdır; ancak düşük bir enerji tüketimi oranı tek başına daha yüksek operasyonel dayanıklılık anlamına gelmez. Tesisin performansı, korumaya çalıştığınız iş yüküyle birlikte değerlendirilmelidir.

5. Fiziksel güvenliği ve ziyaret prosedürlerini doğrulayın

Veri merkezinde ağ güvenliği kadar fiziksel erişim kontrolü de önemlidir. Ziyaretçi kayıtları, yetkilendirme, kamera kayıtlarının saklanması, personel erişimi, kabin kilitleri ve kritik alanlara kontrollü giriş prosedürleri sorulmalıdır. Belirli bir biyometrik yöntem kullanılmasa da erişimlerin kayıtlı ve denetlenebilir olması temel beklentidir.

Sunucu kabinleri size aitse cihaz seri numarası ve envanter doğrulamasıyla, kimlerin ne zaman kabine erişebileceğini belirleyin. Bir üçüncü tarafın kablo çekme veya parça değiştirme işlemi yapması için önce onay verilmesi, değişiklik yönetiminin parçası olmalıdır.

Yangın algılama, uygun söndürme yaklaşımı ve tahliye prosedürü de fiziksel risk yönetimine dahildir. “ISO 27001 sertifikalı” iddiası duyarsanız belgenin gerçek tüzel kişi, tesis ve hizmet kapsamını doğrulayın; sertifika, bütün uygulama ve ağ katmanlarının otomatik olarak güvenli olduğu anlamına gelmez.

6. İnternet operatörleri, fiziksel hat yolları ve gecikme

Birden fazla internet operatörü bulunması faydalı olabilir, fakat tüm operatörlerin kabloları aynı fiziksel güzergâhtan giriyorsa risk beklenenden yüksek kalabilir. Operatör çeşitliliğiyle birlikte fiziksel güzergâh çeşitliliği, farklı cihazlardan bağlantı ve alternatif yönlendirme seçeneklerini inceleyin.

ERP ve uzak masaüstü kullanımında yalnız “1 Gbps port” bilgisi yeterli değildir. Kullanıcıların bağlandığı şehirlerden gecikme, paket kaybı ve yoğun saat performansını mümkün olduğunca gerçek ölçümlerle değerlendirin. Şirketin internet çıkışı kötü durumdaysa tek başına veri merkezi değiştirmek uçtan uca sorunu çözmeyebilir.

Özel IP, VPN, cross-connect, özel hat, DDoS koruma ve trafik aşım koşullarını teklif kapsamına yazın. Başka bir operatöre geçişin nasıl yapılacağı ve geçiş sırasında kimin müdahale edeceği, kritik sistemler için belirleyici olabilir.

7. Sunucu donanımını ve sanallaştırma katmanını ayırın

Veri merkezinin güçlü olması, kiraladığınız sanal makinenin uygulamanız için doğru boyutlandırıldığı anlamına gelmez. Fiziksel sunucu veya VPS seçiminde CPU, RAM, disk gecikmesi, yedeklilik ve kaynak paylaşımı politikası ayrı teknik karardır. İhtiyacınıza göre dedicated sunucu kiralama ile VPS/bulut sunucu seçeneklerini değerlendirin.

SQL Server ve ERP iş yüklerinde depolama gecikmesi, yoğun eş zamanlı işlemler ve bakım sürecindeki davranış, katalogdaki işlemci sayısından daha belirleyici olabilir. Sanal makine başka bir fiziksel hosta taşınabiliyor diye uygulama tutarlılığı, lisans uyumluluğu ve ağ bağlantıları otomatik garanti edilmez.

Teklifte fiziksel host arızasında ne olacağını, yedek kapasitenin gerçekten ayrılıp ayrılmadığını ve planlı bakımda uygulamanın nasıl davranacağını açıklatın. Altyapı erişilebilirliği ile uygulamanın çalışır durumda olması aynı hizmet seviyesi değildir.

8. Yedekleme ile ikinci lokasyonda felaket kurtarmayı ayırt edin

Yedekleme, yanlışlıkla silinen veriyi geri getirmeye yardımcı olabilir. Felaket kurtarma ise daha büyük bir olayda uygulamayı tekrar hizmete alabilmek için alternatif kapasite, ağ, kimlik, veri ve iş süreçlerinin birlikte planlanmasını gerektirir. Aynı tesisteki ikinci diski ayrı felaket kurtarma lokasyonu saymayın.

Kurum içi iş etki analiziyle RPO (kabul edilebilir veri kaybı hedefi) ve RTO (hedef hizmete dönüş süresi) belirlenmelidir. Sağlayıcıdan hedeflere hangi mimariyle yaklaşacağını, geri yüklemeyi nasıl sınayacağını ve hizmet kesintisinde karar yetkisinin kimde olacağını isteyin.

Yedekleme ve felaket kurtarma hizmetleri için ayrı kopya, saklama süresi, uygulama tutarlı yedek, fidye yazılımına karşı izolasyon ve gerçek tatbikat kapsamını karşılaştırın. Her gün yedek alınıyor olması, başarılmış bir geri yükleme testi yapıldığı anlamına gelmez.

9. Yerinde müdahale, remote hands ve 7/24 operasyon

Uzaktan yönetim her fiziksel arızayı çözemez. Kablo kontrolü, disk değişimi, cihaz etiketleme ve konsol erişimi gibi işlemler için yerinde personel gerekebilir. Bu hizmetlerin bazısı “remote hands” adıyla sunulur; kaç dakikada başlayacağı, hangi işlemleri kapsadığı ve ücretlendirmesi sağlayıcıya göre değişir.

Operasyon ekiplerinin yalnız telefon açan bir çağrı merkezi mi, yoksa tesiste müdahale edebilecek yetkili teknik personel mi olduğunu öğrenin. Mesai dışı arızalarda uzman çağırma süreci, yedek parça sorumlusu ve eskalasyon zinciri yazılı olmalıdır.

Yönetilen sunucu hizmeti tercih ediliyorsa fiziksel müdahale ile işletim sistemi, ağ ve uygulama desteğini ayrı kalemler olarak değerlendirin. “7/24 destek” ifadesinin kapsamı, bir olayın çözümü için en kritik sorulardan biridir.

10. SLA ve bakım penceresinde nelerin dahil olduğunu okuyun

SLA, yalnız bir yüzde veya “kesintisiz hizmet” sloganı değildir. Ölçümün hangi servis noktası için yapıldığı, planlı bakımın nasıl sayıldığı, istisnalar, olay bildirimi, müdahale sorumluluğu ve hizmet kredisi gibi konuların sözleşmede açık olması gerekir.

Elektrik ve ağ için verilen hizmet seviyesi, müşterinin işletim sistemi veya ERP yazılımının kesintisiz çalışacağını otomatik garanti etmez. Fiziksel altyapı, sanallaştırma ve uygulama hizmetini farklı taraflar yönetiyorsa sorumluluk matrisi hazırlanmalıdır.

Bakım takviminin nasıl bildirildiğini, bakımda hangi bileşenlerin etkilenebileceğini ve planlanan kesintinin kimin onayına tabi olduğunu kontrol edin. Uptime Institute'un Tier sınıflandırması ve sağlayıcınızın sözleşmesi farklı belgeleridir; bir sertifikadan otomatik olarak belirli bir hizmet kredisi veya SLA sonucu çıkarılamaz.

11. Büyüme, ilave kabin, güç ve IP kapasitesini planlayın

Bugün bir kabine ya da iki sanal sunucuya ihtiyacınız olabilir; gelecek yıl ek depolama, firewall, daha fazla bant genişliği veya başka bir fiziksel host gerekebilir. Başlangıçta boş kapasitenin varlığı, bunun ileride aynı maliyet ve takvimle sağlanacağı anlamına gelmez.

Colocation planında kabin başına güç tahsisi, ek U alanı, kablolama, yeni operatör bağlantısı ve remote hands ücretlerini değerlendirin. Kendi sunucunuzu barındıracaksanız colocation/kabin kiralama kapsamında cihaz ölçüleri, PSU tipi, port ihtiyaçları ve bakım erişimi belirlenmelidir.

Ek kapasitenin sağlanma süresi, sözleşme süresi, fiyat değişikliği ve büyütme sırasında oluşabilecek kesinti önceden konuşulmalıdır. Donanımı kolayca büyütmek, yalnız maliyet meselesi değil; planlama ve iş sürekliliği konusudur.

12. Toplam maliyet, sözleşme ve hizmetten çıkış senaryosu

Teklifleri yalnız aylık kabin veya sunucu bedeliyle karşılaştırmak eksik olur. Elektrik, bant genişliği, cross-connect, ek IP, güvenlik, yedekleme, yerinde destek, lisans, taşıma ve olası veri çıkış ücretlerini aynı tabloda gösterin. Yalnız dahil kalemleri değil, dahil olmayanları da yazılı isteyin.

Sözleşme bitişinde verinin nasıl teslim edileceği, fiziksel cihazların nasıl çıkarılacağı, IP ve ağ taşıması için süre tanınıp tanınmadığı, yedeklerin silinme prosedürü ve hizmet sonlandırma sorumlusu netleşmelidir. Yeni veri merkezine geçişte oluşacak kesinti ve işçilik, ilk teklifin görünmeyen maliyeti olabilir.

Satın almada birim fiyat yerine uygulamanın destek kapsamını da içeren toplam sahip olma maliyetini karşılaştırın. Aynı teknik gereksinim belgesini tüm adaylara gönderin; yalnız en düşük bedeli değil, test edilebilir süreklilik ve operasyon kapasitesini değerlendirin.

Veri merkezi tekliflerini karşılaştırmak için karar matrisi

Aşağıdaki tablo, teknik görüşmede kullanılacak kısa bir kontrol aracıdır. Puanlar evrensel bir sertifikasyon veya gerçek sağlayıcı derecelendirmesi değildir. Önce kuruluşunuz için vazgeçilmez koşulları tanımlayın; bunlardan birini karşılamayan tesisi salt toplam puanla seçmeyin.

Örneğin ERP ve SQL Server çalıştıran bir şirket, ağ gecikmesi ve uygulama tutarlı yedeklemeyi vazgeçilmez kabul edebilir. Şirketin kendi donanımını tesise koyduğu colocation modelinde ise güç kapasitesi, yerinde müdahale ve parça sorumluluğu daha ön plana çıkabilir. Her iki durumda da ölçülebilir kabul kriteri yazılmalıdır.

Sunucu kiralama ve colocation için önerilen ön keşif

İlk görüşmede şirketinizin uygulama listesini, kullanıcı ve şube sayısını, bugünkü CPU/RAM/disk kullanımını ve kritik çalışma saatlerini paylaşın. Ardından bağlantı modeli, verinin nerede tutulması gerektiği, yedek saklama süresi, RPO/RTO hedefi ve olay anında kimlerin karar vereceğini belirleyin.

Tesis gezisi mümkünse enerji dağıtımı, kabin yerleşimi, ağ girişleri ve yetkili ziyaret süreci için belge veya yerinde açıklama isteyin. Gizli güvenlik ayrıntılarını herkese açık biçimde ifşa etmek gerekmez; buna rağmen bağımsız denetim, sözleşmesel teyit veya kontrollü teknik inceleme ile yeterli güven sağlanabilir.

Netsun Bilişim ile ihtiyaç bazlı çalışma başlatmak için veri merkezi ve sunucu barındırma teklifi alın. Böylece teknik ekibiniz, tek başına bir sertifika veya fiyat etiketi yerine gereksinime uygun altyapıyı değerlendirebilir.

Sık sorulan sorular

1. Veri merkezi seçerken ilk bakılması gereken özellik nedir?

Önce iş yükünüzün kesinti ve veri kaybı toleransını belirleyin. Ardından elektrik, ağ, soğutma, güvenlik, müdahale ve felaket kurtarma kapsamlarını bu hedeflerle karşılaştırın. Tek bir teknik özellik tüm işletmeler için en önemli kriter değildir.

2. Tier III veri merkezi hiç kesilmez mi?

Hayır. Tier III, altyapının planlı bakım sırasında çalışmayı sürdürebilmesine ilişkin bir topoloji seviyesidir; insan hatası veya bütün arızalara karşı sıfır kesinti garantisi değildir. Resmî belge türü ve kapsamı ayrıca doğrulanmalıdır.

3. Tier III ile TIA-942 Rated-3 aynı sertifika mı?

Hayır. Uptime Institute'un Tier sistemi ve TIA'nın TIA-942 derecelendirmesi farklı standart ve sertifika programlarıdır. Bir sağlayıcının hangi belgeye sahip olduğu, belgenin kapsamı ve geçerliliği ayrı ayrı incelenmelidir.

4. İki internet operatörü kullanılması yeterli midir?

Her zaman değil. Operatörlerin fiziksel kablo güzergâhları, tesis girişleri, yönlendirme cihazları ve diğer ortak hata noktaları da değerlendirilmeli; kritik uygulamalar için uçtan uca bağlantı testleri yapılmalıdır.

5. Veriler Türkiye'de bulunuyorsa KVKK uyumu tamam mıdır?

Hayır. Veri yerleşimi önemli olabilir ancak tek başına bütün hukuki ve teknik yükümlülükleri karşılamaz. Veri işleme rolleri, erişim güvenliği, sözleşmeler ve güncel mevzuat ayrıca incelenmelidir.

6. Colocation ile dedicated sunucu kiralama arasında veri merkezi açısından fark nedir?

Colocation'da kuruma ait donanım veri merkezinde barındırılır; fiziksel cihaz ve parça sorumlulukları sözleşmeye bağlı olarak müşteride kalabilir. Dedicated modelde fiziksel sunucu kiralanır. İkisinde de güç, ağ, müdahale ve yedekleme kapsamı ayrı değerlendirilmelidir.

7. Veri merkezi tekliflerinde en sık atlanan maliyetler hangileridir?

Ayrı güç kapasitesi, ek bant genişliği, cross-connect, yerinde müdahale, farklı lokasyonda yedekleme, IP, cihaz taşıma, lisans ve çıkış bedelleri atlanabilir. Tüm adaylardan aynı şartnameye göre kapsamlı teklif isteyin.

Resmî teknik kaynaklar ve sonuç

Bu kontrol listesindeki sertifikasyon açıklamaları, Uptime Institute Tier Certification, Uptime Institute Tier sınıflandırması ve TIA-942 sertifikasyon dereceleri üzerinden kontrol edilmiştir. Standart sürümü, sertifika kapsamı ve ilgili tesisin belge durumu seçilecek sağlayıcı özelinde yeniden incelenmelidir.

Sonuç: Doğru veri merkezi; teknik yedekliliği, güvenliği, ağ kalitesini, kurtarma yaklaşımını ve sözleşmesini işinizin gereksinimlerine uygun şekilde kanıtlayabilen tesistir. Karşılaştırmayı yalnız maliyet veya pazarlama terimleri üzerinden değil, ölçülebilir kabul kriterleriyle yapın. Kurumsal veri merkezi ve sunucu kiralama teklifini talep edin.