ในตัวอย่างจาก ตอนที่ 1 บริการ EasyTravelService รายการ storeBooking อยู่ดีๆ ก็ใช้เวลาในการตอบสนองน้อยลงมาก จริงๆ แล้วเกิดจากระบบทำงานไม่ได้เลย
(มี Failure Rate หรือค่าความผิดพลาดถึง 100%) แบบนี้เราถึงบางอ้อได้เลยว่า ระบบทำงานได้รวดเร็วปานสายฟ้า แต่คนใช้งานไม่น่าจะมีความสุข 🤣
นี่จึงเป็นที่มาที่เน้นความสำคัญของ Signal ลำดับต่อไป
Figure 10: Error
2nd Signal: ความผิดพลาด (Error) ⛔
ถ้าเรามองในมุมผู้ใช้บริการออนไลน์ ถึงแม้ว่าบริการนั้นอาจจะตอบสนองช้า แต่ถ้ายังให้บริการได้ เราอาจจะยังพอทนใช้งานต่อไปได้บ้าง โดยคาดหวังว่าบริการนั้นๆ จะทำงานได้ตามที่ควรจะเป็นโดยไม่มีข้อผิดพลาด เพราะฉะนั้นในมุมผู้ใช้งานแล้ว ข้อผิดพลาดต่างๆ ไม่ควรจะเกิดขึ้นเลย แต่ในความเป็นจริง ในฐานะผู้ให้บริการ แม้จะมีความรู้ความเชี่ยวชาญเป็นอย่างดี ก็ยังหลีกเลี่ยงปัญหาเหล่านี้ได้ยาก
Figure 11: Example of errors
ควรวัดค่าเป็นตัวเลข หรือเป็น %?
ในขณะที่เครื่องมือวัดผลยุคเก่าจะพยายามนับจำนวนครั้งที่เกิด Error เช่น HTTP 5xx count แต่ในเครื่องมือวัดผลที่ทันสมัย จะพยายามวัดเป็น % Error rate หรือ % Failure rate สาเหตุเนื่องจาก Error count ไม่ได้บ่งบอกว่าปัญหานี้กระทบผู้ใช้ส่วนน้อยหรือส่วนใหญ่ การมี Error 500 ครั้งจากการใช้งาน 1 ล้านครั้ง (Failure rate=0.05%) ดูมีผลกระทบน้อยกว่า Error 50 ครั้ง จากการใช้งาน 100 ครั้ง (Failure rate=50%)
Figure 12: Error Count vs. Error rate %
แต่หลายๆ หน่วยงาน อาจจะวัดผลในทางกลับด้าน กล่าวคือ วัด Success Rate ของการทำรายการ เพื่อใช้วัดค่า Service Level Agreement ซึ่ง Success Rate ก็คือส่วนกลับของ Error Rate เมื่อเอาไปลบออกจาก 100% นั่นเอง ถ้า Error rate = 5% เราจะได้ Success Rate=95%
Figure 13: Success Rate of Transfer
ถ้าวัดผลแล้ว พบว่า Error rate สูงล่ะ?
เครื่องมือ Observability ที่ดี เวลาเห็น Error Rate สูง จะแจ้งเตือนและจะปะติดประต่อข้อมูลให้เราได้ โดยที่ไม่ต้องไปไล่ กราฟต่างๆ หรือไล่ดู Log file ของระบบงานเอง เช่นในกรณีนี้ เราสามารถคลิกครั้งเดียว เพื่อดูรายละเอียดได้ทันที
Figure 14: Error drilldown
ซึ่งเราจะได้เห็นข้อมูลว่า 83% ของ Error ทั้งหมดเป็น HTTP 500 ซึ่งเกิดขึ้นเนื่องจากในรายการ storeBooking พบ InvalidTravellerCostItemException ซึ่ง Exception นี้ เกิดขึ้นในระหว่างกำลังทำคำสั่ง getTotalCosts ในคลาส JourneyPriceHelper (บอกกระทั่งว่าเป็นบรรทัดที่ 23 ที่เจอ Exception) โดยมี Error message ด้วยว่า “Had error while accessing item ….” และเรายังสามารถกดดู Detail ต่อได้อีก
Figure 15: Error message, Exception
เมื่อกดดู Detail เราสามารถเลือกรายการที่มี Error มาดู Trace ได้ดังภาพ ซึ่งจะเห็นว่ามี Error สีแดงๆ เกิดในบริการ EasyTravelService ที่มีเทคโนโลยีเป็น Apache Tomcat (รูปแมว)
Figure 16: Error Trace
เมื่อคลิกที่บริการ EasyTravelService แล้วเลือก Tab: Errors เราก็จะเห็น Exception Message พร้อมตัวเลขครบถ้วน จะไปทดลอง Reproduce ปัญหานี้ด้วย input เดียวกัน แล้วเปิด Debug ที่บรรทัดที่เกิด Exception ก็สามารถทำได้ง่าย
Figure 17: View Exception detail
สรุป 2nd signal: ความผิดพลาด (Error)
· ผู้ใช้คาดหวังว่าการใช้งานระบบ ไม่ควรมีความผิดพลาด
· การวัดผลควรใช้ Error Rate มากกว่า Error Count
· และเพื่อให้การวัดผล Error มีความแม่นยำที่สุด ควรมีการดำเนินการปรับแก้สิ่งเหล่านี้ในเครื่องมือวัดผลด้วย
o แก้ False Positive (แจ้งปัญหาในตอนที่จริงๆ แล้วไม่มี)
§ HTTP 401 ซึ่งเกิดจากไม่ได้ล๊อกอิน
§ HTTP 5xx ในช่วงระบบ Maintenance
§ ระบบหลังบ้าน เกิด Exception ยอดเงินไม่พอโอน
o แก้ False Negative (จริงๆ แล้วมีปัญหาเกิดขึ้น แต่ไม่มีการแจ้งปัญหา)
§ ระบบแจ้ง HTTP 200 OK แต่ขึ้นระบบขัดข้อง