재난 복구 계획

1) 목적, 범위 및 원칙

목표는 규제 요구 사항, 계약 및 플레이어 기대치를 위반하지 않고 재난 후 (재해, 사이버, 공급 업체, 지정 학적) IT 플랫폼을 적시에 복구하는 것입니다.
영역: 생산 환경 (게임 회로, 결제, KYC/AML, 사기 방지, DWH/BI 상점), 통합 (PSP, KYC, CNC, 스튜디오/애그리 게이터), 인프라 (클라우드/K8, 네트워크, 비밀/키), 데이터 (데이터베이스, 파일, 로그).
원칙: 안전 우선, RTO/RPO 최소화, 자동화 및 재현성 (IaC), "기본적으로 확률", 정기 연습.

2) 시스템 분류 및 복구 목표

2. 1 비판 수준

1 단계 (중요): 지불/캐스 하우트, 핵심 게임, 로그인/인증, ICC/제재.
2 단계: 실시간 분석, 마케팅/CRM, DWH보고.
3 단계: 내부 포털, 보조 서비스.

2. 2 목표

RTO-복구 시간 목표

RPO (Recovery Point Objective) -허용 가능한 데이터 손실.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual) -실제 값은 보고서에 기록됩니다.
MTO/MBCO: 최대 허용 가동 중지 시간/최소 허용 서비스 수준 (저하 모드).

• Tier-1-RTO Tier-2-RTO Tier-3-RTO

3) DR 전략 및 건축

3. 1 토폴로지

액티브 액티브 (다중 지역): 최소 RTO/RPO, 일관성 및 충돌 해결이 필요합니다.
액티브 스탠비 (뜨거운/따뜻한/차가운): 비용/속도 균형.
데이터와 키의 지리적 분리: 지역당 KMS/HSM, 한국, 독립적 인 복제 경로.

3. 데이터 및 백업 2 개

PITR (포인트 인 타임 복구): 트랜잭션 로그, Tier-1의 경우 보관 간격이 5-15 분입니다.
스냅 샷/전체 백업: 매일/시간별, 3-2-1 체계 (3 부, 2 개 미디어, 1 개 오프라인/오프 사이트) 에 따른 스토리지.
불변성: WORM/객체 잠금 장치, 서명/해시 아티팩트 체인.
복구 카탈로그: 백업 인벤토리, 무결성, 만료 날짜, 테스트 암호 해독.

3. 3 가지 응용 프로그램 및 통합

Statles Services-IaC/CI를 통한 신속한 배포

주 구성 요소: 일관된 스냅 샷, 출시 시퀀스의 오케스트레이션.
통합 (PSP/KYC/애그리 게이터): 이중 크레딧, 대체 엔드 포인트, 서명 된 웹 후크, 재 전달 제어 (idempotency).

4) 복구 순서 (일반 런북)

1. DR 사건 사령관 (DR-IC) 을 지정하여 DR 스크립트를 선언하고 전쟁 실을 시작합니다.
2. 피해 평가: 영향을받는 지역/서브 시스템, 현재 RTA/RPA, feilover 활성화 결정.
3. 격리/격리: 원래 원인 차단 (네트워크 ACL, 비밀, 공급자 연결 해제).

• 네트워크/비밀/KMS →
• DB/Vault/캐시 →
• API/서비스 → 전면/CNC → 외부 통합.
• 5. 무결성 점검: 카운터. "건조한" 요청, 건강 샘플의 양.
• 6. 금융/게임의 조정: 지불 조정, 베팅, 잔액, 거래의 엄청난 반복.
• 7. 커뮤니케이션: 상태 페이지, 플레이어/파트너/규제 기관 업데이트 일정.
• 8. 관찰 및 안정화: 정규화가 진행됨에 따라 분해 비활성화.
• 9. 사후: RCA, CAPA, DRP 업데이트.

5) 전문가 런북 (스 니펫)

5. 1 액티브 스탠비 → 스탠비

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5. PITR에서 2 개의 부패 DB/복구

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5. DR 모드에서 3 PSP 저하

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6) 데이터 무결성 및 조정

재무: 예금/지불/수수료 조정, 중복 제거 알림 및 웹 후크 (deimpotency-key).
게임 윤곽: 라운드 상태 복구, 필요한 경우 합의 반복, 이중 충전/충전 방지.
로그/감사: WORM 로그 매핑 전/후, 서명/해시, 일관성 보고서.
DPO/준수 보고서: PII 영향의 경우 캡처 규모, 타임 라인 및 알림.

7) 핵심 기술을위한 DR (예)

DBMS (관계형): 동기/비동기 복제, WAL 슬롯, 빠른 프로모션, 핫 대기.
NoSQL/caches: 멀티 클러스터, TTL 장애, 콜드 필링, 충돌 해결없이 교차 지역 쓰기 거부.
대기열/스트림: 미러 토픽/클러스터, 오프셋 제어, 소비자 중복 제거.
오브젝트 스토리지: 버전 지정, 벙커 복제, 오브젝트 인벤토리 및 보존 정책.
CI/CD/아티팩트: 레지스트리 복제본, 아티팩트 서명, 중요한 컨테이너의 오프라인 사본.
비밀/키: 지역당 KMS, 독립적 인 루트 키, 로깅이있는 브레이크 글래스 및 TTL.

8) DR의 보안 및 개인 정보 보호

최소 권리의 원칙: 개별 역할/프로파일 (JIT/PAM) 에 의한 DR 액세스.
불변의 백업: 오프라인/오프 사이트, 복구 및 암호 해독 테스트.
규제 창: 법률/DPO와 함께 이벤트 캡처 및 알림 결정 (규제/은행/PSP/사용자).
추적 성: 전체 DR 명령 활동 로그, 타임 라인 서명.

9) 운동 및 테스트 유형

보행/검토: 문서/역할/연락처 검토 (분기 별).

테이블 탑: 충돌 해결을 통해 "건조" 에 대한 시나리오를 실행하십시오

기술 부분: 단일 서비스/데이터베이스 복구.
완전한 장애/전환-트래픽 및 데이터를 백업 지역으로 전송합니다.
혼돈 일 (제어): 자동 검사 실패/실패 주입.

각 테스트 → RTA/RPA, 편차 목록, CAPA 및 DRP 업데이트가있는 보고서.

10) 측정 항목 (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): 95% 일치합니다.
DR 테스트 범위: 2 개 이상의 완전한 DR 테스트/년 + 일반 부분.

첫 번째 상태: DR 발표 후 약 15 분

조정 Zero-Diff: 불일치가없는 모든 현금 및 게임 조정.
백업 무결성: 스팟 복원의 100% 가 분기에 성공합니다.
드리프트 설정: 1 차/2 차 (IaC 비교) 사이의 0 드리프트.
DR의 보안: 로그 및 확인이 포함 된 100% DR 활동.

11) RACI (확대)

12) 점검표

12. 1 DR 준비

• DR 팀/공급 업체/규제 기관 연락처 업데이트
• 복제 녹색, PITR 활성화, 백업의 테스트 암호 해독
• JIT/PAM 액세스, 브레이크 글래스 검증
• 가짜 플레이 북과 환경 변수가 유효합니다
• PSP/KYC 듀얼 크레딧/웹 후크, 대체 경로
• 상태 페이지/메시지 템플릿 준비

12. DR 중 2

• DR-IC 할당, 전쟁 실 개방, 이벤트 타임 라인
• 격리, 스크립팅, 실행 런북 원인
• 무결성 검사, 건강 검진, 연기 검사
• 최초의 공개 업데이트 SLA의 파트너/규제 기관에 알림
• 조사를 위해 인공물 캡처

12. DR 후 3

• 돈/게임 및 잡지의 완전한 조정
• 날짜와 소유자가있는 사후, RCA, CAPA
• DRP/BIA/연락처/IaC 업데이트
• 수정 리테스트 계획

13) 템플릿 (조각)

13. 1 서비스 카드 (DR 여권)

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13. 2 DR 테스트 보고서 (노출)

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13. 3 상태 메시지 템플릿

[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

14) 구현 로드맵 (6-8 주)

1-2 주: 서비스 및 종속성 목록, 계층 분류, RTO/RPO 목표, 토폴로지 선택, DR 여권.
3-4 주: 백업/PITR/불변성 구현, 비밀 복제/KMS, 런북 준비 및 상태.
5-6 주: PSP/KYC/지역 시나리오에 따른 부분 기술 테스트 (데이터베이스/캐시/대기열).
7-8 주: 전체 전환 (가능한 경우), RTA/RPA, CAPA, DRP 업데이트 및 정기적 인 테스트 계획으로보고하십시오.

15) 다른 위키 섹션과의 통합

링크: BCP, 위험 등록, 사건 관리, 로그 정책 (WORM), TPRM 및 SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/최소 특권, 비밀번호 정책 및 MFA, 변경/릴리스 관리.

TL; DR

Working DRP = Tier → Active/Standby architecture의 명확한 RTO/RPO + 불변의 백업/PITR → 재생 가능한 런북 및 feilover → 돈/게임의 조정 → 규칙적인 연습 및 CAPA. 그런 다음 주요 실패는 예측 가능한 복구 시간과 규제 기관 및 플레이어에 대한 놀라움이없는 관리 가능한 절차로 바뀝니다.