ดูแลและอัปเดตปลั๊กอินชำระเงินอย่างปลอดภัย โดยไม่ให้ร้านหยุดชะงัก
อ่าน 1 นาที
ไม่มีรูปภาพ
ปลั๊กอินรับชำระเงินเป็นชิ้นส่วนที่ไม่ควรพังเด็ดขาด ถ้าหยุดทำงานตอนกลางวันที่ลูกค้าเยอะ ออเดอร์จะค้างและทีมต้องตามเก็บเอง แต่การไม่อัปเดตเลยก็เสี่ยงเรื่องความปลอดภัย บทความนี้เสนอขั้นตอนอัปเดตอย่างมีแบบแผน ใช้ได้กับปลั๊กอินของ WooCommerce, WHMCS, Magento หรือระบบใดก็ตาม
ทำไมต้องอัปเดตอย่างระมัดระวังทั้งสองด้าน
การอัปเดตมีสองความเสี่ยงที่ดึงกันอยู่ ถ้าอัปเดตช้า ช่องโหว่ที่รู้กันแล้วยังเปิดอยู่ ถ้าอัปเดตเร็วโดยไม่ทดสอบ อาจเจอปัญหาไม่เข้ากับธีม ปลั๊กอินอื่น หรือเวอร์ชันของระบบ ทางออกคือกำหนดขั้นตอนที่ทำซ้ำได้ ไม่ใช่ตัดสินใจตามอารมณ์
ก่อนอัปเดต
- อ่านบันทึกการเปลี่ยนแปลง ว่าแก้อะไร มีการเปลี่ยนวิธีตั้งค่าหรือไม่ ถ้ามีคำว่าไม่รองรับย้อนหลัง ให้ระวังเป็นพิเศษ
- สำรองข้อมูล ทั้งไฟล์และฐานข้อมูล และตรวจว่าไฟล์สำรองเปิดได้
- จดการตั้งค่าปัจจุบัน เช่นถ่ายภาพหน้าตั้งค่า (ไม่ถ่ายรวมค่าลับ เช่น API key หรือ webhook secret) เพื่อเทียบหลังอัปเดต
- เลือกช่วงเวลา ที่ออเดอร์น้อย และมีคนพร้อมดูแล ไม่ใช่ก่อนปิดงานวันศุกร์
ทดสอบบน staging ก่อน
เว็บทดสอบที่เป็นสำเนาของเว็บจริงช่วยให้เห็นปัญหาล่วงหน้า สิ่งที่ควรทดลองคือสั่งซื้อครบวงจรหนึ่งรายการ ตั้งแต่เลือกวิธีชำระ จ่ายเงินด้วยยอดน้อย อัปโหลดสลิป จนออเดอร์เปลี่ยนสถานะ สำหรับปลั๊กอินของ PPay เอกสารเองก็แนะนำให้ลองบน staging เพราะต้องทดสอบกับระบบจริงของแต่ละร้านอยู่แล้ว
รายการทดสอบหลังอัปเดตบน staging
- สร้างรายการชำระสำเร็จและได้ลิงก์จ่ายเงิน
- หน้าชำระเงินและปุ่มกลับร้านทำงาน
- ออเดอร์เปลี่ยนสถานะเมื่อชำระผ่าน
- กรณีสลิปไม่ผ่านหรือยอดไม่ตรงแสดงผลถูกต้อง
- งานตรวจเป็นรอบ (cron) ยังทำงาน
ระหว่างและหลังอัปเดตบนเว็บจริง
- อัปเดตทีละตัว ไม่อัปเดตทั้งหมดพร้อมกัน เพื่อให้รู้ว่าตัวไหนทำให้เกิดปัญหา
- ทดลองสั่งซื้อจริงด้วยยอดน้อย
- ตรวจว่าการแจ้งเตือน (webhook) ยังถึงเว็บ ถ้าตั้ง secret ไว้ ต้องไม่หายไป
- เฝ้าดูออเดอร์ในชั่วโมงถัดไปว่ามีออเดอร์จ่ายแล้วแต่สถานะไม่เปลี่ยนหรือไม่
ระบบของ PPay รองรับกรณีที่ webhook ล้มเหลว เพราะปลั๊กอินยังตรวจสถานะเป็นรอบทุก 5 นาทีตามเอกสาร แต่ก็ไม่ควรพึ่งอย่างเดียวโดยไม่เฝ้าดู
แผนย้อนกลับ
เขียนไว้ก่อนเริ่ม ไม่ใช่ตอนเกิดปัญหา
- เก็บไฟล์ปลั๊กอินเวอร์ชันเดิมไว้ เพื่อติดตั้งทับย้อนกลับได้
- กำหนดเกณฑ์ชัดเจนว่า "ถ้าเกิดอะไร จะย้อนกลับ" เช่นสั่งซื้อทดสอบไม่ผ่าน
- ถ้าฐานข้อมูลถูกปรับโครงสร้างโดยการอัปเดต อ่านคู่มือก่อนว่าย้อนกลับได้หรือไม่
- ระหว่างแก้ไข ให้ลูกค้ามีทางเลือกสำรอง เช่นแจ้งช่องทางติดต่อร้าน
การดูแลต่อเนื่อง
| ความถี่ | งาน |
|---|---|
| ทุกสัปดาห์ | ตรวจว่ามีอัปเดตด้านความปลอดภัยหรือไม่ ตรวจออเดอร์ค้าง |
| ทุกเดือน | ตรวจผู้ใช้ที่มีสิทธิ์สูง ตรวจปลั๊กอินที่ไม่ใช้ |
| ทุกไตรมาส | ทดลองกู้คืนข้อมูลสำรอง ทบทวนคีย์และ secret |
เช็กลิสต์สรุป
- มีขั้นตอนอัปเดตเป็นลายลักษณ์อักษร
- มี staging หรืออย่างน้อยมีแผนทดสอบยอดน้อยบนเว็บจริง
- มีไฟล์สำรองและเวอร์ชันเดิมพร้อมย้อนกลับ
- มีคนรับผิดชอบเฝ้าดูหลังอัปเดต
อ่านเรื่องความปลอดภัยของเว็บเพิ่มที่ ความปลอดภัยเว็บ WordPress และดูเวอร์ชันปลั๊กอินล่าสุดที่ หน้าปลั๊กอิน หากมีคำถามดู FAQ