47 Dakikada Çözülen Ödeme Servisi Arızası

Ödeme servisi arızası 1:49'da başladı. PagerDuty alarmı verildi ve ödemeler servisi CrashLoopBackOff durumuna girdi. 4 dakika sonra ben de olay köprüsüne katıldım. 2:36'da sorunu çözdük. 47 dakika süren bir hata ayıklama süreci için sadece 2 satırlık bir YAML değişikliği yeterli oldu.

İlk 10 Dakika: Açık Yanlış Cevap

Pod'lar aynı anda çöktüğünde, genellikle son yapılan dağıtım sorumlu olmakla together. İlk 10 dakika bu doğrultuda geçti: kubectl rollout history deployment/payments-service -n production ve kubectl describe deployment/payments-service -n production komutlarıyla son dağıtıma baktık.

Son dağıtım 7:52'de yapılmıştı, yani 6 saat önce. Pod'lar o günden beri sağlıklı çalışıyordu. Bu, dağıtımınponsible olmadığını gösteriyordu, ancak bunu yeterince hızlı içselleştiremedik. Dağıtım diff'ini incelemek için 5 dakika daha harcadık.

Sonraki 15 Dakika: Log Arkeolojisi

Dağıtım sorumluluğundan sonra, log'lara baktık: kubectl logs payments-service-7d9f8b-xkp2q --previous -n production ve kubectl logs payments-service-7d9f8b-mn4lw --previous -n production. Log'lar servisi normal şekilde başlattığını, Redis bağlantısı kurmaya çalıştığını ve sonra... hiçbir şey olmadığını gösteriyordu. Süreç öldürülmüştü, hiçbir hata veya panic mesajı yoktu.

27. Dakika: Olay Günlüğü (Buradan Başlamamız Gerekirdi)

Her postmortem'de düşündüğüm anda buradayım: neden olay günlüğünden başlamadık?

kubectl get events -n production --sort-by='.lastTimestamp' | tail -30 komutuyla olay günlüğüne baktık. İşte oradaydı: Liveness probe başarısızlığı. Probe zaman aşımına uğramıştı.

Ancak burada ikinci hatayı yaptığımız yer: liveness endpoint'inin kendisinin bozulduğunu varsaydık. Belki servis doğru şekilde başlamıyordu. Belki bir bağımlılığı ulaşamıyordu. Sağlık endpoint'ini manuel olarak curl yaparak, çalışan bir pod'a girerek endpoint'in yanıt verdiğini görmeye çalıştık.

37. Dakika: Kontrol Edilmeyen Düğüm Olayı

Bir mühendis köprüde şunları söyledi: "Bekleyin, bu ne zaman başladı? 1:49 mu? O zamandan önce düğümlerde bir şey oldu mu?

kubectl get events -n kube-system --sort-by='.lastTimestamp' | grep -E "Node|node" komutuyla düğümlerin olay günlüklerine baktık. Bir düğüm 1:47'de döngüye girmişti — arızanın başlangıcından 2 dakika önce.

Bu düğümde redis-cache-0 çalışıyordu. Redis'in yeniden başlamasıyla birlikte, ödemeler servisi liveness probe'u Redis bağlantısını denedi, ancak Redis 3-4 saniye içinde hazır değildi. Probe zaman aşımına uğradı ve Kubernetes pod'u öldürdü.

Gerçek Postmortem: Neden 47 Dakika Sürdü?

Çözüm sadece 2 satırlık bir YAML değişikliğiitti. Ancak soruşturma 47 dakika sürdü. Bu oran asıl sorundur.

Zamanın nereye harcandığını gösteren bir harita:

• Dağıtım soruşturması: 12 dakika
• Log arkeolojisi: 15 dakika
• Sağlık endpoint testi: 10 dakika
• Düğüm olay keşfi: 7 dakika
• Teşhis ve çözüm: 3 dakika

Sorunu çözen sinyaller sıfır dakika itibarıyla oradaydı:

• k8s olayları
• Düğüm olayları
• Redis pod yeniden başlatma zamanı
• Dağıtım history

Eğer bu dört şeyi bu sırayla okursanız, soruşturma 5 dakika sürer, 47 dakika değil. Problemin bu sinyallerin üç farklı yerde olması ve insanın 2'de basınç altında en teşhis edici görüşü doğal olarak başlattığımız yer değil.