Giriş

Yerel geliştirme ortamında düzgün çalışan bir özellik, üretimde farklı koşullar altında hata verebilir. Bu farklar ortam değişkenleri, trafik yoğunluğu, veritabanı içerikleri veya servis zamanlamaları nedeniyle ortaya çıkar. Bu yüzden hatayı "yerel olarak" tekrar üretmek ve üretimdeki kanıtları (log, stacktrace, metric) dikkatlice analiz etmek kritik bir adımdır.

Bu makalede adım adım: hangi bilgileri toplamanız gerektiği, logları nasıl okumanız gerektiği, stacktrace çözümleme yöntemleri, tekrar üretme stratejileri ve üretimde güvenli tanılama yaklaşımlarını açıklayacağım. Temel ilkeler akademik ve operasyonel kaynaklarla desteklenmiştir; hata ayıklama sürecinin yapılandırılması için pratik ipuçları bulacaksınız (Harran Üniversitesi: Kodlama Debug İşlemi).

Yerelden Üretime Hata Ayıklamada Temel İlkeler

• Bağlam topla: Hatanın oluştuğu istek, zaman, sürüm, ortam değişkenleri ve kullanıcı adımlarını not edin.
• Logları merkezileştir: Üretim loglarını güvenli bir log-aggregator içinde toplamak, filtreleme ve korelasyon yapmayı kolaylaştırır.
• Tekrar üretme amacıyla minimal vaka oluşturun: Karmaşık sistemlerde önce en küçük yeniden üretilebilir senaryoyu bulun.
• Stacktrace çözümlemesinde satır ve bağlam önemlidir: Hata mesajı ve çağrı yığını, hatanın kaynağı hakkında doğrudan ipucu verir.
• Üretimde doğrudan müdahaleden önce güvenlik ve performans risklerini değerlendirin: Platforma özel tanılama araçlarını ve örnek olayları kullanın (Microsoft: IIS üretim tanılama örneği).

1. Sorunu Tanımlama: Tekrar Üretme İçin Gerekli Bilgiler

1. Adım adım kullanıcı/istemci senaryosu: Hatanın tetiklendiği tam adımlar (form alanları, buton sırası, veri girişi), mümkünse ekran görüntüsü veya curl/wget isteği örneği.
2. Ortam bilgileri: Uygulama sürümü, bağımlılık sürümleri, işletim sistemi, container imajı etiketi, konfigürasyon dosyaları (gizli anahtarları paylaşmadan).
3. Zaman damgası ve isteğe ait kimlik: Hata zamanını UTC ile, üretim log kaydındaki correlationId/traceId ile eşleştirin.
4. İlgili log ve metric kesitleri: Hata anına yakın log kayıtları, CPU/memory spike grafikleri ve isteğe ait trace dizisi.

2. Log Analizi: Ne Aranır ve Nasıl Okunur

Log analizi hem semantik hem de teknik bir iştir. Aşağıdaki unsurları özellikle arayın:

• Level: ERROR/WARN/INFO/DEBUG sıralaması; hata anında hangi seviye kayıtlarının oluştuğunu kontrol edin.
• Tarih/Zaman: Timestamps'in aynı saat diliminde ve senkronize olduğundan emin olun (UTC önerilir).
• Correlation/Trace ID: Dağıtık sistemlerde bir isteğin izini sürmek için gerekli.
• Exception mesajı ve ek bağlam: Hangi metodda hangi parametrelerle hatanın oluştuğu gibi alanlar.

Örnek yapılandırılmış log girişi (örnek amaçlı):

{"timestamp":"2023-10-15T12:34:56Z","level":"ERROR","service":"orders","message":"NullPointerException in processOrder","correlationId":"abc-123"}

Yapılandırılmış (JSON) loglar, filtrelemeyi ve otomatik alarm kurmayı kolaylaştırır. Analiz sırasında log aggregator'ınızın (ELK, Loki vb.) filtreleme ve desen eşleştirme yeteneklerini kullanın.

Stacktrace çözümleme

Stacktrace satırları genellikle hata tipini, dosya ve satır numarasını sağlar. Basit bir örnek (öğretici amaçlı):

java.lang.NullPointerException: Cannot read property 'length' of null
at com.example.service.OrderService.processOrder(OrderService.java:48)
at com.example.api.OrderController.createOrder(OrderController.java:22)

Burada öncelikli adımlar:

• İlk user-code satırını bul (örnek: OrderService.processOrder satır 48).
• O satırdaki değişkenlerin null olma ihtimalini incele; ilgili girdiler/DB sorguları o anda hangi veriyi döndürüyor kontrol et.
• Satır numarası yoksa (minified veya inlined kod), debug sembollerinin/haritaların (source maps / symbol files) mevcut olduğundan emin olun.

Genel bir yaklaşımın detayları ve hata ayıklama adımları için akademik bir derleme örneği faydalıdır (Harran Üniversitesi).

3. Tekrar Üretme Stratejileri

Tekrar üretme için pratik stratejiler:

1. Minimal reproducer: Hatanın oluştuğu en basit koşulu bulun. Karmaşıklığı azaltmak çoğu zaman problemi görünür kılar.
2. İzole test ortamı: Üretime benzeyen bir staging ortamı kurun; mümkünse aynı veri örnekleriyle test edin.
3. Mock ve stub kullanımı: Harici servisleri izole ederek, sadece uygulama içi mantığı test edin.
4. Commit araması: Hata belirli bir tarihten sonra oluştuysa "git bisect" gibi yöntemlerle değişimin hangi committe başladığını tespit edin.
5. Farklı veri ve yük koşulları: Düşük/orta/yüksek trafik senaryolarında davranışı test edin; bazı hatalar koncurrency veya race-condition kaynaklı olabilir.

4. Üretimde Güvenli Tanılama

Doğrudan üretime müdahale risklidir; bunun yerine aşağıdaki güvenli yaklaşımları tercih edin:

• Log seviyesini geçici yükseltin: Sadece ilgili servis ve kısa süre için DEBUG açmak, yeterli olabilir.
• Sampling ve rate-limit: Çok yüksek trafik altında log spam'ini önlemek için örnekleme uygulayın.
• Core dump ve heap dump analizi: Platforma özgü araçlarla (ör. IIS/Windows ortamı için Microsoft'un önerdiği tanılama araçları) üretim performans sorunlarını analiz edin; her platformun kendi güvenli tanılama rehberi vardır (Microsoft IIS rehberi).
• Feature flags / canary deploy: Düzeltmeyi küçük bir yüzdeyle yayınlayıp izleyin; regresyon riskini azaltır.

5. Kök Neden Analizi ve Kalıcı Düzeltme

Teknik düzeltmeden sonra yapılması gerekenler:

• Regression test: Hata senaryosunu kapsayan birim/entegrasyon testi ekleyin.
• Monitoring alarmları: Benzer hatalar tekrar oluştuğunda erken uyarı verecek metrik ve alertler kurun.
• Post-mortem: Olayın kısa özeti, nedenleri, alınan aksiyonlar ve önleyici tedbirleri içeren bir döküm hazırlayın.

Hızlı Kontrol Listesi (Checklist)

• Hata adımlarını ve zaman damgasını kaydet.
• İlgili logları correlationId ile filtrele.
• Stacktrace'teki ilk user-code satırını incele.
• Minimal reproducer oluştur ve test et.
• Staging'de aynı konfigürasyonla tekrar dene.
• Üretimde kısa süreli debug/verbose log açmadan önce ops onayı al.
• Düzeltme sonrası regression testi ve izleme ekle.

İleri Düzey İpuçları

• Structured logging: JSON logları tercih edin; alan bazlı arama ve alarm kurmayı kolaylaştırır.
• Correlation ID: Tüm mikroservis çağrılarında traceId kullanarak dağıtık izlemeyi etkinleştirin.
• Distributed tracing: OpenTelemetry gibi araçlarla isteğin uçtan uca izlenmesini sağlayın.
• Log enrichment: Oturum, kullanıcı ve isteğe özel meta veriler ekleyin; hatanın bağlamını hızla görmenizi sağlar.

Sonuç

Yerelden üretime hata ayıklama, sistematik bir yaklaşım gerektirir: doğru veriyi toplamak, stacktrace ve logları dikkatle analiz etmek, minimal tekrar üretmeler oluşturmak ve üretimde güvenli tanılama yöntemleri uygulamak. Bu adımların düzenli hale getirilmesi, hata çözüm süresini (MTTR) kısaltır ve uygulama güvenilirliğini artırır. Daha derin teknik rehberlik ve platforma özel örnekler için kaynaklara bakabilirsiniz (Harran Üniversitesi, Microsoft Desteği, Sunucun: WordPress örneği).

Sık Sorulan Sorular

Soru: Hata üretimde, yerelde yeniden üretilemiyorsa ne yapmalıyım?

Cevap: Üretimdeki tam istek verisini (kullanıcı adımları, timestamp, correlationId) toplayın, staging seviyesinde aynı konfigürasyon ve veriyi kullanarak test edin. Gerektiğinde üretim verisinin maskelenmiş bir kopyasını kullanarak test ortamı oluşturun.

Soru: Üretim loglarına erişmek güvenli midir?

Cevap: Loglara erişim yetki bazlı olmalı ve hassas veriler (PII, secret) maskelenmiş olmalıdır. Sadece yetkili ekiplerin erişmesi ve erişim kayıtlarının tutulması iyi bir uygulamadır.

Soru: Stacktrace'ten doğrudan kodu değiştirmek güvenli midir?

Cevap: Doğrudan üretimde kod değişikliği önerilmez. Önce yerelde veya staging'de doğrulama yapın, ardından kontrollü bir dağıtım (canary/rolling) ile yayınlayın.

Soru: Hata tekrar üretme aşamasında hangi araçlar yardımcı olur?

Cevap: Log aggregator (ELK, Loki), distributed tracing (OpenTelemetry), containerization (Docker) ve versiyon kontrol araçları (git) genellikle en faydalı araçlardır. Platforma özel tanılama araçlarını da göz önünde bulundurun.