Load Test ผ่านแล้ว แต่ทำไมระบบยังล่มได้?
ว่าด้วย Performance Engineering ยุคใหม่ — เมื่อคำถามไม่ใช่แค่ “รับได้กี่คน” อีกต่อไป
Retry Storm · Availability Test · SLO · AI-Driven Test Planning
ลองนึกถึงวันที่คุณสอบใบขับขี่ สนามสอบมีกรวยวางเป็นระเบียบ ไม่มีรถคันอื่น ไม่มีฝน ไม่มีมอเตอร์ไซค์ปาดหน้า คุณขับตามเส้นทางที่ซ้อมมา แล้วก็สอบผ่าน
แต่เย็นวันศุกร์สิ้นเดือน ฝนตก รถติดยาวทั้งถนน นั่นเป็นอีกเรื่องหนึ่งเลย
Load Test แบบที่เราคุ้นเคยก็คล้ายสนามสอบนั้น เราเขียนสคริปต์ กำหนดจำนวนผู้ใช้จำลอง กดรัน แล้วดูว่าผ่านเกณฑ์ไหม ทั้งหมดนี้ยังจำเป็นอยู่ แต่ระบบสมัยนี้ซับซ้อนกว่าเดิมมาก และหลายครั้งมันล่มทั้งที่ผลทดสอบบอกว่า “ผ่าน”
บทความนี้จะชวนดูว่า Performance Engineering กำลังขยับไปทางไหน และทีมของคุณควรเตรียมตัวอย่างไร
01ทำไมสคริปต์อย่างเดียวถึงไม่พอ?
หลายปีที่ผ่านมา งาน Performance Test หมุนอยู่รอบ “Script” ใครเขียน Script เก่ง ทำ Correlation คล่อง ก็ถือว่าเป็นมือหนึ่งของทีม
แต่ Script คือ “สิ่งที่เราคิดว่าผู้ใช้จะทำ” ไม่ใช่สิ่งที่ผู้ใช้ทำจริง เราเดาว่าคนจะ Login ค้นหาสินค้า แล้วจ่ายเงิน ทั้งที่ของจริงมีคนกดย้อนกลับ เปิดค้างไว้สิบแท็บ หรือกดรีเฟรชรัว ๆ ตอนหน้าเว็บช้า
วันนี้เราไม่ต้องเดาแล้ว ระบบส่วนใหญ่เก็บร่องรอยการใช้งานจริงไว้ครบ ทั้ง Log จาก API Gateway ทั้ง Distributed Tracing ทั้งข้อมูลจากเครื่องมือ APM และ OpenTelemetry เราจึงรู้ได้ว่าผู้ใช้เดินทำอะไรบ่อยที่สุด ช่วงพีคหน้าตาเป็นอย่างไร และ API ตัวไหนถูกเรียกต่อกันเป็นทอด ๆ
พอมีข้อมูลแบบนี้ คุณภาพของการทดสอบก็ไม่ได้ขึ้นกับฝีมือการทำ Script อีกต่อไป แต่ขึ้นกับว่าเราอ่านข้อมูลจริงได้แม่นแค่ไหน
“เราไม่ได้จำลอง ‘ผู้ใช้’ อีกแล้ว เราจำลอง ‘พฤติกรรม’ แม้จะฟังดูคล้ายกัน แต่ผลลัพธ์ต่างกันมาก”
02ระบบล่มเพราะคนเยอะ จริงหรือ?
คำถามคลาสสิกของ Load Test คือ “ระบบรับได้กี่คนพร้อมกัน” เป็นคำถามที่ดี แต่ไม่ใช่คำถามเดียวที่ต้องถาม
ลองนึกถึงรถติดบนทางด่วน บางวันรถเยอะมากแต่ยังไหลได้ บางวันรถไม่ได้เยอะกว่าปกติเลย แต่ดันมีรถคันเดียวเสียกลางสะพาน ทุกคันพยายามเบียดเพื่อเปลี่ยนเลน แล้วถนนทั้งสายก็หยุดนิ่ง
ปัญหาแบบนี้ไม่มีทางเจอจากการเพิ่มจำนวนผู้ใช้จำลองเฉย ๆ เราต้องตั้งใจสร้างสถานการณ์ขึ้นมา เช่น ทำให้ Service ปลายทางช้าลง ปล่อยให้ Cache ว่างเปล่า หรือดูว่า Auto Scaling ขยายตัวทันทราฟฟิกที่พุ่งขึ้นไหม
Performance Engineering จึงซ้อนทับกับ Resilience Engineering มากขึ้นเรื่อย ๆ คำถามขยับจาก “เร็วแค่ไหน” ไปเป็น “ตอนที่บางอย่างพัง ระบบจะประคองตัวอย่างไร” เรื่องอย่าง Circuit Breaker, Rate Limiting และ Graceful Degradation จึงเป็นสิ่งที่คนทำ Performance Test ต้องเข้าใจด้วย
03ตัวเลขที่ “ผ่าน” คือตัวเลขที่ลูกค้ารู้สึกหรือเปล่า?
เกณฑ์ที่เราคุ้นกันคือ SLA เช่น “95% ของคำขอต้องตอบภายใน 2 วินาที” มันชัดเจน วัดได้ และเขียนลงสัญญาได้ แต่มันไม่ได้บอกว่าลูกค้าเริ่มหงุดหงิดตอนไหน
เหมือนร้านอาหารที่สัญญาว่าอาหารจะออกภายใน 30 นาที ร้านทำได้ตามสัญญาทุกโต๊ะ แต่ลูกค้าเริ่มมองนาฬิกาตั้งแต่นาทีที่ 15 แล้ว
SLO หรือ Service Level Objective คือเป้าหมายที่ผูกกับประสบการณ์จริงของผู้ใช้และผลทางธุรกิจ สมมติข้อมูลของคุณชี้ว่า ถ้าหน้าค้นหาช้าเกินครึ่งวินาที คนจะเลิกค้นแล้วออกจากแอป เป้าหมายของการทดสอบก็ควรเป็นตัวเลขนั้น ไม่ใช่ 2 วินาทีที่เขียนไว้กว้าง ๆ ในเอกสาร
SLA ไม่ได้หายไปไหน มันยังเป็นข้อตกลงกับลูกค้าเหมือนเดิม แต่ตัวเลขที่ทีมใช้ตัดสินว่า “ผ่านหรือไม่ผ่าน” กำลังขยับมาเป็น SLO แนวคิดนี้แพร่หลายมาจากแนวปฏิบัติ SRE ของ Google พร้อมกับเรื่อง Error Budget
04แผนทดสอบต้องตายตัวเสมอไปไหม?
แผนทดสอบแบบดั้งเดิมเหมือนแผนที่กระดาษ เรากำหนดเส้นทางไว้ล่วงหน้า ทั้ง Ramp-up ระยะเวลา และสัดส่วนของแต่ละ Transaction แล้วเดินตามนั้นไม่ว่าระหว่างทางจะเกิดอะไรขึ้น
การนำ AI เข้ามาช่วยทำให้เราได้แนวทางใหม่ที่คล้ายแอปนำทาง หรือ “GPS” มากกว่า มันจะดูสภาพจราจรตอนนั้นแล้วเปลี่ยนเส้นทางให้ ถ้าระหว่างการรันพบว่า Error Rate ของ API ตัวหนึ่งเริ่มผิดปกติ การทดสอบอาจชะลอการเพิ่มโหลด เจาะจุดนั้นให้ลึกขึ้น หรือรันซ้ำเฉพาะ Scenario ที่น่าสงสัย โดยใช้สัญญาณจาก Observability และ CI/CD เป็นตัวตัดสิน
ต้องบอกกันตรง ๆ ว่าเรื่องนี้ยังอยู่ในช่วงเริ่มต้น ทีมส่วนใหญ่ยังไปไม่ถึงจุดที่ AI ปรับแผนทดสอบเองทั้งหมด แต่ชิ้นส่วนเล็ก ๆ ทำได้แล้ววันนี้ เช่น ตั้ง Threshold ให้การทดสอบหยุดเองเมื่อเกินเกณฑ์ หรือให้ Pipeline เลือกรันชุดทดสอบตามส่วนที่โค้ดเปลี่ยน
05แล้วคนทำ Performance Test จะตกงานไหม?
ไม่ตกงาน แต่งานจะเปลี่ยนรูปแบบไป
งานส่วนที่เป็นสิ่งที่เราทำซ้ำๆ เช่น อัด Script แก้ Correlation ไล่ซ่อมสคริปต์ที่พังเพราะหน้าจอเปลี่ยน คือส่วนที่ AI ช่วยได้มากขึ้นทุกวัน ส่วนที่ยังต้องใช้คนคือการตัดสินใจว่าจะทดสอบอะไร ทดสอบไปทำไม และผลที่ได้แปลว่าอะไร
เทียบได้กับช่างภาพในยุคที่กล้องโฟกัสและวัดแสงให้เองได้ ช่างภาพไม่ได้หายไป แต่คุณค่าย้ายจาก “ปรับกล้องเป็น” ไปอยู่ที่ “มองเห็นว่าควรถ่ายอะไร”
ทักษะที่จะมีค่ามากขึ้นมีอยู่สามเรื่อง
- การอ่านข้อมูล — เปิดกราฟจากเครื่องมือ Observability แล้วบอกได้ว่าคอขวดอยู่ตรงไหน และนำข้อมูลการใช้งานจริงมาออกแบบ Workload ได้แทนการเดา
- ความเข้าใจระบบ — รู้ว่าเมื่อจุดหนึ่งช้า ผลกระทบจะลามไปทางไหน และกลไกป้องกันแต่ละตัวทำงานอย่างไร
- การเชื่อมกับธุรกิจ — คิดเป็น SLO อธิบายผลทดสอบเป็นภาษาที่ผู้บริหารเข้าใจ และมองต้นทุนคู่กับความเร็วเสมอ เพราะบน Cloud ทุกอย่างที่เร็วขึ้นมีราคา
พูดง่าย ๆ คือ Performance Engineer ยุคใหม่เป็นลูกครึ่ง ครึ่งหนึ่งเป็นนักทดสอบ อีกครึ่งเป็น SRE
“เครื่องมือเขียนสคริปต์แทนเราได้ แต่ยังบอกแทนเราไม่ได้ว่าระบบพังเพราะอะไร”
06เริ่มต้นยากไหม?
ไม่ต้องรื้อทุกอย่างที่มีอยู่ เครื่องมือที่ใช้รันโหลดทุกวันนี้ ไม่ว่าจะเป็น k6, JMeter, NeoLoad หรือ LoadRunner ยังใช้ได้เหมือนเดิม สิ่งที่เปลี่ยนคือสิ่งที่อยู่รอบ ๆ มัน ได้แก่ข้อมูลที่ป้อนเข้าไป และวิธีอ่านผลที่ออกมา
ขอแนะนำให้เริ่มจากสามก้าวเล็ก ๆ
- ก้าวแรก — เลือก User Journey ที่สำคัญที่สุดมาหนึ่งเส้น แล้วเทียบสัดส่วน Transaction ในสคริปต์กับข้อมูลจริงจาก Production ว่าตรงกันแค่ไหน หลายทีมจะแปลกใจกับคำตอบ
- ก้าวที่สอง — เพิ่ม Scenario “วันที่ไม่ปกติ” เข้าไปหนึ่งอัน เช่น Service ปลายทางตอบช้าลงสามเท่า หรือปิด Instance ไปหนึ่งตัวระหว่างรัน แล้วดูว่าระบบของเราประคองตัวได้ หรือพังตามกันไป
- ก้าวที่สาม — ตั้ง SLO หนึ่งข้อที่ผูกกับธุรกิจจริง ๆ แล้วใช้เป็นเกณฑ์ผ่านของการทดสอบรอบถัดไป
07ทิ้งท้าย
Load Test แบบเดิมตอบคำถามว่า “ระบบรับได้กี่คน” ซึ่งยังเป็นคำถามที่ต้องตอบให้ได้ แต่ระบบที่ซับซ้อนขึ้นทุกปีต้องการคำตอบที่ลึกกว่านั้น คือ“วันที่ทุกอย่างไม่เป็นไปตามแผน ระบบจะเป็นอย่างไร และลูกค้าจะรู้สึกอย่างไร”
อ่านเพิ่มเติม
Reference
- เรียบเรียงและต่อยอดจากแนวคิดในบทความ “The Performance Testing Shift No One Is Prepared For — Except the Top 1% Teams” โดย Kumar Ankit
