OMS 非功能需求與 SLA
整合 RFP 內多版本 NFR（Daphne / Belle / 整合版 / Manus v2.0 / gpt 修正版），涵蓋效能、可用性、安全、相容、維運、SLA。gpt 版對延遲寫死成保證值的修正尤其重要，見文末。
效能需求
主幹目標1
| 指標 | 目標 | 分位 |
|---|---|---|
| 訂單處理延遲 | ≤ 100ms | P99 |
| 訂單從接收到送出延遲 | ≤ 500ms | P99（交易員 → Bloomberg EMSX） |
| 系統吞吐量 | ≥ 1000 訂單 / 秒 | — |
| 成交回報延遲 | ≤ 100ms | P99 |
| 頁面載入時間 | ≤ 3 秒 | — |
| 核心交易處理（Internal Latency） | < 10ms | Belle 版2 |
| 開盤峰值併發 | ≥ 500 筆 / 秒 | Belle 版壓測目標2 |
gpt 修正版 SLO（建議採用）3
原版需求把延遲寫成保證值，gpt 建議改為 SLO：
| 指標 | 建議 SLO |
|---|---|
| Gateway 語法檢核 reject | p95 < 20ms、p99 < 50ms |
| 前置風控延遲 | p95 < 100ms |
| R6 預扣 API | p95 < 200ms，超時進降級 |
| FIX session failover | 秒級內完成，不保證每筆無感重送 |
| 成交回寫帳務 | p95 < 1 秒，失敗進 queue 補償 |
核心哲學：延遲不應寫死成「保證值」，而應是可驗收的 SLO + 降級策略，超出門檻時有明確的失敗處理路徑。
可靠性需求
| 項目 | 目標 |
|---|---|
| 系統可用性 | 99.95% 以上（Daphne / Manus 版）1；99.9% 年度目標（Belle 版）2 |
| 資料完整性 | 100%（無資料遺失）1 |
| 訊息送達率 | ≥ 99.99%1 |
| 資料備份 | 至少每小時一次，能 4 小時內恢復至任意時間點4 |
99.95% 與 99.9% 差異：99.95% 允許每月 21.6 分鐘停機，99.9% 允許每月 43.2 分鐘。RFP 內兩版數字不同，status: contested，上線時需明確裁決。
資訊安全需求
基本要求1
- TLS 1.2+ 加密傳輸
- 密碼策略 — 至少 12 字元，含大小寫字母、數字、特殊符號
- 登入失敗 5 次自動鎖定帳號 30 分鐘
- 雙因素認證 (MFA) 支援
Belle 版加強2
- 符合 ISO 27001 指引
- 靜態原始碼掃描 (SAST)
- 動態滲透測試
- API 加密
法規合規2
- 支援證期局對副委託交易之稽核紀錄留存 5 年
- 美國 broker-dealer 電子紀錄保存需符合 SEC 17a-4（WORM 或 audit-trail alternative 皆可，不必僵化）3
擴展性需求1
- 並行使用者 ≥ 1000
- 歷史訂單查詢 ≥ 100 萬筆
- 模組化架構，支援功能擴展、OTA 升級、衍生性商品擴充2
相容性需求1
| 面向 | 支援 |
|---|---|
| 作業系統 | Windows、macOS、Linux |
| 瀏覽器 | Chrome、Firefox、Safari、Edge |
| 行動系統 | iOS、Android（平板 / 手機） |
部署與環境
環境需求2
建立 四套獨立環境：開發、測試 (QA)、稽核、正式 (Production)。
佈署需求2
- Container 容器化佈署
- 藍綠佈署 (Blue-Green Deployment) 實現零停機更新
- 自動化 CI/CD，確保更新過程不丟單
相容性與擴充性2
- 可對接富邦全公司之副委託中台風控架構
- 保留 OTA 升級接口
維運需求
LOG 管理與標準化2
統一 Log 格式必含：Timestamp、TraceID、UserID、Action，利於稽核追蹤。
API 錯誤管理2
定義標準錯誤碼，讓前端提供人性化提示，例：
R6 餘額不足上手連線超時ERR-RISK-PRICE-DEVIATION（gpt 版建議）3ERR-KYC-PRODUCT-NOT-ELIGIBLE
版本管理2
- 採用 Git Flow 管理分支
- 每次發佈產出完整 Release Note
自動化與改善2
- 引進 RPA 輔助例行性檢查
- 持續優化交易報表產出效率
監控與告警2
- 整合 SCOM 或 Zabbix
- 針對 Ping、CPU、Memory、API Error 即時告警
連線健康監控5
- Latency 追蹤 — 每條 FIX Session 延遲 > 500ms 自動切換備援
- API 儀表板 — R6、Bloomberg、DMA 各渠道即時請求成功率與回應時間
- Session / API / MQ / R6 / DB 全面監控 (gpt 版建議)3
維運服務等級協議 (SLA)2
服務範圍
全球市場交易時段 24/5 支援（配合美股交易時間），包含：
- OMS 核心系統
- FIX 連線模組
- R6 串接介面
KPI 指標
| 指標 | 目標 |
|---|---|
| 回應時間（P1 重大故障） | 30 分鐘內回覆 |
| 恢復時間（P1） | 4 小時內恢復 |
| 系統可用性 | 99.9% |
| 嚴重故障修復時間 | 4 小時內 |
緊急變更流程
- 定義 Hotfix 發佈程序
- 緊急變更須經交易室主管與 IT 主管共同授權
系統維護與更新
- 預定於週六或非交易時段進行例行維修
- 需於 48 小時前通報
驗收與報告
- 每月提供系統健康檢查報告
- 每月維運數據彙總
資料備份與恢復4
| 項目 | 策略 |
|---|---|
| 全量備份 | 每日 |
| 增量備份 | 每小時 |
| 差異備份 | 支援 |
| 恢復時間目標 (RTO) | 4 小時 |
| 恢復時間點 (RPO) | 任意時間點 |
SLO vs 保證值的哲學差異（重要）3
gpt 版對原 RFP 作出關鍵修正，值得開發團隊深思：
| 原版寫法 | gpt 建議 | 理由 |
|---|---|---|
| 「Reject 10ms 內完成」 | p95 < 20ms、p99 < 50ms | 寫死成保證值難驗收，應定義分位數 |
| 「R6 200ms 內必回」 | p95 < 200ms，超時進降級 | 沒有降級策略則單一超時 = 全系統當機 |
| 「2 秒沒回執就自動重送到備援」 | 絕對不可盲目重送 | 訂單可能已送達市場但回報延遲；盲目重送會重複下單 |
| 「備援切換 500ms」 | 秒級內完成，不保證每筆無感重送 | failover 本身可秒級，但每筆 order 是否能無縫續命是另一回事 |
| 「WORM 才合法」 | 不可竄改留痕機制 | SEC 17a-4 接受 WORM 或 audit-trail alternative |
非功能驗收2
- 壓力測試需達預期峰值 2 倍不崩潰
- 完成資安弱點 100% 修正
- AD 權限切換測試通過
相關頁
- RFP 背景：OMS RFP 需求總覽
- 功能清單：OMS 功能需求
- 技術深度：Algo 映射與 R6 整合
- 對手對比：BOCCO BOMS 方案
補充資訊
(未來 ingest 新來源會在此追加段落)