Chaos engineering'i küçük ekipte uygulamak

Chaos engineering denince akla Netflix, AWS, büyük bulut altyapıları geliyor. “Biz küçük ekibiz, bu bize göre değil” diye uzak duruyoruz. Küçük ekipte de disiplini uygulanabilir bir versiyon var, onu paylaşayım.

Temel fikir basit. Sistem çökmeden önce bilinçli olarak parçaları bozarız, ne olduğunu görürüz, learnings alırız. Prod bir Cuma gecesi kendiliğinden çökmek yerine, biz Salı öğleden sonra kontrollü ortamda çökertiyoruz.

Başlangıç seviye: ne çökerse ne olur?

İlk egzersiz dokümante etmek. Takımla oturup “sistemimizin kritik bileşenleri neler ve biri çökerse ne olur?” sorusuna cevap veriyoruz. Örnek:

Bu tablo bile chaos engineering’in en değerli kısmı. “Redis çökerse ne olur” sorusuna takım “ne olacağı belli değil” diye cevap verdiyse, test etmek hayati.

Seviye 1: manuel tek bileşen kapatma

Staging’de bir bileşeni manuel kapat, sistemin davranışını izle.

# staging'de Redis'i kapat
sudo systemctl stop redis

# uygulama loglarında ne görüyoruz?
tail -f /var/log/app.log

# metriklerimizde ne değişiyor?
# → response time arttı mı? error rate ne?

İlk denediğimde Redis kapandı, uygulama 30 saniyelik timeout’la bekledi, sonra exception fırlattı. Kontrolsüz bir hata mesajı kullanıcıya ulaştı. “Redis kapanınca DB’ye düşsün” diye planlamıştık ama kod yazılmamıştı. Bu test olmadan bunu prod’da öğrenecektik.

Fix: Redis client’a connect_timeout: 1s, command_timeout: 500ms. Bağlanamayınca null döner, uygulama cache miss olarak davranır, direkt DB’ye gider.

Seviye 2: ağ problemi simülasyonu

Toxiproxy ile kontrollü ağ gecikmesi/kesintisi ekliyoruz. Staging’de API’ler arası bağlantıya 500ms gecikme, ara sıra packet drop eklersek sistem ne yapıyor?

toxiproxy-cli toxic add -t latency -a latency=500 redis_proxy

Bu test bazı bağımlılıkların sessizce kabuk değiştirdiğini gösterdi. Normal koşulda iyi çalışan bir microservice, upstream 500ms yavaşlayınca connection pool’u tüketiyordu. Yeni istekler bekliyordu. Cascade failure başlıyordu.

Fix: connection pool size’ı artırdık, circuit breaker ekledik.

Seviye 3: load + hata kombinasyonu

Normal yük altında bir şey çökünce ne olur? k6 ile 100 concurrent user yüklerken veritabanını yavaşlatıyoruz.

Bu test veritabanı primary’yi yavaşlatınca tüm API endpointlerinin aynı anda kilitlendiğini gösterdi. Tek cache-free endpoint tek pool’u tüketiyordu. Çözüm, endpoint başına ayrı veritabanı connection pool.

Küçük ekip için disiplin

Netflix bunu otomatik yapıyor, bizim yapamayacağımız ayrı. Ama ayda bir Salı öğleden sonra 2 saat ayırabiliriz. Hedefler:

Bir bileşeni kapat. Sonucu dokümante et.
Fix gerekiyorsa task aç. Aksiyon planı çıkar.
Bir sonraki chaos session öncesi fix’i kontrol et.

Bu kadar. Şovlu değil, disiplinli.

Neyi test etmemeli?

Prod’da bilinmeyen sonuçlu şeyler. Staging önce.
Hafta sonu, tatil öncesi. Oncall desteği olmalı.
Kullanıcıyla konuştuğumuz saatlerde. Düşük trafik penceresinde.
Henüz fallback tasarlanmamış yerlerde. Önce tasarla, sonra kır.

Gamedays

4 ay önce “gameday” diye yarım günlük bir çalıştay yaptık. Bir servisi kapattık, takım gerçek bir incident tatbikatı yaptı. Kim neyi yapar, runbook güncel mi, iletişim kanalları çalışır mı, her şey test edildi. Dört kişilik ekibin koordinasyonu prod incident sırasında daha hızlı oldu.

Gameday tek başına yatırım değil, aynı zamanda eğitim. Yeni gelen developer’ların sisteme hakim olma süresi bu şekilde kısalıyor.

Yaratılan kültür

Chaos engineering disiplini bir süre sonra kültüre işliyor. Yeni feature tasarlarken “peki bu bileşen çökerse ne olur?” sorusu refleks oluyor. Design doc’larda fallback bölümü zorunlu hale geliyor. Single point of failure aramak alışkanlık.

Küçük ekip olmanız bu disiplini uygulamaktan alıkoymasın. Sadece ölçeği küçültün, düzenli yapın, her sefer bir öğrenme çıkarın.

Chaos engineering’i küçük ekipte uygulamak

Bu konuda bir projeniz mi var?