（本文比较偏产品，不涉及技术细节）

上一篇文章说到，企业安全建设后期都会有各种各样的平台，比如 WAF、HIDS、SOC、SIEM、SOAR、SDL 等，在大部分互联网公司里，这些平台都是独立的，由不同的团队开发维护，这就造成一些问题：

1. 许多业务需求或功能需求高度类似、通用化程度很高（比如黑盒和白盒的任务调度，HIDS、WAF 的规则管理），但是由于没有统一的规划，大量的系统重复开发、重复建设，导致复用性低、效率低、人力资源浪费、用户体验不统一。
2. 早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新产品的拓展过程中，系统没法直接复用，甚至没法快速迭代。

为了解决各种平台割裂，数据不能打通，操作无法联动的问题，我们决定做一个安全中台：

资产维度

收集公司所有安全资产，打通资产之间的关联，设置安全基线，自动化发现和防御潜在威胁。

例子：

1. 某合规同学想知道某个产品的服务器安全配置是否满足等保要求，该同学在例行基线检测结果中筛选出该产品的服务器，并生成基线扫描结果的报表。
2. HIDS 发现某个服务器尝试连接外网域名，查询威胁情报后发现该域名是活跃的 DGA 域名，生成高危事件，Oncall 同学收到告警后发现该服务器近期存在其他异常事件，于是选择立即阻断该服务器与外网的连接，网络访问控制系统自动联动添加了 ACL。
3. 某个架构同学查看自己的安全资产时发现有部分主机未安装 HIDS Agent，导致安全资产处于风险状态，于是主动联系基础安全的同学部署了 HIDS。

能力纬度

提供公共组件，避免重复建设；整合安全能力，体现能力价值，安全事件可以关联分析。

例子：

1. 某个同学新开发了一个安全扫描能力，只需接入安全中台即可获取需要扫描的资产列表，同时可以调用规则引擎进行实时分析，生成的安全事件由编排规则自动化处理和响应，最后可以得到默认生成的统计图表和报表。
2. HIDS 检测到某个服务器的敏感文件被修改，查询该服务器关联的域名近期的事件，发现存在外部漏洞扫描行为，相关事件自动升级成高危，并生成攻击路径供运营人员分析。

用户维度

安全能力融入研发流程，员工可一站式处理与自己相关的安全问题。

例子：

1. 某研发同学 DevOps 上线时在安全白盒扫描节点被暂停，发现是代码存在 XSS 漏洞，此时代码仓库对应版本被标记禁用，只有修复通过发布新版本后才能继续上线，同时该同学为了保险给代码仓库关联的域名一键开启了 WAF 保护。
2. 某人力同学收到终端安全提醒，发现自己的电脑被检测出病毒，该同学根据工单的指引，查看知识库的解决方案，自行删除了恶意文件，并在工单上联系 IT 同学协助安装杀毒软件。
3. 某安全运营同学发现有部分安全事件属于同一种威胁，该同学根据可视化的规则生成工具编写了事件处理策略，将这些安全事件自动合并到同一个工单中跟进处理。

管理维度

业务线和产品负责人能直观了解负责产品的安全状态，发现存在风险的薄弱环节，针对性的提高产品安全水平。

例子：

1. 某产品负责人发现自己负责的产品安全评分比其他产品低，查看详情后发现是 Web 漏洞比较多，于是要求开发人员接受安全培训，并主动要求接入白盒扫描和 WAF。
2. 安全月会上评估合规风险时筛选出未进行等保的产品，讨论解决方案。

---

和其他中台产品一样，做安全中台，即需要从上而下的推动和明确的整体规划（组织和战略），否则很可能陷入需求的海洋里，还无法得到合作团队的支持。

举个例子，如果决定某个团队负责中台建设，那么这个团队应该提前提供产品 RoadMap，并和相关团队（业务方）达成一致。如果无法达成一致，业务方决定自己做，需要提供技术架构和未来融合的成本和计划，中台方在设计和规划产品时也需要考虑共建能力的架构支撑（如 API 化、插件化或功能预埋）。

做中台最难的可能不是技术，而是认知的转变，知乎有个回答比较好：
互联网公司中所谓中台是怎么定义的？

一方面，是思维的差异。

很多产品经理并不是从一开始就从事中台相关的事宜，也不是一开始就有中台这样的定位。更多情况下，他们是从前台业务部门，或者以业务为导向的产研部门转型到中台产研部门。

这时，其实要面临很大的思维方式、做事方法的转变。

在业务部门或者以业务为导向的产研部门，最核心的目的就是达成业务目标，要求你速度足够快、功能高效地解决当下的业务问题，当前业务发展的效率是最关键的。

至于说，这个功能将来有没有可能适用于别的场景，有没有可能解决别的问题，这个问题实在是没那么重要。

但是，对于中台不能如此。

对于中台产品经理来说，必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。

这些问题，是中台部门需要思考的问题。这是思维上的差异。

另一方面，是环境的变化。

当你在业务部门的时候，响应业务是相对轻松的。但是，在中台部门，响应多个业务，就没有那么轻松了。

就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候，你只要和对接的业务人员沟通清楚需求就OK了，毕竟，你只要了解这一个或对应的多个部门的业务需求即可，业务目标相对比较明确。

但是，当你需要响应多个业务部门的时候，就没有那么容易了。

你会发现，同样一个需求，A部门的流程和B部门流程完全不同，或者，流程是相似的，但到具体细节的时候，却有很大差异。

更可怕的是，同样一个问题，由于业务的发展阶段不同，对于问题的态度也全然不同：有的部门业务已经非常成熟，自己流程也很清晰，所以不太希望你来调整他们现有的流程；但是，有的部门还处于探索期，还没有遇到你提出的问题，可能压根就不理你。

这时，对于中台产品经理的挑战就非常大。他们可能会将大量的精力耗散于不同部门之间的沟通协调，反复对同一个需求进行确认，很长时间没有明显突破。

这个时候，就要求中台产品经理有很强的沟通、协调和协作能力。并且，因为他们接下来要做的解决方案，是要服务于多个业务。这个时候，需要中台产品经理有很强的逻辑思考能力，看到不同需求之间的共性需求，并提炼出一个产品化的解决方案。

甚至于，对于一些尚未遇到这个问题的业务部门，可能还要帮他们前置地思考解决方案。这又很要求产品经理的逻辑思考和抽象思考能力。

既需要沟通协作的软技能，又需要逻辑抽象的硬思考，这可能才是中台产品经理最有挑战的地方。

最后分享下之前和一个产品同学关于平台和中台的讨论：

1、中台和平台的区别
2、做中台的时机和条件
3、如何平衡业务需求和中台自身需求
4、如何在需求不明确的情况下抽象出标准化
5、其他团队重复造轮子怎么办
6、中台的价值如何体现
7、如何看待阿里现在拆中台的行为

关于上面这些问题可以简单说下我的理解，不一定正确

关于第 1 个问题中台和平台的区别，其实我认为中台不是一种固定的产品形式或者架构模式，而是一种「标准化」的思维方式，他们之间不是一种比较关系，如果多个平台之间的能力存在共性意味着可以进一步下沉，把共性能力标准化后就是所谓的中台，这种思维方式在很久之前就存在，只是放到互联网上大家取了个名字叫中台，而这种思维方式落到具体执行其实是度的问题，如果过了，影响了业务灵活性就要拆，如果不及，做不到横向支撑就要建或者合。那跳到第7 个问题，对于阿里拆中台，因为不清楚阿里具体的中台建设情况，所以也不好评价，但是我相信阿里的目标一定不是去中台，更多还是度的调整，包括做一些细分、架构调整等，来更好的支撑业务，离业务更近。

第 2 个问题对于做中台的时机和条件，我认为核心是规模问题，绝大部分场景都能标准化，但不是所有场景都需要标准化，在于场景覆盖的规模，因为标准化就意味着成本，比如有一家公司的业务是拧螺丝，如果规模很小只需要拧一两颗螺丝，那靠人工就可以完成没必要标准化，如果公司要服务很多客户每天拧成百上千颗螺丝，这时候与其招一批人来拧螺丝，倒不如选择招一批人来造拧螺丝的机器，成本可能会更低，而且能力一旦做了产品化沉淀是可以指数级横向拓展的。对于时机问题就看这家公司计划以及未来能覆盖多大规模了，有些公司刚开始拧一两颗螺丝，但是目标很大相信未来一定会覆盖更多，可能会未雨绸缪，提前做标准化建设，有些公司可能到了一定规模发现扛不住被倒逼做标准化建设。而在字节这种已经有足够体量并且业务丰富的非常高的公司，其实考虑这类问题就更加简单了，因为规模一般都足够，像基础的消息系统、订单系统、账号中心、风控中心等等这些都是可以标准化的。对于条件可能就是更现实的资源问题了，没有资源那就需要看怎么说好业务故事争取资源。

第 3 个问题，还是看具体业务需求的 ROI，中台一定是支撑业务的，不存在中台自身的需求，纯技术建设也一定是为了未来更好的支撑业务，这里面优先级的判断可能不太好展开。

第 4 个问题，如果需求还不明确意味着在行动前需要先明确需求，否则不要轻易行动，中台是支撑业务的，只有先了解清楚业务场景，才能做场景抽象，可以拉上业务聊聊，还能通过调研多方面收集信息。

第 5 个问题，这是个很复杂的问题，如果要归因原因可能有这么 3 类：
1、有平台已经做了建设，但是其他团队不知道，这是信息 gap 问题。
2、知道其他团队在做，但是无法满足自身业务诉求，经过各种资源、排期时长、成本等考量还是决定自己做。
3、知道其他团队在做，而且做的很好，但是屁股决定脑袋就是要再造一个。

其实对于 1、3 的问题需要靠字节的机制去解决，重视中台建设，并且为中台提供信息打通、管理、约束的产品能力，才能根本解决，而对于第 2 个问题可能就需要在字节做好机制优化的基础上，确保承接中台的团队有足够的能力做好中台的建设，现实情况是很多时候大家对中台产品的投入和重视度都很低，很多中台建设靠技术自己搭建，没有 PM 没有 UI，实际上为什么很多公司有中台团队但还是在重复造轮子，就是因为很多时候中台项目离业务很远，支持的能力和业务实际需求不匹配，又因为缺少配套资源导致落地的质量比较差，特别是一些对用户侧的页面，可能会满满的粗糙感，就像是比较常见的“内部系统风格”，但是这在业务视角可能不会允许这样低质量的页面对外，认为中台团队一定要是一个对用户体验有着高敏锐度和高要求的团队，因为恰恰要对很多不同的业务负责，并且面向很多不同业务的用户，否则承接不好业务就会导致“一个业务一个中台”，其实是在考验中台团队的能力。如果中台能力做好了，在字节建立机制前，就需要靠自己的努力去拉客，扩大业务覆盖，树立唯一中台的角色，当然如果能得到负责人的支持至上而下去推动，这一步会更加顺畅，有时候中台的确需要至上而下的统筹和推进，否则会是一件很累的事情。

第 6 个问题，结合中台能力解决的问题来定义价值评估指标，的确比较难一句话说清楚。