AI ได้เปลี่ยนวิธีการสร้างซอฟต์แวร์ของเรา แต่ไม่ได้เปลี่ยนความจริงพื้นฐานเกี่ยวกับเครื่องจักร นั่นคือ พวกมันจมหายไปในสัญญาณรบกวน (noise) เหมือนกับพวกเรา เมื่อวิศวกรเริ่มทดลองใช้ AI ช่วยในการ debug สัญชาตญาณแรกคือการป้อนทุกอย่างให้โมเดล ทั้ง raw logs, traces และ metrics ถูกเทลงไปใน context window ทั้งหมด ผลลัพธ์ที่ได้ไม่ใช่ความเข้าใจที่ลึกซึ้ง แต่คือความล้มเหลว เนื่องจากปริมาณข้อมูลนั้นสูงเกินไป สัญญาณที่สำคัญจึงถูกกลบหายไป Metrics อยู่ในเครื่องมือหนึ่ง Traces อยู่ในอีกเครื่องมือหนึ่ง และโมเดลไม่สามารถนำพวกมันมาเชื่อมโยงกันเป็นเรื่องราวที่สอดคล้องกันได้ ก่อนที่ AI จะช่วยคุณสังเกตการณ์ระบบได้ คุณต้องสังเกตการณ์ระบบด้วยตัวเองก่อน คุณต้องจัดระเบียบข้อมูลให้เรียบร้อยเสียก่อน

ทำไม Raw Logs ถึงทำให้ AI Pipeline ล้มเหลว

ระบบสมัยใหม่สร้างข้อมูล telemetry ในอัตราที่มนุษย์ไม่สามารถอ่านได้ทัน ซึ่งนั่นควรจะทำให้มันเหมาะสำหรับปัญญาประดิษฐ์ แต่มันกลับไม่ใช่ แม้ว่า context window ของ Large Language Model จะขยายใหญ่ขึ้นเรื่อยๆ แต่ก็ยังเป็นท่อที่มีขีดจำกัด หากคุณยัด raw logs จาก production ที่ไม่ผ่านการกรองลงไป คุณจะเสีย token ไปกับสัญญาณ heartbeat ของ cron job และ noise ของการทำ health-check ในขณะที่ปัญหาการหยุดทำงาน (outage) ที่แท้จริงกลับถูกฝังอยู่ลึกกว่านั้น ที่แย่ไปกว่านั้นคือ raw logs ขาดความสัมพันธ์ระหว่างกัน การพุ่งสูงขึ้นของ latency ในเวลา 14:00 น. และข้อผิดพลาดการเชื่อมต่อฐานข้อมูลใน log ที่มี timestamp เดียวกันนั้นมีความเกี่ยวข้องกันอย่างชัดเจน แต่หากไม่มีใครกำหนดโครงสร้างความสัมพันธ์นั้นไว้ล่วงหน้า AI ก็ต้องใช้วิธีการเดา ซึ่งการเดานั้นมีราคาแพง ช้า และมักจะผิดพลาด

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

แกนหลัก 4 ด้านของการตรวจสอบ (Monitoring)

ที่ airCloset ทีมวิศวกรเลิกมองว่า observability เป็นเพียงท่อข้อมูลขนาดใหญ่ (firehose) เพียงอย่างเดียว แต่พวกเขาแบ่งการตรวจสอบออกเป็น 4 แกนหลักที่แตกต่างกัน โดยแต่ละแกนจะมีรูปแบบข้อมูลเฉพาะและตอบคำถามที่เฉพาะเจาะจง

  • Application: Logs และ traces ตอบคำถามว่า "กำลังเกิดอะไรขึ้นในตอนนี้?"
  • Infrastructure: Metrics ตอบคำถามว่า "เรามีทรัพยากรเพียงพอหรือไม่?"
  • CI: Logs และ alerts ตอบคำถามว่า "อะไรเสียและเสียเมื่อไหร่?"
  • LLM: Metrics และข้อมูลที่มีโครงสร้าง (structured records) ตอบคำถามว่า "เราใช้จ่ายไปเท่าไหร่?"

การแยกส่วนนี้มีความสำคัญ เพราะรูปแบบข้อมูลที่เหมาะสมสำหรับกราฟ latency แบบเรียลไทม์นั้น ไม่สามารถนำมาใช้กับการวิเคราะห์ต้นทุนย้อนหลังได้ การบังคับใช้ schema เดียวกันกับทั้ง 4 โดเมนจะสร้าง noise ในลักษณะที่ทำให้ความช่วยเหลือจาก AI ไร้ประโยชน์

CI Observability: ใช้การ Pull แทนการ Push

Continuous integration คือจุดที่โค้ดต้องเผชิญกับความเป็นจริง เมื่อการ build ล้มเหลว นักพัฒนาต้องการทราบสาเหตุอย่างรวดเร็ว วิธีการแบบพื้นๆ คือการให้ CI runner ทำการ push logs ไปยัง observability backend โดยตรงในขณะที่กำลังทำงานอยู่ แม้มันจะดูเหมือนมีประสิทธิภาพ แต่มันกลับอันตราย

ที่ airCloset พวกเขาเปลี่ยนโมเดลนี้ โดยที่ CI runner จะไม่แตะต้อง observability stack เลย หลังจากที่ GitHub Actions workflow ทำงานเสร็จสิ้น พวกเขาจะ pull logs จาก GitHub API และนำเข้า (ingest) ไปยัง Loki แทน

สถาปัตยกรรมแบบ pull นี้ให้ผลลัพธ์ที่จับต้องได้ 3 ประการ:

Decoupling. หาก pipeline การนำเข้าข้อมูลมีปัญหา หรือไม่สามารถเข้าถึง Grafana ได้ ตัวการรันการทดสอบ (test run) ก็จะไม่ได้รับผลกระทบ การ build จะผ่านหรือล้มเหลวด้วยคุณสมบัติของมันเอง ความล้มเหลวของระบบ observability ไม่ควรส่งผลให้การ deployment ต้องหยุดชะงัก

Security. CI workflow ไม่จำเป็นต้องใช้ Grafana API key เลย โค้ดสำหรับทดสอบมักจะมีปัญหาเรื่องการเข้าถึงความลับ (secrets) ที่ไม่ควรเข้าถึง และการลดการเปิดเผยข้อมูลดังกล่าวจะช่วยลดขอบเขตความเสียหาย (blast radius) หากมี dependency ตัวใดตัวหนึ่งถูกเจาะระบบ

Cross-querying. เมื่อ CI