데이터 마이그레이션-위험 또는 필수?

우리 회사의 소프트웨어 개발 부서는 데이터 마이그레이션이 특히 관리자에게 잠재적으로 위험한 것으로 간주되는 문제에 직면하고 있습니다.

배경은 고객이 품질 이 좋지 않은 대량의 데이터를 사용하고 있다는 것 입니다. 그 이유는 소프트웨어 품질 과 부분적으로 만 관련 이있는 것이 아니라 데이터 기록과 관련이 있습니다. 대부분은 이전 시스템 에서 마이 그 레이션 되었습니다 . 일부 버그로 인해 데이터 레코드 또는 실수로 인해 데이터 레코드의 불일치 가 발생했습니다. 고객 측 (우리 소프트웨어가 오류로 허용 한).

관리자의 가장 중요한 반론은 잘못된 데이터가 더 나쁜 데이터로 변할 수 있고, 데이터 문제 로 인해 고객의 일부 관리자 가 깨어날 수 있으며, 고객 측의 일부 프로세스는 시스템에 다소 적응되어 더 이상 작동하지 않을 수 있다는 것입니다.

개인적으로 데이터 마이그레이션은 소프트웨어 개발 의 핵심 부분 으로 간주되며 리팩토링이 코딩하는 데이터를 데이터 마이그레이션으로 볼 수 있습니다. 데이터 마이그레이션은 진화하는 소프트웨어를 만드는 데 필수적 이라고 생각 합니다 . 그것 없이는 우리는 나쁜 데이터 구조를 해결하는 고통스러운 소프트웨어를 만들어야합니다.

나는 당신에게 묻고 있습니다 :

• 데이터 마이그레이션에 대한 생각, 특히 개발자의 관점뿐만 아니라 실제 사례에 대해 어떻게 생각하십니까?
• 관리자의 의견에 반대되는 주장이 있습니까?
• 귀사는 데이터 마이그레이션과 그로 인한 어려움을 어떻게 처리합니까?
• 이 주제에 속하는 다른 흥미로운 생각?

데이터 마이그레이션은 제 빵과 버터이며 데이터 정리는 실제로 매우 중요한 문제입니다. 우리가 사용하는 전략 중 하나는 고객 데이터의 100 %를 마이그레이션하는 점근선 데이터 정리 사전 마이그레이션 도구입니다.

1. 이는 수십 개의 데이터 무결성 검사 (대부분 SQL 쿼리)를 개발하는 것을 의미합니다.

2. 고객과 청소 도구 교환 (그의 데이터이므로 패치 유틸리티를 디자인하고 유효성을 검사하고 실행합니다).

3. 반복을 통해 도구를 수정하고 KPI 지원 측정 가능한 품질에 도달합니다.

4. 마이그레이션이 발생한 후 데이터 일관성 확인 이를 통해 D-Day에서 GO / NOGO 결정을 내릴 수 있습니다.

결국 데이터 마이그레이션은 3 년에서 5 년 후에 수행해야하는 매우 유익한 운동입니다.

1. 플랫폼의 비즈니스 지원 능력을 향상시킬 수 있습니다.

2. 데이터베이스를 간소화 할 수 있습니다.

3. 차세대 비즈니스 툴 (ESB / EAI, 포털, 셀프 케어 플랫폼,보고 및 데이터 마이닝 등)을위한 IT 플랫폼을 준비합니다.

4. 그것은 "긴급한 요구 사항"을 충족시키기 위해 빠르고 임시적인 "일시적인"방식으로 수년에 걸쳐 축적 된 플랫폼 간의 DIY 데이터 흐름을 재구성합니다.

5. 무엇보다 플랫폼을 더 잘 알고 '할 수있는'태도를 키우는 IT 프로덕션 팀에 힘을 실어줍니다. 이러한 종류의 이점은 측정하기 어렵지만 많은 고객을 알게되면 이러한 고려 사항이 분명해집니다. 마이그레이션을 거부하는 기업은 다음 단계에 머물러 있고 대담한 기업이 주도권을 잡고 있습니다.

집의 지하실이 재목으로 뒤섞 일 때와 약간 비슷합니다. 어느 날 아침, 모든 것을 꺼내서 필요한 것만 빼고 나머지는 버려야합니다. 그 후, 당신은 지하실을 다시 사용할 수 있습니다 ;-)

또 다른 근본적인 고려 사항은 "고객이 항상 더 까다로워하는 것처럼"오늘날 고객의 기대는 항상 움직이고 있다는 것입니다. 따라서 시장 점유율을 높이려는 분명한 의도로 이러한 새로운 트렌드를 모색 할 때 특정 회사의 경쟁 업체가 항상 상당 부분을 차지하게됩니다. 그들이하는 방식은 트렌드를 고수하거나 트렌드를 주도하도록 오퍼링을 조정하는 것이며, 지속적인 비즈니스 리엔지니어링이 수반됩니다. IT 플랫폼이 너무 단단하면 자신의 시장 트렌드를 배우자 또는 선행하고 궁극적으로 자신의 시장 점유율을 유지하기 위해 자신의 적성을 끌 수 있습니다. 다시 말해, 움직이는 시장 관성에서 관련성이없는 레시피입니다.

대조적으로, 새로운 시스템으로의 데이터 마이그레이션은보다 현대적이고 다양한 생산성 도구를 출시하여 직원들에게 더욱 매력적인 최신 기술을 제공함으로써 회사의 내부 혁신 프로세스를 지원하거나 이끄는 데 기여할 것입니다 이에 따라 상대 시장 점유율을 확보 또는 증가시킵니다.

위의 고려 사항은 실제로 "데이터 마이그레이션-위험 또는 필수"라는 제목의 질문 중 절반에 대해서만 답변합니다. 예 데이터 마이그레이션이 있다 필수하지만은 또한 위험? 이 때문에 IT의 많은 것들이 위험합니다. 말 그대로 스테이크가 높은 것은 위험합니다. 특히 문제를 심각하게 다루지 않는 경우. 그러나 이것은 실제로 IT에서 가장 일반적인 패턴 입니다. 심각하게 데이터 센터 또는 고 가용성 또는 재난 복구를 고려하지 않는 것은 입니다 위험.
그것은 오늘날의 회사가 오늘날의 정보 기술 환경의 기둥을 선택하지 않아야한다는 것을 의미합니까? 분명히 아니다 !

농담으로 포인트를 만들기 위해 "전문가가 만든 비행기를 사용하지 않으면 비행이 위험하다"고 주장 할 수 있습니다. 데이터 마이그레이션과 동일합니다. 전문가가 실행하고 수행 할 때 잘 설계되고 잘 운영되는 비행기에서 비행하는 것보다 더 위험하지 않습니다. ROI는 지상 교통 수단과 동일한 비율입니다.
전문가에게 맡기면 대부분의 마이그레이션은 잘 통제 된 성공이며 실패 + 포기 율은 매우 낮습니다.

귀하의 관리자는 스스로에게 물어 주도해야한다 "대부분의 기업 만들 것입니다 무엇을 성공적으로 데이터 마이그레이션 프로젝트를 통해 이동하는 동안 우리 가 대신 오류가 발생할 것이라고 때문에 다른 회사? 그것은 하나없이 잘 지낼 수 있을까?"

Alain은 성공적인 데이터 마이그레이션 프로젝트를위한 데이터 정리의 중요성과 데이터 마이그레이션 수행에 대한 근거에 대해 큰 대답을했습니다. 관리자의 특정 관심사 만 타겟팅하고 싶습니다.

내 의견으로는 데이터 마이그레이션을 수행할지 여부는 문제가 아니며 언제 해야하는지에 관한 것입니다. 귀하의 관리자는 귀하의 데이터가 더 이상 귀하의 데이터가 아니며 최종 고객이 이미 그 주위에 절차를 구축했음을 분명히 지적합니다. 그러나이 상태는 나중에 변경되지 않습니다 . 조만간 나쁜 데이터 품질은 비즈니스 속도 저하의 불가피한 요소가되어 마이그레이션을 수행해야합니다. 압력이 가해지고 마감 시간이 촉박 한 상황에서이를 수행하면 차선책이 될 수 있습니다. 또한 현재 가지고 있고 앞으로 2-3 년 동안 보유 할 전문 지식에 대해 생각해보십시오. 데이터를 이해하는 사람들이 회사를 떠날 경우 어떻게해야합니까? 가지고있는 문서가 충분합니까?

아마도 지금 마이그레이션을 수행 할 필요는 없지만 관리자는 최소한 마이그레이션을 정확히 수행 할 시점에 대한 비전을 가지고 있어야합니다.

저는 보험 회사에서 일했으며 핵심 시스템의 데이터 마이그레이션에 참여했습니다. 글쎄, 총 4 번 있었다. 그래서 여기 내 의견 :

필자의 경우 데이터 마이그레이션은 필수 조건입니다. 규정에 따라 데이터를 10 년 이상 유지해야하며 장기적으로 이중 시스템을 지원할 여유가 없습니다. 다른 이유는 사용자가 새 응용 프로그램으로 작업을 계속할 수 있기를 기대하기 때문입니다. 그들이 일하는 아이템을 찾을 수 없다면, 당신의 응용 프로그램은 나쁘고 데이터가 정확하지 않을 때 더 나빠집니다.

글쎄, 데이터 마이그레이션은 끔찍한 짐승이며 실제 상황이므로 직면하십시오. 위험하지만 조기에 신중하게 처리하여 최소화 할 수 있습니다. 참고로, 데이터 마이그레이션에서 고려해야 할 4 가지 큰 프로세스가 있습니다.

1. 데이터 매핑. 새로운 시스템에 대한 마스터 (및 그 조합) 맵
2. 데이터 정리 데이터, 즉 새 시스템에서 조합이 유효하지 않은 것으로 간주되는 데이터의 예외 맵. 가능한 경우 비즈니스와 거래하여 매핑 할 방법이없는 데이터를 제외하고 잠재적으로 새 시스템을 중단하고 해결 방법을 준비하십시오.
3. 실제 데이터 마이그레이션. 데이터 마이그레이션을 수행하기위한 많은 전략이 있습니다. 예 : 빅뱅, 증분
4. 통합보고. 두 시스템이 동시에 실행되어야한다면 정확하고 일관된 보고서를 작성하는 방법

신중한 계획으로 이벤트, 똥이 발생합니다! 마이그레이션과 관련된 문제를 처리 할 수있는 특수한 태스크 포스 팀이 준비되어 있어야합니다.

1) 개발자의 관점뿐만 아니라 실제 사례에 대한 데이터 마이그레이션에 대한 귀하의 생각은 무엇입니까? :

마이그레이션은 시스템 개발의 필수 요소입니다. 이전 시스템을 부분적으로 또는 전체적으로 교체하는 경우 마이그레이션은 경영진이 원하든 원하지 않든 사실입니다. 기존 데이터가 나쁜 경우 새 시스템에 잘못 반영됩니다. 따라서 좋은 마이그레이션 전략을 세우는 것이 매우 중요합니다.

2) 관리자의 의견에 반대하는 주장이 있습니까?

예, 마이그레이션은 위험하지만 인생의 사실이기도하므로 처리하십시오. 그리고 가능한 빨리 처리하십시오.

3) 귀사는 데이터 마이그레이션과 그로 인한 어려움을 어떻게 처리합니까?

우리 회사는 성공을 거두면서 고객의 마이그레이션 프로세스에 적극적으로 참여했습니다. 프로젝트의 초기 단계에서 기존 데이터를 최대한 검토하고 마이그레이션을 시작하기 전에 고객이 데이터 품질을 개선하도록 권장합니다. 때때로 우리는 실제로 그것을 요구합니다.

4 :이 주제에 속하는 다른 흥미로운 생각

필자는 마이그레이션 프로세스를 변환 및 데이터 정리라는 두 단계로 나누는 것이 좋습니다. 변환은 상당히 직설적입니다. 기존 시스템 객체를 새 시스템에 매핑합니다. 반면에 데이터 정리는 매우 까다로울 수 있습니다 (위에서 언급 한 것처럼). 고객을 최대한 많이 참여시키고 가능한 빨리 프로세스를 시작하십시오. 잘못된 데이터는 새로운 시스템에 잘못 반영 될 수 있으며 때로는 이유없이 완전히 반영되지 않습니다. 새 시스템이 작동하지 않으면 고객은 이전 시스템에서 제대로 작동하는 것처럼 보이는 데이터를 탓하지 않습니다.

마이그레이션하려는 데이터가 현재 불량한 경우 마이그레이션 수행 여부에 관계없이 수정해야합니다. 나쁜 데이터 = 쓸모없는 데이터.

마이그레이션은 위험하므로 사실입니다. 그러나 모든 주요 IT 프로젝트도 마찬가지입니다. 위험을 완화 할 수있는 방법이 있으며 마이그레이션에서 미리 계획해야합니다.

첫째, 항상 시스템을 현재 상태로 되돌릴 수있는 방법이 있어야합니다. 두 번째 마이그레이션은 마이그레이션 전용으로 설정된 테스트 서버에서 수행해야합니다. 먼저 테스트하지 않고 마이그레이션을 수행하는 것은 어리석은 일입니다. 셋째, 마이그레이션을위한 모든 코드는 소스 제어에 있어야합니다.

넷째, 마이그레이션을 시작하기 전에 요구 사항 및 테스트 계획이 필요합니다. 이전 시스템에 1,293,687 개의 레코드가있는 경우 새 시스템에서 동일한 레코드를 가지고 있거나 레코드가 어디로 갔는지 (예외 테이블로) 알고 있어야합니다. 비정규 화 된 구성표를 정규화하는 경우 시작하기 전에 끝내야하는 레코드 수를 계산 한 다음 확인해야합니다. 한 시스템에서 다른 시스템으로의 맵핑을 지정하는 문서가 필요합니다. 이를 통해 품질 관리 담당자가 데이터가 올바른 위치로 이동했는지 확인할 수 있습니다.

현재 불량 데이터를 처리하는 방법을 결정해야합니다. 정리할 수있는 것, '알 수 없음'이라고 표시된 필수 필드에 값이 필요한 것, 예외 테이블에 던져야 할 것, 사용자 그룹의 수동 개입이 필요한 것 (이 두 사람이 실제로 dup인지 또는 예를 들어 같은 실습에서 두 명의 의사가 있고 두 레코드가 다를 때 선택할 데이터가 dup 인 경우 등).

성공적인 마이그레이션의 핵심은 계획입니다. 계획 (테스트 사례 및 단위 테스트 작성 포함)은 일반적으로 실제 개발보다 시간이 더 걸린다는 것을 알았습니다.

성공적인 데이터 마이그레이션의 다음 열쇠는 QA입니다. 출시 전날 QA 팀에 던질 프로젝트가 아닙니다. QA에서 문제가 있다고 말하면 시작할 프로젝트가 아닙니다.

성공적인 마이그레이션의 또 다른 열쇠는 원래 시스템이 계속 실행되는 동안 대부분의 데이터를 배포하고 테스트하는 것입니다. 많은 레코드를 이동하는 경우 시간이 오래 걸리고 새로운 변경 사항이 발생합니다. 따라서 마이그레이션이 시작된 후에도 프로세스에서 데이터 변경 사항을 가져올 수 있어야합니다. 예를 들어 SQL Server에는 Change Data Capture라는 것이 있는데이를 도와 줄 수 있습니다. 원래 시스템의 백업을 수행하고 동시에 변경 데이터 캡처를 켤 수 있습니다. 그런 다음 백업을 마이그레이션 서버로 다시 배치하고 마이그레이션을 테스트하고 대부분의 데이터를로드 한 다음 변경된 레코드 만로드하면됩니다. 최종 레코드를 마이그레이션 할 때 마이그레이션이 완료 될 때까지 소스 시스템을 끄십시오. 이것이 대부분의 레코드를 미리 마이그레이션하는 이유 중 하나입니다. 따라서 응용 프로그램의 시간이 가장 짧습니다. 이주 시간을 잘 선택하고 급여를 처리하거나 W2를 발송해야하는 날에 급여 시스템을 종료하지 마십시오. 그리고 낮은 사용 시간 동안 수행하십시오. 클라이언트가 여러 명인 경우 먼저 하나를 마이그레이션하고 다른 클라이언트를 수행하기 전에 모든 것이 올바른지 확인하는 것이 좋습니다. 문제가있는 경우 한 고객의 데이터를 10000보다 롤백하는 것이 훨씬 쉽습니다. 하지만 그렇게하면 신중하게 계획하십시오. 문제점이있는 경우 10000보다 큰 데이터. 하지만 그렇게하면 신중하게 계획하십시오. 문제점이있는 경우 10000보다 큰 데이터. 하지만 그렇게하면 신중하게 계획하십시오.

마이그레이션에 새로운 사용자 인터페이스가 포함 된 경우 실제 사용자가 마이그레이션 테스트의 일부로 사용하도록하십시오. 그런 다음 라이브하기 전에 다른 사용자를 교육하십시오 (그러나 라이브하기 전에 일주일도 채 걸리지 않으면 잊어 버리게됩니다). 테스트에 참여한 사용자가 교육을 설계하는 데 도움을주고, 질문에 대한 질문과 사람들이 어떤 순서로 알아야 하는지를 알고 있습니다. 사용자가 레코드를 입력 할 때 일반적으로 해당 데이터가없는 경우 도움이되지 않아야한다고 생각하므로 필수 입력 필드를 작성하십시오. 그들은 그렇지 않으면 데이터를 얻을 수 없기 때문에 새로 필요한 필드에 정크를 넣을 것입니다.

현재 데이터에 어떤 문제가 있는지 살펴보십시오. 향후에 이것이 나쁜 것을 피하기 위해 외래 키, 제약 조건, 트리거, 응용 프로그램의 비즈니스 규칙, 기본값 등을 추가 할 수 있습니까? 불량 데이터를 정리할 때 향후에도 이와 같이 불량 데이터가 들어오는 것을 방지 할 수있는 방법을 만들어야합니다. 불량 데이터가 할당 된 이유를 분석하고 설계의 허점을 수정하십시오.

데이터 마이그레이션이 필요합니다. 데이터 마이그레이션이 없으면 종종 발전 할 수 없습니다. 필자는 이전 시스템에서만 사용 가능한 필수 이력으로 작업 한 많은 시스템입니다. 마이그레이션은이 작업을 수행 할 수있는 유일한 실용적인 방법입니다. 데이터 품질은 종종 문제입니다. 일반적으로 이것은 이전 시스템에서 처리해야합니다. 품질을 회복하려면 데이터를 변경해야 할 수도 있습니다.

내가 작업 한 다른 시스템은 다른 시스템의 데이터에 의존했습니다. 이것은 다르지만 중요한 문제입니다. 경우에 따라 데이터를 완전히 대체 할 수 있습니다. 새 데이터에 포함 된 변경 사항을 기존 세트에 병합하여 다른 경우를보다 잘 처리 할 수 ​​있습니다. 이러한 유형의 마이그레이션에는 수신 피드에 대한 유효성 검사가 포함되어야합니다.

기존 데이터의 유효성을 검사하고 정리하는 기능은 시스템의 중요한 기능이 될 수 있습니다. 이는 마이그레이션과 무관합니다. 시스템이 통제 할 수없는 데이터를 수정하는 메커니즘이 종종 있습니다. 이로 인해 데이터가 유효하지 않을 수 있습니다. 다른 데이터 문제는 응용 프로그램의 버그로 인해 발생합니다. 유효성 검사 루틴을 정기적으로 실행하면 문제를 식별하고 마이그레이션하기 전에 데이터를 정리할 수 있습니다. 앞서 언급했듯이 데이터를 조기에 정리하면 마이그레이션이 더 쉬워 질 수 있습니다.

일부 유효성 검사는 시간에 민감하므로 수정되지 않은 데이터에는 적용하지 않아야합니다. 이것은 코드가 폐기 된 코드화 된 값에서 일반적입니다. 유효성 검사 오류를 유발하지 않고 레코드의 다른 필드를 변경할 수 있어야합니다. 따라서 유효성 검사 전에 변경된 필드를 식별해야하기 때문에 업데이트 유효성 검사가 더 복잡해질 수 있습니다. 교차 필드 유효성 검사가 더 복잡 할 수도 있습니다. 이 경우 유효성 검사를 피할 수 있으므로 일부 레코드를 읽기 전용으로 처리하는 기능이 도움이 될 수 있습니다.

내가 작업 한 하나의 시스템에서 고객이 새 시스템을 부분적으로 거부했습니다. 그들은 새로운 데이터 입력 모듈의 사용을 거부했다. 그러나 새로운 시스템에서 배치 처리를 원했습니다. 솔루션은 배치 실행 전에 매일 밤 데이터를 마이그레이션하는 것이 었습니다.

필요한 악이다. 나는 양쪽 끝에 있었고 이것들은 문제를 복잡하게 만드는 다른 문제 중 일부입니다.

1. 특히 기업에서는 회사가 새로운 시스템으로 갈 때 기존 시스템이하는 모든 일을하기를 원합니다. 그들은 그들의 절차를 검토하지 않습니다. 그들은 너무 압도되어 모든 것을 똑같은 방식으로 계속하고 싶어합니다. 이것은 그들에게 안전합니다.
2. 그들은 새로운 시스템을 배우거나 전문 지식을 가진 사람들을 고용하는 데 시간이 걸리지 않습니다.
3. 그들은 새로운 시스템을 커스터마이징하여 # 1을 수용하거나 비즈니스의 새로운 측면을 처리하려고합니다. 새로운 시스템 X 사용자 정의 X 변환 된 데이터 = 복합 합병증
4. 테스트 시간이 충분하지 않습니다.
5. 고객은 병렬로 실행하는 것을 싫어합니다. 다른 모든 업무가 본격적으로 이루어지기 때문에이 작업을 수행 할 시간이 없기 때문에 사용자를 비난 할 수 없습니다.

관리자가 데이터를 변환하지 않음으로써 판매 손실을 정당화 할 수 있다면 더 많은 힘을 얻을 수 있습니다. 고객이 모든 데이터 변환에 실패했다고 말하면 작동하지 않을 것입니다.

데이터 마이그레이션에 대한 생각, 특히 개발자의 관점뿐만 아니라 실제 사례에 대해 어떻게 생각하십니까?

소프트웨어는 정기적으로 업그레이드해야합니다. 마이그레이션을 저장하려면 백업 및 테스트가 필요합니다.

관리자의 의견에 반대되는 주장이 있습니까?

그는 그것이 위험하다는 것이 옳습니다. 그러나 덜 위험하게 만드는 기술을 적용 할 수 있습니다.

귀사는 데이터 마이그레이션과 그로 인한 어려움을 어떻게 처리합니까?

프로덕션 환경에 배포하기 전에 매일 백업, 증분 백업, 백업이 있습니다. 적어도 나쁜 일이 발생하면 롤백 할 수 있습니다.

테스트 환경, 자동화 된 테스트 및 일일 빌드 서버가 있습니다. 또한 주요 작동 및 기능이 올바르게 작동하는지 확인하기위한 연기 테스트 절차. 개발자, QA 및 사용자가 데이터를 마이그레이션 한 빌드를 테스트해야합니다.

우리는 루비 온 레일을 사용하여 데이터 마이그레이션, 업그레이드 및 롤백의 버전을 제공합니다. 우리 삶을 더 편하게 만듭니다

우리는 코드 업데이트 및 데이터 마이그레이션을 수행하기 위해 capistrano를 사용하고 있습니다. 마이그레이션을 자동화되고 단순하게 유지하는 것이 프로덕션 시스템이 작동하도록하는 핵심 요소 중 하나입니다.

이 주제에 속하는 다른 흥미로운 생각?

데이터 마이그레이션과 관련된 또 다른 문제는 코드 업그레이드 및 데이터 마이그레이션의 일관성입니다. 제 경우에는 다시 자동화 된 방법으로 처리하고 있습니다. 항상 롤백 할 준비가되었습니다.

데이터 마이그레이션을 수동으로 실행하면 데이터베이스가 알 수없는 상태가 될 수 있습니다. 다른 서버 환경간에 데이터 마이그레이션 버전을 비교하기는 어렵습니다.

도움이되기를 바랍니다.

시간과 투자 및 위험이 모두 너무 높기 때문에 기존 레거시 시스템에서 데이터를 마이그레이션하는 데 시간을 낭비하지 않습니다. 우리는 새로운 시스템으로 나아가고 필요할 때 통합합니다.

모든 비즈니스에는 지원해야하는 레거시 시스템의 형태가 있으며 이는 정상적인 비즈니스 비용입니다.

관리자가 실현하고자하는 보상은 마이그레이션 비용을 감안할 때 매우 높았습니다.