Frenli Kendini Onarma

Ne görüyorsun

Üç servis çalıştıran üç node’luk oyuncak bir cluster ve tek bir sağlık sinyalini izleyen bir onarım kontrolcüsü. Her buton cluster’ı farklı bir şekilde bozuyor. Guardrail’ler açıkken kontrolcü, yazıda anlatılan state machine’i adım adım yürütüyor: Detect (sorunu fark et), Diagnose (sebebi ilişkilendir), Propose (tek bir aksiyon öner), Policy gate (bütçe, cooldown ve otonomi sınırına takılıyor mu bak), Act (bir kez uygula), Verify (20 saniye bekleyip gerçekten düzeldiğini doğrula) ve Close (kapat). Reddedilen bir öneri ya da başarısız bir verify asla sessizce tekrar denenmiyor; iş bir insana, yani on-call’a page olarak düşüyor.

Frenler neden önemli

Öldürülen bir pod dürüst bir arıza: tek restart düzeltir, iki döngü de bunu halleder (naif olan daha hızlı, çünkü verify beklemesinin gerçek bir maliyeti var). Latency eklemek ise yanıltıcı bir sinyal: pod’lar sağlam, bozuk olan bir dependency. Guard’lı döngü bir kez restart atıyor, düzelme görmüyor ve duruyor. Hatalı bir deploy, pencere başına bir tane gate’ten geçen rollback hakkı alıyor. Node çökmesinin blast radius’u koca bir node; policy bunun için yalnızca öneri yapılmasına izin veriyor. Guardrail’leri kapatıp aynı arızaları tekrar dene: flapping’i, restart fırtınalarını ve hatalı release’in bütün replica’lara yayılmasını göreceksin. Hepsi log’a “success” olarak düşüyor ve hiçbiri kimseye page atmıyor.

Policy değerleri (incident başına 3 aksiyon, 120 saniyelik restart cooldown, pencere başına bir rollback, 20 saniyelik verify beklemesi) Melih Kızmaz’ın yazısının arkasındaki lab reposundan geliyor. O lab’de naif döngü sağlıklı bir servisi 106 saniyede 13 kez restart etti; guard’lı döngü ise 20,4 saniyede işi bir insana devretti. Bu sayfa gerçek bir cluster değil, tarayıcında çalışan bir simülasyon.