운영 데이터를 고치기 전에 확인하는 것들

운영 데이터를 직접 고쳐야 할 때가 있고 코드로 안 되거나 화면에 그 기능이 없을 때가 그렇다. 몇 번 잘못 건드리고 나서 실행 전에 확인할 순서를 만들었다.

Open Table of contents

대상을 고른 방식

가장 크게 틀렸던 자리가 대상 선정이었다. 상태값으로 대상을 잡았더니 수천 건이 나왔는데 실제로 이번 문제에 해당하는 것은 몇 건이었고 나머지는 몇 해에 걸친 정상 처리분이었다.

상태값은 지금 그렇다는 것만 말하고 왜 언제 그렇게 됐는지를 담지 않는다. 그래서 그 문제가 만든 기록으로 대상을 잡고 시간 범위로 좁힌 뒤에 현재 상태를 역으로 확인하는 순서로 바꿨다.

화면이나 배치가 하는 일을 질의로 재현할 때 같아 보이는데 다르게 동작하는 경우가 있었다. 코드에서 목록에 없으면 통과시키던 조건을 질의의 부정 조건으로 옮겼는데 그 컬럼에 빈 값이 많았다.

코드에서는 빈 값이 목록에 없으니 통과하는데 질의에서는 비교 결과가 참도 거짓도 아니라 행이 버려진다. 정반대로 동작해서 대상의 상당수가 조용히 빠졌으므로 재현 질의는 원본이 통과시키는 건수와 맞춰 본다.

큰 테이블을 건드리기 전에 실행 계획으로 접근 방식과 사용 인덱스와 예상 행 수를 본다. 이것을 안 보고 돌렸다가 데이터베이스를 멈춘 적이 있다.

예상 행 수는 추정치이므로 조건에 맞는 실제 건수를 따로 세어 본다. 그 값이 예상과 크게 다르면 조건을 잘못 이해한 것이다.

고치기 전에 고칠 대상의 고칠 컬럼만 남겨 두면 가볍고 되돌리기도 쉽다. 여기서 중요한 것은 백업의 범위가 실제 영향 범위와 같아야 한다는 점이다.

스크립트를 재사용하면서 인자만 바꿨는데 안에 다른 조건이 하드코딩돼 있어서 백업은 인자 기준이고 수정은 하드코딩 기준으로 돌아 범위가 어긋난 적이 있다. 재사용할 때는 인자만이 아니라 본문의 값까지 함께 확인한다.

전체를 한 번에 돌리지 않고 몇 건만 먼저 하고 결과를 본다. 이때 바꾼 값만 보지 않고 관련 테이블과 새로 생긴 작업과 외부로 나간 호출까지 함께 본다.

명령이 성공했다는 것이 의도대로 됐다는 뜻이 아니므로 반환값이 아니라 다시 조회해서 센다. 바뀌지 말아야 할 것이 안 바뀌었는지도 함께 확인한다.