MaggieF8
January 16
·
ทำไมระบบประกันสังคมต้องเริ่มนับหนึ่งใหม่ ทั้งที่เคยทำสำเร็จมาแล้ว 12 ปีก่อน
1. เรื่องราวเริ่มต้นจากการที่คุณณัฐวุฒิ ได้ติดตามข่าวความคืบหน้าโครงการพัฒนาระบบ Web Application ของสำนักงานประกันสังคม หรือ SSO ซึ่งมีกำหนดเสร็จล่าช้าจากเดิมปี 2566 ไปจนถึงปี 2569 ค่ะ สิ่งที่ทำให้เขารู้สึกตกใจและประหลาดใจอย่างยิ่งคือหนึ่งในเหตุผลที่ระบุว่าระบบเก่านั้นทำงานมานานกว่า 34 ปีแล้ว โดยฐานข้อมูลเดิมยังคงเป็นแบบ Text File ที่เขียนด้วยภาษา COBOL ซึ่งเป็นเรื่องที่น่าเหลือเชื่ออย่างยิ่งสำหรับระบบงานขนาดใหญ่ระดับประเทศในยุคปัจจุบันที่ควรจะมีการพัฒนาไปไกลกว่าการใช้ไฟล์ข้อความแบบดั้งเดิมตั้งนานแล้วค่ะ
2. คุณณัฐวุฒิเล่าด้วยความรู้สึกอัดอั้นใจว่า ตัวเขาเองนี่แหละที่เป็นคนรับหน้าที่สำคัญในการ Migrate หรือย้ายระบบจาก SAPIEN มาเป็น IBM DB2 เมื่อหลายปีก่อน ซึ่งในตอนนั้นเขามั่นใจว่าขั้นตอนการย้ายข้อมูลทั้งหมดได้สำเร็จลุล่วงไปด้วยดีตามมาตรฐาน และได้ทำการส่งมอบงานต่อให้กับทีม Solution Delivery เพื่อนำไปพัฒนาต่อในส่วนของ Web Application เรียบร้อยแล้วค่ะ ดังนั้นเมื่อได้ยินข่าวว่าระบบปัจจุบันยังคงเป็นแบบเก่าอยู่ จึงทำให้เขารู้สึกแปลกใจว่าสิ่งที่เขาเคยทุ่มเทแรงกายแรงใจทำไว้นั้นหายไปไหนหมด หรือโครงการที่แสนภาคภูมิใจนั้นถูกพับเก็บไปเฉยๆ กันแน่คะ,
3. ย้อนกลับไปเมื่อช่วงสงกรานต์ปี 2555 ซึ่งถือเป็นหนึ่งในเหตุการณ์ที่เขาภาคภูมิใจที่สุดในชีวิตการทำงานเลยค่ะ โครงการที่เขาทำในตอนนั้นมีชื่อว่า "โครงการพัฒนาระบบสารสนเทศงานประกันสังคม" หรือที่เรียกย่อๆ ว่า DBMS 6+3 โดยมีเป้าหมายหลักคือการย้ายโครงสร้างระบบทั้งหมดจากระบบ SAPIENS ไปสู่ IBM DB2 และพัฒนา Web Application ด้วยภาษา JAVA ผ่าน Middleware อย่าง IBM WebSphere ค่ะ โครงการนี้เริ่มมาตั้งแต่ปี 2550 แต่เขามีโอกาสได้เข้าไปช่วยจัดการในส่วนของ Data Migration อย่างเต็มตัวในช่วงปี 2554 ในฐานะบริษัทในเครือค่ะ
4. ในช่วงเริ่มต้นของการทำงาน เขาต้องเผชิญกับอุปสรรคมากมาย โดยเฉพาะการทำงานร่วมกับ IT Vendor เจ้าถิ่นและที่ปรึกษาโครงการที่ไม่ค่อยให้ความร่วมมือเท่าที่ควรค่ะ เขาต้องใช้ความพยายามอย่างมากในการคัดค้านแนวทางการทำงานแบบเดิม หรือ Migration methodology ที่ใช้กันมาตลอด เพราะจากการประเมินอย่างรอบคอบแล้ว เขาพบว่าวิธีการเหล่านั้นไม่มีทางที่จะนำไปสู่ความสำเร็จได้อย่างแน่นอนค่ะ การต้องงัดข้อกับที่ปรึกษาจึงเป็นเรื่องที่เหนื่อยที่สุด แต่เขาก็จำเป็นต้องทำเพื่อให้โครงการเดินหน้าต่อไปได้อย่างถูกต้องตามหลักการวิศวกรรมข้อมูลที่ควรจะเป็นค่ะ
5. วิธีการเดิมที่ทางโครงการพยายามทำมาตลอดคือการ Extract ข้อมูลจาก SAPIEN แล้วนำเข้าสู่ DB2 โดยใช้คอมพิวเตอร์ PC เพียง 7 เครื่องในการช่วยกัน Convert ข้อมูลค่ะ แบ่งเป็น 6 เครื่องสำหรับระบบหลัก และอีก 1 เครื่องสำหรับระบบย่อยอีก 3 ระบบ แล้วจึงค่อยโยนข้อมูลกลับเข้าไปใน DB2 อีกครั้ง ซึ่งเป็นวิธีการที่ดูเหมือนจะล่าช้าและไม่เหมาะสมกับปริมาณข้อมูลอันมหาศาลค่ะ คุณณัฐวุฒิเห็นจุดอ่อนนี้อย่างชัดเจนและรู้ว่าหากยังฝืนทำแบบเดิมต่อไป โครงการไม่มีทางจบลงได้อย่างแน่นอนในกรอบเวลาที่กำหนดไว้ เขาจึงต้องเร่งปรับปรุงกระบวนการใหม่ค่ะ
6. สำหรับการดึงข้อมูลหรือ Extract Data นั้น ทีมงานชุดเดิมได้ดูแลในส่วนของ Script ไว้เรียบร้อยและมีความถูกต้องดีอยู่แล้วค่ะ แต่ความยุ่งยากจริงๆ คือการที่ข้อมูลดั้งเดิมเป็นภาษา COBOL และอยู่ในรูปแบบ Text Files ซึ่งผู้ที่จะทำงานนี้ได้ต้องมีความเข้าใจในแง่ธุรกิจเป็นอย่างดีเยี่ยมค่ะ ต้องสามารถระบุได้ว่าตัวอักษรแต่ละตำแหน่งมีความหมายว่าอย่างไร เช่น ตำแหน่งที่ 1 ถึง 5 คือพารามิเตอร์ และตำแหน่งถัดไปคือข้อมูลจริงค่ะ การจัดการกับ Fixed Length Delimiter เช่นนี้ต้องใช้ความละเอียดรอบคอบสูงมากเพื่อไม่ให้ข้อมูลสำคัญผิดเพี้ยนไปแม้แต่นิดเดียวค่ะ
7. อุปสรรคที่แท้จริงที่เขาพบคือกระบวนการ Convert Data เนื่องจากข้อมูลดิบรวมๆ มีขนาดใหญ่มากถึงประมาณ 5 Terabytes ค่ะ ในการแปลงข้อมูลจะต้องนำข้อมูลจากส่วน Core ที่ถูกแบ่งเป็นชิ้นเล็กๆ เพื่อความสะดวกในการถ่ายโอนมารวมกันให้เป็นตารางปลายทางก่อนค่ะ จากนั้นจึงค่อยนำข้อมูลจากระบบย่อยไปแปลงต่อ แต่ปัญหาคือไม่สามารถทำความสะอาดข้อมูลทีละระบบได้โดยตรง เพราะต้องตรวจสอบเรื่องความถูกต้องและความสัมพันธ์ของข้อมูลระหว่างกันด้วยค่ะ ทำให้กระบวนการนี้ซับซ้อนและต้องส่งข้อมูลไปมาระหว่างเครื่อง PC ทั้ง 7 เครื่อง จนกลายเป็นคอขวดมหาศาลค่ะ
8. เมื่อคุณณัฐวุฒิวิเคราะห์เห็นปัญหาคอขวดที่เกิดขึ้น เขาจึงตัดสินใจออกแบบ Data Pipeline ใหม่ทั้งหมดโดยการตัดการใช้เครื่อง PC ทั้ง 7 เครื่องทิ้งไปค่ะ เขาหันมาขอความช่วยเหลือจากบริษัทเพื่อขยายทรัพยากรของเครื่อง IBM DB2 ปลายทางเพียงเครื่องเดียวให้พอรองรับการแปลงข้อมูลในคราวเดียวค่ะ นอกจากการปรับปรุง Data Pipeline แล้ว เขายังได้ใช้เทคนิคเฉพาะทางด้าน Database Administrator เข้ามาทำการ Fine Tuning ระบบเพื่อเพิ่มประสิทธิภาพสำหรับการ Migration โดยเฉพาะ เพื่อให้สามารถรองรับการโหลดข้อมูลปริมาณมากได้อย่างรวดเร็วและมีประสิทธิภาพสูงสุดภายใต้ข้อจำกัดที่มีค่ะ
9. เขาเริ่มต้นกระบวนการด้วยการแยก Tablespace ออกเป็น 2 กลุ่มหลัก โดยกลุ่มแรกเรียกว่า MGTTS ซึ่งออกแบบมาเพื่อใช้สำหรับ Load ข้อมูลที่ได้จากการ Extract เข้าไปตรงๆ โดยเฉพาะค่ะ การแยกส่วนเช่นนี้ช่วยให้การจัดการข้อมูลดิบเป็นไปอย่างเป็นระบบและไม่รบกวนส่วนอื่นๆ ของฐานข้อมูลค่ะ การวางแผนโครงสร้างตั้งแต่ระดับพื้นฐานเช่นนี้เป็นสิ่งสำคัญมากในการจัดการกับข้อมูลที่มีขนาดใหญ่และมีความซับซ้อนสูง เพื่อให้ขั้นตอนการทำงานในลำดับถัดไปสามารถดำเนินไปได้อย่างราบรื่นและลดโอกาสที่จะเกิดข้อผิดพลาดในระหว่างกระบวนการย้ายข้อมูลที่แสนยุ่งยากนี้ค่ะ
10. นอกจากกลุ่ม MGTTS แล้ว เขายังได้แบ่ง Tablespace กลุ่มที่สองสำหรับการใช้งานจริง โดยแยกย่อยตามระบบงานต่างๆ เพื่อให้ดิสก์สามารถทำงานได้เต็มประสิทธิภาพและรองรับการแปลงข้อมูลแบบขนานหรือ Parallel ได้ค่ะ กระบวนการนี้ยังรวมถึงการจัดกลุ่ม Bufferpool ให้สอดคล้องกันด้วยนะคะ ในส่วนของการนำข้อมูลเข้า เขาเลือกใช้คำสั่ง DB2 Load และต้องแยก Script ออกเป็นขั้นตอนย่อยๆ ตั้งแต่การสร้างตาราง การโหลดไฟล์ข้อมูลจำนวนมาก ไปจนถึงการสร้าง Index และ Constraints ต่างๆ เพื่อให้การทำงานในแต่ละขั้นตอนรวดเร็วที่สุดเท่าที่จะเป็นไปได้ โดยต้องบริหารจัดการทรัพยากรระบบอย่างเข้มงวดค่ะ
11. กลยุทธ์สำคัญที่คุณณัฐวุฒิใช้ในการแปลงข้อมูลคือการเปลี่ยนจากการส่งไฟล์ไปมา เป็นการแปลงด้วย SQL Statement โดยตรง และใช้เทคนิค Load from Cursor เพื่อลดขั้นตอนการพักไฟล์หรือการโอนย้ายข้อมูลที่ซ้ำซ้อนค่ะ แม้วิธีนี้จะต้องแลกมาด้วยการทำ Fine Tuning ในทุกๆ Statement และต้องใช้พื้นที่ของ Temp Tablespace เป็นจำนวนมหาศาล แต่เขาก็ยอมรับความท้าทายนั้นค่ะ เขาต้องคอยปรับค่าพารามิเตอร์ต่างๆ ของระบบให้เหมาะสมกับ Script แต่ละตัวที่มีจำนวนเกือบ 2,000 ชุด เพื่อให้การทำงานราบรื่นและใช้ทรัพยากรที่มีอยู่อย่างคุ้มค่าที่สุดในระหว่างกระบวนการค่ะ
12. ในทุกขั้นตอนการทำงาน เขาจะทำการทดสอบอย่างละเอียดว่าแต่ละงานเน้นใช้ทรัพยากรส่วนไหนเป็นหลักค่ะ หากช่วงไหน CPU ยังว่าง เขาก็จะนำงานที่สามารถทำแบบคู่ขนานหรือ Parallel Run ได้เข้ามาเบียดเสริมทันทีค่ะ เช่นเดียวกันกับหากพื้นที่ Disk หรือความเร็วในการอ่านเขียนยังรองรับไหว เขาก็จะจัดสรรงานเข้าไปทำงานร่วมกันโดยไม่ให้รบกวนกันค่ะ การวางแผนที่แยบยลเช่นนี้ทำให้เขาสามารถรีดความสามารถของระบบออกมาได้จนถึงขีดสุด ซึ่งเป็นหัวใจสำคัญที่ทำให้การย้ายข้อมูลขนาดใหญ่ระดับหลาย Terabytes สามารถดำเนินไปได้อย่างรวดเร็วและทันตามกำหนดเวลาที่ตกลงกันไว้ค่ะ
13. เมื่อกระบวนการแปลงข้อมูลทั้งหมดเสร็จสิ้นลง ก็จะเข้าสู่ขั้นตอนที่เรียกว่า PostConvert ค่ะ ในขั้นตอนนี้เขาต้องทำการล้างข้อมูลการตั้งค่าต่างๆ ที่เตรียมไว้สำหรับงาน Migrate ออกให้หมด เพื่อปรับจูนระบบให้เหมาะสมกับการทำงานจริงของ Web Application ค่ะ เช่น การลบ Index และ Tablespace ที่ใช้เฉพาะงานย้ายข้อมูลทิ้งไป แล้วสร้าง Index ชุดใหม่ที่ตรงตามลักษณะการใช้งานจริงของแอปพลิเคชันแทนค่ะ รวมถึงการปรับจูน Buffer ตามการใช้งานจริง เพื่อให้ระบบมีเสถียรภาพและมีประสิทธิภาพสูงสุดพร้อมสำหรับการเปิดใช้งานอย่างเป็นทางการเพื่อให้ประชาชนได้รับบริการที่ดียิ่งขึ้นค่ะ
14. การ Migration ครั้งใหญ่นี้ผ่านการทดสอบหลายต่อหลายรอบจนมั่นใจในความถูกต้องแม่นยำค่ะ และในที่สุดความสำเร็จที่สมบูรณ์แบบก็เกิดขึ้นในช่วง "Bigbang ครั้งที่ 7" ระหว่างวันที่ 12-19 เมษายน พ.ศ. 2555 ค่ะ ซึ่งเป็นช่วงวันหยุดยาวสงกรานต์ที่คุณณัฐวุฒิและทีมงานต้องทำงานกันตลอด 24 ชั่วโมง โดยนอนเฝ้าระบบอยู่ที่สำนักงานประกันสังคมเลยทีเดียวค่ะ ความทุ่มเทในครั้งนั้นทำให้การย้ายข้อมูลสำเร็จลุล่วงอย่างงดงาม และเขาก็ได้ส่งมอบงานต่อให้กับทีม Solution Delivery เพื่อนำไปพัฒนาต่อในส่วนของ Web Application ตามแผนงานที่วางไว้อย่างภาคภูมิใจค่ะ,
15. ตามหลักการแล้ว เมื่อการย้ายข้อมูลสำเร็จตั้งแต่ปี 2555 เรื่องราวควรจะจบลงและระบบใหม่ควรถูกใช้งานต่อเนื่องมาจนถึงปัจจุบันค่ะ หากระบบที่พัฒนาขึ้นใหม่มีความล่าช้า สิ่งที่ควรทำคือการไปปรับจูนประสิทธิภาพให้ดีขึ้น หรือหากพบว่าข้อมูลไม่ถูกต้อง ก็ควรเข้าไปแก้ไขที่ Data Pipeline แล้วทำการย้ายข้อมูลใหม่อีกครั้งในลักษณะ Bigbang ค่ะ แต่สิ่งที่เกิดขึ้นจริงกลับกลายเป็นเรื่องตลกร้ายที่น่าเศร้า เพราะดูเหมือนว่ากระบวนการที่เขาอุตสาหะทำมานั้นจะไม่ได้ถูกนำไปสานต่อให้เกิดประโยชน์อย่างต่อเนื่องในระยะยาวอย่างที่เขาคาดหวังเอาไว้ในตอนแรกเลยค่ะ
16. อีกหนึ่งประเด็นที่น่าสนใจในตอนนั้นคือเรื่องลิขสิทธิ์ของซอฟต์แวร์ค่ะ เนื่องจากโครงการนี้เริ่มต้นมานานตั้งแต่ปี 2550 ทำให้ License ของ IBM DB2 กำลังจะหมดอายุลงในปี 2555 ซึ่งเป็นช่วงเวลาใกล้เคียงกับการทำ Bigbang ครั้งที่ 7 พอดีค่ะ ในช่วงเวลาที่สำคัญที่สุดนั้น กลับมีประเด็นความต้องการที่จะเปลี่ยนไปใช้ระบบ Oracle แทน ทำให้ต้องเสียเวลาไปกับการทำ Proof of Concept หรือ POC ใหม่ทั้งหมดอีกครั้งค่ะ ความไม่แน่นอนในเชิงนโยบายและการเลือกใช้เทคโนโลยีเช่นนี้ ยิ่งทำให้โครงการที่ควรจะจบลงได้โดยง่ายกลับมีความซับซ้อนและยืดเยื้อออกไปอีกโดยไม่จำเป็นเลยค่ะ
17. ในปัจจุบัน เมื่อคุณณัฐวุฒิได้รับทราบข่าวว่าโครงการประกันสังคมยังคงติดหล่มอยู่กับระบบเก่าที่เป็น COBOL และ Text File เขารู้สึกอึ้งและสับสนเป็นอย่างมากค่ะ เขาตั้งคำถามว่าความภาคภูมิใจและความสำเร็จที่เขาเคยทำไว้เมื่อ 12 ปีก่อน กลายเป็นเพียงเศษซากของโครงการที่ถูกทิ้งไปเฉยๆ อย่างนั้นหรือคะ ทำไมถึงมีการวนกลับมาเริ่มนับหนึ่งใหม่ในเรื่องเดิมๆ ทั้งที่ความยากลำบากในการย้ายข้อมูลนั้นเคยถูกพิชิตไปแล้วโดยฝีมือของเขาและทีมงานในอดีตค่ะ มันเป็นเรื่องที่น่าเสียดายทั้งเวลาและความทุ่มเทมหาศาลที่คนทำงานได้เสียสละไปจริงๆ ค่ะ
18. สิ่งที่น่ากังวลที่สุดในมุมมองของเขาคือ "วงจรอุบาทว์" ของงานด้าน IT ในองค์กรขนาดใหญ่ค่ะ เขาตั้งข้อสังเกตว่าในอีก 15 ปีข้างหน้า ชะตากรรมแบบที่เขาเจออาจจะเกิดขึ้นซ้ำอีก โดยจะมีบริษัทใหม่เข้ามาประมูลงานแล้วเริ่มกระบวนการ Migration และพัฒนาระบบใหม่วนเวียนไปเรื่อยๆ ไม่จบสิ้นค่ะ การที่ระบบต้องวนกลับมาแก้ไขปัญหาเดิมซ้ำๆ แทนที่จะเป็นการต่อยอดจากฐานข้อมูลที่ทำไว้ดีแล้ว ถือเป็นความสูญเสียอย่างยิ่งต่อการพัฒนาระบบดิจิทัลของประเทศ และทำให้ประชาชนต้องรอคอยบริการที่ทันสมัยออกไปอย่างไม่มีกำหนดค่ะ
19. แม้เขาจะจำรายละเอียดงบประมาณที่แน่นอนไม่ได้ในตอนนี้ แต่เขาก็พอจะจำได้รางๆ ว่าโครงการที่เขาเคยทำนั้นมีมูลค่ามหาศาลอยู่ระหว่าง 1,000 ถึง 2,000 ล้านบาทเลยทีเดียวค่ะ การเห็นเม็ดเงินจำนวนมากขนาดนี้ต้องจมหายไปกับโครงการที่ไม่สามารถใช้งานได้จริง หรือต้องถูกรื้อทำใหม่ซ้ำแล้วซ้ำเล่า จึงเป็นเรื่องที่น่าสลดใจอย่างยิ่งค่ะ ในฐานะคนที่เคยเป็นส่วนหนึ่งของความสำเร็จในอดีต เขาจึงอดไม่ได้ที่จะออกมาตั้งคำถามถึงประสิทธิภาพในการบริหารจัดการโครงการด้านเทคโนโลยีสารสนเทศของหน่วยงานภาครัฐที่ส่งผลกระทบต่อเงินภาษีและคนจำนวนมากค่ะ
20. เรื่องราวของคุณณัฐวุฒิจึงเป็นบทเรียนที่สำคัญมากสำหรับแวดวง IT และการบริหารงานภาครัฐไทยค่ะ ว่าการมีเทคโนโลยีที่ดีหรือมีบุคลากรที่เก่งกาจเพียงอย่างเดียวอาจไม่เพียงพอ หากขาดวิสัยทัศน์และการบริหารจัดการที่ต่อเนื่อง รวมถึงความกล้าที่จะเปลี่ยนผ่านจากระบบเก่าอย่างแท้จริงค่ะ ความผิดพลาดในอดีตที่ปล่อยให้โครงการพันล้านกลายเป็นเพียงตำนานที่ถูกลืม ควรจะเป็นบทเรียนเพื่อไม่ให้ประวัติศาสตร์ซ้ำรอยอีก เพื่อให้การพัฒนาระบบของประเทศเดินหน้าไปได้อย่างยั่งยืนและเกิดประโยชน์สูงสุดต่อประชาชนทุกคนที่ฝากความหวังไว้กับระบบประกันสังคมค่ะ
https://www.facebook.com/photo/?fbid=122120010441016745&set=a.122094513273016745