İade/iptal süreçlerini sunucu loglarıyla kanıtlama rehberi

İade (return) veya iptal (cancellation) süreçleri çoğu zaman “hizmet beklenen performansı vermedi” gibi soyut ifadelerle uzuyor. Oysa sunucu tarafında zaman damgalı (timestamp) loglar ve ölçülebilir metrikler, iddianızı netleştirir ve karşı tarafın inceleme süresini kısaltır. Bu rehberde, VDS/VPS/dedicated sunucu veya yönetilen hosting hizmetlerinde sorun yaşadığınızda nasıl delil toplayacağınızı adım adım öğreneceksiniz. Hedef: Talep dosyanızda “hangi gün-saat aralığında ne oldu, hangi bileşen etkilendi” sorularına doğrudan cevap veren kanıt seti oluşturmak.

1) İade/iptal talebinde hangi kanıtlar işe yarar?

İade/iptal incelemeleri genellikle iki eksende ilerler: - Sözleşme/ilan edilen özellik ile gerçekleşen durumun kıyaslanması (CPU/RAM/Disk/IO/Network, erişilebilirlik, hata oranı) - Sorunun zaman aralığı ve etkilediği bileşenlerin net gösterimi (web/app kesintisi, servis çökmesi, bağlantı reddi, yüksek hata kodları)

Bu yüzden kanıt olarak şunları hedefleyin: - Sistem logları: kernel, systemd, uygulama servisleri (nginx, apache, php-fpm, docker, agent) - Web/app erişim kayıtları: status code oranları (200/4xx/5xx), request süreleri - Kaynak metrikleri: CPU/RAM kullanımı, load, disk I/O bekleme, ağ bant genişliği - Zaman doğrulama: logların NTP ile senkron olduğunun kanıtı

Not: “Ekran görüntüsü” yerine dosya tabanlı log ve metrik tercih edin. Görsel kanıt tek başına denetimsiz kalabilir; dosya tabanlı kanıt ise süreçte referans alınabilir.

Kanıt seti için pratik hedef

Talep mesajınıza tek paket halinde şunları koyun: - Olayın başladığı ve bittiği tarih-saat aralığı (örn. 2026-09-03 20:15-21:10 TRT) - Aynı aralıkta oluşan kritik hataların log satırları - Kaynak kullanım metriklerinden en az 1 grafik veya özet - Eğer varsa istek reddi/5xx artışı gösteren erişim logları

2) Başlamadan önce: zaman senkronu ve dosya standardı

Logların işe yaraması için iki koşul kritiktir: doğru saat ve doğru format.

NTP/saati doğrulayın (timestamp tutarlılığı)

Sunucunuzun saatini ilk önce doğrulayın. Linux’ta tipik kontrol: - timedatectl status çıktısını alıp saklayın. - Bulunduğunuz saat dilimine göre loglarda fark oluşuyorsa, bunu dosyada açıkça belirtin.

Eğer sorun yaşadığınız anlarda saat kayması varsa, karşı taraf logları “başka saate denk geliyor” diye reddedebilir.

Dosya standardı: aralık ve isimlendirme

Delil toplarken dosyaları tutarlı isimlendirin. Örnek şablon: - issue_YYYY-MM-DD_start-end_trt_service.log - metrics_YYYY-MM-DD_start-end_cpu_ram_io.txt

Böylece inceleyen kişi “hangi dosya hangi olayı anlatıyor” sorusunu sormadan ilerler.

3) Sistem ve servis logları: en güçlü omurga

Sunucu tarafında yaşanan çoğu kesinti/performans sorunu servis loglarında iz bırakır.

systemd servis logları (nginx/apache/php-fpm vb.)

Servisiniz systemd ile çalışıyorsa, olay aralığına göre sorgu yapın.

Hedef: Olay zamanında şu tip kayıtları görmek: - servis yeniden başlatma (restart) - hata/çökme (crash, segfault) - upstream timeouts - permission/limit aşımı (ulimit, file descriptor limit)

Uygulanabilir sorgu yaklaşımı: - Olayın başlangıç-bitiş aralığını belirleyin. - O servis için yalnızca o aralığı kapsayan log satırlarını çıkarın.

İade talebine koymak için en az 20-50 satırlık “yoğun hata bölümü” yeterlidir; binlerce satır yerine özlü ve doğrudan alan parçaları daha etkilidir.

Kernel / OOM / disk/IO uyarıları

Performans iddiasını güçlendiren log türleri: - OOM (Out Of Memory) belirtileri: süreç öldürülmesi - disk doluluğu (ENOSPC), inode bitmesi - IO starvation uyarıları - network düşüşleri, “packet loss”, “connection reset” kalıpları

Bu kısım özellikle “sunucunun kaynakları yetersiz” veya “hizmet sürekliliği” konularında belirleyicidir.

Dosya tabanlı örnek çıktı yapısı

Talep paketinizde şu formatı koruyun: - --- service logs (20:15-21:10 TRT) --- - ... log satırları ... - --- summary --- - Özet: nginx upstream timeout oranı arttı, php-fpm restart oldu, OOM kaydı var.

4) Web/app erişim loglarıyla performans farkını ölçün

Logların en somut yanı, kullanıcı trafiğiyle yaşanan hatayı status code ve süreyle ilişkilendirmektir.

Nginx erişim logları: 5xx ve timeout kanıtı

Erişim loglarından şu metrikleri çıkarın: - 5xx oranı (500/502/503/504) - belirli uç noktalarda artan hata - upstream timeouts - request süre dağılımı

Basit hedef tablo: - Olay öncesi 30 dk - Olay anı 30-60 dk - Olay sonrası 30 dk

Bu karşılaştırma, “tek seferlik anomali mi, sistematik mi?” ayrımını netleştirir.

Apache ve uygulama logları

Apache kullanıyorsanız 4xx/5xx ve vhost bazında dağılımı çıkarın. Uygulama tarafında (ör. Laravel/Node/Python) da şu kanıtları ekleyin: - exception stack trace - retry/batch işlemlerinin başarısız olması - veritabanı bağlantı timeout

WAF/CDN varsa: hangi katmanın hatalı olduğunu ayırın

Sunucunuz arkasında CDN/WAF varsa yalnızca origin loglarına bakmak yanıltıcı olabilir. Talep dosyanıza şu notu ekleyin: - Sorun CDN tarafında mı geldi, origin’de mi? - İstekler origin’e ulaştı mı?

Net ayırım için mümkünse: - CDN edge logu (varsa) - origin nginx/apache access log

5) Kaynak metrikleri: CPU/RAM/Disk/Network iddiasını somutlaştırın

İade/iptal sürecinde karşı tarafın en çok aradığı şeylerden biri “ölçüm”dür. En azından olay aralığında şu özetleri çıkarın: - CPU: average, peak (ve mümkünse steal time) - RAM: kullanıldı/boş, swap kullanımı - Disk I/O: wait süreleri, yoğun okuma/yazma - Network: inbound/outbound bant genişliği, bağlantı sayısı

Swap ve bellek baskısı

Yetersiz bellek performansını ciddi etkiler. Eğer loglarda OOM varsa veya swap kullanımı yükseldiyse bunu paketleyin.

İşin net tarafı: “Swap artışı ve ardından 5xx artışı” gibi bir zinciri kanıtlamak.

Disk doluluğu ve inode problemi

Disk dolulukları sadece storage’ı değil servisleri de kilitleyebilir. - “Disk kullanımının %90+ olduğu anlarda servis loglarında hata” örüntüsü - inode tükenmesi belirtileri

VDS/VPS’de throttling/limit etkisi

Bazı altyapılarda kaynak paylaşımı veya oversubscription etkisi görülebilir. Elde edilebilir kanıtlar: - CPU kullanımı yükselirken servis gecikmesinin artması - steal time (hypervisor kaynak alıkoyması) artışı

Bu tarz metrikleri istiyorsanız, sunucu kontrol panelinde (veya agent ile) tutulan ölçümleri de talep paketine ekleyin.

6) Kontrol paneli/altyapı kayıtları: tek taraflı iddiayı dengeleyin

İletişim tarafında “bizde öyle bir şey yok” cümlesini kırmanın yolu, altyapı kayıtlarını da kullanmaktır.

Sağlayıcı kontrol paneli (billing/instance) kayıtları

Şunları ekleyin: - yeniden başlatma (reboot) yapıldı mı? - ağ ayarı değişti mi? - otomatik kurtarma (auto-recovery) denendi mi?

Eğer sağlayıcı “zaten reboot olmuş” derse, sizin loglarınız servis etkisini doğrular ya da zaman çizelgenizi düzeltir.

Yönetilen servis/agent kullanıyorsanız

Bazı sağlayıcılar metrikleri otomatik toplar. O zaman: - olay aralığı seçin - grafik ekran görüntüsü yerine mümkünse veri tabanlı dışa aktarma (CSV/Export) varsa onu talep dosyasına koyun.

7) Paketi nasıl hazırlamalısınız? (kopyala-yapıştır mantığı)

Başarılı bir iade/iptal talebi “tek e-posta” değil, inceleyen kişinin hızlıca doğrulayacağı bir dosya setidir.

Önerilen dosya içeriği listesi

Aşağıdaki listeyi talep paketinizin çekirdeği yapın: - timedatectl_status.txt - issue_timeline.txt (olay sıralaması) - systemd_service_logs.txt (ilgili servis: nginx/php-fpm/app) - kernel_oom_disk_network_logs.txt - web_access_logs_summary.txt (5xx oranı ve zaman dilimi) - resource_metrics_summary.txt (CPU/RAM/IO/network) - control_panel_events.txt (reboot/limit/ağ değişimi var/yok)

Olay zaman çizelgesi örneği (özet metin)

Talep mesajınızda şu format çok işe yarar: - 20:15: Uygulamada 502/504 artışı - 20:18: nginx upstream timed out yoğunluğu - 20:22: php-fpm restart kaydı - 20:30: OOM log kaydı (veya swap artışı) - 21:10: servis normalize oldu

Bu metin, karşı tarafın logları “rastgele” taraması yerine “aynı sırayla” incelemesini sağlar.

8) Karşı tarafın itiraz ettiği yaygın noktalar ve net cevap stratejisi

“Loglar bizimle aynı zamanla değil” itirazı

Çözüm: - timedatectl kaydı - logların başındaki zaman damgaları - olay aralığını TRT ile net yazma

“Sorun sizin uygulamanızdan” itirazı

Çözüm: - nginx 5xx artışıyla eşzamanlı servis hataları - kaynak metrikleriyle performans çöküşünü bağlama - uygulama loglarında da hatayı desteklemek

“İş yükü arttı” itirazı

Çözüm: - erişim loglarında request sayısı ve 5xx oranı - kaynak metriklerinde throttling ve bekleme artışı - “yük artışıyla orantısız hata” gösterimi

9) İade/iptal sürecinde iletişim dili: teknik ama ölçülebilir

Logları gönderirken mesaj metni şu üç parçayı içermeli: 1) Ne talep ediyorsunuz? (iade/iptal) 2) Hangi aralıkta sorun yaşandı? 3) Hangi log/metrikler kanıt?

Örnek mesaj iskeleti (kendi bilgilerinizi doldurun): - “20:15-21:10 TRT aralığında nginx erişim loglarında 502/504 artışı (normal aralık: %0.2, olay aralığı: %7.5) tespit ettim. Aynı aralıkta php-fpm restart kaydı ve kernel tarafında OOM uyarısı bulunuyor. Zaman senkronunu timedatectl çıktısıyla doğruladım. Bu nedenle hizmet performansının ilan edilen SLA/özellikleri karşılamadığını düşünüyorum.”

Böyle bir yapı, “duygusal açıklama” değil “ölçülebilir rapor” olarak algılanır.

10) Aksiyon önerisi: şimdi uygulayabileceğiniz 15 dakikalık plan

Bugün/şimdi, bir sonraki talepte zaman kazanmak için şu planı uygulayın: - 1) Olay yaşadığınız gün-saat aralığını TRT ile yazın. - 2) timedatectl status kaydını alın. - 3) En az bir servis için (nginx/php-fpm/app) olay aralığı loglarından hata bloğunu çıkarın. - 4) Nginx/Apache access loglarında 4xx/5xx özetini çıkarın ve olay öncesi/olay arası karşılaştırın. - 5) CPU/RAM/IO için olay aralığında özet metrikleri alın (panel/agent varsa dışa aktarın). - 6) Dosyaları isimlendirip bir klasöre koyun: “issue paketiniz”.

Son olarak, iade/iptali konuşmaya başlamadan önce “tek paketlik kanıt seti” hazırlayın. Bu yaklaşım hem inceleme süresini kısaltır hem de sağlayıcı ile görüşmelerde aynı verileri tekrar tekrar aramayı engeller.