ESL'de yedekleme ve felaket kurtarma

ESL sisteminde bir felaket senaryosu, ilk bakışta göründüğünden farklı işler. Sunucu çöktüğünde raflar boş kalmaz — etiketler son gösterdikleri fiyatı göstermeye devam eder. Sorun görünürlükte değil, yönetim yeteneğinin kaybındadır.

Neyin yedeklenmesi gerekiyor?

Dört veri kümesi kritik:

1. Eşleştirme tablosu. Hangi etiket hangi ürüne bağlı. Bu kaybolursa binlerce etiket tek tek yeniden eşleştirilmek zorundadır — kurulumu baştan yapmak demektir (ESL'de eşleştirme).

2. Şablonlar. Kategori bazında tasarımlar. Yeniden yapılması günler alır ve ilk hâline birebir dönmek zordur.

3. Yapılandırma. Yetkiler, kullanıcılar, alarm eşikleri, entegrasyon ayarları, kapsama haritası.

4. Fiyat geçmişi. Mevzuat ve şikâyet savunması açısından gereklidir (ESL'de fiyat arşivi).

Birinci madde açık ara en kritiktir. Diğer üçü yeniden üretilebilir; eşleştirme tablosu ancak sahada yeniden üretilir.

Bulut ve yerel: sorumluluk farkı

Bulut modelinde yedekleme tedarikçinin sorumluluğundadır. Ama bu, sorumluluğun sizde olmadığı anlamına gelmez — sorulması gereken:

• Yedek sıklığı nedir?
• Yedekler nerede tutuluyor (coğrafi ayrım var mı)?
• Kurtarma süresi taahhüdü (RTO) nedir?
• Veri kaybı toleransı (RPO) nedir?
• Yedeği siz de indirebiliyor musunuz?

Son madde önemlidir: tedarikçiye bağımlı bir yedek, tedarikçi kaynaklı bir sorunda işe yaramaz.

Yerel sunucu modelinde yedekleme tamamen sizin işinizdir ve genellikle unutulur. Kurulum sırasında yedekleme planı yazılı hâle getirilmelidir (bulut mu yerel sunucu mu).

Yedek sıklığı ne olmalı?

Eşleştirme tablosu sık değişmez — raf düzenlemesi olduğunda değişir. Şablonlar daha da seyrek.

Pratik bir plan:

Günlük yedek, en kötü senaryoda bir günlük raf değişikliğinin kaybı demektir; bu, kabul edilebilir bir tolerans.

Kurtarma süresi gerçekte ne kadar?

Tedarikçiler genellikle "birkaç saat" der. Gerçek süre, yedekten dönme süresi değil sistemin tam çalışır hâle gelme süresidir:

1. Sunucu yeniden kurulur ya da yedekten döner (1–4 saat)
2. Ağ ve erişim noktaları bağlanır (15–30 dakika)
3. Entegrasyon yeniden kurulur ve doğrulanır (1–2 saat)
4. Tam bir güncelleme turu çalıştırılır (etiket adedine göre dakikalar–saatler)
5. Doğrulama turu yapılır (1–2 saat)

Toplam: gerçekçi olarak yarım ila bir iş günü. Bu sürenin sözleşmede taahhüt edilmesi gerekir (sözleşmeye yazılacak servis maddeleri).

Bu sürede mağaza ne yapar?

Kritik soru budur ve cevabı rahatlatıcıdır: etiketler çalışmaya devam eder. Son gösterdikleri fiyat okunabilir durumdadır.

Yapılamayan tek şey fiyat değiştirmektir. Bu yüzden felaket anında:

• Fiyat artışları ertelenir (rafta eski fiyat varsa o bağlayıcıdır).
• Zorunlu indirimler kâğıt etiketle geçici olarak yapılabilir.
• Kampanya başlangıcı erteleneceği duyurulur.

Bu üç maddelik plan, kurtarma süresince mağazanın çalışmaya devam etmesini sağlar ve elektrik kesintisinde ESL ne olur yazısındaki yaklaşımla aynı mantığı izler.

Yedeği test etmek

Alınan yedeğin geri yüklenebildiği, test edilmeden bilinemez. Yılda bir kez yapılacak basit bir tatbikat:

1. Yedeği ayrı bir ortama geri yükleyin.
2. Eşleştirme tablosunun bütünlüğünü kontrol edin.
3. Bir şablonun doğru açıldığını doğrulayın.

Test edilmemiş yedek, yedek sayılmaz — bu, IT'nin klasik kuralıdır ve ESL için de geçerlidir.

Sözleşme biterse: aynı veri, farklı senaryo

İlginç biçimde, felaket kurtarma için gereken veri seti ile tedarikçi değişimi için gereken veri seti aynıdır: eşleştirme tablosu, şablonlar, yapılandırma, geçmiş.

Bu yüzden dışa aktarım yeteneği iki amaca birden hizmet eder ve sözleşmeye tek bir madde olarak yazılabilir (ESL projesinde gizli maliyetler).

Kısmi felaketler daha sık

Tam sunucu kaybı nadirdir. Sahada çok daha sık görülen üç kısmi senaryo:

Entegrasyon kopması. ERP ile bağlantı kesilir; sistem çalışır ama yeni fiyat gelmez. Tespiti zordur çünkü hiçbir şey hata vermez. Aktarım alarmı bu yüzden kritiktir (ESL ağının izlenmesi).

Yanlışlıkla toplu değişiklik. Hatalı bir şablon ya da yanlış bir fiyat dosyası, binlerce etikete aynı anda uygulanır. Geri alma (rollback) yeteneği varsa dakikalar, yoksa saatler sürer.

Veritabanı bozulması. Kısmi veri kaybı; eşleştirmelerin bir bölümü gider. En zor senaryo budur çünkü hangi kayıtların bozulduğu belli olmaz.

Üçü için de ortak çözüm aynıdır: düzenli yedek ve geri alma yeteneği.

Geri alma (rollback) sorulmalı

"Son uygulanan toplu değişikliği geri alabiliyor musunuz?" sorusu, satın alma sırasında sorulan listede nadiren bulunur ama sahada en çok ihtiyaç duyulan yetenektir.

Yetenek varsa hatalı bir kampanya güncellemesi dakikalar içinde düzelir. Yoksa doğru veri yeniden yüklenir ve tam bir güncelleme turu daha çalışır — büyük parklarda saatler demektir.

Bu madde tedarikçi seçerken sorulacak 20 soru listesine eklenmelidir.

Zincirde merkezi risk

Çok mağazalı bir kurulumda merkezi sunucu tek bir arıza noktasıdır: çökerse bütün mağazalar etkilenir.

İki mimari yaklaşım var: merkezde yedekli sunucu, ya da her mağazada yerel bir denetleyici + merkezde yönetim. İkincisi, merkez düşse bile mağazaların çalışmaya devam etmesini sağlar.

Hangi mimarinin kurulduğu, zincir projelerinde baştan netleşmelidir (zincir markette ESL).