Yönetilen hizmet hangi katmanları kapsıyor?
Sunucu hizmetini donanım, sanallaştırma, işletim sistemi, veritabanı ve uygulama gibi katmanlara ayırabilirsiniz. Fiziksel cihazın bakımının sağlayıcıda olması, web uygulamasındaki hatanın da aynı ekip tarafından çözüleceği anlamına gelmez. VDS’nin çalışır durumda olmasıyla ERP’deki bir raporun doğru sonuç üretmesi farklı kontrollerdir. Teklifte desteklenen sistemler ve üstlenilen işlemler görülmelidir.
“Tam yönetim” gibi bir ifade kullanılıyorsa bunu görev listesine çevirmeyi isteyin. İşletim sistemi kurulumu, güvenlik ayarları, yazılım güncellemesi ve uygulama kurulumu ayrı kalemler olabilir. Kurumun IT ekibinin veya yazılım üreticisinin devam eden görevleri de aynı tabloda yer almalıdır. Böylece hizmet talebinde bulunacak kişi, sorunu hangi ekibe ileteceğini bilir.
Örnek senaryo: sunucu açık, iş uygulaması yanıt vermiyor
Bir şirketin sanal sunucusuna erişilebildiğini, fakat çalışanların iş uygulamasına giriş yapamadığını düşünelim. Sunucuya bağlantı kurulması, işletim sisteminin tamamen sağlıklı veya uygulamanın çalışır olduğunu tek başına göstermez. Uygulama servisi durmuş, veritabanı bağlantısı kesilmiş ya da disk alanı dolmuş olabilir. Bildirimde hangi kullanıcıların etkilendiği ve sorunun ne zaman başladığı belirtilmelidir.
Bu senaryoda izleme kapsamı önem kazanır. Yalnızca sunucuya erişimi kontrol eden izleme, uygulamanın giriş ekranının çalışmadığını fark etmeyebilir. Uygulama kontrolü talep ediliyorsa neyin ölçüleceği ve alarmla kimin ilgileneceği belirlenmelidir. Sağlayıcının veritabanı veya uygulama katmanına müdahale yetkisi olup olmadığı da planın parçasıdır. Yetki verilmemiş bir ekibin sorunu çözmesi beklenemez.
Güncelleme için sürüm, test ve bakım zamanı
İşletim sistemi güncellemesi ile uygulama sürüm yükseltmesi aynı işlem değildir. Uygulama üreticisi belirli sürümleri destekliyor olabilir. Güncelleme kararı verilirken bağımlılıklar, lisans koşulları ve geri dönüş yöntemi değerlendirilir. Otomatik güncelleme bulunan bir ortamda da hangi bileşenlerin otomatik değiştiği bilinmelidir. Değişikliklerin sonuçlarını takip etmek için kayıt tutulabilir.
Kritik uygulamalarda bakım zamanı iş birimiyle görüşülür. Test ortamı gerekiyorsa bunun nasıl sağlanacağı, güncelleme öncesi hangi yedeğin alınacağı ve başarısızlıkta kimin karar vereceği belirlenir. Kullanıcılar çalışırken yapılacak bir değişiklikle mesai dışı planlanan değişiklik farklı riskler taşır. Yönetim teklifinde sadece güncellemenin yapılıp yapılmayacağı değil, nasıl onaylanacağı ve kontrol edileceği de anlatılmalıdır.
Yedek işini kim izliyor, geri dönüşü kim yapıyor?
Yedek alma, başarısız işleri takip etme ve veriyi geri yükleme ayrı görevlerdir. İşlem her gece otomatik çalışıyor olabilir; bir hata oluştuğunda kimin haberdar olacağı bilinmiyorsa kopyalar beklenenden eski kalabilir. Saklama süresi ve yedeklerin tutulduğu ortam, hizmet açıklamasında açık olmalıdır. Bir dosyanın mı, veritabanının mı, yoksa bütün makinenin mi geri döndürüleceği de belirlenir.
Geri yüklemenin yapılabilmesi ile uygulama verisinin kabul edilmesi farklı sorumluluklardır. Sağlayıcı yedeği açabilir; muhasebe veya operasyon ekibinin son kayıtları doğrulaması gerekebilir. Testte bu ekiplerin görev alması, gerçek olayda eksik kalan adımları azaltır. Yedekleme talebinde veri sahibini, kabul edilebilir kayıp aralığını ve hizmetin ne kadar süre kapalı kalabileceğini konuşun.
Destek saati, bildirim ve çözüm süresi
Bir destek kanalının her saat açık olması, bütün sorunların aynı sürede çözüleceğini göstermez. Talebin alınması, değerlendirilmesi, ilk müdahale ve çözüm farklı aşamalardır. Sizin için kritikse bu aşamaların hangi koşullarda tanımlandığını sorun. İncelemeye başlamak için gerekli erişimlerin veya uygulama üreticisinin desteğinin bulunmaması süreyi etkileyebilir.
İletişim planında kurumun yetkili kişileri, kullanılacak kanal ve önceliklendirme yöntemi yer alabilir. Bildirimde hata zamanı, etkilenen iş, son değişiklikler ve görülen mesaj paylaşılır. Yönetici şifreleri gibi hassas bilgiler genel bir hata açıklamasına eklenmemelidir. Kurum içindeki yetkili değiştiğinde sağlayıcının doğru kişiye ulaşabilmesi için bu liste güncellenir.
Erişim yetkisi ve değişiklik onayı
Yönetim görevini üstlenen ekibin hangi sistemlere erişebileceği belirlenmelidir. Her işlem için sınırsız yönetici yetkisi kullanılması zorunlu değildir; görevle ilişkili erişim değerlendirilebilir. Hesapların kime ait olduğu, çalışan veya hizmet sağlayıcı değişiminde nasıl kapatılacağı ve yapılan değişikliklerin nasıl kaydedileceği planlanır. Erişim bilgilerinin teslimi de kontrollü yapılmalıdır.
Kurumdan onay gerektiren işlemler ayrıca tanımlanabilir. Örneğin kullanıcı hesabını kapatma, uygulama sürümünü değiştirme veya eski bir yedeği canlı sistemin üzerine geri yükleme iş sonucunu etkiler. Bu işlemi kimin talep edebileceği ve onayın nasıl verileceği bilinmelidir. Yedek geri dönüşünde yeni verilerin kaybolması ihtimali varsa veri sahibi kararın parçası olur.
Kendi ekibinizle mi, dış hizmetle mi ilerlemelisiniz?
Teknik ekibi bulunan bir kurum bazı işletim görevlerini içeride sürdürebilir. Ekip zamanı, uzmanlık, mesai dışı müdahale ve dokümantasyon ihtiyacı birlikte değerlendirilir. Dış hizmette de kurumun uygulama ve iş süreçleriyle ilgili sorumlulukları devam eder. Seçim, kurumun hangi işleri düzenli yürütebildiği ve hangi görevler için destek istediği üzerinden yapılmalıdır.
Bir görevden sorumlu olmak, diğer ekiplerden bağımsız çalışmak anlamına gelmez. Uygulama güncellemesi altyapı değişikliği gerektirebilir; yedekleme politikası iş biriminin veri beklentisine bağlıdır. Teklif görüşmesinde bugünkü görev dağılımını göstermek yararlıdır. Eksik kalan işler görülür ve iki ekibin aynı işi yaptığını sanması ya da bir işin tamamen sahipsiz kalması önlenebilir.
Disket’e yönetim talebini nasıl tarif edebilirsiniz?
İlk görüşmede çalışacak uygulamaları, işletim sistemi sürümünü ve mevcut teknik ekibinizi anlatabilirsiniz. Ardından hangi görevleri üstlenebildiğinizi ve nerede desteğe ihtiyacınız olduğunu belirtin. Güncelleme, izleme, yedekleme, taşıma ve uygulama desteğini tek bir “sunucu yönetimi” başlığı yerine ayrı ele almak daha açıklayıcıdır.
Disket’in sanal veya fiziksel sunucu çözümleri için kaynak planıyla birlikte bu işletim beklentileri değerlendirilir. Kesin görevler, desteklenen yazılımlar ve müdahale kapsamı teklif üzerinde belirlenmelidir. Genel rehberdeki bir örnek görev tablosu, otomatik olarak hizmet taahhüdü değildir. Görüşmenin amacı, kurumun ihtiyacını uygulanabilir bir sorumluluk dağılımına dönüştürmektir.
Teklif görüşmesinde doldurulabilecek görev tablosu
| Görev | Belirlenecek sorumlu | Kontrol veya onay |
|---|---|---|
| İşletim sistemi güncellemesi | Kurum veya sağlayıcı | Bakım zamanı ve uyumluluk |
| Uygulama sürümü değişimi | Kurum veya uygulama ekibi | Test ve iş birimi onayı |
| Alarm takibi | Kapsama göre belirlenir | Bildirim ve müdahale akışı |
| Yedek geri yükleme | Kapsama göre belirlenir | Veri sahibi onayı ve kabul |
| Erişimlerin kapatılması | Yetkili ekip | Personel ve hizmet değişimi |
Teklif öncesi kontrol listesi
- Uygulama ve işletim sistemi envanteri
- Kurum, sağlayıcı ve yazılım üreticisinin görevleri
- Güncelleme ve bakım onayları
- İzlenecek hizmetler ve alarm sorumluları
- Yedek alma, geri yükleme ve veri kabulü
- Destek kanalı, erişim yetkileri ve teslim belgeleri
Sık sorulan sorular
Yönetilen sunucuda uygulama desteği her zaman dahil midir?
Hayır. İşletim sistemi, veritabanı ve uygulama destek görevleri ayrı tanımlanır. Kullanılan yazılımın desteklenip desteklenmediği, erişim yetkileri ve kurumun yazılım üreticisiyle yürüteceği işler teklifte görülmelidir.
7/24 destek bütün sorunların anında çözüleceği anlamına gelir mi?
Destek kanalının çalışma saati ile müdahale ve çözüm aşamaları farklıdır. Beklentiniz önemliyse talep alma, ilk değerlendirme ve müdahale kapsamını ayrı sorun; koşullar teklif üzerinde belirlenir.
Geri yükleme tamamlandığında uygulama hazır sayılır mı?
Uygulamanın açılması ve iş verisinin doğrulanması gerekir. Geri yükleme işini yapan ekip ile veriyi kabul eden iş biriminin görevleri birlikte planlanmalıdır.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.