投资之前，先选对 HSM。

架构会将应用、管理、备份和密钥保管彼此分离。分区是一种逻辑上的隔离，但并不能替代所有组织层面或物理层面的隔离。我们会明确哪些密钥允许复制、谁可以扩展集群，以及各站点之间存在哪些依赖关系。一旦 HSM 出现故障，应用不得在未察觉的情况下切换到未受保护的密钥文件。我们会针对具体模块核查证书状态和 Security Policy；仅凭产品名称或算法验证是不够的。

在最终审批之前，我们会使用计划采用的客户端对接方式，测试典型操作。测量内容包括约定负载特征下的吞吐量、延迟和错误处理。测试结果中还包含关于增长、许可和运维方面的假设。作为起点，我们需要应用概览、现有密钥类型、站点要求，以及您的组织实际必须满足的证明材料。

网络型 HSM 可以为多个应用提供集中式的密码功能。此时，网络路径、身份认证和租户隔离都会成为架构的一部分。PCIe 板卡将功能更紧密地绑定在主机上；第二台主机则需要单独的可用性方案。对于托管服务，我们会核查可用的 API 以及管理职责的划分方式。我们不会仅凭采购价格做出这一决策：运维投入、可达站点、维护窗口以及未来的更换可能性，都属于比较范围。

在试点阶段，我们会描述一个完整的业务交易：哪些调用会到达 HSM，每笔交易会产生多少次调用，以及在什么情况下算作响应超时？除了平均值之外，我们还会记录高百分位延迟以及负载高峰时的表现。仅测试单次签名，无法反映并发客户端、连接建立过程或节点故障的情况。您将获得实测条件和剩余的性能余量，从而确保采购决策建立在有据可查的负载特征之上。

未来将有多个应用通过共享基础设施完成签名。OTOKO® 会将密钥和职责分配给各个应用，核查所需的机制，并比较共享平台与独立实例两种方案。在试点中，我们不仅测试签名成功的情况，还会测试权限缺失、会话资源耗尽以及节点关闭等情形。最终得到的是一个可靠的架构决策，包含集成工作量、许可需求和尚待解决的依赖关系，而不是笼统地推荐购买最大型号的设备。