No. Transactions Per Hour

Make Your Performance Criteria More Manageable

โปรดักท์ โอนเนอร์เดินมาคุยกับเราเรื่องประสิทธิภาพของระบบอีคอมเมิร์สที่เค้าดูแลอยู่

“ตอนนี้ธุรกิจกำลังขยายตัว ผมอยากให้เรารองรับได้อย่างน้อย 24,000 ออเดอร์ต่อวัน — เป็นไปได้มั้ยครับ?”

ในฐานะหัวหน้าทีมพัฒนาหรือจะโปรเจกต์ เมเนเจอร์ก็ตามแต่ คำว่า 24,000 ออเดอร์ต่อวันนั้นไม่มีความหมายในเชิงเทคนิค มันเป็นสิ่งที่กว้างและจับต้องยากเกินไป

หน่วย “วัน” ใหญ่เกินไป

คิดง่ายๆเลย ถ้ากำหนดรีไควเม้นต์มาแบบนี้ การทดสอบระบบหนึ่งเทสเคสต้องรันระบบทิ้งไว้ 24 ชั่วโมงเพื่อดูว่าระบบเรารองรับออเดอร์ได้อย่างน้อย 24,000 ออเดอร์หรือไม่ … มันนานไปกว่าจะวัดผลได้ … ไม่ดีๆ

สิ่งที่เราควรทำคือถามโปรดักท์ โอนเนอร์กลับไปว่า “พี่อยากรับออเดอร์ได้เท่าไรต่อชั่วโมงครับ?” … เราต้องย่อยหน่วยให้เล็กลงจากวันมาเป็นชั่วโมง

การกระจายของโหลดไม่ได้เป็นค่าเฉลี่ย

หลายครั้งโปรดักท์ โอนเนอร์จะเตรียมมาแค่บิสซิเนสรีไควเม้นต์นั่นก็คือ 24,000 ออเดอร์ต่อวัน จะว่าไปก็ไม่ผิดหรอกเค้ามีหน้าที่ดูแลเรื่องธุรกิจและการคำนวณยอดขายต่อวันนั่นสมเหตุสมผลที่สุดสำหรับเค้า แต่การที่เราคำนวณตัวเลขต่อชั่วโมงด้วยการจับ 24,000 มาหารด้วย 24 เท่ากับชั่วโมงล่ะ 1,000 ออเดอร์ … นั่นก็ง่ายและหยายเกินไปเพราะธรรมชาติของการสั่งซื้อสินค้ามันขึ้นอยู่กับเวลาด้วย

เราต้องคุยกันเรื่องโหลดในระดับเฉลี่ย (Average Load) และโหลดในช่วงพีค (Peak Load) ครับ … ช่วงเวลายิงโปรโมชั่น ช่วงเวลาฤดูกาลขายดีอย่างปีใหม่หรือสงกรานต์ หรือวันเงินเดือนออก อื่นๆ

เพื่อป้องกันความเสี่ยง … ตัวเลขทั้งหมดนี้เป็นแค่การคาดการณ์ทั้งนั้นครับ ถ้าโหลดที่เข้ามาจริงมันไม่เกินตัวเลขพวกนี้ก็ดีไป แต่ถ้าเกินหละ? ระบบพังเลยมั้ย? … ทางที่ดีเราควรปรับตัวเลขนี้ให้สูงขึ้นจากรีไควเม้นต์อีกสักนิด 10–15% ก็พอจะช่วยให้เรามั่นใจได้มากขึ้นกว่าเดิมอีกนิดนึง

ข้อมูลที่วิ่งเข้ามาไม่ได้มีแค่ออเดอร์

มองกันให้ลึกอีกนิดนึง ระบบอีคอมเมิร์สนั้นต้องจัดการออเดอร์ เราต้องถามตัวเองว่า “แล้วในออเดอร์มันมีข้อมูลอะไรอีก” เราต้องพยายามจำลองสถานการณ์ให้เหมือนของจริงที่สุด

“ไม่มีใครสั่งซื้อของโดยไม่มีสินค้าอยู่ในตะกร้าหรอก” — จริงมั้ย?

เพราะฉะนั้นคำว่าออเดอร์มันต้องมีคำว่าสินค้าเข้ามาเกี่ยวข้องด้วยเสมอ คำถามกลับไปยังโปรดักท์ โอนเนอร์คือ “พี่ครับ โดยเฉลี่ยแล้วหนึ่งออเดอร์จะมีสินค้ากี่ชิ้น?” ความแตกต่างระหว่างออเดอร์ที่มีสินค้าหนึ่งชิ้นกับ 100 ชิ้นนั้นต่างกันนะครับ ระบบเรากำลังจัดการกับตัวเลขไหนอยู่?

พฤติกรรมนั้นมีมากมายหลากหลายรูปแบบ

ย้ำอีกครั้งว่าเราต้องพยายามจำลองสถานการณ์ให้เหมือนของจริงที่สุด

“ไม่มีลูกค้าคนไหนเปิดหน้าเวปเข้ามาแล้วกดปุ่มออเดอร์ทันทีหรอก” — จริงมั้ย?

จริงๆคงไม่มีระบบไหนที่ทำแบบนี้ได้ด้วยซ้ำ (อย่างน้อยก็ต้องล๊อกอินหละวะ ฮ่าๆ)คำถามกลับไปที่โปรดักท์ โอนเนอร์เพิ่มเติมคือ “พี่ครับ ช่วยเล่าพฤติกรรมมาตรฐานของกลุ่มลูกค้าของพี่ให้ฟังหน่อยครับ มันเป็นประมาณนี้รึเปล่า?”

• Login
• Browse Products
• Search Products
• Next Page
• Select Product
• Add to Cart
• Back to Search Result
• Next Page
• Select Product
• Add to Cart
• Back to Home Page
• Add Review to Product
• Proceed Checkout
• Change Billing Information
• Click Confirm Payment
• Etc Etc Etc

นี่แค่ตัวอย่างซิงเกิ้ลยูเซ่อร์นะ ของจริงไม่ใช่แน่นอนเพราะระบบเราฮอตมาก อาจจะมีลูกค้า 3,000 คนเข้ามาใช้ระบบเราพร้อมๆกัน … ยังไงหละทีนี้?

เราจะถามโปรดักท์ โอนเนอร์ต่อไปอีกว่า “พี่ครับ คำว่าหนึ่งออเดอร์ของพี่คือการที่ลูกค้าทำนั่นนี่จนถึง Click Confirm Payment ใช่มั้ยครับ?” — เห็นป่าวว่าหนึ่งออเดอร์หนะมันแยกย่อยได้หลายรีเควสมากๆ … กำหนดกรอบให้ชัดเจนนะครับ

การทดสอบนั้นก็หลายหลายเช่นกัน

การทดสอบเรื่องประสิทธิภาพของระบบนั้นมีหลายเทคนิค … ซึ่งเราควรประยุกต์ใช้ให้ครบถ้วนเพื่อการการันตีคุณภาพและเพิ่มความมั่นใจ

Load Test = แปลว่าเราลองทดสอบว่าระบบเราสามารถรองรับปริมาณโหลดตามจำนวนที่เรากำหนดไว้ได้หรือไม่ ทั้งโหลดโดยเฉลี่ยและโหลดในช่วงพีค

Reliability Test = เรียกอีกอย่างว่า Longevity Test ซึ่งคือเทคนิคการเทสเพื่อการันตีว่าการที่ระบบเราผ่าน Load Test มาได้ไม่ใช่เรื่องฟลุ๊ก … แบบว่ารองรับโหลดช่วงพีคได้แต่อีกสองนาทีต่อมาล่ม ฮ่าๆ การเทสประเภทนี้คือการปล่อยโหลดในปริมาณปกติสลับพีคเข้าไปในระบบอย่างต่อเนื่องเป็นชั่วโมง เป็นวัน เป็นสัปดาห์ ดูซิว่ามันพังมั้ย กินซีพียูหรือแรมแบบผิดปกติมั้ย?

Stress Test = เป็นการเทสเพื่อดูจุดแตกหักของระบบเรา เพื่อหาตัวเลขปริมาณโหลดสูงสุดที่รองรับได้ เทสไม่ยากด้วยการปล่อยโหลดที่ระดับพีคเข้าไปหนึ่งชั่วโมง — พังมั้ย? ยังไม่พังก็เพิ่มจำนวนเข้าไปอีก — ยังไม่พัง? ทำซ้ำๆไปจนมันพัง จดตัวเลขมาว่าปริมาณโหลดสุดท้ายอยู่ที่กี่ทรานแซคชั่นต่อชั่วโมง

ห้าข้อง่ายๆ (ที่ผมคิดออกตอนนี้) ที่จะช่วยให้เราตีความบิสซิเนสรีไควเม้นต์ให้มาเป็นเทคนิคัลรีไควเม้นต์ในเรื่องของประสิทธิภาพของระบบได้ชัดเจนและจับต้องได้มากขึ้นครับ

ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟต์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ