0-3 dakika: etkiyi ve zamanı netleştirin
İlk soru “neden oldu?” değildir. İlk soru “kim etkileniyor ve ne zamandan beri?” olmalıdır. Çünkü kök nedeni ararken kullanıcı etkisini ölçmezseniz, teknik olarak ilginç ama iş açısından önemsiz bir ayrıntıya takılabilirsiniz.
Bir olay notu açın ve tek bir zaman çizgisi tutun. Saat kaçta başladı, kim bildirdi, hangi uç noktalar etkileniyor, sadece yazma mı yoksa okuma da mı bozuk, tek tenant mı yoksa herkes mi? Bu basit kayıt, olay bittikten sonra da en değerli belgedir.
- Başlangıç zamanı: ilk alarm, ilk kullanıcı bildirimi ve ilk log hatası ayrı ayrı not edilir.
- Etki alanı: tek servis, tek tenant, tek bölge veya tüm platform olarak sınıflandırılır.
- Semptom: zaman aşımı, connection refused, yavaş sorgu, disk doluluğu veya replikasyon gecikmesi gibi adı konur.
- Müşteri etkisi: okuma, yazma, ödeme, raporlama veya arka plan işlerinden hangisi bozuldu belirtilir.
3-7 dakika: değişiklikleri dondurun, fotoğraf alın
Olay sırasında en sık yapılan hata, kanıt toplamadan peş peşe değişiklik yapmaktır. Bir pod yeniden başlar, biri parametre değiştirir, biri kullanıcı parolasını döndürür; sorun düzelirse bile gerçek neden kaybolur.
Önce sistemi olduğu haliyle fotoğraflayın. Son yayına alma ne zaman çıktı, bakım penceresi var mıydı, ağ veya DNS değişikliği yapıldı mı, cluster olaylarında ne görünüyor? Birkaç dakika kaybediyormuş gibi hissettirir ama çoğu zaman saat kazandırır.
TürkDB ile olay fotoğrafı
turkdb cluster get app-db turkdb cluster events app-db --limit 50 turkdb cluster allowlist list app-db turkdb backup list app-db turkdb cluster pitr window app-db
Her motor PITR desteklemeyebilir; komutun amacı geri dönüş penceresini erken görmek ve ekip konuşmasını tahminden kanıta taşımaktır.
7-12 dakika: sorunu doğru sepete koyun
Bu dakikalarda amaç kök nedeni tamamen çözmek değil, problemi doğru sınıfa koymaktır. Bağlantı mı kopuyor, sorgular mı yavaşlıyor, disk mi doluyor, failover mı yaşandı, yedekleme/geri yükleme ihtimali mi konuşulmalı?
Her sepetin ilk kanıtı farklıdır. Bağlantıda izin listesi ve TLS, yavaş sorguda motorun kendi sistem tabloları, kapasitede CPU/bellek/disk, failoverda olay kayıtları ve uygulama reconnect davranışı öne çıkar.
- Bağlantı hatası varsa: uygulama DSN, TLS parametresi, izin listesi, çıkış IP adresi ve pool limiti kontrol edilir.
- Yavaşlık varsa: motorun yavaş sorgu/explain sinyali alınır, sadece kaynak kullanımına bakılmaz.
- Disk doluluğu varsa: tablo büyümesi, yedek/retention, WAL/binlog/oplog veya ClickHouse part büyümesi ayrılır.
- Failover olduysa: yeni birincil, uygulama reconnect ve yazma başarısı doğrulanır.
- Veri kaybı şüphesi varsa: müdahale etmeden önce yedekleme/PITR penceresi ve silme zamanı netleştirilir.
12-15 dakika: karar ve iletişim ritmi kurun
İlk 15 dakikanın sonunda herkesin aynı şeyi bilmesi gerekir: etki ne, en güçlü şüphe ne, sıradaki aksiyon ne, rollback veya geri yükleme ihtimali var mı, bir sonraki güncelleme ne zaman verilecek?
Bu noktada kahramanlık değil ritim işe yarar. “Beş dakika içinde tekrar bilgi vereceğiz” cümlesi, sessizce uğraşmaktan daha güven vericidir. Teknik ekip de destek ekibi de aynı zaman çizelgesini görür.
Kısa olay notu şablonu
Durum: PostgreSQL app-db üzerinde yazma isteklerinde zaman aşımı Başlangıç: 2026-06-14 14:08 TRT Etki: ödeme akışı API p95 > 8s, ödeme sonrası kayıt gecikiyor Son değişiklik: 13:52 backend yayına alma v2026.06.14-2 İlk kanıt: connection pool dolu, veritabanı CPU normal Sıradaki aksiyon: pool tüketen sorgular ve idle transaction kontrolü Sonraki güncelleme: 14:25 TRT
Olay bittikten sonra aynı soruna tekrar düşmeyin
Olay kapandıktan sonra yapılacak en iyi iş, “kim hatalıydı?” aramak değil, bir sonraki ekip üyesinin aynı olayı daha kısa sürede çözmesini sağlamaktır. Hangi sinyal kök nedeni gösterdi, hangi metrik yanıltıcıydı, hangi komut işe yaradı?
TürkDB tarafında olay kayıtları, bakım geçmişi ve yedek/geri yükleme kanıtları bu postmortem notuna malzeme verir. Ama en değerli kısım yine ekibin kendi cümlesidir: bir dahaki sefere ilk bakacağımız yer burası.
- Alarm eşiği çok geç mi tetiklendi, yoksa doğruydu ama okunmadı mı?
- Müdahale Rehberita eksik kalan komut veya bağlantı bilgisi var mıydı?
- Geri dönüş planı konuşuldu mu, konuşulduysa hangi eşik kararı belirledi?
- Müşteri iletişimi teknik ekipten bağımsız sürdürülebildi mi?