Üretimde Bir Hatayı 10 Dakikada Daraltmanın Sistematiği

Bir üretim hatası bildirildiğinde en yaygın refleks, doğrudan log dosyalarına dalmaktır. Bu genellikle en verimsiz başlangıçtır: elinizde henüz hangi isteği aradığınıza dair bir filtre yoktur ve binlerce satır arasında kaybolursunuz. Aşağıdaki sıra, her adımda olasılık alanını yarıya indirmek üzere kurulmuştur.

0-1. dakika: etkiyi ölçün

Önce kapsamı belirleyin: tüm kullanıcılar mı, tek bir müşteri mi? Bir uç mu, tüm site mi? Bu cevap hem aciliyeti hem de arama alanını belirler. "Herkes" ile "yalnızca bir kullanıcı" tamamen farklı hipotez kümeleri üretir.

# Hata oranı gerçekten arttı mı, yoksa tek bir bildirim mi?
grep -c "CRITICAL\|ERROR" writable/logs/log-$(date +%Y-%m-%d).php

# Son 10 dakikadaki hataların dağılımı
grep "ERROR" writable/logs/log-$(date +%Y-%m-%d).php \
  | awk '{print $2}' | cut -d: -f1,2 | sort | uniq -c | tail -10

1-3. dakika: "ne değişti?"

Üretim hatalarının büyük çoğunluğu bir değişikliği takip eder. Kod dağıtımı, yapılandırma güncellemesi, sertifika yenilemesi, üçüncü parti servis değişikliği veya trafik artışı. Bu soruyu log okumadan önce sormak, çoğu vakayı doğrudan çözer.

# Son dağıtım ne zaman ve neydi?
git log -3 --format='%h %ad %an %s' --date=iso

# Yapılandırma son ne zaman değişti?
ls -lt --time-style=long-iso .env writable/ | head

# Sistem tarafında bir şey mi yeniden başladı?
journalctl --since "30 minutes ago" -p warning --no-pager | tail -30

3-6. dakika: tek bir isteği izleyin

Log okumanın verimli olması, aramayı tek bir isteğe daraltabilmenize bağlıdır. Bunun ön koşulu, her isteğe bir korelasyon kimliği atamaktır — yoksa şimdi eklemek, bir sonraki olayda saatler kazandırır.

// Filtre: her isteğe izlenebilir bir kimlik ver
public function before(RequestInterface $request, $arguments = null)
{
    $id = $request->getHeaderLine('X-Request-Id') ?: bin2hex(random_bytes(8));

    // Hem log satırlarına hem de yanıta yaz: kullanıcı hata kodunu bize söyleyebilsin
    $GLOBALS['istek_id'] = $id;
    service('response')->setHeader('X-Request-Id', $id);
}

// Log yazarken kimliği daima ekleyin
log_message('error', sprintf(
    '[%s] Sipariş oluşturulamadı: kullanici=%d, hata=%s',
    $GLOBALS['istek_id'] ?? '-',
    session()->get('user_id') ?? 0,
    $e->getMessage()
));

# Artık tek bir isteğin tüm izini çekebilirsiniz
grep "a1b2c3d4e5f60718" writable/logs/log-*.php

Yavaşlığın kaynağı sorgu sayısıysa belirti dağınık olur; toplu yükleme yazımızdaki sorgu sayacı bunu hızla ortaya çıkarır.

6-8. dakika: katmanları ikili daraltın

Hata hâlâ belirsizse, sistemi katmanlara bölüp her birini ayrı doğrulayın. Amaç, sorunun hangi tarafta olduğunu tek bir testle ikiye bölmektir.

# Veritabanı yanıt veriyor mu, yavaş mı?
mysql -e "SELECT 1" && echo "bağlantı ok"
mysql -e "SHOW PROCESSLIST" | awk '$6 > 5' | head       # 5 saniyeden uzun sorgular

# Disk doldu mu? (sessiz ama çok yaygın bir sebep)
df -h | awk '$5+0 > 85'

# Dış servis mi yavaşladı?
curl -o /dev/null -s -w "durum=%{http_code} sure=%{time_total}s\n" https://api.saglayici.com/health

Disk dolması özellikle sinsidir: uygulama beklenmedik yerlerde hata verir ve belirti kök nedene hiç benzemez. Bu senaryo için disk doldu alarmı yazımızda ayrı bir kontrol listesi var.

8-10. dakika: karar

On dakika sonunda kök nedeni bulmuş olmayabilirsiniz — bu normaldir. Ama karar vermiş olmalısınız: geri alınacak mı, yoksa ileri doğru düzeltilecek mi? Kural basittir: etki büyükse önce geri alın, sonra araştırın. Kullanıcılar hata alırken kök neden aramak, iki maliyeti birden ödemektir. Bu kararı hızlı verebilmenin ön koşulu, geri alma planının önceden hazır olmasıdır.

Buradaki komut ve örneklerin nasıl hazırlandığını merak ediyorsanız kod örnekleri SSS sayfamıza bakabilirsiniz.

Sonrasında: aynı hatayı bir daha aramamak

Olay kapandıktan sonra tek bir soru sorun: "Bunu bir dakikada bulmamı ne sağlardı?" Cevap genellikle eksik bir log satırı, olmayan bir alarm veya belirsiz bir hata mesajıdır — ve hepsi on dakikada eklenebilir. Neyin loglanacağı konusunda üretimde log'a ne yazmalı yazımız, genel alışkanlıklar için hata ayıklamada zaman kurtaran alışkanlık yazımız tamamlayıcıdır. Gözlemlenebilirlik kavramlarının ortak tanımları için OpenTelemetry gözlemlenebilirlik girişi iyi bir kaynaktır.

Sonuç

Üretim hatasına müdahalede hız, bilgiden çok sıradan gelir: önce etkiyi ölçün, sonra "ne değişti?" sorusunu sorun, ardından tek bir isteği korelasyon kimliğiyle izleyin, katmanları ikili daraltın ve onuncu dakikada geri alma kararını verin. Bu sıra, panikle log karıştırmayı disiplinli bir daraltmaya çevirir. Bugün yapabileceğiniz en değerli hazırlık ise korelasyon kimliğini eklemektir — bir sonraki olayda kazandıracağı süre, harcadığınız on dakikanın kat kat üzerinde olacaktır.