屋外寒风呼啸，大雪飘飞。闲来无事，不如将上周末技术分享的部分内容引申为一篇博客，暂记于此。

无论是正向建设还是反向建设，是由经验出发总结亦或立足于顶层设计。在从策略的制定到技术标准和运营流程的形成过程中，实现或者履行的最终参考往往就是流程的建立。无论是行政相关还是业务相关，例如人事部门管理的入离调转，财务部门管理的账务核算等流程，技术部门的发布变更等流程。这些设计最初经由文档落地并获得认可/批准，其后通过一定的平台形成流程约束后就实现了部分管理的需求。比较常见的平台有Jira、Servicenow之类的，可以很好的实现业务流程管理（BPM），在形式上的体现基本为ticket/工单。

下面简单介绍一下如何正向去设计和优化流程。（反向的话一般是从日常工作出发，将经验中的最佳实践按照一定模式固定下来的过程。很多场景化的SOP基本是反向建设的。）

需求分析与依赖管理

• 不要期待一次性搞定所有的需求。在设计流程时往往会出现来自各个部门的不同需求。同样在流程实现之后，依旧会遇到不同的场景和问题，由此形成了新的需求。而优化就依赖于这种持续的反馈，不断的发现问题解决问题。我们不能期待一次搞定所有的需求，但需要尽量的设计综合性解决方案，能够在实施过程中分阶段去覆盖不同的需求和问题点。而不是每解决一个问题点就需要设计一个方案，大量的临时方案会使得实际场景故障越来越多，系统越来越拉。

• 及时更新依赖项并使需求对齐。这取决于沟通面儿及频次，确保所有相关方都要沟通到位，以及需求的变化在一个方向上。例如不能出现既要信息透明又要信息隔离的需求，这种自相矛盾的既要又要是无法实现的。以架构评审举例，如果这个流程是从零开始建设的，就需要去考虑PMO对项目管理的需求，运维对资源管理的需求，安全对控制基线的需求，研发对迭代及发布的需求以及法务合规等各自需求。并且确保需求在一个大致的原则上。例如安全需要扫描卡发布以实现左移及默认安全，如果某些部门希望能够提高发布效率，尽量避免修复发布前的漏洞。那这种和最初设计相悖的地方就需要多次沟通，以达到一个共同认可的解决方式。

模式融合和系统实现

• 经验中总结出来的不同模式（Pattern）/模型（Model）构成了“所谓”的最佳实践（Best Practice），而长期的最佳实践逐渐形成了参考架构（Reference Architecture）。。这些Pattern可以理解为Rule Set，是由一条条的rule组成。而对于每个领域，都有各自的规律可循（Domain Model）。这些Pattern共同作用形成了System。对于软件架构而言，常见的Pattern有C/S、M/S、MVC、Pipeline、Broker、Plugin等等，对于安全来说Secxuiry， Security Domain Model有SABSA、O-ESA， STRIDE等，而对于企业架构，又有TOGAF等。在分析需求和解决问题的过程中就需要将不同领域的参考架构融合到一起，也可以理解为知识迁移的过程。可以参考上一篇博客里框架融合的部分。千万注意不要先入为主，需要对未知的领域进行多次的调研沟通。

• 系统实现指的是目标能够可拆解、实现过程是结构化的。系统实现的最终结果不一定是一个IT系统或者各种软件，比如在这里指的就是一个流程的建立。怎么去拆解流程，怎么样组合pipeline的节点，顺序等。通过不同Pattern的作用，形成了相应的System。

逻辑层面来说，设计流程并优化的大概思路就是上面所写的了。可以是真正的一个流程，比如说线上变更的工单流程，也可以是去解决问题的一个思考过程。

以办公网安全治理举例(其中终端安全的细节可以参考之前的浅谈终端安全), 终端安全这里就有黑白名单软件禁用的流程，软件统一推送的流程，Admin权限回收的流程，回收后的提权流程，证书推送的流程，数据泄漏后的处置流程，IT的资产管理流程，职工身份的转变流程等等。这里面就有IT和安全部门的协同，还有不同部门的员工办公需求等。那怎么在员工的行为规范中体现这些策略，怎么在实施中包含具体的控制点等就是设计时着重关注的。谁提，谁批，分支到哪，谁实施，哪里记录，哪里审计，哪里实施等。这些就是具体的工单覆盖，把流程统统的变成平台/系统中的Ticket。

再以微服务安全举例来理解下系统化的思考及解决问题的过程。

1. 需求分析：解决X1,X2,X3问题
2. 依赖管理：AWS Cloud，K8S，Service Mesh, Spring Cloud。运维倾向XX，不愿意XX，应用倾向XX，不愿XX，安全XX，YY
3. 模式融合：现有变更流程，现有的发布模式，现有的基础设施，现有的安全管理。分别参考了哪些最佳实践，有哪些可以结合的点。例如上篇博客中提到的安全架构和TOGAF的融合
4. 系统实现：长期方案从基础设施层面去做XXX，解决了哪几个问题。短期方案从应用层面去做XXX，解决了哪几个问题；在长期方案中需要A1,A2,A3,A4 步骤实施，分别怎么解决XXX问题

总结着才突然发现，虽然写的流程建设但实际更多是在描述系统化思考的过程。怎么样具备逻辑的去拆分问题，去组合相应的影响因素然后去解决问题。

当然，系统化思考对于技术工作是有一定好处的。不过也总感觉讲究严谨的逻辑的同时其实也丧失了天真和浪漫的想象。