จุดจบของ Observability กำลังใกล้เข้ามา (และฉันก็โอเคกับมัน)

• เป้าหมายหลักของ เครื่องมือ Observability ตลอดหลายทศวรรษที่ผ่านมา คือการทำให้ มนุษย์เข้าใจ Telemetry data ขนาดใหญ่ที่หลากหลายได้
• การมาถึงของ AI และ LLM กำลังเปลี่ยนกระบวนทัศน์เดิมที่เน้น "แดชบอร์ด+การแจ้งเตือน+การสุ่มตัวอย่าง" และทำให้กระบวนการวิเคราะห์ถูกแทนที่ด้วย ระบบอัตโนมัติ
• ในความเป็นจริง AI agent วิเคราะห์สาเหตุของ latency spike ได้ภายใน 80 วินาทีด้วยการเรียกใช้เครื่องมือ 8 ครั้ง ทำงานที่เคยใช้ในเดโมแบบเดิมให้เป็นอัตโนมัติ และแก้ปัญหาได้ด้วยต้นทุนเพียง 60 เซนต์
• แดชบอร์ดสวย ๆ หรือการทำ instrumentation ที่สะดวก ไม่ได้มีคุณค่าเฉพาะตัวอีกต่อไป เพราะ LLM ทำให้การวิเคราะห์กลายเป็นสินค้าโภคภัณฑ์ และ OpenTelemetry ทำให้ instrumentation กลายเป็นมาตรฐานทั่วไป
• อนาคตของ Observability คือ "feedback loop ที่รวดเร็ว" และ เวิร์กโฟลว์ความร่วมมือระหว่าง AI+มนุษย์ ซึ่งจะเป็นกุญแจสู่ความสำเร็จและขับเคลื่อนยุคของซอฟต์แวร์และระบบอัตโนมัติที่มากยิ่งขึ้น

---

ประวัติของเครื่องมือ Observability และการมาถึงของ AI

• ตลอดหลายทศวรรษที่ผ่านมา เป้าหมายหลักของเครื่องมือ Observability คือการ บีบอัด/สรุปข้อมูลมหาศาลที่ต่างชนิดกัน (telemetry) ให้อยู่ในระดับที่มนุษย์เข้าใจได้
• ทุกครั้งที่มี abstraction ใหม่ของซอฟต์แวร์เกิดขึ้น (เช่น Rails, AWS, Kubernetes, OpenTelemetry ฯลฯ)
  ก็จะมีการพัฒนาเครื่องมือต่าง ๆ เช่น monitoring, measurement, dashboard, adaptive alerting, dynamic sampling เพื่อซ่อนความซับซ้อนนั้น และส่งต่อข้อมูลที่ถูกย่อให้เหมาะกับขีดความสามารถในการรับรู้ของมนุษย์

LLM = ตัวประมาณฟังก์ชันอเนกประสงค์ และตอนนี้มันใช้งานได้จริงแล้ว

• ในเชิงคณิตศาสตร์ LLM เป็นเพียง ตัวประมาณฟังก์ชันอเนกประสงค์ (universal function approximator) แต่ในทางปฏิบัติมันมีประโยชน์มากในการแก้ปัญหาด้าน Observability
• ตัวอย่างจากเดโมของ Honeycomb ที่ ให้ AI agent วิเคราะห์ latency spike บน heatmap ด้วยภาษาธรรมชาติ
  • “ช่วยวิเคราะห์สาเหตุของ latency spike ที่เกิดขึ้นทุก 4 ชั่วโมงในบริการ frontend ให้หน่อย”
  • ใช้ LLM แบบ off-the-shelf (Claude Sonnet 4) เชื่อมต่อกับ Model Context Protocol (MCP) ของ Honeycomb
  • ใช้เวลา 80 วินาที เรียกใช้เครื่องมือ 8 ครั้ง และมีค่าใช้จ่ายเพียง 60 เซนต์ในการวิเคราะห์สาเหตุโดยอัตโนมัติ
• มันไปถึงระดับที่ แก้สถานการณ์จริงแบบ zero-shot ได้ โดยไม่ต้องมี prompt เพิ่มเติม การฝึกเฉพาะทาง หรือคู่มือกำกับ
• การทำให้การวิเคราะห์กลายเป็นสินค้าโภคภัณฑ์ (commoditization):
  • เมื่อ LLM ทำให้การวิเคราะห์เป็นอัตโนมัติ จุดแตกต่างของผลิตภัณฑ์ Observability แบบเดิม (กราฟสวย ๆ, instrumentation ที่ทำได้ง่าย ฯลฯ) ก็เริ่มหมดความหมาย
  • OpenTelemetry ทำให้ instrumentation กลายเป็นมาตรฐานทั่วไป และ LLM ทำให้การวิเคราะห์กลายเป็นสินค้าโภคภัณฑ์
  • ต่อจากนี้ “feedback loop ที่รวดเร็ว” จะเข้ามาแทนคุณค่าหลักของเครื่องมือ Observability

บทบาทของมนุษย์ และการเปลี่ยนแปลงในอนาคต

• บทบาทของมนุษย์จะไม่ได้หายไปทั้งหมด
  • เหมือนกับที่การมาถึงของคลาวด์ไม่ได้ทำให้การมีอยู่ของ IT หมดไป AI ก็ไม่ได้เข้ามาแทนที่นักพัฒนา/ผู้ปฏิบัติการทั้งหมด
  • การเพิ่มขึ้นของผลิตภาพจะขยายภูมิทัศน์โดยรวม และทำให้มีซอฟต์แวร์เกิดขึ้นมากกว่าเดิม
• คำถามสำคัญคือ
  ในโลกที่ต้นทุนของการเขียนโค้ด/รีแฟกเตอร์/วิเคราะห์ลดลงอย่างมาก และการวิเคราะห์กลายเป็นสิ่งต้นทุนคงที่
  แก่นแท้ของ Observability จะมุ่งไปทางไหน?

สิ่งที่สำคัญจริง ๆ คือ "feedback ที่รวดเร็ว"

• สิ่งที่สำคัญที่สุดคือการมี "feedback loop ที่รวดเร็วและถี่" ในทุกขั้นตอนของการพัฒนาและการปฏิบัติการ
  • AI จะเหนือกว่ามนุษย์ในเรื่องความเร็วเสมอ
  • LLM สามารถตั้งสมมติฐานได้หลายสิบครั้งอย่างรวดเร็ว ล้มเหลวได้เร็ว และในที่สุดก็หาคำตอบที่ถูกต้องเจอ
    (และต้นทุนก็ต่ำมาก)
• ปรัชญาของ Honeycomb:
  • feedback loop ที่รวดเร็ว, การแบ่งปันความรู้แบบร่วมมือ, การพัฒนา/ปฏิบัติการเชิงทดลอง
  • ต่อจากนี้ AI assistant จะถูกนำมาใช้ตลอดวงจรชีวิตของการพัฒนาและการปฏิบัติการซอฟต์แวร์
    • ตัวอย่าง
      • ระหว่างการเขียนโค้ดและ deploy, AI agent ให้ feedback แบบเรียลไทม์ และเสนอแนะการแก้บั๊ก/ปรับปรุงคุณภาพ
      • ระหว่างการปฏิบัติการ ตรวจจับ/วิเคราะห์ emergent behavior/สร้างรายงานอัตโนมัติ และหลังได้รับอนุมัติก็ปรับปรุงให้เองอัตโนมัติ
      • องค์กรแนวหน้าจะทำให้บทบาท SRE/SWE เป็นอัตโนมัติด้วย AI+เครื่องมือ และไปถึงขั้นบรรลุเป้าหมายทางธุรกิจได้โดยตรง
• เงื่อนไขของอนาคต Observability เพื่อความสำเร็จ
  • ประสิทธิภาพการ query ที่มี latency ต่ำมาก
  • ที่เก็บข้อมูลแบบรวมศูนย์
  • เวิร์กโฟลว์การทำงานร่วมกันที่ลื่นไหลระหว่างมนุษย์กับ AI
• สรุป:
  • เครื่องมือ Observability แบบเดิมที่เน้นแดชบอร์ด การแจ้งเตือน และการแสดงผลข้อมูล
    จะไม่ใช่แกนหลักในยุค AI อีกต่อไป
    และมีเพียง “feedback loop ที่รวดเร็ว” กับ แพลตฟอร์มความร่วมมือระหว่าง AI-มนุษย์ เท่านั้นที่จะอยู่รอด

[redlasha]

เช่นเดียวกับที่ Observability ไม่ใช่จุดจบของ Monitoring, LLM ก็คงไม่ใช่จุดจบของ Observability
เหมือนที่ Observability พัฒนาต่อยอดขึ้นมาบนพื้นฐานของ Monitoring ที่ก้าวหน้า, การวิเคราะห์ด้วย LLM ก็คงจะพัฒนาต่อยอดขึ้นมาบนพื้นฐานของ Observability ที่ก้าวหน้าเช่นกัน

[ethanhur]

ฉันก็คาดหวังเหมือนกันว่าเพราะ LLM วงการ Observability จะถูกพลิกโฉมอย่างรวดเร็ว แต่พาดหัวล่อเป้าเกินไปหน่อย 555

[crawler]

โปรโมตบริการของตัวเองด้วยการบอกว่า "วันสิ้นสุดกำลังใกล้เข้ามา" ก็แอบเขินนิดหน่อยนะ...

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• รู้สึกว่าเรากำลังประเมินคุณค่าของความเป็นกำหนดได้แน่นอนต่ำเกินไปในภาพรวม และในทางกลับกันก็ประเมินต้นทุนที่มากับความไม่เป็นกำหนดต่ำเกินไปด้วย ไม่นานมานี้ผมลองทดสอบผลิตภัณฑ์อีกตัวที่ขายด้วยคำพูดลักษณะคล้ายกัน ซึ่งมันพยายามทำ RCA จากการเชื่อมโยงเหตุการณ์ของผมเข้ากับกราฟ สุดท้ายผลที่ออกมากลายเป็นเหมือนหน้า Spurious Correlations ซึ่งถ้าได้เห็นเองจะชัดและขำมาก
  • ควรเป็นที่รับรู้กันให้มากกว่านี้ว่าข้อมูลอนุกรมเวลาอ่อนแอต่อความสัมพันธ์ลวง (spurious correlations) มากจริง ๆ ค่า r² ก็ไม่มีความหมายด้วย ที่แย่กว่านั้นคือเวลาตีความกราฟด้วยสายตา เพราะถ้าเป็นข้อมูลที่เปลี่ยนไปตามเวลา ก็ควรใช้เกณฑ์วัดที่เหมาะกับลักษณะนั้น
  • ผมอาจเข้าใจประเด็นผิดก็ได้ แต่แม้แต่ในแอปที่อิง LLM ถ้าออกแบบดี ๆ ก็ยังทำ UX แบบกำหนดได้แน่นอนในช่วงเวลาสำคัญมาก ๆ ได้ โดยให้ LLM สร้างสเปกที่กำหนดได้แน่นอนสำหรับสิ่งที่ต้องทำเมื่อจำเป็น แล้วบันทึกงานหรือแอ็กชันนั้นไว้ ให้ผู้ใช้บันทึกสเปกที่สามารถรันซ้ำได้ทุกเมื่อพร้อมกับบทสนทนา และเมื่อสเปกล้มเหลวก็ให้ AI เสนอวิธีแก้ไขได้ ลักษณะการไหลจะคล้ายประสบการณ์ใช้ AI เขียนโค้ด เพียงแต่ต้องจำกัดโดเมนของสเปกให้แคบลงและคิดเรื่องการกู้คืนสเปกที่ล้มเหลวให้มากขึ้น เป็นรูปแบบที่ทำได้โดยไม่ต้องให้ผู้ใช้ไปเรียนภาษาสเปกแยกต่างหาก
• ในฐานะคนที่ทำ RCA เป็นประจำ ผมกังวลว่าเพื่อนร่วมงานที่เดิมทีก็รู้สึกเสียหน้าอยู่แล้ว อาจยิ่งแย่ลงถ้าเชื่อเครื่องมือที่ให้คำตอบผิด 10% แต่พูดด้วยความมั่นใจเต็มที่ ผมห่วงว่าพอมีเครื่องมือแล้ว คนจะพึ่งมันโดยไม่ต้องพูดต่อสาธารณะว่าไม่รู้จริง ๆ ถ้าเครื่องมือสรุปผลแล้วตามด้วยการมองหาข้อมูลที่หักล้างการตีความนั้น และระบุหลักฐานที่น่าเชื่อถือกว่าหรือความไม่แน่นอนให้ชัดขึ้น ก็คงแย่น้อยลง
  • ถ้าเขียน system prompt ดี ๆ ก็ช่วยอุดช่องนี้ได้พอสมควร จริง ๆ แล้วผมเคยทำ custom prompt/คำสั่งที่ดึงคำตอบจาก LLM ให้เข้มงวดและผ่านการคิดค้นมากขึ้นเป็นค่าเริ่มต้นได้ และประสบการณ์ก็ค่อนข้างดี prompt ที่ผมใช้ใน ChatGPT คือ: "ให้ความสำคัญกับสาระ ความชัดเจน และความลึก มองทุกข้อเสนอ การออกแบบ และข้อสรุปเป็นสมมติฐาน แล้วตั้งคำถามอย่างเฉียบคม เปิดเผยสมมติฐานแฝง trade-off และกรณีล้มเหลวตั้งแต่เนิ่น ๆ คำชมที่ไม่จำเป็นให้ละไว้หากไม่มีหลักฐาน ถ้าไม่แน่ใจให้ระบุให้ชัด เสนออีกมุมมองทางเลือกเสมอ การอ้างข้อเท็จจริงให้ฟันธงเฉพาะเมื่อมีแหล่งอ้างอิงหรือหลักฐานมั่นคง หากอาศัยการอนุมานหรือข้อมูลไม่สมบูรณ์ให้แจ้งอย่างชัดเจน ให้ความสำคัญกับความถูกต้องมากกว่าความมั่นใจ" โครงแบบนี้ช่วยยกระดับคุณภาพและความลึกของคำตอบได้มากจริง ๆ
• ประวัติแบบที่ว่า “New Relic มากับการปฏิวัติ Rails, Datadog มากับการเติบโตของ AWS, และ Honeycomb เป็นผู้นำ OpenTelemetry” เป็นการตีความที่มีอคติ OpenTelemetry (OTel) เกิดขึ้นจากการที่ OpenCensus ซึ่ง Google เริ่ม และ OpenTracing ซึ่ง LightStep เริ่ม รวมกันอย่างเป็นทางการ องค์กรหลากหลายอย่าง Google, LightStep, Microsoft, Uber ฯลฯ เข้าร่วมใน governance ระยะแรก จริงอยู่ว่า Honeycomb มีบทบาทมากทั้งด้านโค้ด ชุมชน และการผลักดันการใช้งานเทคโนโลยี แต่จะบอกว่า “เป็นผู้นำ” ก็เกินจริง
  • ผมกำลังอ่านในฐานะคนที่เพิ่งนำ Honeycomb มาใช้เมื่อไม่นานนี้ และมันเป็นเครื่องมือที่น่าทึ่งมาก โดยเฉพาะการได้ insight ภายในไม่กี่ชั่วโมงด้วย otel auto-instrumentation ส่วนความสามารถด้าน dashboard/query ก็สัมผัสได้ว่ามาจากปรัชญา Observability ที่ลึกจริง ๆ ทั้งทีมของเราตกใจกับความสมบูรณ์ของเครื่องมือนี้ Datadog ให้ความรู้สึกเหมือนเน้นการตลาดกับเช็กลิสต์คำว่า 'observability' มากกว่า
• ถ้าวาง “คำขาย” ไว้ข้าง ๆ นี่เป็นหนึ่งในแอปพลิเคชันที่ LLM มีคุณค่าจริง ๆ ตลอดมางาน monitoring และ observability เป็นพื้นที่ของ SRE ในองค์กรใหญ่ และสำหรับองค์กรเล็กกำแพงมันสูงมาก (ในมุม IT) การเลือก metric ที่มีความหมาย ตั้งค่า heartbeat กับ baseline เอง ต้องใช้ทั้งเวลา เครื่องมือเฉพาะ สภาพแวดล้อมการพัฒนาขนาดใหญ่ และระบบตรวจสอบการเปลี่ยนแปลงมากมาย จนทีม IT ทั่วไปไม่ค่อยกล้าแตะ ตอนนี้ด้วย LLM ที่ฝึกกับเครื่องมือกระแสหลักมากที่สุด แม้ทีม IT ที่งบหรือศักยภาพจำกัดก็สร้างระบบ observability แบบ “จริงจัง” บน open framework/tool ได้แล้ว ไม่ต้องพึ่งโซลูชัน subscription หรูหราอีกต่อไป ตอนต้องสร้าง dashboard หรือตั้งค่า monitoring ที่ใช้ได้จริง LLM นี่เหมือนพรสำหรับคนทำงานเลย สำหรับฝ่าย IT ที่พออ่านคู่มือและแก้ปัญหาได้ แต่ไม่มีเวลาขุดลึกผลิตภัณฑ์นับไม่ถ้วนที่ CIO ผลักเข้ามา ประโยชน์ใช้งานแทบสุดทาง ถ้าแปะคำแนะนำสาเหตุขั้นต่ำไปกับการแจ้งเตือน PagerDuty ได้ สำหรับ SMB/SME นี่คือการปฏิวัติ observability
  • การหา metric ที่มีความหมายเป็นเรื่องที่ LLM ทำไม่ได้ แต่ส่วนที่เหลืออย่าง heartbeat หรือ baseline นั้นเป็นพื้นที่ที่ทำให้อัตโนมัติได้ด้วย ConvNet (โครงข่ายประสาทเทียมแบบคอนโวลูชัน) มานานแล้ว ส่วนเรื่องตรวจสอบการเปลี่ยนแปลงหรือการควบคุมเสถียรภาพซึ่งเป็นความกังวลด้านการ deploy นั้นอยู่นอกขอบเขตของเครื่องมือ observability
  • ผมคาดหวังผลกระทบมหาศาลแม้กับทีม SRE ขนาดเล็ก ทีมเรามี 2 คนดูแล bare-metal server หลายร้อยเครื่อง และเวลาเกิดเหตุขัดข้อง กระบวนการไล่แคบหาสาเหตุนั้นเครียดมาก ถึงขั้นเคยคิดจะสร้างเครื่องมือแบบ MCP (Master Control Program) ขึ้นมาใช้เอง หลายครั้งก็เป็นปัญหาที่แฝงตัวอยู่นานมากแล้วค่อยปะทุเป็น error ซึ่งกรณีแบบนี้ LLM น่าจะช่วยได้มาก
• หัวข้อดูหวือหวาเกินไป เครื่องมือ observability เดิมไม่ได้จะไร้ค่า เพียงแต่อาจใช้เวลาสร้างกราฟและนั่งเฝ้าดูน้อยลง คล้ายผลกระทบที่ LLM มีต่อทุกวงการ คือช่วยให้ทำงานที่ทำเป็นอยู่แล้วได้เร็วขึ้น หรือช่วยเรียนรู้วิธีทำงานนั้น แต่ไม่ได้แทนที่เทคนิคเฉพาะอย่างอย่างสมบูรณ์
  • ข้อสรุปว่า “เพิ่มความเร็วให้งานที่ทำเป็นอยู่แล้ว” และ “ช่วยให้เรียนรู้งานใหม่” วันนี้ผมเพิ่งได้ยินเป็นครั้งที่สอง การอนุมานเป็นข้อ 2 และการเพิ่มประสิทธิภาพข้อ 1 แบบสุดขั้วนี่แหละคือทิศทางที่มีผลิตภาพที่สุดต่อจากนี้
  • หัวข้ออาจหวือหวา แต่สารชัดเจน — คูเมืองป้องกันการแข่งขัน (moat) กำลังต่ำลงเรื่อย ๆ
  • ผมเรียกปรากฏการณ์นี้ว่า “Charity Majors effect”
• ในเดโมมีคำพูดว่า “นี่ไม่ใช่ตัวอย่างที่สร้างขึ้น เราเอาคำถามเดียวกับที่ถามผู้ใช้ในเดโมไปถาม LLM agent และมันก็หาคำตอบที่ถูกต้องได้ทันทีโดยไม่ต้องมี prompt การฝึก หรือคำแนะนำเพิ่ม” แต่ในความเป็นจริง สถานการณ์นี้ถูกรวมอยู่ในเดโมอยู่แล้ว และยังเป็นกรณีที่มีโซลูชันอยู่ก่อนแล้วด้วย ผมกลับคิดว่าควรใช้ตัวอย่างที่สร้างขึ้นมา เพื่อแสดงให้เห็นว่าโมเดลสามารถทำ generalization กับสถานการณ์ใหม่ที่ไม่ได้อยู่ตรง ๆ ในข้อมูลฝึกได้หรือไม่ ความสามารถจริงของ LLM นั้นมีประโยชน์ก็จริง แต่ถ้าจะประกาศแรงระดับ “จุดจบของ observability” เครื่องมือนั้นต้องแสดงความสามารถในการ generalize ให้เห็น
• ผมไม่คิดว่านี่คือ “จุดจบของ observability” แต่ประเด็นที่บทความยกมาก็ไม่ได้เหลวไหลไปเสียหมด แน่นอนว่ามีความเป็นไปได้สูงที่จะเกิดชั้นของ AI agent แบบใหม่ที่รับบทบาทหลากหลายในงาน SRE (รวมถึง RCA) ได้ อย่างไรก็ตาม ต่อให้สิ่งนั้นเป็นจริง observability stack เดิมส่วนใหญ่ (หรืออาจทั้งหมด) ก็ยังจำเป็นอยู่ และตราบใดที่ปัญหาเรื่องการเพ้อมั่ว/ความน่าเชื่อถือ/ความเสถียรของ LLM ยังไม่ถูกแก้ที่ต้นตอ การทำความเข้าใจปัญหาเชิงลึกก็ยังต้องใช้มนุษย์อยู่ดี
• กลยุทธ์ธุรกิจแบบ “ใช้ AI เติมแรงอีกนิดก็ทำงานของผู้เชี่ยวชาญได้ทั้งหมด” เป็นกลยุทธ์ที่น่าดึงดูดมาก น่าเศร้าแต่ถ้าเอาคำพูดนี้ไปแปะกับสตาร์ตอัป AI 80% ทุกวันนี้ก็ไม่แปลกเลย
  • รู้แหละว่านี่ฟังดูเหมือนประชด แต่ผู้เชี่ยวชาญที่ “พอทำงานได้จริง” นั้นเป็นทรัพยากรที่แพง<i>มาก</i> ถ้าระบบอัตโนมัติแบบนี้เกิดขึ้นได้จริง ก็ยิ่งเข้าใจได้ว่าทำไมถึงมีสตาร์ตอัป AI แบบครึ่ง ๆ กลาง ๆ ผุดขึ้นมาเต็มไปหมด
• บทความนี้ให้ความรู้สึกเหมือน AI เขียนทั้งหมด “AI จะยุติพาราไดม์นี้ มันเกิดขึ้นแล้ว และจะเปลี่ยนทั้งการออกแบบระบบกับวิธีปฏิบัติการอย่างรากฐาน” — แค่ตีความข้อมูลบางส่วนได้ ทำไมถึงเรียกว่า “จุดจบของ observability” ได้ยังไง
• ตรรกะที่ว่า “ต่อไปไม่ต้องดูข้อมูลผ่านกราฟและ UI แล้ว” มีข้อจำกัดในโลกจริง LLM ตอนที่ไปได้สวยนั้นดีมาก แต่ตอนพลาด มนุษย์ก็ยังต้องเข้ามาดูกราฟและภาพแสดงผลเอง กราฟหรือ visualization ก็ยากอยู่แล้ว แต่ความยากที่หนักกว่านั้นอยู่ในงานเก็บข้อมูลจริง หรือการออกแบบ query ที่ซับซ้อนและรูปแบบการจัดเก็บข้อมูล observability จะ “หายไป” ก็ต่อเมื่อมีปัญญาประดิษฐ์แท้จริงที่ตัดสินทุกอย่างได้แทบสมบูรณ์เท่านั้น ซึ่งสุดท้ายตอนนั้นทั้งโครงสร้างสังคมก็จะเปลี่ยนไปหมด เป็นการเปลี่ยนผ่านทางวัฒนธรรมครั้งใหญ่ (ไม่ถึงกับล่มสลาย แต่ก็คงเจ็บปวด) AI กำลังเปลี่ยนภูมิทัศน์ของ observability จริง และมันกำลังเกิดขึ้นแล้ว แต่ยังไปไม่สุด