Production hataları genellikle “tek bir bug” değil; sürüm değişikliği, bağımlılık davranışı, veri anormalliği, kapasite sınırı veya konfigürasyon farklarının birleşimi olarak ortaya çıkar. Bu yüzden üretimde hızlı hata ayıklama (debugging) bir “tek araç” işi değildir: doğru loglar, doğru bağlam (context), doğru korelasyon ve doğru uyarı tasarımı birlikte çalışmalıdır.

Bu yazı; yapılandırılmış (structured) loglama, trace/metric ile korelasyon, güvenli log yönetimi ve monitoring + SLO-temelli alerting ile MTTR’yi (onarım süresi) düşürmeye odaklanan pratik bir rehberdir. Teknik kavramları sade tutup, ekiplerin doğrudan uygulayabileceği kontrol listeleri ve örnek şemalar ekledim.

1) Üretimde hızlı teşhis için “gözlemlenebilirlik” (observability) yaklaşımı

Üretimde hata ayıklamanın amacı yalnızca hatayı “görmek” değil, kök nedeni doğrulanabilir sinyallerle bulmaktır. Bu noktada üç ana sinyal genellikle birlikte kullanılır:

• Loglar: Olayın detayını ve iş bağlamını taşır.
• Metric’ler: Eğilimleri ve anormallikleri hızla görünür kılar (ör. gecikme, hata oranı).
• Trace’ler: Dağıtık sistemlerde bir isteğin uçtan uca yolculuğunu gösterir.

Modern ekipler için kritik nokta, bu sinyallerin “ayrı ayrı” iyi olması değil; birlikte aranabilir ve ilişkilendirilebilir olmasıdır. OpenTelemetry’nin log veri modeli ve korelasyon alanları (ör. TraceId/SpanId) özellikle bu amaçla tasarlanır. Referans: OpenTelemetry Logs spesifikasyonu.

2) Loglama temelleri: Önce “amaç” ve “okunabilirlik”

İyi loglar iki ihtiyaca aynı anda hizmet eder:

• İnsan odaklı: Olayı okuyanın hızlı anlaması için kısa, net bir mesaj.
• Makine odaklı: Filtreleme, arama, korelasyon ve alarm üretimi için tutarlı alanlar.

Bu yüzden serbest metin (free-text) loglar yerine yapılandırılmış (çoğunlukla JSON) loglama tercih edilir. Yapılandırılmış loglar, sorgulanabilir alanlar sayesinde teşhis süresini pratikte azaltmaya yardımcı olur. Uygulama odaklı bir özet için: Structured logging best practices (Mezmo).

2.1 Yapılandırılmış log için minimum alan seti

Her ekip kendi şemasını zenginleştirebilir; ancak üretimde hızlı arama için aşağıdaki alanlar başlangıçta çok iş görür:

• timestamp (UTC tercih edilir)
• severity (INFO/WARN/ERROR gibi)
• service.name (hangi servis?)
• environment (prod/stage)
• message (insan-okunur kısa açıklama)
• event.name veya event.type (tutarlı sınıflandırma)
• request_id (varsa)
• trace_id ve span_id (dağıtık sistemlerde kritik)
• error alanları (error.type, error.message, stack gibi; dil/çerçeveye göre)

2.2 Örnek log kaydı (şema örneği)

Aşağıdaki tablo, serbest metin yerine alan bazlı aramayı kolaylaştıran örnek bir log kaydını gösterir (alan isimleri ekibin standardına göre değişebilir):

3) Log–trace korelasyonu: Dağıtık sistemlerde “en hızlı yol”

Mikroservislerde “tek bir isteğin” hangi servislerden geçtiğini bilmeden teşhis zorlaşır. OpenTelemetry, log kayıtlarına TraceId ve SpanId ekleyerek logların trace’lerle ilişkilendirilmesini standartlaştırır. Bu sayede bir hata logundan ilgili trace’e, oradan da diğer servislerdeki gecikme/hata noktalarına geçebilirsiniz. Referans: OpenTelemetry Logs.

3.1 Pratik uygulama adımları

1. Servislerde tracing’i etkinleştirin: HTTP/gRPC girişinde trace context üretilsin/taşınsın.
2. Logger ile tracing bağlamını bağlayın: Log üretirken mevcut trace/span kimliklerini otomatik ekleyin.
3. Collector/pipeline tarafında alanları koruyun: Dönüşüm (transform) adımlarında trace_id/span_id kaybolmasın.
4. Log arama arayüzünde “trace’e git” akışını kurun: Operasyonel hız için kritik bir UX adımıdır.

4) Log seviyeleri, maliyet ve gürültü: DEBUG’u üretimde nasıl yönetmeli?

Üretimde tüm DEBUG detaylarını sürekli toplamak çoğu ekip için pratik olmayabilir: hem maliyet hem de “gürültü” artar. Yaygın yaklaşım; severity filtering, rate limiting ve gerektiğinde sampling uygulamaktır. Bu konudaki genel yönlendirmeler için OpenTelemetry’nin log yaklaşımı ve structured logging pratikleri faydalı bir başlangıç sağlar: OpenTelemetry Logs, Mezmo structured logging.

4.1 Pratik stratejiler

• Default seviyeyi sade tutun: Prod’da genelde INFO/WARN/ERROR ağırlıklı başlamak, sonra veriyle ayarlamak daha güvenlidir.
• “Anomali anında detay” yaklaşımı: Her zaman ayrıntı yerine; hata oranı artınca belirli bir süre daha detaylı log açma gibi kontrollü mekanizmalar düşünün.
• Tekrarlı hata loglarını sınırlayın: Aynı hatayı saniyede yüzlerce kez yazmak teşhisi hızlandırmayabilir; rate limit iş görür.
• Yük testleriyle doğrulayın: Log hacmi, I/O ve CPU üzerinde etkili olabilir; değişiklikleri ölçerek devreye alın.

5) Merkezi log pipeline tasarımı: Toplama, filtreleme, saklama, erişim

Üretimde hızlı teşhis kadar, logların güvenli yönetimi de önemlidir. NIST’in log yönetimi rehberi; merkezi toplama, saklama, zaman senkronizasyonu, erişim kontrolü ve süreçlerin planlanması gibi kurumsal pratikleri ele alır: NIST SP 800-92.

5.1 Basit bir referans mimari

• Uygulama → stdout / dosya / agent
• Collector/agent → parse, enrich (service/env), filtre/sampling, PII maskeleme
• Transport → güvenli aktarım, kuyruklama/buffer
• Storage & index → arama ve saklama politikaları
• Access control → rol bazlı erişim, audit izleri

5.2 Zaman senkronizasyonu ve olay sıralaması

Dağıtık sistemlerde “hangi olay önce oldu?” sorusu teşhisin merkezindedir. NIST, log yönetimi kapsamında zaman tutarlılığı ve logların güvenilir analizini destekleyen süreçlerin önemini vurgular. Bu nedenle UTC tabanlı timestamp, tutarlı saat senkronizasyonu ve servisler arası korelasyon alanları (trace_id, request_id) birlikte düşünülmelidir. Referans: NIST SP 800-92.

6) Güvenli loglama: PII, kimlik bilgileri ve log enjeksiyonu riskleri

Loglar, tanım gereği “olan biteni” kaydeder; ancak güvenlik açısından en riskli veri sızıntıları da loglar üzerinden gerçekleşebilir. OWASP, güvenli loglama için özellikle şu riskleri öne çıkarır: PII/secret yazılması, log enjeksiyonu, yetkisiz erişim ve yetersiz maskeleme. Referans: OWASP Logging Cheat Sheet.

6.1 Kesin kural: Gizli veriyi loglamayın

• Şifreler, erişim anahtarları, API token’ları, oturum bilgileri
• Kişisel veriler (PII) ve hassas kimlik verileri
• Ödeme veya kritik kimlik doğrulama verileri

Uygulamada bu kuralı sürdürülebilir kılmak için:

• Merkezi redaction/maskeleme: Sadece uygulama koduna güvenmek yerine collector/pipeline katmanında da maskeleme uygulayın.
• Allowlist yaklaşımı: Log’a yazılacak alanları allowlist ile sınırlamak, “yanlışlıkla yazma” riskini düşürür.
• Erişim kontrolü: Log arama sisteminde rol bazlı erişim ve denetim izi (audit) önemlidir.

Bu bölüm güvenlik farkındalığı içindir; uyumluluk veya regülasyon yorumları için kurumunuzun güvenlik/hukuk ekiplerinden görüş alın.

6.2 Log enjeksiyonunu azaltma

OWASP; kullanıcı girdilerinin log formatını bozarak sahte satırlar/alanlar üretebileceği riskine dikkat çeker. Pratikte şu önlemler yardımcı olur:

• Yapılandırılmış log: Serbest metin yerine alan bazlı kayıt, enjeksiyon etkisini azaltır.
• Kaçış/normalize: Kullanıcı girdilerini doğrudan “message” içine koymak yerine ayrı alanlarda tutun.
• Log arama tarafında güvenlik: Yetkilendirme, anomali tespiti ve kayıt bütünlüğü süreçleri.

Referans: OWASP Logging Cheat Sheet.

7) Monitoring ve alerting: SLO odaklı uyarılarla “alarm yorgunluğunu” azaltma

Uyarılar (alerts) doğru tasarlanmazsa ekipler sürekli “gürültü” ile uğraşır. Sektörde yaygın eğilim; uyarıları SLO (Service Level Objective) ve kullanıcı etkisi etrafında tasarlamak, diğer sinyalleri ise dashboard/analiz için kullanmaktır. Observability ve platform kalitesi ilişkisini tartışan sektör değerlendirmeleri bu yaklaşımı destekler: Honeycomb (DORA perspektifi).

7.1 SLO-temelli alerting için pratik çerçeve

• Paging (acil) uyarılar: Kullanıcı etkisi yüksek ve aksiyon gerektiren durumlar (ör. hata bütçesi hızlı eriyor).
• Ticket (planlı) uyarılar: Trend bozulması veya kapasite yaklaşımı gibi orta aciliyetli sinyaller.
• Bilgilendirme: Dağıtım sonrası metrik değişimleri gibi durumlar.

Bu ayrım, on-call yükünü azaltıp hataya odaklanmayı kolaylaştırır. Uyarı tasarımını postmortemlerde düzenli olarak gözden geçirmek de iyi bir pratiktir: Atlassian postmortems rehberi.

8) Üretimde hata ayıklama akışı: Adım adım “triage → teşhis → doğrulama”

Aşağıdaki akış, farklı ekip ve teknoloji yığınlarına uyarlanabilir bir iskelet sunar:

8.1 Triage (ilk 15–30 dakika)

• Etkisini tanımlayın: Hangi kullanıcılar/iş akışları etkileniyor?
• Son değişikliklere bakın: Deploy, feature flag, config değişimi, bağımlılık sürümü.
• Birincil sinyali seçin: SLO ihlali mi, hata oranı mı, gecikme mi?
• İlk hipotezleri yazın: 2–3 olası kök neden (örn. dış servis timeout, DB bağlantı havuzu).

8.2 Teşhis: Log + trace ile daraltma

• Önce filtre: service.name, environment, severity=ERROR, endpoint/route, region/cluster.
• Sonra korelasyon: Aynı trace_id üzerindeki diğer servis loglarına ve trace zaman çizgisine geçin.
• Hata sınıflandırma: error.type / exception adı / HTTP status dağılımı.
• Bağlam alanları: request_id, customer_tier gibi (PII içermeden) iş bağlamı alanları.

OpenTelemetry log modelinde korelasyon alanlarının amacı tam olarak bu “logdan trace’e” geçişi standartlaştırmaktır. Referans: OpenTelemetry Logs.

8.3 Doğrulama: Düzeltme gerçekten işe yaradı mı?

• Fix sonrası metrik: Hata oranı ve gecikme normale dönüyor mu?
• Log sinyali: Aynı error.type tekrar ediyor mu, azaldı mı?
• Geri dönüş planı: Rollback/disable gibi güvenli geri dönüş yolu hazır mı?

9) Runbook ve olay yönetimi: Süreç, araç kadar önemli

Olay anında herkesin “ne yapacağını” bilmesi, üretimde hata ayıklamayı ciddi ölçüde hızlandırır. CISA’nın incident response plan (IRP) temelleri, kurumların olay müdahalesi için planlı yaklaşım benimsemesini önerir: CISA IRP Basics.

9.1 Minimum runbook şablonu

• Belirti: Hangi alarm/durum bu runbook’u tetikler?
• İlk kontrol: İlgili dashboard ve temel sorgular (log/metric/trace).
• Daraltma adımları: Hangi alanlarla filtrelenecek (service, route, region)?
• Güvenli müdahale: Feature flag kapatma, trafik azaltma, rollback.
• İletişim: Kime/escalation nasıl yapılır?
• Sonlandırma kriteri: “Olay bitti” ne demek?

10) Postmortem: Tekrarı azaltmak için “blameless” öğrenme döngüsü

Olay söndükten sonra asıl değer, öğrenmeyi kalıcı hale getirmektir. Blameless postmortem yaklaşımı, bireyleri suçlamak yerine sistem ve süreç iyileştirmelerine odaklanır. Atlassian’ın incident yönetimi rehberinde postmortemlerin yapılandırılması ve eylem maddelerine bağlanması anlatılır: Atlassian postmortems. CISA da olay sonrası adımların planlı olmasını destekler: CISA IRP Basics.

10.1 Pratik postmortem kontrol listesi

• Zaman çizelgesi: Alarm → tespit → müdahale → çözüm adımları
• Kök neden(ler): Teknik + süreç kök nedenleri ayrı yazın
• Yakalanabilir miydi? Hangi sinyal/alert daha erken yakalardı?
• Eylem maddeleri: Sahip, tarih, doğrulama kriteri
• İyileştirme: Log alanı eksik mi? Trace yok mu? Runbook mu güncellenecek?

11) AI destekli debugging: Nerede işe yarar, nerede dikkat gerekir?

AI destekli araçlar; olay triage’ı, benzer olayları bulma, runbook önerisi ve RCA (root cause analysis) taslakları üretme gibi alanlarda yardımcı olabilir. Ancak bu tür sistemler; doğruluk, veri gizliliği ve otomasyon güvenliği gibi riskleri de beraberinde getirebilir. Konuyu tartışan bir perspektif için: Rootly (AI-assisted debugging).

Pratik öneri: AI çıktısını insan onayı olmadan otomatik aksiyona dönüştürmeyin; ayrıca AI’ya gönderilen log/trace verilerinde PII ve gizli bilgi bulunmaması için OWASP/NIST ilkelerine uygun filtreleme uygulayın. Referans: OWASP Logging Cheat Sheet, NIST SP 800-92.

12) Hızlı uygulama planı: 2 haftalık “temel seviye” yol haritası

Hafta 1: Log kalitesi ve güvenlik

• Yapılandırılmış log formatına geçin (en azından kritik servisler).
• Ortak alan setini standardize edin (service/env/severity/trace_id).
• PII/secret redaction kurallarını uygulayın (uygulama + pipeline).
• Log seviyeleri için başlangıç politikasını yazın (prod default + istisnalar).

Hafta 2: Korelasyon, arama ve uyarı tasarımı

• Trace context taşımasını ve log-trace korelasyonunu doğrulayın.
• En sık 5 hata senaryosu için hazır sorgular ve dashboard oluşturun.
• SLO odaklı paging uyarılarını tanımlayın; gürültü üreten alarmları azaltın.
• Minimum 3 runbook yazın (en sık alarmlar için).

13) Kısa özet: Production’da daha hızlı debug için “olmazsa olmazlar”

• Yapılandırılmış loglama ile arama/korelasyon hızlanır. (Bkz. Mezmo)
• TraceId/SpanId korelasyonu dağıtık hatalarda teşhisi ciddi kolaylaştırır. (Bkz. OpenTelemetry)
• Güvenli loglama: PII ve secret’lar loglanmaz; erişim kontrollüdür. (Bkz. OWASP)
• Merkezi log yönetimi: toplama, saklama, süreç ve zaman tutarlılığı planlanır. (Bkz. NIST SP 800-92)
• SLO-temelli alerting ve blameless postmortem öğrenmeyi hızlandırır. (Bkz. Honeycomb, Atlassian)