AI ไม่ได้มาแทนที่ DevOps แต่ช่วยร่นระยะทางสู่สมมติฐาน
เจาะลึกวิธีที่วิศวกรใช้ AI ช่วยแก้ปัญหาโครงสร้างพื้นฐาน ลดการเปิดแท็บเบราว์เซอร์นับสิบ และเร่งกระบวนการคิดวิเคราะห์โดยไม่ยอมให้ AI ตัดสินใจแทน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- AI ไม่ได้เข้ามาแทนที่งานแก้ไขปัญหาโครงสร้างพื้นฐาน แต่ช่วยร่นระยะทางจากจุดที่เกิดปัญหาไปยังจุดที่ควรตรวจสอบ
- การใช้งานแบ่งออกเป็น 3 ด้านหลัก ได้แก่ การสื่อสารสรุปผล การทวนสอบเหตุผล และการจัดการงานเขียนโค้ด
- วิศวกรยังคงเป็นผู้ตัดสินใจขั้นสุดท้ายและตรวจสอบความถูกต้องด้วยตนเองเสมอ
- ระมัดระวังความเสี่ยงในการส่งข้อมูลความลับหรือ Hostname เข้าไปในระบบ AI
การแก้ปัญหาเมื่อระบบเกิดแจ้งเตือนขึ้นมา พร้อมกับแท็บเบราว์เซอร์ที่เปิดค้างไว้สิบแท็บ และข้อความแจ้งเตือนใน Slack คือการทำงานจริงในสายงานนี้ ไม่ว่าจะเป็นการเปิด Grafana, CloudWatch, ตรวจสอบ Log, รันคำสั่ง kubectl describe บนพอดที่มีปัญหา, เช็กประวัติการเมิร์จใน GitHub ไปจนถึงตรวจสถานะการดีพอยต์ใน Argo CD การถือข้อมูลจากหลายไทม์ไลน์ไว้ในหัวพร้อมกันขณะเปิดสิบแท็บคืองานที่แท้จริง ไม่ใช่การจำไวยากรณ์หรือแฟล็กของคำสั่ง
งานจริงคือการเชื่อมโยงสัญญาณที่กระจัดกระจายให้เร็วพอที่จะสร้างสมมติฐานที่คุ้มค่าแก่การทดสอบ และนี่คือจุดที่ AI เข้ามาเปลี่ยนวิธีการทำงาน โดยไม่ได้มาแย่งงานแก้ปัญหาไป เพราะวิศวกรยังคงต้องทำทุกขั้นตอนด้วยตัวเอง แต่ AI ช่วยร่นระยะห่างระหว่างคำว่า "มีบางอย่างผิดปกติ" กับ "นี่คือน่าจะเป็นจุดที่ควรไปดู" ให้สั้นลง
การนำ AI มาใช้ในงาน DevOps ยุคปัจจุบันเปลี่ยนจากการมองว่าเป็นผู้ช่วยเขียนโค้ดอัตโนมัติ สู่การเป็นเครื่องมือช่วยลดภาระทางปัญญา (Cognitive Load) ในการคัดกรองข้อมูลจำนวนมหาศาลจากระบบคลาวด์ ช่วยให้วิศวกรสามารถโฟกัสไปที่ตรรกะและการตัดสินใจที่มีความเสี่ยงสูงได้ดียิ่งขึ้น
การใช้งาน AI ในปัจจุบันแบ่งออกเป็น 3 ด้านหลัก โดยแต่ละเครื่องมือมีบทบาทแตกต่างกัน สิ่งสำคัญไม่ใช่แค่การเข้าถึง AI แต่คือการรู้ว่าควรใช้ที่ไหน ต้องให้บริบทอะไร และเมื่อไหร่ที่ต้องตรวจสอบความถูกต้องของผลลัพธ์ โดยไม่มีเครื่องมือใดตัดสินใจในระบบโปรดักชันแทนได้ และกฎเหล็กข้อหนึ่งก่อนใช้งานคือการระมัดระวังเรื่องข้อมูลความลับ เช่น Config ที่มี Real Hostnames หรือ Account IDs จะไม่ถูกป้อนเข้าไปเด็ดขาด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในด้านการสื่อสารและการสรุปผล งานสืบสวนทางเทคนิคเสร็จสิ้นแล้ว แต่ความท้าทายคือการอธิบายให้ผู้พัฒนา ผู้จัดการ เวนดอร์ หรือคนในทีมเข้าใจ โดยไม่พ่นตัวเลขดิบๆ ใส่คนที่ไม่ต้องการ หรือลดทอนจนผิดเพี้ยน ตัวอย่างเช่น การตรวจสอบ Log ของ EKS control-plane ที่พบว่า api, audit และ authenticator logs มีการกินพื้นที่ 20–25 GB ต่อคลัสเตอร์ต่อเดือน ซึ่งต้นทุนหลักมาจากค่า Ingestion ไม่ใช่ Storage ทางแก้คือการลดประเภท Log และปรับ Retention จาก 90 วันเหลือ 30 วัน การให้ ChatGPT ช่วยขัดเกลาบทสรุปสำหรับโพสต์ใน Slack ช่วยประหยัดเวลาในการเขียนซ้ำหลายรอบได้เป็นอย่างดี
"I stopped asking AI to make the call and started asking it to find the hole in mine."
วิศวกร DevOps เจ้าของบทความ
การใช้งานรูปแบบที่สองคือการใช้เป็นผู้ช่วยทวนเหตุผล (Second Pair of Eyes) เช่น เมื่อมีอินสแตนซ์ c7i.2xlarge ที่ไม่ได้ใช้งานเต็มที่และต้องการลดขนาดลงเป็น c7i.xlarge คำถามที่ดีไม่ใช่ "ควรลดขนาดไหม" เพราะนั่นคือสิ่งที่มีธงในใจอยู่แล้ว แต่เป็นคำถามที่ว่า "มีอะไรที่มองข้ามไปก่อนจะเปลี่ยนอินสแตนซ์นี้" ซึ่ง AI มักจะช่วยสะกิดให้คิดถึงเรื่อง Network Throughput, EBS bandwidth, ช่วงพีคสั้นๆ ที่ค่าเฉลี่ย 30 วันซ่อนไว้, รูปแบบภาระงาน และเส้นทางย้อนกลับ (Rollback Path)
สำหรับงานที่มีลักษณะเป็นโค้ด เช่น Kubernetes manifests, Bash, Python scripts และ CI/CD config จะใช้งาน Claude ส่วน Claude Code มีประโยชน์อย่างมากเพราะปัญหาใน Kubernetes มักไม่ได้อยู่แค่ไฟล์เดียว แต่มักกระจายอยู่ตาม Helm templates, values.yaml, values-prod.yaml, ConfigMap, Secret, GitHub Actions workflow และ Argo CD ตัวอย่างเช่น ปัญหาพอดรีสตาร์ทซ้ำๆ และขึ้นสถานะ Last State: OOMKilled Exit Code: 137 ซึ่งบ่งบอกว่าเป็นปัญหาเรื่องแรม Claude Code จะช่วยเดินตามรอยไฟล์เหล่านี้แทนการที่วิศวกรต้องเปิดแปดไฟล์เพื่อประกอบร่างข้อมูลด้วยตัวเอง แต่บางครั้งมันก็มีความมั่นใจแต่ให้ข้อมูลที่ผิด เช่น ชี้เป้าไปที่ลิมิตใน values.yaml โดยบอกว่าเป็นค่าที่ใช้จริงในโปรดักชัน ทั้งที่ Argo CD ซิงค์บริการนั้นมาจากอีกรีโพซิตรีหนึ่ง ผลลัพธ์จาก AI จึงเป็นเพียงแนวทางนำทาง ไม่ใช่คำตัดสินเด็ดขาด
ในส่วนของเครื่องมือโครงสร้างพื้นฐาน AWS DevOps Agent สามารถตรวจสอบเหตุการณ์ความผิดปกติตựงอัตโนมัติ เชื่อโยง Telemetry เข้ากับข้อมูลโค้ดและการดีพอยต์ พร้อมสรุปสาเหตุรากเหง้า (Root Cause) และแผนบรรเทาปัญหา ปัญหาเดิมไม่ใช่การหาคราฟต์กราฟ แต่เป็นการดูว่ามีอะไรเปลี่ยนแปลงไปพร้อมๆ กับจุดที่เกิดเพลิงไหม้ เช่น เมื่อ CPU ของ RDS พุ่งสูงขึ้น ปกติจะต้องดึงกราฟ CPUUtilization, DatabaseConnections, FreeableMemory, read/write IOPS, latency, DiskQueueDepth, Performance Insights และอื่นๆ มาดูประกอบกัน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น