İade/iptal sürecini loglarla kanıtlama: Net şablon + kontrol listesi

İade (refund) veya iptal (cancellation) süreçleri, çoğu kullanıcı için “süreç başlatma” ile sınırlı kalır. Oysa sağlayıcı tarafında karar genellikle teknik gerekçeye ve tutarlı kanıtlara dayanır. Bu rehberde, sunucu kiralama (VPS/VDS/dedicated) ya da yönetilen hosting kullanımlarında iade/iptal talebinizi sunucu loglarıyla nasıl destekleyeceğinizi adım adım göreceksiniz. Hangi logları toplayacağınızı, hangi zaman penceresinde arayacağınızı ve sağlayıcıya nasıl tek dosyalık paket halinde sunacağınızı net bir kontrol listesiyle vereceğim.

Bu içerik, "performansım kötüydü" gibi genel ifadeler yerine, kanıtlanabilir olay zinciri kurmanıza yardımcı olur: erişim denemeleri, servis hataları, kaynak tükenmesi, ağ kopmaları ve yönetim paneli olayları gibi.

Hangi iade/iptal durumlarında log kanıtı gerekir?

Log kanıtı her durumda şart değildir; ancak şu senaryolarda karar sürecini belirgin şekilde hızlandırır:

• Hizmet dışı kalma (downtime): Uptime iddialarıyla çelişen uzun süreli kesintiler.
• Kaynak yetersizliği: CPU/RAM/disk doluluğu yüzünden uygulamanın çalışmaması.
• Ağ sorunları: Packet loss, yüksek latency, bağlantı kopmaları.
• Kurulum/konfigürasyon iddiaları: Sağlayıcı “sorun sizde” derken sizde olay kanıtları bulunması.
• Güvenlik/erişim: Beklenmeyen yetkilendirme (authorization) hataları, saldırı yüzünden servis etkilenmesi.
• Şeffaflık: “Ödeme yaptım, ama beklediğim performans yok” durumlarında ölçüm/olay zinciri.

İade/iptal formunda genellikle alanlar sınırlıdır. O yüzden loglarla desteklenmiş, zaman damgalı (timestamp’li) anlatım en güçlü kısımdır.

“Ben yaşadım” yerine “ne zaman, ne oldu, hangi kaynaktan anlaşılıyor?”

Log kullanmanın amacı, olayın tek bir ekran görüntüsüyle değil, zaman içinde birbiriyle tutarlı verilerle ispatlanmasıdır. İstemci tarafında uygulama hatası görürsünüz; sunucu tarafında ilgili saat aralığında CPU spike, disk I/O wait artışı, kernel log’u ya da web sunucusu error’ı gibi bir karşılığı olmalıdır.

İade/iptel talebi için log toplama stratejisi (zaman penceresi şart)

Logları gelişi güzel toplamak yerine şu stratejiyi uygulayın:

1. Başlangıç saatini sabitleyin: Uygulamanın bozulduğu ilk an.
2. Bitiş saatini sabitleyin: Hizmetin düzeldiği an veya iptal/iade karar tarihi.
3. %10 tampon ekleyin: Örn. 14:00–14:30 aralığınıza 10’ar dakika tampon ekleyin.
4. UTC/yerel saat farkını yakalayın: Sağlayıcı ile aynı saat dilimini kurun. En güvenlisi hem yerel hem UTC dönüşümüyle referans vermektir.
5. Tek paket dosyası hazırlayın: Okunabilirlik için birleştirin.

Hedef: Sağlayıcı temsilcisi “Hangi dakikalarda ne oldu?” sorusuna 2 dakikada yanıt verebilsin.

Log toplarken doğruluk kontrolü

• Dosyaların boyutu büyüyebilir. Yine de sadece “ilgili saat aralığı” dışındaki kısımları ayıklayın.
• Aynı olayı birden fazla kaynaktan doğrulayın (web server error log + sistem journal + kaynak metrikleri).
• Log zaman damgalarının kaymasını önlemek için (özellikle VM’lerde) NTP/clock senkronizasyonunu da kontrol edin.

Hangi loglar “kanıt” sayılır? (VDS/VPS/dedicated için pratik liste)

Aşağıdaki listeyi, iade/iptal nedeninize göre seçerek kullanın. Bu başlık “her logu atın” demek değil; ilişkili olanları toplamanız gerektiğini anlatır.

1) Sistem olayları (downtime ve servis çökmesi)

• Systemd journal (Ubuntu/Debian/modern Linux): journalctl çıktıları
• Kernel log: OOM (Out of Memory), disk/IO hataları, network driver olayları
• cron / uyarı event’leri: planlı restart veya bakım varsa

Kanıt olarak özellikle şu anahtar kelimeler işe yarar: - OOM, out of memory - disk error, I/O error - segfault - network unreachable, link down

2) Uygulama ve web sunucusu logları (hizmetin erişilememesi)

• Nginx: access.log ve error.log
• Apache: error_log
• Uygulama (Node.js, PHP, Java): uygulama hata stack trace’leri

Öneri: İade/iptal için en kritik olanlar şunlardır: - Hata oranı (örn. 500’ler) - Bağlantı reddi (connection refused) - Timeout (upstream timed out)

3) Kaynak tükenmesi (performans ve “çalışmıyor” iddiası)

• O anlarda CPU spike / load artışı
• RAM tükenmesi (OOM)
• Disk doluluğu (filesystem full)
• Disk I/O wait (I/O darboğaz)

Kanıt üretmek için iki yol vardır: 1. Sağlayıcının metrik paneli (varsa) 2. Sizin topladığınız sistem metrikleri (ör. sar, vmstat, iostat çıktıları)

4) Ağ sorunları (packet loss / yüksek latency)

• Uzak servis çağrılarında timeout
• İç ağda DNS/route sorunları
• Packet loss gözlemi (mümkünse)

Kanıt olarak: - Uygulama loglarında timeout/ETIMEDOUT - Sunucu tarafında bağlantı kopmalarının kaydı

5) Panel/sağlayıcı aksiyonları (restart, migrate, değişiklik)

İade/iptal tartışmalarında sağlayıcı tarafında “şu işlem yapıldı” gerekçesi sık geçer. Bu yüzden kontrol paneli olaylarını saklayın: - VM restart (otomatik veya manuel) - snapshot/backup restore - network reconfigure - hardware maintenance gibi etiketler

Sunucu loglarını sağlayıcıya iletilecek hale getirme (paketleme standardı)

Sağlayıcı ekipleri için en büyük düşman: dağınık dokümanlar ve belirsiz zaman aralıklarıdır. Aşağıdaki formatı uygulayın.

Minimum iade/iptal log paketi (örnek yapı)

• README.txt: Sorun özeti + zaman penceresi + saat dilimi
• system/: journal ve kernel logları
• web/: nginx/apache error + access (gerekli bölümler)
• app/: uygulama hataları
• metrics/: kaynak metrikleri (varsa)
• screenshots/: zorunlu ekran görüntüleri (log yerine değil, destek olarak)

README.txt içinde bulunması gereken alanlar

• Hizmet türü: VDS/VPS/dedicated
• Sunucu adı veya ID
• Etkilenen domain/uygulama URL
• Olay başlangıç-bitiş: ör. 2026-10-01 14:00-14:30 (TRT, UTC+3)
• Neden iade/iptal istediğiniz: tek cümlelik teknik gerekçe
• Logların ilgili klasör listesi

Zaman çizgisi (timeline) tablosu: taleplerde fark yaratır

Sağlayıcı temsilcisine tek sayfada netlik sağlayan yapı şudur:

Bu tablo, “sorun neydi” sorusunu tartışmaya kapatır.

İade/iptal metninde logları nasıl kullanmalısınız? (kanıt dili)

Logları iletmek tek başına yetmez; metin içinde logları bir argüman gibi bağlamak gerekir.

İyi örnek (kanıt odaklı iskelet)

• “2026-10-01 14:00-14:30 aralığında, app.example.com için HTTP 502/timeout hataları oluştu. Bu hatalar nginx error.log içinde 14:05 sonrası yoğun. Aynı saat aralığında kernel loglarında OOM kill kaydı var. CPU/load artışı metrics dosyalarında görülüyor.”

Kötü örnek (genel ifade)

• “Sunucu yavaş ve sürekli kesiliyor. İade istiyorum.”

Genel ifade, sağlayıcının “ölçüm yok, zaman belirsiz” yanıtını kolaylaştırır. Kanıt dili ise reddedilmesi zor bir çerçeve kurar.

VDS/VPS alırken “logları saklayacak düzen” oluşturma (bugünden hazırlık)

İade/iptal başvurusu bazen beklenmedik şekilde gelir. Bu yüzden şu düzeni daha baştan kurmak, ileride saat kazandırır.

1) Log rotasyonu ve saklama süresi

• Sistem logları otomatik rotasyon yapar ancak iade talebi için yeterli süreyi kontrol edin.
• logrotate ayarlarında, en az olay tarihinden birkaç gün sonrasını kapsayın.

2) Uygulama hatalarını merkezi kayıt altına alma

• Uygulama loglarını dosyaya yazın.
• Hata stack trace’lerini ezmeden saklayın.

3) Kaynak metriklerini düzenli örnekleme

• O anı yakalamak için kısa aralıklarla örnekleme faydalıdır.
• Sağlayıcının panelinde metrik görseniz bile, sistem tarafı metriklerinin referansı ayrıca güç verir.

4) Saat senkronizasyonu

• VM içinde NTP/chrony senkronizasyonu düzgün olmalı.
• Aksi halde log zamanları “kaymış” görünebilir ve itiraz uzar.

Kontrol listesi: iade/iptal talebinde son kez doğrulayın

Aşağıdaki listeyi doldurun. Eksik madde varsa önce tamamlayın.

• [ ] Sunucu ID / hizmet adı yazıldı
• [ ] İlgili tarih-saat aralığı net ve saat dilimi belirtilmiş
• [ ] nginx/apache error loglarından ilgili satırlar seçildi
• [ ] Uygulama hata logu (stack trace) eklendi
• [ ] Sistem journal veya kernel loglarında kritik olay var (örn. OOM, I/O error)
• [ ] CPU/RAM/disk doluluğu ile ilgili metrik veya ekran görüntüsü var
• [ ] Timeline tablosu eklendi
• [ ] Panelde yapılan restart/migration gibi aksiyonların kanıtı var (varsa)
• [ ] README ile klasör yapısı açık
• [ ] Loglar tek zip dosyası halinde gönderildi

Sonuç: Log paketi + timeline ile iade/iptal kararını hızlandırın

İade/iptal süreçleri, “şikayet” ile “teknik kanıt” arasındaki fark yüzünden uzar. Doğru zaman penceresi, ilişkili web/app/system logları ve tek sayfalık timeline, sağlayıcının inceleme süresini kısaltır ve itiraz ihtimalini azaltır. Aksiyon olarak: Önce olay başlangıç-bitiş aralığını sabitleyin, ardından web error log + sistem journal/kernel + kaynak metriği üçlüsünü oluşturup README ile tek pakette gönderin.

İsterseniz mevcut sunucu tipinizi (VPS/VDS/dedicated), kullandığınız işletim sistemini (Ubuntu/CentOS/Windows) ve yaşadığınız sorunu (downtime, performans düşüşü, ağ kopması vb.) yazın; hangi logların “zorunlu” olduğunu daha da net bir paket taslağına dönüştüreyim.