- ระบบล่มมีสามแบบ คือรับคนไม่ไหว ข้อมูลหาย และพังเงียบ ๆ โดยไม่มีใครรู้ แต่ละแบบต้องเตรียมรับมือต่างกัน
- ไฟล์สำรองที่ไม่เคยลองกู้ ยังนับว่ามีสำรองไม่ได้
- เจ้าของกิจการต้องตอบเองสองข้อ ระบบหยุดได้นานแค่ไหน และข้อมูลหายย้อนหลังได้กี่ชั่วโมง ทีมเทคนิคจะออกแบบตามคำตอบนี้
ระบบล่มสามแบบที่ธุรกิจเจอ
สองทุ่มตรงของวันแคมเปญ ลูกค้าหลายพันคนกดเข้าเว็บพร้อมกัน หน้าเว็บเริ่มหมุนค้าง ทีมการตลาดถามในกลุ่มแชตว่าเกิดอะไรขึ้น และไม่มีใครตอบได้ ภาพนี้เป็นการล่มแบบที่คนนึกถึงมากที่สุด แต่แบบที่ทำให้เสียหายหนักกว่ามักเงียบกว่านี้
แบบแรกคือรับคนไม่ไหว ระบบที่รองรับผู้ใช้ปกติได้สบายจะช้าลงจนใช้ไม่ได้เมื่อคนเข้าพร้อมกันมากกว่าที่เคยเจอ จุดที่ตันมักเป็นฐานข้อมูล ซึ่งการเพิ่มเครื่องหน้าเว็บช่วยไม่ได้
แบบที่สองคือข้อมูลหาย สาเหตุมีตั้งแต่พนักงานลบผิดตาราง เครื่องเสีย ไปจนถึงมัลแวร์เรียกค่าไถ่ที่เข้ารหัสไฟล์ทั้งหมด กรณีหลังสุดจะลามไปถึงไฟล์สำรองด้วย ถ้าไฟล์สำรองต่ออยู่กับระบบหลักตลอดเวลา
แบบที่สามคือพังเงียบ หน้าเว็บยังเปิดได้ แต่ขั้นตอนสำคัญบางขั้นหยุดทำงาน ลูกค้าจ่ายเงินสำเร็จแต่ออเดอร์ไม่ถูกบันทึก หรืออีเมลยืนยันไม่ถูกส่ง แบบนี้แพงที่สุดเพราะกว่าจะมีคนรู้ก็ผ่านไปหลายชั่วโมง และต้องตามแก้ทีละรายการ
แอปที่สร้างด้วย Vibe Code มาพร้อมหน้าจอครบ แต่ไม่มีระบบเฝ้าดู ไม่มีการสำรองข้อมูล และไม่มีใครถูกปลุกตอนตีสอง เพราะไม่มีใครสั่งให้ AI สร้างสิ่งเหล่านี้ และตอนเดโมก็ไม่มีใครเห็นว่ามันขาด
ความพร้อมสี่ชั้น และหลักฐานที่ควรขอดู
ร้านอาหารที่พร้อมรับคืนวันศุกร์รู้ว่าครัวทำได้กี่จานต่อชั่วโมง มีคนคอยดูหน้าร้าน มีเตาสำรองเมื่อแก๊สหมด และทุกคนรู้ว่าใครตัดสินใจเมื่อไฟดับ ระบบออนไลน์ต้องการสี่อย่างเดียวกัน แต่ละอย่างมีหลักฐานที่เจ้าของกิจการขอดูได้โดยไม่ต้องเข้าใจเทคนิค
| ชั้นความพร้อม | คำถามของเจ้าของกิจการ | หลักฐานที่ควรขอดู |
|---|---|---|
| กำลังรับ | ระบบรับผู้ใช้พร้อมกันได้กี่คนก่อนจะช้า | ผล Load Test ครั้งล่าสุด พร้อมตัวเลขและวันที่ทดสอบ |
| การมองเห็น | ถ้าระบบผิดปกติตอนนี้ ใครรู้ก่อน ลูกค้าหรือเรา | หน้าจอ Monitoring และรายการแจ้งเตือนที่ตั้งไว้ |
| การกู้คืน | ถ้าฐานข้อมูลหายตอนนี้ เราได้ข้อมูลกลับมาถึงเวลาไหน และใช้เวลากี่ชั่วโมง | บันทึกการซ้อมกู้ข้อมูลครั้งล่าสุด |
| การรับมือ | คืนวันเสาร์ระบบล่ม ใครตัดสินใจ และใครแจ้งลูกค้า | Runbook และตารางเวรที่มีชื่อคนจริง |
ชั้นการกู้คืนต้องการคำตอบจากเจ้าของกิจการสองข้อ ข้อแรกคือระบบหยุดได้นานแค่ไหนก่อนที่ธุรกิจจะเสียหายเกินรับได้ วิศวกรเรียกค่านี้ว่า RTO ข้อที่สองคือข้อมูลหายย้อนหลังได้มากแค่ไหน เรียกว่า RPO ร้านที่รับออเดอร์นาทีละหลายสิบรายการรับ RPO หนึ่งวันไม่ได้ เพราะเท่ากับออเดอร์ทั้งวันหายไป ส่วนเว็บไซต์บริษัทที่อัปเดตเดือนละครั้งรับได้สบาย ยิ่งตั้งสองค่านี้ให้สั้น ค่าใช้จ่ายยิ่งสูง ตัวเลขจึงควรมาจากธุรกิจ
หลักการสำรองที่ใช้กันมานานคือ 3-2-1 เก็บสำเนาสามชุด บนสื่อสองแบบ และให้หนึ่งชุดอยู่นอกสถานที่ ชุดที่อยู่นอกสถานที่และไม่ได้ต่อกับระบบหลักคือชุดที่รอดเมื่อเจอมัลแวร์เรียกค่าไถ่
สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค
ตั้ง SLO ของเส้นทางสั่งซื้อและชำระเงิน แจ้งเตือนจากอาการที่ลูกค้าเจอ เช่น Error Rate, Latency ที่ P95 และอัตราชำระเงินสำเร็จ มี Synthetic Check ที่จำลองการสั่งซื้อทุกไม่กี่นาที ใช้ Backup แบบ Point-in-time พร้อม Restore Test อัตโนมัติ ทำ Load Test ที่ระดับสูงกว่ายอดพีคที่คาดไว้ และรับออเดอร์ผ่าน Queue เพื่อไม่ให้รายการหายเมื่อฐานข้อมูลช้า
กรณีจำลอง
แบรนด์เครื่องสำอางกับยี่สิบห้านาทีแรกของแคมเปญ
แบรนด์เครื่องสำอางที่ขายผ่านเว็บของตัวเองเปิดแคมเปญตอนสองทุ่ม สองทุ่มสี่นาทีเว็บเริ่มช้า สองทุ่มสิบนาทีหน้าชำระเงินค้าง ลูกค้าบางคนถูกตัดเงินแล้วแต่ไม่ได้เลขออเดอร์ เพราะสัญญาณยืนยันจากธนาคารส่งมาถึงตอนที่ระบบไม่ตอบ ทีมรู้เรื่องจากคอมเมนต์ในเพจตอนสองทุ่มยี่สิบห้า และรีสตาร์ตเครื่องได้ตอนสองทุ่มสี่สิบ เช้าวันรุ่งขึ้นพนักงานสามคนต้องเทียบรายการตัดเงินจากธนาคารกับออเดอร์ในระบบทีละรายการ
ถ้าย้อนดูว่าความพร้อมแต่ละชั้นจะเปลี่ยนอะไร Load Test หนึ่งสัปดาห์ก่อนแคมเปญจะบอกว่าฐานข้อมูลคือจุดที่ตัน การแจ้งเตือนที่ผูกกับอัตราชำระเงินสำเร็จจะทำให้ทีมรู้ภายในสองนาที คิวรับออเดอร์จะเก็บสัญญาณจากธนาคารไว้จนระบบกลับมา และ Runbook จะบอกว่าใครเป็นคนประกาศในเพจโดยไม่ต้องถามกันกลางเหตุ
ซ้อมกู้ข้อมูลทุกไตรมาส
- เลือกไฟล์สำรองล่าสุดของฐานข้อมูลหลัก
- กู้ลงเครื่องแยกที่ไม่ใช่ระบบจริง จับเวลาตั้งแต่เริ่มจนเปิดใช้งานได้
- ตรวจสามอย่าง ออเดอร์ล่าสุดในไฟล์สำรองเป็นของเวลาใด จำนวนลูกค้าตรงกับระบบจริงไหม และล็อกอินแล้วเปิดออเดอร์ได้หรือไม่
- จดเวลาที่ใช้กับช่วงข้อมูลที่หาย แล้วเทียบกับค่าที่เจ้าของกิจการกำหนด
- แก้จุดที่ติดขัด แล้วนัดวันซ้อมรอบถัดไป
หลักฐานคือบันทึกการซ้อมที่มีวันที่ เวลาที่ใช้ และชื่อคนทำ จุดที่การซ้อมมักพลาดคือสำรองไว้เฉพาะฐานข้อมูล ส่วนไฟล์รูปสินค้า เอกสารที่ลูกค้าอัปโหลด และค่าตั้งระบบอยู่อีกที่หนึ่งซึ่งไม่เคยถูกสำรอง
ความพร้อมระดับไหนจึงคุ้มกับธุรกิจ
ร้านที่ขายผ่าน Marketplace หรือแพลตฟอร์มร้านค้าสำเร็จรูปแทบไม่ต้องคิดเรื่องนี้ ผู้ให้บริการดูแลให้อยู่แล้ว บทความนี้พูดถึงธุรกิจที่มีระบบของตัวเอง ซึ่งต้องตัดสินใจเองว่าจะเตรียมถึงชั้นไหน
วิธีคิดที่ใช้ได้คือประเมินค่าเสียหายต่อชั่วโมง เอายอดขายต่อชั่วโมงในช่วงพีค บวกค่าแรงของทีมที่ต้องตามแก้ และบวกลูกค้าที่จะไม่กลับมา แล้วเทียบกับค่าเตรียมความพร้อมแต่ละชั้น ธุรกิจที่ค่าเสียหายต่ำควรมีอย่างน้อยการสำรองข้อมูลที่ซ้อมกู้แล้ว กับการแจ้งเตือนพื้นฐาน เพราะสองอย่างนี้ราคาไม่สูงและกันความเสียหายที่กู้กลับไม่ได้
ลำดับการลงทุนที่สมเหตุสมผลคือ เริ่มจากสำรองข้อมูลและซ้อมกู้ ตามด้วยการเฝ้าดูเส้นทางที่แตะเงิน จากนั้นทำ Load Test ก่อนแคมเปญใหญ่ เขียน Runbook พร้อมซ้อมรับเหตุ และปิดท้ายด้วยระบบสำรองที่สลับแทนได้เอง ซึ่งเรียกว่า Failover สำหรับธุรกิจที่หยุดไม่ได้เลย
ควรขยับขึ้นชั้นถัดไปเมื่อ
- ยอดขายต่อชั่วโมงช่วงพีคสูงกว่าค่าเตรียมความพร้อมของชั้นนั้น
- มีแคมเปญที่คาดว่าคนจะเข้ามากกว่าที่ระบบเคยรับ
- เคยมีเหตุที่ลูกค้ารู้ก่อนทีม
- มีสัญญากับลูกค้าองค์กรที่กำหนดเวลาให้บริการไว้
ตัวเลขที่ควรติดตามหลังลงทุนคือเวลาตั้งแต่เกิดเหตุจนทีมรู้ เวลาตั้งแต่รู้จนระบบกลับมา จำนวนเหตุที่ลูกค้ารู้ก่อน และผลการซ้อมกู้ครั้งล่าสุด ถ้าเวลาที่ทีมใช้จนรู้เหตุไม่ลดลงหลังติดตั้ง Monitoring แปลว่าการแจ้งเตือนยังผูกกับตัวเลขของเครื่อง ยังไม่ได้ผูกกับสิ่งที่ลูกค้าเจอ ควรกลับไปแก้ตรงนั้นก่อนซื้อเครื่องเพิ่ม
เตรียมระบบให้พร้อมก่อนแคมเปญใหญ่ครั้งถัดไป
ผู้บริหารของคุณเป็นคนกำหนดว่าธุรกิจรับการหยุดได้แค่ไหน ฝ่ายการตลาดรู้ปฏิทินแคมเปญ และฝ่ายบริการลูกค้ารู้ว่าลูกค้าถามอะไรเมื่อระบบมีปัญหา DNA Maker รวบรวมคำตอบจากทั้งสามฝ่ายแล้วแปลงเป็นเป้าหมายของระบบ ได้แก่ช่วงเวลาที่ห้ามหยุด เส้นทางที่ต้องเฝ้า ตั้งแต่สั่งซื้อ ชำระเงิน จนถึงยืนยันออเดอร์ และลำดับการตัดสินใจเมื่อเกิดเหตุ
ทีมของเราตรวจ Architecture ทำ Load Test และ Stress Test เพื่อหาจุดที่ตัน ติดตั้ง Monitoring กับการแจ้งเตือนบนเส้นทางที่แตะเงิน วางรอบ Backup พร้อมซ้อมกู้ และเขียน Disaster Recovery Plan กับ Runbook ร่วมกับทีมของคุณ ระบบที่ต้องการ High Availability เราออกแบบการขยายตัวและเครื่องสำรองให้ ถ้าคุณมีแคมเปญใหญ่ในอีกสองสามเดือน นำปฏิทินแคมเปญกับบันทึกของเหตุการณ์ครั้งล่าสุดที่ระบบมีปัญหามาคุยกัน งานจะเริ่มจากจุดที่เสี่ยงที่สุดก่อน
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
คำเหล่านี้ใช้ตกลงกับทีมเทคนิคว่าระบบต้องทนได้แค่ไหน สองคำแรกเป็นตัวเลขที่ฝ่ายธุรกิจต้องเป็นคนกำหนด
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| RTO | เวลานานที่สุดที่ยอมให้ระบบหยุดได้ นับตั้งแต่เกิดเหตุจนกลับมาใช้งาน | ร้านกำหนดว่าหน้าชำระเงินต้องกลับมาภายในสามสิบนาที | ค่า RTO ที่ตั้งไว้เคยทำได้จริงในการซ้อมหรือยัง? |
| RPO | ช่วงข้อมูลที่ยอมให้หายได้เมื่อต้องกู้จากไฟล์สำรอง | สำรองทุกสิบห้านาที ถ้าต้องกู้ ออเดอร์ที่หายจะไม่เกินสิบห้านาทีสุดท้าย | ถ้าต้องกู้ตอนนี้ ข้อมูลล่าสุดที่ได้กลับมาเป็นของกี่โมง? |
| Backup | สำเนาข้อมูลที่เก็บแยกจากระบบหลัก ใช้กู้เมื่อข้อมูลจริงเสียหายหรือหาย | ฐานข้อมูลออเดอร์ถูกสำเนาไปเก็บอีกที่หนึ่งทุกคืน และเก็บย้อนหลังสามสิบวัน | ไฟล์สำรองเก็บที่ไหน ใครเข้าถึงได้ และลองกู้ครั้งล่าสุดเมื่อไร? |
| Load Test | การจำลองผู้ใช้จำนวนมากเข้าระบบพร้อมกัน เพื่อวัดว่ารับได้เท่าไรและตันที่จุดไหน | จำลองลูกค้าห้าพันคนกดซื้อพร้อมกันหนึ่งสัปดาห์ก่อนแคมเปญ | ระบบเริ่มช้าที่ผู้ใช้กี่คน และจุดที่ตันคือส่วนไหน? |
| Runbook | คู่มือทีละขั้นสำหรับรับมือเหตุที่คาดไว้ล่วงหน้า ระบุคนทำและคนตัดสินใจ | เมื่อหน้าชำระเงินล่ม คู่มือบอกว่าใครตรวจอะไร ใครประกาศในเพจ และข้อความที่ใช้ | คู่มือนี้ถูกใช้ซ้อมครั้งล่าสุดเมื่อไร และคนในตารางเวรอ่านแล้วหรือยัง? |
| Disaster Recovery | แผนและระบบสำหรับกู้การให้บริการเมื่อเกิดเหตุใหญ่ เช่น ศูนย์ข้อมูลล่มหรือข้อมูลถูกเข้ารหัส | เมื่อผู้ให้บริการคลาวด์ล่มทั้งภูมิภาค ทีมเปิดระบบจากสำเนาในอีกภูมิภาคหนึ่ง | แผนนี้ครอบคลุมเหตุแบบไหน และต้องใช้ใครบ้างในการสั่งเริ่มแผน? |
| Failover | การสลับไปใช้เครื่องหรือระบบสำรองเองเมื่อเครื่องหลักหยุดทำงาน | ฐานข้อมูลหลักดับ ระบบสลับไปใช้ตัวสำรองภายในหนึ่งนาทีโดยลูกค้าไม่ต้องทำอะไร | การสลับเคยถูกทดสอบกับระบบจริงหรือยัง และมีข้อมูลหายระหว่างสลับไหม? |