이전을 예약하기 전에 프로젝트 인벤토리 작성
client.example.com에서 예시 문의 웹사이트를 사용한다. 편집자는 프로젝트 페이지를 게시하고, 방문자는 브리프를 업로드하며, 예약된 작업이 문의를 클라이언트 시스템으로 내보낸다. 공개 페이지만 이전하면 작업의 일부만 처리하게 된다. 날짜를 확정하기 전에 원본과 대상에 대한 승인된 접근, 도메인 제어 및 복구 사본을 확인한다.
각 구성 요소에 대해 소유자, 버전, 위치, 종속성 및 승인 점검을 기록한다. 자격 증명 위치는 인벤토리에 남기고, 비밀번호와 개인 키는 승인된 비밀 저장소에 보관한다.
모든 테이블 열을 보려면 가로로 스크롤하세요.
| 구성 요소 | 이전 전 기록 | 확인 담당자 |
|---|---|---|
| 도메인 및 DNS | 등록기관, DNS 운영자, 현재 레코드 및 TTL | 클라이언트 계정 소유자 |
| 애플리케이션 | 릴리스, 런타임, 확장 및 배포 방법 | 에이전시 유지보수 담당자 |
| 데이터 및 업로드 | 데이터베이스, 업로드 경로, 백업 방법 및 마지막 사용 가능한 사본 | 데이터 운영자 |
| 양식 및 통합 | 수신자, 웹훅 엔드포인트 및 허용된 테스트 대상지 | 클라이언트 워크플로 소유자 |
| 예약된 작업 | Cron 또는 스케줄러, 시간대, 큐 및 마지막 성공 실행 | 에이전시 유지보수 담당자 |
프로덕션을 건드리기 전에 복구 사본 입증
운영 데이터베이스가 아닌 별도의 테스트 대상지로 복원하세요. PostgreSQL의 경우 SQL 덤프는 일관된 데이터베이스 스냅샷을 나타내지만, 단일 데이터베이스 덤프에는 클러스터 전체의 역할이나 테이블스페이스가 포함되지 않습니다. 애플리케이션에 필요한 지원 객체를 기록하세요. 또한 해당 데이터베이스 스냅샷이 별도로 복사된 업로드를 자동으로 일관되게 만들어 주지는 않습니다. PostgreSQL SQL 덤프 문서.
WordPress 프로젝트의 경우 파일과 데이터베이스를 포함하세요. URL이 변경될 경우 프로젝트의 마이그레이션 관련 지침을 따르세요. 무분별한 데이터베이스 검색 및 바꾸기는 직렬화된 값을 손상시킬 수 있습니다. 선택한 방법을 복사본에서 리허설하세요. WordPress 마이그레이션 핸드북.
알려진 문의와 그 첨부 파일을 기록하고, 이를 복원한 후 애플리케이션을 통해 둘 다 검증하세요. 원본 백업은 이동 중인 서버 외부에 안전하게 보관하세요. 파일 전송 완료는 복원 승인이 아닙니다.
클라이언트가 알아차릴 워크플로 리허설
접근이 제한된 임시 호스트명 또는 운영자 전용 이름 매핑을 사용하여 테스트하세요. HTTPS 및 관련 콜백 URL을 포함하여 해당 테스트 경로에 맞게 애플리케이션을 구성하세요. 복사본이 운영 메시지를 발송하거나, 실제 결제를 처리하거나, 운영 일정을 실행하지 못하도록 방지하세요. 불필요한 개인 데이터 대신 승인된 합성 레코드를 사용하세요.
각 점검 전에 예상 결과를 작성하세요. 통과 또는 실패, 증거 위치 및 검토한 사람을 기록하세요. 홈페이지 스크린샷 하나로 전체 그리드를 대신할 수 없습니다.
모든 테이블 열을 보려면 가로로 스크롤하세요.
| 워크플로 | 예상 결과 | 보관할 증거 |
|---|---|---|
| 양식 및 첨부 파일 | 저장된 문의 하나와 읽을 수 있는 파일 하나; 테스트 수신자만 | 합성 레코드 식별자 및 전달 관찰 |
| 웹훅 | 승인된 테스트 이벤트가 의도한 테스트 소비자에게 도달함 | 이벤트 식별자 및 소비자 결과 |
| 예약 내보내기 | 통제된 실행 1회, 올바른 시간대, 이전 서버 중복 없음 | 실행 식별자 및 내보낸 레코드 비교 |
| 편집자 및 방문자 경로 | 예상 권한, 리디렉션, 자산 및 HTTPS 동작 | 확인한 URL 및 모든 실패 세부 정보 |
구 시스템에서 마지막 쓰기 정의
이 예시에서 에이전시는 짧은 유지보수 기간을 제안합니다. 문의 제출 및 편집을 일시 중지하고, 이전 내보내기 일정을 중단하고, 대기 중인 작업을 완료하거나 처리한 다음, 최종 데이터베이스와 업로드 복사본을 생성합니다. 제출이 일시적으로 불가능하다는 사실을 방문자에게 어떻게 알릴지 클라이언트가 승인해야 합니다.
마지막으로 수락된 문의 식별자와 쓰기가 중단된 시간을 기록하세요. 새 제출을 허용하기 전에 대상지에 해당 레코드와 첨부 파일이 포함되어 있는지 확인하세요. DNS 응답이 다를 수 있는 동안 소스가 독립적인 쓰기를 수락하지 못하도록 유지하세요. 쓰기를 일시 중지할 수 없는 프로젝트에는 애플리케이션별 동기화 설계가 필요합니다. 전환 중에 즉흥적으로 만들지 마세요.
DNS 결정 로그 유지
TTL은 DNS 응답이 캐시되는 기간을 제어합니다. 전환 시점에 TTL을 낮춰도 이전 값으로 이미 캐시된 응답이 무효화되지는 않으므로, TTL 변경은 미리 준비하고 관련 네트워크에서 전환 과정을 관찰하세요. Cloudflare는 또한 로컬 캐싱으로 인해 변경 사항이 보이기까지 지연될 수 있다고 설명합니다. Cloudflare DNS TTL 문서.
레코드 이름과 유형, 이전 값, 의도한 값, 이전 TTL, 승인, 변경 시각, 관찰된 결과를 기록하세요. IPv4 레코드와 IPv6 레코드가 모두 존재하면 둘 다 확인하세요. 관련 없는 메일 레코드는 보존하세요. 변경 후에는 공용 호스트 이름이 의도한 IP 주소에 도달하는지뿐 아니라 의도한 애플리케이션과 핵심 워크플로에 도달하는지 검증하세요.
롤백을 데이터 결정으로 만들기
구체적인 중지 조건에 합의하세요: 최종 문의가 누락됨, 첨부 파일을 열 수 없음, 로그인 실패, 또는 웹훅이 잘못된 수신자에게 도달함. 새 쓰기가 시작되기 전에는 보존된 원본으로의 리허설된 복귀가 가능할 수 있습니다. 대상이 새 문의를 수용한 후에는 이전 백업을 복원하거나 DNS만 되돌리면 해당 레코드를 잃을 수 있습니다.
재개 후 중지 조건이 나타나면 쓰기를 일시 중지하고 두 사본을 모두 보존하며, 지정된 운영자가 변경 사항을 조정한 후 권위 있는 시스템을 선택하도록 하세요. 고객 승인자가 복구를 계속할지 합의된 대안을 사용할지 결정합니다. DNS를 반복적으로 전환하는 대신 간단한 사고 로그를 유지하세요.
증거와 책임 소재로 이전 종료
고객이 승인 그리드를 검토하도록 하세요. 하나의 활성 스케줄러, 새 백업 경로, 알림 담당자, 다음 관찰 체크포인트를 확인하세요. 합의된 기간 동안 원본을 보존한 후 명시적으로 폐기를 승인하세요. 프로젝트 합의에 따라 임시 접근 권한과 테스트 데이터를 제거하세요.
결과를 사용하여 다음을 업데이트하세요: 운영 책임 시트 및 프로젝트 예산. 이 절차는 팀의 작업을 정리하는 것이며, 마이그레이션 지원이나 무중단 서비스가 포함됨을 의미하지 않습니다.
출처 및 검토
기술 참고 자료는 12년 2026월에 확인되었습니다. 예시는 계획 연습입니다. 참조된 소프트웨어 문서가 PrivateHostLab 서비스 기능을 입증하지는 않습니다.