BT Hizmetlerinde Kullanılabilirlik Yönetimi Nasıl Yapılır?
Beceri rehberi

BT Hizmetlerinde Kullanılabilirlik Yönetimi Nasıl Yapılır?

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

Kullanılabilirlik yönetimi, bir BT hizmetinin iş tarafının ihtiyaç duyduğu anda çalışır durumda olmasını hedef, ölçüm ve iyileştirme döngüsüyle güvence altına alır. Başarı, yüzdeden çok doğru ölçülen ve iş etkisine bağlanan hedefle ilgilidir.

Bir bakışta

  1. Hedef sistemin değil, hizmetin kullanılabilirliği için konur. Kullanıcı sunucuyu değil, uçtan uca çalışan hizmeti görür; ölçüm de bu bakıştan yapılmalıdır.
  2. Hedef iş etkisinden türer, teknik rekordan değil. Kesinti saatinin iş tarafındaki bedeli, hangi hizmete ne kadar yatırım yapılacağını belirler.
  3. Kullanılabilirlik, sıklık ve süre birlikte ölçülür. MTBF kesintilerin ne sıklıkla, MTRS ise ne kadar sürede toparlandığını gösterir.
  4. Planlı bakım ile plansız kesinti ayrı izlenir. Anlaşılan hizmet süresi tanımı, hangi sürenin hesaba katılacağını açıklığa kavuşturur.
  5. İyileştirme, kesinti kayıtlarını nedene göre okumakla başlar. Tekrarlayan neden, tek seferlik arızadan daha fazla yatırım hakkı doğurur.

Kullanılabilirlik yönetimi neyi güvence altına alır?

Kullanılabilirlik, hizmetin gerektiğinde ve gerektiği ölçüde çalışabilmesidir. Yönetimin amacı kesintiyi sıfırlamak değil, iş tarafının tahammül edebileceği kesinti düzeyini bilmek, ona göre tasarım ve işletme kararları almak ve gerçekleşeni ölçerek hedefle karşılaştırmaktır.

Bu çalışma tek bir ekibin işi değildir. Altyapı, uygulama, ağ, hizmet masası, değişiklik yönetimi ve tedarikçiler aynı hizmetin kullanılabilirliğini etkiler. Kullanılabilirlik yönetimi bu parçalar arasındaki ortak hedefi ve sorumluluk sınırlarını netleştirir.

Hizmet seviyesi anlaşmasındaki kullanılabilirlik taahhüdü çoğunlukla bu çalışmanın girdisidir. Yönetim işi hedeften geriye doğru kurar: tasarımda hangi artıklık gerekir, işletmede hangi izleme ve bakım düzeni gerekir, kesinti anında hangi toparlanma yolu hazır olmalıdır.

Hedefi nasıl belirlersiniz?

Hedef konuşmasını iş birimleriyle yapın. Hangi iş süreci bu hizmete dayanıyor, hangi saatlerde kritik, kesintinin pratik sonucu ne? Bir ay sonu kapanış sistemi ile bir iç bilgi portalının kesinti toleransı aynı olmaz; her birine aynı hedefi vermek ya gereksiz yatırım ya da yetersiz koruma doğurur.

Her hizmet için şu soruları yanıtlayın: hizmet hangi zaman diliminde mutlaka açık olmalı, kısmi çalışma kabul edilebilir mi, bakım pencereleri nasıl ve ne zaman duyurulur, kesintinin işe maliyeti nedir? Maliyet tahmini kaba bile olsa, hedefi gerekçelendirir.

Hedefi hizmet düzeyinde yazın ve kullanılabilirliğin nasıl ölçüleceğini aynı yerde tanımlayın: hangi zaman dilimi hesaba katılır, planlı bakım dışarıda mı, kısmi bozulma kesinti sayılır mı, ölçüm hangi noktadan yapılır? Ölçüm tanımı yazılmamış hedef, ay sonunda tartışma çıkarır.

Hedefe giden maliyeti de hesaba katın. Daha yüksek kullanılabilirlik, artıklık, yedek bileşen, daha sıkı izleme ve daha disiplinli değişiklik yönetimi demektir. Her artış üstel biçimde pahalılaşır; iş etkisi yatırımı haklı çıkarmıyorsa hedef düşürülmelidir.

Şekil 1

Hedef, iş ihtiyacından bileşen düzeyine doğru iner

  1. İş ihtiyacıHangi süreç hizmete dayanır, kesinti ne kaybettirir?
  2. Hizmet hedefiAnlaşılan süre ve ölçüm tanımıyla yazılan kullanılabilirlik düzeyi.
  3. Bileşen gereksinimiHer bileşenin dayanıklılığı, artıklığı ve onarım süresi.
  4. Ölçüm ve raporGerçekleşenin hedefle karşılaştırıldığı düzenli görünüm.
Kaynak: Sayfa içeriğiMindset Institute

Ölçüm: MTBF, MTRS ve kesinti süresi

Kullanılabilirlik oranı, anlaşılan hizmet süresinden kesinti süresini çıkarıp anlaşılan hizmet süresine bölerek hesaplanır. Aynı oran bileşen düzeyinde MTBF bölü MTBF artı MTRS biçiminde de ifade edilir. Bu ifadeler aynı gerçeği anlatır: kullanılabilirlik hem kesintinin ne kadar sık hem ne kadar uzun sürdüğüne bağlıdır.

Bu yüzden tek bir yüzdeye bakmak yanıltıcıdır. Seyrek ama uzun süren kesintiler ile sık ama kısa kesintiler aynı oranı verebilir, oysa kullanıcıya etkileri farklıdır. MTBF kesintilerin sıklığını, MTRS ise toparlanma hızını gösterdiği için hangi kolu iyileştireceğinizi söyler. MTBF düşükse arızanın kaynağına, MTRS yüksekse tespit, teşhis ve onarım zincirine odaklanın.

Veriyi olay kayıtlarından türetin. Kesintinin başladığı an, tespit anı, hizmetin döndüğü an ve etkilenen hizmet kayıtta bulunmalıdır. Başlangıç zamanını izleme sistemi otomatik damgalıyorsa, kullanıcı bildirimi beklenerek tespit edilen kesintilerde süre olduğundan kısa görünür. Planlı bakım ile plansız kesintiyi ayrı alanlarda tutun.

Kullanılabilirlik yönetiminde yıllık döngü

Kullanılabilirlik yönetimi tek seferlik bir proje değil, tekrar eden bir döngüdür. Hedefler gözden geçirilir, ölçümler toplanır, kesinti kayıtları nedene göre analiz edilir, iyileştirme önerileri üretilir, onaylananlar plana alınır ve sonuç yeniden ölçülür.

Döngünün girdileri; olay ve problem kayıtları, değişiklik kayıtları, izleme verisi ve hizmet seviyesi raporlarıdır. Çıktıları ise güncel hedefler, iyileştirme planı ve yönetime sunulan kullanılabilirlik raporudur. Olay yönetimi ile problem yönetimi bu döngünün en önemli ortaklarıdır: olay yönetimi hizmeti hızla döndürür, problem yönetimi aynı kesintinin tekrarını önler.

Döngüye yeni hizmetleri ve önemli değişiklikleri erken katın. Yeni bir hizmetin tasarım aşamasında kullanılabilirlik gereksinimleri sorulmazsa, sonradan artıklık eklemek çok daha pahalıdır. Büyük bir değişiklikten önce 'bu değişiklik kullanılabilirliği nasıl etkiler' sorusunun sorulması, değişiklik onay sürecinin basit bir maddesi olabilir.

Şekil 2

Kullanılabilirlik, ölçüp analiz edip iyileştirerek sürdürülür

  1. Hedefi gözden geçirİş ihtiyacı ve ölçüm tanımı güncel mi?
  2. Ölçümü toplaKesinti kayıtları ve izleme verisi birleştirilir.
  3. Nedene göre analiz etTekrarlayan neden ve uzun toparlanmalar ayrıştırılır.
  4. İyileştirmeyi planlaYatırım, süreç ve tasarım değişiklikleri sıralanır.
  5. Sonucu yeniden ölçDeğişikliğin etkisi bir sonraki ölçümle doğrulanır.
Kaynak: Sayfa içeriğiMindset Institute

Örnek senaryo: ödeme onay uygulaması

Kurgusal bir kurumda ödeme onay uygulaması, ay sonu yoğunluğunda finans ekibinin ana çalışma aracıdır. İş tarafı, ay sonu günlerinde kesintiyi neredeyse kabul etmez; ay ortasında ise kısa bakım kabul edilebilir. Bu talepler, tek bir düz hedef yerine zamana göre farklılaşan bir hizmet tanımına dönüştürülür.

Ölçüm sonucu bir ay boyunca kısa süreli ama sık kesinti gösteriyor. MTBF düşük, MTRS makul. Olay kayıtları incelendiğinde kesintilerin çoğunun veritabanı bağlantı havuzunun dolmasından kaynaklandığı görülüyor. Çözüm yeni bir artıklık değil, havuz ayarının ve uyarı eşiğinin düzeltilmesi ve problem kaydı açılmasıdır.

Sonraki ay ölçümü iyileşmeyi doğrular, ancak bir değişiklik penceresindeki hatalı dağıtım uzun bir kesinti üretir. Bu kez MTRS öne çıkar: geri dönüş planı hazır olmadığı için toparlanma uzamıştır. Kök neden analizi, değişiklik yönetiminde geri dönüş adımı zorunluluğunu ve dağıtım sonrası doğrulama kontrolünü getirir. Örnek, aynı kullanılabilirlik hedefinin farklı dönemlerde farklı iyileştirme alanlarını işaret edebildiğini gösterir.

Sık yapılan hatalar

En yaygın hata, hedefi iş etkisinden bağımsız ve herkese aynı biçimde koymaktır. Bu, kritik olmayan hizmetlere gereksiz yatırım, kritik hizmetlere ise yetersiz koruma getirir.

İkinci hata, kullanılabilirliği bileşen düzeyinde ölçüp hizmet düzeyini görmemektir. Sunucular çalışıyor görünürken kullanıcı hizmete erişemiyor olabilir. Ölçümü kullanıcı deneyimine yakın bir noktadan, örneğin yapay işlem denemeleriyle, tamamlayın.

Üçüncü hata, planlı bakımı ya da kısmi bozulmayı tanımsız bırakmaktır. Taraflar ay sonunda farklı hesaplar sunar. Dördüncü hata, ölçümü yalnız raporlamak ve nedene göre analiz etmemektir; rapor ile iyileştirme arasındaki bağ kurulmazsa sayılar değişmez. Son olarak, kesinti zamanını kullanıcı bildirimine göre kaydetmek süreleri olduğundan kısa gösterir; izleme sistemindeki ilk tespit zamanı esas alınmalıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

ITIL 4 Foundation eğitiminin temel kavramlar, hizmet değer sistemi ve genel yönetim uygulamaları başlıkları, hizmetin değeri, kesintinin etkisi ve sürekli iyileştirme kavramlarını ortak dille anlamak isteyen BT operasyon ve hizmet masası çalışanları için başlangıç noktasıdır.

Kullanılabilirlik ve sürekliliği hizmet portföyü düzeyinde yönetecek olanlar için ITIL 4 Intermediate programının hizmet oluşturma, sunma ve destekleme ile yüksek hızlı BT uygulamaları modülleri, tasarım ve işletme kararlarını bir arada görmeye yardımcı olur.

İlgili Mindset programı

ITIL® 4 Foundation Eğitimi

Sık sorulanlar

Sık sorulan sorular

Kullanılabilirlik yönetimi ile süreklilik yönetimi aynı şey mi?

Hayır. Kullanılabilirlik yönetimi günlük işletmede hizmetin çalışır kalmasını hedefler. Süreklilik yönetimi ise büyük bir felaket ya da uzun süreli kayıp sonrasında hizmetin kurtarılmasını planlar. Bunlar birbirini tamamlar, farklı olay ölçeklerini ele alır ve aynı hizmet hedeflerine bağlıdır.

Kullanılabilirlik yüzdesine bakmak yeterli mi?

Tek başına yetmez. Seyrek ama uzun kesintiler ile sık ama kısa kesintiler aynı oranı verebilir ama kullanıcıya etkileri çok farklıdır. MTBF ve MTRS gibi sıklık ve süre göstergelerini, kesinti nedeni ve iş etkisi ile birlikte okumak gerekir.

MTRS ile MTTR arasındaki fark nedir?

Bu kısaltmalar toparlanma süresini anlatır, ancak kurumdan kuruma tanım değişir. MTRS genellikle kesintinin başlangıcından hizmetin dönüşüne kadar geçen süredir; MTTR ise bazen yalnız onarım aşamasını kapsar. Raporlamadan önce kurumun tanımını yazılı hale getirmek tutarlılığı sağlar.

Küçük bir BT ekibi nereden başlamalı?

En kritik birkaç hizmeti seçin, her biri için iş tarafıyla kesinti toleransını konuşun, ölçüm tanımını yazın ve olay kayıtlarında kesinti başlangıç ve bitişini düzenli tutun. Birkaç ay sonra elinizde nedene göre okunabilir bir veri olur ve yatırım önceliği netleşir.

Bulut hizmeti kullanmak kullanılabilirlik sorununu çözer mi?

Altyapı artıklığının bir kısmını sağlayıcıya devredersiniz, ama uygulama tasarımı, yapılandırma, değişiklik hataları ve sağlayıcıya bağımlılık sizin sorumluluğunuzda kalır. Hizmet seviyesi taahhütlerini ve kendi uygulamanızın dayanıklılığını ayrı ayrı değerlendirmek, sağlayıcının kesinti geçmişini de incelemek gerekir.

Kullanılabilirlik Yönetimi: Hedef, Ölçüm ve İyileştirme