เซิร์ฟเวอร์ฐานข้อมูล tracking พังกลางดึก ไม่มี backup: บทเรียนราคาแพงและวิธีวางแผนกู้คืนให้ทัน
สรุปสั้น ๆ
ฐานข้อมูล tracking ที่เก็บประวัติการผูก UID, Click ID และ Conversion ทั้งหมด ถ้าไม่มีแผน backup และกู้คืนที่ชัดเจน วันหนึ่งที่เซิร์ฟเวอร์มีปัญหา ธุรกิจอาจเสียประวัติข้อมูลลูกค้าที่สะสมมาเป็นปีในคืนเดียว การวางแผนกู้คืนไม่ใช่เรื่องของธุรกิจใหญ่เท่านั้น แต่เป็นสิ่งที่ธุรกิจทุกขนาดควรมี
เจ้าของธุรกิจขายอะไหล่รถแห่งหนึ่งเล่าประสบการณ์ที่ยังจำได้แม่นว่า คืนหนึ่งเซิร์ฟเวอร์ที่รันระบบ tracking ของธุรกิจล่มกะทันหันจากปัญหาฮาร์ดแวร์ พอกู้เซิร์ฟเวอร์กลับมาได้ พบว่าฐานข้อมูลเสียหายบางส่วน และไม่มี backup ที่ใช้ได้เลย เพราะทีมที่ตั้งระบบไว้ตอนแรกคิดว่า 'ผู้ให้บริการคลาวด์คงมี backup ให้อยู่แล้ว' ซึ่งกลายเป็นว่าเป็นแค่สแนปช็อตของเครื่อง ไม่ใช่ backup ระดับฐานข้อมูลที่กู้คืนได้แม่นยำ ประวัติการผูก UID กับ Click ID ของลูกค้ากว่าสองปีหายไปเกือบทั้งหมด
เรื่องแบบนี้ไม่ใช่ความผิดพลาดที่หายาก เพราะระบบ tracking มักถูกมองว่าเป็นแค่ 'ตัวช่วย' ไม่ใช่ระบบหลักของธุรกิจ ทั้งที่จริง ๆ แล้วข้อมูลที่เก็บอยู่ในนั้นคือสินทรัพย์สำคัญที่สะสมมานาน การสูญเสียมันไปหมายถึงการเริ่มนับหนึ่งใหม่ในการทำความเข้าใจลูกค้า
บทความนี้จะพาดูว่าแผนกู้คืนข้อมูล (disaster recovery) ที่ทำได้จริงสำหรับธุรกิจที่ไม่มีทีม IT ขนาดใหญ่ ควรมีองค์ประกอบอะไรบ้าง
มี backup กับมีแผนกู้คืนจริง เป็นคนละเรื่องกัน
หลายทีมเข้าใจผิดว่าแค่เปิดฟีเจอร์ backup อัตโนมัติของผู้ให้บริการคลาวด์แล้วจบ แต่ backup ที่ไม่เคยถูกทดสอบกู้คืนจริง อาจใช้งานไม่ได้ตอนที่จำเป็นจริง ๆ ก็ได้ ปัญหาที่พบบ่อยคือไฟล์ backup เสียหาย หรือกู้คืนกลับมาได้แต่เวอร์ชันของระบบไม่ตรงกับที่ backup ไว้ ทำให้ข้อมูลใช้งานไม่ได้
แผนกู้คืนที่แท้จริงต้องมีมากกว่าแค่ไฟล์ backup ต้องมีขั้นตอนที่ชัดเจนว่าถ้าเกิดเหตุจริง ใครเป็นคนกดปุ่ม กู้คืนจากที่ไหน ใช้เวลาเท่าไหร่ และจะรู้ได้ยังไงว่าข้อมูลที่กู้คืนมาสมบูรณ์จริง
สองตัวเลขที่ต้องตกลงกันไว้ล่วงหน้า
| ตัวเลข | ความหมาย | ตัวอย่างการตั้งเป้า |
|---|---|---|
| RPO (Recovery Point Objective) | ยอมเสียข้อมูลย้อนหลังได้มากที่สุดกี่ชั่วโมง นับจากจุดที่ backup ล่าสุด | backup ทุก 6 ชั่วโมง แปลว่าถ้าล่มตอนไหน เสียข้อมูลได้สูงสุด 6 ชั่วโมงล่าสุด |
| RTO (Recovery Time Objective) | กู้ระบบกลับมาใช้งานได้ภายในกี่ชั่วโมง นับจากตอนเกิดเหตุ | ตั้งเป้าไว้ 4 ชั่วโมง สำหรับธุรกิจที่พึ่งพาระบบ tracking ตลอดเวลาทำการ |
ขั้นตอนที่ทำได้จริงโดยไม่ต้องมีทีม IT ใหญ่
- ตั้งค่า backup ฐานข้อมูลแบบอัตโนมัติที่ระดับฐานข้อมูลเอง ไม่ใช่แค่สแนปช็อตของเครื่องเซิร์ฟเวอร์ทั้งหมด เพราะกู้คืนได้แม่นยำกว่ามาก
- เก็บ backup ไว้อย่างน้อยสองแห่งที่แยกจากกัน เช่นในผู้ให้บริการคลาวด์เดิมและอีกที่หนึ่งแยกต่างหาก เผื่อผู้ให้บริการหลักมีปัญหาทั้งระบบ และตั้งนโยบายการเก็บรักษาข้อมูลให้สอดคล้องกับความจำเป็นทางธุรกิจและกฎหมาย
- ทดสอบกู้คืนจริงอย่างน้อยทุกไตรมาส โดยกู้คืนขึ้นสภาพแวดล้อมทดสอบแล้วตรวจสอบว่าข้อมูลครบถ้วนใช้งานได้ ไม่ใช่แค่เชื่อว่า backup มีอยู่
- เขียนขั้นตอนกู้คืนเป็นเอกสารง่าย ๆ ที่คนอื่นนอกจากผู้ตั้งระบบเดิมก็ทำตามได้ เผื่อคนที่รู้ระบบดีที่สุดไม่อยู่ในวันที่เกิดเหตุจริง
อย่าลืมส่วนอื่นนอกจากฐานข้อมูล
แผนกู้คืนที่ครบถ้วนต้องคิดถึงมากกว่าแค่ฐานข้อมูล เช่นการตั้งค่า webhook ที่ผูกกับ LINE OA, credential ที่ใช้เชื่อมกับแพลตฟอร์มโฆษณา (ดูเพิ่มเติมเรื่องการจัดการ credential), และโค้ดที่ deploy อยู่บนระบบ ทั้งหมดนี้ต้องกู้คืนกลับมาให้ทำงานร่วมกันได้ ไม่ใช่แค่มีข้อมูลแต่ระบบรอบข้างใช้งานไม่ได้ ควรมีแผนสื่อสารกับลูกค้าและทีมงานตามแนวทางของการรับมือเหตุการณ์ข้อมูลรั่วไหลควบคู่ไปด้วย เผื่อเหตุการณ์นั้นกระทบข้อมูลลูกค้าโดยตรง
สรุป
ข้อมูลการผูก UID, Click ID และประวัติ Conversion ที่สะสมมาเป็นปี ไม่ใช่สิ่งที่สร้างใหม่ได้ในวันเดียวถ้าหายไป มันคือความเข้าใจลูกค้าที่ธุรกิจใช้เวลาสั่งสมมานาน
แผนกู้คืนที่ทดสอบจริงแล้ว ไม่ใช่แค่ backup ที่นอนเงียบอยู่ในระบบ คือสิ่งที่แยกธุรกิจที่ฟื้นตัวได้ภายในไม่กี่ชั่วโมง กับธุรกิจที่ต้องเริ่มนับหนึ่งใหม่ทั้งหมด
- มี backup อัตโนมัติกับมีแผนกู้คืนที่ทดสอบจริงแล้ว เป็นคนละเรื่องกัน
- ตกลง RPO และ RTO ล่วงหน้าให้ชัดเจนตามความสำคัญของข้อมูลต่อธุรกิจ
- แผนกู้คืนต้องครอบคลุมมากกว่าฐานข้อมูล รวมถึง credential และการตั้งค่า webhook ด้วย
คำถามที่พบบ่อย
ธุรกิจขนาดเล็กจำเป็นต้องมีแผนกู้คืนข้อมูลระดับนี้ไหม
จำเป็นในระดับพื้นฐานเสมอ ไม่ว่าธุรกิจขนาดไหน เพราะข้อมูลที่สะสมมาคือสินทรัพย์ที่กู้กลับมาไม่ได้ถ้าไม่มีการเตรียมไว้ ระดับความซับซ้อนของแผนอาจต่างกันตามขนาดธุรกิจ แต่หลักการพื้นฐานควรมีเหมือนกัน
ใช้บริการคลาวด์ที่มี backup อัตโนมัติอยู่แล้ว ยังต้องทำอะไรเพิ่มไหม
ควรตรวจสอบให้แน่ใจว่า backup ที่มีอยู่คือระดับฐานข้อมูลจริง ไม่ใช่แค่สแนปช็อตของเครื่อง และควรทดสอบกู้คืนจริงอย่างน้อยครั้งหนึ่งเพื่อยืนยันว่าใช้งานได้ ไม่ควรเชื่อโดยไม่เคยทดสอบ
RPO กับ RTO ควรตั้งเท่าไหร่ถึงจะเหมาะ
ขึ้นอยู่กับว่าธุรกิจพึ่งพาข้อมูลนี้มากแค่ไหน ธุรกิจที่ตัดสินใจงบโฆษณารายวันจากข้อมูลนี้ควรตั้ง RPO และ RTO ให้สั้น ส่วนธุรกิจที่ใช้ข้อมูลเพื่อวิเคราะห์ภาพรวมรายเดือนอาจยอมรับค่าที่หลวมกว่าได้
ทดสอบกู้คืนบ่อยแค่ไหนถึงจะพอ
อย่างน้อยทุกไตรมาสสำหรับธุรกิจทั่วไป และควรทดสอบทันทีหลังมีการเปลี่ยนแปลงโครงสร้างฐานข้อมูลครั้งใหญ่ เพื่อให้แน่ใจว่ากระบวนการกู้คืนยังใช้ได้กับโครงสร้างใหม่
ถ้าไม่มีทีมเทคนิคเลย ควรทำยังไง
ควรปรึกษาผู้ให้บริการระบบ tracking หรือเอเจนซี่ที่ดูแลอยู่ให้ยืนยันเป็นลายลักษณ์อักษรว่ามีนโยบาย backup และกู้คืนอย่างไร แทนที่จะสันนิษฐานเอาเองว่าทุกอย่างถูกดูแลให้แล้ว
บทความที่เกี่ยวข้อง
