การโยกย้ายข้อมูล - เป็นอันตรายหรือจำเป็น?


26

ฝ่ายพัฒนาซอฟต์แวร์ของ บริษัท ของฉันประสบปัญหาที่การโยกย้ายข้อมูลถือเป็นอันตรายโดยเฉพาะอย่างยิ่งสำหรับผู้จัดการของฉัน

พื้นหลังเป็นว่าลูกค้าของเราจะใช้ข้อมูลจำนวนมากที่มีคุณภาพไม่ดี เหตุผลในการนี้เป็นเพียงบางส่วนที่เกี่ยวข้องกับซอฟต์แวร์ของเราที่มีคุณภาพ แต่เพื่อความเป็นมาของข้อมูล: ส่วนใหญ่ของพวกเขาได้รับการอพยพออกจากระบบบรรพบุรุษข้อบกพร่องบางอย่างที่เกิด (ส่วนใหญ่เป็นธุรกิจ) ไม่สอดคล้องกันในบันทึกข้อมูลหรือmisentriesโดยอุบัติเหตุบน ด้านลูกค้า (ซึ่งซอฟต์แวร์ของเราอนุญาตโดยมีข้อผิดพลาด)

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

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

ฉันกำลังถามคุณ:

  • คุณคิดอย่างไรกับการย้ายข้อมูลโดยเฉพาะอย่างยิ่งในกรณีของชีวิตจริงและไม่เพียง แต่จากมุมมองของนักพัฒนาเท่านั้น
  • คุณมีข้อโต้แย้งต่อความคิดเห็นของผู้จัดการของฉันหรือไม่?
  • บริษัท ของคุณจัดการกับการย้ายข้อมูลและปัญหาที่เกิดจากพวกเขาอย่างไร
  • ความคิดที่น่าสนใจอื่น ๆ ซึ่งเป็นของหัวข้อนี้?

เป็นคำถามที่ดี แต่อาจเป็นของprogrammers.stackexchange.com
Tom Anderson

1
นั่นไม่จำเป็นต้องเป็นคำถาม "หรือ"
David Thornley

1
ข้อโต้แย้งเดียวที่ฉันต้องเพิ่มคือ: มันจะไม่ง่ายขึ้นในอนาคต หากพวกเขาไม่ต้องการดำเนินการโยกย้ายตอนนี้อย่างน้อยพวกเขาควรใช้โครงการ 'การล้างข้อมูล' เพื่อเขียนโค้ดบางอย่างเพื่อระบุบันทึกปัญหาในระบบที่มีอยู่
Michael Kohne

คำตอบ:


29

การย้ายข้อมูลคือขนมปังและเนยของฉันและการล้างข้อมูลเป็นเรื่องสำคัญอย่างยิ่ง กลยุทธ์หนึ่งที่เราใช้ทำการโยกย้าย 100% ของข้อมูลลูกค้าของเราคือการล้างข้อมูลแบบอะซิมโทติคเพื่อทำความสะอาดเครื่องมือล่วงหน้า

  1. ซึ่งหมายถึงการพัฒนาการตรวจสอบข้อมูลเป็นหมื่น (ส่วนใหญ่แบบสอบถาม SQL)

  2. การแลกเปลี่ยนเครื่องมือทำความสะอาดกับลูกค้า (เนื่องจากเป็นข้อมูลของเขาเราจึงออกแบบยูทิลิตี้การปะแก้เขาตรวจสอบและดำเนินการ)

  3. การปรับแต่งเครื่องมือมากกว่าการวนซ้ำและการเข้าถึงโดยเร็ว KPI ที่สนับสนุนคุณภาพที่วัดได้

  4. การตรวจสอบความสอดคล้องของข้อมูลหลังจากการโยกย้ายเกิดขึ้น สิ่งนี้ช่วยในการตัดสินใจ GO / NOGO ใน D-Day

ในที่สุดการย้ายข้อมูลเป็นแบบฝึกหัดที่มีประโยชน์อย่างมากที่ต้องเกิดขึ้นหลังจาก 3 ถึง 5 ปี

  1. ช่วยเพิ่มความสามารถของแพลตฟอร์มในการสนับสนุนธุรกิจ

  2. จะช่วยให้การปรับปรุงฐานข้อมูล

  3. มันเตรียมแพลตฟอร์มไอทีสำหรับเครื่องมือทางธุรกิจรุ่นต่อไป (ESB / EAI, พอร์ทัล, แพลตฟอร์มการดูแลตนเองรายงานและการขุดข้อมูลที่คุณตั้งชื่อ)

  4. มันจัดระเบียบข้อมูลกระแส DIY ระหว่างแพลตฟอร์มที่สะสมมานานหลายปีในวิธี "ชั่วคราว" ที่รวดเร็วและสกปรกเพื่อตอบสนอง "ข้อกำหนดเร่งด่วน"

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

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

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

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

ข้อพิจารณาข้างต้นตอบคำถามเพียงครึ่งเดียวที่ถามในชื่อ "การย้ายข้อมูล - อันตรายหรือจำเป็น" ใช่การย้ายข้อมูลเป็นสิ่งจำเป็น แต่พวกมันก็อันตรายเช่นกัน ในบัญชีนี้มีหลายสิ่งในไอทีที่เป็นอันตรายแล้ว ตามคำจำกัดความสิ่งที่เดิมพันสูงเป็นอันตราย โดยเฉพาะถ้าคุณไม่จริงจังกับเรื่องนี้ แต่นี่เป็นรูปแบบที่พบบ่อยที่สุดในไอที การไม่ใช้ศูนย์ข้อมูลหรือความพร้อมใช้งานสูงหรือการยอมรับจากภัยพิบัติเป็นสิ่งที่อันตราย
นั่นหมายความว่า บริษัท ทุกวันนี้ควรเลือกที่จะไม่ใช้เสาหลักของภูมิทัศน์เทคโนโลยีสารสนเทศในปัจจุบัน? ไม่แน่นอน!

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

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


5
ดังที่สะท้อนโดยคำตอบของ @ Alain หนึ่งในเหตุผลสำหรับแนวทางของผู้จัดการของคุณคือการโยกย้ายข้อมูลในตัวเองเป็นโครงการสำคัญที่มีความเสี่ยงทั้งหมดของผู้ดูแล นอกจากนี้ยังมีความเสี่ยงเฉพาะสำหรับการโยกย้ายข้อมูล - โครงการโยกย้ายข้อมูลเดียวที่ฉันเกี่ยวข้องกับการบรรลุอัตราความสำเร็จ 98.6% ในการล้างข้อมูล สิ่งนี้ฟังดูค่อนข้างดีจนกระทั่งมีใครรู้ว่าอัตราความล้มเหลวเหลือ 600,000 ระเบียนลูกค้าที่จะแก้ไขด้วยตนเอง สิ่งนี้เกี่ยวข้องกับการตั้งค่าแผนกแยกต่างหากและกระบวนการตรวจสอบและตรวจสอบความถูกต้อง อีกครั้งนี้ไม่ถูกหรือไม่มีความเสี่ยง

@ Chris เราตั้งเป้าหมายไว้ที่ 100% และฉันบรรลุเป้าหมายอย่างน้อยหนึ่งครั้ง เวลาส่วนใหญ่ที่ลูกค้าทิ้งไว้และสร้างใหม่ด้วยตนเองนั้นน้อยกว่าหนึ่งโหล

4
@Alain - ขอแสดงความยินดี โครงการที่ฉันอ้างถึงนั้นตั้งเป้าหมายไว้ที่ 100% แต่กลับกลายเป็นว่าไม่สามารถทำได้ ข้อมูลจำนวนมากที่ต้องใช้การล้างด้วยมือนั้นจำเป็นต้องมีการตรวจสอบแบบฟอร์มด้วยตนเอง "ของจอห์นสมิ ธ ทั้งสามที่เราบันทึกไว้ในที่อยู่นี้มีบุคคลที่แตกต่างกันกี่คน" การย้ายข้อมูลโดยเฉพาะนี้มาจากการที่ไม่ใช้ RDMS ไปยัง RDMS และข้อมูลการทำความสะอาดโดยนัยที่สะสมมานานถึง 25 ปี

2
และผู้เชี่ยวชาญควรเป็นผู้เชี่ยวชาญด้านการโยกย้ายข้อมูล (หรืออย่างน้อยก็ผู้เชี่ยวชาญด้านข้อมูล) ไม่ใช่โปรแกรมเมอร์แอปพลิเคชัน บริษัท ต่างๆประสบปัญหาเพราะพวกเขาขอให้มือสมัครเล่นข้อมูลทำสิ่งนี้มากกว่าผู้เชี่ยวชาญด้านข้อมูล สิ่งเดียวกันกับการออกแบบฐานข้อมูลมากเกินไป
HLGEM

1
ในฐานะที่เป็นแพลตฟอร์มที่กำลังพัฒนาจำเป็นต้องมี "การโยกย้าย" หรือการนำเข้าจำนวนมาก ในการเน้นย้ำถึงค่าใช้จ่ายสูงในการบำรุงรักษาโครงสร้างข้อมูลแบบดั้งเดิมและการขยาย infinium ของโฆษณา ข้อมูลที่ไม่ดีซึ่งกลายเป็นข้อมูลที่แย่กว่านั้นคือปัญหาบริบทที่เกิดขึ้นและเพิ่มมูลค่าลูกค้าอย่างมากเพราะตอนนี้พวกเขารู้แล้วด้วยความมั่นใจที่มากขึ้นว่าข้อมูลใดที่พวกเขาสามารถไว้ใจได้และสิ่งใดที่พวกเขาไม่สามารถทำได้ มันจะไม่สำคัญและจะมีค่าเป็นกลาง)
JustinC

5

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

ในความคิดของฉันมันไม่ใช่คำถามว่าจะทำการโยกย้ายข้อมูลหรือไม่มันเกี่ยวกับเวลาที่จะทำ ผู้จัดการของคุณมีจุดที่ถูกต้องอย่างแน่นอนโดยบอกว่าข้อมูลของคุณไม่ได้เป็นเพียงของคุณอีกต่อไปและลูกค้าปลายทางได้สร้างขั้นตอนการทำงานของพวกเขาแล้ว อย่างไรก็ตามรัฐนี้จะไม่เปลี่ยนแปลงในอนาคต ไม่ช้าก็เร็วคุณภาพของข้อมูลที่แย่จะกลายเป็นปัจจัยที่หลีกเลี่ยงไม่ได้ที่จะทำให้ธุรกิจของคุณช้าลงและคุณจะถูกบังคับให้ทำการโยกย้าย การทำเช่นนี้ภายใต้ความกดดันและด้วยกำหนดเวลาที่ จำกัด อาจนำไปสู่การตัดสินใจที่ไม่ดี นอกจากนี้ให้คิดถึงความเชี่ยวชาญที่คุณมีอยู่ในขณะนี้และจะมีในอีก 2-3 ปีข้างหน้า เกิดอะไรขึ้นถ้าคนที่เข้าใจข้อมูลของคุณจะออกจาก บริษัท ? คุณแน่ใจว่าเอกสารที่คุณมีเพียงพอหรือไม่

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


5

ฉันทำงานให้กับ บริษัท ประกันภัยและมีส่วนร่วมในการโยกย้ายข้อมูลสำหรับระบบหลัก มีอยู่ทั้งหมด 4 ครั้ง ดังนั้นที่นี่ความคิดเห็นของฉัน:

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

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

  1. การแมปข้อมูล แผนที่หลัก (และชุดค่าผสม) ไปยังระบบใหม่
  2. ล้างข้อมูล แผนที่ของข้อยกเว้นในข้อมูลนั่นคือข้อมูลที่มีการรวมกันถือว่าไม่ถูกต้องในระบบใหม่ หากเป็นไปได้ให้จัดการกับธุรกิจเพื่อแยกข้อมูลที่ไม่มีวิธีการแมปและอาจทำลายระบบใหม่และเตรียมวิธีแก้ปัญหา
  3. การโยกย้ายข้อมูลจริง เป็นกลยุทธ์มากมายในการโยกย้ายข้อมูล ตัวอย่างเช่น: บิ๊กแบงเพิ่มขึ้น
  4. การรวมรายงาน หากทั้งสองระบบทำงานในแบบคู่ขนานวิธีสร้างรายงานที่ถูกต้องและสอดคล้อง

เหตุการณ์ที่เกิดขึ้นด้วยแผนการที่รอบคอบ กองเรือรบพิเศษควรพร้อมที่จะจัดการกับปัญหาที่เกี่ยวข้องกับการย้ายถิ่น


1
ฉันทำงานด้านดาราศาสตร์เรามีข้อมูล (บนแผ่นถ่ายภาพ) ย้อนกลับไป 130 ปีทำให้เรามีปัญหา Y1.9K และ Y2K พร้อมกัน นอกจากนี้เรายังมีข้อมูลเกี่ยวกับเทปจากก่อนที่ผู้คนจะตกลงกันว่ามีบิตอยู่กี่ไบต์
Martin Beckett

3

1) คุณมีความคิดอย่างไรกับการโยกย้ายข้อมูลโดยเฉพาะอย่างยิ่งกรณีชีวิตจริงและไม่เพียง แต่จากมุมมองของนักพัฒนาเท่านั้น:

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

2) คุณมีข้อโต้แย้งต่อความคิดเห็นของผู้จัดการของฉันหรือไม่?

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

3) บริษัท ของคุณจัดการกับการย้ายข้อมูลและปัญหาที่เกิดจากพวกเขาอย่างไร

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

4: ความคิดที่น่าสนใจอื่น ๆ ซึ่งเป็นของหัวข้อนี้

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


2

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

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

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

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

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

กุญแจสำคัญในการโยกย้ายที่ประสบความสำเร็จคือการวางแผน ฉันพบว่าการวางแผน (ซึ่งรวมถึงการเขียนกรณีทดสอบและการทดสอบหน่วย) มักใช้เวลามากกว่าการพัฒนาจริง

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

กุญแจสำคัญอีกข้อหนึ่งในการย้ายข้อมูลที่ประสบความสำเร็จคือการปรับใช้ข้อมูลส่วนใหญ่และทดสอบในขณะที่ระบบเดิมยังคงทำงานอยู่ หากคุณกำลังย้ายบันทึกจำนวนมากอาจใช้เวลานานและการเปลี่ยนแปลงใหม่จะเกิดขึ้น ดังนั้นกระบวนการของคุณจะต้องสามารถดึงการเปลี่ยนแปลงข้อมูลหลังจากการโยกย้ายเริ่มต้นเช่นกัน อินสแตนซ์ของ SQL Server มีบางสิ่งที่เรียกว่า Change Data Capture ซึ่งสามารถช่วยได้ คุณสามารถสำรองข้อมูลของระบบเดิมและเปิดการจับข้อมูลการเปลี่ยนแปลงในเวลาเดียวกัน จากนั้นคุณสามารถโหลดการสำรองข้อมูลไปยังเซิร์ฟเวอร์การโยกย้ายของคุณทดสอบการโยกย้ายรับข้อมูลส่วนใหญ่ที่โหลดแล้วคุณจะต้องโหลดระเบียนที่มีการเปลี่ยนแปลงเท่านั้น เมื่อคุณโอนย้ายระเบียนสุดท้ายให้ปิดระบบต้นทางจนกว่าจะทำการโยกย้ายเสร็จ นี่คือเหตุผลหนึ่งในการโยกย้ายบันทึกส่วนใหญ่ล่วงหน้า ดังนั้นแอปพลิเคชันจะลดจำนวนเวลาอย่างน้อยที่สุด เลือกเวลาการโยกย้ายของคุณได้ดีอย่าปิดระบบเงินเดือนลงในวันที่พวกเขาควรดำเนินการกับเงินเดือนหรือส่ง W2s และทำในช่วงเวลาการใช้งานต่ำ หากคุณมีลูกค้าหลายรายคุณสามารถพิจารณาการย้ายระบบก่อนและตรวจสอบให้แน่ใจว่าทุกอย่างดีก่อนที่จะดำเนินการกับคนอื่น มันง่ายกว่ามากในการย้อนกลับข้อมูลของลูกค้าหนึ่งรายมากกว่า 10,000 หากมีปัญหา แต่วางแผนอย่างนี้ถ้าคุณทำ ข้อมูลมากกว่า 10,000 ถ้ามีปัญหา แต่วางแผนอย่างนี้ถ้าคุณทำ ข้อมูลมากกว่า 10,000 ถ้ามีปัญหา แต่วางแผนอย่างนี้ถ้าคุณทำ

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

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


1

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

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

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

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

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


1

มันเป็นความชั่วร้ายที่จำเป็น ฉันได้รับทั้งสองด้านและเหล่านี้เป็นปัญหาอื่น ๆ ที่ประกอบปัญหา

  1. โดยเฉพาะอย่างยิ่งในองค์กรเมื่อ comapnies ไปสู่ระบบใหม่พวกเขาต้องการให้มันทำทุกสิ่งที่ระบบเก่าทำ พวกเขาไม่ตรวจสอบขั้นตอนของพวกเขา พวกเขารู้สึกหนักใจมากที่พวกเขาต้องการทำทุกอย่างในแบบเดียวกัน ปลอดภัยสำหรับพวกเขา
  2. พวกเขาไม่ต้องใช้เวลาในการเรียนรู้ระบบใหม่หรือจ้างคนที่มีความเชี่ยวชาญ
  3. พวกเขาต้องการปรับแต่งระบบใหม่เพื่อรองรับ # 1 หรือเพื่อจัดการกับมุมมองใหม่ของธุรกิจของพวกเขา ใหม่การปรับแต่งระบบ X การแปลงข้อมูล X = ภาวะแทรกซ้อนที่รวมกันแล้ว
  4. มีเวลาไม่เพียงพอในการทดสอบ
  5. ลูกค้าเกลียดการทำงานแบบขนาน / ทำสองครั้ง ไม่สามารถตำหนิผู้ใช้เนื่องจากพวกเขาไม่ได้ให้เวลาในการทำเช่นนี้เนื่องจากหน้าที่อื่น ๆ ทั้งหมดของพวกเขาถูกเก็บไว้อย่างเต็มที่

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


0

คุณคิดอย่างไรกับการย้ายข้อมูลโดยเฉพาะอย่างยิ่งในกรณีของชีวิตจริงและไม่เพียง แต่จากมุมมองของนักพัฒนาเท่านั้น

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

คุณมีข้อโต้แย้งต่อความคิดเห็นของผู้จัดการของฉันหรือไม่?

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

บริษัท ของคุณจัดการกับการย้ายข้อมูลและปัญหาที่เกิดจากพวกเขาอย่างไร

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

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

เรากำลังใช้ ruby ​​กับรางซึ่งให้เวอร์ชันของการโยกย้ายข้อมูลการอัพเกรดและการย้อนกลับ ซึ่งทำให้ชีวิตของเราง่ายขึ้น

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

ความคิดที่น่าสนใจอื่น ๆ ซึ่งเป็นของหัวข้อนี้?

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

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

หวังว่ามันจะช่วย


-1

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

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

รางวัลที่ผู้จัดการของคุณคาดหวังว่าจะได้รับนั้นดีกว่ามากเนื่องจากค่าใช้จ่ายในการโยกย้าย


ฉันหวังว่าคุณจะไม่ได้เข้าโรงพยาบาล: ทำไมเรามีบันทึกผู้ป่วยสำหรับเด็กทารกเท่านั้น? เราติดตั้งระบบใหม่เมื่อปีที่แล้วและมันยากเกินไปที่จะโยกย้ายข้อมูลเก่าทั้งหมดดังนั้นเราจึงใส่ผู้ป่วยรายใหม่ลงไปเท่านั้น!
Martin Beckett

ไม่ฉันไม่มีโรงพยาบาล อ่านสิ่งที่ฉันพูดอีกครั้ง "The reward your managers hope to realize had better be extremely high given the cost of the migration." หากรางวัลสูง - อะไรก็ตามที่เป็นไปได้ - มันก็คุ้มค่า มิฉะนั้นจะเป็นการเสียเวลาของทุกคนและความเสี่ยงที่ไม่จำเป็น นอกจากนี้ฉันได้กล่าวถึงคำตอบของฉันว่าการรวมสามารถทำได้เพื่ออนุญาตให้ระบบใหม่เข้าถึงข้อมูลเก่าในบางกรณี แต่การตัดสินใจครั้งนี้ขึ้นอยู่กับสถานการณ์ทั้งหมด
jmort253

ฉันขอโทษ แต่การรวมเพียงแค่รวบรวมความเศร้าโศก
พอลนาธาน

@Paul - แน่นอน แต่มีการย้ายข้อมูล ไม่มี bullet เงินที่นี่
jmort253
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.