---
title: "Üretimde Bir Hatayı 10 Dakikada Daraltmanın Sistematiği"
url: "https://cilginyazilim.com/blog/uretimde-hatayi-hizli-daraltma-yontemi"
description: "Üretimde çıkan hata nasıl hızlı daraltılır? Ne değişti sorusu, log korelasyon kimliği, ikili daraltma ve doğrulama adımlarıyla pratik bir müdahale sırası."
published: "2026-08-20T10:00:00+03:00"
modified: "2026-08-20T10:00:03+03:00"
author: "superadmin"
category: "İpuçları ve Rehberler"
tags: ["php", "izleme", "devops", "hata ayıklama", "ipuçları", "sistem yönetimi", "rehber", "gözlemlenebilirlik", "korelasyon kimliği", "üretim hatası", "log", "olay yönetimi", "sorun giderme"]
site: "CılgınYazılım"
language: "tr"
---

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

Panikle log karıştırmak yerine, her adımı olasılık alanını yarıya indiren bir sıra izleyin.

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.

![Üretim hatasına müdahale adımları](https://cilginyazilim.com/uploads/blog/2026/08/uretimde-hatayi-hizli-daraltma-yontemi-ozet.png)
*Sıra önemlidir: “ne değişti?” sorusu, log okumaktan önce gelir.*

## 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.

```bash
# 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.

```bash
# 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
```

> Bu adımı hızlandıran en iyi yatırım, dağıtım anlarını izleme grafiklerine dikey çizgi olarak işaretlemektir. Hata eğrisiyle dağıtım çizgisinin çakışması, tartışmayı saniyeler içinde bitirir.

## 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.

```php
// 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);
}
```

```php
// 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()
));
```

```bash
# 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](https://cilginyazilim.com/blog/toplu-yukleme-batch-loading-deseni) 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.

```bash
# 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ı](https://cilginyazilim.com/blog/disk-doldu-alarmi-ilk-10-dakikada-ne-yapmali) 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](https://cilginyazilim.com/blog/geri-alma-plani-olmayan-dagitim-dagitim-degildir) önceden hazır olmasıdır.

Buradaki komut ve örneklerin nasıl hazırlandığını merak ediyorsanız [kod örnekleri SSS](https://cilginyazilim.com/blog/blog-kod-ornekleri-sik-sorulan-sorular) 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ı](https://cilginyazilim.com/blog/uretimde-log-a-ne-yazmali-ne-yazmamali) yazımız, genel alışkanlıklar için [hata ayıklamada zaman kurtaran alışkanlık](https://cilginyazilim.com/blog/hata-ayiklamada-zaman-kurtaran-aliskanlik) yazımız tamamlayıcıdır. Gözlemlenebilirlik kavramlarının ortak tanımları için [OpenTelemetry gözlemlenebilirlik girişi](https://opentelemetry.io/docs/concepts/observability-primer/) 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.

## Sıkça Sorulan Sorular

### Kök nedeni bulmadan geri almak kötü bir pratik değil mi?

Değil. Kullanıcı etkisi devam ederken araştırma yapmak, hem etkiyi uzatır hem de baskı altında yanlış karar verme olasılığını artırır. Geri alma, araştırmayı iptal etmez; yalnızca onu sakin bir ortama taşır.

### Korelasyon kimliğini nasıl kullanıcıya kadar taşırım?

Hata sayfasında kısa bir kod olarak gösterin ve destek ekibine bu kodu istemelerini söyleyin. Kullanıcının ilettiği tek bir kod, binlerce satır log arasında doğrudan ilgili isteği bulmanızı sağlar.

### Log seviyeleri nasıl ayarlanmalı?

Üretimde varsayılan olarak bilgi ve üzeri yeterlidir; hata ayıklama seviyesi disk tüketir ve gürültü yaratır. Ancak seviyeyi dağıtım gerektirmeden geçici olarak yükseltebilmek çok değerlidir — bunu yapılandırmadan okunacak şekilde kurun.

### Küçük ekipte alarm kurmak zahmetli değil mi?

Başlangıç için üç alarm yeterlidir: hata oranı, yanıt süresi ve disk doluluğu. Üçü de birkaç satırlık bir betikle kurulabilir. Alarm eksikliğinin maliyeti, sorunu kullanıcıdan öğrenmektir ve bu her zaman daha pahalıdır.

---

Kaynak: [Üretimde Bir Hatayı 10 Dakikada Daraltmanın Sistematiği](https://cilginyazilim.com/blog/uretimde-hatayi-hizli-daraltma-yontemi)