Sürüm Yükseltmesi Patladığında Kaç Dakikada Geri Dönebiliyorsun? Dijital Ürün Scriptinde Kimsenin Yazmadığı Geri Alma Planının İçyüzü

Herkes güncellemeyi konuşur, kimse geri dönmeyi konuşmaz. Oysa saha gerçeği şu: iyi hazırlanmış bir işletmeyi kötü hazırlanmış olandan ayıran şey güncellemeyi hatasız yapması değil, hata olduğunda ne kadar hızlı eski hâline döndüğüdür. Bir bayinin "sürüm attım, sipariş akmıyor" diye yazdığı mesajın altında neredeyse her zaman aynı cümle yatar: "Yedek var ama nasıl geri yükleneceğini bilmiyorum."

Geri alma planı bir dosya değil, bir karar zinciridir. Kim karar verir, hangi eşikte tetiklenir, hangi sırayla uygulanır, hangi veri kaybı kabul edilir? Bu yazıda bir dijital ürün satış scripti için gerçekten uygulanabilir bir geri dönüş planını parça parça kuracağız. Sonunda elinde, gecenin üçünde uykulu kafayla bile takip edebileceğin tek sayfalık bir yol haritası olacak.

Geri alma ile yedekten dönmek aynı şey mi? Kesinlikle değil

Yedekten dönmek, sistemi dünün fotoğrafına çevirmektir. Geri alma ise sistemi bir önceki çalışan sürüme, bugünün verisiyle döndürmektir. Aradaki fark, o gün alınan siparişlerdir. Bir e-pin satış yazılımı günde yüz sipariş alıyorsa, dünkü yedeğe dönmek yüz siparişi silmek anlamına gelir; müşteri parasını ödemiştir ama sistemde kaydı yoktur. Bu, teknik bir arızayı ticari bir krize dönüştürür.

Bu yüzden plan yazarken iki ayrı kutu düşün. Birinci kutu kod ve şablon: burada geri dönüş ucuzdur, veri kaybı yoktur, saniyeler sürer. İkinci kutu veritabanı: burada geri dönüş pahalıdır, veri kaybı riski taşır ve dikkat gerektirir. İyi bir planın ilk hedefi, olayların büyük kısmını birinci kutuda çözebilecek şekilde kurulum yapmaktır.

RTO ve RPO'nu yazmadan plan yazmış olmuyorsun

İki sayı belirlemen gerekir. RTO, arızadan sonra ne kadar sürede ayağa kalkmayı hedeflediğin. RPO ise en fazla kaç dakikalık veri kaybını kabul edebileceğin. Dijital ürün satışında tipik hedef RTO on beş dakika, RPO beş dakikadır. Bu sayılar soyut gibi görünür ama yapacağın her teknik seçimi belirler: RPO beş dakika istiyorsan veritabanı yedeğini günde bir kez almanın hiçbir anlamı kalmaz, ikili günlük kaydı veya sık artımlı yedek şarttır.

Sayıları yazdıktan sonra mevcut durumunu ölç. Bir sonraki bakım penceresinde staging üzerinde gerçek bir geri dönüş tatbikatı yap ve kronometre tut. Ölçtüğün süre hedefinin üç katıysa plan değil temenni yazmışsın demektir. Ölçüm olmadan hiçbir epin yazılım kurulumunda kurtarma süresi bilinemez.

En zor kısım neresi? Veritabanı şemasını geri sarmak

Kodu geri almak kolaydır çünkü kod durumsuzdur. Veritabanı ise durumu taşır. Yeni sürüm bir kolon eklediyse ve o kolona veri yazmaya başladıysa, eski sürüme dönmek o kolonu görmezden gelmek anlamına gelir; genelde sorun çıkmaz. Ama yeni sürüm bir kolonu bölmüş ya da silmişse geri dönüş veri kaybıdır.

Pratik savunma üç adımdır. Birincisi: güncelleme öncesi yalnızca şema dökümünü ayrı bir dosyaya al, böylece neyin değiştiğini karşılaştırabilirsin. İkincisi: migrasyonların geri alma adımı olup olmadığını önceden kontrol et; yoksa geri dönüşün tek yolu tam dökümdür ve RPO'n bozulur. Üçüncüsü: yıkıcı işlemleri erteleyen sürümleri tercih et. Kolon silme gibi işlemler bir sonraki sürüme bırakılabiliyorsa, arada güvenli bir geri dönüş penceresi kalır.

İki dizin hilesi: dosya tarafında geri dönüşü saniyeye indirmek

Dosya katmanında yıllardır en güvenilir yöntem şudur: sürümleri üzerine yazmak yerine yan yana tut. surum-12 ve surum-13 diye iki dizin, web sunucusunun baktığı yol ise bu dizinlerden birine işaret eden bir sembolik bağ olsun. Güncelleme, yeni dizini hazırlayıp bağı çevirmekten ibarettir; geri alma ise bağı geri çevirmek. İkisi de saniyeler sürer ve yarım kopyalanmış dosya durumu hiç oluşmaz.

Bu yapının ikinci şartı, durum taşıyan her şeyin sürüm dizinlerinin dışında yaşamasıdır: yüklenen görseller, üretilen faturalar, log dosyaları, önbellek dizini ve yapılandırma. Bunları paylaşımlı bir dizine alıp sürüm dizinlerinden bağlarsan, ileri geri geçişlerde müşteri dosyaları hiç etkilenmez. Böyle kurulmuş bir e-pin scripti ortamında geri alma artık korkulacak bir işlem değil, tek satırlık bir komuttur.

Geri mi alacaksın, ileri mi düzelteceksin? Karar eşiğini önceden koy

Arıza ânında en çok vakit kaybettiren şey teknik işlemler değil, tereddüttür. "Beş dakika daha uğraşırsam çözerim" düşüncesi otuz dakikalık kesintiye dönüşür. Bu yüzden eşiği soğukkanlıyken belirle: ödeme veya teslimat akışını etkileyen bir arızada teşhis için en fazla on dakika harca, çözülmezse geri al. Görsel bir bozukluk, yanlış hizalanmış bir buton veya küçük bir metin hatası ise geri alma gerektirmez; ileri düzeltme ile bir sonraki yamada çözülür.

Kararı kim verir sorusunun cevabı da yazılı olmalı. Tek kişilik bir işletmede bu sensin; ekipli bir yapıda nöbetçi kişidir. İkinci bir kural daha ekle: geri alma kararı verildikten sonra tartışma kapanır, plan uygulanır. Sistem ayağa kalktıktan sonra neden olduğunu rahatça araştırırsın. Müşteri, kök nedeni merak etmez; kod gelmesini bekler.

Geri aldıktan sonra ne yapacaksın? Olay kapanışı da planın parçası

Sistem eski sürümde ayağa kalktı, siparişler akıyor. İş burada bitmez. Üç şey yapman gerekir. Birincisi, kesinti penceresinde etkilenen siparişleri listele ve elle telafi et; bekleyen ödemeleri manuel teslimata bağla, gecikme için kısa bir özür mesajı gönder. İkincisi, arızanın kök nedenini staging'de yeniden üret; canlıda tekrar denemek aynı çukura ikinci kez düşmektir. Üçüncüsü, öğrendiğin şeyi kontrol listene bir madde olarak ekle.

Bu döngüyü birkaç kez çevirdiğinde planın kalınlaşır ve kesinti süreleri kısalır. İyi işleyen bir dijital ürün satış yazılımı operasyonunun sırrı hiç hata yapmamak değil, aynı hatayı ikinci kez yapmamaktır. Her olay, planına eklenen bir satırdır.

Geri alma planı, bir gün kullanacağın ama asla kullanmak istemeyeceğin bir belgedir; tam da bu yüzden bugün yazılmalı. Kendi kurulumunda sürüm ve sipariş ekranlarının bu akışa nasıl oturduğunu görmek istersen Pinova'nın canlı demo ortamında panelin içinde dolaşabilir, planının hangi adımını hangi ekrandan yürüteceğini şimdiden işaretleyebilirsin.