Contoh Kerja: Memulihkan Kedai WooCommerce yang Rosak Daripada Sandaran Luar Tapak

Ini adalah contoh kerja hipotesis, bukan kajian kes. Syarikat, angka dan garis masa di bawah adalah senario ilustrasi yang dibina untuk menjelaskan satu kaedah pemulihan — ia tidak menggambarkan pelanggan atau insiden JagaWeb yang sebenar. Apabila artikel ini menyebut apa yang JagaWeb sendiri sediakan, ia berpegang kepada yang tercatat di halaman harga kami.

Senario: Sebuah Kedai WooCommerce dan Pangkalan Data yang Rosak

Bayangkan sebuah syarikat pengedar alat ganti kenderaan dan jentera berat mengendalikan portal e-dagang WooCommerce dengan katalog melebihi 12,000 SKU aktif, memproses purata 120 hingga 180 pesanan perbankan internet PayNet FPX setiap hari daripada bengkel membaiki kenderaan di seluruh Semenanjung Malaysia, Sabah, dan Sarawak.

Pada jam 10:15 pagi hari Isnin—waktu puncak pesanan alat ganti mingguan bermula—pusat panggilan syarikat menerima mesej WhatsApp kecemasan daripada pelanggan. Laman web tiba-tiba memaparkan skrin kosong putih (White Screen of Death - WSOD), disusuli ralat HTTP 500 dan mesej amaran: "Error Establishing a Database Connection".

Pelayan lumpuh sepenuhnya. Trafik kempen iklan Google Search yang sedang berjalan membazirkan bajet setiap saat, manakala transaksi pembayaran pelanggan yang sedang dalam proses tersekat di pintu masuk perbankan. Garis masa dan angka di bawah (contohnya, pemulihan dalam 102 minit, sifar kehilangan data) adalah sasaran ilustrasi bagi pemulihan yang bersedia dengan baik, bukan hasil yang terjamin untuk setiap insiden — masa pemulihan sebenar bergantung pada saiz pangkalan data, cara sandaran disimpan, dan sejauh mana kerosakan merebak sebelum disedari.

---

Bedah Siasat: Punca Kegagalan Sistem yang Biasa Berlaku

Dalam senario ini, pengurusan mungkin mengesyaki laman web mereka diserang penggodam atau mengalami serangan penafian perkhidmatan (DDoS). Tetapi punca yang lebih biasa dalam ekosistem WordPress tempatan ialah ini: kemas kini pemalam automatik yang tidak disahkan, dijalankan terus pada persekitaran langsung.

KRONOLOGI PUNCA KEGAGALAN:
1. Jam 02:30 Pagi: Pemalam caching dan pengindeksan pangkalan data pihak ketiga mengemas kini dirinya sendiri secara automatik.
2. Jam 02:35 Pagi: Skrip migrasi pangkalan data pemalam tersebut mengalami gelung rekursif (infinite loop) semasa mengindeks jadual 12,000 produk.
3. Skrip yang rosak itu menulis puluhan ribu entri transient sampah ke dalam jadual "wp_options" dengan bendera "autoload = 'yes'".
4. Saiz baris "alloptions" yang sepatutnya di bawah 800 KB membengkak secara mendadak kepada 86 MEGABAIT!

flowchart TD
    A[Pelawat Tiba di Laman] --> B[Pelayan Web Memanggil PHP-FPM]
    B --> C[WordPress Memuatkan Baris alloptions daripada MySQL]
    C --> D{Saiz alloptions: 86 MB}
    D -->|Setiap Proses Menggunakan > 300MB RAM| E[Had Memori PHP 256MB Tercapai]
    E --> F[PHP Fatal Error: Allowed memory size exhausted]
    F --> G[Proses MySQL Terkandas / Max Connections Tercapai]
    G --> H[Ranap Sistem Menyeluruh / HTTP 500]

Dalam seni bina teras WordPress, setiap kali halaman web dibuka oleh mana-mana pelawat, sistem akan memanggil kueri tunggal SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'. Data ini kemudiannya dimuatkan secara terus ke dalam memori kerja PHP pelayan.

Apabila saiz data autoload melonjak kepada 86MB, setiap satu permintaan pelawat memerlukan lebih daripada 350MB RAM untuk menghuraikan data tersebut. Dengan had memori PHP pelayan ditetapkan pada 256MB (memory_limit = 256M), setiap proses PHP-FPM mati serta-merta dengan ralat:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 90177536 bytes) in /public_html/wp-includes/option.php on line 189

Dalam masa 15 minit, beratus-ratus proses PHP yang tergantung memenuhi pangkalan data MySQL sehingga mencapai had sambungan maksimum (max_connections), melumpuhkan pelayan secara total.

---

Mengapa Pelan Sandaran Biasa Gagal Berfungsi Dalam Senario Ini

Sebelum menghubungi JagaWeb, katakan pengurusan cuba memulihkan laman web menggunakan pelan sandaran sedia ada daripada penyedia hosting lama mereka. Dalam senario ini, kedua-duanya gagal:

1. Sandaran Tempatan cPanel Tidak Boleh Diekstrak: Pelayan telah kehabisan 100% ruang cakera keras (0 bytes free). Puncanya: Peristiwa ralat memori PHP yang berterusan sejak jam 2:30 pagi telah menjana fail log ralat (error_log) gergasi bersaiz 39GB dalam direktori utama. Kerana cakera penuh, pelayan pangkalan data MySQL enggan dimulakan semula, dan sistem arkib cPanel tidak dapat mengekstrak sebarang fail sandaran.
2. Pemalam Sandaran Awan Percuma Terkandas di Pertengahan Jalan: Pemalam sandaran pihak ketiga yang dijadualkan menghantar salinan ke Google Drive didapati telah gagal beroperasi sejak tiga minggu lalu. Skrip sandaran PHP tersebut sentiasa terputus akibat had masa tamat eksekusi (max_execution_time 30s) kerana pangkalan data 12,000 SKU itu terlalu besar untuk diproses oleh skrip pemalam biasa.

---

Protokol Pemulihan JagaWeb: 6 Fasa, Dalam Contoh Kerja Ini

Dalam senario ini, jurutera JagaWeb diaktifkan mengikut protokol pemulihan kecemasan. Berikut adalah fasa-fasa yang dijalankan:

Fasa 1: Pengasingan Trafik & Halaman Penyelenggaraan Pinggir (Minit 0 – 12)

Langkah pertama bukan membaiki kod, tetapi menghentikan beban pada pelayan. Kami mengalihkan trafik DNS melalui proksi Cloudflare ke Halaman Penyelenggaraan Pinggir (Edge Maintenance Page) statik dengan kod status HTTP 503. Ini menghalang pelawat daripada terus mencetuskan ralat memori pada pelayan asal dan mengelakkan pelanggan daripada menghantar transaksi FPX yang tergantung.

Fasa 2: Pembebasan Ruang Cakera Melalui Terminal SSH (Minit 12 – 25)

Mengakses pelayan secara langsung melalui protokol SSH yang selamat:

# Kenal pasti fail gergasi yang memenuhi storan
df -h
du -sh /home/user/public_html/* | sort -hr | head -n 5

# Padam fail log ralat membengkak dengan selamat
rm -f /home/user/public_html/error_log
systemctl restart php8.2-fpm
systemctl restart mysqld

Ruang cakera kembali pulih dengan 45GB storan kosong, membolehkan perkhidmatan MySQL dan PHP-FPM kembali beroperasi.

Fasa 3: Pengekstrakan Arkib Luar Tapak Kalis Ubah (Minit 25 – 45)

Kami memuat turun snapshot pangkalan data yang bersih dari repositori simpanan luar tapak kami di AWS S3 Singapura (ap-southeast-1), yang disulitkan secara AES-256 dan dilindungi oleh polisi Object Lock:

aws s3 cp s3://jagaweb-immutable-backups-sg/clients/subang-auto/db_snapshot_20260924.sql.gz.enc ./
openssl enc -d -aes-256-cbc -pbkdf2 -in db_snapshot_20260924.sql.gz.enc -out clean_backup.sql.gz -pass file:/root/.backup_key
gzip -d clean_backup.sql.gz

Fasa 4: Pembedahan Pangkalan Data & Pembuangan Transients Rosak (Minit 45 – 70)

Daripada memadam keseluruhan laman web, kami melakukan pembedahan berfokus pada jadual wp_options yang rosak:

-- Bersihkan semua transients sementara yang membengkak
DELETE FROM wp_options WHERE option_name LIKE ('_transient_%') OR option_name LIKE ('_site_transient_%');

-- Semak saiz data autoload terkini
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb FROM wp_options WHERE autoload = 'yes';

Dalam beberapa saat, saiz autoload berkurang daripada 86MB kembali kepada 512KB—jauh di bawah ambang selamat 800KB. Pemalam punca masalah kemudiannya dinyahaktifkan secara terus melalui WP-CLI tanpa membuka pelayar web:

wp plugin deactivate faulty-cache-plugin --skip-plugins --skip-themes

Fasa 5: Penyelarasan Titik Masa (Point-in-Time Reconciliation) Transaksi FPX (Minit 70 – 88)

Untuk memastikan tiada pesanan pelanggan yang hilang antara jam 2:30 pagi (waktu insiden) dan jam 10:15 pagi, kami mengekstrak log transaksi gerbang pembayaran Billplz melalui panggilan API dan memadankannya dengan rekod jadual wp_wc_orders. Dua pesanan FPX yang telah ditolak wangnya oleh Maybank2u tetapi gagal dikemas kini oleh webhook telah dimasukkan semula ke dalam status "Processing" secara manual.

Fasa 6: Ujian Integriti & Pelancaran Semula Laman (Minit 88 – 102)

• Ujian aliran pembelian penuh menggunakan akaun ujian dengan transaksi FPX sebenar bernilai RM1.00.
• Ujian carian pantas katalog 12,000 produk untuk memastikan fungsi indeks berfungsi normal.
• Penamatan mod penyelenggaraan Cloudflare dan pengembalian trafik langsung kepada umum.

GARIS MASA PEMULIHAN AKHIR:
- Mula Intervensi  : 10:28 Pagi MYT
- Sistem Pulih Sepenuhnya : 12:10 Tengah Hari MYT
- Jumlah Masa Henti (RTO) : 1 Jam 42 Minit (Sasaran: < 2 Jam)
- Kehilangan Data Transaksi (RPO): SIFAR (Semua rekod FPX berjaya diselaraskan)

---

Pengajaran Kritikal untuk Pemilik E-Dagang Malaysia

Pemulihan yang pantas dalam contoh kerja ini bukan nasib baik — ia adalah hasil daripada persediaan seni bina yang mematuhi disiplin kejuruteraan yang ketat:

1. Jangan Sekali-kali Bergantung pada Sandaran Hosting Tempatan: Sandaran di pelayan yang sama akan gagal apabila berlaku bencana cakera penuh atau serangan siber. Sandaran luar tapak terasing secara geografi adalah mandatori.
2. Kemas Kini Automatik Tanpa Pengawasan Adalah Bahaya Komersial: Persekitaran pementasan terpencil (staging sandbox) wajib digunakan untuk menyaring sebarang kemas kini pemalam sebelum menyentuh pelayan pengeluaran.
3. Pengawasan Pangkalan Data Adalah Kunci Kelajuan: Memantau saiz data autoload jadual wp_options di bawah 800KB adalah perbezaan antara laman web yang responsif dan laman web yang ranap apabila menerima trafik tinggi.

Di bawah Pelan JagaWeb Care (RM450/bulan), pelanggan sebenar mendapat kemas kini teras, tema dan pemalam dengan kesediaan rollback, sandaran luar tapak harian dengan ujian pemulihan, serta pemantauan ketersediaan 24/7 dan tindak balas insiden — disiplin yang sama yang menjadikan contoh kerja di atas berjaya.

Bagi perniagaan yang ingin menguji sama ada pelan pemulihan bencana mereka benar-benar berfungsi sebelum krisis berlaku, Semakan Pemilikan & Akses (RM1,500) JagaWeb menyediakan audit menyeluruh terhadap infrastruktur, pangkalan data, dan sandaran syarikat anda.