บทความโดย  คุณถิรพันธุ์ สรรพกิจ รองผู้จัดการ หัวหน้าสายงานเทคโนโลยีสารสนเทศตลาดหลักทรัพย์แห่งประเทศไทย

วันนี้ผมขออนุญาตลงศัพท์เทคนิคด้าน IT หน่อยนะครับ คือคำว่า “Spike Load” ซึ่งหมายถึง การที่ระบบมีปริมาณการใช้งานเพิ่มสูงขึ้นในปริมาณมากหลายๆ เท่า แต่เป็นแค่ในช่วงระยะเวลาสั้นๆ เป็นแค่หลักนาที หรือ ชั่วโมง ทำให้เมื่อนำปริมาณการใช้งานมาพล็อตเป็นกราฟแล้วจะเห็นเป็นแท่งสูงๆ แหลมๆ เหมือนหนาม ซึ่งเป็นที่มาของคำว่า “Spike” นั่นเอง ซึ่งเจ้า Spike Load นี้แหละที่เป็นหนึ่งในความท้าทายอันดับต้นๆ ของทีมงาน IT ทุกคน เพราะนอกจากจะต้องออกแบบและพัฒนาระบบให้สามารถรองรับปริมาณการใช้งานที่เพิ่มสูงขึ้นเป็นปริมาณหลายๆ เท่าให้ได้แล้ว ยังจะต้อง Trade off ให้เหมาะสมระหว่างความเสี่ยงที่ระบบอาจล่มได้หากเตรียม Capacity ไว้ไม่พอ กับการที่ต้องแบกรับต้นทุนของระบบที่อาจสูงเกินไปในระยะยาวหากเตรียม Capacity ไว้มากเกินไปและนานเกินไป

สำหรับตลาดทุน หุ้น IPO (Initial Public Offering) หรือหุ้นเข้าใหม่ ถือเป็นหนึ่งปัจจัยสำคัญ ที่ทำให้เกิดความน่าสนใจและสร้างบรรยากาศการลงทุนในตลาดหลักทรัพย์ โดยเฉพาะอย่างยิ่งเมื่อผู้ออกหลักทรัพย์เปิดโอกาสให้ผู้ลงทุนรายย่อยได้สิทธิ์จองซื้อก่อน ด้วยหลักการ Small lot first เพื่อให้มีการกระจายหุ้นแก่ประชาชนเป็นจำนวนมาก ส่งผลให้จำนวนผู้ลงทุนหน้าใหม่เพิ่มมากขึ้น และมีจำนวนไม่น้อยที่เริ่มเปิดบัญชีซื้อขายหลักทรัพย์ รวมถึงผู้ลงทุนเดิมที่เคยเปิดบัญชีไว้เป็นเวลานาน แต่ไม่ค่อยได้ทำการซื้อขาย (Inactive) ก็อาจกลับมา Active จากหุ้นเข้าใหม่ด้วย

หลายๆ ครั้ง หุ้น IPO มักจะตามมาซึ่งความท้าทายในรูปแบบ “Spike Load” ของระบบในตลาดหลักทรัพย์ฯ หลายระบบที่เกี่ยวข้อง อาทิ ระบบการจองซื้อและประกาศผล (Random and announcement) ระบบนายทะเบียนหลักทรัพย์ (Registrar) ระบบให้บริการผู้ลงทุน (Contact center) และระบบซื้อขายหลักทรัพย์สำหรับผู้ลงทุน (Streaming) เป็นต้น ซึ่งทีมงาน SET IT ได้ผ่านประสบการณ์ IPO มาหลายต่อหลายครั้ง โดยบางครั้งเป็นหุ้น IPO ที่มีขนาดใหญ่มากซึ่งมีผู้จองซื้อเป็นหลักหลายๆ แสนคน ผมเลยขออนุญาตนำประสบการณ์และบทเรียนในบางเหตุการณ์มาแบ่งปันในบทความนี้ครับ

เริ่มจากระบบการจองซื้อและประกาศผล ซึ่งในกรณีที่มียอดผู้ที่จะได้รับการจัดสรรเพิ่มขึ้นมากเป็นหลักหลายแสนคน ก็ต้องมีการปรับ Random process และระบบประกาศผลให้ทำงานบน Memory แทนการใช้ File หรือ Database เพื่อให้สามารถทำการ Random และแสดงผลการค้นหาให้ได้รวดเร็วที่สุด ในบางครั้งต้องมีการกระจายเครื่องประกาศผลไปใช้งานบน Public Cloud ถึง 5 แห่งผ่านระบบ Load balancer เพื่อกระจายปริมาณผู้เข้าใช้ ไม่ให้มีการกระจุกตัวอยู่ที่เดียวซึ่งอาจเกิดปัญหาคอขวดหรือ Bottleneck ได้

ระบบนายทะเบียน (Registrar) ก็ต้องมีการปรับแต่ง Application โดยเฉพาะในส่วนของ Database Index เพื่อเพิ่มประสิทธิภาพ ลดการทำ Full table scan รวมถึงหากต้องมีการพิมพ์ใบหุ้นเป็นจำนวนมากในหลักหลายแสนใบภายในระยะเวลาไม่กี่วัน ก็ต้องมีการสั่งซื้อ/เช่าเครื่อง Printer เพื่อมาใช้งานเป็นการเร่งด่วน รวมถึงต้องเตรียมเครื่องสำรอง และอะไหล่ ไว้ให้เพียงพอ เนื่องจากมีเงื่อนไขของเวลาในการส่งมอบใบหุ้น ดังนั้น ต้องมีแผนรองรับฉุกเฉินในกรณีที่เครื่อง Printer บางเครื่องอาจถอดใจหยุดทำงานไปจากการทำงานหนักติดกันหลายๆ วัน รวมถึงระบบให้บริการผู้ลงทุน (Contact center) ก็เช่นกัน ที่ต้องมีการเพิ่มช่องทางอีกหลายช่องทาง เช่น ระบบตอบรับอัตโนมัติ IVR (Interactive Voice Response), ระบบ Chat message และ ระบบ Digital form เนื่องจากจำนวนพนักงานปัจจุบันรวมพนักงาน outsource แล้ว ก็ยังไม่สามารถตอบคำถามผู้ลงทุนที่โทรเข้ามาเป็นปริมาณหลายพันคนพร้อมๆ กันได้ 

ระบบที่ถือว่าได้รับความท้าทายจากเจ้า “Spike Load” เป็นอย่างมากก็น่าจะเป็นการซื้อขายหลักทรัพย์ผ่านอินเทอร์เน็ต (Internet trading) หรือโปรแกรม Streaming เนื่องจากในบางเหตุการณ์ IPO ที่ผ่านมา เราเคยเห็นการเพิ่มขึ้นของปริมาณผู้เข้าใช้ระบบจากปกติเพิ่มขึ้นวันละประมาณ 3 พันคนเป็นเกือบ 1 แสนคนหรือมากกว่า 30 เท่าจากวันปกติ ซึ่งต้องถือว่าโชคดีที่เหตุการณ์ครั้งนั้น เราได้เตรียมขยาย Capacity เผื่อไว้แล้วค่อนข้างมากในทุกๆ ส่วน เริ่มตั้งแต่ขยาย Network Bandwidth ทั้ง Internet และ Private link เพิ่มจำนวน Server บน Domestic และ Internet Cloud เกือบสองเท่าจากเดิม ปรับแต่ง  Application และ Database รวมถึงทำการทดสอบ Load test และ Stress test (การจำลองการเข้าใช้งานระบบพร้อมๆ กันในปริมาณมากๆ) เพื่อให้มั่นใจว่าการปรับแต่งนั้นมีผลจริงกับการเพิ่มความสามารถในการรองรับการใช้งาน เป็นต้น 

โดยจากประสบการณ์ที่ผ่านมา น่าจะมี 3 ประเด็นหลักที่ช่วยให้เราผ่านสถานการณ์ IPO ในหลายๆครั้งไว้ได้ค่อนข้างดี ได้แก่ 1) การออกแบบระบบที่ดีโดยเฉพาะในส่วนที่ต้องสามารถขยายตัวในการรองรับการใช้งานที่เพิ่มขึ้นได้ในลักษณะ Scale out 2) การเตรียมความพร้อมที่ดีจากการประชุมระดมความคิดเห็น ในทุกส่วนงานที่เกี่ยวข้องรวมถึงการทดสอบระบบในลักษณะ Stress test ก่อนสถานการณ์จริง และ 3) การที่เรามักจะกังวลกับทุกเรื่องที่อาจจะเกิดขึ้นได้ เพื่อนำกลับมาเตรียมแผนสำรองในการรองรับ อย่างไรก็ตาม ก็ยังมีอีกหลายเหตุการณ์ IPO ที่ทีมงาน IT เคยประสบปัญหาค่อนข้างหนักที่ต้องมีการแก้ไขปัญหาหน้างานเพิ่มเติมเพื่อให้สามารถผ่านไปได้

หากใครเคยได้ยินกฎของเมอร์ฟี่ (Murphy’s law) ที่กล่าวไว้ว่า Anything that can go wrong, will go wrong ก็เรียกได้ว่าเจ้า Spike Load จากหุ้น IPO นี้แหละเป็นตัวสำคัญในการกระตุ้นกฎข้อนี้ได้มากสำหรับระบบ IT ในตลาดหลักทรัพย์เลยทีเดียว จากประสบการณ์ของทีมงานที่เคยประสบปัญหาหลายครั้ง แต่ผมเชื่อว่าปัญหาทุกครั้งจะยิ่งทำให้ทีม SET IT ได้นำประสบการณ์ที่เราได้ ไปเรียนรู้ พัฒนาและนำไปปรับปรุงเพิ่มเติม อย่างไรก็ตาม หากไปเทียบกับโครงการในระดับประเทศ เช่น เราไม่ทิ้งกัน หมอชนะ ไทยชนะ คนละครึ่ง รวมถึงโครงการล่าสุดคือ เราชนะ ที่ผมคาดว่าน่าจะต้องเจอกับ Spike Load ในระดับหลายล้านคนแล้ว ก็เรียกได้ว่าน่ายังมีอีกหลายสิบเรื่องที่ทีมงานยังคงต้อง เรียนรู้และพัฒนาเพิ่มขึ้นกันต่อไป

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

บทความโดย  คุณถิรพันธุ์ สรรพกิจ รองผู้จัดการ หัวหน้าสายงานเทคโนโลยีสารสนเทศตลาดหลักทรัพย์แห่งประเทศไทย