ย้ายครบ ไม่ได้แปลว่าย้ายถูก: validate และ cutover ตอนเปลี่ยนระบบ

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

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

"ครบ" ไม่เท่ากับ "ถูก"

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

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

ชั้นที่คนมักข้ามคือ spot-check การสุ่มค่าจริงมาเทียบทีละรายการกับระบบเดิม โดยตั้งใจเลือกเคสขอบ เช่น รายการที่มีค่าติดลบ รายการที่บาง field เว้นว่าง หรือรายการที่เก่าที่สุดในระบบ เพราะข้อมูลที่แปลงพลาดมักโผล่ที่ขอบก่อนตรงกลาง ชั้นสุดท้ายคือ referential integrity การตรวจว่าความสัมพันธ์ระหว่างตารางยังอยู่ครบ ใบสั่งซื้อยังชี้ไปหาลูกค้าที่มีตัวตนจริง ไม่ได้กลายเป็นรายการลอยที่โยงไปหาข้อมูลที่หายไปตอนย้าย

ข้อมูลที่หายมีคนสังเกต ข้อมูลที่ผิดไม่มี

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

เกณฑ์ผ่านต้องตกลงก่อนวัน go-live

acceptance criteria คือเงื่อนไขที่ตกลงกันไว้ล่วงหน้าว่าข้อมูลแบบไหนถึงเรียกว่าผ่าน และต้องเขียนให้วัดได้จริง ประโยคอย่าง "ข้อมูลถูกต้องครบถ้วน" ฟังดูดีแต่ตีความได้ร้อยแบบ และไม่มีใครฟันธงได้ว่าตอนไหนถือว่าผ่าน เงื่อนไขที่ใช้ได้จริงต้องชี้วัดเป็นข้อๆ เช่น ยอดรวมทางการเงินของทุกบัญชีต้องตรงกับระบบเดิมถึงหลักสตางค์ จำนวนลูกค้าที่ยัง active ต้องเท่ากัน และทุกรายการที่ตรวจไม่ผ่านต้องมีคำอธิบายกำกับ แทนการปล่อยผ่านเป็นยอดคงเหลือที่ไม่มีใครดู

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

ที่สำคัญไม่แพ้ตัวเกณฑ์คือใครเป็นคนเซ็นรับ คนนั้นควรเป็นเจ้าของข้อมูลฝั่งธุรกิจ คนที่ใช้ข้อมูลชุดนั้นทำงานทุกวัน เพราะเขาคือคนเดียวที่มองออกว่าตัวเลขที่เห็นสมเหตุสมผลหรือเปล่า ทีมเทคนิคยืนยันได้ว่าย้ายมาครบตามกระบวนการ แต่ยืนยันแทนไม่ได้ว่ายอดขายเดือนนี้ที่ระบบใหม่แสดง เป็นตัวเลขที่ถูกในสายตาคนทำธุรกิจ การตัดสินใจ Go/No-Go จึงต้องมีเจ้าของที่ชัดและมีเกณฑ์ที่เขียนไว้ แทนการปล่อยให้เป็นความรู้สึกร่วมของคนที่เหลืออยู่ในห้องตอนตีสอง

Cutover คือขั้นตอนที่ย้อนไม่ได้ ต้องมี runbook

cutover คือช่วงเวลาสั้นๆ ที่สลับจากระบบเก่าไประบบใหม่จริง หลายคนเข้าใจว่ามันคือการก็อปข้อมูลชุดสุดท้ายแล้วกดเปิดเครื่อง แต่จริงๆ มันคือลำดับงานหลายสิบขั้นที่ต้องทำตามคิว และบางขั้นเมื่อเริ่มไปแล้วย้อนกลับไม่ได้

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

ในลำดับนั้นมักมี freeze window ช่วงที่หยุดรับข้อมูลใหม่เข้าระบบเก่าชั่วคราว เพื่อไม่ให้มีรายการเกิดขึ้นหลังจากย้ายข้อมูลชุดสุดท้ายไปแล้ว การเลือกความยาวของ freeze window เป็น trade-off ที่ต้องคุยกันตรงๆ ยิ่งหยุดนาน ยิ่งย้ายและตรวจได้ละเอียด แต่ธุรกิจก็หยุดนานตามไปด้วย ยิ่งหยุดสั้น แรงกดดันด้านเวลายิ่งสูงและโอกาสพลาดยิ่งมาก หลายองค์กรจึงเลือกทำในสุดสัปดาห์หรือวันหยุดยาว ซึ่งมักเป็นช่วงที่ปริมาณธุรกรรมต่ำ

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

แผน rollback มีไว้ก่อนเริ่ม ไม่ใช่คิดตอนพลาด

ก่อนกดเริ่ม cutover ทีมต้องรู้อยู่แล้วว่าถ้าถึงจุดไหนจะถอยกลับไปใช้ระบบเก่า เงื่อนไขถอยควรเป็น no-go trigger ที่กำหนดเป็นตัวเลขหรือเหตุการณ์ชัดเจนไว้ล่วงหน้า เช่น ถ้าการตรวจข้อมูลไม่ผ่านเกินจำนวนที่ตกลงไว้ หรือถ้าเลยเวลาที่กำหนดแล้วยังโหลดข้อมูลไม่เสร็จ ให้ถอย การมีเงื่อนไขเขียนไว้ก่อนช่วยไม่ให้ต้องมานั่งเถียงกันตอนที่ทุกคนเหนื่อยและเหตุกำลังเกิด

สิ่งที่ทำให้ rollback ยากขึ้นทุกนาทีคือเวลา ยิ่งเปิดให้ผู้ใช้ทำรายการใหม่บนระบบใหม่ไปนานเท่าไร การถอยกลับยิ่งแพงเท่านั้น เพราะทุกรายการที่เกิดขึ้นหลังสลับต้องถูกตามเก็บกลับมาใส่ระบบเก่าให้ครบ ไม่งั้นข้อมูลช่วงนั้นจะหายไปเมื่อถอย คู่มือ Database migration: Concepts and principles (Part 2) ของ Google Cloud (ปรับปรุงล่าสุด 29 เมษายน 2025) อธิบาย fallback ว่าเป็นการย้ายข้อมูลในทิศกลับ และระบุว่าระบบที่เคยทำงานกับฐานข้อมูลเดิมต้องยังพร้อมใช้งานอยู่ จึงจะสลับกลับได้จริง

แผนถอยที่ดีจึงมีเส้นตายของตัวเอง มีจุดที่เรียกว่า point of no return ที่เมื่อเลยไปแล้ว ทางเลือกจะเหลือแค่แก้ปัญหาไปข้างหน้า ทีมควรรู้ล่วงหน้าว่าจุดนั้นอยู่ตรงไหน และตกลงกันว่าใครมีอำนาจประกาศถอยก่อนถึงจุดนั้น

ส่วนกรณีที่ระบบล่มแบบไม่ได้วางแผนหลังเปิดใช้ไปแล้ว บทบาทและการตัดสินใจตอนนั้นเป็นคนละโจทย์กับ rollback ที่เตรียมไว้ล่วงหน้า เรื่องว่าใครสั่งการและสื่อสารอย่างไรตอนระบบล่มจริง เราเขียนแยกไว้ใน DR Plan ที่รอดวันจริง

parallel run เมื่อไรคุ้ม เมื่อไรไม่คุ้ม

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

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

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

เขียนอะไรลง TOR ให้ได้ข้อมูลที่ใช้ได้จริง

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

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

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

ข้อสามคือกำหนดให้ส่งมอบ mapping doc หรือ data dictionary ที่บอกว่า field ไหนของระบบเก่าไปลงที่ไหนของระบบใหม่ และแปลงค่าด้วยกติกาอะไร เอกสารนี้คือสิ่งที่ทีมภายในต้องใช้ต่อในวันที่ผู้พัฒนาไม่อยู่แล้ว และเป็นหลักฐานเดียวที่อธิบายได้ว่าข้อมูลวันนี้มีที่มาอย่างไร

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

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

สรุป

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

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

หากองค์กรของคุณกำลังอยู่ในขั้นวางแผนเปลี่ยนระบบ หรือกำลังร่างขอบเขตงาน และอยากให้มีคนช่วยอ่านทบทวนแผน migration และ cutover ก่อนประกาศ เรายินดีคุยด้วย ติดต่อได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ไม่มีกำหนดเวลาบังคับ และหากคุยแล้วพบว่ายังไม่ถึงเวลาต้องเปลี่ยนระบบ เราจะบอกตรงๆ