코로케이션 전환을 준비하며 두 달 전에 만들어 둔 NCloud 서버 현황 문서를 다시 갱신하게 됐다. 바뀐 항목만 고치면 될 것으로 보고 df -h 디스크 사용률만 다시 재려고 했다.
Table of contents
Open Table of contents
증상 — 바뀐 것만 고치려던 계획
디스크만 재고 나머지는 그대로 두려다가 다른 항목도 한 번 확인해 봤다. 그랬더니 한 서버의 nproc 이 두 달 사이에 4에서 8로 늘어나 있었다.
누군가 증설을 해 놓고 문서에는 반영하지 않은 것이었다. 변경 기록이 없으니 그런 변경이 있었다는 사실 자체를 알 수 없었다.
판단 기준 — 무엇이 바뀌었는지 모르면 전부 재야 한다
바뀐 것만 고치려면 무엇이 바뀌었는지를 먼저 알고 있어야 한다. 그것을 모르는 상태에서 일부만 다시 재면 안 잰 항목은 옛 값 그대로 남아서 문서가 절반만 최신이 된다.
두 가지 방법이 있었다. 눈에 띄는 항목만 손으로 다시 재는 것과, nproc·free -m·df -h·uname -r·systemctl list-units 를 한 번에 뽑는 inventory.sh 를 만들어 전부 다시 재는 것이다. 뒤쪽을 골랐다. 이유는 돌려 보니 일 분이면 끝나서 재는 비용이 손으로 고르는 비용보다 낮아서다. 대신 스크립트가 서버마다 ssh 로 붙을 키 관리가 하나 더 생기는 것을 감수했다. 재는 비용이 낮으면 전부 다시 재는 쪽이 선택이 아니라 기본이 된다.
조치 — 자동으로 뽑을 것과 손으로 적을 것
사양과 사용률과 커널 판과 도는 서비스는 자동으로 뽑히지만 용도와 담당과 특이사항과 NCloud 계약 만료일은 그렇지 않다. 두 부분을 문서 안에서 나눠 뒀다.
자동 수집 부분은 돌릴 때마다 덮어쓰고 손으로 적은 부분은 그대로 남는다. 손으로 적는 부분을 자동 부분과 섞어 두면 갱신할 때마다 다시 옮겨 적게 된다.
잰 시각과 옛 문서
자동 수집 부분에 date -u 로 잰 시각을 함께 적었다. 이전 문서에는 그 시각이 없어서 언제 잰 값인지도 알 수 없었다.
덮어쓰지 않고 inventory-2020-10.md 처럼 달마다 새 파일로 남기니 diff 하나로 무엇이 바뀌었는지가 보였다. 파일이 작아서 남기는 부담이 거의 없었다.
차이 자체가 정보인 이유
문서와 실제가 다르다는 사실 자체가 신호였다. 아무도 모르는 변경이 있었다는 뜻이기 때문이다.
차이가 나면 왜 바뀌었는지 찾고 승인된 변경인지 확인한 뒤 기록에 남기는 순서를 뒀다. 한 번은 부하 시험하려고 ulimit 을 바꿔 놓고 되돌리지 않은 설정이 그렇게 드러났다.
정리
- 다시 확인할 때 옛 값을 그대로 쓰면 틀린다
- 무엇이 바뀌었는지 모르면 일부만 재도 문서가 절반만 최신이 된다
- 재는 비용이 낮으면 전부 다시 재는 것이 기본이 된다
- 재는 것을
inventory.sh로 두면 손으로 적지 않아도 된다 - 자동으로 뽑을 것과 손으로 적을 것을 문서 안에서 나눈다
- 잰 시각을 적어야 얼마나 낡았는지 알 수 있다
- 옛 문서를 남기면
diff만으로 변경이 드러난다 - 문서와 실제의 차이 자체가 모르는 변경을 찾는 수단이다