Skip to content

Domain, hosting, code and data — in your name, in writing

jagaweb.

Penyelenggaraan & Penjagaan Laman

Menyediakan Laman Web untuk Waktu Puncak Musim di Malaysia

Bacaan 6 minitOleh JagaWeb

Kapasiti, pembekuan perubahan, ujian checkout dan pelan rollback untuk Ramadan, Raya, Hari Merdeka, 11.11 dan jualan hujung tahun.

Kalendar runcit Malaysia bukan mempunyai satu musim puncak sahaja — ia mempunyai beberapa musim puncak, tersebar tidak sekata sepanjang tahun, masing-masing dengan bentuk dan tekanan tersendiri terhadap sesebuah laman web. Ramadan dan Hari Raya Aidilfitri bergerak mengikut kalendar lunar dan membawa beberapa minggu persediaan sebelum tarikh sebenar setiap tahun. Hari Merdeka jatuh pada 31 Ogos, diikuti Hari Malaysia pada 16 September, disambut di seluruh negara sejak 2010 (Malaysia Day, Wikipedia) — kedua-duanya kerap dijadikan asas untuk promosi bertemakan kebangsaan. Peniaga dalam talian menganjurkan 11.11 dan 12.12 sebagai kempen jualan tahunan, tarikh yang telah menjadi lumrah di platform membeli-belah yang beroperasi di Malaysia. Kemudian ada tempoh jualan hujung tahun yang berlarutan sehingga Disember. Tiada satu pun daripada tempoh ini berkelakuan sama, tetapi semuanya berkongsi satu perkara: laman web yang baik-baik sahaja pada hari Selasa biasa boleh mengalami tekanan sebenar apabila promosi, cuti umum dan lonjakan tumpuan berlaku dalam minggu yang sama — dan kebanyakan pembetulan untuk itu perlu dibuat lebih awal, bukan semasa ia berlaku.

Ini bukan tentang mengejar kalendar pemasaran. Ini tentang beberapa keputusan teknikal dan operasi yang menentukan sama ada tempoh puncak berjalan lancar atau menjadi huru-hara saat akhir.

Kenali had maksimum sebelum anda memerlukannya

Soalan khusus yang wajar dijawab sebelum sebarang tempoh puncak yang diketahui adalah mudah: jika bilangan pelawat, atau bilangan orang yang cuba checkout pada masa yang sama, meningkat dengan ketara berbanding minggu biasa, adakah apa-apa di laman web akan benar-benar gagal berfungsi? Bukan "berapa laju halaman utama dimuat naik sekarang" — itu soalan lebih sempit tentang prestasi harian — tetapi sama ada pelan hosting, pangkalan data, dan mana-mana caching di hadapannya mampu menyerap peningkatan berterusan tanpa sesiapa perlu mengetahuinya dengan cara yang menyakitkan, secara terbuka, di tengah-tengah promosi.

Caching melakukan banyak kerja praktikal di sini. Halaman yang dihidangkan daripada cache — salinan siap sedia, diberikan sebagaimana adanya — hampir tidak memerlukan kos untuk dihidangkan berbanding halaman yang dibina semula daripada pertanyaan pangkalan data pada setiap permintaan. Untuk kandungan yang tidak berubah dari minit ke minit, iaitu kebanyakan halaman, pada kebanyakan masa, caching selalunya menjadi pembeza antara laman web yang menyerap peningkatan trafik tanpa sesiapa perasan dan laman web yang menjadi perlahan tepat pada saat paling kritikal. Mengesahkan bahawa caching sememangnya dikonfigurasikan — bukan diandaikan begitu kerana seseorang pernah menetapkannya bertahun-tahun lalu — wajar dilakukan sebelum tempoh puncak yang diketahui, bukan semasa ia berlangsung.

Bekukan perubahan berisiko sebelum puncak, bukan semasa puncak

Masa paling berisiko untuk membuat perubahan besar kepada laman web ialah sejurus sebelum, atau semasa, tempoh yang paling memerlukan ia berfungsi dengan sempurna. Dinyatakan secara jujur, ini kedengaran jelas, tetapi tetap sering diabaikan — biasanya kerana promosi juga merupakan saat yang tepat apabila pihak pemasaran mahukan banner baharu, laman pendaratan baharu, atau kemas kini harga "ringkas" dinaikkan secara live.

Pembekuan perubahan — satu tempoh yang dipersetujui di mana hanya pembetulan mendesak dinaikkan live dan segala-galanya yang lain menunggu — adalah kawalan yang mudah dan tidak glamor tetapi mencegah sebahagian besar gangguan yang berpunca daripada tindakan sendiri. Ia tidak bermaksud tiada apa-apa berubah; ia bermaksud perubahan yang tidak benar-benar perlu dijadualkan sebelum pembekuan bermula atau selepas ia tamat, supaya versi laman web yang live semasa minggu paling kritikal juga merupakan versi yang paling diuji dan paling kurang disentuh baru-baru ini. Bersetuju dengan tempoh pembekuan lebih awal, dan memberitahu semua pihak yang mungkin meminta perubahan "kecil" semasa tempoh itu, adalah sebahagian besar daripada kerja sebenar.

Uji laluan checkout dan pembayaran seperti seorang pelanggan

Setiap promosi bermusim mengandaikan laluan pembayaran berfungsi. Andaian itu wajar disemak secara langsung, bukan dianggap benar hanya kerana laman web dimuat naik seperti biasa. Ujian sebenar hujung-ke-hujung — menambah produk, memasukkan butiran penghantaran, sampai ke langkah pembayaran, dan menyelesaikan transaksi sebenar atau sandbox di mana gateway menyokongnya — mengesan masalah yang tidak akan dikesan oleh semakan halaman utama sahaja: kelayakan tamat tempoh pada payment gateway, pengiraan penghantaran yang rosak akibat kod diskaun promosi baharu, webhook yang senyap-senyap berhenti mengesahkan pesanan walaupun storefront kelihatan baik-baik sahaja. Inilah kegagalan yang tidak kelihatan sebagai gangguan; laman web kelihatan baik, pemasaran kelihatan baik, tetapi pesanan senyap-senyap gagal di sebaliknya.

Ini wajar dilakukan pada pelayar desktop dan peranti mudah alih, memandangkan banyaknya trafik runcit di Malaysia tiba melalui telefon, dan ia wajar diulang selepas sebarang perubahan yang dibuat menjelang tempoh puncak — termasuk perubahan yang dibuat khusus untuk persediaan itu.

Jadualkan kandungan dan promosi, bukan menerbitkannya secara live di bawah tekanan

Halaman promosi, banner, dan perubahan harga yang terikat kepada tarikh tertentu lebih mudah dilakukan dengan betul apabila ia dibina dan dijadualkan lebih awal, disemak sekali dengan tenang, kemudian sekadar dihidupkan — berbanding disusun dan diterbitkan pada saat-saat akhir sebelum kempen bermula. Kebanyakan sistem pengurusan kandungan menyokong penerbitan berjadual atas sebab ini. Menggunakannya menghapuskan satu kategori kesilapan saat akhir: promosi yang live sejam lewat, atau dengan tarikh tahun lepas masih kekal dalam teks, kerana seseorang melakukannya secara live di bawah tekanan masa.

Ada pelan rollback, dan tahu cara menggunakannya

Walau bagaimana teliti sekalipun persediaan untuk tempoh puncak, sesuatu masih boleh tersasar — perubahan yang dianggap selamat berinteraksi buruk dengan beban tambahan, atau perkhidmatan pihak ketiga yang laman web bergantung kepadanya mengalami masalah sendiri yang tiada kaitan dengan anda. Persediaan yang berguna bukanlah cuba menjamin tiada apa-apa akan tersasar; ia adalah mengetahui, lebih awal, cara membatalkan perubahan terkini jika ia didapati punca masalah. Ini bermakna mempunyai backup terkini yang telah disahkan atau sejarah deployment yang jelas untuk kembali kepadanya, dan — sama pentingnya — mengetahui siapa mempunyai akses dan kuasa untuk benar-benar melakukannya dalam masa singkat, bukan mencari jawapannya buat kali pertama semasa insiden itu sendiri berlaku.

Senarai semak ringkas sebelum puncak

  • Sahkan caching aktif dan benar-benar berfungsi, bukan sekadar diandaikan
  • Persetujui dan maklumkan tempoh pembekuan perubahan kepada semua pihak yang mungkin meminta pengecualian
  • Jalankan ujian hujung-ke-hujung checkout atau borang pertanyaan, pada mudah alih dan desktop
  • Jadualkan kandungan promosi dan perubahan harga lebih awal berbanding menerbitkannya secara live
  • Sahkan backup terkini wujud, dan seseorang tahu cara memulihkannya
  • Sahkan siapa mempunyai akses untuk membuat pembetulan kecemasan, dan cara menghubungi mereka, semasa tempoh puncak

Tiada satu pun daripada ini khusus untuk mana-mana tarikh kempen — senarai yang sama terpakai sama ada puncaknya Ramadan dan Raya, Hari Merdeka, 11.11, atau tempoh jualan hujung tahun. Yang berubah ialah kalendar. Senarai semak kekal sama.

Di mana ini sesuai

Menyelesaikan senarai ini sekali, menjelang tempoh puncak yang diketahui, adalah jenis tugas yang sesuai secara semula jadi dalam penjagaan laman web berterusan berbanding projek sekali sahaja. JagaWeb Care (RM450/bulan) merangkumi pemantauan dan perhatian yang menjadikan pembekuan perubahan dan pelan rollback benar-benar boleh digunakan; di mana kerja pra-puncak turut melibatkan membuat perubahan — melaraskan konfigurasi caching, menjadualkan kandungan promosi, menyemak tetapan payment gateway — Care + Changes (RM1,500/bulan) membina peruntukan bulanan untuk itu. Tiada satu pun menjanjikan tempoh puncak bebas masalah, yang tiada sesiapa boleh berjanji secara jujur — hanya bahawa seseorang sedang memberi perhatian apabila ia penting.

WhatsApp