Yıldız Geliştiriciniz İstifa Ettiğinde: Mühendislik Ekiplerinde Bus Factor Yönetimi

Şöyle bir senaryo düşünün: Büyük bir ürün lansmanının tam ortasındasınız, her şey yolunda gidiyor ve sonra tüm ödeme sistemini tasarlayan baş mühendisisiniz iki haftalık istifasını veriyor. Rekabet yasağı nedeniyle hemen işten ayrılıyor ve bir rakibe geçiyor.

Aniden fark ediyorsunuz ki paranın uygulamanızda nasıl aktığı, dolandırıcılık tespitinin nasıl çalıştığı ve o bir veritabanı sorgusunun neden tam olarak 47 saniyede tamamlanması gerektiği bilgisi tamamen bir kişinin kafasında yaşıyor. Bus factor problemiyle tanışın.

Bus Factor Gerçeği

“Bus factor” ekip dayanıklılığını ölçmenin biraz karanlık mizahla yapılan bir yolu: Projeniz duraksın diye kaç takım üyesinin otobüs çarpması (ya da gerçekte şirketten ayrılması) gerekiyor? Bu sayı bir ise, başınız dertte.

Bu senaryoyu kabul etmek istemeyeceğim kadar çok kez yaşadım. Otobüs kısmını değil - bilgi kaybı kısmını. Temel sisteminizi tek başına inşa eden dahiyane mühendis “yeni fırsatları keşfetmek” istediğine karar veriyor ve aniden günlük milyonlarca lira geliri işleyen 50.000 satır belgesiz kodla karşı karşıya kalıyorsunuz.

Sorun bu mühendislerin bencil ya da gizli saklı olması değil. Genellikle son teslim tarihleri yaklaştığında öne çıkan, takımın geri kalanı başka önceliklerle meşgulken gece gündüz çalışarak özellikleri teslim eden kahramanlardır. Ama bilgi transferi olmayan kahramanlık kırılganlık yaratır. Kritik yol dokümantasyonu ve pair programming rotasyonları bu riski proaktif olarak azaltır. Panik testi: Sistem yönetim kurulu toplantısı sırasında bozulsa 30 dakikada neyi bilmen gerekir? O dokümante edilir ilk.

Bilgi Konsantrasyonunun Anatomisi

Bus factorların kritik riskler haline geldiği en yaygın kalıpları anlatayım:

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

Her ekipte vardır - müşteri tablosunun neden tam 47 indeksi olduğunu, o gizemli stored procedure’ün ne yaptığını ve yedek işinin neden tam 3:17’de çalıştığını bilen kişi (spoiler: eski bir timezone bug’ı yüzünden, ki bu “özellik” haline geldi).

Bu kişi ayrıldığında, veritabanı sorunları arkeolojik keşiflere dönüşüyor. Müşteri aramasının yoğun trafikte neden aniden 30 saniye aldığını anlamaya çalışan bir dedektif gibi EXPLAIN sorguları çalıştırırsınız.

Deploy Ustası

Bu kişi üç farklı AWS hesabı, manuel sertifika yenileme ve hassas zamanlı veritabanı migrasyonlarını içeren 23 adımlık deployment sürecini ezberlemiş. “Düzgün dokümante etmek çok karmaşık” dediği için hiç yazmamış, zaten üç yıldır sorunsuz yapıyormuş.

Hücre servisinin olmadığı uzak bir adaya rüya tatile çıkana ve kritik bir güvenlik yamasını push’lamanız gerekene kadar. O anda deployment bilgisi tam da ihtiyaç duyduğunuz anda yoktur.

Entegrasyon Kahinesi

Üçüncü parti API’ler onların uzmanlığı. A Satıcısının webhook’unun Salı günleri bazen çift event gönderdiğini, B Satıcısının rate limiting’inin belgelenmemiş “burst mode”u olduğunu ve C Satıcısının sandbox ortamının production’la hiç benzerlik taşımadığını bilirler.

Bu kişi ayrıldığında, her entegrasyon istediği zaman patlayabilecek gizemli bir kara kutu haline gelir. Hangi davranışların kasıtlı, hangilerinin workaround gerektiren quirklar olduğunu bilemezsiniz.

Bilgi Dağıtım Stratejisi Oluşturma

Produktiviteyi öldürmeden ya da dokümantasyonu bürokratik bir kabuslara çevirmeden bus factor’ları sistematik olarak azaltma konusunda öğrendiklerimi paylaşayım:

1. Kritik Yol Dokümantasyonuyla Başlayın

Her şeyi dokümante etmeye çalışmayın - ekibinizi tükenir ve kimsenin okumadığı dokümanlar yaratırsınız. Bunun yerine sisteminizdeki kritik yolları belirleyin ve oraya odaklanın.

“Panik testi” dediğim yöntemi kullanıyorum: Bu sistem yönetim kurulu toplantısı sırasında bozulsa, 30 dakikada düzeltmek için neyi bilmem gerekir? İlk dokümante edilen o olur. Kritik yol dokümantasyonu her şeyi belgelemekten farklıdır—odaklanmak, okunabilirlik ve güncellik sağlar.

/**
 * Ödeme İşleme Kritik Yolu
 * 
 * Neden var: Günlük 2M+ TL işlem yapıyor
 * 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, açık fail
 * - 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 tamamlanMALI
      const fraudResult = await this.fraudService.check(paymentIntent, {
        timeout: 2000,
        fallback: 'APPROVE' // Meşru satışları bloklamak için açık fail
      })
      
      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 serbest bırak
      await this.releaseInventory(inventoryLock)
      throw error
    }
  }
}

2. Mimari Karar Kayıtları (ADR’ler)

ADR’ler mimari kararların “neden”ini yakalamak için en iyi arkadaşınız. Sistemimizde neden beş farklı önbellekleme katmanımız olduğunu anlamaya çalışarak üç ay geçirdikten sonra kullanmaya başladım (meğer her biri farklı ölçek noktalarında belirli performans problemlerini çözüyormuş).

İşe yarayan bir şablon:

# ADR-15: Event-Driven Order Processing

## Status
Kabul edildi

## Context
Monolitik order processing darboğaz oluyordu: peak'te 15+ sn, payment failure'lar inventory'ye cascade, yeni order tipi eklemek zor.

## Decision
AWS EventBridge ile event-driven mimari: order'lar lifecycle'ta event emit eder, ayrı servisler payment/inventory/notification halleder, failed event'ler exponential backoff ile retry.

## Consequences
### Positive
Order oluşturma <2 sn. Servisler bağımsız scale. Yeni order tipleri kolay.

### Negative
Eventual consistency. Cross-service debugging zor. Daha fazla altyapı.

### Mitigations
Order status endpoint, X-Ray ile distributed tracing, ortak EventBridge schema.

3. Runbook Kültürü

Runbook’lar sadece olaylar için değil - bilgi sigortası poliçeleridir. Ama yaşayan dokümanlar olmalı, iki yıl önce doğru olan tozlu PDF’ler değil.

# 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 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. Payment Servis 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. Fraud Servisini Kontrol Et (2 dakika)

Fraud servisi düşükse ödemeler kapanır (tasarım gereği).

# Fraud servis durumu
curl https://fraud-api.internal/health

# Düşükse geçici olarak fraud kontrolünü kapat:
kubectl set env deployment/payment-service FRAUD_CHECK_ENABLED=false
# Fraud servisi restore edildikten sonra tekrar aç!

Rollback Prosedürleri

Diğer her şey başarısız olursa ödemeleri yedek işlemciye yönlendir:

kubectl set env deployment/payment-service PRIMARY_PROCESSOR=backup

Beklenen gelir etkisi: %2.5 daha yüksek işlem ücretleri. Maksimum yedek süresi: finans escalation öncesi 4 saat.

4. Bilgi Doğrulama, Sadece Dokümantasyon Değil

Dokümantasyon iyidir ama doğrulanmış dokümantasyon daha iyidir. Her çeyrek kritik bir sistemi seçip, onu inşa etmeyen birinin yalnızca dokümantasyonu kullanarak deploy, debug veya değiştirmesini isterim. Boşluklar hızla ortaya çıkar. Bu “documentation gameday” yaklaşımı runbook’ların gerçekten işe yaradığını kanıtlar ve sessiz varsayımları yüzeye çıkarır. Tester olarak sistemi inşa etmeyen birini seçmek kritik - aksi halde kör noktalar kalır.

// Ödeme Sistemi için Bilgi Doğrulama Checklist
interface ValidationTest {
  scenario: string
  timeLimit: string
  successCriteria: string
  tester: string
}

const validationTests: ValidationTest[] = [
  { scenario: "Staging'e sıfırdan deploy", timeLimit: "30 dk", successCriteria: "Health check geçer", tester: "frontend-engineer" },
  { scenario: "Test ödemelerinin reddedilme sebebini debug et", timeLimit: "15 dk", successCriteria: "Kök neden bulunup düzeltilsin", tester: "devops-engineer" },
  { scenario: "Yeni ödeme yöntemi ekle (Apple Pay)", timeLimit: "2 saat", successCriteria: "Dev'de çalışan entegrasyon", tester: "mobile-engineer" }
]

Araçlar ve İşe Yarayan Metrikler

Ölçülebilir metrikler olmadan bus factor yönetimi kör uçuyor. Aşağıdaki araçlar gerçekten işe yaradı.

Kod Sahipliği Analizi

GitHub bilgi dağılımı konusunda şaşırtıcı derecede iyi içgörüler sağlıyor:

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

# Sonuç bilginin konsantre olup olmadığını gösterir:
#  47 [email protected]  # Kırmızı bayrak - bir kişi %80'ini sahipleniyor
#  8 [email protected]
#  3 [email protected]
#  1 [email protected]

Bir kişinin kritik dosyalarda commit’lerin %70’inden fazlasına sahip olması bus factor riski demektir. Pair programming oranları ve retrospektiflerdeki bilgi transfer metrikleriyle bu analizi tamamla - hangi alan için kim code review yapıyor?

Dokümantasyon Kapsamı Takibi

Dokümantasyon kapsamını test kapsamı gibi takip ediyorum: her kritik sistem için runbook, mimari diyagram ve deploy rehberi var mı diye bakıyorum. Son güncelleme tarihini ve bilgi doğrulama skorlarını izliyorum. Kritik sistemlerde skor 70’in altındaysa uyarı veren bir sistem kullandım. Validate edilmemiş dokümanlar yarım sayılır - sadece gameday’dan geçen runbook’lar gerçek kapsamda.

Altyapı Kodu ile Bilgi Korunması

Kendi kendini dokümante eden altyapı bus factor’ı önemli ölçüde azaltır:

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

  # Bilgi notları
  tags = {
    Sahip  = "payments-team"
    Runbook  = "https://wiki.company.com/payments/runbook"
    SlackKanal  = "#payments-urgent"
    SLA  = "99.9-yuzde"
    GelirEtkisi  = "kritik-50k-gunluk"
    SonOlay  = "2024-11-15-stripe-timeout"
  }

  # Not: Deploy sırasında minimum_healthy_percent 100 tutuyoruz çünkü
  # bir olayda %50 kapasitede ödemeler başarısız olmuştu.
  deployment_configuration {
    maximum_percent  = 200
    minimum_healthy_percent = 100
  }
}

Sektörden Başarı Hikayeleri

Netflix’in Chaos Engineering’i

Netflix, production instance’larını rastgele öldüren Chaos Monkey’i yarattı. Bu, herhangi bir bileşen olmadan - insanlar dahil - hayatta kalabilen sistemler inşa etmeye zorladı.

Google’ın SRE Modeli

Google, operasyonel bilginin ekipler arasında paylaşıldığı Site Reliability Engineering modelini öncülük etti.

Spotify’ın Squad Modeli

Spotify, servislerini uçtan uca sahiplenen küçük, çapraz fonksiyonel squad’lara organize oldu.

Amazon’un İki Pizza Takımları

Amazon ekip büyüklüğünü iki pizzanın doyurabileceği kadar kişiyle sınırlar. Bu, herkesin her şeyden biraz bilmesini gerektirir.

Bus Factor Azaltmanın ROI’si

Rakamlardan bahsedelim, çünkü yönetim rakamları seviyor.

interface BusFactorCost {
  system: string
  revenueAtRisk: number // Sistem başarısız olursa günlük gelir
  expertSalary: number // Ana uzmanın yıllık maaşı
  replacementTime: number // Uzmanı değiştirmek için ay
  onboardingTime: number // Yenisini hazırlamak için ay
  opportunityCost: number // Bilgi boşluğu nedeniyle geciken projeler
}

const paymentSystemRisk: BusFactorCost = {
  system: "payment-processor",
  revenueAtRisk: 50000, // Günlük 50k TL gelir
  expertSalary: 180000,
  replacementTime: 3, // işe alma için ay
  onboardingTime: 4, // tam verimlilik için ay  
  opportunityCost: 200000 // geciken özellikler
}

// Risk hesaplaması:
// Uzman ayrılırsa: 7 ay * 50k TL/gün * 30 gün = 10.5M TL gelir riski
// Artı 200k TL fırsat maliyeti = 10.7M TL toplam risk
// Dokümantasyon/eğitim yatırımı: 50k TL (takımın 1-2 aylık zamanı)
// ROI: 214:1 yatırım getirisi

Bu rakamlar iş durumlarını çok ikna edici yapıyor.

Bus factor sadece teknik risk değil - güvenlik ve performans kadar dikkat hak eden bir iş sürekliliği konusudur. Sistematik bilgi dağılımına yatırım yapan ekipler gece daha rahat uyurken başarıyla büyüyen ekiplerdir.

Yaygın Tuzaklar ve Nasıl Kaçınılır

Ölçüm yoksa iyileştirme de yok. Aşağıdaki tuzaklar en sık karşılaşılanlardır.

Dokümantasyon Çürümesi

Problem: Dokümanlar yazıldığı anda eskiyor. Çözüm: Dokümantasyon güncellemelerini her PR’ın “done” tanımının parçası yapın.

Aşırı Dokümantasyon

Problem: Kimsenin ihtiyacını bulamayacağı kadar çok dokümantasyon. Çözüm: Kritik yollara ve yaygın senaryolara odaklanın. 80/20 kuralını kullanın.

Zorla Bilgi Paylaşımı

Problem: Buy-in olmadan bilgi transferini zorunlu kılmak kırgınlık yaratır. Çözüm: Bilgi paylaşımını kariyer büyüme metriği yapın ve halka açık kutlayın.

Süreç Yükü

Problem: O kadar çok süreç var ki iş yavaşlıyor. Çözüm: Küçük başlayın, etkiyi ölçün, işe yarayanları koruyun.

Kültürel Direnç

Problem: Bazı mühendisler “vazgeçilmez” olmayı tercih eder. Çözüm: Öğretenleri kutlayın, kahramanları değil. Bilgi paylaşımını terfi kriteri yapın.

Dayanıklı Mühendislik Kültürü Oluşturma

Kahramanlar Kurtarıcı Değil Öğretmen Olsun

Hafta sonu krizi çözeni değil, sistemi o kadar iyi dokümante eden mühendisi kutlayın ki bir sonraki kriz orijinal ekipte olmayan biri tarafından 20 dakikada çözülsün.

Öğrenme Yolları Oluşturun

Bilgi paylaşımını kariyer gelişimi olarak yapılandırın: mevcut uzmanı, öğrenenleri ve doğrulanabilir kilometre taşlarını netleştirin. Örneğin “beş production deployment’ı gölge olarak izle”, “denetimle deployment liderliği yap”, “bağımsız olarak bir deployment olayını çöz” gibi aşamalı milestonelarla bilgi yayılır.

Bilgi Dağılımını Mümkün Kılan Araçlar

İzleme ve Uyarı: Grafana ile herkesin okuyabildiği dashboard’lar, PagerDuty ile on-call rotasyonu, Datadog ile metrik, log ve trace korelasyonu. Dokümantasyon: Confluence veya Notion ile yaşayan dokümanlar, Mermaid ile versiyonlanan mimari diyagramlar, GitHub Wiki ile koda yakın dokümantasyon. Bilgi Doğrulama: Gameday’larda simüle hatalarla egzersiz, Wheel of Misfortune ile geçmiş olayları farklı yanıtlayıcılarla canlandırma, dokümantasyon sprint’lerinde yazım ve güncelleme.

Farklı Yapacağım Şeyler

1. Olay müdahalesiyle başlayın, dokümantasyonla değil. En motive edici dokümantasyon, geçen olayda sizi kurtaracak runbook’tur.
2. Sosyal yapın - peer learning zorlamadan daha iyi çalışır. Mühendislerin birbirine öğretmesi için teşvikler yaratın.
3. Doğrulamayı otomatikleştirin - dokümantasyonun güncel kaldığını varsaymayın; doğrulayan sistemler kurun.
4. Başarıyı halka açık kutlayın - bir sistemi inşa etmeyen biri bir sorunu çözdüğünde bunu tanıyın. Önce kritik sistemlerdeki tek kişi bağımlılıklarını tespit edin; sonra o kişiyle dokümantasyon ve pair programming planı yapın.

Öncelik sırası: Önce “panic test” ile en kritik sistemi belirleyin. O sistemin runbook’unu ve ADR’larını yazın. Sonra kod sahipliği analiziyle bir sonraki riski tespit edin. Paralel olarak öğrenme yolları oluşturun - gölge deployment’lar, pairing, olay sonrası post-mortem’ler bilgiyi yayar.

Unutmayın: Amaç uzmanlığı ortadan kaldırmak değil - uzmanlığın yıldız performansınızla birlikte kapıdan çıkıp gidebileceği silolarda sıkışıp kalmamasını sağlamaktır.