Bulut, Sunucu ve Yönetilen BT
KOBİ İçin Fiziksel, Bulut ve Hibrit Sunucu Seçimi
Sunucu seçimini yalnızca donanım fiyatına göre yapmayın. Fiziksel, bulut ve hibrit seçenekleri iş yükü, erişilebilirlik, güvenlik ve toplam işletim maliyetiyle birlikte değerlendirin.
Sunucu seçimi işletmenin çalışma biçimiyle başlar
KOBİ için sunucu seçimi, yalnızca işlemci, bellek ve disk kapasitesi belirlemek değildir. Asıl karar; uygulamaların nerede çalışacağı, çalışanların bunlara nasıl erişeceği ve bir sorun yaşandığında işlerin nasıl sürdürüleceğidir. Muhasebe yazılımını yalnızca ofiste kullanan bir işletmeyle farklı şehirlerden sipariş alan bir e-ticaret şirketinin ihtiyaçları aynı olmayabilir.
Fiziksel sunucu, bulut ve hibrit mimari arasında herkes için geçerli tek bir doğru yoktur. Düzenli iş yükleri fiziksel altyapıyı, değişken talep bulutu öne çıkarabilir. Bazı uygulamaların yerinde kalması gerektiğinde hibrit yapı değerlendirilebilir. Her seçenekte bakım, güvenlik ve destek sorumlulukları ayrıca tanımlanmalıdır. Mevcut sistemi korumak da ölçümler bunu destekliyorsa geçerli bir tercihtir.
Önce ihtiyaçları belirleyin, ardından aynı hizmet kapsamına sahip teklifleri karşılaştırın. Böylece düşük görünen başlangıç bedelinin lisans, yedekleme veya yönetim giderleriyle büyümesini gözden kaçırmazsınız. Hedef en güçlü sunucuyu değil, işinizi sürdürülebilir koşullarda çalıştıracak altyapıyı seçmektir. Teknik özellikler bu hedefin ardından gelmelidir; kararın başlangıç noktası olmamalıdır.
Öne çıkanlar
Teklif istemeden önce iş yükünüzü tanımlayın
Kapasite planını yalnızca çalışan sayısına dayandırmayın. Aynı kullanıcı sayısına sahip işletmelerin veritabanı, dosya paylaşımı ve raporlama yükleri farklı olabilir. Yoğun dönemlerdeki kaynak tüketimini kullanıcıların yaşadığı gecikmelerle birlikte inceleyin. Performans sorununun sunucudan mı, ağdan mı yoksa uygulamadan mı kaynaklandığını doğrulayın; kapasite artırmak her sorunu çözmez. Envantere planlanan yeni uygulamaları da ekleyin. Hangi işlerin bekleyebileceğini, hangilerinin aksamasının operasyonu durduracağını ayırın. Belirsiz bir “sistem yavaş” ifadesi yerine, gecikmenin hangi işlemde ve ne zaman yaşandığını kaydedin. Bu bilgiler, tekliflerin gerçek ihtiyaçlara dayanmasını kolaylaştırır. Ölçümlere büyüme için makul bir kapasite payı eklemek de önemlidir. Uygulamaların birbirine bağımlılığını da gösterin. Bir yazılımın taşınması lisans değişikliği veya üretici onayı gerektiriyorsa bunu teklif aşamasında açıklığa kavuşturun. Sonradan ortaya çıkan uyumluluk sorunları, uygun görünen bir seçeneği geçersiz kılabilir. Büyüme beklentisini kesinleşmiş ihtiyaçlarla olası planları ayırarak yazın; böylece gereksiz kapasite alımıyla kaynak yetersizliği riskini birlikte değerlendirebilirsiniz.
Uygulama envanteri
ERP, muhasebe, dosya paylaşımı ve veritabanlarını; sürüm, lisans ve üretici destek koşullarıyla listeleyin.
Kaynak tüketimi
İşlemci, bellek, disk gecikmesi, depolama büyümesi ve ağ kullanımını değerlendirin.
Erişim ihtiyacı
Ofis, şube ve uzaktan çalışanların bağlantı koşullarını belirleyin.
Karşılaştırma
Fiziksel sunucu ile bulutun temel farkları
Fiziksel: Ek bileşen veya yeni sunucu gerekebilir.
Bulut: Kaynaklar hizmetin sınırları içinde değiştirilebilir.
Fiziksel: Donanım bakımı ve ortam koşulları sözleşmeye göre işletmede kalabilir.
Bulut: İşletim sistemi, erişim ve uygulama yönetiminin kapsamı ayrıca belirlenir.
Uygulama süreci
Erişilebilirliği sunucu türünden bağımsız planlayın
Bulutta bulunmak tek başına kesintisiz çalışma anlamına gelmez; güçlü bir fiziksel sunucu da tek başına iş sürekliliği sağlamaz. İnternet, enerji, uygulama bileşenleri ve kullanıcı erişimi birlikte ele alınmalıdır. Yedekli altyapı, yedekleme ve felaket kurtarma farklı sorunlara yanıt verir; birbirlerinin yerine geçmez. Ofis bağlantısının kesilmesi de buluttaki uygulamalara erişimi etkileyebilir. Yalnızca sunucunun açık olduğunu değil, kritik işlemlerin tamamlanabildiğini de izleyin. Kurtarma önceliklerini iş birimleriyle belirleyin; sorumluları, iletişim kanallarını ve gerekli erişimleri önceden hazırlayın. Dokümantasyonu sistem değişikliklerinden sonra güncelleyin. Teknik çözüm hazır olsa bile eksik erişim bilgisi veya belirsiz görev dağılımı kurtarmayı geciktirebilir. Testleri yalnızca teknik ekibin kontrolüyle sınırlamayın. İlgili kullanıcıların uygulamaya bağlanabildiğini ve iş açısından gerekli işlemleri tamamlayabildiğini doğrulayın. Böylece altyapının yeniden çalışmasıyla operasyonun gerçekten başlaması arasındaki fark görünür olur. Test sonuçlarını kaydedin ve tespit edilen eksikler için sorumlu belirleyin. İş sürekliliği planı, ancak uygulanabilirliği düzenli olarak gözden geçirildiğinde işe yarar.
- 01
Kesinti toleransını belirleyin
Kabul edilebilir kesinti süresini ifade eden RTO hedefini iş etkisine göre tanımlayın.
- 02
Veri kaybı toleransını netleştirin
Kabul edilebilir veri kaybını zaman olarak ifade eden RPO hedefini yedekleme planıyla eşleştirin.
- 03
Geri yüklemeyi test edin
Yedeğin alınmasıyla yetinmeyin; uygulamanın açılmasını ve kullanıcı erişimini de doğrulayın.
Kontrol listesi
Güvenlik ve veri kontrolünü somut sorularla değerlendirin
Verinin işletme binasında bulunması tek başına güvenli olduğu anlamına gelmez. Bulutta barındırılması da sorumluluğu tamamen sağlayıcıya bırakmaz. Yetkilendirme, güncellemeler, erişim kayıtları ve yedeklerin korunması her modelde önemlidir. Teknik önlemleri sözleşmedeki görev paylaşımıyla birlikte değerlendirin; belirsiz sorumlulukları hizmet başlamadan açıklığa kavuşturun. Ayrılan çalışanların erişimlerinin kapatılması da günlük işletimin parçasıdır. Veri konumu ve aktarımıyla ilgili hukuki yükümlülükleri ilgili uzmanlarla ayrıca inceleyin. Bir altyapı modelinin adı, tek başına mevzuata uygunluk kanıtı değildir. Kontrol listesindeki her sorunun bir sorumlusu ve doğrulanabilir yanıtı olsun. Güvenlik önlemlerinin kurulması kadar sürdürülmesi ve düzenli gözden geçirilmesi de planlanmalıdır; bunları yalnızca satın alma aşamasında ele almayın. Sağlayıcının sunduğu güvenlik özellikleriyle işletmenin uygulaması gereken kontrolleri ayırın. Yönetici hesaplarının kimde olduğu, yetki değişikliklerinin nasıl onaylandığı ve olay kayıtlarının kim tarafından incelendiği açık olmalıdır. Bu görevlerin yazılı hâle getirilmesi, hizmet sırasında sorumluluk boşluğu oluşmasını önlemeye yardımcı olur. Verilerin dışa aktarılması ve silinmesi için izlenecek süreçleri de başlangıçta öğrenin.
- ✓
Erişimler nasıl yönetilecek?
Yönetici ve kullanıcı hesaplarını ayırın; yetkileri görev ihtiyacıyla sınırlayın.
- ✓
Veri nerede tutulacak?
Ana veri, yedek ve kayıtların konumlarını; dışa aktarma ve silme koşullarını öğrenin.
- ✓
Bakım ve olay takibi kime ait?
Güncelleme, şüpheli olay bildirimi ve kayıt inceleme sorumlularını belirleyin.
Toplam sahip olma maliyetini aynı kapsamla hesaplayın
Fiziksel sunucunun satın alma fiyatıyla bulutun aylık bedelini doğrudan karşılaştırmak yanıltıcıdır. Fiziksel tarafta donanım, lisans, kurulum, enerji, soğutma, barındırma, bakım ve yenileme giderlerini hesaba katın. Bulutta ise depolama, yedekleme, veri aktarımı, güvenlik bileşenleri ve yönetim hizmetleri bedeli değiştirebilir. Kiralık fiziksel sunucularda da hangi kalemlerin bedele dahil olduğunu inceleyin.
Karşılaştırmayı ortak bir dönem üzerinden yapın. Mevcut kullanımın yanında büyüme ve yoğun talep senaryolarını değerlendirin. Sürekli yüksek kapasite kullanan bir uygulamayla dönemsel çalışan bir ortamın maliyet dengesi farklı olabilir. Kullanılmayan bulut kaynaklarının açık bırakılması da bütçeyi etkileyebilir. Kaynakların kim tarafından izleneceğini ve gereksiz kullanımın nasıl tespit edileceğini belirleyin.
İç ekibin harcadığı zamanı, kesintilerin iş etkisini, para birimini, fiyat güncellemelerini ve hizmetten çıkış giderlerini görünür kılın. Lisans veya yedekleme içermeyen bir teklifi bunları kapsayan hizmetle eşit kabul etmeyin. Amaç yalnızca ucuz görüneni değil, maliyeti ve sorumlulukları anlaşılır olan çözümü seçmektir. Teknik ihtiyaç değiştiğinde maliyet tablosunu da güncelleyin.
Karşılaştırma
Hangi koşulda hangi seçenek öne çıkar?
İhtiyaç: Yerel erişim ve öngörülebilir kapasite.
Kontrol: Donanım bakımı ve yedeklilik.
İhtiyaç: Esnek kaynak tahsisi.
Kontrol: Bağlantı kalitesi ve yönetim kapsamı.
İhtiyaç: Farklı barındırma koşulları.
Kontrol: Gecikme ve operasyon karmaşıklığı.
Uygulama süreci
Geçişi kontrollü bir değişim olarak yönetin
Yeni altyapının kurulması geçişin tamamlandığı anlamına gelmez. Veri taşıma, uygulama doğrulama, kullanıcı erişimi ve geri dönüş planı birlikte ele alınmalıdır. Önce düşük riskli bir iş yüküyle yaklaşımı sınamak yararlı olabilir. Taşıma sırasında değişen verilerin hangi ortamda tutulacağını belirleyerek kopyalar arasında tutarsızlık oluşmasını önleyin. Kullanıcılara yeni bağlantı yöntemini ve geçiş takvimini önceden bildirin. Bikare’nin [bulut altyapı ve buluta geçiş hizmetleri](/bulut-altyapi-ve-buluta-gecis-hizmetleri), ihtiyaç analizi ve geçiş planlaması için değerlendirilebilir. Hangi uygulamaların taşınacağını, kabul ölçütlerini ve devreye alma sonrasındaki sorumluları hizmet kapsamına yazın. Eski ortamı kapatmadan önce gerekli veri ve kayıtların erişilebilirliğini doğrulayın; iş birimlerinin onayını da teknik kontrollerle birlikte alın. Geri dönüş planının hangi koşullarda uygulanacağını önceden belirleyin. Yeni ortamda işlem yapılmaya başlandıktan sonra eski sisteme dönmek, veri tutarlılığı açısından ayrıca planlama gerektirebilir. Canlıya geçiş kararını yalnızca kurulumun tamamlanmasına bağlamayın; kullanıcı erişimi, temel işlemler ve performans kabul ölçütleri de karşılanmalıdır. Geçiş sonrasında kapasite tahminlerini gerçek kullanımla karşılaştırarak gerekli düzenlemeleri yapın.
- 01
Ön koşulları doğrulayın
Lisans, sürüm, bağlantı ve veri taşıma yöntemlerini kontrol edin.
- 02
Test edin ve geri dönüşü hazırlayın
Temsili işlemlerle veri tutarlılığını, performansı ve kullanıcı erişimini sınayın.
- 03
Canlıya geçişi izleyin
Kaynak tüketimini, hata kayıtlarını ve kullanıcı bildirimlerini takip edin.
Kontrol listesi
Son kararda yönetim ve destek kapsamını netleştirin
Sunucunun nerede bulunduğu kadar onu kimin işleteceği de önemlidir. “Yönetilen” ifadesi tek başına yeterli değildir; izleme, bakım, güncelleme, uygulama ve yedekleme sorumlulukları hizmete göre değişebilir. Rutin kullanıcı taleplerinin ve kapasite değişikliklerinin nasıl karşılanacağını da sorun. İşletme içinde teknik kararları onaylayacak bir kişinin belirlenmesi, dış destek alınsa bile önemini korur. Bikare’nin [BT bakım ve teknik destek hizmetleri](/bt-bakim-ve-teknik-destek-hizmetleri) ile [yedekleme ve felaket kurtarma çözümleri](/yedekleme-ve-felaket-kurtarma), işletim ihtiyaçlarının değerlendirilmesinde ilgili hizmetlerdir. Keşif öncesinde uygulama envanterini, mevcut sorunları ve büyüme planını hazırlayın. İyi seçim, ihtiyaçları karşılayan ve sorumlulukları anlaşılır olan çözümdür; yalnızca başlangıç fiyatına bakılarak belirlenmez. Destek teklifinde müdahale koşullarıyla sorunun çözülmesine ilişkin taahhütleri birbirine karıştırmayın; sözleşmede neyin tanımlandığını okuyun. Hizmet saatlerini, talep kanallarını ve kapsam dışı işlemlerin ücretlendirmesini açıkça öğrenin. Hizmet değişikliği ihtimalini de başlangıçta düşünün: verilerin, yönetici erişimlerinin ve dokümantasyonun teslimi belirsiz kalmamalıdır. İşletilebilirlik kadar taşınabilirlik de uzun vadeli kararın parçasıdır.
- ✓
Görev paylaşımı açık mı?
İşletme, sağlayıcı ve destek ekibinin sorumluluklarını yazılı olarak ayırın.
- ✓
Destek koşulları anlaşılır mı?
Hizmet saatlerini, öncelikleri ve müdahale koşullarını sözleşmeden doğrulayın.
- ✓
Çıkış planı var mı?
Verilerin, yönetici erişimlerinin ve dokümantasyonun teslim koşullarını belirleyin.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
