Yönetilen BT hizmeti; işletmenin sunucu, ağ, bilgisayar ve temel BT servislerinin sürekli izlenmesi, bakımı ve teknik yönetimidir. Kullanıcı desteği, güncelleme, arıza müdahalesi, kapasite takibi ve veri koruma çalışmalarını birleştirerek iş uygulamalarının güvenilir biçimde çalışmasını destekler.
ERP ekranı yavaşladığında sorun uygulamada, veritabanında, depolamada veya kullanıcıyla sunucu arasındaki bağlantıda olabilir. Bu katmanların her biri farklı bir firmaya aitse olayın sahipliğini üstlenecek bir operasyon düzeni gerekir. Yönetilen BT hizmetinin değeri burada ortaya çıkar: sistemleri düzenli işletmek, değişiklikleri kontrol etmek ve arızanın etkisini iş süreci üzerinden takip etmek.
Sağlıklı bir hizmet modeli üç şeyi görünür kılar: hangi varlık yönetiliyor, hangi iş yapılıyor ve yapıldığı nasıl kanıtlanıyor? Aşağıdaki çerçeve, mevcut BT ekibiyle birlikte çalışılan ya da günlük altyapı yönetiminin dışarıdan yürütüldüğü ortamlarda teknik kapsamı değerlendirmek için kullanılabilir.
1. Envanter, cihaz listesinden hizmet haritasına dönüşmeli
Bir envanterde IP adresi, işletim sistemi ve RAM bilgisi bulunması başlangıçtır. İşletim için uygulamanın sahibi, desteklenen sürümü, lisans durumu, yedekleme politikası, bağlı olduğu veritabanı ve hizmet verdiği iş birimi de gerekir. Kullanımdan kaldırılmış bir sunucunun hâlâ DNS kaydında veya bir entegrasyonda bulunması, yanlış değişiklik kararına yol açabilir.
Örneğin depo uygulaması bir veritabanına, dosya paylaşımına, etiket yazıcısına ve kimlik doğrulama servisine bağlı olsun. Yalnız uygulama sunucusunu izlemek bu zincirin tamamını kapsamaz. Bağımlılık haritası, arıza sırasında hangi kontrollerin birlikte yapılacağını ve bakımda kimlerin bilgilendirileceğini gösterir.
- Her kritik hizmet için teknik sorumlu ve iş birimi sahibi belirlenir.
- Varlıkların destek süresi, kritikliği ve bakım penceresi kaydedilir.
- Envanterdeki değişiklikler kurulum, kaldırma ve erişim süreçleriyle eşleştirilir.
2. İzleme, hizmetin kullanıcıya verdiği cevabı ölçmeli
Sunucunun ping yanıtı vermesi, sipariş ekranının çalıştığını göstermez. Altyapı metriklerinin yanında uygulamanın dışarıdan gözlenen davranışı da izlenmelidir. Google’ın SRE yaklaşımı bu ayrımı iç metrikler ile kullanıcının gördüğü hizmet davranışı üzerinden kurar; gecikme, trafik, hata ve doygunluk birlikte değerlendirilir. İzleme yaklaşımının teknik açıklaması.
Bir ERP için güvenli bir sentetik kontrol, yetkisi sınırlandırılmış test hesabıyla belirli bir okuma işleminin süresini ölçebilir. Buna depolama gecikmesi, veritabanı bağlantı sayısı ve kuyruk uzunluğu eşlik eder. Amaç, gerçek sipariş üretmeden erişim yolunu sınamaktır. Başarısız kontrolün kime ulaşacağı ve hangi olay kaydını oluşturacağı da tanımlanmalıdır.
| Sinyal | Olası teknik inceleme | İş etkisi |
|---|---|---|
| Uygulama yanıtı yavaş | Veritabanı beklemeleri, disk gecikmesi, ağ ve bağlantı havuzu | Sipariş veya sevkiyatın gecikmesi |
| Yedek işi başarısız | Depo kapasitesi, kimlik bilgisi, kilit ve aktarım hatası | Geri dönülebilir veri aralığının büyümesi |
| Disk hızla doluyor | Günlük büyümesi, saklama politikası, veri artışı | Hizmetin yazma yapamaz hâle gelmesi |
| Replika gecikmesi artıyor | Bağlantı, hedef performansı ve değişim hızı | Devralmada veri kaybı penceresinin büyümesi |
Tablonun tamamı için yana kaydırabilirsiniz.
3. Yama yönetimi, yükleme ve doğrulama zinciridir
Güncellemeler envanterdeki bütün cihazlara aynı anda dağıtıldığında, ortak bir uyumsuzluk birden fazla hizmeti etkileyebilir. Önce güncellemenin ilgili ürüne uygulanabilirliği, açığın etkisi ve sistemin maruz kaldığı erişim değerlendirilir. Ardından pilot grup, bakım penceresi, geri alma koşulu ve uygulama kabul adımı belirlenir.
NIST SP 800-40 Rev. 4, yama yönetimini teknolojinin önleyici bakımı olarak ele alır. Bu yaklaşım, güncellemenin bulunmasından uygulanmasının doğrulanmasına kadar olan sürecin planlanmasını gerektirir. NIST kurumsal yama yönetimi rehberi.
Örnek bir uygulamada önce test ortamı, ardından sınırlı üretim grubu, son olarak kalan sistemler güncellenir. Yeniden başlatma gerekiyorsa bu adım açıkça planlanır. Bir güncellemenin konsolda “başarılı” görünmesiyle yetinilmez; servis durumu, olay günlükleri ve ilgili iş akışı kontrol edilir. Uygulanamayan yamalar için gerekçe, geçici kontrol ve yeniden değerlendirme tarihi kaydedilir.
4. Yetki, yedekleme ve değişiklik yönetimi birlikte çalışır
Yönetim erişimi kişiye bağlı hesaplarla, görev için gereken yetkiyle ve mümkün olan ortamlarda çok faktörlü doğrulamayla kurulmalıdır. Günlük kullanıcı hesabı ile yönetici hesabını ayırmak, rutin bir hesap olayının yönetim alanına etkisini sınırlar. Ayrıcalıklı işlemler kayıt altına alınır; personel veya tedarikçi ayrıldığında erişimlerin kaldırılması hizmetin parçasıdır.
Yedekleme tarafında işin başarılı bitmesi, saklama hedefinin karşılandığı ve verinin geri yüklenebildiği anlamına gelmez. Düzenli geri yükleme örnekleri, yedek deposunun kapasitesi ve yetki ayrımı izlenir. Ağ kuralı veya sanallaştırma değişikliği öncesinde mevcut yapılandırmanın sürümü ve geri dönüş yolu belli olmalıdır. Böylece bir olayın hangi değişiklikten sonra başladığı araştırılabilir.
“Depo uygulaması için yeni entegrasyon erişimi”: kaynak ve hedef, gerekli protokol, uygulama sahibi, onaylayan kişi, uygulama zamanı, test sonucu ve kuralın yeniden gözden geçirileceği tarih birlikte tutulur. “Erişim açıldı” şeklindeki tek satır, sonraki bakım için yeterli bilgi bırakmaz.
5. Olayı gidermek ile tekrarını önlemek farklı işlerdir
Bir disk dolduğunda geçici alan açmak hizmeti geri getirebilir. Ancak günlüklerin neden büyüdüğü, saklama politikasının neden çalışmadığı ve kapasite alarmının neden oluşmadığı araştırılmazsa olay tekrar eder. Operasyon düzeninde hizmeti geri getiren olay müdahalesiyle, tekrar eden nedeni ortadan kaldıran problem çalışması ayrı takip edilir.
Öncelik belirlenirken cihazın modeli yerine iş etkisi esas alınır. Tek kullanıcının yazıcı sorunu ile bütün fabrikanın sevkiyat uygulamasına erişememesi aynı kuyrukta aynı önceliğe sahip olmamalıdır. İlk yanıt süresi, teknik çalışmanın başlaması, geçici çözüm ve kalıcı çözüm süreleri de ayrı ölçülmelidir. Hızlı yanıt verilen ama saatlerce sahiplenilmeyen olaylar iyi hizmet göstergesi değildir.
6. Aylık rapor, cihaz sayısından karar üretmeli
Raporlamada kapanan talep sayısının yanında tekrar eden olaylar, başarısız değişiklikler, destek dışına yaklaşan sürümler ve çözülmemiş kapasite riskleri yer almalıdır. Uygulama yanıt süreleri için yalnız ortalamaya bakmak yoğun saatlerdeki sorunu gizleyebilir; örneğin p95 ölçümü, isteklerin yüzde 95’inin hangi sürenin altında tamamlandığını gösterir. Ölçüm dönemi ve işlem türü aynı tutulmalıdır.
Hizmeti değerlendirirken şu çıktıları isteyin: güncel envanter, sahipliği belli olay kayıtları, uygulanmış ve ertelenmiş yama listesi, geri yükleme deneme sonuçları ve sonraki dönemin öncelikleri. Bu çıktılar, altyapının yalnız ayakta tutulduğunu değil, nasıl yönetildiğini de gösterir. Kurumun kendi ekibi varsa rapor, bir sonraki iyileştirme kararının ortak girdisi olur.
Sık sorulan sorular
Yönetilen BT ile teknik servis aynı şey mi?
Teknik servis tekil arızalara odaklanabilir. Yönetilen BT, üzerinde anlaşılan işlerin devamlı yürütülmesini ve takibini kapsar.
Tüm işleri tek firmaya vermek zorunda mıyız?
Hayır. Mevcut ekiple paylaşılan veya belirli alanlarla sınırlanan bir kapsam oluşturulabilir.