Yazılım

Risk Yönetiminde Otobüs Faktörü

Yazılım mühendisliğinde risk yönetimi yaklaşımlarından biri de “Bus Factor” dür. Dilimize otobüs faktörü olarak çevrilebilecek bu yaklaşım bir projede/operasyonda kilit roldeki çalışanların kaçının otobüs çarpması, yani işten ayrılması durumunda projenin/operasyonun telafisi imkansız veya zor zararlar göreceğini ölçmek için kullanılır.

Ölçü birimi doğrudan kişi sayısıdır ve ölçmek için en sık aşağıdaki yöntemler kullanılır.

  1. Bilgi Dağılım Matrisi
    • En yaygın kullanılan ölçüm yöntemlerinden biridir.
    • Satırlar: Kritik iş süreçleri, domain bilgileri veya kod modülleri
    • Sütunlar: Ekip üyeleri
    • Hücreler: Uzmanlık seviyeleri (1-5 arası)
    • Hesaplama : Bir satırda 3 ve üzeri puan alan sadece bir kişi varsa o süreç için bus factor 1 dir. Genel proje puanı en düşük puanlı kritik sürece eşittir.
  2. Kod Sahipliği Analizi
    • Her bir dosyanın veya modülün kim tarafından yazıldığına bakılır
    • Dosyaların %50 sinden fazlası sadece bir kişi tarafından yazıldıysa o kişi ana bilgi sahibi olarak kabul edilir.
    • O kişi sistemden çıkarıldığında projenin yüzde kaçının sahipsiz kalacağı hesaplanır.
  3. Bağımlılık ve Yanıt Süresi Analizi
    • Eğer bir soruya cevap almak veya bir sorunu çözmek tek bir kişiye çıkıyorsa operasyonel bus factor ölçülmelidir.
    • Ölçüm metriği x kişi tatildeyken çözülemeyen ticket sayılarının oranıdır.
  4. Basit Kişi Sayısı Yaklaşımı
    • En yaygın ve ilkel ölçüm metodudur
    • Bir sistem veya modül için şu soruya cevap aranır ; “Bu işi gerçekten bilen kaç kişi var?”
  5. Ticket / Incident Ownership Analizi
    • ITSM araçlarının çıktıları kullanılır
    • Kim hangi kayıtları çözüyor incelenir
    • Kritik kayıtlar hep aynı kişiye mi adresleniyor ?
    • Kritik kayıtlardan kaçılıyor mu kaçılmak zorunda mı kalınıyor analiz edilir.
  6. Dokümantasyon ve Runbook Skoru
    • Bilgi kişide mi sistemde mi saklı kontrol edilir?
    • Güncel doküman var mı ?
    • RunBook var mı?
    • On-Call dışı biri tarafından çözebilir mi ?
    • Modül veya kritik süreç bu sorular ile puanlanır.
    • Toplam skor düşükse BF düşük demektir.
  7. Simülasyon / Tatbikat Yöntemi
    • En gerçekçi ama uygulanması zor yöntemdir
    • Kritik kişi bir iki hafta bilinçli olarak devreden çıkarılır
    • İşler kime düşüyor gözlemlenir
    • Aksıyorsa nerede aksama var ve kimden destek istendiği gözlemlenir
    • Sistem duruyorsa BF 1 demektir
    • Yavaşlıyorsa 2
    • Sorunsuz devam ediyorsa 3 demektir.
  8. Karma / Olgun Organizasyon Yaklaşımı
    • Code + Ticket + Knowladge + Dokümantasyon birlikte ölçülür
    • En zayıf halka BF i belirler

Bus Factor Puanlama

  • 1 Kişi – BF çok riskli
  • 2-3 Kişi – BF Orta riskli
  • 4+ Kişi – Görece güvenli

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu