비즈니스 연속성 계획
1) 목적, 범위 및 원칙
목적: 라이센스 및 계약을 위반하지 않고 실패 및 빠른 복구시 중요한 서비스 (예금, 베팅/게임, 결론, KYC/AML, 지원) 의 지속을 보장합니다.
영역: 온라인 플랫폼, 결제 루프, 사기 방지/CUS, DWH/BI, 지원, 운영 및 법률 기능, 주요 공급 업체 (PSP/KYC/클라우드/CNC/스튜디오/애그리 게이터).
원칙: 안전 우선, 플레이어 우선, 규제 정확성, RTO/RPO 최소화, 간단한 저하 모드, 확률 및 정기적 인 연습.
2) BIA-비즈니스 영향 분석
중요한 프로세스, 입력/출력, 종속성, 수동 대안 및 대상 RTO/RPO를 식별합니다.
BIA 단편 (YAML) 의 예:yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]3) 위험 → 영향 → 응답
클라우드 영역 충돌, 데이터베이스 오류, 클러스터 손실, DDoS 공격, CNC 오류.
공급 업체: PSP/KYC 저하, 게임 애그리 게이터와의 휴식, 사기 방지/제재 심사에 접근 할 수 없습니다.
사이버: 계정/키 손상, 랜섬웨어, PII 누출.
프로세스/사람: 파업/질병, 주요 전문가 출발, 릴리스 오류.
지리/힘 전공: 통신/에너지 중단, 군사/제재 위험, 도메인/교통 차단.
각 트리거, 에스컬레이션 임계 값, 제어 조치, 서비스 저하 및 통신 템플릿.
4) 지속 가능성 아키텍처 및 전략
지역별 활성/활성 대기; 빠른 상승을위한 코드로서의 인프라.
분해 모드: 읽기 전용 쇼케이스, 중요하지 않은 게임 제공 업체의 연결 해제, 지불 제한, 지연된 캐스하우트 (법적으로 허용되는 경우) 가있는 "예금 만", 낮은 분석/ETL 빈도.
교통 관리: Anycast CDN, 지리 밸런싱, 건강 점검, 카나리아 라우팅.
데이터: PITR 백업, 로그 변경, 지역 간 복제, 암호화 무결성 (해시/세계).
키/비밀: 지역당 독립적 인 KMS, 로깅이있는 "브레이크 글래스".
PSP/KYC 멀티 호밍: 자동 장애, SLA/대기 시간 라우팅.
5) 사건 명령 시스템
사건 사령관 (IC) - 단일 결정 포인트.
Ops Lead (SRE/Platform) - 기술 안정화, feilover, 지표.
비즈니스 연속성 리드-프로세스/수동 절차 조정.
Comms Lead - 외부/내부 알림 (플레이어, 파트너, 규제 기관).
보안/DPO-사이버 사건/개인 정보 보호, 규제 창.
결제/KYC 리드-PSP/KYC 시나리오.
연락 담당자: 법률, 지원, VIP/CRM, 데이터/BI.
규칙: 사고 당 하나의 IC, 명확한 채널 및 의사 결정 로그.
6) 커뮤니케이션 계획
채널: 전쟁 실 (채팅/브리지), 백업 연결 (전화/라디오/alt-messenger), 사전 확인 된 PSP/KYC/은행 연락처.
외부 메시지 템플릿: 상태 페이지, 소셜 네트워크, 이메일/푸시; 톤-사실, 타이밍, 다음 단계.
규제 기관 및 파트너: 사전 설정된 주소, SLA 알림; 동의 한 문구.
플레이어: 저하 기간 동안 투명한 ETA, 보상/보너스 (해당되는 경우), FAQ.
7) 운영 계획 (런북)
단편의 예:7. 다른 지역으로의 1 Feilover
yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"7. 2 PSP 분해
yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter7. 3 KYC 공급자 사용할 수 없음
yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch8) IT 및 데이터 복구 (DR)
시스템 범주: Tier-1 (플랫폼/결제/CCM), Tier-2 (게임/분석), Tier-3 (내부).
들어 올리기 절차: 설정 → sekrety/KMS → BD → kesh → API → front/CNC → internatsii → analitika.
무결성 검사-체크섬, 로그/복제 검증, 트랜잭션 조정.
DR 테스트: 매년 전체 (전환), 분기 별 부분; 실제 RTO/RPO를 전송하십시오
9) 사람, 사무실 및 물류
원격 준비: 중복 랩톱/모뎀, SSO/MFA를 통한 액세스, IC에 대한 "빨간색" 액세스.
대체 위치: 예비 사무실/공동 작업 공간, 통과 목록, 대피 계획.
교대 회전: 역량 행렬, 주요 역할의 중복, 교체 계획.
중요한 통신/에너지 제공 업체: 연락처, SLA, 발전기/UPS (관련된 경우).
10) 공급 업체 및 공급망
계약의 BCP/DR 요구 사항: RTO/RPO, 필수 테스트, 감사 권한 및 공동 연습.
하위 프로세서 등록: 연락처, 중단 계획, 오프 보드시 데이터 삭제/내보내기 확인.
1 단계 분기 별 리뷰: 사건, DR 프로토콜, 인증 상태, SLA.
11) 훈련, 훈련 및 테스트
분기당 한 번 테이블 탑: PSP/KYC/클라우드/사이버 시나리오.
기술 연습: DR 부분/전체; DDoS/CNC 전환; "킬 스위치" SDK 제공 업체.
통신 훈련: 보도 자료/상태 업데이트/규제 서신.
회고전: 타임 라인, RCA, CAPA, 런북 업데이트 및 BIA.
12) 측정 항목 (KPI/KRI)
RTO/RPO 실제 (Tier-1에 따름): 목표를 95% 이상 충족시킵니다.
MTTD/MTTR: 하향 추세; 중요한 사고의 MTTR
Feilover 성공: 데이터/주문/속도 손실없이
적용 범위 연습: 2 개 이상의 완전한 DR 테스트/년 + 4 테이블 탑.
커뮤니케이션: 첫 번째 업데이트까지의 시간
공급 업체 탄력성: 12 개월 동안 DR 테스트가 확정 된 Tier-1의 점유율은 100% 입니다.
13) RACI (확대)
14) 점검표
14. 1 실패 준비
- 현재 IC/공급 업체/규제 기관 연락처
- 복제 상태, 정기적 인 PITR 백업
- SDK/Webhook 킬 스위치 검증
- 검증 된 건강 검사가있는 교통 관리자 (GSLB/CNC)
- 상태/문자 템플릿 및 게시 권한
- 런북 및 액세스 (SSO/MFA) 매월 검토
14. 사건 중 2
- IC 할당, 전쟁 실 개방, 의사 결정 로그 시작
- 분류 (P1/P2), 시나리오 선택 및 저하
- 기술적 인 행동 (feilover/limites/disconsections)
- 최초 공개 업데이트
- SLA 규제/파트너 알림
- 사후 인공물 캡처
14. 사건 후 3
- RCA 및 CAPA와의 사후 부검
- 업데이트 된 BIA/임계 값/루틴
- 교육/수정 수정, 보드 보고서
- 재무/화해
15) 템플릿 (조각)
15. 스크립트 카드 1 개
yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]15. 상태 페이지에 메시지 2 개
[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.16) 문서 및 버전 관리
저장소, 변경 로그, 문서 소유자에서 BCP/런북을 검증합니다.
수정 기간 (Tier-1의 분기 별), 오프라인 사본 가용성 제어.
드릴/사고 아티팩트 및 성능 지표 저장.
17) 구현 로드맵 (6-8 주)
1-2 주: BIA 및 중요한 프로세스, RTO/RPO 목표, 시나리오 및 소유자 목록.
3-4 주: 안정성 및 저하 모드, 런북, 통신 템플릿, 연락처 아키텍처.
5-6 주: 공급 업체 통합 (PSP/KYC/클라우드), 파일럿 연습 (탁상 + 부분 DR), 조정.
7-8 주: 전체 DR 테스트 (가능한 경우), 분기 별 운동주기 시작, 보드 보고서 및 규제 패키지 (필요한 경우).
18) 관련 위키 섹션
위험 등록, 사고 및 누출, DR/BCP 테스트, TPRM 및 SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/최소 특권, 로그 정책/WORM-견고성과 확률의 단일 루프.
TL; DR
효과적인 BCP = BIA → RTO/RPO → stsenarii 및 분해 성 → 다중 공급 업체/다중 지역 + 명확한 사건 명령, 통신 및 연습. 문서를 생생하게 유지하고 정기적으로 테스트하십시오. 심지어 큰 충돌조차도 비즈니스를 중단하거나 라이센