運營和管理→業務流程連續性

業務流程連續性（BCP）

1）什麼是BCP，為什麼需要

BCP（業務連續性規劃）是一種系統化方法,用於確保業務流程在任何故障中都具有可持續性：從數據中心故障到提供商危機、數據泄露或負載突然增加。
在高負載產品（iGaming，fintech，市場）中，這不僅是關於基礎設施-這是關於保持信任，遵守監管義務和保護收入。

• 保持關鍵服務和數據的可用性。
• 最大限度地減少恢復時間（RTO）和數據丟失（RPO）。
• 確保團隊、溝通和外部合作夥伴在危機中正常工作。
• 標準化響應和員工培訓。

2）BCP的主要組件

1.BIA（業務影響分析）-評估故障對流程和業務的影響。
2.風險和情景-威脅矩陣（基礎設施，外部，人為）。
3.RTO/RPO目標是恢復和允許損失的目標。
4.恢復計劃（DRP）-重新啟動系統和進程的詳細步驟。
5.通訊-內部和外部渠道，通知模板。
6.測試和審計-定期檢查，演習，後期分析。
7.文檔和版本控制-集中訪問和相關性。

3）影響分析（BIA）

BIA確定了哪些過程是關鍵的，以及恢復它們的速度有多快。

1.所有業務流程列表（Payments、Bets、Games、KYC、支持）。

2.定義相關性（服務、數據、提供商、員工）。

3.評估拒絕的影響：財務，法律，聲譽，運營。

4.為每個流程安裝RTO/RPO。

5.優先級：「必須擁有」，「應該擁有」，「需要擁有」。

4）風險矩陣

5） RTO、RPO和臨界水平

RTO（恢復時間目標）：恢復前允許多少時間。
RPO（恢復點目標）：可能會丟失多少數據。

6) DRP (Disaster Recovery Plan)

目的：確保系統快速一致地恢復。

1.定義腳本（數據中心災難、PSP故障、密鑰損害、網絡丟失）。

2.對於每個腳本-完成分步劇本。

3.支持DR基礎架構：備份群集、DB副本、CDN/edge。

4.定期測試RTO/RPO和故障轉移程序。

5.將所有語句存儲在具有版本控制的單個存儲中。

Scenario: EU region falls
RTO: 30 min    RPO: 5 min
Actions:
1. Activate plan DR # EU
2. Switch DNS → AP Region
3. Verify database consistency (replication lag ≤ 60s)
4. Update Status on StatusPage
5. Perform API benchmarking

7）團隊和角色的組織

BCP協調員：計劃所有者，組織審核和測試。
DR領導：負責DR計劃的技術實施。
域所有者：確保其過程的連續性（Payments、Games、KYC）。
通信命令：負責內部/外部通知和狀態平臺。
HR/Admin：員工的BCP（遠程、通信、訪問）。
法律/合規性：監管通知和法律措施。

8）危機中的溝通

• 明確的渠道和備用聯系。
• 第一次升級是在事件發生後15分鐘內。
• 通信的統一基調，事實和ETA。
• 事件結束前每N分鐘更新一次。
• 恢復後-報告和驗屍。

[HH: MM] PSP-X failed. Impact: Deposits in EU region.
Measures: feilover on PSP-Y. ETA stabilization: 30 min.
The next update is at 15:00.

9）測試和演習

技術：故障測試，DB恢復，DDoS模擬。
操作：手動/角色更改命令。
完整的BCP演習：「停電」腳本或提供商不可用。

• DR測試-每季度；
• BCP全面教學每年進行1-2次。
• 文件：結果，偏離RTO/RPO，改進行動。

10）度量和KPI

RTO合規性：恢復目標≤過程百分比。
RPO法規遵從性：不丟失數據>目標過程的百分比。
DR測試成功率：成功驗證恢復過程。
BCP覆蓋：具有當前計劃的過程比例（>90％）。
Comms SLA：第一個摘要≤ 15分鐘，ETA更新。
Postmortem SLA：100%關鍵事件分析≤ 72小時。

11）文檔和知識管理

單個BCP存儲（版本，所有者，修訂日期）。
版本控制：至少每6個月審核一次。
可用性：離線拷貝和備用通信渠道（包括電信/信使）。
集成：在SOP、事件過程和操作儀表板中引用BCP。
與Risk Register和Security Policies同步。

12）30/60/90-實施計劃

• 確定BCP所有者和關鍵過程。
• 執行基本的BIA和分類（RTO/RPO）。
• 創建風險矩陣和事件腳本目錄。
• 開發DRP模板和優先服務的第一個版本。

• 進行試點DR測試（failover，DB恢復）。
• 準備通信模式和角色分配。
• 創建一個BCP文檔存儲和SOP集成。
• 開始團隊培訓和呼叫人員。

• 進行團隊間BCP演習。
• 對RTO/RPO合規性和KPI度量進行審核。
• 最終確定BCP流程的修訂計劃和自動化。
• 將BCP納入季度OKR和內部安全檢查。

13）反模式

「BCP僅用於打勾」：沒有真正的測試和所有者。
與當前體系結構不匹配的過時DR語句。
未經驗證的通信渠道和聯系人。
未記錄的依賴關系（PSP，CDN，KYC提供商）。
故障後缺乏驗屍。
網絡崩潰時無法離線訪問BCP。

14） BCP文檔結構示例

1. Objectives and Scope
2. Critical Processes (BIA)
3. Risk Matrix
4. Target RTO/RPO
5. DRP (by scenario)
6. Contacts and Roles
7. Communication templates
8. Schedule of tests and exercises
9. Reporting and auditing
10. Version and update history

15）與其他部分的集成

操作分析：對頭和降級到事件的指標。
通知和警報系統：啟動BCP程序的早期信號。
管理倫理：透明報告和誠實測試。
AI助手：自動準備BCP摘要和DR檢查表。
責任文化：培訓，「遊戲日」，回顧展。

16) FAQ

Q： BCP與DRP有何不同?

答：BCP更廣泛：涵蓋人員、流程、溝通、合作夥伴和基礎設施。DRP是IT系統恢復的技術計劃。

Q： 如何經常更新BCP?

答：每次重大架構變更、事件發生後，或每6個月至少1次。

問：是否需要包括合作夥伴？
A：是的。PSP、KYC和工作室是連續性鏈的一部分，必須有自己的OLA和BCP協議。