Canl\u0131 sistemleri ta\u015f\u0131yaca\u011f\u0131n\u0131z bir tesis se\u00e7ece\u011finiz zaman, i\u015f asl\u0131nda sadece fiyat teklifi toplamakla bitmez. Veri merkezi se\u00e7imi<\/strong>, SLA seviyesinden felaket kurtarma senaryonuza kadar t\u00fcm mimariyi etkiler. Yanl\u0131\u015f karar, saatlerce s\u00fcren kesintiler, veri kayb\u0131 ve uyku ka\u00e7\u0131ran gece bak\u0131m pencereleri demektir. Do\u011fru karar ise \u00f6ng\u00f6r\u00fclebilir uptime<\/strong>, stabil bir network altyap\u0131s\u0131<\/strong> ve \u00f6l\u00e7eklenebilir bir platform anlam\u0131na gelir.<\/p>\n Bir sistem y\u00f6neticisi olarak ilk bakt\u0131\u011f\u0131m \u015fey; tesisin ka\u011f\u0131t \u00fczerindeki \u00f6zelliklerinden \u00e7ok, operasyonel olgunlu\u011fu ve ge\u00e7mi\u015f performans\u0131d\u0131r. Tier seviyesi, enerji altyap\u0131s\u0131, ba\u011flant\u0131 se\u00e7enekleri, izleme sistemleri ve destek ekibinin tecr\u00fcbesi bu resmin \u00f6nemli par\u00e7alar\u0131d\u0131r. Bunlar\u0131 netle\u015ftirmeden imza atmak, \u00fcretim ortam\u0131n\u0131 kumar masas\u0131na koymakla ayn\u0131 \u015fey.<\/p>\n Detaylara girmeden \u00f6nce, hangi i\u015f y\u00fck\u00fcn\u00fc bu veri merkezine ta\u015f\u0131yaca\u011f\u0131n\u0131z\u0131 netle\u015ftirmek gerekir. Y\u00fck tipi, se\u00e7ece\u011finiz yap\u0131y\u0131 do\u011frudan belirler:<\/p>\n \u00d6rne\u011fin, gecikmeye \u00e7ok duyarl\u0131 bir finansal uygulama ile sadece yedek depolayan bir ortam\u0131n gereksinimleri ayn\u0131 de\u011fildir. \u0130lkinde d\u00fc\u015f\u00fck latency, y\u00fcksek uptime<\/strong> ve yedekli network altyap\u0131s\u0131<\/strong> kritik olurken, ikincisinde daha \u00e7ok depolama kapasitesi ve maliyet \u00f6ne \u00e7\u0131kar.<\/p>\n Biz canl\u0131 sistem ta\u015f\u0131rken genellikle \u00f6nce k\u00fc\u00e7\u00fck bir pilot i\u015f y\u00fck\u00fcyle tesisi deneriz: Birka\u00e7 VPS<\/a> veya VDS<\/a> sunucu a\u00e7ar, ger\u00e7ek kullan\u0131c\u0131 trafi\u011fine benzer y\u00fckler alt\u0131nda latency, IO performans\u0131 ve paket kayb\u0131n\u0131 g\u00fcnlerce izleriz. Teklif dok\u00fcman\u0131nda yazan hi\u00e7bir \u015fey bu pratik g\u00f6zlemin yerini tutmaz.<\/p>\n Adres sadece posta i\u00e7in \u00f6nemli de\u011fil. Lokasyon; gecikme s\u00fcreleri, afet riski ve fiziksel eri\u015fim imkan\u0131n\u0131z\u0131 belirler. \u00d6zellikle T\u00fcrkiye i\u00e7i kullan\u0131c\u0131ya hizmet veriyorsan\u0131z, yurtd\u0131\u015f\u0131 bir tesiste bar\u0131nd\u0131r\u0131lan sistemlerin gecikme s\u00fcreleri kullan\u0131c\u0131 deneyimini bozabilir.<\/p>\n De\u011ferlendirirken \u015fu noktalara bak\u0131n:<\/p>\n Pratik bir ad\u0131m olarak, tesise yak\u0131n farkl\u0131 ISP noktalar\u0131ndan gecikme ve rota analizi yap\u0131n. \u0130kinci kritik ba\u015fl\u0131k, tesisin tasar\u0131m standard\u0131. Burada genellikle Uptime Institute s\u0131n\u0131fland\u0131rmalar\u0131 kullan\u0131l\u0131r: Tier I, II, III ve IV. Kurumsal \u00fcretim y\u00fckleri i\u00e7in en az\u0131ndan tier 3 veri merkezi<\/strong> seviyesini hedeflemek mant\u0131kl\u0131 bir e\u015fiktir.<\/p>\n Tier 3 veri merkezi, a\u015fa\u011f\u0131daki anlamlara gelir:<\/p>\n Elbette sadece “biz tier 3 seviyesindeyiz” demeleri yetmez. Uptime Institute sertifikas\u0131, tasar\u0131m ve in\u015faat dok\u00fcmanlar\u0131, elektrik ve mekanik \u015femalar\u0131 isteyin. Sertifika yoksa, en az\u0131ndan tasar\u0131m\u0131n Tier 3 prensiplerine ne kadar uydu\u011funu sorgulay\u0131n. Bir harfin arkas\u0131na saklanan pazarlama s\u00f6ylemi yerine, teknik ger\u00e7ekleri g\u00f6rmek gerekir.<\/p>\n Ka\u011f\u0131t \u00fczerinde yazan uptime<\/strong> y\u00fczdesi, i\u015fin sadece g\u00f6r\u00fcnen y\u00fcz\u00fc. %99,982 ile %99,9 aras\u0131nda bile ay baz\u0131nda ciddi kesinti farklar\u0131 \u00e7\u0131kar. Bir veri merkezi se\u00e7imi yaparken, SLA metnine \u00e7ok detayl\u0131 bakmak \u015fartt\u0131r.<\/p>\n \u00d6zellikle \u015fu sorular\u0131n cevab\u0131n\u0131 isteyin:<\/p>\n Ger\u00e7ek\u00e7i olmak gerekirse; hi\u00e7bir tesis %100 verilebilirlik garantisini pratikte sa\u011flayamaz. Ancak iyi tasarlanm\u0131\u015f bir tier 3 veri merkezi<\/strong>, sa\u011flam bir SLA ile desteklendi\u011finde i\u015f y\u00fcklerinizi uzun vadede g\u00fcvene al\u0131r. Ayr\u0131ca bak\u0131m planlar\u0131n\u0131n \u00f6nceden duyurulma \u015fekli ve s\u0131kl\u0131\u011f\u0131 da kritiktir. Gece 03:00 bak\u0131m penceresinin, sizin uygulaman\u0131z i\u00e7in asl\u0131nda pik saat olmas\u0131 kimsenin i\u015fine yaramaz.<\/p>\n Bir\u00e7ok kesinti senaryosunda, sorun sunucularda de\u011fil a\u011f katman\u0131nda \u00e7\u0131kar. Bu y\u00fczden network altyap\u0131s\u0131<\/strong>, veri merkezi se\u00e7iminin kritik parametrelerinden biridir. Ana omurgan\u0131n tasar\u0131m\u0131, kullan\u0131lan donan\u0131m, yedeklilik seviyesi ve operat\u00f6r \u00e7e\u015fitlili\u011fi mutlaka sorgulanmal\u0131d\u0131r.<\/p>\n Sorulmas\u0131 gereken temel ba\u015fl\u0131klar:<\/p>\n Biz yeni bir tesis test ederken mutlaka uzun s\u00fcreli latency ve paket kayb\u0131 \u00f6l\u00e7eriz. \u00d6rne\u011fin, VPS.TC \u00fczerindeki bir bulut sunucu<\/a> ile farkl\u0131 ISP hatlar\u0131ndan 24-48 saatlik Sunucu odas\u0131nda her \u015fey iyi g\u00f6r\u00fcnebilir, ama g\u00fc\u00e7 hatt\u0131nda tek bir zay\u0131f halka varsa, t\u00fcm yat\u0131r\u0131m\u0131n\u0131z bir anda karanl\u0131kta kal\u0131r. Sa\u011flam bir g\u00fc\u00e7 altyap\u0131s\u0131 olmadan y\u00fcksek uptime<\/strong> hedeflemek ger\u00e7ek\u00e7i de\u011fildir.<\/p>\n \u0130ncelenmesi gereken noktalar:<\/p>\n Ger\u00e7ek bir \u00f6rnek: Baz\u0131 tesisler jenerat\u00f6r testlerini tam y\u00fckte de\u011fil, k\u0131smi y\u00fckte yapar. Bu da ger\u00e7ek bir kesinti an\u0131nda hi\u00e7 denenmemi\u015f bir senaryoyla kar\u015f\u0131la\u015fman\u0131z anlam\u0131na gelir. Test prosed\u00fcrlerini, kay\u0131tlar\u0131n\u0131 ve ar\u0131za ge\u00e7mi\u015flerini talep etmekten \u00e7ekinmeyin.<\/p>\n Siber g\u00fcvenlik kadar, fiziksel g\u00fcvenlik de \u00f6nemlidir. Veri merkezinde yetkisiz biri sunucu odas\u0131na girdiyse, en iyi firewall bile sizi koruyamaz. Bu nedenle eri\u015fim kontrol\u00fc, izleme ve kay\u0131t politikalar\u0131 mutlaka masaya yat\u0131r\u0131lmal\u0131.<\/p>\n Kontrol etmeniz gereken ba\u015fl\u0131klar:<\/p>\n \u00d6zellikle \u00fcretim ortam\u0131n\u0131zda disk s\u00f6k-tak gibi fiziksel m\u00fcdahaleler gerekiyorsa, bu operasyonlar\u0131n nas\u0131l kaydedildi\u011fini sorgulay\u0131n. Her eri\u015fimin loglanmas\u0131, kim taraf\u0131ndan ne zaman ne yap\u0131ld\u0131\u011f\u0131n\u0131n izlenebilir olmas\u0131 gerekir. Aksi halde bir olay ya\u015fand\u0131\u011f\u0131nda geriye d\u00f6n\u00fck inceleme yapmak imkans\u0131z hale gelir.<\/p>\n Bir\u00e7ok ki\u015fi veri merkezi se\u00e7erken sadece tier seviyesi ve fiyatla ilgilenir, ancak tesis i\u00e7i iklimlendirme ve yang\u0131n koruma sistemleri g\u00f6z ard\u0131 edilir. Oysa bu katmandaki zay\u0131fl\u0131klar, donan\u0131m ar\u0131zalar\u0131n\u0131 ve beklenmeyen kesintileri ciddi bi\u00e7imde art\u0131r\u0131r.<\/p>\n Sorulmas\u0131 gereken sorular \u015funlar:<\/p>\n Stabil \u00e7al\u0131\u015fmayan bir iklimlendirme sistemi, \u00f6zellikle disk ve PSU ar\u0131zalar\u0131n\u0131 dramatik bi\u00e7imde art\u0131r\u0131r. Loglar\u0131n\u0131za gereksiz donan\u0131m hatalar\u0131 d\u00fc\u015fmesini istemiyorsan\u0131z, bu katman\u0131 detayl\u0131ca sorgulay\u0131n.<\/p>\n \u00d6zellikle finans, sa\u011fl\u0131k, e-ticaret gibi sekt\u00f6rlerde \u00e7al\u0131\u015f\u0131yorsan\u0131z; sadece teknik \u00f6zellikler de\u011fil, uyumluluk gereksinimleri de \u00f6nemlidir. \u0130yi bir tesis en az\u0131ndan a\u015fa\u011f\u0131daki sertifikasyonlara sahip olmal\u0131d\u0131r:<\/p>\n Sertifikalar\u0131n g\u00fcncelli\u011fini, kapsam\u0131n\u0131 ve denetim periyotlar\u0131n\u0131 mutlaka sorgulay\u0131n. Ayr\u0131ca KVKK ve ilgili di\u011fer yerel mevzuata uyum konusunda nas\u0131l bir hukuki \u00e7er\u00e7eve sunduklar\u0131n\u0131 netle\u015ftirin. Uyumsuz bir veri merkezi ile \u00e7al\u0131\u015fmak, olas\u0131 bir denetimde do\u011frudan sizin ba\u015f\u0131n\u0131z\u0131 a\u011fr\u0131tacakt\u0131r.<\/p>\n Bizim i\u015fte, teknoloji kadar insan fakt\u00f6r\u00fc de belirleyicidir. 03:00’te kritik bir ar\u0131za ya\u015fad\u0131\u011f\u0131n\u0131zda, kar\u015f\u0131n\u0131zda prosed\u00fcr ezberleyen biri mi olacak, yoksa problemi ger\u00e7ekten anlayan bir k\u0131demli m\u00fchendis mi? Bu fark, kesinti s\u00fcresini saatlerden dakikalara indirebilir.<\/p>\n \u015eu ba\u015fl\u0131klar\u0131 netle\u015ftirin:<\/p>\n M\u00fcmk\u00fcnse referans m\u00fc\u015fterilerle konu\u015fun, ger\u00e7ek ar\u0131za senaryolar\u0131nda nas\u0131l bir performans sergilendi\u011fini \u00f6\u011frenin. Teklif toplant\u0131s\u0131ndaki sunumlar\u0131n etkileyicili\u011finden daha \u00e7ok, ger\u00e7ek hayatta ya\u015fanan vakalar size yol g\u00f6sterir.<\/p>\n Hi\u00e7bir veri merkezi sonsuza kadar sorunsuz \u00e7al\u0131\u015fmayacak. \u00d6nemli olan, b\u00fcy\u00fck bir afet veya uzun s\u00fcreli kesinti durumunda i\u015f s\u00fcreklili\u011finizi nas\u0131l koruyaca\u011f\u0131n\u0131z. Bu nedenle felaket kurtarma ve \u00f6l\u00e7eklenebilirlik, veri merkezi se\u00e7iminin son ama en kritik kriterlerinden biridir.<\/p>\n Dikkat edilmesi gerekenler:<\/p>\n Biz genellikle \u00fcretim y\u00fcklerini kademeli olarak ta\u015f\u0131r ve \u00f6ncesinde felaket kurtarma senaryolar\u0131n\u0131 test ortam\u0131nda deneriz. \u00d6rne\u011fin bir k\u0131s\u0131m i\u015fi sanal veri merkezi<\/a> altyap\u0131s\u0131nda \u00e7al\u0131\u015ft\u0131r\u0131p, di\u011fer k\u0131sm\u0131 farkl\u0131 bir b\u00f6lgede tutarak ger\u00e7e\u011fe yak\u0131n tatbikatlar yapar\u0131z. Bu t\u00fcr tatbikatlar, ka\u011f\u0131t \u00fczerindeki planlar\u0131n ne kadar uygulanabilir oldu\u011funu ac\u0131mas\u0131zca ortaya \u00e7\u0131kar\u0131r.<\/p>\n Teknik kriterler kadar, s\u00f6zle\u015fme metni ve operasyonel \u00e7er\u00e7eve de \u00f6nemlidir. Bir\u00e7ok problem teknik de\u011fil, s\u00f6zle\u015fmesel belirsizliklerden \u00e7\u0131kar. Bu y\u00fczden veri merkezi se\u00e7imi s\u00fcrecinde hukuki ekibinizi de erken a\u015famada devreye al\u0131n.<\/p>\n S\u00f6zle\u015fmede \u00f6zellikle dikkat etmeniz gereken noktalar:<\/p>\n Ayr\u0131ca d\u00fczenli denetim ve raporlama mekanizmalar\u0131 talep edin. \u00d6rne\u011fin, ayl\u0131k kesinti raporlar\u0131, kapasite kullan\u0131m raporlar\u0131 ve g\u00fcvenlik olay \u00f6zetleri, tesisin ger\u00e7ek performans\u0131n\u0131 uzun vadede izlemenize yard\u0131mc\u0131 olur.<\/p>\n Bug\u00fcn pek \u00e7ok i\u015fletme, fiziksel sunucu, sanal sunucu ve konteyner altyap\u0131lar\u0131n\u0131 hibrit \u015fekilde kullan\u0131yor. VPS.TC \u00fczerinde \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131z VPS<\/a>, LXC konteyner<\/a>, bulut sunucu<\/a> veya dedicated sunucu<\/a> gibi bile\u015fenler, do\u011fru veri merkezi se\u00e7imi ile birlikte \u00e7ok daha \u00f6ng\u00f6r\u00fclebilir hale gelir.<\/p>\n Stratejinizi olu\u015ftururken \u015fu yakla\u015f\u0131m i\u015finizi kolayla\u015ft\u0131r\u0131r:<\/p>\n B\u00f6ylece tek bir tesise ba\u011f\u0131ml\u0131 kalmadan, hem maliyet hem de dayan\u0131kl\u0131l\u0131k a\u00e7\u0131s\u0131ndan dengeli bir mimari kurabilirsiniz. \u00d6nemli olan, t\u00fcm bu bile\u015fenleri ayn\u0131 teknik ve operasyonel standartlara g\u00f6re y\u00f6netmek.<\/p>\n Teoriyi bir kenara b\u0131rak\u0131p pratik bir yol haritas\u0131 \u00e7izmek gerekirse; \u00f6nce mevcut i\u015f y\u00fcklerinizi envanterleyin, sonra bu yaz\u0131da ge\u00e7en 10 kriteri bir kontrol listesine d\u00f6n\u00fc\u015ft\u00fcr\u00fcn. Her aday tesis i\u00e7in ayn\u0131 sorular\u0131 sorun, ayn\u0131 metrikleri \u00f6l\u00e7\u00fcn ve sonu\u00e7lar\u0131 objektif olarak kar\u015f\u0131la\u015ft\u0131r\u0131n.<\/p>\n Sonraki a\u015famada, k\u00fc\u00e7\u00fck bir pilot ortam kurup ger\u00e7ek kullan\u0131c\u0131 trafi\u011fine benzer bir y\u00fckle deneme yap\u0131n. Gecikme s\u00fcreleri, hata oranlar\u0131, destek yan\u0131t s\u00fcreleri ve beklenmedik davran\u0131\u015flar\u0131 birka\u00e7 hafta boyunca izleyin. K\u00e2\u011f\u0131t \u00fczerindeki teklif ile sahadaki performans\u0131n uyumlu olup olmad\u0131\u011f\u0131n\u0131 bu sayede g\u00f6rebilirsiniz.<\/p>\n Son olarak, felaket kurtarma senaryolar\u0131n\u0131z\u0131 g\u00fcncelleyin ve se\u00e7ti\u011finiz tesisle birlikte u\u00e7tan uca test edin. E\u011fer her senaryoda kabul edilebilir bir kesinti s\u00fcresine inebiliyorsan\u0131z, do\u011fru yolda oldu\u011funuz s\u00f6ylenebilir. Bu yakla\u015f\u0131m\u0131 izledi\u011finizde, veri merkezi se\u00e7imi<\/strong> sadece “en ucuz teklif” meselesi olmaktan \u00e7\u0131k\u0131p, i\u015f s\u00fcreklili\u011finizi uzun y\u0131llar ta\u015f\u0131yacak stratejik bir karara d\u00f6n\u00fc\u015f\u00fcr.<\/p>\n \u0130lk ad\u0131m, hangi i\u015f y\u00fck\u00fcn\u00fc bu tesise ta\u015f\u0131yaca\u011f\u0131n\u0131z\u0131 netle\u015ftirmektir. Uygulaman\u0131n gecikme hassasiyeti, d\u00fczenleyici gereksinimleri ve s\u00fcreklilik ihtiyac\u0131 belirlenmeden do\u011fru veri merkezi se\u00e7imi yapmak m\u00fcmk\u00fcn de\u011fildir. Bu analiz sonras\u0131nda lokasyon, tier seviyesi, uptime hedefi ve network altyap\u0131s\u0131 gibi teknik ba\u015fl\u0131klar\u0131 de\u011ferlendirmeye ba\u015flamal\u0131s\u0131n\u0131z.<\/p>\n<\/div>\n \u00c7o\u011fu kurumsal i\u015f y\u00fck\u00fc i\u00e7in tier 3 veri merkezi seviyesi pratikte yeterli kabul edilir; \u00e7\u00fcnk\u00fc bak\u0131m s\u0131ras\u0131nda bile hizmeti kesintiye u\u011fratmadan \u00e7al\u0131\u015facak \u015fekilde tasarlan\u0131r. Ancak \u00e7ok kritik finansal sistemler, savunma sanayii veya s\u0131f\u0131ra yak\u0131n kesinti tolerans\u0131 olan uygulamalarda, ek olarak co\u011frafi yedeklilik, yedek veri merkezi ve detayl\u0131 felaket kurtarma planlar\u0131yla bu altyap\u0131n\u0131n desteklenmesi gerekir.<\/p>\n<\/div>\n Uptime de\u011feri, hizmetin belirli bir periyotta ne kadar s\u00fcre eri\u015filebilir kald\u0131\u011f\u0131n\u0131 ifade eden teknik bir metriktir. SLA ise bu uptime hedefine ek olarak hangi ko\u015fullarda nas\u0131l \u00f6l\u00e7\u00fclece\u011fini, planl\u0131 bak\u0131mlar\u0131n nas\u0131l ele al\u0131naca\u011f\u0131n\u0131, hedefler tutmazsa hangi kredi veya tazmin mekanizmas\u0131n\u0131n devreye girece\u011fini tan\u0131mlayan s\u00f6zle\u015fmesel \u00e7er\u00e7evedir. Bu nedenle veri merkezi se\u00e7imi s\u0131ras\u0131nda sadece uptime y\u00fczdesine de\u011fil, tam SLA metnine bakmak gerekir.<\/p>\n<\/div>\n Zay\u0131f tasarlanm\u0131\u015f bir network altyap\u0131s\u0131, y\u00fcksek gecikme, jitter, paket kayb\u0131 ve s\u0131k ya\u015fanan y\u00f6nlendirme problemleri olarak kar\u015f\u0131n\u0131za \u00e7\u0131kar. Uygulamalar\u0131n\u0131z ka\u011f\u0131t \u00fczerinde ayakta olsa bile kullan\u0131c\u0131lar yava\u015fl\u0131k, kopma ve zaman a\u015f\u0131m\u0131 \u015fikayetleri ya\u015far. Ayr\u0131ca tek operat\u00f6re ba\u011f\u0131ml\u0131 yap\u0131, hat ar\u0131zalar\u0131nda uzun s\u00fcreli kesintilere yol a\u00e7abilir. Bu y\u00fczden \u00e7oklu operat\u00f6r, yedekli router ve switch mimarisi ile d\u00fczenli latency ve paket kayb\u0131 \u00f6l\u00e7\u00fcmleri kritik \u00f6nemdedir.<\/p>\n<\/div>\n<\/div>\n\u0130htiya\u00e7 analizi: Hangi y\u00fck\u00fc nereye koyuyorsunuz?<\/h2>\n
\n
Veri merkezi se\u00e7imi i\u00e7in 10 kritik kriter<\/h2>\n
1. Lokasyon, gecikme ve afet riski<\/h3>\n
\n
mtr<\/code> veya benzeri ara\u00e7larla rotan\u0131n ka\u00e7 hop \u00fczerinden ge\u00e7ti\u011fini, nerelerde jitter olu\u015ftu\u011funu g\u00f6r\u00fcn. Ka\u011f\u0131t \u00fczerinde iyi g\u00f6r\u00fcnen bir lokasyon, pratikte sorunlu bir g\u00fczergaha sahip olabilir.<\/p>\n2. Tier seviyesi ve tasar\u0131m standartlar\u0131<\/h3>\n
\n
3. Uptime, SLA ve bak\u0131m pencereleri<\/h3>\n
\n
4. Network altyap\u0131s\u0131 ve ba\u011flant\u0131 \u00e7e\u015fitlili\u011fi<\/h3>\n
\n
ping<\/code> ve mtr<\/code> sonu\u00e7lar\u0131n\u0131 toplamak, a\u011f kalitesi hakk\u0131nda ger\u00e7e\u011fe \u00e7ok daha yak\u0131n bir fikir verir.<\/p>\n5. G\u00fc\u00e7 altyap\u0131s\u0131, jenerat\u00f6r ve enerji s\u00fcreklili\u011fi<\/h3>\n
\n
6. Fiziksel g\u00fcvenlik ve eri\u015fim kontrolleri<\/h3>\n
\n
7. Yang\u0131n alg\u0131lama, iklimlendirme ve ortam izleme<\/h3>\n
\n
8. Sertifikasyonlar, mevzuat ve uyumluluk<\/h3>\n
\n
9. Operasyon ekibi, s\u00fcre\u00e7ler ve destek kalitesi<\/h3>\n
\n
10. Felaket kurtarma, yedek veri merkezi ve \u00f6l\u00e7eklenebilirlik<\/h3>\n
\n
SLA, s\u00f6zle\u015fme ve denetim haklar\u0131n\u0131 netle\u015ftirmek<\/h2>\n
\n
VPS.TC altyap\u0131s\u0131yla uyumlu veri merkezi stratejisi<\/h2>\n
\n
Do\u011fru veri merkezi karar\u0131n\u0131 h\u0131zland\u0131rmak i\u00e7in sonraki ad\u0131mlar<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
Veri merkezi se\u00e7imi yaparken ilk dikkat edilmesi gereken kriter nedir?<\/h3>\n
Tier 3 veri merkezi her senaryo i\u00e7in yeterli midir?<\/h3>\n
Uptime de\u011feri ile SLA aras\u0131ndaki fark nedir?<\/h3>\n
Network altyap\u0131s\u0131 g\u00fc\u00e7l\u00fc olmayan bir veri merkezinde ne t\u00fcr sorunlar ya\u015fan\u0131r?<\/h3>\n