Running a Lock-Wait Incident: Ownership, Intervention Decisions and Recovery Evidence

▸ Yönetici Özeti ve Olay Anı Gerçeği

PostgreSQL kilit beklemeleri (lock contention), platform mühendisliğinin en hızlı tırmanan ve en tehlikeli kriz türlerinden biridir. Bir web servisi bellek tükettiğinde pod yeniden başlar; CPU yükseldiğinde autoscaler devreye girer. Ancak bir transaction kritik bir satır veya tabloda kilit tutarken beklemeye girdiğinde, saniyeler içinde yüzlerce oturum aynı kilidi beklemeye başlar. Bağlantı havuzu tükenir (53300 too many clients), API yanıt süreleri tırmanır, arka planda biriken sorgular sunucuyu kilitler.

Bu kriz anında en büyük tehlike yanlış kararlar almaktır:

1
Rastgele oturum öldürmek: Kök bloklayıcıyı (root blocker) bulmadan kilit bekleyen masum istemcileri öldürmek sorunu çözmez; yeni bağlantılar hemen boşalan yerleri doldurarak kuyruğu daha da şişirir.
2
`pg_cancel_backend` yanılgısı: idle in transaction durumundaki bir işlemi pg_cancel_backend ile durdurmaya çalışmak başarılı döner (true), ancak oturum açık kaldığı için kilitler bırakılmaz.
3
Retry fırtınası (retry storm): Timeout yiyen istemcilerin hemen aynı işlemi tekrar denemesi, veritabanı kilit kuyruğunu katlayarak çöküşü kaçınılmaz hale getirir.

Bu rehber, bir PostgreSQL kilit krizi patlak verdiğinde veri platformu ve SRE ekiplerinin izleyeceği operasyonel standardı tanımlar: rol paylaşımı (RACI), adım adım müdahale sınırları, retry fırtınasını dondurma protokolü, paydaş iletişimi ve olay sonrası kanıta dayalı postmortem standardı.

1. Olay Sahipliği ve RACI Matrisi

Bir kilit krizi sırasında Slack kanalında 15 kişinin aynı anda öneri sunması felakettir. Kimin yetkili olduğu krizden önce bilinmelidir.

Rol	Sorumlu Kişi	Temel Görev (RACI)	Yetki Sınırı
Incident Commander (IC)	Nöbetçi SRE / Platform Lead	Accountable (A): Kriz kanalını yönetir, kararları kaydeder, iletişimi tek elden yürütür.	Müdahale zaman sınırını koyar. Teknik detaya boğulmaz.
Database On-Call / DBA	Kıdemli Veritabanı Mühendisi	Responsible (R): Kök bloklayıcı PID'yi tespit eder, kilit türünü ve güvenli sonlandırma yöntemini belirler.	`pg_cancel_backend` veya `pg_terminate_backend` çalıştırma yetkisi tek kişidedir.
Uygulama Sahibi (App Owner)	Servisin Tech Lead'i	Consulted (C): Bloklayan işlemin iş yükü önemini değerlendirir: Finansal mutabakat mı, arka plan raporu mu?	İşlem geri alınırsa (rollback) veri kaybı veya tutarsızlık olup olmayacağını onaylar.
Paydaş İletişimcisi (Comms)	Ürün Yöneticisi / Destek Lideri	Informed (I): Müşteri ve yönetim kanallarına standart durum şablonlarını iletir.	Teknik kanala soru sormaz; yalnızca IC'nin özetini yayar.

[!IMPORTANT] Tek Komut Kuralı: Canlı veritabanında aynı anda birden fazla kişi SQL çalıştırmaz. Sadece DBA rolündeki mühendis konsolda komut yürütür ve çıktıyı IC'nin kayıt kanalına yapıştırır.

2. Müdahale Karar Ağacı: Rollback, Cancel veya Terminate

Kriz anında kök neden bulunduysa (örneğin PID 113), DBA ve Uygulama Sahibi şu karar matrisini uygular:

Mimari Topoloji & Akış Şeması

Mermaid şeması çiziliyor...

▸2.1. `pg_cancel_backend` vs `pg_terminate_backend` Ayrımı

Laboratuvar testlerimizde (L5 Senaryosu) kesin olarak kanıtlandığı üzere:

`pg_cancel_backend(pid)`: Yalnızca o anda çalışmakta olan bir SQL ifadesine SIGINT sinyali gönderir. Eğer oturum idle in transaction durumundaysa, fonksiyon true döndürür ancak hiçbir şey yapmaz! Oturum açık kalmaya, transaction devam etmeye ve satır kilitleri tutulmaya devam eder.
`pg_terminate_backend(pid)`: Backend prosesine SIGTERM gönderir, istemci bağlantısını koparır, transaction'ı sunucu tarafında güvenle ROLLBACK eder ve tutulan tüm kilitleri anında işletim sistemine ve PostgreSQL'e iade eder.

[!WARNING] idle in transaction durumundaki kök bloklayıcılar için pg_cancel_backend ile vakit kaybetmeyin. Doğrudan hedefli pg_terminate_backend(pid) çalıştırın.

3. Retry Fırtınasını (Retry Storm) Önleme Protokolü

Kilit beklemelerinin en yıkıcı ikinci dalgası, veritabanı kilitlendiği anda mikroservislerin agresif retry politikalarıyla gelir.

▸Mekanizma:

1
100 kullanıcı aynı anda checkout butonuna basar.
2
İlk istek kilit alır; diğer 99 istek lock_timeout (örneğin 2 sn) süresine takılarak 55P03 veya 57014 hatası alır.
3
Uygulama kodu for (let i = 0; i < 3; i++) { retry(); } döngüsüne girer.
4
Sıfır bekleme süresiyle (zero delay) 99 istek anında tekrar veritabanına hücum eder. 99 istek 198, ardından 396 isteğe dönüşür.
5
Veritabanı bağlantı havuzcusu (PgBouncer) kilitlenir, sunucuda CPU tavan yapar.

▸Protokol:

1
Circuit Breaker: Kilit bekleme süresi 5 saniyeyi aştığında istemci katmanı veya API Gateway (Kong, Envoy) ilgili uç noktayı 503 Service Unavailable ile anında reddetmeli, veritabanına yeni bekleme sokmamalıdır.
2
Exponential Backoff + Full Jitter:

$$\text{sleep} = \text{random}(0, \min(\text{cap}, \text{base} \times 2^{\text{attempt}}))$$ Tüm istemcilerin aynı anda retry atmasını engellemek için tam rastgelelik (full jitter) zorunludur.

4. Olay İletişim Şablonları

Incident Commander, kriz sırasında paydaşlara kesinlikle kod parçası veya iç SQL çıktıları göndermez. İki standart şablon kullanılır:

▸4.1. Dahili Mühendislik & Yönetim Güncellemesi (Her 15 dakikada bir)

text

[DURUM GÜNCELLEMESİ #2] - Ödeme Servisi DB Kilit Beklemesi Olayı
Durum: Araştırılıyor (Kök bloklayıcı PID 1420 tespit edildi)
Kullanıcı Etkisi: %12 oranında ödeme isteği 504 Gateway Timeout alıyor.
Alınan Aksiyon: Kök bloklayıcı oturumun 'idle in transaction' kaldığı doğrulandı. 
Uygulama Sahibi onayı ile pg_terminate_backend(1420) çalıştırıldı.
Sonraki Adım: Kuyruk erimesi ve replikasyon gecikmesi izleniyor.
Bir Sonraki Güncelleme: 14:30 TSİ

▸4.2. Müşteri & Kamuoyu Bildirimi

text

Ödeme sistemlerimizde geçici bir yavaşlık tespit edilmiştir. 
Mühendislik ekibimiz müdahale etmektedir; mevcut işlemler güvendedir ve mükerrer tahsilat 
riski bulunmamaktadır. Yeni denemeler için lütfen 5 dakika bekleyiniz.

5. Doldurulabilir Olay Kartı (Incident Card)

Kilit vakası çözüldükten hemen sonra Incident Commander ve DBA bu kartı doldurarak olay kanalına sabitler:

Alan	Bilgi / Kayıt	Açıklama
Olay Kodu	`INC-2026-11-06-LOCKS-01`	Benzersiz olay kimliği
Başlangıç / Bitiş	`14:02 UTC` — `14:18 UTC` (Süre: 16 dk)	TTD (Tespit) ve TTR (Çözüm) süreleri
Kök Bloklayıcı PID	`PID 113` (`app_checkout_a`)	Kilit kuyruğunu başlatan backend prosesi
Kilit Tipi & Nesne	`ExclusiveLock` on `orders_p2026_11`	Beklemeye neden olan tablo/satır kilidi
Kuyruk Boyutu	`48 oturum bekledi` (`53300 pool near max`)	Maksimum eşzamanlı bloke olan oturum sayısı
Müdahale Kararı	`pg_terminate_backend(113)` uygulandı	Neden: `idle in transaction` süresi > 120s
Toparlanma Kanıtı	`pg_stat_activity` kilit bekleyen: 0; CPU: %14'e düştü	Veritabanı ve havuz metriklerinin normale dönüşü
Kök Katkı Faktörü	Dış PSP çağrısının transaction içinde yapılması	HTTP timeout süresince DB transaction açık kalmış
Önleyici Aksiyon	PSP çağrısı transaction dışına taşınacak; `idle_in_transaction_session_timeout = '15s'` set edilecek	JIRA: `PLAT-4921` (Kapanış: 3 gün)

6. Kanıta Dayalı Postmortem ve 90 Günlük İyileştirme Planı

Bir kilit krizi geçiştirilemez. Postmortem toplantısında suçlama yapılmaz; pipeline ve mimari açıklar kapatılır.

▸Katkı Faktörleri Modeli (Blameless Review)

Tetikleyici: Ödeme servisinin dış sağlayıcıdan (PSP) yanıt alamaması.
Mimari Açık: BEGIN; SELECT FOR UPDATE; await fetch(psp); COMMIT; şeklinde ağ çağrısının transaction içine yazılmış olması.
Sistemik Güvenlik Eksikliği: Veritabanında idle_in_transaction_session_timeout tanımlanmamış olması.

▸90 Günlük Yol Haritası:

1
0–30 Gün (Sert Koruma):

Tüm uygulama rollerinde idle_in_transaction_session_timeout = '15s' zorunlu kılınacak.
Tüm DDL operasyonlarında lock_timeout = '2s' standardı CI/CD migration araçlarına entegre edilecek.

1
31–60 Gün (Gözlemlenebilirlik):

Kilit bekleme süresi > 1s olduğunda Slack alert üreten Prometheus/Datadog metriği devreye alınacak.
PGBouncer bağlantı satürasyon alarmları erken uyarı moduna geçirilecek.

1
61–90 Gün (Mimari Olgunluk):

Kod tabanındaki tüm FOR UPDATE ve uzun transaction kalıpları denetlenecek.
Veritabanı işlemlerinde optimistic locking (version kolonu) desenine geçiş başlatılacak.

Kilit Beklemesi Olayını Yönetmek: Sahiplik, Müdahale Kararı ve Toparlanma Kanıtı