eBay Otomasyon Hata Yönetimi: Kill Switch, Audit Log ve Güvenli Retry Tasarımı

eBay otomasyon hata yönetimi, job başarısız olduğunda Slack mesajı almak değildir. Asıl hedef yanlış bir işlemin kaç ilana, kaç hesaba ve kaç siparişe yayılabileceğini önceden sınırlandırmaktır. Supplier fiyat parser'ı virgülü yanlış okuduğunda sistem teknik olarak “başarılı” çalışabilir; fakat £39.99 ürünleri £3.99'a günceller. HTTP 200 kalite kanıtı değildir.

Otomasyon stack'i büyüdükçe sessiz hata olasılığı artar: scheduler çalışır fakat eski veriyi okur, webhook iki kez gelir, retry aynı siparişi tekrar işler, AI var olmayan özelliği onaylar veya API bazı satırları reddederken batch'in geri kalanı yayınlanır. AI agent ve kural tabanlı otomasyon karşılaştırması karar motorunu tartışır; bu rehber karar yanlış veya eksik olduğunda hasarı durduracak operasyon katmanını kurar.

Başarı metriği uptime değil güvenli sonuçtur

Bir fiyat sync job'ının her saat çalışması etkileyici görünebilir. Fakat son başarılı supplier fetch üç gün önceyse sistem eski maliyetle ilan güncelliyordur. “Job completed” metriği, veri tazeliği ve iş sonucu ile birlikte okunmalıdır.

Her otomasyon için üç ayrı sağlık sinyali gerekir:

• Execution health: Job başladı mı, bitti mi, ne kadar sürdü?
• Data health: Kaynak veri güncel, tam ve beklenen aralıkta mı?
• Business health: Değişiklik marjı, quantity'yi, teslimat sözünü ve hesap politikasını koruyor mu?

Bu üç katmandan biri başarısızsa işlem tam başarılı sayılmamalıdır. Örneğin eBay update tamamlanmış olsa bile yeni fiyat minimum margin altındaysa business health başarısızdır ve olay açılmalıdır.

Hata sınıfları retry kararını belirler

eBay'in resmi API error handling rehberi, application-level ve infrastructure error ayrımını açıklar. Bu teknik ayrım başlangıçtır; kendi iş kurallarınız için ayrı hata kodları üretmeniz gerekir.

Kill switch tek büyük kırmızı düğme değildir

Tüm otomasyonu kapatan global düğme gereklidir, fakat günlük operasyonda fazla kabadır. Güvenli sistem beş seviyede durabilmelidir: tek SKU, supplier, işlem türü, eBay hesabı ve global. Bir supplier parser'ı bozulduğunda tüm hesapların tracking upload akışını kapatmak yeni sorun üretir.

Kill switch otomatik ve manuel tetiklenebilir. Örnek otomatik eşikler:

• On dakikada fiyatı %25'ten fazla değişen 10 SKU
• Son batch'te validation error oranının %5'i aşması
• Aynı tracking numarasının iki order'a yazılması
• Supplier feed yaşının belirlenen SLA'yı aşması
• Bir hesapta beklenmeyen cancellation veya quantity-zero sıçraması
• AI doğruluk örnekleminde kritik claim hatası bulunması

Eşikler kategoriye göre değişmelidir. Günlük fiyat oynaklığı yüksek ürün ile stabil mobilya parçası aynı yüzdeyle izlenmez. Kill switch çalıştığında yalnızca alarm değil, hangi queue'nun durduğu ve hangi son güvenli checkpoint'e dönüleceği de görünmelidir.

Idempotency: aynı olay iki kez gelirse tek sonuç

Webhook teslimatı, scheduler çakışması veya kullanıcının tekrar tıklaması aynı işlemi iki kez tetikleyebilir. Güvenli otomasyon, aynı iş anahtarıyla ikinci çalışmada yeni sonuç üretmemelidir. Örneğin order ID + action type, tracking upload için idempotency anahtarı olabilir; price update için SKU + source version + target price kullanılabilir.

Retry öncesinde “ilk istek eBay'e ulaştı mı?” sorusu cevaplanmalıdır. Timeout, isteğin hiç işlenmediğini garanti etmez. Durumu okumadan create işlemini tekrar etmek duplicate kayıt; refund işlemini tekrar etmek finansal tutarsızlık üretebilir. Önce mevcut state okunur, hedef state zaten oluşmuşsa işlem başarılı kabul edilir.

eBay Inventory API'nin bazı create-or-replace işlemleri mevcut kaydı tamamen değiştirebilir. Resmi inventory item yönetimi dokümanı, replace güncellemesinde uygulanabilir alanların birlikte gönderilmesi gerektiğini belirtir. Kısmi update varsayımıyla eksik payload göndermek mevcut alanları kaybettirebilir.

Audit log, ekran görüntüsü arşivi değildir

Bir olaydan sonra “sistem değiştirmiş” cevabı kabul edilemez. Her mutation kaydı şu soruları yanıtlamalıdır: ne değişti, önceki değer neydi, yeni değer ne, kaynak veri hangisi, hangi kural veya kullanıcı karar verdi, eBay sonucu ne oldu ve nasıl geri alınır?

Minimum audit olayı şu alanları taşır:

• Timestamp, environment, account ID ve SKU/item ID
• Action (`price_update`, `quantity_update`, `publish`, `end`, `tracking_upload`)
• Before/after değerleri ve para birimi
• Supplier source version veya fetch zamanı
• Rule version, AI model/prompt version veya kullanıcı kimliği
• Request ID, response durumu, warning ve error code
• Retry count, parent event ve rollback event bağlantısı

Log değiştirilemez veya en azından değişiklik geçmişi korunur yapıda olmalıdır. Kişisel alıcı verileri gereksiz yere loglanmamalı; erişim ve saklama süresi tanımlanmalıdır. Gözlemlenebilirlik, veri minimizasyonunu iptal etmez.

Alert tasarımı: her hata insan uyandırmamalı

Validation hatası tek SKU'da review kuyruğuna gidebilir; global fiyat anomalisi ise acil alarm gerektirir. Alert şiddeti etki alanı, geri döndürülebilirlik ve zaman baskısına göre atanmalıdır.

Pratik seviye modeli:

1. Info: Beklenen retry ile kendiliğinden düzelen olay, trend için kaydedilir.
2. Warning: Belirli SKU/supplier queue'su durdu, çalışma saatinde inceleme gerekir.
3. Critical: Para, hesap sağlığı veya çok sayıda canlı ilan etkileniyor; on-call müdahalesi gerekir.

Aynı kök nedenden 500 alert göndermek müdahaleyi hızlandırmaz. Olaylar fingerprint ile gruplanmalı; ilk alarm etki sayısını güncelleyerek devam etmelidir. Alert içinde dashboard linki değil, son güvenli çalışma, etkilenen SKU sayısı, değişiklik örneği ve önerilen ilk eylem bulunmalıdır.

Human-in-the-loop nerede zorunlu?

İnsan onayı her satırda olursa otomasyonun değeri kaybolur; hiç olmazsa politika ve para hatası büyür. Onay, risk bazlı yerleştirilmelidir. Yeni supplier'ın ilk 25 ürünü, yüksek fiyat değişimi, brand/VeRO sinyali, yeni category mapping, yüksek değerli refund ve AI'ın düşük güvenli ürün iddiası insan incelemesine gitmelidir.

Stabil supplier'da küçük quantity değişimi veya önceden doğrulanmış floor-price kuralı otomatik yürüyebilir. Sistem zamanla güven kazansa bile approval bypass nedeni loglanmalıdır. “AI confidence %95” tek başına ticari güven değildir; doğruluk örneklemi ve hata maliyetiyle kalibre edilmelidir.

Incident sırasında 30 dakikalık sıra

İlk adım kök nedeni bulmak değil hasarı durdurmaktır. Etkilenen işlem türünde kill switch çalıştırılır, devam eden queue pause edilir ve yeni batch engellenir. İkinci adım etki alanıdır: hesap, supplier, SKU ve zaman aralığı çıkarılır. Üçüncü adım canlı listing state'i ile audit log karşılaştırılır.

Sonra rollback kararı verilir. Her şeyi eski hâle döndürmek de kör bir otomasyondur; olaydan sonra gerçekleşmiş geçerli satışlar veya manuel düzeltmeler olabilir. Diff bazlı, yalnızca hatalı event'in değiştirdiği alanlar geri alınmalıdır. En son kök neden düzeltilir, küçük canary batch çalıştırılır ve metrikler normalleşmeden queue tamamen açılmaz.

İyi postmortem kişi aramaz; kontrol açığını arar. “Operatör yanlış CSV yükledi” son neden değildir. Neden dry-run farkı yoktu, yüzde değişim limiti çalışmadı ve ikinci onay gerekmiyordu soruları cevaplanmalıdır.

Hata bütçesi ve canary yayın

Yüzde yüz hatasızlık gerçekçi değildir; kontrolsüz hata kabul edilemez. Her otomasyon için kritik hata bütçesi tanımlayın. Örneğin price update'te floor altı sonuç toleransı sıfır, eksik optional aspect warning'i belirli düşük oranda kabul edilebilir olabilir.

Yeni rule veya supplier parser doğrudan tüm portföye açılmamalıdır. Önce 5 SKU canary, sonra 25, 100 ve tam hacim uygulanır. Her aşamada fiyat farkı, validation, publish ve manuel inceleme oranı kontrol edilir. eBay otomasyon stack'i hangi işlerin otomatikleşeceğini anlatır; canary yöntemi o otomasyonun nasıl güven kazanacağını belirler.

TurkoLister ile kontrollü otomasyon

TurkoLister'da supplier, listing, fiyat, stok ve kâr bağlamını aynı akışta değerlendirmek iş kuralı hatalarını API sonucundan önce yakalamaya yardımcı olur. İlk kurulumda üç koruma belirleyin: minimum net kâr, maksimum tek seferlik fiyat değişimi ve stale supplier data süresi. Ardından hangi ihlalin blok, hangisinin review üreteceğini yazın.

TurkoLister free trial sırasında başarıyı yalnızca üretilen ilan sayısıyla ölçmeyin. Engellenen riskli güncelleme, manuel inceleme süresi, false-positive oranı ve rollback yapılabilirliği daha değerli güvenlik metrikleridir.

Sonuç

Güvenli eBay otomasyonu hızlı çalışan değil, hata anında kontrollü duran sistemdir. Hataları sınıflandırın, retry'ı idempotent kurun, kill switch'i dar kapsamlı çalıştırın, her mutation için audit izi bırakın ve yeni kuralları canary batch ile açın. Otomasyonun kalite standardı normal günde hızı değil, kötü günde sınırlandırdığı hasardır.