신뢰성 - 재해 복구 패턴 | 패턴 |

신뢰성 - 재해 복구 패턴

잘 설계된 신뢰성 → 재해 복구 및 무중단 업무 운영에 대해 자세히 알아보기

패턴

찾을 위치	유사성
데이터 백업 전략	✅ 데이터 내보내기 서비스 또는 전용 백업 및 복구 서비스(예: 자체)를 사용하는 주별 또는 월간 자동 내보내기. 내보내기 주기는 RPO 요구 사항과 일치합니다. 필요한 경우 외부 개체 저장소로 내보낸 중요 개체 데이터입니다.
메타데이터 백업 전략	✅ 모든 메타데이터는 Salesforce DX 소스 형식을 사용하여 Git에서 버전화됩니다. 소스 제어에서만 배포된 메타데이터 변경 사항입니다. CI/CD 파이프라인은 리포지토리에서 모든 환경을 다시 만들 수 있습니다. Git 내역을 통해 시점 복구를 사용할 수 있습니다.
파일 백업 전략	✅ ContentVersion 레코드, 첨부 파일 및 문서는 일정에 따라 외부 저장소로 내보냅니다. 규제 보존 요구 사항에 대한 자동 파일 내보내기 비즈니스 운영 요구보다 오래된 파일의 외부 보관 시스템입니다.
백업 유효성 검사	✅ 분기별로 전체 Sandbox 또는 Developer 환경으로 드릴을 복원합니다. 단계별 지침을 사용하여 실행북에 명시된 절차를 복원합니다. 테스트 복원은 재해가 발생하기 전에 백업 무결성 및 완결성을 확인합니다.
복구 테스트 일정	✅ 분기별 부분 복원 테스트(메타데이터, 특정 개체, 파일 하위 집합). 완전한 환경 복원과 함께 연간 전체 복구 드릴 모든 테스트 후 문서화된 학습 및 업데이트된 실행북
타사 백업 서비스	✅ 시점 복원 기능이 포함된 자동 백업 RPO/RTO를 정의하는 서비스 수준 계약입니다. 백업 완료를 일일 자동으로 확인합니다. 여러 지역에 저장된 백업이 있는 지리적 중복성
사용자 정의 개체 및 필드	✅ 예약된 데이터 내보내기 서비스 실행에 포함된 사용자 정의 개체. 수식 및 롤업 요약 필드 값이 내보내기 대신 재계산된 경우(가져오기에 저장된 값이 없음) 파일 또는 첨부 파일 이진이 별도의 내보내기 경로를 통해 처리됩니다. 복잡한 필드 유형 및 조회 관계는 복원 순서에서 문서화 및 테스트됩니다.
파일 및 첨부 파일	✅ 파일 이진으로 내보낸 ContentDocument 및 ContentVersion 개체 폴더 구조 및 권한을 포함하여 백업된 문서 라이브러리입니다. 내보낸 파일은 중요 문서 유형의 버전 내역을 유지합니다.
Sandbox 새로 고침 전략	✅ 로드 테스트 및 재해 복구 검증을 위해 프로덕션 조직이 분기별로 전체 Sandbox 새로 고쳐집니다. Sandbox 새로 고침은 복원 절차 테스트로 사용됩니다. 새로 고침 후 적용된 데이터 마스킹은 테스트 환경에서 중요한 데이터를 보호합니다.
백업 모니터링 및 경고	✅ 예약된 백업이 실패하거나 지연되면 자동으로 경고합니다. 백업 작업 성공률, 완료 시간, 데이터 용량 추세가 표시된 대시보드 허용되는 지연 기간을 초과하는 백업 실패에 대한 온콜 에스컬레이션

안티 패턴

찾을 위치	불만 사항
백업 전략	⚡️ 자동 백업이 구성되지 않으며 플랫폼 인프라 백업에만 의존합니다. 타사 백업 서비스가 구성되었지만 테스트되지 않았습니다. 백업이 손상되거나 불완전할 수 있습니다. 수동 Data Loader 내보내기는 백업에 사용됩니다(일관성 없는 실행, 불완전한 적용 범위, 자동화 없음).
메타데이터 버전 관리	⚡️ 소스 제어 없이 변경 집합을 통해 배포된 메타데이터 변경 사항 메타데이터 내역에 대한 Git 리포지토리가 없습니다. 시점 복구 불가능 - 폐기적인 변경 후 마지막으로 정상 작동이 확인된 구성을 복원할 수 없습니다.
백업 유효성 검사	⚡️ 백업이 구성되었지만 테스트 환경으로 복원되지 않았습니다. 실제 재해로 인해 범위가 불완전하거나 아카이브가 손상된 경우 첫 번째 복원 시도가 발생합니다. 백업 절차는 문서화되었지만 백업 직원이 테스트하지 않았습니다.
백업 범위	⚡️ 데이터 내보내기 서비스가 수식 및 롤업 요약 필드 값이 내보내지 않거나(동적으로 재계산되지 않고 저장되지 않음) 파일 또는 첨부 파일 이진이 별도로 처리되어야 하므로 복원 시에만 격차가 발견됩니다.
복구 절차	⚡️ 복구 실행북에는 2년 전 아키텍처의 기한이 경과한 단계가 포함되어 있습니다. 회사를 떠난 이후 단일 전문가가 테스트한 복구 절차입니다. 수동 절차는 너무 복잡하여 스트레스를 받는 상태에서 실행할 때 오류가 발생할 수 있습니다.
백업 주기	비즈니스 요구 사항이 24시간 RPO인 경우 주별로 백업되는 중요 트랜잭션 데이터 비즈니스 중요도와 일치하지 않는 백업 주기 - 중요도에 관계없이 모든 데이터에 대해 동일한 일정입니다. 모니터링 및 경고 부족으로 인해 백업 일정이 누락되었습니다.
규제 준수	⚡️ 규정에 따라 필요한 것보다 백업 보존 시간이 단축됩니다. 예를 들어, HIPAA 규정 준수 문서(정책, 위험 분석, BAA, 위반 레코드)가 6년 §164.316 보존 전에 제거되었거나 SOX 관리 재무 감사 레코드가 7년 보존 전에 삭제되었습니다. 감사 동안 발견된 규정 준수 격차입니다.
파일 저장소	⚡️ 보관 전략이 없는 Salesforce에 저장된 대용량 파일입니다. 조직의 접근 제한까지 파일 저장소가 증가합니다. ContentVersion 레코드 백업 없음 - 조직이 손상되면 파일이 손실됩니다. 중요 파일의 개인 사본을 유지 관리하기 위해 사용자에게 의존합니다.
Sandbox 테스트	⚡️ 프로덕션에서 전체 Sandbox 새로 고친 적이 없음 - 테스트 환경은 프로덕션과 매우 다릅니다. Sandbox의 데이터 용량 1%는 실제 복원 검증을 방지합니다. Sandbox 새로 고침은 재해 복구 확인 기회가 아닌 불편함으로 취급됩니다.
모니터링	⚡️ 백업 작업은 경고 없이 자동으로 실패합니다. 백업이 필요한 경우 재해 중 몇 주 후에 백업 실패를 발견합니다. 백업 작업 성공 추세가 표시된 대시보드가 없습니다. 백업 서비스 상태는 인보이스가 도착하는 경우에만 모니터링됩니다.
암호화 키	⚡️ 키 자료를 보호하지 않고 Shield 암호화된 데이터를 안전하게 처리합니다. 키만 순환하면 이전 데이터가 그대로 유지되지만, 테넌트 암호(크립토 분할)를 폐기하거나 자체 키 또는 캐시 전용 키 자료를 분실하면 암호화된 데이터를 영구적으로 복구할 수 없습니다. 키 관리는 복구 절차에서 생략됩니다.
교차 조직 종속성	⚡️ 솔루션이 연결된 앱, 외부 통합 또는 SSO에 의존하는 경우 기본 조직만 백업합니다. 연결된 앱 암호, 명명된 자격 증명 및 OAuth 권한 부여, 외부 인증 토큰은 데이터 및 메타데이터 복원에 의해 유지되지 않으며 복구된 조직이 외부 시스템에 인증하기 전에 다시 구성하고 다시 인증해야 합니다. 외부 SSO가 유일한 로그인 경로이면 사용할 수 없는 ID 공급자가 완전히 복구된 조직에도 로그인을 차단합니다.

패턴

찾을 위치	유사성
복구 시간 목표(RTO) 정의	✅ 전체 조직에서 균일하지 않고 비즈니스 성능별로 정의된 RTO입니다. 매출 크리티컬 작업: 분~~1시간. 고객 대면 서비스: 1~~4시간. 내부 도구: 4~24시간. 내역 보고: 일수. 비즈니스 이해당사자 승인으로 문서화된 RTO입니다.
복구 지점 목표(RPO) 정의	✅ 수용력당 허용되는 데이터 손실을 기반으로 정의된 RPO입니다. 금융 트랜잭션: 거의 0 RPO(초, 이벤트 중심 비동기 복제). 고객 레코드: 거의 0(CDC를 통한 분) Analytics 데이터: 시간(예약된 동기화). 임시 워크플로 상태: 일수(복제 필요 없음).
팀 가용성 및 역할	✅ 모든 중요 역할에 대해 문서화된 기본 및 백업 직원 운영 Knowledge 단일 지점은 없습니다. 기본 응답자, 첫 번째 백업, 두 번째 백업을 정의하는 에스컬레이션 트리입니다. Salesforce를 사용할 수 없는 경우 시스템에서 유지되는 연락처 정보에 액세스할 수 있습니다.
커뮤니케이션 절차	✅ 사용자, 고객, 경영진에게 알리는 사람을 정의하는 사고 통신 계획 플랫폼이 중단되는 동안 사용자 커뮤니케이션을 위해 Salesforce 외부에서 호스팅되는 외부 상태 페이지입니다. 기본 커뮤니케이션 도구를 사용할 수 없는 경우 온콜 팀에 대한 SMS 알림 시스템입니다. 문서화된 에스컬레이션 시간 범위(팀에서 관리자에서 경영진으로 에스컬레이션하는 경우)
공급업체 종속성 매핑	✅ Salesforce, 통합 파트너, ISV 패키지 공급자를 포함하여 문서화된 모든 중요 외부 공급업체 공급업체 SLA 및 지원 구간이 문서화되어 있습니다(24/7 및 업무 시간 전용 비교). 공급업체 에스컬레이션 연락처 및 절차 문서화. 중요 종속성에 대해 식별된 대체 공급업체 옵션입니다.
규제 알림 의무	✅ 산업별로 문서화된 필수 사고 알림 요구 사항(재무 서비스, 헬스케어, 정부). 각 규정의 필수 기간에 맞춰 정의된 알림 시간 범위입니다. 어떤 규제 단체에 알림을 전송하는 사람을 정의하는 책임 매트릭스 빠른 규제 알림을 위해 준비된 템플릿입니다.
비즈니스 영향 분석	✅ 매출 영향, 사용자 영향, 규제 위험별로 순위가 지정된 각 비즈니스 역량 비즈니스 영향 등급을 기반으로 한 복구 우선 순위 지정 비즈니스 중요도에 비례하여 재해 복구에 할당된 리소스입니다. 비즈니스 우선 순위가 발전함에 따라 연간 검토되는 영향 분석입니다.

안티 패턴

찾을 위치	불만 사항
RTO/RPO 정의	⚡️ 측정 가능한 RTO/RPO 목표가 없는 “시스템이 신뢰할 수 있어야 함” 비즈니스 이해당사자가 입력하지 않은 IT 팀이 정의한 RTO/RPO입니다. 중요도 차이를 무시하는 모든 기능 전반에 걸쳐 일관된 대상을 설정합니다(“모든 작업에 99.999% 가동 시간이 필요합니다”).
팀 준비도	⚡️ 단일 Salesforce 관리자는 문서 또는 백업 직원이 없는 재해 복구 절차를 알고 있습니다. 온콜 순환에는 복구 절차를 실행하지 않은 직원이 포함됩니다. 재해 발생 시 기본 대응 담당자를 사용할 수 없습니다(휴가, 질병, 사라진 회사).
커뮤니케이션 계획	⚡️ 커뮤니케이션 계획 없음 - 사고가 이미 진행 중인 후 사용자에게 알림이 필요합니다. Salesforce가 중단되는 동안 Salesforce 자체에서 호스팅되는 상태 페이지를 사용할 수 없습니다. 복구를 시도하는 동안 경영진에게 알리는 대기 시간입니다.
공급업체 종속성	⚡️ 재해가 발생할 때까지 공급업체 SLA 조건을 인식하지 않고 업무 시간만 적용되는 공급업체의 연중무휴 지원을 기대합니다. 문서화된 공급업체 에스컬레이션 연락처가 없습니다. ISV 패키지 공급자는 복구에 필요하지만 회사는 더 이상 비즈니스를 진행하지 않습니다.
규제 요구 사항	⚡️ 필수 위반 알림 법률을 인식하지 못합니다. 48시간이 경과된 후 24시간 알림 요구 사항을 알아봅니다. 준비된 템플릿 없음 - 규정 준수 시간을 기다리는 동안 사고 대응 중 규제 알림 초안 작성
복구 우선 순위 지정	⚡️ 매출 크리티컬 작업의 우선 순위를 지정하는 대신 재해 시 모든 기능을 동시에 복원하려고 합니다. 고객 대면 주문 시스템을 해결하기 전에 내부 보고 기능을 복구하는 데 8시간이 소요됩니다.
테스트 및 상세 검색	⚡️ 비즈니스 연속성 계획은 드릴을 통해 테스트되지 않았습니다. 문서화된 절차가 검증되지 않은 상태에서 작동한다고 가정합니다. 실제 재해 중에 발견되지 않은 문제를 복구하는 데 며칠을 소비하더라도 “시간 부족”으로 인해 테이블탑 연습이 방지되었습니다.
Knowledge 전송	⚡️ 재해 복구 Knowledge 아무것도 문서화하지 않은 한 명의 선임 설계자에게 집중되었습니다. 새 팀 구성원이 재해 복구 교육 없이 온보딩됩니다. 명시적 교육 또는 상세 조치 없이 모든 사람이 재해 시 수행할 작업을 알고 있다고 가정합니다.
가정 유효성 검사	⚡️ 복구 절차에서는 백업에 15분 이내에 액세스할 수 있다고 가정하지만, 콜드 저장소에서 백업 검색에는 8시간이 소요됩니다. 팀이 30분 이내에 사용 가능하지만 통화 순환 또는 에스컬레이션 절차가 정의되지 않았다고 가정합니다. 테스트를 통해 확인되지 않은 낙관적인 가정을 기반으로 한 복구 시간 추정

패턴

찾을 위치	유사성
RTO 아키텍처 정렬	✅ 아키텍처 결정이 RTO 서약과 일치합니다. 분 RTO는 자동 페일오버 및 핫 스탠비가 필요합니다. 시간 RTO는 스크립트 복구 및 온도 대기가 필요합니다. 일수 RTO는 콜드 백업에서 수동 복구를 허용합니다. 비즈니스가 복잡한 이유가 아닌 경우 과잉엔지니어링을 피합니다.
RPO 복제 전략	✅ 복제 방법이 RPO 대상과 일치합니다. 거의 0 RPO: 모든 레코드 저장 시 플랫폼 이벤트를 통해 비동기식 이벤트 스트리밍(전파 지연 초, 전달 한 번 이상) 분 RPO: 데이터 수집 비동기 복제 변경 시간 RPO: 예약된 배치 API 추출. 일수 RPO: 고정 일정에 따른 수동 백업.
RTO 테스트	✅ 시간 제한 조건에서 테스트된 복구 절차입니다. 재해 복구 드릴 도중 측정된 실제 RTO입니다. 목표 RTO와 달성된 RTO 간의 차이를 식별하고 수정했습니다. RTO는 기본 전문가뿐만 아니라 백업 직원이 달성할 수 있습니다.
RPO 유효성 검사	✅ 복구 테스트 동안 측정된 데이터 손실입니다. 드릴 도중 목표 대상을 비교한 실제 RPO입니다. 프로덕션에서 복제 지연이 지속적으로 모니터링됩니다. 복제가 RPO 서약에서 벗어날 경우 구성된 경고입니다.
수용력별 RTO/RPO	✅ 비즈니스 중요도에 따라 비즈니스 성능에 따라 RTO/RPO 목표가 다릅니다. 전자상거래 주문 플로: 15분 RTO, 거의 0 RPO(다중 조직 활성-패시브의 정당화). 내부 Knowledge 자료: 8시간 RTO, 24시간 RPO(백업에서 수동 복원하는 이유).
비용-혜택 분석	✅ RTO/RPO 목표는 구현 비용에 균형을 맞춥니다. 더 엄격한 목표를 달성하려면 기하급수적으로 증가하는 투자가 필요합니다. 가동 중지 시간 비용이 재해 복구 투자를 정당화하는 문서화된 비즈니스 사례 연간 검토는 투자 및 비즈니스 가치 간 지속적인 정렬을 확인합니다.
SLA 정렬	✅ 솔루션 RTO/RPO 목표는 플랫폼 SLA 기준선을 고려합니다. 솔루션은 다중 조직 아키텍처를 사용하는 플랫폼 기준선보다 뛰어난 RTO만 제공할 수 있습니다. 플랫폼 기능을 기본으로 고려하여 현실적인 목표를 설정합니다.
복구 기능 모니터링	✅ 백업 통화(백업 경과일 및 RPO 대상 비교)의 지속적인 모니터링 백업이 예약에서 늦어지면 알림 복구 인프라(보조 조직, 외부 저장소)가 작동하는지 자동으로 확인합니다.
자동 복구와 수동 복구 비교	✅ 적극적인 RTO 대상(분)에는 최소한의 인적 개입을 수행하는 자동 페일오버가 필요합니다. 적절한 RTO 목표(시간)를 사용하면 사람이 시작하는 스크립트 복구가 가능합니다. 보통 수준의 RTO 대상(일)은 문서화된 절차에 따라 수동 복구를 허용합니다.

안티 패턴

찾을 위치	불만 사항
실현되지 않는 목표	⚡️ 수동 복구 절차를 실행하는 데 4시간이 걸리는 15분 RTO를 확정합니다. 동기식 복제 인프라 없이 RPO가 0으로 약속됩니다. 아키텍처 지원 없이 IT에서 설정한 RTO 목표입니다.
아키텍처 정렬 오류	⚡️ 30분 RTO 서약이 있지만 자동 페일오버 및 복구 절차는 완전히 수동으로 수행되지 않습니다. RPO 서약은 없지만 일일 백업만 구성됩니다. 자동화 및 중복에 대한 적절한 투자 없이 공격적인 대상.
테스트되지 않은 대상	⚡️ RTO는 시간 설정된 재해 복구 드릴을 통해 확인되지 않았습니다. 2시간 RTO를 달성할 수 있지만 시간 제약으로 복원되지 않는 것으로 가정합니다. 실제 재해 시 4시간 RTO를 문서화한 경우 실제로 18시간이 걸립니다.
균일한 목표	⚡️ 비즈니스 중요도에 관계없이 동일한 RTO/RPO가 할당된 모든 기능 내부 배치 보고 시스템은 9개 가용성에 맞춰 설계되었으며, 매출 크리티컬 전자상거래에는 동일한 목표가 있습니다. 중요하지 않은 기능에 대한 과도한 투자와 중요 시스템에 대한 적은 투자
종속성 무시	⚡️ RTO는 Salesforce 조직 복원만 가정하지만 솔루션은 외부 ID 공급자도 사용할 수 없는지에 따라 다릅니다. RPO는 데이터 백업이 충분하다고 가정하지만 통합 자격 증명 및 구성이 백업되지 않았습니다. 복구 시간 예상 시간은 종속 시스템을 복원하는 시간을 무시합니다.
복제 간격	⚡️ 15분 RPO를 확정하지만 중요 개체 12개 중 3개에 대해서만 변경 데이터 수집 구성됩니다. 플랫폼 이벤트 복제가 구성되었지만 이벤트 배달 지연은 모니터링되지 않았습니다. 복제 인프라가 중단되고 재해가 발생하기까지 몇 주 동안 감지되지 않습니다.
비용 무시	⚡️ 구현 비용을 이해하지 않고 9진수 가용성 확보 비용-수익 분석 없이 설정된 RTO/RPO 목표 고객에게 이미 커밋된 대상에 필요한 인프라에 자금을 지원하지 않는 비즈니스
정적 대상	⚡️ 비즈니스 성장 및 우선 순위 변화에도 불구하고 5년 전에 정의된 RTO/RPO는 다시 평가되지 않았습니다. 솔루션이 발전하고 중요도가 변경되면 대상은 그대로 유지됩니다. 연간 검토 프로세스가 누락되었습니다.
문서 간격	⚡️ 아키텍처 문서에 문서화되었지만 비즈니스 이해당사자에게 전달되지 않은 RTO/RPO 대상. 비즈니스에서 커밋된 복구 기능을 인식하지 못하는 경우 비즈니스에서 1시간 복구를 기대했지만 아키텍처에서 24시간 RTO만 지원하는 경우 격차가 발견되었습니다.
False precision	⚡️ 모니터링 인프라가 정확한 측정을 수행할 수 없는 경우 “99.97% 가용성” 확정 기본 분석이 원활한 예상인 경우 거짓 정밀도로 정의된 대상은 엄격함을 제안합니다.
부재 모니터링	⚡️ 복구 기능은 지속적으로 모니터링되지 않습니다. 백업이 RPO 서약을 위반하지만 경고가 없습니다. 복제 업데이트를 수신하지 않지만 상태 확인을 구성하지 않은 활성-패시브 아키텍처의 보조 조직입니다.
실행 없이 계획	⚡️ 적극적인 RTO/RPO 목표가 있지만 자동화, 테스트 또는 확인된 절차가 없는 아름다운 재해 복구 계획 규정 준수 확인란을 충족하도록 생성된 계획이지만 서약 뒤에 운영 현실이 없습니다.

패턴

찾을 위치	유사성
데이터 중복	✅ 플랫폼은 인프라 백업을 자동으로 제공합니다. 비즈니스에 더 빠른 복구가 필요한 경우 응용 프로그램 수준 복제가 플랫폼 백업을 보완합니다. 변경 데이터 수집 또는 플랫폼 이벤트는 중요 데이터를 보조 저장소로 지속적으로 복제합니다. 복제를 통해 인프라 백업에서 해결할 수 없는 논리적 손상 또는 구성 오류를 복구할 수 있습니다.
응용 프로그램 중복성	✅ 개별 트랜잭션 실패를 겪을 수 있는 상태가 없는 응용 프로그램 논리입니다. 서버측 상태가 없어 수평 확장을 방지합니다. 모든 응용 프로그램 서버에서 사용자 정의 메타데이터 유형 및 구성용 사용자 정의 설정을 즉시 사용할 수 있습니다. 응용 프로그램 서버는 특정 서버 상태에 따라 모든 요청을 처리할 수 있습니다.
통합 중복성	✅ 회로 차단기 패턴이 통합 실패를 감지합니다. 플랫폼 이벤트는 사용자 작업을 차단하는 대신 외부 시스템을 사용할 수 없는 경우 요청을 대기열에 지정합니다. 사용자 대면 기능과 분리된 외부 시스템 오류입니다. 공급업체가 중단되는 동안 빠른 공급자 전환을 지원하는 중요한 통합에 대해 식별된 여러 외부 공급업체 옵션입니다.
중요한 작업 부하에 대한 다중 조직 패턴	✅ 활성-비활성 패턴: 기본 조직은 모든 트래픽을 제공하고, 보조 조직은 동기화되지만 유휴 상태이며, 기본 지역이 중단되는 동안 페일오버를 수행합니다. 활성 패턴: 두 조직 모두 영역 또는 사업부별로 할당된 사용자로 지속적으로 프로덕션 트래픽을 제공합니다. 다중 조직은 비즈니스에 플랫폼 기능 이상의 RPO/RTO가 필요한 경우에만 유효합니다.
다중 조직 데이터 동기화	✅ 변경 데이터 수집 중요 데이터에 대해 실시간에 가까운 복제를 제공합니다(15분 RPO). 플랫폼 이벤트는 중요 트랜잭션에 대한 이벤트 스트리밍을 제공합니다(약 0 RPO). 참조 데이터에 대한 대량 API 2.0 예약 복제(24시간 RPO 허용) 두 조직에서 동일한 레코드가 수정된 경우 활성-활성에 대해 정의된 충돌 해결 전략입니다.
다중 조직 활성-패시브 아키텍처	✅ 미국 동부 지역의 주 조직은 모든 프로덕션 트래픽을 제공합니다. CDC를 통해 동기화되었지만 유휴 상태인 유럽 지역의 보조 조직입니다. DNS 라우팅 또는 인증 계층은 사용자를 활성 조직으로 안내합니다. 기본 조직을 10분 연속으로 사용할 수 없는 경우 자동 상태 확인이 페일오버를 트리거합니다.
다중 조직 활성-활성 아키텍처	✅ 유럽 조직의 EMEA 사용자, 사용자 프로필 지역 필드를 기반으로 미국 조직의 AMER 사용자. 공유 참조 데이터(계정, 제품)의 양방향 복제 지역 데이터는 해당 조직(주문, 사례)에 유지됩니다. 충돌 해결은 고객 마스터 데이터에 대한 지역 권한이 있는 마지막 쓰기-수주를 사용합니다.
지리적 분포	✅ Hyperforce 지역 데이터 센터는 지리적 분포 기능을 제공합니다. 플랫폼 관리 중복성이 99.9% 가용성에 충분한 단일 지역 배포 지역 전체의 다중 조직은 99.95% 이상의 요구 사항 또는 규제 데이터 보존 요구 사항에 대해서만 고려됩니다.
외부 시스템 중복성	✅ 중요 외부 API에는 기본 및 페일오버 끝점이 있습니다. 기본 익스피리언스가 지속적으로 실패하면 회로 차단기가 페일오버 끝점으로 전환됩니다. 중요한 통합을 위해 지리적 중복이 있는 외부 서비스가 단일 지역 공급자보다 선호됩니다.
인프라 모니터링	✅ Trust.salesforce.com은 상태 API를 통해 모니터링됩니다. 인스턴스별 상태 알림을 구독합니다. 솔루션은 성능 저하 시 비중요한 부하를 줄여 플랫폼 상태에 동적으로 대응합니다. 확장 센터는 중복 수용력에 영향을 미치기 전에 자원 집약적인 작업을 식별합니다.
페일오버 자동화	✅ 적극적인 RTO 대상의 경우 수동 대신 자동 페일오버를 선호합니다. 상태 확인은 1~5분마다 실패를 감지합니다. 페일오버 결정 논리는 거짓 양성을 방지합니다(지연한 오류가 아닌 지속적인 실패 필요). 페일오버 대상도 건강하지 않은 경우 자동 롤백
단일 실패 지점	✅ 아키텍처 검토는 모든 단일 지점 오류를 식별합니다. 비즈니스 영향 및 경감 비용에 대해 각각 식별된 SPOF가 평가됩니다. 중복을 통해 완화된 영향력이 높은 SPOF. 문서화된 위험 수락 및 복구 절차와 함께 영향이 낮은 SPOF가 허용됩니다.
중복성 기능 테스트	✅ 예약된 페일오버 드릴은 자동화된 페일오버 논리의 유효성을 검사합니다. 백업 시스템이 로드 시 테스트되었습니다(유휴 온도 대기 중 아님). 활성-패시브 테스트 동안 보조 조직 수용력의 확인된 처리 프로덕션 부하 각 테스트에서 배운 점은 자동화 및 절차를 개선합니다.

안티 패턴

찾을 위치	불만 사항
단일 실패 지점	⚡️ 전체 솔루션은 대체 기능이 없는 단일 외부 API에 의존합니다. 사용자 정의 도메인 공급자는 SPOF입니다. 공급자가 실패하면 사용자가 Experience Cloud에 액세스할 수 없습니다. 단일 통합 사용자 계정 - 비활성화하면 모든 통합이 실패합니다.
테스트되지 않은 중복성	⚡️ 다중 조직 활성-패시브 아키텍처가 구성되었지만 테스트되지 않았습니다. 보조 조직이 동기화되지 않지만 상태 확인이 구성되지 않았습니다. 보조 조직이 손상되었거나 작동하지 않음을 나타내는 실제 재해 중에 첫 번째 페일오버 시도가 발생합니다.
데이터 동기화 간격	⚡️ 중요 개체 30개 중 5개에 대해 CDC 복제를 구성한 활성 패시브 멀티 조직 페일오버가 발생하지만, 보조 조직에 필요한 데이터의 80%가 누락되었습니다. 복제 지연 모니터링 부재 - 보조 조직은 기본 3일 이후이지만 경고가 없습니다.
False redundancy	두 조직이 모두 동일한 Hyperforce 지역에서 호스팅되는 경우 다중 지역 아키텍처 가정 실제로 동일한 업스트림 공급자를 사용하는 “중복” 외부 API입니다. 모두 동일한 단일 오류 지점을 통해 라우팅되는 여러 통합 경로입니다.
시/도 보장 아키텍처	⚡️ 응용 프로그램 논리는 메모리 내 상태에서 가로 확장을 방지합니다. 단일 응용 프로그램 서버는 모든 사용자 세션 상태를 유지합니다. 서버 재시작은 모든 사용자를 로그아웃합니다. 플랫폼 캐시 대신 응용 프로그램 메모리에 캐시된 정적 리소스가 서버 전체에서 불일치를 야기합니다.
회로 차단기 없음	⚡️ 외부 통합이 실패하고 모든 트랜잭션이 전체 120초 시간 초과를 기다립니다. 단일 외부 시스템을 사용할 수 없는 경우 모든 사용자에게 영향을 미칩니다. 실패 격리 없음 - 하나의 실패 통합은 전체 플랫폼 성능을 저하합니다.
수동 페일오버만 해당	⚡️ 수동 페일오버 절차만 포함된 다중 조직 아키텍처 비즈니스가 중단되는 동안 페일오버를 시작하려면 2시간의 절차가 필요합니다. 자동 상태 확인이 구현되지 않았습니다. 페일오버 결정은 실행 승인 지연 복구가 필요합니다.
수용력 계획 실패	⚡️ 프로덕션 부하의 20%에 해당하는 활성/패시브 아키텍처의 보조 조직입니다. 페일오버가 발생하지만 보조 조직에서 전체 프로덕션 트래픽을 처리할 수 없습니다. 한 조직이 실패하면 두 조직이 모두 85% 수용력인 활성 활성 아키텍처로 중복되지 않습니다.
구성 드리프트	⚡️ 배포가 동기화되지 않으므로 기본 및 보조 조직은 시간에 따라 다릅니다. 메타데이터는 기본에 배포되지만 보조에는 배포되지 않습니다. 페일오버는 6개월 전 코드 버전을 실행하는 보조 조직을 표시합니다.
과잉 엔지니어링	5명이 사용하는 내부 관리자 도구에 대한 활성 활성 복제를 사용하는 다중 조직 아키텍처 비즈니스 크리티컬성에 근거하지 않는 다중 조직의 운영 복잡성 배치 보고를 위한 99.999% 가용성 목표는 99%로 허용됩니다.
지리적 오해	⚡️ Hyperforce “다중 지역”은 자동으로 다중 조직 기능을 제공한다고 가정합니다. 단일 조직이 항상 단일 지역에 있고 다중 지역에는 여러 조직이 필요하다는 점을 이해하지 못했습니다. 단일 조직 아키텍처에서는 지역 기반 중복이 불가능합니다.
통합 커플링	⚡️ 모든 통합은 비동기식 대체 기능 없이 동기식입니다. 외부 시스템을 사용할 수 없으면 사용자 작업이 차단됩니다. 대기열 메커니즘 없음 - 외부 시스템이 일시적으로 다운되면 트랜잭션이 실패합니다. 통합을 지원하지 않을 경우 사용자가 진행할 수 없습니다.