Küçük işletmede sunucu kurulumu öncesi hangi bilgiler hazırlanmalı?

Küçük bir işletmede sunucu kararı, çalışacak işlerin ve bu işler aksadığında yaşanacak etkinin anlaşılmasıyla başlar. Kullanıcı sayısı tek başına cihaz seçtirmez: aynı ekip yalnız ortak dosyalara erişiyor da olabilir, birlikte bir iş uygulaması kullanıyor da olabilir. İlk görüşmeye uygulama, erişim, veri ve kesinti ihtiyaçlarını anlatan kısa bir notla gitmek, karşılaştırılabilir teklif almayı kolaylaştırır.

Yeni sunucunun hangi ihtiyacı karşılayacağını yazın

Önce bugün neyin eksik kaldığını tarif edin. Dosyaların farklı bilgisayarlarda kalması, bir uygulamanın tek bilgisayara bağımlı olması ve mevcut sistemin büyümeye yetmemesi farklı sorunlardır. Her biri için aynı donanımı almak yerine, işin gerektirdiği çözümü değerlendirin. Yalnız dosya paylaşımı gerekiyorsa NAS seçeneği de görüşülebilir; uygulama çalıştırma ihtiyacı varsa yazılımın desteklediği ortam ayrıca doğrulanır.

Bulut üzerinden kullanılan bir uygulamanın varlığı, işletmede mutlaka yerel sunucu gerektiğini göstermez. Hangi işin zaten dış hizmette yürüdüğünü, hangisinin ofiste kalması gerektiğini ve internet bağlantısına bağımlılığını ayırın. Mevcut düzen ihtiyacı karşılıyorsa bunun korunması da değerlendirmeye dahil olabilir. Bu rehber işletmede kullanılan yerel sunucuların planlanmasına yöneliktir; hosting, VPS veya oyun sunucusu seçimini kapsamaz.

Tekliften önce bir sayfalık ihtiyaç notu hazırlayın

Uygulamalar ve işler: Kullanılan programların adlarını, biliniyorsa sürümlerini ve işlevlerini yazın. Teklifte hangi uygulamanın kurulacağı, hangisinin yalnız taşınacağı ve hangi işlem için yazılım sağlayıcısının desteği gerektiği ayrı görülsün.

Kullanıcılar ve yoğun zamanlar: Toplam çalışan sayısının yanında aynı anda sistemi kullanacak kişileri, ofis dışından erişim ihtiyacını ve yoğun dönemleri belirtin. Kişilerin parolaları yerine görevlerini ve hangi bilgiye ihtiyaç duyduklarını anlatın.

Veri ve büyüme: Yaklaşık mevcut veri miktarını, dosya türlerini ve beklenen büyümeyi not edin. Bilmediğiniz değeri tahmin edilmiş kesin sayı gibi sunmayın; ölçüm gerekiyorsa bunun kim tarafından ve hangi erişimle yapılacağını görüşün.

Mevcut donanım ve lisanslar: Cihazların bilinen modeli, yaşı, garanti durumu ve mevcut lisansların hangi ürünlere ait olduğu ilk değerlendirmeye yardımcı olur. Bu listeye lisans anahtarlarını eklemeyin. Eldeki lisansın yeni donanımda veya sanal ortamda kullanılabilirliği, ilgili ürünün koşullarıyla ayrıca doğrulanmalıdır.

Çalışma ve kesinti: Hangi işlerin öncelikli olduğunu, planlı geçiş için uygun zaman aralığını ve kesinti olduğunda kimin karar vereceğini belirtin. Veri kaybına ilişkin beklenti ile işin ne kadar süre durabileceği iki ayrı sorudur; teklif bunları tek bir “yedekli sistem” ifadesiyle geçmemelidir.

Kurulum yeri ve sorumlular: Sunucunun bulunacağı alanı, mevcut ağ ve güç altyapısını, uygulama sağlayıcısını ve işletmedeki yetkili kişiyi belirtin. Elektrik kapasitesi veya UPS süresi için bu nottan hesap çıkarılmaz; gerekiyorsa ilgili uzman değerlendirmesi ayrı planlanır.

Sanallaştırmayı kapasite ve uygulama desteğiyle değerlendirin

Sanallaştırma, fiziksel kaynaklar üzerinde ayrı sanal makineler çalıştırmayı sağlar. Microsoft’un Hyper-V açıklaması da sanal makine çalıştırmayı, yüksek kullanılabilirlik ve kurtarma gibi ek yeteneklerden ayrı ele alır. Bu nedenle “sanal sunucu kurulacak” ifadesinin hangi iş yüklerini, hangi kaynakları ve hangi yönetim kapsamını içerdiği sorulmalıdır. Birden fazla sanal makine, kendiliğinden birden fazla bağımsız fiziksel sunucu anlamına gelmez.

Teklifte işlemci, bellek ve depolama önerisinin hangi uygulama gereksinimine dayandığını; uygulama ve işletim sistemi sürümlerinin birlikte desteklenip desteklenmediğini sorun. Sanallaştırma platformu, konuk işletim sistemi ve iş uygulamasının lisans koşulları ayrı açıklanmalıdır. Bu yazı belirli bir marka, kapasite veya lisans paketini bütün küçük işletmeler için uygun ilan etmez.

RAID ile yedekten geri dönüşü ayrı değerlendirin

RAID, tek başına bağımsız bir yedek değildir. Seagate’in yedekleme açıklaması, RAID düzeninin verinin bir kopyasını barındırabileceğini; bunun kendi başına yedekleme planı yerine geçmediğini belirtir. Teklifte RAID bulunuyorsa ayrıca hangi verinin nerede yedekleneceğini, hangi geçmiş kopyaların tutulacağını ve geri dönüşün nasıl kontrol edileceğini sorun. Sunucudaki tek veri kopyası, disk düzeninin adı değiştiğinde yedeklenmiş olmaz.

Yedeklemenin kapsamı da açık olmalıdır: yalnız dosyalar mı, uygulama verileri ve gerekli yapılandırmalar da mı korunacak? NCSC, yedekten geri yüklemeyi bilmenin ve önemli verilerin yedekte bulunduğunu kontrol etmenin gereğini vurgular. Sunucu kurulumunda teslim edilecek yedekleme hazırlığıyla, ayrıca yürütülecek geri yükleme denemesinin kapsamını ve sorumlusunu ayırın. Deneme, çalışan sistemin üzerine izinsiz veri yazılmasını gerektiren bir kabul adımı olarak tanımlanmamalıdır.

Geri dönüş kontrolünde sorulacak ayrıntılar için Yedek alındığını görmek neden tek başına yeterli değil? rehberini inceleyebilirsiniz.

Erişimi ve hesap sahipliğini baştan konuşun

Kimlerin hangi uygulama ve verilere erişeceğini görev bazında belirleyin. Günlük kullanıcı erişimi, sistem yöneticiliği ve dış destek erişimi ayrı ele alınmalıdır. NCSC’nin erişim yönetimi kılavuzu, gereksiz yetkilerin kaldırılmasını, yönetim hesaplarının günlük kullanımdan ayrılmasını ve yönetim erişiminde çok faktörlü doğrulamayı önerir. Seçilen çözümün bu gereksinimleri nasıl karşılayacağı teknik incelemede netleştirilmelidir.

İşletme adına açılacak hesapların sahibi, yetkili teslim alıcısı ve kurtarma bilgilerinin sorumlusu belli olmalıdır. Personel veya destek sağlayıcısı değiştiğinde erişimin nasıl sonlandırılacağı da teslim görüşmesine girer. İlk teklif mesajına parola, VPN bilgisi, kurtarma kodu, lisans anahtarı veya müşteri dosyası eklemeyin. Gerçek erişim gerektiğinde kapsamı, yetkiyi ve güvenli paylaşım yolunu ilgili sorumlular belirlemelidir.

Teslim kabulünü işletmenin yaptığı işle tanımlayın

“Sunucu açıldı” kaydı tek başına işin tamamlandığını anlatmaz. Kabul listesinde hangi uygulamanın hangi yetkili kullanıcı rolüyle çalışacağı, hangi dosyalara erişilebileceği ve nelerin kapsam dışında kalacağı yazılabilir. Uygulama sağlayıcısının incelemesi gereken bir işlev varsa bu kontrolün sorumlusu da belirtilmelidir. Gerçek müşteri verisi kullanımı ve deneme ortamı ayrıca kararlaştırılmalıdır.

Taşıma yapılacaksa geçişten önce korunacak verinin, mevcut yedeğin ve geri dönüş koşullarının değerlendirilmesini isteyin. Yeni sistem kabul edilmeden eski sistemin veya son kullanılabilir kopyanın kaldırılması planın varsayılan adımı olmamalıdır. Geçişi başlatma ve gerektiğinde durdurma kararının kimde olduğu yazılmalı; hedeflenen kesinti süresi garanti edilmiş sonuç gibi sunulmamalıdır.

Teslim dosyasında kurulan bileşen ve sürümler, kabul kontrollerinin sonucu, tamamlanmayan işler, lisans ve destek kapsamı ile erişim devrinin nasıl yapıldığı bulunmalıdır. Parolaların açık belgeye eklenmesi yerine güvenli devir yöntemi kaydedilir. Test edilmemiş bir işlev için başarılı sonucu veya geleceğe dönük sıfır kesinti taahhüdü beklenmemelidir.

Kurulum sonrası işleri ve ayrı bedelleri netleştirin

Donanım temini, lisanslar, yazılım üreticisinin desteği, yedekleme sistemi ve sürekli bakımın hangi kalemlerde yer aldığını karşılaştırın. Kurulumu yapan kişinin daha sonra uyarıları izleyeceği veya bütün uygulamalara süresiz destek vereceği varsayılmamalıdır. Güncelleme planı, yedek takibi, kapasite izleme ve arıza bildirimini kimin yürüteceği belirlenmelidir; saat, ücret ve müdahale hedefi yalnız gerçek teklif veya sözleşmeyle netleşir.

İhtiyaç notunuz hazır olduğunda sunucu kurulumu ve sanallaştırma hizmetinin kapsamını inceleyebilirsiniz. Teklif görüşmesinde nottaki açık soruların hangilerinin keşifle, hangilerinin uygulama sağlayıcısıyla cevaplanacağını belirlemek faydalı bir başlangıçtır.

Düzenli destek düşünülüyorsa sunucu ve network bakım sözleşmesinin kapsamını okuma rehberi kurulumdan sonraki sorumlulukları karşılaştırmaya yardımcı olur.