การค้นพบสิ่งที่ไม่รู้จักที่ไม่เป็นที่รู้จัก

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

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

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

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

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

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

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

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

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

การแปลสิ่งที่ไม่รู้จักให้เป็นสิ่งที่รู้จักและการหาปริมาณสิ่งนั้น

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

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

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

• “สิ่งที่ไม่รู้จักที่เป็นที่รู้จักแล้ว” - เมื่อโค้ดเครื่องมือตรวจพบและรายงานการถดถอย และเรามีเครื่องมือจำนวนมากที่ช่วยสร้างสัญญาณนี้
• “สิ่งที่ไม่รู้จักที่ไม่เป็นที่รู้จัก” - เมื่อไม่พบการถดถอยจากภายใน และเราพึ่งพาผู้ใช้ในการรายงานการถดถอยจริง

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

การสร้างสัญญาณและข้อมูลเชิงลึก

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

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

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

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

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

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

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

ปรับขนาดให้พื้นที่ของผลิตภัณฑ์เล็กลง

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

ในการปรับขนาดมีเงื่อนไขหลายประการที่ต้องปฏิบัติตามดังนี้

1. เราต้องมีการครอบคลุมที่แม่นยำและมีการจำแนกประเภทของพื้นที่ผลิตภัณฑ์ที่มีอยู่อย่างเหมาะสม
2. เราต้องลดพื้นที่ของการถดถอยสำหรับผลิตภัณฑ์ที่มีอยู่ (โปรดอ่านเรื่องการป้องกัน)
3. เราต้องขยายอัลกอริทึมของเราให้ครอบคลุมพื้นที่ผลิตภัณฑ์ใหม่

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

ก้าวข้ามจุดบกพร่อง

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

การป้องกันเกี่ยวข้องกับแนวคิดต่อไปนี้

1. เราจะเรียนรู้จากการถดถอยครั้งก่อนๆ ได้อย่างไร
2. เราจะใช้การป้องกันแบบใดเพื่อไม่ให้การถดถอยเหล่านี้เกิดขึ้นอีก
3. เราจะทำอย่างไรเพื่อให้แน่ใจว่าเมื่อเวลาผ่านไป พื้นที่ของการถดถอยจะยังคงลดลง

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

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

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

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

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

บทความนี้เขียนขึ้นโดยร่วมมือกับคุณ Bijan Marjan ซึ่งดำรงตำแหน่งผู้จัดการโปรแกรมทางเทคนิคที่ Meta