E-Pin Yazılımın Bir Gece Çökerse Ne Olacağını Biliyor musun? Kimsenin Yapmadığı Felaket Kurtarma Tatbikatının Perde Arkası

Çoğu işletme sahibi yedeği bir sigorta poliçesi sanır: panelde "otomatik yedek açık" yazıyorsa mesele kapanmıştır. Oysa yedek bir dosya değildir, bir süreçtir. Dosyanın var olması yeterli değil; o dosyanın açılabilir, tutarlı, güncel ve geri yüklenebilir olması gerekir. Bu dört şartı hiç test etmediysen elinde yedek yok, yedek hissi var.

Gerçek felaket gecenin üçünde gelir. Diskte bozulma olur, bir güncelleme yarıda kalır, veya panelde yanlış bir toplu işlem beş bin siparişin durumunu değiştirir. O anda kimsenin sana sorusu "yedeğin var mı" değildir; "kaç dakikada açılırsın ve kaç siparişi kaybettin" olur. Bu yazıda bir e-pin satış scripti için gerçekten işe yarayan felaket kurtarma tatbikatını, senaryolarıyla ve zaman ölçümleriyle kuruyoruz.

Yedeğin var mı, yoksa yedeğin olduğunu mu sanıyorsun?

Yedeğin gerçek olup olmadığını anlamanın tek yolu geri yüklemektir. Bunu canlı sistemde denemeyeceğin için bir kenara test ortamı kurman gerekir. Denemeyi yaptığın gün üç şeyi birden öğrenirsin: dosya bozuk mu, şema güncel mi, ve geri yükleme kaç dakika sürüyor. Üçüncüsü en çok şaşırtan kısımdır; insanlar geri yüklemenin on dakika olduğunu sanır, gerçek süre çoğu zaman bir saatin üstündedir.

İkinci sık hata yedeği aynı sunucuda tutmaktır. Sunucu diski sorun çıkardığında hem site hem yedek aynı anda gider. Bu yüzden kural nettir: bir kopya sunucuda, bir kopya farklı sağlayıcıda, bir kopya da haftalık olarak kendi bilgisayarında. Ayrıca yedeğin sadece veritabanı değil, yükleme klasörü ve yapılandırma dosyalarını da içermesi gerekir. Bir e-pin yazılımı için yapılandırma kaybı çoğu zaman veri kaybından daha uzun kesintiye yol açar, çünkü ödeme ve tedarikçi entegrasyon anahtarlarını yeniden almak saatler alır.

RTO ve RPO: iki sayıyı bilmeden tatbikat yapılmaz

Felaket kurtarmanın tüm dili iki kısaltmaya dayanır. RTO, sistemi yeniden ayağa kaldırmak için kabul ettiğin en uzun süredir. RPO ise kaybetmeye razı olduğun en fazla veri penceresidir. Bu iki sayıyı yazmadan hiçbir yedek stratejisi anlamlı değildir, çünkü kararların tamamı bu sayılardan çıkar.

Örnek üzerinden gidelim. Günde dört yüz sipariş alan bir site için altı saatlik RPO, yaklaşık yüz siparişin kaybı anlamına gelir; bunların çoğu ödeme almış ama teslim edilmemiş siparişlerdir, yani doğrudan müşteri şikâyetidir. Bu işletme için altı saat çok uzundur; bir saatlik artımlı yedek gerekir. Aynı şekilde RTO'yu dört saat koyuyorsan geri yüklemeyi bir kişinin telefondan yapabilecek kadar belgelemiş olmalısın. Sayıları koy, sonra altyapıyı o sayılara göre seç. Tersini yapan herkes fazla para ödeyip yine de hazırsız kalır.

Tatbikat senaryoları gerçekten neye benzer?

Tek bir "sunucu öldü" senaryosu yetmez. Gerçek olaylar çoğunlukla kısmi arızalardır ve kısmi arızalar tam çökmeden daha tehlikelidir, çünkü sistem yarım çalıştığı için kimse alarmı çalmaz. Aşağıdaki beş senaryoyu yılda bir kez baştan sona oyna.

İlk 90 dakikalık tatbikatı nasıl kurgularsın?

Tatbikatı büyütmeye çalışırsan hiç yapmazsın. Bu yüzden ilk turu doksan dakikaya sıkıştır. İlk on beş dakikada bir test sunucusu ve test alan adı hazırla. Sonraki yirmi dakikada son yedeği indir, boyutunu ve tarihini not et. Otuz dakikayı geri yüklemeye ayır ve süreyi kronometreyle tut. Son yirmi beş dakikada ise doğrulama yap: bir sipariş oluşturmayı dene, bir e-pin teslim edilsin, bakiye düşsün, e-posta çıksın.

Bu turun sonunda elinde üç çıktı olur: gerçek geri yükleme süresi, gerçek veri kaybı penceresi ve eksik adımların listesi. Bu listeyi bir sayfalık kurtarma kılavuzuna çevir ve sunucu dışında bir yerde sakla. Kılavuzun ilk satırı "bakım moduna al" olmalı, çünkü yarım çalışan bir dijital ürün satış scripti kapalı bir siteden daha fazla zarar verir: ödeme alır, teslim etmez, itiraz üretir.

Teslimat kuyruğu ve çift teslim riskini nasıl kontrol edersin?

Felaket kurtarmanın e-pin işine özgü en kritik kısmı burasıdır. Geri yükleme yaptığında sistem, yedeğin alındığı ana döner. O andan sonra teslim edilmiş kodlar veritabanında "teslim edilmemiş" görünür. Kuyruk yeniden çalışırsa aynı müşteriye ikinci bir kod gider ve stoktan ikinci kez düşer. Bu, geri yüklemenin en pahalı yan etkisidir.

Çözüm iki katmanlıdır. Birincisi, teslimat kuyruğunu geri yükleme sırasında kapalı tutmak ve elle açmaktır. İkincisi, her teslimatın sipariş kalemi başına tek bir benzersiz anahtarla kaydedilmesidir; böylece kuyruk aynı kalemi ikinci kez işlemeyi reddeder. Buna ek olarak teslimat logunu veritabanından ayrı bir dosyada da tutmak işini çok kolaylaştırır: geri yükleme sonrası bu logu karşılaştırarak hangi siparişlerin gerçekten teslim edildiğini görebilirsin. Pinova'da teslimat kayıtlarının ayrı tutulması ve kuyruğun elle devreye alınabilmesi tam bu senaryo için vardır; özellikler bölümünde hangi katmanların ayrı loglandığını görebilirsin.

Tatbikat sonrası kontrol listesini kim imzalar?

Tatbikat, çıktısı imzalanmadığı sürece bir sohbettir. Aşağıdaki listeyi her turdan sonra doldur, tarih at ve sorumlusunu yaz. Sorumlusu olmayan satır bir sonraki felakette de boş kalır.

Felaket kurtarma pahalı bir altyapı işi değil, disiplin işidir. Bu hafta doksan dakikanı ayırıp ilk turu yaparsan bir daha aynı korkuyla uyanmazsın. Kurtarma sırasında hangi ekranların işini kolaylaştırdığını merak ediyorsan canlı demo üzerinden teslimat logu, kuyruk yönetimi ve bakım modu akışını kendin deneyebilir, kendi kurtarma kılavuzunu bu adımların üzerine yazabilirsin.