🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 문제: 긴급 처리가 반복되며 배포 DB 변경 절차가 지켜지지 않아 DB 환경 간 불일치 · DDL 누락으로 혼란 발생.
- 목표: DDL 누락 방지와 DB 환경 간 일관성 확보.
- 담당: 본인이 배포 DB 담당으로서 정책을 수립·운영.
1왜 필요했나
긴급 처리가 반복되면서 정해진 배포 DB 변경 절차가 무너졌다. 변경이 절차 밖에서 임의로 진행되거나 일부 환경에 누락되어, 마스터 DB와 배포 DB, 그리고 하류 환경 간 형상이 어긋났다. → 사람의 주의력이 아니라 정책·권한 분리로 강제해야 했다.
2역할·권한 정의
DB별로 역할과 권한을 명확히 정의해, 단일 담당자가 변경을 끝까지 임의로 처리하지 못하게 했다.
| 역할 | 책임 |
|---|
| DB 정의 변경 최종 권한 | 스키마(DB 정의) 변경의 최종 승인 |
| DDL 실행 담당 | 승인된 변경의 DDL 실제 실행 |
| 테스트(검증) 관리 | 변경 검증 절차 관리 |
| 초기설치본 형상 유지 | 초기설치본과 동일한 DB 형상 유지 |
| 배포 데이터 일관성 | 배포 DB 데이터의 일관성 책임 |
3변경 반영 흐름
- DB 변경 요청 접수
- 검토 · 승인 (권한 분리: 요청자와 승인자 분리)
- 배포 DB 반영 — 배포 DB 담당자가 최종 반영
- binlog를 통한 환경 전파
변경은 마스터 → 배포 DB 반영 → binlog로 하류 환경 전파로 이어진다. 최종 반영 책임을 배포 DB 담당자에게 모아 누락·임의 진행을 차단.
반영 후 초기설치본과 동일한 형상인지 검증해, 신규 설치 환경과 운영 환경의 DB 형상이 어긋나지 않게 한다.
4온보딩 포인트
- 배포 DB 변경은 반드시 요청 → 검토·승인 → 배포 DB 반영 → binlog 전파 순서를 따른다.
- 긴급이라도 절차를 건너뛰지 않는다 — 환경 간 불일치·DDL 누락이 바로 이 지점에서 발생한다.
- 초기설치본 형상과 일치 검증은 정책의 일부다. 누락 시 신규 설치 환경이 운영과 어긋난다.
5성과
- 배포 DB 변경의 누락·임의 진행을 감소.
- DB 환경 간 일관성 확보로 운영 안정성 향상.
6공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/deployment-db-policy.html)은 내부 식별자(티켓 ID·내부 테이블/뷰명·호스트명·IP·고객사명·동료 이름)를 제거하고 문제·접근·권한 분리·임팩트 중심으로 일반화했다. DDL·binlog·마스터/배포 DB 등 개념어는 양쪽 모두 유지. 이 내부 문서는 본인 참고/온보딩용.