Adım Adım E‑Ticaret: Bakım Rutini (Güncel)

Adım Adım E-Ticaret Bakım Rutini​

E-ticaret bakımı yalnız tema ve eklenti güncellemek değildir. Sipariş, ödeme, stok, fiyat, kargo, iade, müşteri hesabı, analitik ve güvenlik aynı operasyon zincirinde çalışır. İyi bir rutin; kritik arızayı günlük yakalar, veri farkını haftalık uzlaştırır, değişiklikleri aylık olarak test eder ve felaket kurtarmayı düzenli prova eder.

---

Bakımın başarısı görev sayısıyla değil, kesintisiz ve mutabık müşteri yolculuğuyla ölçülür.

Bakım Envanteri ve Sorumluluklar​

Önce sistem haritasını çıkarın. Mağaza, ödeme kuruluşu, kargo, ERP/muhasebe, e-fatura, pazar yeri, e-posta/SMS, analitik, CDN ve destek araçlarının sahibi belli olmalıdır. Her entegrasyon için kimlik bilgisi, test yöntemi, alarm ve alternatif işlem yolu kaydedilmelidir.

• Teknik sahip: Uygulama, sunucu, cache, veri tabanı ve sürüm yönetimi
• Operasyon sahibi: Sipariş, stok, fiyat, kargo, iptal ve iade
• Finans sahibi: Tahsilat, komisyon, iade, chargeback ve mutabakat
• İçerik sahibi: Ürün verisi, kampanya, teslimat ve politika metinleri
• Güvenlik sahibi: Yetki, olay, yama, WAF/bot ve sır yönetimi

Bakım ilkesi' Alıntı:

Bir kontrolün sonucu, sorumlusu ve hata halinde uygulanacak adım yazılı değilse o kontrol tamamlanmış sayılmaz.

Genişletmek için tıkla ...

Günlük Kontrol: Sipariş Akışı​

Günlük kontrol 10–20 dakikada kritik ticari kesintiyi görünür kılmalıdır. Rastgele bir siparişi ürün görüntülemeden onaya kadar izleyin; yalnız yönetim panelindeki “site açık” durumuna güvenmeyin.

• Son 24 saatte sipariş, ödeme ve başarısız ödeme sayıları normal aralıkta mı?
• Ödeme sağlayıcıdaki başarılı tahsilatların mağazada karşılığı var mı?
• Bekleyen webhook, kuyruk veya e-fatura hatası oluşmuş mu?
• Stok sıfır/negatif, hatalı fiyat veya yinelenen ürün sinyali var mı?
• Kargo etiketi ve takip numarası üretimi çalışıyor mu?
• Müşteri destek kanalında aynı hatayı bildiren birden fazla kayıt var mı?

Başarısızlık oranını adet ve parasal etkiyle birlikte izleyin. Trafiğin düşük olduğu saatte tek yüksek tutarlı sipariş hatası, yüzdesel ortalamanın küçük görünmesine rağmen kritik olabilir.

Günlük Güvenlik ve Erişim Kontrolü​

Yeni yönetici hesabı, olağandışı giriş, API anahtar hatası, WAF engeli ve dosya değişikliği günlük görünümde olmalıdır. Alarmın yalnız e-posta kutusuna gitmesi yeterli değildir; sorumlu, yanıt süresi ve eskalasyon kanalı belirlenmelidir.

• Yönetici ve finans yetkilerinde beklenmedik değişiklik var mı?
• Başarısız giriş, kart deneme veya sahte hesap dalgası görülüyor mu?
• Ödeme/webhook imza doğrulama hatası arttı mı?
• Sırlar, token veya kişisel veri uygulama loguna düşüyor mu?
• Güvenlik güncellemesi veya sağlayıcı duyurusu bekliyor mu?

Haftalık Katalog ve Stok Bakımı​

Ürün verisi müşteri, arama motoru, reklam kanalı ve operasyon arasında tutarlı olmalıdır. Haftalık olarak stok, fiyat, varyant, görsel, GTIN/marka alanı ve teslimat bilgisini kaynak sistemle karşılaştırın.

• Yüksek trafik alan fakat stokta olmayan ürünler doğru alternatif sunuyor mu?
• Kampanya bitişi sonrasında eski fiyat veya kupon kalmış mı?
• Varyant seçimi doğru SKU, stok ve görselle eşleşiyor mu?
• Merchant/pazar yeri reddi, fiyat veya bulunabilirlik farkı oluşmuş mu?
• Sonuçsuz site aramaları yeni kategori, eş anlamlı veya ürün ihtiyacı gösteriyor mu?

Toplu ürün güncellemesini doğrudan canlıya göndermeyin. Küçük örnek dosyayı doğrulayın; ekleme, güncelleme ve silme davranışını ayrı test edin. Hatalı içe aktarım için sürüm veya geri yükleme planı tutun.

Haftalık Checkout ve İade Testi​

Gerçek veya sağlayıcının resmî test ortamında; başarılı ödeme, reddedilme, timeout, 3D Secure dönüşü, iptal, kısmi iade ve tam iade senaryolarını sırayla çalıştırın. Aynı istek tekrarlandığında ikinci tahsilat oluşmadığını ve webhook tekrarının işlemi çoğaltmadığını kontrol edin.

• Toplam fiyat, vergi, kargo ve indirim bütün ekranlarda aynı mı?
• Zorunlu alanlar, klavye kullanımı ve hata mesajları anlaşılır mı?
• Başarı sayfası sunucu sipariş durumuyla eşleşiyor mu?
• İade sonrası stok, ödeme, fatura ve müşteri bildirimi güncelleniyor mu?
• Teslimat ve cayma bilgileri ödeme öncesinde görünür mü?

Haftalık Performans Kontrolü​

Ana sayfa yerine kategori, ürün, sepet ve checkout şablonlarını mobil alan verisiyle izleyin. LCP, INP ve CLS yanında TTFB, arama gecikmesi, sepete ekleme ve ödeme API süresini takip edin.

Son sürümden sonra kötüleşen şablonu değişiklik günlüğüyle eşleştirin. Üçüncü taraf reklam, sohbet, kişiselleştirme ve analitik kodlarının checkout ana iş parçacığını bloke edip etmediğini inceleyin. Performans eklentisi eklemeden önce darboğazın sunucu, sorgu, görsel, JavaScript veya dış servis olduğunu kanıtlayın.

Haftalık Mutabakat​

Mağaza siparişi, ödeme sağlayıcı hareketi, banka/hesaplaşma, iade ve fatura kayıtlarını ortak kimlikle birleştirin. Tarih ve tutar eşleştirmesi tek başına yeterli değildir; aynı tutarlı iki işlem olabilir.

Net beklenen tutar = tahsilat − iade − chargeback − komisyon − diğer kesintiler

• Sağlayıcıda var, mağazada olmayan işlem
• Mağazada “ödendi”, sağlayıcıda başarısız/bekleyen işlem
• İade kaydı açılmış fakat sağlayıcıya ulaşmamış işlem
• Yanlış komisyon, para birimi veya kur farkı
• Yinelenen tahsilat veya yinelenen fatura

Farklar otomatik kapanmamalıdır. Araştırma, karar ve düzeltme kaydı bırakın; finansal işlemi silmek yerine ters kayıt veya durum geçişi kullanın.

Aylık Yazılım ve Altyapı Bakımı​

Çekirdek, tema, eklenti, runtime, veritabanı ve entegrasyon SDK'larını envanterleyin. Güncelleme notlarını okuyun; destek dışı sürüm ve bilinen güvenlik açığını önceliklendirin. Test ortamında kritik akışları çalıştırmadan canlı güncelleme yapmayın.

1. Dosya ve veri tabanı yedeği alın; geri yükleme süresini doğrulayın.
2. Staging ortamını güncel verinin maskelenmiş örneğiyle hazırlayın.
3. Sipariş, ödeme, iade, kargo, e-posta ve analitik testini çalıştırın.
4. Performans ve görsel farkı önceki sürümle karşılaştırın.
5. Bakım penceresi ve kullanıcı iletişimini hazırlayın.
6. Canlıya alın, alarm ve kuyrukları yakından izleyin.
7. Sorunda geri alma veya ileri düzeltme kararını önceden yazılmış eşikle verin.

Aylık Yetki ve Sır Denetimi​

İşten ayrılan kullanıcı, geçici ajans hesabı ve kullanılmayan API anahtarı kaldırılmalıdır. Yönetici, finans, iade ve kampanya yetkilerini görev ayrılığına göre inceleyin. “Herkes yönetici” modeli bakım hızını değil olay riskini artırır.

• MFA kapsamı ve kurtarma kodlarının güvenli saklanması
• Servis hesabı anahtarlarının kapsamı, son kullanımı ve kullanım kaydı
• Test/canlı kimlik bilgilerinin ayrılması
• Webhook sırları ve ödeme anahtarları için döndürme prosedürü
• Yedek, log ve raporlara erişen kullanıcıların kontrolü

Aylık İçerik ve Mevzuat Kontrolü​

Teslimat süresi, kargo bedeli, iade adresi, cayma koşulu, şirket ve iletişim bilgileri güncel olmalıdır. Kampanya metninin gerçek stok ve fiyatla, ürün açıklamasının güncel ürün özelliğiyle uyuştuğunu kontrol edin.

Tüketiciye sunulan ön bilgilendirme ve sözleşme kayıtlarının hangi sürümle onaylandığını saklayın. Çerez/analitik ve pazarlama izinlerini kullanılan araçlarla karşılaştırın; kaldırılmış bir araç için gereksiz çerez veya metin bırakmayın.

Üç Aylık Felaket Kurtarma Provası​

Yedeğin var olması, geri dönüşün çalıştığı anlamına gelmez. İzole ortamda dosya ve veritabanını geri yükleyin; uygulama anahtarları, medya, kuyruk ve dış entegrasyonların nasıl yeniden bağlanacağını doğrulayın.

• Hedef geri dönüş süresi ve kabul edilen veri kaybı aralığı gerçekçi mi?
• Yedekler üretim hesabından ayrı ve yetkili erişimle korunuyor mu?
• DNS/CDN/ödeme sağlayıcı erişimi tek kişiye bağlı mı?
• Kurtarılan sistemde sipariş bütünlüğü ve ödeme mutabakatı yapılabiliyor mu?
• Müşteri, çalışan ve sağlayıcı iletişim şablonları hazır mı?

Üç Aylık Kapasite ve Tedarikçi İncelemesi​

Kampanya tepe yükü, katalog büyümesi, sorgu maliyeti, depolama, API limiti ve kuyruk kapasitesini gözden geçirin. Dış sağlayıcıların hizmet durumu, destek süresi, veri dışa aktarma ve olay bildirim sorumluluğunu sözleşmeyle karşılaştırın.

Yük testinde yalnız başarılı ana sayfa isteği üretmeyin. Arama, sepete ekleme, kupon, stok rezervasyonu ve ödeme callback yükünü gerçekçi oranlarda simüle edin. Üretim sistemine izinsiz test uygulamayın.

Bakım Takvimi Örneği​

Sık Sorulan Sorular​

Bakım için mağazayı kapatmak gerekir mi?
Her işlem için değil. Veri göçü veya uyumsuz güncellemede bakım penceresi gerekebilir; düşük riskli değişiklikler kademeli ve geri alınabilir yayımlanabilir.

Otomatik güncellemeler yeterli mi?
Güvenlik yamalarını hızlandırabilir; ancak uyumluluk, veri göçü ve kritik akış testi yine gerekir.

Test siparişi gerçek kartla mı yapılmalı?
Önce sağlayıcının resmî test ortamı ve test araçları kullanılmalıdır. Canlı doğrulama gerekiyorsa düşük riskli, kayıtlı ve finans ekibiyle mutabık süreç izleyin.

Mutabakat ne sıklıkta olmalı?
Hacim ve riske bağlıdır. Kritik ödeme farkları günlük, ayrıntılı finansal uzlaştırma en az haftalık veya hesaplaşma döngüsüne göre yapılabilir.

Yedekleme ile felaket kurtarma aynı şey mi?
Hayır. Yedek veri kopyasıdır; kurtarma ise erişim, anahtar, altyapı, bütünlük ve operasyonun hedef sürede yeniden çalışmasıdır.

Bakım başarısı nasıl ölçülür?
Kesinti süresi, ödeme/sipariş farkı, geri alma süresi, açık güncellik süresi ve tekrar eden olay sayısıyla.

İç Bağlantılar​

• E-Ticaret ve Ödeme Başlangıç Rotası
• E-ticaret bakım rutini
• E-ticaret hız ve güvenlik rehberi
• E-ticaret analitik ve veri rehberi

Dış Kaynaklar​

• Google Analytics — E-ticaret olayları
• Google Merchant Center ürün verisi spesifikasyonu
• PCI Security Standards Council — PCI DSS
• Ticaret Bakanlığı — Mesafeli Sözleşmeler Rehberi
• Stripe Docs — Webhook güvenliği ve tekrar denemeleri

Özetle​

Günlükte sipariş ve alarmı, haftalıkta checkout ve mutabakatı, aylıkta sürüm-yetki-politikayı, üç aylıkta kurtarma ve kapasiteyi sınayın. Mağazanızda en sık tekrarlayan bakım sorununu paylaşın; rutine ölçülebilir bir kontrol ekleyelim.

---