Skip to content
isdnetworks
Go back

마이그레이션이 두고 간 이력

패널티 이의신청을 처리해야 했고 판정 기준은 실제 중지나 품절 이력이 있는지 하나였다. 관리 화면에서 그 이력을 찾았는데 비어 있었다.

Table of contents

Open Table of contents

화면에 안 나오던 이력

상품 자체는 조회되는데 그 상품에 붙어 있어야 할 이력만 안 나왔다. 이유를 찾아보니 상품 구조를 신버전으로 옮길 때 이전 이력이 함께 안 옮겨졌다.

화면은 신버전 이력만 보여 주는데 이관 이전 기록은 옛 테이블에 그대로 남아 있었다. 데이터가 사라진 것이 아니라 보이는 자리에만 없는 상태였던 것이다.

한 번의 이관 누락이 만든 수작업

운영 쪽에서 화면으로 확인할 수 없으니 건마다 개발팀으로 문의가 넘어왔다. 결국 개발팀이 데이터를 직접 조회해서 판정하는 흐름이 굳어졌다.

원래는 화면을 보고 판정할 일이 데이터 접근 권한이 필요한 일이 돼 버렸다. 한 번의 이관 누락이 끝나지 않는 수작업으로 바뀐 것이고 그 비용은 이관 시점의 비용보다 훨씬 컸다.

데이터가 남아 있으면 자동화 여지가 있다

다행히 이전 이력이 지워지지는 않았고 옛 테이블에 그대로 보존돼 있었다. 그러면 한 번 옮기는 작업으로 판정이 다시 운영 화면으로 돌아간다.

지워졌다면 복구가 불가능해서 이 수작업이 영구적인 것이 됐을 것이다. 남아 있는지 아닌지가 근본 해결의 가능 여부를 갈랐다.

대상군에 따라 갈리는 문구

판정 말고도 확인할 것이 있었는데 반려 사유 문구가 대상군에 따라 달랐다. 일부 채널군은 우리가 그 채널의 정책을 대행해 적용하고 나머지는 채널이 직접 부과한다.

책임 주체가 다르므로 문구도 다르고 잘못 고르면 누가 부과한 것인지가 틀리게 전달된다. 어느 군인지를 먼저 보고 문구를 고르는 절차로 적었다.

규모로 판단한 실행과 잔여 분류

조회할 때 그 테이블에는 기본 키 외에 인덱스가 없어서 사유 컬럼으로 검색하면 전체를 훑게 된다. 다만 전체가 수천 건이라 그 규모에서는 문제가 없다고 보고 실행했다.

미처리 건을 연도별로 나눠서 세어 보니 오래 방치된 것이 상당수였다. 최근 건과 레거시를 나눠야 실제 처리 대상이 나왔고 증상 대응과 함께 이력 이관이라는 근본 해결을 같이 적었다.

정리


Share this post on:

Previous Post
프로필을 나누자 로그인까지 갈렸다
Next Post
뒤 클레임을 막은 앞 상태