AI ในงาน DevOps: อ่าน Log และหาต้นเหตุปัญหา

ตีสองคืนวันศุกร์ ระบบแจ้งเตือนว่าเว็บตอบช้าและมี error 502 เป็นระยะ คุณเปิด log ขึ้นมาเจอหลายหมื่นบรรทัดจาก nginx, PHP-FPM และแอปพลิเคชัน สถานการณ์แบบนี้คือจุดที่ AI ช่วยได้มาก มันอ่าน log ปริมาณมากได้เร็ว จับ pattern ที่ซ้ำ และเสนอสมมติฐานได้หลายแบบ แต่ถ้าใช้ไม่ระวัง เราอาจส่งข้อมูลลูกค้าออกไปนอกองค์กร หรือทำตามคำแนะนำที่แก้ผิดจุดบน production บทความนี้จะพาดูวิธีใช้ AI อ่าน log อย่างเป็นระบบ ตั้งแต่ตัด log ให้พอดี ลบข้อมูลส่วนตัว ไล่ timeline ไปจนถึงขอบเขตที่ AI ไม่ควรแตะ

ตัด log ให้พอดี ไม่ใช่ส่งทั้งไฟล์

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

หลักการตัด log

• ตัดตามเวลา เอาช่วงก่อนเกิดปัญหาเล็กน้อยจนถึงหลังเกิดปัญหา เช่น ก่อน 10 นาที ถึงหลัง 5 นาที
• กรองระดับ เอา error และ warning ก่อน แล้วค่อยเพิ่มบรรทัดปกติรอบ ๆ ถ้าจำเป็น
• สรุปแทนการส่งดิบ สำหรับ access log ที่มีปริมาณมาก ให้นับจำนวนตาม status code หรือ URL แทนการส่งทุกบรรทัด
• รวมจากหลายแหล่ง nginx, PHP-FPM และ log ของแอป ในช่วงเวลาเดียวกัน เพราะสาเหตุมักอยู่ข้ามระบบ

# access log: นับ status code ทีละนาที ช่วง 02:00-02:15 (รูปแบบ combined)
grep -E '10/Oct/2026:02:(0[0-9]|1[0-5]):' /var/log/nginx/access.log \
  | awk '{ split($4, t, ":"); print t[2]":"t[3], $9 }' \
  | sort | uniq -c

# 20 URL ที่ได้ 5xx มากที่สุดในช่วงเดียวกัน
grep '10/Oct/2026:02:' /var/log/nginx/access.log \
  | awk '$9 ~ /^5/ { split($7, u, "?"); print u[1] }' \
  | sort | uniq -c | sort -rn | head -20

# error log ของ nginx และ PHP-FPM ช่วงเวลาเดียวกัน
grep '2026/10/10 02:' /var/log/nginx/error.log | tail -200
grep '10-Oct-2026 02:' /var/log/php-fpm.log | tail -200

สังเกตว่าคำสั่งที่สองตัด query string ออกจาก URL ด้วย ซึ่งช่วยทั้งรวมกลุ่ม URL ที่เหมือนกัน และลดโอกาสที่ token หรือข้อมูลผู้ใช้ใน query string หลุดออกไป ตำแหน่งคอลัมน์ใน awk อ้างอิงรูปแบบ combined ที่เป็นค่าเริ่มต้นของ nginx ถ้าเซิร์ฟเวอร์ของคุณตั้ง log_format เอง ต้องปรับตามจริง

ลบข้อมูลส่วนตัวก่อนส่ง

log มักเต็มไปด้วยข้อมูลที่ไม่ควรออกนอกองค์กร เช่น IP address ของผู้ใช้ อีเมลใน URL หรือข้อความ error, session ID, token ใน query string และบางครั้งมีข้อมูลที่ผู้ใช้กรอกฟอร์มติดมาใน log ของแอป สิ่งเหล่านี้อาจเป็นข้อมูลส่วนบุคคลตาม PDPA ก่อนส่ง log ให้ AI ภายนอก ให้ผ่านขั้นตอน redact เสมอ

#!/usr/bin/env bash
# redact-log.sh : ปิดบังข้อมูลที่พบบ่อยใน log ก่อนส่งออก
# ใช้: ./redact-log.sh input.log > safe.log
set -euo pipefail

perl -pe '
  s/\b\d{1,3}(?:\.\d{1,3}){3}\b/[IP]/g;
  s/[\w.%+-]+@[\w.-]+\.[A-Za-z]{2,}/[EMAIL]/g;
  s/((?:token|access_token|api_key|session|PHPSESSID|password)=)[^&" ]+/${1}[REDACTED]/gi;
  s/(Authorization:\s*Bearer\s+)[\w.-]+/${1}[REDACTED]/gi;
' "$1"

ใช้ perl แทน sed เพราะ syntax ของ regex เหมือนกันทั้งบน Linux และ macOS ที่สำคัญกว่าคือ regex ไม่มีทางจับได้ครบทุกกรณี ให้เปิดไฟล์ผลลัพธ์อ่านคร่าว ๆ ทุกครั้งก่อนส่ง และถ้า log มีข้อมูลอ่อนไหวจำนวนมาก พิจารณาใช้โมเดลที่รันภายในองค์กรแทน

ข้อสังเกต: การแทน IP ทั้งหมดด้วย [IP] ทำให้ AI แยกไม่ออกว่า request มาจากเครื่องเดียวกันหรือไม่ ถ้าการวิเคราะห์ต้องการข้อมูลนี้ เช่น สงสัยว่าถูกยิง request จาก IP เดียว ให้นับจำนวน request ต่อ IP ในเครื่องของเราเองก่อน แล้วส่งเฉพาะผลสรุปแบบไม่มี IP จริง

ตัวอย่าง: log nginx และ PHP-FPM จากเหตุการณ์จริง

ตัวอย่างนี้เป็น log สมมติที่จำลองจากเหตุการณ์ที่พบบ่อย หลัง redact แล้ว

# nginx error.log
2026/10/10 02:03:41 [error] 2211#2211: *91822 upstream timed out (110: Connection timed out) while reading response header from upstream, client: [IP], server: example.com, request: "GET /report/export?year=2026 HTTP/1.1", upstream: "fastcgi://unix:/run/php/php-fpm.sock", host: "example.com"
2026/10/10 02:04:02 [error] 2211#2211: *91850 connect() to unix:/run/php/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: [IP], server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php-fpm.sock", host: "example.com"

# php-fpm.log
[10-Oct-2026 02:02:55] WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
[10-Oct-2026 02:03:40] WARNING: [pool www] child 3381, script '/var/www/app/frontend/web/index.php' (request: "GET /index.php?r=report/export") executing too slow (30.112 sec), logging

# สรุป access log (นับต่อ URL, 02:00-02:10)
   412 /report/export
   388 /
    95 /site/login

เมื่อส่งให้ AI ให้ขอเป็น timeline และสมมติฐาน ไม่ใช่ขอ "วิธีแก้" ทันที

บริบท: เว็บ Yii2 บน nginx + PHP-FPM (ยังไม่ได้ตรวจค่า config ของ pool)
อาการ: 502/504 เป็นระยะ ตั้งแต่ประมาณ 02:03
แนบ: log ที่ redact แล้วด้านบน

ขอ:
1. timeline ของเหตุการณ์เรียงตามเวลา อ้างอิงบรรทัด log
2. สมมติฐานสาเหตุ 2-3 แบบ เรียงตามความน่าจะเป็น พร้อมหลักฐานที่สนับสนุนและที่ขัดแย้ง
3. สำหรับแต่ละสมมติฐาน: คำสั่งแบบ read-only ที่ใช้ตรวจสอบเพิ่ม
ห้ามเสนอคำสั่งที่แก้ไข config หรือ restart service ในขั้นนี้

จากตัวอย่างนี้ AI น่าจะเรียง timeline ได้ว่า PHP-FPM เต็มจำนวน worker ก่อน จากนั้นมี request /report/export ที่ทำงานนานกว่า 30 วินาที แล้ว nginx เริ่ม timeout และต่อ socket ไม่ได้ สมมติฐานหลักคือ export รายงานที่ช้าจับ worker ไว้ทั้งหมดจนหน้าอื่นไม่มี worker ว่าง ซึ่งเราต้องยืนยันต่อด้วยข้อมูลจริง เช่น ดู slow log ของ PHP-FPM ดู query ที่ช้าในฐานข้อมูล และดูว่ามีใครหรือ bot เรียก export ถี่ผิดปกติหรือไม่

ไล่ timeline: วิธีคิดที่ใช้ได้ทุกเหตุการณ์

ไม่ว่าจะใช้ AI หรือไม่ การไล่ timeline คือหัวใจของการหาต้นเหตุ เพราะช่วยแยก "สาเหตุ" ออกจาก "อาการ" ในตัวอย่างข้างต้น 502 คืออาการ worker เต็มคืออาการที่ลึกขึ้น ส่วนต้นเหตุอาจเป็น query ที่ไม่มี index หรือ endpoint ที่ไม่มี rate limit

เทคนิคสำคัญคือ ถาม AI เสมอว่า "เหตุการณ์ก่อนหน้านี้มีอะไรที่ควรดูอีก" เช่น deploy, cron job, การเปลี่ยน config หรือ traffic ที่ผิดปกติ เพราะต้นเหตุมักเกิดก่อนที่ error แรกจะปรากฏ และตรวจเวลาของแต่ละ log ว่าใช้ timezone เดียวกัน ไม่อย่างนั้น timeline จะเพี้ยนทั้งหมด

เส้นที่ห้ามข้าม: AI ไม่สั่งแก้ production เอง

ในยุคที่ AI agent รันคำสั่งได้เอง มีความคิดที่น่าดึงดูดว่า "ให้ AI ต่อเข้า server แล้วแก้ไปเลย" อย่าทำ ด้วยเหตุผลเหล่านี้

• AI มั่นใจได้แม้สมมติฐานผิด คำสั่งที่ดูสมเหตุสมผลอาจทำให้เหตุการณ์แย่ลง เช่น restart service ระหว่างที่ migration กำลังรัน
• log และข้อความ error อาจมีข้อความที่ผู้โจมตีใส่มาเพื่อชักนำ AI (prompt injection) เช่นใน User-Agent หรือ URL
• การแก้บน production ต้องมีคนรับผิดชอบ มีบันทึก และย้อนกลับได้

แนวปฏิบัติที่แนะนำ: AI ใช้ได้กับการอ่าน วิเคราะห์ และร่างคำสั่ง ส่วนการรันคำสั่งที่เปลี่ยนแปลงระบบ คนต้องอ่าน เข้าใจ และรันเอง ตามขั้นตอนของทีม เช่น มีคนที่สองตรวจ ถ้าให้ agent ช่วยตรวจระบบ ให้ใช้บัญชีที่มีสิทธิ์อ่านอย่างเดียว และไม่ให้ agent ถือ credential ของ production

หลังเหตุการณ์จบ AI ยังช่วยได้อีกมากในงานที่ปลอดภัย เช่น ร่างรายงาน postmortem จาก timeline และบันทึกการแก้ไข เสนอ alert ใหม่ที่จะเตือนก่อน worker เต็ม หรือร่างเทสต์ที่กันปัญหาเดิมเกิดซ้ำ

สรุป

• ตัด log ตามช่วงเวลาและระดับ และสรุปเป็นตัวเลขก่อนส่ง แทนการส่งทั้งไฟล์
• redact IP อีเมล token และ session ทุกครั้ง แล้วอ่านตรวจผลลัพธ์ก่อนส่ง
• ขอ timeline และสมมติฐานพร้อมหลักฐาน ไม่ใช่ขอวิธีแก้ทันที และรวม log จากหลายแหล่ง
• AI อ่านและเสนอได้ แต่คำสั่งที่เปลี่ยน production ต้องให้คนตรวจและรันเองเสมอ

ลองทำ

นำ log จากเครื่อง staging หรือ dev ของคุณมาหนึ่งช่วงที่เคยมีปัญหา หรือจำลองเองด้วยการเขียน action ที่ sleep() นานแล้วยิง request พร้อมกันหลายตัว รันสคริปต์ redact แล้วอ่านผลว่ามีอะไรหลุดหรือไม่ จากนั้นใช้ prompt ตัวอย่างขอ timeline และสมมติฐาน เทียบกับสิ่งที่คุณรู้ว่าเกิดขึ้นจริง จดว่า AI ถูกตรงไหนและพลาดตรงไหน