Player Unknown’s Bug: ถ้าบันทึกปัญหาที่หาสาเหตุไม่ได้ เราจะเติบโตได้ไหม?

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

---

เวลาพัฒนาซอฟต์แวร์ไปเรื่อย ๆ ก็มักจะเจอปัญหาที่ไม่รู้สาเหตุ
โดยเฉพาะฝั่งเว็บฟรอนต์เอนด์ นอกจากจะได้รับผลจากสถานะของเซิร์ฟเวอร์แล้ว ยังได้รับอิทธิพลจากปัจจัยภายนอกอีกมากมาย เช่น ประเภทหรือเวอร์ชันของเบราว์เซอร์, Chrome Extension เป็นต้น

ถ้าเราไม่รู้สาเหตุของปัญหา หรือสาเหตุของปัญหาไม่ได้อยู่ที่เรา ก็อดสงสัยไม่ได้ว่า แค่ทำ postmortem อย่างเดียวจะเพียงพอสำหรับการสร้างโครงสร้างที่แข็งแรงหรือไม่ (หรือว่ายังไม่พอ?)

จุดเริ่มต้น

ครั้งหนึ่งเคยใช้เวลาถึง 9 ชั่วโมงตั้งแต่ได้รับรายงานปัญหาที่ไม่ทราบสาเหตุจนถึงปิดเคส
หลังจากทุ่มเวลาไปกับการดีบักปัญหา 4 ชั่วโมง จึงได้รู้ว่าสาเหตุของปัญหาไม่ได้อยู่ที่โค้ดภายในหรืออินฟราสตรักเจอร์ แต่เกิดจากบั๊กของ Chrome Extension ของผู้ใช้

ไม่เพียงแต่ยากที่จะระบุว่าสาเหตุของปัญหาอยู่ที่ไหน แต่กว่าจะรู้ว่าสาเหตุอยู่ภายนอกก็ใช้เวลา ถึง 4–5 ชั่วโมง ทำให้รู้สึกโกรธตัวเองมาก
จึงสร้างหน้าใน Notion ชื่อว่า ‘Player Unknown’s Bug(PUB)’ และจดบันทึกทั้งสิ่งที่ลองทำระหว่างรับมือกับปัญหา สิ่งที่น่าเสียดาย และสิ่งที่ควรปรับปรุงเอาไว้ พร้อมกับความหงุดหงิดในตอนนั้น

การฝังรากเป็นวัฒนธรรม และการพัฒนาต่อ

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

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

องค์กรพัฒนาของ AB180 มีการทำ ‘postmortem’ เป็นพื้นฐานอยู่แล้ว หาก postmortem ภายในบริษัทเน้นที่ Resolution และ Action Items เป็นหลัก PUB มีเป้าหมายเพื่อรวบรวม Lesson Learn สร้างความปลอดภัยทางใจในการรับมือปัญหา และจัดระเบียบว่าปัจจัยใดควรถูกตรวจสอบก่อนเมื่อเจอปัญหาที่ไม่รู้สาเหตุ

วัฒนธรรมการแบ่งปันข้อมูลอย่างสมัครใจ

เมื่อวัฒนธรรมนี้เริ่มลงหลักปักฐาน ปัญหาที่สมาชิกคนอื่น ๆ ในทีมรับมือก็เริ่มสะสมเพิ่มขึ้นทีละเรื่อง
การทบทวนย้อนหลังเพื่อพูดถึงสิ่งที่ไม่เคยรู้มาก่อน และใช้เวลาเจาะลึกมากขึ้น เริ่มทำงานเหมือน ‘เซสชันแบ่งปันความรู้’ เล็ก ๆ ที่เกิดขึ้นอย่างสมัครใจ

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

Lesson Learn

• ต้องยกระดับความปลอดภัยทางใจของทั้งทีมที่รับมือเหตุขัดข้อง และเพื่อให้เป็นเช่นนั้น ต้องพูดคุยกันให้มากขึ้น
• หากไม่เป็นเช่นนั้น ปัญหาจะเกิดซ้ำ และจะฝังความคิดในองค์กรว่า ‘ปัญหา = สิ่งที่ไม่ควรพูดถึง’
• การแบ่งปันข้อมูลสามารถสร้างความปลอดภัยทางใจในองค์กรได้ และยิ่งไปกว่านั้นยังยกระดับมันได้ด้วย
• และวัฒนธรรมการแบ่งปันข้อมูลแบบนี้ อาจเริ่มต้นได้จากเรื่องที่เล็กกว่าที่คิด

[kunggom]

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

[hiddenest]

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

ขอบคุณที่อ่านบทความอันยังไม่สมบูรณ์ของผมนะครับ/คะ

[kunggom]

จริง ๆ แล้วไม่ว่าจะเมื่อก่อนหรือตอนนี้ ผมก็ไม่เคยคิดว่าการจัดการเหตุขัดข้องเป็นเรื่องสนุกเลย
ยกตัวอย่างเช่นเหตุขัดข้องที่จัดการวันนี้ ดันเกิดขึ้นในผลิตภัณฑ์ที่ทีมของเราถูกปิดกั้นการเข้าถึงเซิร์ฟเวอร์ production โดยตรงพอดี นอกจากช่วงต้นที่พบเหตุขัดข้องและเริ่มตรวจสอบอาการ กับช่วงท้ายที่กว่าจะได้สิทธิ์เข้าถึงเซิร์ฟเวอร์มาอย่างหวุดหวิดแล้ว ก็เลี่ยงไม่ได้ที่จะรู้สึกหมดพลังอยู่บ้าง ถ้าทีมของเราขอให้ช่วยดำเนินการอะไรบางอย่างแบบนั้นแบบนี้ ทีมปฏิบัติการเซิร์ฟเวอร์ก็ปฏิเสธด้วยเหตุผลฝั่งเขาเอง
ดังนั้นสิ่งที่ผมรู้สึกระหว่างเขียนเอกสาร postmortem ก่อนเลิกงาน น่าจะใกล้เคียงกับความคิดว่า ‘ให้ตายเถอะ ต่อไปจะไม่พลาดแบบนี้อีกแล้ว!’ มากกว่า

[hiddenest]

พอได้ฟังสิ่งที่คุณเล่ามา ก็รู้สึกได้เลยว่าคงหนักหนามากจริง ๆ ครับ/ค่ะ อย่างที่คุณบอก พอไม่ทำผิดพลาดแบบเดิมซ้ำ ก็มีแต่จะค่อย ๆ ดีขึ้นทีละนิด... ฮือ

[kunggom]

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