根据Reg SCI，容量和压力测试证据是年度SCI审查的一部分。
适用于受Regulation SCI监管的美国交易所、结算机构及其他市场基础设施的合规和系统团队。
美国证券交易委员会(SEC)的系统合规与完整性条例(Reg SCI)自2015年11月3日合规日起，监管美国市场基础设施的核心技术。该条例要求市场运营实体保持其系统的能力、韧性和可用性，并提供证明。容量和压力测试处于这一义务的核心位置。
规则1001(a)为核心条款，要求制定书面政策和程序，以合理确保SCI系统具备足够的容量、完整性、韧性、可用性和安全性。规则1001(a)(2)则明确这些政策需涵盖当前和未来容量规划以及定期容量压力测试，确保系统能够准确、及时、高效地处理交易。
大多数在线Reg SCI内容由律师事务所撰写，侧重合规摘要。本文则聚焦工程层面，详细介绍SCI审查期望的容量和压力测试证据，以及如何通过专门工具生成这些证据。LoadView是基于云的负载与压力测试平台，以下章节将SCI审查员关注的各项内容与LoadView功能一一对应。
本指南涵盖内容
- Regulation SCI适用对象
- 容量和压力测试在Reg SCI中的角色
- SCI审查期望的证据
- LoadView如何支持Reg SCI容量和压力测试
- 为何小规模或仅协议测试无法满足审查员
- 如何生成符合Reg SCI要求的测试证据
- 容量和压力测试频率
- Reg SCI要求报告的内容
- 记录保存期限
- 结论
- 常见问题解答
Regulation SCI适用对象
Reg SCI并非适用于所有市场参与者。它适用“SCI实体”，即为市场整体运行依赖的系统提供服务的特定实体：
- 自律组织，包括国家证券交易所、注册结算机构、FINRA及MSRB。
- SCI另类交易系统，即在NMS或非NMS股票中跨越成交量门槛的较大ATS。
- 计划处理方及部分豁免结算机构。
义务根据系统的重要程度递增。规则1000将系统划分为“SCI系统”及更严格要求的“关键SCI系统”，后者的失败会最大程度扰乱市场。2023年SEC提议修改扩大覆盖实体范围，当前边界附近的公司应关注该提案，不应假定其不在监管范围内。
容量和压力测试在Reg SCI中的角色
规则的三部分推动测试工作，它们相互支持：
- 规则1001(a)：容量和韧性。政策必须确保SCI系统具备足够容量，包括当前和未来容量规划及定期容量压力测试。这是负载和压力测试的直接依据。
- 规则1003(b)：年度SCI审查。每个SCI实体每年至少进行一次Reg SCI合规审查，由客观、合格人员执行，涵盖系统渗透测试及控制评估。容量测试证据是该审查的重点之一。
- 规则1004：业务连续性与灾难恢复测试。SCI实体须至少每12个月进行一次业务连续性及灾难恢复计划测试，包括指定成员或参与者的参与。
对于交易所撮合引擎、结算系统或市场数据源，“充足容量”并非固定数字。遇波动市况，消息速率激增，期权成交量在行权日达到峰值，单一新闻事件也能令订单流量远超正常水平。Reg SCI期望SCI实体规划余量，以测量限制为依据的容量规划，而非在激增时临时发现极限。
SCI审查期望的证据
SCI审查基于实物证据。当审查容量与韧性，通常查找如下记录：
审查员关注的证据 | 它所展示的内容 |
|---|---|
记录的容量和性能要求 | 存在经过批准的吞吐量、延迟和错误率目标，每一次测试都有明确的通过/失败标准。 |
重大系统变更前的容量压力测试 | 变更生效前进行容量核查，而非事故发生后的补救。 |
峰值及超峰值压力测试 | 系统被推至预计峰值及超过峰值，故明确知晓突破点。 |
含响应时间、吞吐量和错误率的测试报告 | 结果具备记录日期且可复现。 |
当前和未来的容量规划文档 | 记录当前余量及随之消耗的增长曲线。 |
发现瓶颈时采取的措施 | 发现问题后采取修复并重新测试，而非仅存档报告。 |
随交易量增长的定期复测 | 测试持续跟踪消息速率增长，而非一次性操作。 |
第一条规则是程序最常失败之处。无书面性能SLA，压力测试无通过/失败标准，审查员看到的图表无据可依。首先确立标准：每个系统的峰值消息率，峰值下的延迟上限，以及视为失败的错误率限制。
第二和第三条关注时机与强度。压力测试应在重大变更前进行，表明在市场依赖前已核查容量；突破预计峰值则将“破坏点”转化为记录中的数值，而非波动开启时的意外。后续几条涵盖持续记录：带日期的报告、当前和未来容量规划、审查员问“如何处理”时的修复及复测记录，以及随交易量上涨的复测节奏。
LoadView如何支持Reg SCI容量和压力测试
上述各项均对应LoadView的直接功能。表格将审查员要求的证据与LoadView产出的功能一一对应。
SCI审查证据 | LoadView如何生成 |
|---|---|
记录的容量和性能要求 | 为每笔交易设置响应时间和错误率的通过/失败阈值，使每次测试均可自动评判是否达标。 |
重大系统变更前的容量压力测试 | 从CI/CD流水线触发测试，确保每次变更上线前附带容量核查。 |
峰值及超峰值压力测试 | 使用可配置负载曲线保持在预计峰值，然后逐步超越以寻找极限。 |
含响应时间、吞吐量及错误率的测试报告 | 导出带时间戳的性能报告，包括响应时间百分位数、吞吐量、错误率和按元素分解的瀑布图。 |
当前和未来的容量规划文档 | 读取延迟开始上升且错误率增加的负载等级，作为测得的系统极限，并记录对应的消息速率增长预测。 |
发现瓶颈时采取的措施 | 利用瀑布图和分层时序找出瓶颈组件，修复后重新运行同一测试以记录前后效果。 |
随交易量增长的定期复测 | 安排定期测试并在流水线中保持，使复测自动跟踪负载变化。 |
SCI系统分为两级，LoadView均可覆盖。对订单录入网关、市场数据接口，API负载测试以速率驱动服务端点。对于SCI实体及其参与者运营的面向Web的系统（成员门户、发行商与参与者仪表板、状态与报告站点），真实浏览器负载测试测量用户实际体验。高并发负载测试则实现交易所级别的消息速率。
为何小规模或仅协议测试无法满足审查员
两种测试简化会削弱SCI审查所需的证据力度。
其一是低于真实峰值的测试。容量测试如仅接近平均水平，对波动开盘或到期日激增毫无说明。Reg SCI要求覆盖当前与未来容量，测试必须达到并超出预计峰值，这时基于速率的交易并发测试才能生成审查员信赖的有效证据。
其二是仅测量协议层面。对于面向Web的系统，纯协议层测试仅触发HTTP请求，报出吞吐量，而忽略成员实际看到的JavaScript、认证重定向及渲染界面。真实浏览器测试通过Chromium实例执行完整流程，报告中的响应时间即代表真实参与者在负载下的感受，这才是判断高峰期用户能否持续操作的关键数据。
测试工具宣称“每秒百万条消息”的数字，仅代表原始吞吐量，无法单凭此显示撮合引擎是否满足延迟上限，或成员门户是否依旧可用。证据必须反映规则关注的实际指标。
协议级测试测量端点；真实浏览器测试测量负载下面向成员的工作流。
如何生成符合Reg SCI要求的测试证据
满足容量义务无须新类型工具，只需测试对应证据清单且形成可交付审查的记录。LoadView操作步骤如下：
- 编写每系统的容量与性能要求。设定峰值消息率、延迟上限、错误率限制，获批后作为通过/失败阈值录入，使测试结果自动分级。
- 构建对应真实接口的测试。通过Web应用负载测试和API测试驱动订单及市场数据端点，用EveryStep录制器脚本化成员门户互动，确保Web层模拟真实操作。
- 测试达到并超越预计峰值。配置负载曲线类型，容量测试保持预计峰值，压力测试则逐步超越，实现“能否应对当日流量”与“系统极限何在”的评估。
- 从服务区域注入负载。利用多个美国地区地理分布式负载注入节点，测量成员实际连接点的延迟。
- 保存测试报告。导出含百分位响应时间、吞吐量、错误率、负载曲线和时间戳的性能测试报告，归档作为SCI审查资料。未达标时利用报告辅助定位性能瓶颈。
- 按计划复测，变更后复测及业务连续/灾难恢复测试。重大系统变更后及消息量增长时重复容量压力测试，融合到CI/CD流水线中。与灾难恢复测试配合，确保规则1004的测试基于已负载测试系统执行。
LoadView完全云托管，无需搭建或向审查员解释额外负载生成基础设施，其产物正是SCI审查所需，且顺序符合审查流程。
容量和压力测试频率
Reg SCI对部分测试频率有固定要求，其他由风险评估决定。年度审查有明确规则；容量测试则在“定期”范畴内，细节由你决定。
活动 | 最低频率 | 依据或触发条件 |
|---|---|---|
SCI审查 | 每个日历年至少一次 | 根据规则1003(b)确定 |
业务连续和灾难恢复计划测试 | 每12个月至少一次 | 根据规则1004确定，包括指定成员和参与者 |
容量压力测试 | 定期进行 | 依据规则1001(a)(2)的风险评估设定 |
重大系统变更前测试 | 每次重大变更 | 变更生效前 |
随交易量增长复测 | 消息速率接近最近测得极限时 | 容量规划触发 |
规则中对容量测试的用词是“定期”，非固定间隔，故审查员认可的答案须经风险评估支持并有记录证明。实际上，许多实体每年至少进行一次容量压力测试以配合SCI审查，系统消息速率快速增长或波动大者会更频繁，且重大变更或已知峰值事件（如指数调整、大型IPO）前必须测试。审查员更关注节奏是否与风险匹配及是否遵守，而非具体间隔。
Reg SCI要求报告的内容
测试证据不会束之高阁。Reg SCI多项义务要求向SEC备案或向成员披露相关信息。
SCI事件以Form SCI报告
容量引发的停机属于“三类SCI事件”之一的“系统中断”，另外两类为系统合规问题及系统入侵。根据规则1002，一旦责任SCI人员有合理依据认定SCI事件已发生，需立即通知SEC，24小时内提交Form SCI书面报告，持续更新直至事件解决，调查关闭后提交最终报告。无影响或极微影响事件则每季度报告一次，需于季度结束后30个日历日内提交，且规则1002(c)要求及时向受影响成员或参与者共享重大事件信息。
容量测试在此双轨发挥作用：降低需报告事件概率，事件发生时，测试记录作为根因分析报告重要依据。
季度重大系统变更
SCI实体每季度结束后30个日历日内，需提交报告说明已完成、进行中及计划中的重大系统变更（规则1003(a)）。围绕每次变更进行的容量测试，是证明变更发运前已核查的依据。
年度SCI审查报告
SCI审查报告首先提交给高级管理层，随后实体于60个日历日内向SEC提交最终报告及管理层回应（规则1003(b)）。容量及压力测试报告是审查文档组成部分。
记录保存期限
测试报告只有在审查员需要时依然保存，方具备证据效力。规则1005设定保存下限。
SCI实体须制作、保存及保全证明合规的记录。对SCI自律组织，规则1005将其与已有自律组织（SRO）记录规则（规则17a-1）挂钩；对非自律组织SCI实体，则直接设定保存要求。标准是至少保存五年，其中前两年应易于访问。
容量工作意味着需保存的内容不限于测试结论：
- 带日期的性能报告，包括响应时间、吞吐量、错误率及生成它们的负载曲线。
- 每次测试所依据的容量和性能要求。
- 容量规划文件及背后的增长假设。
- 测试发现瓶颈后的整改记录及复测结果。
- 相关的Form SCI备案及SCI审查报告。
将测试配置及结果集中管理、按需导出，使五年保存规则由“临时奔波”变为“轻松查阅”。LoadView存储完成的测试结果及报告，确保提交的文档在两年、三年乃至五年后依然可取用。
了解LoadView如何生成SCI审查所需的容量和压力测试证据。预约LoadView演示，为您的峰值消息率设计测试，并导出审查员所需报告。
结论
Reg SCI未直接提供测试清单，但规则1001(a)(2)明确要求容量规划及定期容量压力测试，并通过年度SCI审查进行核验。关键系统为市场所依赖，标准是系统能否在实际负载下准确及时处理交易。
设定容量和延迟目标，在API及Web层测试峰值及超峰值，记录带日期的报告，随消息率增长复测。LoadView可产出所有上述证据，且是基于您本就应执行的测试，使SCI审查变成递交已有记录的简单过程。
常见问题解答
Regulation SCI是否要求容量和压力测试？
实质上是的。规则1001(a)要求制定合理设计的政策和程序，确保SCI系统具备足够的容量、完整性、韧性、可用性和安全性；规则1001(a)(2)明确这些政策应包括当前和未来容量规划及定期容量压力测试，确认系统能准确、及时和高效地处理交易。负载和压力测试是生成此类证据的实际手段。
谁属于Regulation SCI下的SCI实体？
SCI实体包括国家证券交易所、注册结算机构、FINRA、MSRB等自律组织，符合交易量门槛的SCI另类交易系统，计划处理方及部分豁免结算机构。SEC于2023年提议扩大监管实体范围，边界附近的公司应密切关注。
SCI审查关注哪些测试证据？
审查通常关注：记录的容量和性能要求、重大系统变更前的容量压力测试、峰值及超峰值压力测试、包含响应时间、吞吐量及错误率的测试报告、当前和未来容量规划文档、瓶颈处置记录，以及随交易量增长的定期复测。
SCI实体须多久测试一次？
规则1003(b)要求每个日历年至少进行一次SCI审查，规则1004要求每12个月至少对指定成员和参与者进行业务连续和灾难恢复计划测试。容量压力测试为定期进行，并应在重大系统变更和消息量增长后执行。
SCI事件何时必须向SEC报告？
依规则1002，一旦相关SCI人员有合理依据确定发生SCI事件（系统中断、合规问题或入侵），SCI实体须立即通知SEC，24小时内提交Form SCI书面报告，持续更新至事件解决后提交最终报告。无影响或极微影响事件则季度内报告。
Reg SCI测试记录需保留多久？
规则1005要求SCI实体保存Reg SCI合规记录至少五年，其中前两年应可方便获取。容量工作相关包括带日期的测试报告、测试依据的性能要求、容量规划文档、整改记录及相关Form SCI和SCI审查报告。
LoadView如何助力Reg SCI合规？
LoadView生成SCI审查所需的容量和压力测试证据。它针对面向Web的SCI系统执行真实浏览器负载测试，针对订单和市场数据端点执行API测试，使用可配置负载曲线实现峰值及峰值超越测试，从多个美国区域注入负载，并导出带时间戳的响应时间、吞吐量和错误率报告供审查使用。