เจาะลึก
Infra / AIOps
เน็ตฟลิกซ์ทิ้งการเฝ้าระวังแบบตั้งรับ ใช้ AI วิ่งหา root cause เองที่สเกล 38 ล้านอีเวนต์ต่อวินาที
วิศวกรสองคนจากเน็ตฟลิกซ์เล่าว่าพวกเขาเปลี่ยนระบบ observability จาก "รอคนไปนั่งดูแดชบอร์ด" มาเป็นกราฟความรู้ที่ AI คิวรีเองได้
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ถ้า telemetry ของคุณเยอะจนคนอ่านไม่ทัน คำถามจริงๆ ไม่ใช่ "จะทำแดชบอร์ดยังไงให้สวยขึ้น" แต่คือ "จะให้ AI อ่านแทนแล้วสรุปให้เราฟังได้ไหม"
พราะถ้าคุณยังคิดว่า observability คือการเปิด Grafana ดูกราฟสีแดงๆ แล้วไล่หาว่าอะไรพัง เน็ตฟลิกซ์กำลังบอกคุณทางอ้อมว่าคุณกำลังทำมันผิดวิธี พวกเขาเพิ่งออกมาแชร์ในงานนำเสนอว่าจัดการระบบ observability ที่รับอีเวนต์ 38 ล้านตัวต่อวินาทีได้ยังไง และคำตอบไม่ใช่ "จ้างคนเพิ่ม" หรือ "ซื้อเครื่องมือใหม่" แต่คือการสร้าง ontology สำหรับปฏิบัติการที่ขับเคลื่อนด้วย AI
ฟังดูเหมือนโจทย์ธรรมดาของบริษัทเทคยักษ์ใหญ่ แต่ตัวเลข 38 ล้านอีเวนต์ต่อวินาทีเนี่ยมันไม่ธรรมดาเลย มันคือระดับที่ถ้าคุณพยายามใช้วิธีเดิมๆ อย่าง "ตั้ง alert ไว้แล้วรอให้มันเด้ง" คุณจะจมอยู่กับ alert ที่ไม่ actionable เป็นพันๆ ตัวต่อวัน ทีมงานเลยต้องหันมาคิดใหม่ทั้งหมด
Prasanna Vijayanathan และ Renzo Sanchez-Silva สองวิศวกรจากเน็ตฟลิกซ์เล่าว่า พวกเขาเปลี่ยนจากการเฝ้าระวังแบบตั้งรับ (reactive monitoring) มาสู่สิ่งที่เรียกว่า operational ontology ที่ขับเคลื่อนด้วย AI แทน ความหมายง่ายๆ คือแทนที่จะให้มนุษย์ไปนั่งตีความว่ากราฟนี้หมายถึงอะไร พวกเขาสร้างชั้นความรู้ที่ AI เข้าใจได้ แล้วให้มันจัดการตีความแทน
หัวใจของเรื่องนี้คือการรวม MELT telemetry — Metrics, Events, Logs, Traces — ที่ปกติกระจัดกระจายอยู่คนละระบบ ให้กลายเป็น knowledge graph ที่คิวรีได้ อันนี้คือจุดที่ผมคิดว่าน่าสนใจที่สุด เพราะที่ผ่านมาองค์กรส่วนใหญ่มีข้อมูลครบทุกอย่าง แต่ไม่มีทางเชื่อมโยงมันเข้าหากันแบบมีความหมาย คุณมี metric บอกว่า CPU พุ่ง มี log บอกว่า error เกิดตอนไหน มี trace บอกว่า request ไหนช้า แต่ไม่มีอะไรบอกได้ว่า "ทั้งสามอย่างนี้คืออาการของปัญหาเดียวกัน"
พอรวมเป็นกราฟเดียวได้แล้ว สิ่งที่เปิดตามมาคือความสามารถในการให้ AI agent เข้าไปไล่หาสาเหตุได้เอง นี่คือส่วนที่เขาเรียกว่า agentic workflows โดยใช้ Claude ร่วมกับ graph database ตัว AI จะไม่ใช่แค่ chatbot มาตอบคำถาม แต่จะเข้าไปคิวรีกราฟ ไล่ความสัมพันธ์ระหว่างเหตุและผล แล้วสรุปออกมาว่า root cause น่าจะอยู่ตรงไหน
ผลลัพธ์ที่เขาอ้างถึงมีสามอย่างหลักๆ ที่ระบบนี้เปิดทางให้:
Automated triaging
ระบบจัดหมวดหมู่และจัดลำดับความสำคัญของปัญหาที่เกิดขึ้นได้เอง แทนที่จะให้คนมานั่งแยกว่า alert ไหนควรดูก่อน
Root-cause analysis
วิเคราะห์หาสาเหตุรากของปัญหา โดยไล่จากความสัมพันธ์ใน knowledge graph ไม่ใช่ดูแค่ symptom ที่โผล่ขึ้นมา
Self-healing systems
ระบบที่แก้ปัญหาตัวเองได้ในบางกรณี ลดเวลาที่คนต้องเข้าไปยุ่ง
ตรงนี้แหละที่ผมว่ามันเป็นก้าวที่ต่างจากเดิมจริงๆ ไม่ใช่แค่ "เอา AI มาแปะบนระบบเดิม" แต่เป็นการรื้อวิธีคิดว่าข้อมูล observability ควรถูกจัดโครงสร้างยังไงตั้งแต่ต้น ถ้าข้อมูลยังกองรวมกันแบบไม่มีโครงสร้าง AI ก็ไม่มีทางไล่หาความสัมพันธ์ได้
แต่ก็ต้องพูดตรงๆ ว่าเรื่องแบบนี้มันไม่ง่าย เน็ตฟลิกซ์มีทั้งทีมวิศวกรระดับท็อปและงบประมาณที่บริษัททั่วไปไม่มี การสร้าง operational ontology ไม่ใช่แค่ติดตั้งเครื่องมือ แต่ต้องมีการออกแบบโมเดลความรู้ที่ตรงกับระบบของคุณจริงๆ ซึ่งใช้เวลานานและต้องมีคนที่เข้าใจทั้งระบบและเข้าใจ AI พร้อมกัน
สิ่งที่เน็ตฟลิกซ์ทำอยู่นี้ไม่ใช่แค่ปรับปรุงเครื่องมือ แต่เป็นการนิยามใหม่ว่า observability ควรทำงานยังไงในยุคที่ข้อมูลเยอะจนคนอ่านไม่ไหว — และถ้าทิศทางนี้ถูก มันจะกลายเป็นมาตรฐานใหม่ที่บริษัทอื่นต้องตามให้ทัน ไม่ใช่แค่ทางเลือก nice-to-have
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...