ESL sisteminde yedekleme ve felaket kurtarma planı

Elektronik raf etiketi sistemi çalışırken görünmezdir. Fiyatlar gider, etiketler güncellenir, kimse arkadaki veritabanını düşünmez. Yedekleme sorusu genellikle tek bir anda sorulur: sunucu bozulduğunda.

O anda cevap hazır değilse, kayıp yalnızca birkaç saatlik veri değildir. Kaybedilen asıl şey, etiket–ürün eşleştirme tablosudur ve bu tablo yeniden kurulmak zorunda kalırsa mağazada haftalarca süren bir iş doğar.

Hangi veri kritik?

ESL sisteminde tutulan verilerin hepsi eşit değerde değildir. Üç gruba ayırmak, yedekleme planını gereksiz yere büyütmeden kurmayı sağlar.

Yeniden üretilemeyen veri. Etiket–ürün eşleştirme tablosu, etiket konum bilgisi ve etiket kimlik envanteri. Bunlar kaybedilirse kaynak sistemden geri getirilemez; çünkü bu bilgi mağazada, fiziksel olarak üretilmiştir. Birisi her etiketi tek tek o ürüne bağlamıştır.

Yeniden üretilebilir ama zahmetli veri. Şablonlar, kullanıcı tanımları, yetki matrisi, erişim noktası yerleşimi. Bunlar yeniden yazılabilir ama günler alır.

Kaynaktan akan veri. Fiyatlar, ürün adları, stok bilgisi. Bunlar zaten kaynak sistemde durur; ESL veritabanı kaybolsa bile ilk eşitlemede geri gelir (fiyat değişikliğinin yolculuğu).

Yedekleme planı birinci grubun etrafında kurulur. İkinci grup aynı yedeğe dahil edilir çünkü maliyeti düşüktür. Üçüncü grup için ayrı bir çaba gerekmez.

Bulut ve yerel kurulumda sorumluluk farkı

Yazılım tedarikçinin bulutunda çalışıyorsa yedekleme tedarikçinin sorumluluğundadır — ama bu sorumluluk sözleşmede yazılı değilse varsayımdan ibarettir.

Sorulacak üç soru nettir: yedek ne sıklıkla alınıyor, ne kadar süre saklanıyor, geri dönüş talebi ne kadar sürede karşılanıyor. Cevaplar sözleşmeye yazılacak servis maddeleri listesine eklenmelidir.

Yerel kurulumda sorumluluk işletmededir. Bu durumda ESL sunucusu, kurumun mevcut yedekleme rutinine dahil edilmelidir. En sık yapılan hata, sunucunun kurulup bu rutine hiç eklenmemesidir; çünkü kurulum tedarikçi tarafından yapılır, yedekleme ise BT biriminin işidir ve arada kimse konuyu devralmaz.

Bu devir teslim, ESL'ye geçiş sonrası ilk 90 gün kontrol listesinde açık bir madde olmalıdır.

Geri dönüş süresi: asıl ölçü

Yedeğin varlığı tek başına bir şey ifade etmez. Ölçülmesi gereken, geri dönüş süresidir: sistem tamamen durduğunda kaç saat içinde yeniden çalışır hâle gelir?

Bu sürenin makul sınırı, mağazanın fiyat değiştirme ihtiyacına bağlıdır. Günde birkaç kez kampanya güncellemesi yapan bir markette bir günlük kesinti ciddidir; fiyatların haftada bir değiştiği bir mağazada aynı kesinti tolere edilebilir.

Önemli bir rahatlatıcı gerçek şudur: sunucu dursa bile etiketler son hâllerini göstermeye devam eder. E-ink ekran, güç olmadan görüntüyü korur. Yani kesinti, yanlış fiyat değil, güncellenemeyen fiyat anlamına gelir.

Bu fark önemlidir çünkü panik seviyesini belirler. Kesinti sırasında yapılacak şey, fiyat değişikliklerini bekletmek ya da geçici kâğıt etiketle yönetmektir (etiket arızalandığında operasyon).

Yedek gerçekten çalışıyor mu?

Hiç denenmemiş bir yedek, yedek sayılmaz. Bu, bilgi işlem dünyasının en eski kurallarından biridir ve ESL için de geçerlidir.

Yılda bir kez yapılacak basit bir tatbikat yeterlidir: yedek dosya bir test ortamına geri yüklenir, sistem ayağa kalkar, eşleştirme tablosunun bütünlüğü kontrol edilir. Test ortamı zaten ESL'de test ortamı gerekli mi yazısında anlatılan gerekçelerle kurulmuşsa, bu tatbikat ek maliyet getirmez.

Tatbikatın sonucu bir sayıdır: geri dönüş kaç saat sürdü. Bu sayı, sözleşmedeki taahhütle karşılaştırılır.

Çoklu mağazada yerel dayanıklılık

Zincirde merkezî sunucu kullanılıyorsa, merkez ile mağaza arasındaki hat koptuğunda ne olacağı ayrı bir sorudur. İki mimari vardır: mağazadaki erişim noktaları yalnızca merkezden komut alır, ya da mağazada yerel bir denetleyici bulunur ve hat koptuğunda son bilinen durumla çalışmaya devam eder.

İkinci mimari daha dayanıklıdır ama daha pahalıdır. Hangi modelin kullanıldığı, teklif aşamasında sorulması gereken teknik sorulardan biridir (tedarikçi seçerken sorulacak 20 soru).

Tek sayfalık plan yeterli

Bu konu için kapsamlı bir felaket kurtarma dokümanı yazmak çoğu işletme için aşırıdır. Tek sayfalık bir not yeterlidir ve dört satır içerir: yedek nerede duruyor, kim erişebiliyor, geri dönüş kaç saat, son tatbikat ne zaman yapıldı.

Bu dört satır güncel tutulduğu sürece, sunucunun bozulduğu gün panik yerine bir prosedür işler.

Bulut ve yerel kurulum arasındaki daha geniş karşılaştırma için bulut mu yerel sunucu mu yazısına bakılabilir; yedekleme sorumluluğu, o kararın en somut sonuçlarından biridir.

Eşleştirme tablosunun ayrı bir kopyası

Yedekleme planının en değerli tek maddesi, eşleştirme tablosunun düzenli olarak dışa aktarılmasıdır.

Bu, tam bir veritabanı yedeğinden farklıdır: basit bir tablo dosyasıdır ve içinde etiket kimliği, ürün kodu ve konum bulunur. Haftada bir alınıp işletmenin kendi dosya alanında saklanabilir.

Faydası ikilidir. Birincisi, sunucu kurtarılamazsa yeni sistem bu dosyayla hızlıca beslenir. İkincisi, tedarikçi değişikliği gündeme geldiğinde geçişin en ağır kısmı hazır durur (tedarikçi iflas ederse ne olur).

Bu dışa aktarımın mümkün olup olmadığı, teklif aşamasında sorulması gereken sorulardandır. "Verilerimizi istediğimizde dışa aktarabiliyor muyuz" sorusuna verilen cevap, sistemin açıklığı hakkında da bilgi verir.

Yedeklemenin sorumluluk sınırı

Son olarak bir sınır çizmek gerekir: ESL yedeklemesi, kurumun genel yedekleme politikasının yerine geçmez ve ondan bağımsız da düşünülmemelidir.

En sağlıklı yaklaşım, ESL sunucusunu ya da dışa aktarılan dosyaları mevcut rutine bir satır olarak eklemektir. Ayrı bir süreç kurmak, unutulmaya en açık çözümdür.

Bu satır eklendiğinde konu kapanır ve yıllarca bakım gerektirmez (ESL operasyonunda KPI takibi).