8. 解决方案

如切如磋，如琢如磨[1]。——《诗经》

本章介绍如何去寻找一个合适的度[2]，去设计简单的解决方案[3]以及相关内容模块。

明确需求[4]

期望的范围（原始需求的目标期望）

详细描述方案的原始需求，并给出目标期望。衡量自己的资源，是否要削减非必要需求或者延缓低优先级需求，确保能够在当前的资源条件下进行实施。例如可以将需求分阶段实施，一期去实行紧急且重要的需求。

适用场景[5]

需求的范围（基础设施、应用、数据等）

原始的需求结合当前的实际情况确定出有哪些适用的场景[6]。例如进行商密改造（负载均衡、API网关、Web服务器、应用服务、密码学库等）；Ipv6改造（线路、路由、安全防护、DNS服务器、应用服务等）；代码扫描（发布系统、源代码控制系统等）；流量监控（多端、进出口流量等）；

需求依赖[7]

风险与资源的范围（预算、人力、技术、项目管理等）

需要什么资源（预算、采购、周期、关键人员、关键技术等），有哪些已知的风险（资源不足、遗留系统、整改有期限等）。衡量已知的风险和实现需求目标的资源，判断是否能够解决，或者是需要寻求哪些进一步的支持。

最佳实践[8]

参考答案的集合（需求、场景、资源、风险等）

方案设计

包含[9]技术架构、流程、运营等，是逻辑架构到上下文架构的具体体现[10]。通过基础设施的组合实现技术方案[11]，同时提供日常操作、维护、特例等处置的参考案例。

验收规范

通过一定的测试用例来判断是否符合目标期望[12]，以及能否维持SLA，具备SOP[13]，符合验收规范后可以进行Sign Off。

参考架构

提供行业标准、行业最佳实践的相应说明以作参考。

项目管理

明确范围，减少待定的过程

从明确需求到具体的适用场景，以及梳理依赖到输出最佳实践的过程都离不开项目管理。上至寻求支持，下至任务分配。即便在整个过程中存在专业的项目经理时，作为安全架构师还是应该能够完成跨团队沟通，通过会议、邮件、IM等形式确定好关键利益人(Stakeholder)、接口人等。简单的来说，务必要求对每一个输入[14]都有一个输出以及减少输出中的待定项。

[1] 诗经中本用于形容君子的自我修养，解决方案也应当根据需求精细打磨。没有充足的理由下当拒绝去使用临时方案。

[2] 权衡，适度。

[3] 解决方案内容需要不同视角支撑、包含业务、技术、功能、实施等。

[4] 安全的需求可能来自法务（合规）、产研（技术）、管理等。明确需求主要是用于确定目标的期望。

[5] 适用场景其实是实际情况中的具体需求。

[6] 例如下文提到的商密和Ipv6改造一期可能是仅支持网络层入口流量。

[7] 需求资源支持，明确职责范围。

[8] 通过组合工具、服务及相关资源去解决特定的需求问题。理论上需要设计2-3种具有明显差异化的架构方案进行对比较为合适，以此选择出最佳实践。

[9] 建议包含，不意味着一定全部具备。根据实际场景而言，大多只包含了部分。

[10] 从Conceptual Architecture到Contextual Architecture，从High Level Design到Low Level Design。

[11] 是否引入了新的模块，新的模块是否需要定制化亦或完全自研，是否符合前文中的架构基础。例如具备监控告警，符合HA之类的特性。

[12] 适用场景的具体需求有没有得到解决，是否符合预期。

[13] 以及其他过程中的相关文档（Policy、Guideline等）。文档化是架构设计过程中的一个主要输出。

[14] 多为项目级别的输入，这些输入进行评估，判断得到一个结论作为输出，有时候可能没有得到结果是待定（TBD），但应该逐步去减少结论中的待定项。例如需要多久进行定期的review，找到谁能够给到支持，是否必要采购什么产品等。