Conversion หายกลางดึก แต่ทีมงงว่าใครต้องทำอะไรก่อน: เขียน Runbook รับมือเหตุขัดข้องให้ไม่ต้องเดาเอาหน้างาน

ทีมของธุรกิจขายอุปกรณ์กีฬาออนไลน์แห่งหนึ่งเจอเหตุการณ์ Conversion หยุดส่งเข้าระบบตอนตีสามของคืนวันศุกร์ ซึ่งตรงกับช่วงแคมเปญลดราคาใหญ่พอดี กว่าจะมีคนสังเกตเห็นก็ตอนเช้า และกว่าจะรู้ว่าใครควรเป็นคนแก้ปัญหานี้ก็เสียเวลาไปอีกเกือบชั่วโมง เพราะคนที่เห็นปัญหาก่อนไม่รู้ว่าตัวเองมีสิทธิ์เข้าถึงระบบพอจะแก้เองได้ไหม หรือต้องรอใคร

ปัญหาแบบนี้ไม่ได้เกิดจากทีมไม่เก่งพอ แต่เกิดจากไม่มีการเตรียมตัวไว้ล่วงหน้าว่าเมื่อเกิดเหตุขัดข้องจริง ใครต้องทำอะไรตามลำดับไหน ในสถานการณ์ที่ทุกวินาทีมีความหมาย การต้องมานั่งคิดหรือถามกันเองว่าใครรับผิดชอบ คือการเสียเวลาที่ไม่ควรเสีย

บทความนี้จะพาดูว่า runbook รับมือเหตุขัดข้องของระบบ tracking ที่ใช้งานได้จริง แม้เป็นทีมเล็กที่ไม่มีแผนกรับมือเหตุฉุกเฉินแยกต่างหาก ควรมีโครงสร้างแบบไหน

runbook คืออะไร ต่างจากเอกสารคู่มือทั่วไปยังไง

runbook คือเอกสารสั้น ๆ ที่บอกขั้นตอนชัดเจนว่าเมื่อเกิดปัญหาแบบใดแบบหนึ่ง ต้องทำอะไรตามลำดับ ต่างจากคู่มือทั่วไปที่อธิบายว่าระบบทำงานยังไง runbook เน้นที่ 'ต้องทำอะไรตอนนี้' ไม่ใช่ 'ระบบนี้ทำงานยังไง' เพราะตอนเกิดปัญหาจริง คนไม่มีเวลาอ่านคู่มือยาว ๆ

runbook ที่ดีควรอ่านและทำตามได้ภายในไม่กี่นาทีแรกของเหตุการณ์ แม้คนที่อ่านจะไม่ใช่คนที่คุ้นเคยกับระบบมากที่สุดก็ตาม

โครงสร้างที่ใช้งานได้จริง

1. ระบุอาการที่บ่งบอกว่ากำลังเกิดปัญหา เช่น 'อัตราส่งสำเร็จลดต่ำกว่า 90% นานเกิน 30 นาที' เพื่อให้คนไม่ต้องเดาว่านี่ถือว่าเป็นเหตุขัดข้องหรือยัง
2. ระบุคนที่ควรถูกแจ้งเตือนก่อนตามลำดับ พร้อมช่องทางติดต่อที่ใช้ได้จริงนอกเวลางาน ไม่ใช่แค่อีเมลที่อาจไม่มีใครเปิดดูตอนตีสาม
3. ระบุขั้นตอนตรวจสอบเบื้องต้นที่ทำได้ทันทีโดยไม่ต้องรอผู้เชี่ยวชาญ เช่นเช็ก log ล่าสุด เช็กว่า credential หมดอายุหรือไม่ เช็กว่าเป็นปัญหาที่ปลายทาง (Google, Meta) หรือต้นทาง (ระบบของธุรกิจเอง) คล้ายกับขั้นตอนที่ใช้วินิจฉัยกรณีwebhook ล่ม
4. ระบุเกณฑ์ว่าเมื่อไหร่ควรตัดสินใจ rollback หรือปิดบางฟีเจอร์ชั่วคราว แทนที่จะพยายามแก้ต้นตอทันทีขณะที่ข้อมูลยังหายอยู่
5. ระบุขั้นตอนหลังแก้ปัญหาเสร็จ เช่นต้องแจ้งใครบ้างว่าคลี่คลายแล้ว และต้องตรวจสอบข้อมูลช่วงที่ระบบมีปัญหาย้อนหลังไหม

อย่าจบแค่แก้ปัญหาเสร็จ ต้องมีการทบทวนหลังเหตุการณ์

หลังแก้ปัญหาเสร็จ ควรมีการทบทวนสั้น ๆ ว่าเกิดอะไรขึ้น ทำไมถึงเกิด และจะป้องกันไม่ให้เกิดซ้ำได้ยังไง ไม่ใช่เพื่อหาคนผิด แต่เพื่อปรับปรุง runbook ให้ดีขึ้นสำหรับครั้งต่อไป บางเหตุการณ์อาจนำไปสู่การเพิ่มตัวชี้วัดใหม่ในแดชบอร์ดสุขภาพ pipeline เพื่อจับสัญญาณเตือนได้เร็วกว่าครั้งนี้

ทีมที่ทำเรื่องนี้เป็นประจำจะพบว่า runbook ของตัวเองค่อย ๆ สมบูรณ์ขึ้นเรื่อย ๆ ตามเหตุการณ์จริงที่เคยเจอ ต่างจากทีมที่เขียน runbook ครั้งเดียวแล้วไม่เคยกลับมาแก้ไข ซึ่งมักจะล้าสมัยและใช้ไม่ได้จริงเมื่อถึงเวลาต้องใช้

ทีมเล็กไม่มีคนเวรตลอด 24 ชั่วโมง ทำยังไงได้บ้าง

• ยอมรับความจริงว่าทีมเล็กอาจตอบสนองได้ไม่ทันทีตอนกลางดึก แต่ควรมีระบบแจ้งเตือนที่ปลุกคนได้จริงสำหรับปัญหาระดับร้ายแรงเท่านั้น ไม่ใช่ทุกความผิดปกติเล็กน้อย
• กำหนดเวลาตอบสนองที่เป็นจริงได้ เช่น 'ปัญหาระดับร้ายแรงต้องมีคนรับรู้ภายใน 2 ชั่วโมง' แทนที่จะตั้งเป้าแบบธุรกิจใหญ่ที่มีทีมเวรตลอดเวลา
• พิจารณาจ้างบริการภายนอกที่รับผิดชอบเฝ้าดูระบบนอกเวลางาน ถ้าธุรกิจเริ่มพึ่งพา Conversion แบบเรียลไทม์มากขึ้นจนความเสี่ยงจากการตอบสนองช้าเริ่มสูงเกินรับได้ หรืออย่างน้อยเตรียมแผนสำรองแบบในกรณี LINE เองมีปัญหาไว้ด้วย เพราะบางครั้งต้นตอไม่ได้อยู่ที่ระบบของธุรกิจเลย

สรุป

เหตุขัดข้องของระบบ tracking ไม่ใช่คำถามว่า 'จะเกิดไหม' แต่เป็นคำถามว่า 'เมื่อเกิดแล้วทีมจะพร้อมแค่ไหน' ทีมที่มี runbook ชัดเจนจะฟื้นตัวได้เร็วกว่าทีมที่ต้องมานั่งคิดขั้นตอนกลางสถานการณ์ฉุกเฉินหลายเท่า

การลงทุนเวลาไม่กี่ชั่วโมงเขียน runbook ไว้ล่วงหน้า อาจดูเหมือนงานที่ไม่เร่งด่วนในวันที่ทุกอย่างยังปกติดี แต่มันคือสิ่งที่ทำให้คืนที่เลวร้ายที่สุดกลายเป็นแค่เหตุการณ์ที่จัดการได้ ไม่ใช่วิกฤต

• runbook เน้นบอกว่า 'ต้องทำอะไรตอนนี้' ไม่ใช่อธิบายว่าระบบทำงานยังไง
• ต้องมีอาการที่ระบุชัด ลำดับคนที่ต้องแจ้ง และขั้นตอนตรวจสอบเบื้องต้นที่ทำได้ทันที
• ทบทวนและอัปเดต runbook หลังทุกเหตุการณ์จริง ไม่ใช่เขียนครั้งเดียวแล้วปล่อยทิ้งไว้

คำถามที่พบบ่อย