15
วิเคราะห์เทเลเมทรีเพื่อคาดการณ์ปัญหาและบรรลุเป้าหมายได้ดียิ่งขึ้น
ดังที่เราเห็นในบทที่แล้ว เราจำเป็นต้องมีเทเลเมทรีในระบบ Production ที่เพียงพอทั้งในแอปพลิเคชันและโครงสร้างพื้นฐาน เพื่อให้เห็นและแก้ไขปัญหาเมื่อมันเกิดขึ้น ในบทนี้ เราจะสร้างเครื่องมือที่ช่วยให้เราค้นพบความผิดปกติและสัญญาณความล้มเหลวที่อ่อนลงเรื่อยๆ ที่ซ่อนอยู่ในเทเลเมทรีของ Production เพื่อป้องกันภัยพิบัติ เราจะนำเสนอเทคนิคทางสถิติหลากหลายรูปแบบพร้อมกรณีศึกษาที่แสดงการนำไปใช้จริง
เทเลเมทรีที่ Netflix (2012)
ตัวอย่างที่ยอดเยี่ยมของการวิเคราะห์เทเลเมทรีเพื่อค้นหาและแก้ไขปัญหาเชิงรุกก่อนที่ลูกค้าจะได้รับผลกระทบคือ Netflix Netflix มีรายได้ 6.2 พันล้านดอลลาร์จากสมาชิก 75 ล้านคนในปี 2015 รายได้ 5.7 พันล้านดอลลาร์ในเดือนมีนาคม 2020 และสมาชิก 209 ล้านคน ณ เดือนกรกฎาคม 2021 1 เป้าหมายหนึ่งของพวกเขาคือการมอบประสบการณ์ที่ดีที่สุดให้กับผู้ที่รับชมวิดีโอออนไลน์ทั่วโลก ซึ่งต้องมีโครงสร้างพื้นฐานการส่งมอบที่แข็งแกร่ง ปรับขนาดได้ และยืดหยุ่น
Roy Rapoport อธิบายถึงความท้าทายหนึ่งในการจัดการบริการสตรีมวิดีโอบนคลาวด์ของ Netflix: "เมื่อมีฝูงวัวที่ควรจะมีลักษณะและพฤติกรรมเหมือนกัน วัวตัวไหนที่ดูแตกต่างจากตัวอื่น? หรือพูดให้ชัดเจนคือ ถ้าเรามีคลัสเตอร์คอมพิวเตอร์แบบ stateless จำนวนหนึ่งพันโหนด ที่รันซอฟต์แวร์เดียวกันและรับภาระทราฟฟิกใกล้เคียงกัน ความท้าทายของเราคือการหาโหนดที่ไม่เหมือนกับโหนดอื่นๆ" 2
หนึ่งในเทคนิคทางสถิติที่ทีม Netflix ใช้ในปี 2012 คือ outlier detection (การตรวจจับค่าผิดปกติ) ซึ่งถูกนิยามโดย Victoria J. Hodge และ Jim Austin จาก University of York ว่าเป็นการตรวจจับ "สภาวะการทำงานที่ผิดปกติซึ่งอาจนำไปสู่การเสื่อมประสิทธิภาพอย่างมีนัยสำคัญ เช่น ข้อบกพร่องในการหมุนของเครื่องยนต์อากาศยาน หรือปัญหาการไหลในท่อส่ง" 3
Rapoport อธิบายว่า Netflix "ใช้ outlier detection ในวิธีที่ง่ายมาก คือเริ่มจากคำนวณก่อนว่า 'ภาวะปกติปัจจุบัน' คืออะไร ในขณะนั้นจากประชากรของโหนดในคลัสเตอร์คอมพิวเตอร์ จากนั้นเราก็ระบุว่าโหนดไหนไม่เข้ากับรูปแบบนั้น แล้วเอาโหนดเหล่านั้นออกจาก Production" 4
Rapoport กล่าวต่อว่า
เราสามารถตรวจจับโหนดที่ทำงานผิดปกติโดยอัตโนมัติ โดยไม่ต้องนิยามว่าพฤติกรรมที่ 'ถูกต้อง' คืออะไรแต่อย่างใด และเนื่องจากเราออกแบบระบบให้ทำงานได้อย่างยืดหยุ่นบนคลาวด์ เราจึงไม่ต้องแจ้งทีม Operations ให้ดำเนินการใดๆ—เราก็แค่ฆ่าโหนดที่ป่วยหรือทำงานผิดปกตินั้นทิ้ง แล้วบันทึกหรือแจ้งวิศวกรในรูปแบบที่พวกเขาต้องการ 5
Rapoport กล่าวว่า การนำกระบวนการตรวจจับเซิร์ฟเวอร์ที่เป็น outlier มาใช้ทำให้ Netflix "ลดความพยายามในการหาเซิร์ฟเวอร์ที่ป่วยลงอย่างมหาศาล และที่สำคัญกว่านั้นคือลดเวลาที่ต้องใช้ในการแก้ไขลงอย่างมาก ส่งผลให้คุณภาพบริการดีขึ้น ประโยชน์ของการใช้เทคนิคเหล่านี้ในการรักษาสุขภาพจิตของพนักงาน ความสมดุลระหว่างชีวิตและการทำงาน และคุณภาพบริการนั้นไม่สามารถประเมินค่ามากเกินไปได้" 6 *
ในบทนี้ เราจะสำรวจเทคนิคทางสถิติและการแสดงผลด้วยภาพมากมาย (รวมถึง outlier detection) ที่เราสามารถใช้วิเคราะห์เทเลเมทรีเพื่อคาดการณ์ปัญหาได้ดียิ่งขึ้น ซึ่งช่วยให้เราแก้ไขปัญหาได้เร็วขึ้น ถูกลง และทันท่วงทีกว่าที่เคย ก่อนที่ลูกค้าหรือใครก็ตามในองค์กรจะได้รับผลกระทบ นอกจากนี้ เราจะสร้างบริบทให้กับข้อมูลของเรามากขึ้นเพื่อช่วยให้เราตัดสินใจได้ดีขึ้นและบรรลุเป้าหมายขององค์กร
ใช้ค่าเฉลี่ยและค่าเบี่ยงเบนมาตรฐานเพื่อตรวจจับปัญหาที่อาจเกิดขึ้น
หนึ่งในเทคนิคทางสถิติที่ง่ายที่สุดที่เราใช้วิเคราะห์เมตริกใน Production คือการคำนวณ mean (ค่าเฉลี่ย) และ standard deviation (ค่าเบี่ยงเบนมาตรฐาน) การทำเช่นนี้ช่วยให้เราสร้างตัวกรองที่ตรวจจับเมื่อเมตริกนี้แตกต่างไปจากค่าปกติอย่างมีนัยสำคัญ และยังปรับแต่งการแจ้งเตือนให้เราสามารถดำเนินการแก้ไขได้ (เช่น แจ้งทีม Production ที่อยู่เวรตอนตี 2 AM ให้ตรวจสอบเมื่อ query ฐานข้อมูลช้ากว่าค่าเฉลี่ยอย่างมีนัยสำคัญ)
เมื่อบริการใน Production ที่สำคัญมีปัญหา การปลุกคนตอนตี 2 AM อาจเป็นสิ่งที่ถูกต้อง แต่เมื่อเราสร้างการแจ้งเตือนที่ไม่ได้นำไปสู่การดำเนินการใดๆ หรือเป็น false-positive เราก็ปลุกคนโดยไม่จำเป็นกลางดึก John Vincent หนึ่งในผู้นำยุคแรกๆ ของขบวนการ DevOps กล่าวว่า "ความล้าจากการแจ้งเตือน (alert fatigue) คือปัญหาใหญ่ที่สุดที่เรามีอยู่ในตอนนี้... เราต้องฉลาดขึ้นเกี่ยวกับการแจ้งเตือนของเรา มิฉะนั้นเราทุกคนจะคลั่งกันไปหมด" 7
เราสร้างการแจ้งเตือนที่ดีขึ้นโดยเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวน (signal-to-noise ratio) โดยมุ่งเน้นที่ความแปรปรวนหรือ outlier ที่สำคัญ สมมติว่าเรากำลังวิเคราะห์จำนวนครั้งที่พยายามเข้าสู่ระบบโดยไม่ได้รับอนุญาตต่อวัน ข้อมูลที่เก็บรวบรวมมีการกระจายตัวแบบ Gaussian (คือการกระจายตัวแบบปกติหรือโค้งระฆัง) ที่ตรงกับกราฟใน รูป 15.1 เส้นแนวตั้งตรงกลางของโค้งระฆังคือค่าเฉลี่ย และค่าเบี่ยงเบนมาตรฐานที่หนึ่ง สอง และสาม ที่ระบุด้วยเส้นแนวตั้งอื่นๆ มีข้อมูล 68%, 95% และ 99.7% ตามลำดับ
รูป 15.1: ค่าเบี่ยงเบนมาตรฐาน ( σ ) และค่าเฉลี่ย (μ) กับการกระจายตัวแบบ Gaussian
ที่มา: Wikipedia, "Normal Distribution," https://en.wikipedia.org/wiki/Normal_distribution .
การใช้งานค่าเบี่ยงเบนมาตรฐานทั่วไปคือการตรวจสอบชุดข้อมูลของเมตริกเป็นระยะ และแจ้งเตือนหากมันเปลี่ยนแปลงไปจากค่าเฉลี่ยอย่างมีนัยสำคัญ ตัวอย่างเช่น เราอาจตั้งการแจ้งเตือนเมื่อจำนวนครั้งที่พยายามเข้าสู่ระบบโดยไม่ได้รับอนุญาตต่อวันมีค่ามากกว่าค่าเฉลี่ยสามเท่าของค่าเบี่ยงเบนมาตรฐาน หากชุดข้อมูลนี้มีการกระจายตัวแบบ Gaussian เราคาดว่ามีเพียง 0.3% ของจุดข้อมูลที่จะทำให้เกิดการแจ้งเตือน
แม้การวิเคราะห์ทางสถิติแบบง่ายๆ นี้ก็มีคุณค่า เพราะไม่มีใครต้องกำหนดค่า threshold แบบตายตัว ซึ่งเป็นเรื่องที่เป็นไปไม่ได้หากเราต้องติดตามเมตริก Production นับพันหรือหลายแสนรายการ †
ติดตามและแจ้งเตือนเมื่อเกิดผลลัพธ์ที่ไม่พึงประสงค์
Tom Limoncelli ผู้ร่วมเขียน The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems และอดีต Site Reliability Engineer ที่ Google เล่าเรื่องราวต่อไปนี้เกี่ยวกับการมอนิเตอร์:
เมื่อมีคนขอคำแนะนำว่าควรมอนิเตอร์อะไร ฉันมักพูดติดตลกว่า ในโลกอุดมคติ เราควรลบการแจ้งเตือนทั้งหมดที่มีอยู่ในระบบมอนิเตอร์ของเราทิ้ง จากนั้นหลังจากที่เกิด outage ที่ผู้ใช้เห็นแต่ละครั้ง เราก็ถามว่าตัวชี้วัดอะไรที่จะคาดการณ์ outage นั้นได้ แล้วเพิ่มสิ่งเหล่านั้นลงในระบบมอนิเตอร์ของเรา แจ้งเตือนตามจำเป็น ทำซ้ำไปเรื่อยๆ แล้วเราจะเหลือแต่การแจ้งเตือนที่ป้องกัน outage ไม่ใช่ถูกถล่มด้วยการแจ้งเตือนหลังจาก outage เกิดขึ้นแล้ว 8
ในขั้นตอนนี้ เราจะจำลองผลลัพธ์ของการฝึกปฏิบัติดังกล่าว วิธีที่ง่ายที่สุดวิธีหนึ่งคือการวิเคราะห์ incidents ที่รุนแรงที่สุดของเราในอดีตที่ผ่านมา (เช่น สามสิบวัน) และสร้างรายการเทเลเมทรีที่อาจช่วยให้ตรวจจับและวินิจฉัยปัญหาได้เร็วขึ้น รวมถึงยืนยันได้ง่ายขึ้นและเร็วขึ้นว่าการแก้ไขที่มีประสิทธิภาพได้ถูกนำไปใช้แล้ว ตัวอย่างเช่น ถ้าเรามีปัญหาที่ NGINX web server หยุดตอบสนองต่อคำขอ เราจะดูตัวชี้วัดนำ (leading indicators) ที่อาจเตือนเราก่อนหน้านี้ว่าเรากำลังเริ่มเบี่ยงเบนจากการดำเนินงานปกติ เช่น:
• ระดับแอปพลิเคชัน: เวลาโหลดหน้าเว็บที่เพิ่มขึ้น เป็นต้น
• ระดับ OS: หน่วยความจำว่างของเซิร์ฟเวอร์เหลือน้อย พื้นที่ดิสก์เหลือน้อย เป็นต้น
• ระดับฐานข้อมูล: เวลาทำธุรกรรมฐานข้อมูลนานกว่าปกติ เป็นต้น
• ระดับเครือข่าย: จำนวนเซิร์ฟเวอร์ที่ทำงานอยู่เบื้องหลัง load balancer ลดลง เป็นต้น
แต่ละเมตริกเหล่านี้คือตัวบ่งชี้เบื้องต้น (precursor) ที่อาจนำไปสู่ incident ใน Production สำหรับแต่ละเมตริก เราจะกำหนดค่าระบบแจ้งเตือนให้แจ้งเราเมื่อมันเบี่ยงเบนจากค่าเฉลี่ยอย่างมีนัยสำคัญ เพื่อให้เราสามารถดำเนินการแก้ไขได้
เมื่อเราทำซ้ำกระบวนการนี้กับสัญญาณความล้มเหลวที่อ่อนลงเรื่อยๆ เราจะพบปัญหาได้เร็วขึ้นในวงจรชีวิต ส่งผลให้มี incidents ที่กระทบต่อลูกค้าและเหตุการณ์เฉียดฉิว (near misses) น้อยลง กล่าวอีกนัยหนึ่ง เรากำลังป้องกันปัญหาไปพร้อมกับทำให้ตรวจจับและแก้ไขได้เร็วขึ้น
ปัญหาที่เกิดขึ้นเมื่อข้อมูลเทเลเมทรีของเราไม่มีการกระจายตัวแบบ Gaussian
การใช้ค่าเฉลี่ยและค่าเบี่ยงเบนมาตรฐานเพื่อตรวจจับความแปรปรวนนั้นมีประโยชน์อย่างมาก อย่างไรก็ตาม การใช้เทคนิคเหล่านี้กับชุดข้อมูลเทเลเมทรีหลายชุดที่เราใช้ใน Operations จะไม่ให้ผลลัพธ์ที่ต้องการ ดังที่ Dr. Toufic Boubez กล่าวว่า "เราไม่ได้แค่ถูกปลุกตอนตี 2 AM เท่านั้น แต่เราจะถูกปลุกตอนตี 2:37 AM , 4:13 AM , 5:17 AM อีกด้วย สิ่งนี้เกิดขึ้นเมื่อข้อมูลพื้นฐานที่เราตรวจสอบไม่มีการกระจายตัวแบบ Gaussian" 9
กล่าวคือ เมื่อการกระจายตัวของชุดข้อมูลไม่มีรูปร่างแบบ Gaussian ดังที่อธิบายไว้ก่อนหน้านี้ คุณสมบัติที่เกี่ยวข้องกับค่าเบี่ยงเบนมาตรฐานก็จะใช้ไม่ได้ ตัวอย่างเช่น พิจารณาสถานการณ์ที่เรากำลังตรวจสอบจำนวนการดาวน์โหลดไฟล์ต่อนาทีจากเว็บไซต์ของเรา เราต้องการตรวจจับช่วงเวลาที่มีการดาวน์โหลดสูงผิดปกติ เช่น เมื่ออัตราการดาวน์โหลดมากกว่าค่าเฉลี่ยสามเท่าของค่าเบี่ยงเบนมาตรฐาน เพื่อที่เราจะได้เพิ่มความจุเชิงรุก
รูป 15.2 แสดงจำนวนการดาวน์โหลดพร้อมกันต่อนาทีในช่วงเวลาต่างๆ โดยมีแถบสีทับอยู่ด้านบน เมื่อแถบเป็นสีเข้ม จำนวนการดาวน์โหลดในช่วงเวลาที่กำหนด (บางครั้งเรียกว่า "sliding window") มีค่าอย่างน้อยสามเท่าของค่าเบี่ยงเบนมาตรฐานจากค่าเฉลี่ย มิฉะนั้นแถบจะเป็นสีอ่อน
รูป 15.2: ดาวน์โหลดต่อนาที: การแจ้งเตือนมากเกินไปเมื่อใช้กฎ "สามเท่าของค่าเบี่ยงเบนมาตรฐาน"
ที่มา: Dr. Toufic Boubez, "Simple math for anomaly detection."
ปัญหาที่เห็นได้ชัดจากกราฟคือเรากำลังแจ้งเตือนเกือบตลอดเวลา ทั้งนี้เพราะในเกือบทุกช่วงเวลา เรามีกรณีที่จำนวนดาวน์โหลดเกินเกณฑ์สามเท่าของค่าเบี่ยงเบนมาตรฐาน
เพื่อยืนยันสิ่งนี้ เมื่อเราสร้างฮิสโตแกรม (histogram) (ดู รูป 15.3 ) ที่แสดงความถี่ของการดาวน์โหลดต่อนาที เราจะเห็นว่ามันไม่มีรูปร่างโค้งระฆังสมมาตรแบบคลาสสิก กลับเห็นได้ชัดว่าการกระจายตัวเบ้ไปทางค่าต่ำ แสดงให้เห็นว่าส่วนใหญ่แล้วเรามีการดาวน์โหลดต่อนาทีน้อยมาก แต่จำนวนดาวน์โหลดมักจะพุ่งสูงเกินสามเท่าของค่าเบี่ยงเบนมาตรฐานเป็นประจำ
รูป 15.3: ดาวน์โหลดต่อนาที: ฮิสโตแกรมของข้อมูลที่แสดงการกระจายตัวแบบไม่ใช่ Gaussian
ที่มา: Dr. Toufic Boubez, "Simple math for anomaly detection."
ชุดข้อมูลใน Production หลายชุดไม่มีการกระจายตัวแบบ Gaussian Dr. Nicole Forsgren อธิบายว่า "ใน Operations ชุดข้อมูลของเราหลายชุดมีการกระจายตัวแบบ 'chi square' การใช้ค่าเบี่ยงเบนมาตรฐานกับข้อมูลนี้ไม่เพียงทำให้แจ้งเตือนมากเกินไปหรือน้อยเกินไป แต่ยังให้ผลลัพธ์ที่ไร้ความหมายอีกด้วย" เธอกล่าวต่อ "เมื่อคุณคำนวณจำนวนการดาวน์โหลดพร้อมกันที่มีค่าน้อยกว่าค่าเฉลี่ยสามเท่าของค่าเบี่ยงเบนมาตรฐาน คุณจะได้ค่าติดลบ ซึ่งเห็นได้ชัดว่าไม่สมเหตุสมผล" 10
การแจ้งเตือนมากเกินไปทำให้วิศวกร Operations ต้องถูกปลุกกลางดึกเป็นเวลานาน แม้ว่าจะมีสิ่งที่ทำได้น้อยก็ตาม ปัญหาของการแจ้งเตือนน้อยเกินไปก็สำคัญไม่แพ้กัน
ตัวอย่างเช่น สมมติว่าเรากำลังตรวจสอบจำนวนธุรกรรมที่เสร็จสมบูรณ์ และจำนวนธุรกรรมที่เสร็จสมบูรณ์ลดลง 50% ในตอนกลางวันเนื่องจากความล้มเหลวของคอมโพเนนต์ซอฟต์แวร์ หากค่านี้ยังอยู่ในช่วงสามเท่าของค่าเบี่ยงเบนมาตรฐานจากค่าเฉลี่ย จะไม่มีการแจ้งเตือนใดๆ เกิดขึ้น หมายความว่าลูกค้าจะพบปัญหาก่อนเรา และเมื่อถึงตอนนั้นปัญหาอาจแก้ไขได้ยากขึ้นมาก โชคดีที่มีเทคนิคที่เราสามารถใช้ตรวจจับความผิดปกติได้แม้ในชุดข้อมูลที่ไม่ใช่ Gaussian ซึ่งจะอธิบายต่อไป
กรณีศึกษา
การปรับขนาดความจุอัตโนมัติที่ Netflix (2012)
เครื่องมืออีกตัวที่พัฒนาขึ้นที่ Netflix เพื่อเพิ่มคุณภาพบริการคือ Scryer ซึ่งแก้ไขข้อบกพร่องบางประการของ Amazon Auto Scaling (AAS) ที่เพิ่มและลดจำนวนเซิร์ฟเวอร์คอมพิวเตอร์ AWS ตามข้อมูลปริมาณงาน Scryer ทำงานโดยทำนายว่าความต้องการของลูกค้าจะเป็นเท่าใดโดยอิงจากรูปแบบการใช้งานในอดีต และจัดเตรียมความจุที่จำเป็น 11
Scryer แก้ปัญหาสามประการของ AAS ปัญหาแรกคือการจัดการกับความต้องการที่พุ่งสูงอย่างรวดเร็ว เนื่องจากเวลาเริ่มต้นของ instance AWS อาจอยู่ที่สิบถึงสี่สิบห้านาที ความจุคอมพิวเตอร์เพิ่มเติมจึงมักมาช้าเกินไปที่จะรับมือกับความต้องการที่พุ่งสูง
ปัญหาที่สองคือหลังจากเกิด outage ความต้องการของลูกค้าที่ลดลงอย่างรวดเร็วทำให้ AAS ลดความจุคอมพิวเตอร์มากเกินไปจนรับมือกับความต้องการที่จะเข้ามาในอนาคตไม่ได้ ปัญหาที่สามคือ AAS ไม่ได้นำรูปแบบทราฟฟิกที่ทราบอยู่แล้วมาพิจารณาเมื่อจัดสรรความจุคอมพิวเตอร์ 12
Netflix ใช้ประโยชน์จากข้อเท็จจริงที่ว่ารูปแบบการรับชมของผู้บริโภคนั้นสอดคล้องและคาดเดาได้อย่างน่าประหลาดใจ แม้จะไม่มีการกระจายตัวแบบ Gaussian ก็ตาม รูป 15.4 เป็นแผนภูมิที่แสดงจำนวนคำขอของลูกค้าต่อวินาทีตลอดสัปดาห์ทำงาน แสดงให้เห็นรูปแบบการรับชมของลูกค้าที่สม่ำเสมอและคงที่ตั้งแต่วันจันทร์ถึงวันศุกร์ 13
รูป 15.4: ความต้องการรับชมของลูกค้า Netflix เป็นเวลาห้าวัน
ที่มา: Jacobson, Yuan, and Joshi, "Scryer: Netflix's Predictive Auto Scaling Engine," The Netflix Tech Blog, November 5, 2013, http://techblog.netflix.com/2013/11/scryer-netflixs-predictive-auto-scaling.html .
Scryer ใช้การผสมผสานของ outlier detection เพื่อทิ้งจุดข้อมูลที่ไม่มีประโยชน์ จากนั้นใช้เทคนิคเช่น fast fourier transform (FFT) และ linear regression เพื่อทำให้ข้อมูลเรียบเนียนขึ้นในขณะที่คงไว้ซึ่งการพุ่งสูงของทราฟฟิกที่เกิดขึ้นซ้ำในข้อมูล ผลลัพธ์คือ Netflix สามารถพยากรณ์ความต้องการทราฟฟิกได้อย่างแม่นยำอย่างน่าประหลาดใจ (ดู รูป 15.5 )
รูป 15.5: การพยากรณ์ทราฟฟิกของลูกค้าด้วย Scryer ของ Netflix และตารางการจัดสรรทรัพยากรคอมพิวเตอร์ AWS ที่ได้
(ที่มา: Jacobson, Yuan, Joshi, "Scryer: Netflix's Predictive Auto Scaling Engine.")
เพียงไม่กี่เดือนหลังจากเริ่มใช้ Scryer ใน Production Netflix ก็ปรับปรุงประสบการณ์การรับชมของลูกค้าได้อย่างมีนัยสำคัญ เพิ่มความพร้อมใช้งานของบริการ และลดต้นทุน Amazon EC2
กรณีศึกษาของ Netflix แสดงให้เห็นว่าเครื่องมือ Scryer ใช้ประโยชน์จากชุดข้อมูลที่ไม่ใช่ Gaussian เพื่อทำความเข้าใจลูกค้าได้ดีขึ้น และใช้พฤติกรรมของพวกเขาในการตรวจจับและคาดการณ์ปัญหา
การใช้เทคนิคการตรวจจับความผิดปกติ (Anomaly Detection)
เมื่อข้อมูลของเราไม่มีการกระจายตัวแบบ Gaussian เรายังคงสามารถหาความแปรปรวนที่น่าสนใจได้ด้วยวิธีการหลากหลาย เทคนิคเหล่านี้ถูกจัดอยู่ในหมวดกว้างๆ ที่เรียกว่า anomaly detection (การตรวจจับความผิดปกติ) ซึ่งมักถูกนิยามว่า "การค้นหาสิ่งของหรือเหตุการณ์ที่ไม่เป็นไปตามรูปแบบที่คาดหวัง" 14 ความสามารถบางอย่างนี้มีอยู่ในเครื่องมือมอนิเตอร์ของเราแล้ว ในขณะที่บางอย่างอาจต้องอาศัยความช่วยเหลือจากผู้ที่มีทักษะทางสถิติ
Tarun Reddy รองประธานฝ่าย Development และ Operations ที่ Rally Software สนับสนุนการทำงานร่วมกันระหว่าง Operations และสถิติอย่างแข็งขัน โดยกล่าวว่า:
เพื่อยกระดับคุณภาพบริการ เราใส่เมตริก Production ทั้งหมดของเราลงใน Tableau ซึ่งเป็นชุดซอฟต์แวร์วิเคราะห์ทางสถิติ เรายังมีวิศวกร Ops ที่ได้รับการฝึกอบรมด้านสถิติซึ่งเขียน R code (อีกหนึ่งชุดซอฟต์แวร์ทางสถิติ)—วิศวกรคนนี้มี backlog ของตัวเอง ที่เต็มไปด้วยคำขอจากทีมอื่นๆ ในบริษัทที่ต้องการหาความแปรปรวนให้เร็วขึ้น ก่อนที่มันจะกลายเป็นความแปรปรวนที่ใหญ่ขึ้นซึ่งอาจส่งผลกระทบต่อลูกค้าของเรา 15
หนึ่งในเทคนิคทางสถิติที่เราสามารถใช้ได้เรียกว่า smoothing (การทำให้เรียบเนียน) ซึ่งเหมาะสมเป็นพิเศษหากข้อมูลของเราเป็น time series หมายความว่าแต่ละจุดข้อมูลมีเวลากำกับ (เช่น เหตุการณ์ดาวน์โหลด เหตุการณ์ธุรกรรมที่เสร็จสมบูรณ์ ฯลฯ) Smoothing มักเกี่ยวข้องกับการใช้ moving averages (หรือ rolling averages) ซึ่งแปลงข้อมูลของเราโดยการเฉลี่ยแต่ละจุดกับข้อมูลอื่นๆ ทั้งหมดภายใน sliding window ของเรา ซึ่งมีผลทำให้ความผันผวนระยะสั้นเรียบเนียนขึ้นและเน้นแนวโน้มหรือวัฏจักรระยะยาว ‡
ตัวอย่างของ smoothing effect นี้แสดงใน รูป 15.6 เส้นสีอ่อนแสดงข้อมูลดิบ ในขณะที่เส้นสีเข้มแสดงค่าเฉลี่ยเคลื่อนที่สามสิบวัน (คือค่าเฉลี่ยของสามสิบวันย้อนหลัง) §
รูป 15.6: ราคาหุ้น Autodesk และตัวกรองค่าเฉลี่ยเคลื่อนที่สามสิบวัน
ที่มา: Jacobson, Yuan, Joshi, "Scryer: Netflix's Predictive Auto Scaling Engine."
ยังมีเทคนิคการกรองที่ซับซ้อนกว่านี้อีก เช่น fast fourier transform ซึ่งถูกใช้อย่างแพร่หลายในงานประมวลผลภาพ และ Kolmogorov-Smirnov test (ที่พบใน Graphite และ Grafana) ซึ่งมักใช้เพื่อค้นหาความเหมือนหรือความแตกต่างในข้อมูลเมตริกที่มีลักษณะเป็นช่วงเวลา/ฤดูกาล
เราคาดว่าสัดส่วนขนาดใหญ่ของเทเลเมทรีที่เกี่ยวกับข้อมูลผู้ใช้จะมีความคล้ายคลึงกันในเชิงช่วงเวลา/ฤดูกาล—ทราฟฟิกเว็บ ธุรกรรมค้าปลีก การชมภาพยนตร์ และพฤติกรรมผู้ใช้อื่นๆ อีกมากมายมีรูปแบบรายวัน รายสัปดาห์ และรายปีที่สม่ำเสมอและคาดเดาได้อย่างน่าประหลาดใจ สิ่งนี้ทำให้เราสามารถตรวจจับสถานการณ์ที่แตกต่างไปจากค่าปกติในอดีต เช่น เมื่ออัตราธุรกรรมคำสั่งซื้อของเราในบ่ายวันอังคารลดลงถึง 50% ของค่าปกติรายสัปดาห์
เนื่องจากเทคนิคเหล่านี้มีประโยชน์ในการพยากรณ์ เราอาจหาคนในฝ่ายการตลาดหรือ Business Intelligence ที่มีความรู้และทักษะที่จำเป็นในการวิเคราะห์ข้อมูลนี้ เราควรหาคนเหล่านี้และสำรวจการทำงานร่วมกันเพื่อระบุปัญหาที่มีร่วมกัน และใช้การตรวจจับความผิดปกติและการคาดการณ์ incidents ที่ดีขึ้นเพื่อแก้ไขปัญหาเหล่านั้น ¶
กรณีศึกษา
การตรวจจับความผิดปกติขั้นสูง (2014)
ที่ Monitorama ในปี 2014 Dr. Toufic Boubez ได้อธิบายถึงพลังของการใช้เทคนิค anomaly detection โดยเฉพาะอย่างยิ่งการเน้นย้ำถึงประสิทธิภาพของ Komogorov-Smirnov test ซึ่งเป็นเทคนิคที่มักใช้ในสถิติเพื่อพิจารณาว่าชุดข้อมูลสองชุดแตกต่างกันอย่างมีนัยสำคัญหรือไม่ และพบได้ในเครื่องมือ Graphite และ Grafana ที่เป็นที่นิยม 16
รูป 15.7 แสดงจำนวนธุรกรรมต่อนาทีที่เว็บไซต์ e-commerce แห่งหนึ่ง สังเกตความเป็นช่วงรายสัปดาห์ของกราฟ โดยปริมาณธุรกรรมลดลงในช่วงสุดสัปดาห์ จากการตรวจสอบด้วยสายตา เราจะเห็นว่ามีสิ่งผิดปกติเกิดขึ้นในสัปดาห์ที่สี่เมื่อปริมาณธุรกรรมปกติไม่กลับมาสู่ระดับปกติในวันจันทร์ สิ่งนี้บ่งชี้ถึงเหตุการณ์ที่เราควรตรวจสอบ
รูป 15.7: ปริมาณธุรกรรม: การแจ้งเตือนน้อยเกินไปเมื่อใช้กฎ "สามเท่าของค่าเบี่ยงเบนมาตรฐาน"
(ที่มา: Dr. Toufic Boubez, "Simple math for anomaly detection.")
การใช้กฎสามเท่าของค่าเบี่ยงเบนมาตรฐานจะแจ้งเตือนเราเพียงสองครั้ง โดยพลาดการลดลงของปริมาณธุรกรรมในวันจันทร์ที่สำคัญ ซึ่งในอุดมคติ เราควรได้รับการแจ้งเตือนว่าข้อมูลเบี่ยงเบนไปจากรูปแบบวันจันทร์ที่เราคาดหวัง
"แค่พูดว่า 'Kolmogorov-Smirnov' ก็เป็นวิธีที่ดีในการสร้างความประทับใจให้ทุกคนแล้ว" Dr. Boubez กล่าวติดตลก 17
แต่สิ่งที่วิศวกร Ops ควรบอกนักสถิติคือ เทคนิค non-parametric ประเภทนี้เหมาะกับข้อมูลใน Operations อย่างยิ่ง เพราะมันไม่ตั้งสมมติฐานเกี่ยวกับการแจกแจงแบบปกติหรือการแจกแจงความน่าจะเป็นอื่นๆ ซึ่งเป็นสิ่งสำคัญสำหรับเราในการทำความเข้าใจสิ่งที่เกิดขึ้นในระบบที่ซับซ้อนมากของเรา เทคนิคเหล่านี้เปรียบเทียบการแจกแจงความน่าจะเป็นสองแบบ ทำให้เราเปรียบเทียบข้อมูลที่มีลักษณะเป็นช่วงเวลาหรือฤดูกาล ซึ่งช่วยให้เราหาความแปรปรวนในข้อมูลที่เปลี่ยนแปลงไปในแต่ละวันหรือแต่ละสัปดาห์ 18
รูป 15.8 แสดงชุดข้อมูลเดียวกันเมื่อใช้ K-S filter โดยพื้นที่ที่สามเน้นให้เห็นวันจันทร์ที่ผิดปกติซึ่งปริมาณธุรกรรมไม่กลับมาสู่ระดับปกติ ซึ่งจะแจ้งเตือนเราถึงปัญหาในระบบที่แทบจะเป็นไปไม่ได้เลยที่จะตรวจจับด้วยการตรวจสอบด้วยสายตาหรือการใช้ค่าเบี่ยงเบนมาตรฐาน ในสถานการณ์นี้ การตรวจจับตั้งแต่เนิ่นๆ นี้สามารถป้องกันเหตุการณ์ที่ส่งผลกระทบต่อลูกค้า และช่วยให้เราบรรลุเป้าหมายขององค์กรได้ดียิ่งขึ้น
รูป 15.8: ปริมาณธุรกรรม: การใช้ Kolmogorov-Smirnov Test เพื่อแจ้งเตือนเมื่อพบความผิดปกติ
ที่มา: Dr. Toufic Boubez, "Simple math for anomaly detection."
กรณีศึกษานี้แสดงให้เห็นว่าเรายังสามารถหาความแปรปรวนที่มีค่าในข้อมูลได้แม้ไม่มีการกระจายตัวแบบ Gaussian และยังแสดงให้เห็นว่าเราสามารถใช้เทคนิคเหล่านี้ในการทำงานของเราได้อย่างไร รวมถึงวิธีที่เทคนิคเหล่านี้น่าจะถูกใช้ในองค์กรของเราในแอปพลิเคชันที่แตกต่างกันโดยสิ้นเชิง
บทสรุป
ในบทนี้ เราได้สำรวจเทคนิคทางสถิติหลายแบบที่สามารถใช้วิเคราะห์เทเลเมทรีใน Production เพื่อค้นหาและแก้ไขปัญหาได้เร็วขึ้นกว่าที่เคย โดยมักจะทำตั้งแต่ตอนที่ปัญหายังเล็กน้อยและก่อนที่จะก่อให้เกิดผลลัพธ์ที่ร้ายแรง ซึ่งช่วยให้เราค้นหาสัญญาณความล้มเหลวที่อ่อนลงเรื่อยๆ ที่เราสามารถดำเนินการได้ สร้างระบบการทำงานที่ปลอดภัยยิ่งขึ้น และเพิ่มความสามารถในการบรรลุเป้าหมายของเรา
เราได้นำเสนอกรณีศึกษาเฉพาะ รวมถึงวิธีที่ Netflix ใช้เทคนิคเหล่านี้เพื่อนำเซิร์ฟเวอร์ออกจาก Production เชิงรุกและปรับขนาดโครงสร้างพื้นฐานคอมพิวเตอร์โดยอัตโนมัติ นอกจากนี้เรายังได้พูดถึงวิธีใช้ moving average และ Kolmogorov-Smirnov filter ซึ่งทั้งสองอย่างสามารถพบได้ในเครื่องมือสร้างกราฟเทเลเมทรียอดนิยม
ในบทถัดไป เราจะอธิบายวิธีรวมเทเลเมทรีใน Production เข้ากับงานประจำวันของฝ่าย Development เพื่อทำให้การ deploy ปลอดภัยยิ่งขึ้นและปรับปรุงระบบโดยรวม