เปิดขั้นตอน ระบบรายงานผลการเลือกฯ จากหน้าหน่วยถึงหน้าจอ

หลังจากผ่านการเลือกตั้งครั้งประวัติศาสตร์ครั้งหนึ่งในประเทศไทย เมื่อวันที่ 24 มีนาคม 2562 ที่ผ่านมา ที่คนไทยทั้งประเทศตื่นตัว ให้ความสนใจเป็นอย่างมากว่า ผลการเลือกตั้งจะออกมาเป็นอย่างไร แต่ในการรายงานผลที่ออกมาผ่านหน้าจอทีวี สื่อออนไลน์ต่าง ๆ กลับดูสับสน คลาดเคลื่อน ไม่ตรงกัน ทีมงาน MThai ในฐานะของผู้พัฒนาระบบเชื่อมรายงานผลให้กับทีมข่าวของช่อง Mono29 จึงได้รวบรวมข้อมูลต่าง ๆ มากางเป็นขั้นตอนให้เข้าใจการทำงานกันอย่างชัดเจน

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

I.

รู้จักระบบ Rapid Report

ระบบรายงานผลการเลือกตั้งอย่างไม่เป็นทางการ หรือ Rapid Report ทีทางคณะกรรมการการเลือกตั้งได้จัดซื้อจัดจ้าง ให้บริษัทเข้าร่วมเสนอราคา ก่อนดำเนินการทำระบบดังกล่าวขึ้น ในช่วงเดือน พ.ค. 2559 เพื่อใช้ในการรายงานผลการลงคะแนนเสียงประชามติร่างรัฐธรรมนูญ วันที่ 7 สิงหาคม พ.ศ. 2559  โดยในครั้งนั้นมีผู้มาใช้สิทธิ์ออกเสียงลงประชามติ จำนวน 29,740,677 คน จากผู้มีสิทธิ์เลือกตั้ง 50,071,589 คน

จากนั้น ระบบได้ถูกพัฒนาปรับปรุงเพิ่มขึ้น เพื่อใช้ในการรายงานผลการเลือกตั้ง เมื่อวันอาทิตย์ (24 มี.ค. 62 ) ที่ผ่านมา ซึ่ง กกต. คาดหวังว่า ระบบ Rapid Report จะสามารถรายงานผลอย่างไม่เป็นทางการได้ โดยไม่มีปัญหา แต่ท้ายที่สุดแล้ว คะแนนที่เข้ามานั้น กลับมีข้อผิดพลาดหลายอย่างจนนำไปสู่ข้อสงสัยต่าง ๆ ที่เกิดขึ้น

II

ขั้นตอนของการทำงานตั้งแต่หน้าหน่วยถึงหน้าจอ

ตั้งแต่มีความชัดเจนเรื่องของการเลือกตั้งทางสื่อทีวีดิจิตอล สำนักข่าวต่างๆ รวมไปถึงสื่อออนไลน์หลายค่ายด้วยกัน ได้มีตัวแทนเข้าไปพูดคุยกับทางคณะกรรมการการเลือกตั้งถึงเรื่องการรายงานผล โดยผลการเจรจาพูดคุยกันนั้น ได้ข้อสรุปร่วมกันว่า ทาง กกต. จะเปิดระบบให้สื่อมวลชน เข้าไปดึงข้อมูลจากระบบของ กกต. ได้  โดยเซิฟเวอร์กลางของสมาคมสื่อฯ (DTT Pool) เข้าไปเชื่อมต่อกับระบบของ กกต. เพียงเครื่องเดียว เพื่อลดภาระที่อาจจะเกิดขึ้นกับระบบ Rapid Report ของ กกต.

จากแผนผังการทำงานจะเห็นว่า จากหน้าหน่วยเลือกตั้งจะมีเจ้าหน้าที่ที่เป็นกรรมการประจำหน่วยเลือกตั้ง ทำการกรอกข้อมูลต่างๆ ไม่ว่าจะเป็นจำนวนผู้ใช้สิทธิ์ จำนวนบัตรเลือกตั้งที่ได้รับ บัตรดี บัตรเสีย เข้าสู่ระบบ Rapid Report ของ กกต. ผ่านทางแอพฯ ที่สร้างขึ้น ซึ่งข้อมูลทั้งหมด จะวิ่งเข้าสู่เซิฟเวอร์ ของทางกกต. (ขั้นที่ 1 > 2 )

จากนั้นหลังจากข้อมูลเริ่มวิ่งเข้ามา ระบบของ DTT Pool หรือระบบกลางของทางสื่อมวลชน เชื่อมต่อเข้าไปดึงข้อมูลจากเซิฟเวอร์ของ กกต. ที่เป็นตัวเลขรายงานคะแนนผลการเลือกตั้ง (ขั้นที่ 3 ) ก่อนที่จะนำมากระจายกันให้สื่อมวลชนทุกค่ายใช้กัน (ขั้นตอนที่ 4 -ในตัวอย่างจะเป็นเคสของทางช่อง Mono29 ที่ทาง MThai ได้เข้าไปจัดทำระบบให้) โดยผลการพูดคุยกันในกลุ่มก้อนของสื่อมวลชนนั้น จะเปิดการเชื่อมต่อไปยังระบบของ กกต. “เพียง 1 Connection เท่านั้น” ที่เหลือเราจะจัดการกันเอง ทั้งการใช้งาน และค่าใช้จ่ายที่เกิดขึ้นจากการวางระบบ DTT Pool

> ข่าวประชาสัมพันธ์ในเว็บไซต์กกต. เรื่องจับมือสื่อมวลชนรายงานผลการเลือกตั้งอย่างไม่เป็นทางการ

III

ปัญหาแรกในการรายงานจริง “ล่ม/ช้า”

ใน 10 วันสุดท้ายก่อนวันเลือกตั้ง เป็นวันที่ตัวแทนเจรจรพูดคุยกับ กกต. ได้ข้อสรุปของ ข้อมูลต่างๆ ในการเชื่อมต่อระบบเบื้องต้น ซึ่งตลอดระยะเวลานั้น ทางตัวแทนของ DTT Pool คาดหวังว่าจะได้ “ทดลองเชื่อมต่อ” กับระบบของ กกต. อยู่โดยตลอด แต่ทราบว่า ระบบของทาง กกต. ยังไม่พร้อม เนื่องจาก “ไม่สามารถรับการเชื่อมต่อ” ได้เพียงพอ ส่วนสาเหตุนั้น มาจากระบบ Rapid Report นั้น ต้องรองรับการเชื่อมต่อจาก กรรมการการเลือกตั้งประจำหน่วย ทั่วไปเทศ จำนวน 92,320 หน่วย

ทีมงาน MThai ได้ทราบข้อมูลจากแหล่งข่าวว่า ผลการทดสอบการเชื่อมต่อไม่เป็นที่น่าพอใจ ( Load testing ) เนื่องจากระบบไม่สามารถรองรับได้จริง ในการทดสอบตลอดสัปดาห์สุดท้ายก่อนการเลือกตั้ง จำนวนการเชื่อมต่อสูงสุดที่เกิดขึ้นไม่ถึง 3 หมื่น Connections แม้ว่าจะมีทีมอื่นเข้าไปร่วมสนับสนุน แต่ระบบก็ยังไม่สามารถทำอะไรไปได้มากนัก

และในวันจริง ก็เป็นไปตามคาด เมื่อระบบ Rapid Report ไม่สามารถรองรับโหลดที่เกิดขึ้นได้ดีอย่างที่คาดหวัง ปัญหาที่ทีมข่าวได้ทราบมาจากแหล่งข่าวคือ

• ระบบช้ามาก เข้า logins ไม่ได้ ซึ่งเริ่มออกอาการตั้งแต่ตอนช่วงเช้าของวันเลือกตั้ง
• ไม่สามารถกรอกข้อมูลได้ ระบบแจ้ง error
• ฯลฯ

ซึ่งหากพิจารณาข้อมูลการใช้งานแล้ว สิ่งที่คาดว่าจะเกิดขึ้นอย่างแน่นอนคือ เจ้าหน้าที่ประจำหน่วยเชื่อมต่อเข้าระบบพร้อมๆ กัน เกิดการเชื่อมต่อ > 9 หมื่น Connections แต่ระบบรองรับได้ไม่ถึง 3 หมื่น connections ทำให้อีกจำนวนกว่า 6 หมื่นหน่วย คงต้องรอคิวต่อไปในการเชื่อมต่อและอัปเดตข้อมูลคะแนนต่างๆ

ดังนั้นหากกรรมการประจำหน่วยหนึ่งหน่วยใด เกิดกรอกข้อมูลคะแนนที่ผิดพลาดขึ้น หรือที่เรียกว่า Human Error ตามที่ทางกกต.ชี้แจงเมื่อวัน 25 มี.ค. ที่ผ่านมา นั่นหมายความว่า การกลับไปแก้ไขตัวเลขนั้นไม่สามารถทำได้ง่ายๆ อย่างแน่นอน

ทำให้เราจึงได้เห็นตัวเลขแปลกๆ เช่น เบอร์ 1 ได้คะแนน 5 พัน เบอร์อื่นๆ ได้คะแนนเป็น 0 นั่นเอง

ทางแก้ไขในปัญหานี้ทำอย่างไร

ปัจจุบันมีเทคโนโลยีอย่าง Cloud ที่สามารถรองรับโหลดในลักษณะนี้ได้สบายๆ ดังนั้น สิ่งที่ทาง MThai อยากจะเสนอแนะเพื่อปรับปรุง-พัฒนาแก้ไขให้ระบบของภาครัฐดีขึ้น จึงควรมีการจัดทำระบบคลาวด์ของภาครัฐขึ้นมาใช้อย่างจริงจัง เพื่อให้สามารถรองรับการเชื่อมต่อที่เพิ่มมากขึ้นในช่วงหนึ่งช่วงใดของปี/เหตุการณ์ต่างๆ ได้ เช่น การยื่นภาษี, การลงทะเบียนเลือกตั้งล่วงหน้า, ใบขับขี่ออนไลน์ ฯลฯ

นอกจากนี้ ยังมีข้อมูลเพิ่มเติมด้วยว่า ระบบภายในของระบบ Rapid Report นั้น มีโครงสร้างและ Architecture ที่ใช้งานอยู่นั้น ยังไม่ดีพอ ระบบเป็นการพัฒนาต่อยอดจากระบบเดิมที่ทำไว้เพื่อรองรับการลงประชามติ ที่มีความซับซ้อนน้อยว่า ( เห็นด้วย-ไม่เห็นด้วย เพียงแค่นั้น)

ซึ่งหากต้องการให้ระบบ “เสถียร-นิ่ง-ลื่น” มากกว่า นี้ จำเป็นต้องให้เวลาในการปรับปรุงระบบใหม่ทั้งหมด เพื่อให้สามารถทำงานบนระบบคลาวด์ได้อย่างมีประสิทธิภาพเต็มร้อย (ทราบภายหลังว่า ระบบนี้รันอยู่บนคลาวด์อยู่แล้ว – แก้ไขเพิ่มเติม)

III

เลขผิด, บัตรดี-บัตรเสีย-โหวตโน เกินผู้ใช้สิทธิ์

ในวันที่ 24 มี.ค. ทีมไอทีของแต่ละสำนักต่างเข้าประจำการหน้าจอ เพื่อตรวจสอบความเรียบร้อยต่างๆ ก่อนที่จะมาลุ้นกันสุดในช่วงเวลา 17.45 น. ซึ่งเป็นเวลาดีเดย์ที่ระบบ DTT Pool ตัวแทนของสื่อมวลชนทุกสำนักจะเชื่อมต่อกับระบบกกต.อย่างเป็นทางการ แต่จากสาเหตุก่อนหน้านี้จึงทำให้เกิดภาวะ “เชื่อมต่อล้มเหลว” และล่ม แทบทุก 10 นาทีจนราว 1 ทุ่ม คะแนนในระบบหลังบ้านค้างอยู่ที่ ประมาณ 7 แสนคะแนน (~1% ของคะแนนทั้งหมด)

ตัดการเชื่อมต่อ ใช้แผนสำรอง

หลังจากปัญหาล่ม ไม่สามารถเชื่อมต่อได้ ตัวแทนของระบบ DTT Pool ตัดสินใจใช้แผนสำรอง โดยทำการให้ทีมสำรองที่เตรียมไว้คีย์ข้อมูล Backup ไว้ และมีบางส่วนที่ใช้การเปิดหน้าจอของ กกต. ยิงสัญญาณแทน จนเกิดกระแสบนโลกออนไลน์ถึงประเด็น “จำนวนบัตรดี, บัตรเสีย และโหวตโน สูงเกินกว่าจำนวนผู้ใช้สิทธิ์

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

โดยในปัญหานี้ ทางทีมงาน MThai ไม่สามารถระบุปัญหา หรือสาเหตุได้อย่างชัดเจนว่า ตัวเลขที่เกิดขึ้น เกิดจากการกรอกข้อมูลที่ผิดพลาดผ่านทางแอพ Rapid Report หรือช่องทางใดกันแน่ เนื่องจากเป็นระบบภายในของทาง กกต.

แต่จากการค้นข้อมูลพบว่า ในระบบของแอพ Rapid Report เอง ได้มีการเขียนดักป้องกัน จำนวนบัตรการกรอกข้อมูลที่ผิดพลาดอยู่ในระดับหนึ่ง

แน่นอนว่า ปัญหาของจำนวนที่มีแจ้งเข้ามาที่ทีมงาน MThai ไม่ได้มีเพียงปัญหาเดียว แต่ประกอบไปด้วย

• จำนวนผู้ใช้สิทธิ์เลือกตั้ง น้อยกว่า จำนวนบัตรดี-บัตรเสีย-โหวตโน
• จำนวนประชากรผู้มีสิทธิ์เลือกตั้งที่มีจำนวนไม่เท่ากันในแต่ละช่วง
• ฯลฯ

รวมภาพจำนวนตัวเลขผู้มาใช้สิทธิเลือกตั้งที่เปลี่ยนแปลง

ดังนั้น ในปัญหาดังกล่าว ทางทีมงานคาดหวังว่า ในการเลือกตั้งครั้งต่อๆ ทางกกต. น่าจะควรมีกรรมการตรวจเช็คตัวเลขที่กรอกเข้ามา ก่อนแสดงผลขึ้นบนระบบดังกล่าวอีกครั้งหนึ่งว่า ตัวเลขนั้นถูกต้องหรือไม่

IV.

สื่อฯ แต่ละสำนักมีตัวเลขที่นั่งไม่เท่ากัน

ในการรายงานสดของคืนวันที่ 24 มี.ค. 2562 นั้น จากขั้นตอนการทำงานหลังจากที่แต่ละสำนักข่าวไปดึงข้อมูลจากระบบกลางของสื่อมวลชน หรือ DTT Pool แล้ว พบปัญหาการดึงข้อมูลไม่ได้ ตัวเลขบางส่วนมีข้อผิดพลาด ทีมงาน MThai ตัดสินใจใช้แผนสำรองเฉพาะหน้าคือ ตัดระบบการดึงข้อมูลแบบเรียลไทม์ จากระบบกลาง และเปลี่ยนมาใช้การดึงแบบ Manual แทน เพื่อกรองข้อมูลก่อนอีกชั้นหนึ่ง

โดยในส่วนนี้ จะขอกล่าวถึงในส่วนของระบบหลังบ้านที่ทางทีมงาน MThai ดูแลเท่านั้น ซึ่งในสำนักข่าวอื่น อาจจะใช้วิธีการต่างกันออกไปในการแก้ไขปัญหา

1. เมื่อเราพบว่า ระบบคะแนนเริ่มค้างอยู่ที่ ประมาณ 7 แสนคะแนน จึงได้เริ่มทำการตรวจสอบข้อมูลต่างๆ จนพบสาเหตุ
2. จากจำนวนคะแนนที่ล่าช้า และตัวเลขในไลฟ์ของ กกต. นับคะแนนไปแล้วกว่า 40% แล้ว (ข้อมูลในระบบของทีมงานอยู่ที่ 1%) จึงได้เริ่มปรับแผนสำหรับงาน “ทำมือ” เข้ามาแทน
3. ทีมงาม IT ปรับระบบให้มีการ “กรอกมือ” เพิ่มคะแนนเข้าระบบได้
4. ทีม Monitor เริ่มประมวลข้อมูลโดยการแคปเจอร์ภาพจาก กกต. แล้วนับใส่คะแนนรวมของแต่ละพรรค เพื่อให้ระบบคำนวนที่นั่ง สส. แบบบัญชีรายชื่อได้ และเริ่มทำภาพรายงานผ่านช่องทางอื่น คือ ผ่านทางหน้าเว็บ News.MThai.com และโซเซียลของ MThai เอง
5. ราวสามทุ่ม ระบบกลางของสื่อฯ เริ่มใช้งานได้ จึงได้มีการปรับตัวเลขปรับเทียบกันระหว่างส่วนที่กรอกมือและจากกกต.
6. ทีม Monitor ยังคงรายงานผ่านตัวเลขที่ได้จากไลฟ์ของ กกต. ระหว่างรอทีม IT ปรับระบบ
7. ราว 23.00 น. ระบบเริ่มกลับสู่สภาวะนิ่ง เราจึงเริ่มเห็นข้อมูลนิ่งขึ้น จำนวนตัวเลขที่นั่ง ส.ส. เริ่มนิ่ง

ซึ่งในขั้นตอนการทำงานของสำนักข่าวอื่นอาจจะแตกต่างกันออกไป และด้วยสาเหตุนี้เอง ที่ทำให้ตัวเลขที่นั่งหลักการคำนวน เป็นตัวเลขที่ได้จาก “คนละช่วงเวลา” กัน ยิ่งในช่วงต้น ข้อมูลที่มีระยะเวลาห่างกันเพียง 2-3 นาที มีจำนวน % ที่เปลี่ยนแปลงเยอะมาก ส่งผลให้ตัวเลขที่นั่ง ส.ส. ที่แสดงผลผ่านหน้าจอนั้น ไม่เท่ากันนั่นเอง

V.

บทสรุปของคะแนน 94% อย่างไม่เป็นทางการ

ในท้ายที่สุดของช่วงสายของวันที่ 25 มี.ค. ระบบกลางของ DTT Pool ได้มีการอัปเดตข้อมูลครั้ง แม้ว่าข้อมูลยังคงเป็นตัวเลขอย่างไม่เป็นทางการที่ 94% แต่ระบบก็เริ่มคำนวนตัวเลขที่นั่ง ส.ส. ได้ใกล้เคียงมากขึ้น ก่อนจะมีตรวจสอบจำนวนกันอีกครั้งในช่วงบ่าย หลังจากการแถลงข่าวของทาง กกต.

ในบทส่งท้ายของบทความนี้ ทางทีมงาน MThai ต้องการนำเสนอข้อมูลที่เกิดขึ้น และแนวทางแก้ไข เพื่อคาดหวังว่า ในอนาคตประเทศไทยจะมีระบบรายงานผลต่างๆ เหล่านี้ได้อย่างถูกต้อง รวดเร็ว มากขึ้น ซึ่งกว่าจะถึงจุดนั้น การรับรู้ปัญหา และนำมาพูดคุยกันเพื่อหาแนวทางแก้ไข ย่อมเป็นสิ่งที่ดีกว่า ดังนั้นบทความนี้ จึงไม่ได้มุ่งหวังในการที่จะค้นหา “แพะ” มารับผิดแต่อย่างใด หากแต่คาดหวังว่า หลายฝ่ายจะมองเห็นปัญหา และร่วมกันแก้ไข เพื่อสิ่งที่ดีกว่านั่นเอง