Bir IT raporu çok sayıda grafik içerebilir fakat yöneticinin hangi kararı vermesi gerektiğini söylemeyebilir. İyi bir rapor, hizmetlerin durumunu iş etkisiyle açıklar; riskleri görünür kılar ve bir sonraki adımı tanımlar. KPI seçimi bu nedenle kullanılan aracın hazır ekranlarından değil, şirketin hizmet hedeflerinden başlamalıdır.
Sunucu çalışıyor mu, iş akışı çalışıyor mu?
CPU veya bellek kullanımı teknik teşhis için değerlidir. Ancak kullanıcı giriş yapamıyorsa düşük CPU kullanımı hizmetin iyi olduğu anlamına gelmez. Kritik uygulamalarda giriş, sorgulama veya sipariş tamamlama gibi anlamlı işlemleri izlemek gerekir. Ölçümün nereden yapıldığı, hangi zaman aralığını kapsadığı ve neyi dışarıda bıraktığı raporda yazmalıdır.
Google SRE'nin hizmet hedeflerine dayalı alarm yaklaşımı, kullanıcı deneyimiyle ilişkili göstergelere odaklanır. Küçük bir kurum için başlangıç, onlarca metrik toplamak yerine kritik birkaç iş akışını ve bunların kabul edilebilir durumunu tanımlamak olabilir. Hedefler hazır bir yüzde kopyalanarak değil, iş ihtiyacıyla belirlenmelidir.
Başlangıç için altı gösterge grubu
| Gösterge | Birlikte sorulacak soru |
|---|---|
| Hizmet kesintisi | Hangi iş akışı ve kaç kullanıcı etkilendi? |
| Olay müdahalesi | Öncelik ve destek saatleri hesaba katıldı mı? |
| Tekrarlayan sorun | Kalıcı çözüm için hangi iş açıldı? |
| Yedek geri yükleme | Gerçek bir veri veya sistem denenebildi mi? |
| Güncelleme durumu | Ertelenen riskin sahibi ve nedeni belli mi? |
| Kapasite eğilimi | Mevcut büyüme sürerse ne zaman karar gerekir? |
Ortalamaların gizlediği sorunları gösterin
Bir ay içindeki taleplerin çoğu kısa sürede çözülürken birkaç kritik olay günlerce bekleyebilir. Tek ortalama bu farkı gizler. Talepleri öncelik ve hizmet türüyle ayırın; açık iş yaşını ve bekleme nedenlerini gösterin. Müşteri onayı, tedarikçi yanıtı ve teknik çalışma sürelerinin birbirinden ayrılması yorumu kolaylaştırır.
Aynı şekilde aylık kaynak ortalaması yerine yoğun saatleri ve eğilimi inceleyin. Örneğin disk doluluğu bugün sorun çıkarmasa da düzenli büyüme nedeniyle yaklaşan bir kapasite ihtiyacı olabilir. Bu varsayımsal örnekte raporun değeri kırmızı bir grafik üretmek değil, temizlik veya kapasite kararı için yeterli zamanı sağlamaktır.
Her bulguyu bir aksiyona bağlayın
“Yedek sorunu var” yerine etkilenen sistem, son başarılı iş, iş etkisi, sorumlu ve hedef tarih belirtilmelidir. Bir sonraki raporda aynı madde yeniden yazılmakla kalmamalı, önceki karara göre durumu açıklanmalıdır. Tamamlanmış aksiyon için doğrulama kanıtı bulunsun. Hassas erişim bilgileri veya kişisel veriler yönetim raporuna gereksiz yere eklenmemelidir.
Aylık toplantı gündemi
- Geçen ayın aksiyonlarını ve gecikmeleri değerlendirin.
- İş etkisi olan olayları ve tekrarları inceleyin.
- Bakım, yedek testi ve açık riskleri gözden geçirin.
- Kapasite ve bütçe kararlarını sahiplerine atayın.
- Bir sonraki dönem için ölçüm veya süreç değişikliklerini onaylayın.
Çok KPI daha iyi yönetim sağlar mı?
Karar veya aksiyon üretmeyen göstergeler raporu ağırlaştırabilir. Her metrik için “Bu sonuç değişirse ne yapacağız?” sorusuna yanıt bulunmalıdır.
Raporlamayı IT yönetimi hizmet kapsamının parçası yapın. Teknik görevleri netleştirmek için sunucu yönetimi kontrol listesini kullanabilirsiniz.