Mühendislik Ekiplerinde Bus Factor: Bilgi Riski Nasıl Azaltılır

Bir sisteme dair kritik bilgi tek bir kişinin kafasında toplandığında o kişi tek hata noktasına dönüşür. İşte bus factor riski budur. Asıl can yakan kısım bu bilginin çoğu zaman yazıya dökülmemiş olmasıdır. Ödeme akışları, dolandırıcılık tespitinin incelikleri ve herkesin güvendiği deploy adımları mühendisle birlikte kapıdan çıkar; toparlanma ise tam bir olay patlak verdiği anda yavaşlar. Kritik yollardan başlayın: önce onları belgeleyin, sonra bu dokümantasyonu sistemi kurmamış birine verip nerede takıldığına bakın.

Kazara Oluşan Tek Hata Noktası#

“Bus factor” ekip dayanıklılığını ölçmenin biraz karamsar bir yolu: Projeniz sürdürülemez hale gelmeden önce kaç kişinin ayrılması gerekir? Bu sayı bir ise konumunuz tehlikelidir.

Mühendisler bilgiyi bilerek kendine saklamaz. Çoğu zaman onlar yoğun dönemde öne çıkan, ekibin geri kalanı başka acil işlerle uğraşırken özellikleri yetiştirmek için geç saatlere kadar çalışan kişilerdir. En çok yükünü taşıdıkları sistemlerin yazılı kaydı genelde en zayıf olanıdır ve kimse böyle bir karar vermeden farkında olmadan tek hata noktasına dönüşürler.

Bilgi Nerede Yoğunlaşır#

Veritabanı Fısıldayıcısı#

Çoğu ekipte veritabanının her tuhaflığını anlayan biri vardır: müşteri tablosunun neden 47 indeksi olduğunu, o gizemli stored procedure’ün aslında ne yaptığını ve yedek işinin neden tam gece 3:17’de çalıştığını bilir (genellikle bir zaman dilimi hatası ya da o dönem mantıklı gelen bir geçici çözümle ilgili bir hikâye vardır). Bu kişi ayrıldığında veritabanı sorun giderme işi çok daha zorlaşır. Ekipler, müşteri aramasının yoğun trafikte neden aniden 30 saniye sürdüğünü anlamaya çalışırken EXPLAIN sorguları çalıştırır; uzman hâlâ buradayken daha fazla soru sorulmuş olmasını dilerler.

Aynı biçim deployment tarafında ve üçüncü parti entegrasyonlarda da karşınıza çıkar. Biri, birden fazla AWS hesabına yayılan, manuel sertifika yenilemeleri ve dikkatle zamanlanmış veritabanı migrasyonları içeren 23 adımlık bir sürümde ustalaşmıştır; net biçimde anlatması çok karmaşık geldiği için hiç yazıya dökülmemiştir ve yıllardır sorunsuz işlemektedir. Bir başkası, A Satıcısının webhook’unun ara sıra çift event gönderdiğini, B Satıcısının rate limiting’inde belgelenmemiş bir “burst mode” bulunduğunu ve C Satıcısının sandbox ortamının production API’siyle hiç benzeşmediğini bedelini ödeyerek öğrenmiştir. İki bilgi de o kişiye ulaşılamayana ve bugün acil bir güvenlik yaması çıkması gerekene kadar görünmez kalır. O noktada hangi davranışın kasıtlı tasarım, hangisinin etrafından dolaşılacak bir tuhaflık olduğunu tahmin etmeye çalışırsınız.

Olayı Atlatmayı Sağlayan Dokümantasyon#

Aşağıdaki alışkanlıklar, dokümantasyonu bürokratik bir yüke dönüştürmeden bilgi yoğunlaşmasını azaltır.

Önce Hangi Yollar Yazılır#

Her şeyi tek seferde belgelemeye çalışmak ekipleri bunaltma ve çok geçmeden bayatlayan dokümanlar üretme eğilimindedir. Daha etkili bir yaklaşım, önce bir sistemin kritik yollarını belirlemektir.

“Acil düzeltme testi” bu noktada işe yarar: Herkes toplantıdayken bu sistem bozulsa, birinin onu hızlıca tekrar çalışır hale getirmek için neyi bilmesi gerekirdi? O bilgi ilk belgelenen olur; çünkü uzman ulaşılamazken en çok ihtiyaç duyulacak bilgi odur.

/**
 * Ödeme İşleme Kritik Yolu
 * 
 * Neden var: her müşteri siparişinin ana gelir yolu
 * Bağımlılıklar: Stripe webhook, dolandırıcılık servisi, envanter sistemi
 * SLA: %99.9 uptime, <5s yanıt süresi
 * Eskalasyon: #payments-urgent Slack kanalı
 * 
 * Bilinen Tuzaklar:
 * - Stripe webhook'ları sıra dışı gelebilir
 * - Dolandırıcılık servisi 2s timeout, fail open
 * - Envanter kilitleri 10 dakika sonra bitiyor
 */
class PaymentProcessor {
  async processPayment(paymentIntent: PaymentIntent) {
    // Aşırı satışı önlemek için envanter rezervasyonuyla başla
    const inventoryLock = await this.reserveInventory(paymentIntent.items)
    
    try {
      // Dolandırıcılık kontrolü 2 saniyede tamamlanmak ZORUNDA
      const fraudResult = await this.fraudService.check(paymentIntent, {
        timeout: 2000,
        fallback: 'APPROVE' // Meşru satışları bloklamamak için fail open
      })
      
      if (fraudResult.action === 'BLOCK') {
        await this.releaseInventory(inventoryLock)
        throw new PaymentBlockedError(fraudResult.reason)
      }
      
      // Stripe ile işle
      const result = await this.stripe.confirmPayment(paymentIntent.id)
      
      // Önemli: Başarıda bile envanter kilidini her zaman serbest bırak
      await this.releaseInventory(inventoryLock)
      
      return result
    } catch (error) {
      // Kritik: Her hatada envanteri her zaman serbest bırak
      await this.releaseInventory(inventoryLock)
      throw error
    }
  }
}

Mimari Karar Kayıtları#

ADR’ler mimari kararların ardındaki “neden”i kayıt altına almanın en pratik yoludur. Tipik bir tetikleyici: bir sistemde neden beş farklı önbellekleme katmanı olduğunu anlamaya çalışarak üç ay geçirmek (her biri farklı ölçek noktalarında belirli bir performans problemini çözüyormuş).

İşe yarayan bir şablon:

# ADR-15: Event-Driven Order Processing

## Status
Kabul edildi

## Context
Monolitik sipariş işlememiz darboğaza dönüşüyordu:
- Yoğun trafikte sipariş oluşturma 15+ saniye sürüyor
- Ödeme hataları envanter sorunlarına yayılıyor
- Yeni sipariş tipleri eklemek zor (abonelikler, hediyeler)

## Decision
AWS EventBridge kullanarak event-driven mimari uygula:
- Siparişler her yaşam döngüsü aşamasında event yayar
- Ayrı servisler ödeme, envanter, bildirimleri halleder
- Başarısız event'ler exponential backoff ile yeniden denenir

## Consequences
### Positive
- Sipariş oluşturma artık <2 saniye
- Servisler bağımsız ölçeklenebilir
- Yeni sipariş tipleri eklemek kolay

### Negative
- Eventual consistency (müşteriler bayat veri görebilir)
- Servis sınırları arasında debug etmek daha zor
- Bakımı yapılacak daha fazla altyapı

### Mitigations
- Gerçek zamanlı sorgular için sipariş durumu endpoint'i eklendi
- X-Ray ile distributed tracing uygulandı
- Ortak EventBridge schema registry oluşturuldu

Belirtiden Başlayan Runbook’lar#

Bir runbook yalnızca güncel kaldığı sürece işe yarar. İki yıl önce doğru olan bir runbook, nöbetteki mühendisi çıkmaz bir yola sokar; bu da hiç olmamasından kötüdür.

Runbook’u nöbetteki mühendisin ilk gördüğü belirtinin etrafında kurgulayın:

# Runbook: "Ödemeler başarısız oluyor"

## Belirtiler
- #payments-monitoring'den Slack uyarıları
- Reddedilen kartlarla ilgili müşteri şikayetleri
- Gelir dashboard'unda düşüş

## Araştırma Adımları

### 1. Stripe Dashboard'u Kontrol Et (2 dakika)
- Giriş: https://dashboard.stripe.com/company/payments
- Yüksek red oranları ya da servis sorunları ara
- Stripe sorun gösteriyorsa → #stripe-incidents'a escale et

### 2. Ödeme Servisi Sağlığını Kontrol Et (3 dakika)
```bash
# Servis durumu
kubectl get pods -n payments

# Son hatalar
kubectl logs -f deployment/payment-service | grep ERROR | tail -20

# Veritabanı bağlantısı
kubectl exec -it deployment/payment-service -- npm run healthcheck
```

### 3. Dolandırıcılık Servisini Kontrol Et (2 dakika)
Dolandırıcılık kontrolü fail open çalışır; servisin çökmesi tek başına ödemeleri reddettirmez. Asıl kötü senaryo servisin yavaşlamasıdır: her ödeme önce 2s timeout'u baştan sona bekler.
```bash
# Dolandırıcılık servis durumu  
curl https://fraud-api.internal/health

# Çökmüşse geçici olarak dolandırıcılık kontrollerini kapat:
kubectl set env deployment/payment-service FRAUD_CHECK_ENABLED=false
# Dolandırıcılık servisi geri geldikten sonra tekrar açmayı unutma!
```

## Rollback Prosedürleri
Başka her şey başarısız olursa ödemeleri yedek işlemciye yönlendir:
```bash
kubectl set env deployment/payment-service PRIMARY_PROCESSOR=backup
```
Beklenen gelir etkisi: %2.5 daha yüksek işlem ücretleri
Yedekte maksimum süre: finans eskalasyonundan önce 4 saat

Dokümanı Bir Yabancıya Vermek#

Kimsenin test etmediği bir dokümantasyon, bir yabancının neyi anlayacağına dair bir tahminden ibarettir. Bilgi doğrulama egzersizleri bu tahmini, olay anında güvenebileceğiniz bir şeye dönüştürür.

Her çeyrek kritik bir sistem seçin ve onu inşa etmemiş birinden yalnızca dokümantasyonu kullanarak deploy etmesini, debug etmesini ya da değiştirmesini isteyin. Boşluklar hızla ortaya çıkar.

// Ödeme Sistemi için Bilgi Doğrulama Checklist'i

interface ValidationTest {
  scenario: string
  timeLimit: string
  successCriteria: string
  tester: string // Onu inşa etmemiş biri
}

const validationTests: ValidationTest[] = [
  {
    scenario: "Ödeme servisini sıfırdan staging'e deploy et",
    timeLimit: "30 dakika",
    successCriteria: "Servis tüm health check'leri geçer",
    tester: "frontend-engineer"
  },
  {
    scenario: "Test ödemelerinin neden reddedildiğini debug et",
    timeLimit: "15 dakika", 
    successCriteria: "Kök nedeni belirle ve düzelt",
    tester: "devops-engineer"
  },
  {
    scenario: "Yeni ödeme yöntemi ekle (Apple Pay)",
    timeLimit: "2 saat",
    successCriteria: "Development'ta çalışan entegrasyon",
    tester: "mobile-engineer"
  }
]

Yoğunlaşmayı Ölçmek#

Sahipliği Commit Geçmişinden Okumak#

Sürüm kontrol geçmişiniz sahiplik sorusunun çoğunu zaten yanıtlıyor:

# Kritik dosyalar için katkı istatistikleri
git log --format='%an' --follow app/services/payment-processor.ts | 
  sort | uniq -c | sort -nr

# Sonuç bilginin yoğunlaşıp yoğunlaşmadığını gösterir:
#  47 sarah.smith@company.com  # Kırmızı bayrak - bir kişi %80'ini sahipleniyor
#  8 mike.jones@company.com
#  3 lisa.wong@company.com
#  1 alex.kim@company.com

Kaba bir kural olarak, kritik bir dosyadaki commit’lerin %70’inden fazlası tek kişideyse bu, üzerine gidilmesi gereken bir bus factor sinyalidir.

Dokümantasyon Kapsamı#

Dokümantasyon kapsamını test kapsamı gibi takip ediyorum:

interface SystemDocumentation {
  system: string
  hasRunbook: boolean
  hasArchitecture: boolean
  hasDeployGuide: boolean
  lastUpdated: Date
  knowledgeScore: number // Doğrulama testlerine göre 0-100
}

const systemDocs: SystemDocumentation[] = [
  {
    system: "payment-processor",
    hasRunbook: true,
    hasArchitecture: true,
    hasDeployGuide: true,
    lastUpdated: new Date("2024-08-15"),
    knowledgeScore: 85
  },
  {
    system: "fraud-detection",
    hasRunbook: false,  // Kırmızı bayrak
    hasArchitecture: true,
    hasDeployGuide: true,
    lastUpdated: new Date("2024-06-01"), // Kırmızı bayrak - 15+ aylık
    knowledgeScore: 45  // Kırmızı bayrak
  }
]

// Herhangi bir kritik sistem 70'in altında puan alırsa uyar
const riskySystems = systemDocs
  .filter(doc => doc.knowledgeScore < 70)
  .map(doc => doc.system)

Altyapı Kodunun Taşıdığı Bağlam#

Kendi bağlamını taşıyan altyapı kodu, bütün bir kabile bilgisi sınıfını ortadan kaldırır:

# terraform/payment-processor.tf
resource "aws_ecs_service" "payment_processor" {
  name  = "payment-processor"
  cluster  = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.payment_processor.arn
  desired_count  = 3

  # Bilgi notları
  tags = {
    Owner  = "payments-team"
    Runbook  = "https://wiki.company.com/payments/runbook"
    SlackChannel  = "#payments-urgent"
    SLA  = "99.9-percent"
    RevenueImpact  = "critical"
    LastIncident  = "stripe-timeout"
  }

  # Kendi kendini belgeleyen alarmlar
  health_check_grace_period_seconds = 60
  
  deployment_configuration {
    maximum_percent  = 200
    minimum_healthy_percent = 100
    # Not: bir olaydan sonra deploy sırasında %100 sağlıklı tutuyoruz;
    # o olayda %50 ödeme hatalarına yol açmıştı
  }
}

Bütçeyi Almak#

Bu işe bütçe ayırtmak genellikle bir rakam ister ve akla ilk gelen yöntem günlük geliri, uzmanın yerine birini bulmanın süreceği ayla çarpmaktır. Bu model incelemeye dayanmaz; bir ayrılık nadiren bir sistemin gelirini aylarca sıfıra indirir. Bunu fark eden yönetici, söylediğiniz geri kalan her şeyi de kulak arkası eder.

Savunulabilir rakamlar zaten topladığınız rakamlardır. Benzer bir pozisyon için son işe alma ve uyum süresi, runbook’u olan ve olmayan sistemlerdeki ortalama toparlanma süresi, her kritik dosyadaki commit dağılımı; üçü de kendi kurumunuzda ölçülebilir. Bu üçünü sunun ve sonucu okuyan kişi çıkarsın.

Çürüme, Hacim ve Direnç#

Dokümantasyon yazıldığı gün eskimeye başlar; bu yüzden güncelleme değişiklikle birlikte yol almalıdır. Bu kuralı koymanın en ucuz yeri, pull request’in “done” tanımıdır. Ters yöndeki hata hacimdir ve en az onun kadar yaygın: yeterince çok sayfa yazın, kimse aradığı sayfayı bulamaz. Yazılanları kritik yollarla ve tekrar eden senaryolarla sınırlamak, seti aranabilir kalacak kadar küçük tutar.

Üçüncü tuzak süreçtir. Üst üste yeni tören ekleyen bir bilgi programı, korumak istediği işi yavaşlatır; o yüzden tek bir pratikle başlayın, neyin değiştiğine bakın ve değerini gösteremeyeni bırakın. Kalan sorunlar insana dair. Benimsenmeden dayatılan bilgi transferi kırgınlık ve içi boş dokümanlar üretir; bazı mühendisler de gerçekten vazgeçilmez olmayı ister. İkisi de aynı kaldıraca yanıt verir: öğretmek terfi kriterlerinde yer almalı.

İşi Ayakta Tutan Teşvikler#

Kimi Kutluyorsunuz#

Takdir, davranışı herhangi bir politika belgesinden daha çok şekillendirir. Çoğu ekipte görünür övgüyü hafta sonu kurtarma operasyonu alır; runbook’u sayesinde orijinal ekipte hiç yer almamış bir meslektaşın bir sonraki olayı tek başına çözdüğü mühendisin adı ise geçmez. Bunun düzeltileceği yer performans değerlendirmeleri ve terfi kriterleridir.

Netflix’in Chaos Monkey’i aynı fikri altyapıya taşır: production instance’ları rastgele ölüyorsa müdahale tek bir kişiye ulaşmaya bağlı kalamaz, dolayısıyla dokümantasyon ve otomasyon nöbette kim varsa ona yetecek kadar iyi olmak zorundadır. Google’ın SRE pratiği ise aynı yere kültür tarafından varır: hata bütçeleri ve suçlamasız postmortem’ler vurguyu paylaşılan operasyonel bilgiye taşır.

Öğrenme Yolları#

Bilgi paylaşımını kariyer gelişimi olarak yapılandırın:

interface LearningPath {
  skill: string
  currentExpert: string
  learners: string[]
  milestones: Milestone[]
}

interface Milestone {
  description: string
  timeframe: string
  validationCriteria: string
}

const deploymentMastery: LearningPath = {
  skill: "Production Deployment",
  currentExpert: "sarah.smith",
  learners: ["mike.jones", "lisa.wong"],
  milestones: [
    {
      description: "5 production deployment'ı gölge olarak izle",
      timeframe: "2 hafta",
      validationCriteria: "Her adımı ve amacını açıklayabilir"
    },
    {
      description: "Gözetim altında deployment'a liderlik et",
      timeframe: "1 hafta",
      validationCriteria: "Yönlendirme olmadan başarıyla deploy eder"
    },
    {
      description: "Deployment olayını bağımsız ele al",
      timeframe: "1 ay",
      validationCriteria: "Eskalasyon olmadan deployment sorununu çözer"
    }
  ]
}

İşe Yarayan Araçlar#

Buradaki araçların hiçbiri sıra dışı değil. Grafana ve Prometheus sistem durumunu herkesin okuyabildiği bir dashboard’a taşır. PagerDuty on-call rotasyonunu zorunlu kılar ve ekip planlasa da planlamasa da operasyonel bilgiyi yayar; Datadog ise metrik, log ve trace’leri o kadar yakın tutar ki bir incelemeye “cevap hangi araçta” sorusuyla başlamazsınız. Yazma tarafında Confluence ya da Notion sürüm geçmişi verir, Mermaid mimari diyagramları sürüm kontrolünde tutar, GitHub wiki ise dokümanı anlattığı kodun yanı başında saklar.

Ekiplerin genelde durduğu yer doğrulama araçlarıdır; oysa geri kalanın işe yarayıp yaramadığına karar veren kısım orasıdır. Gameday’ler ekibi simüle edilmiş bir hatanın içinden geçirir. Wheel of Misfortune oturumu geçmiş bir olayı, sıcak koltukta farklı biri varken yeniden oynatır. Dokümantasyon sprint’leri ise başka türlü hiç takvime girmeyen yazma işine zaman ayırır.

Nereden başladığınız, somut bir şeyle başlamanız kadar önemli değil. İnsanların gerçekten yazdığı runbook, son olayda onları kurtaracak olandır; oradan başlayın. Doğrulama kontrolünü insanın unutamayacağı bir yere koyun: takvime bağlı bir egzersiz, bir CI işi ya da bir inceleme kapısı. Çünkü dokümantasyon sessizce eskir. Akran öğrenmesi tepeden inme zorunluluktan daha uzağa yayılır; mühendislere birbirine öğretmek için bir sebep verin ve biri kendisinin inşa etmediği bir sistemde sorun çözdüğünde bunu ekibin göreceği yerde söyleyin.

Bus factor’ü güvenlik ve performansla aynı ağırlıkta bir iş sürekliliği meselesi olarak ele alın; iş o zaman ertelenmek yerine bütçelenmeye başlar. Bu varsayılan, çökmesi gerçek para kaybettiren ve bilgisi üç kişiden azında duran her sistem için geçerlidir. Kısa ömürlü iç araçlar istisnadır; atılacağı belli olan bir araçta kritik yol insanların kafasında kalabilir.

Kaynaklar#

• Bus Factor In Practice (arXiv:2202.01523) (yeni sekmede açılır) - 269 mühendisle yürütülen deneysel çalışma; kod inceleme, toplantı ve sürüm kontrolü verilerini birleştiren çok modlu bir bus factor tahmin algoritması sunar.
• Bus Factor Explorer (arXiv:2403.08038) (yeni sekmede açılır) - Açık kaynak depolarda bus factor hesaplama aracı ve metodolojisi; bilgi yoğunlaşma riskinin boylamsal analizi.
• DORA Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - Binlerce ekip üzerinde yürütülen, yazılım teslimatı ve operasyonel performansa odaklanan yıllık anket araştırması.
• Generative Organizational Culture - DORA Capabilities (yeni sekmede açılır) - DORA’nın Westrum tipolojisini ve bilgi akışının yazılım teslimat performansını nasıl öngördüğünü ele alan sayfa.
• Google SRE Book (yeni sekmede açılır) - Google’ın paylaşılan operasyonel sahiplik, hata bütçeleri ve suçlamasız postmortem anlatımı; çevrimiçi ücretsiz okunabilir.
• Netflix Chaos Monkey (yeni sekmede açılır) - Production instance’larını rastgele sonlandıran araç ve etrafında kurulan dayanıklılık pratikleri.
• Martin Fowler - Conway Yasası (yeni sekmede açılır) - Conway Yasası ve Ters Conway Manevrası; bilgi silolarının mimari sınırları nasıl yansıttığını açıklar.
• Accelerate - IT Revolution Press (yeni sekmede açılır) - Forsgren, Humble ve Kim; teslimat performansını öngören yetkinlikler ve bunların arkasındaki kültür ile bilgi paylaşımı pratikleri.