一、背景

网络安全商品化这个概念，以及商品化与产品化之间的差异，商品化的本质与路径这个是前国电投安全运营负责人王月辉长期网络安全运营工作基础上的总结，研究与理论化。和数世咨询的李少鹏总，我们三个人大概有一个4小时的探讨，个人收获不少，受益良多。对我一直思索的网络安全产品的产品化发展的本质与路径的探讨有很大的启发。

一直琢磨着，要把相关内容消化，梳理总结出来，做个分享。一直没来得及，碌碌无为的忙碌是其中一个原因，酝酿，思索，以及表达也需要时间可能只是一个借口。当然，关于网络安全商品化的相关内容，我只是在自己知识结构基础上的理解和演绎，可能和月辉总本意相差甚远，大家认可我不敢专美，大家批评那一定是我擅自演绎的蹩脚，真正的安全产品商品化理论与实践，大家还是关注月辉总的文章和分享。

二、产品化与商品化异同

从学术上的角度定义两个概念不是我们探讨安全产品问题的初衷，我们还是从目标的角度出发，看产品化和商品化是解决什么问题。月辉总提出的商品化是从商业逻辑自身的规律出发，任何涉及到交易产品和服务的本质，都是商业价值的交付，只有商品是具有客户价值的，客户为之付钱的。我们讨论了两个案例，一个是医用CT的交付，CT的商业价值是检测出疾病的症状指标，而CT的商品化包括安装，调试，人员培训，以及数据分析的模型和应用，包括生命周期的运营，运维与管理，而不仅仅是卖一台CT设备结束，我们也不能把CT直接交付给用户，他是专业的机构医院应用的产品，而安全产品交付的对象是用户，而不是像医院一样的专业机构，但安全产品的复杂度与CT却类似，这就是个问题。另一个是洗脚，洗脚交付的是客户脚部的保养与放松，洗脚的商品化包括药包，水温，技师，时间等一系列标准化的材料，过程，细节，用户同样不需要关注这些细节，享受相应的服务即可。因此，无论从2B还是2C的角度而言，商品化交付的是专业的产品产生商业价值的标准化配套物质，流程，以及用户交互带来的商业价值，商业价值背后是专业的标准化体系。

从网络安全产品的角度而言，从攻击者攻防对抗的场景中定义客户价值，以标准化的方式分解物质，流程，以及用户交互界面，是网络安全产品商品化缺失的关键部分。而这部分是网络安全产品商品化的核心，只有实现了网络安全产品的商品化，才能解决目前安全产业的问题。

我一直诟病网络安全产品的产品力缺失部分，主要集中在交付和运营环节，产品的生命旅程不是在生产完成之后结束，而是在产品交付给客户，在客户侧持续创造价值，直到产品生命周期结束才告一结束。本质上也是认为网络安全产品重设计与研发，轻交付和运营，是导致目前安全产业问题的关键。

产品交付这个环节差强人意包含多方面的原因，问题出现在交付，根因分析的角度可能出现在产品的设计，开发，也可能出现在客户的沟通，协调和商务，也可能出现在公司的组织架构和运营流程甚至公司的战略。而产品交付的影响可能涉及到产品线的决策，公司的利润，商誉，战略，甚至是公司的生死存亡。

运营环节和产品数字化密切相关，对于传统的产品而言，产品交付给客户，唯一的链接可能是保修期内的免费维修服务以及保修期结束的付费维修服务。但从数字化产品的维度来看，产品交付给客户，可能只是产品生命周期的初期阶段，提供的服务并不只是产品运作质量的保障，产品的硬件部分只是终端，产品的软件部分和运营数据才是产品的关键资产，厂商需要持续的运营产生产品的最大价值，这个运营包含两个部分，一是网络外部性带来的模型优化，在关键功能上提升客户价值，一是数据运营，网络效应的数据融合带来涌现的价值，功能优化的创新和质量的提升。而网络安全产品，恰好是典型的数字化产品，运营阶段的价值同样是关键价值。

我在想，我和月辉总虽然概念可能存在差异化，但从理念上来讲，网络安全产品在产品交付和产品运营两个阶段，未能体现数字化产品的特性，在客户价值的变现环节出了问题，导致安全产品市场的发展限制，是当下网络安全市场的关键问题。这个理念应该有异曲同工之妙。

三、产品交付的问题与解决路径

1、产品价值定义

如果把一个产品的生命周期看作一个产品与客户的旅程，产品定义的起源应该是商业价值，即解决什么客户问题，创造客户什么价值，从这个角度来看，我认同月辉总的观点，要做场景的分解，定义好产品。

有些传统的网络安全产品，我们是可以找到清晰的定位的，例如防火墙，防病毒，防火墙是解决网络的边界控制问题，防病毒是查杀病毒，解决病毒破坏问题。但有些创新领域的产品概念就差强人意，例如API安全，你是解决什么安全问题，有的是用来解决API数据泄漏的数据安全问题，有的是用来解决API的认证，授权，治理的问题，反正大家是通过API流量的获取，然后通过协议解析和内容解析，分析其中的脆弱性和威胁，从而发现API治理的风险和数据泄漏的风险，检测和监测实时风险，实现脆弱性和事件预警，这个能力是从安全业务和技术的角度出发定义的安全能力，从商业价值的角度和产品定义的角度，能够给客户带来的产品价值存在模糊和不确定。这在产品交付的环节，容易出现边界问题。

这是第一个需要关注的问题，产品的定义与场景和问题的关系，如何避免以安全能力为切入点定义产品，导致安全能力解决多场景安全问题的价值复杂化，引起产品和客户对价值边界的分歧，造成的产品交付风险。

2、产品非功能设计与研发

产品的功能设计部分无需多言，产品的竞争力不能局限于功能设计，所以当安全产品鼓吹自己的技术优势，算法优势，模型优势等技术核心能力优势时，优越感无可厚非，但一定不要忽视了核心能力优势之外的产品核心优势。

老外的产品有个很有意思的情况，涉及到我们认为的核心技术能力的，往往并不敝帚自珍，以开源的方式获取外部资源共同打磨，反而是我们认为的通用的管理和用户界面能力作为产品化的卖点，这背后的含义在于专业能力是网络安全产业关注的问题，而用户界面和管理能力才是客户解决问题的关键触点，才是产品化的关键核心，才是需要精心设计工作界面和流程的产品核心竞争力。

安全产品涉及到在线的检测和监测能力，甚至具备在线自动化决策与处置能力，与业务系统集成和串联混合部署成为主流。这个时候，产品的健壮性，鲁棒性之外，三个核心能力需要具备。一是故障自动By Pass功能，不要成为业务可用性的唯一故障点，二是agent，策略和插件的灰度升级能力，不要全部流量的大开大和，三是一键回滚，敏捷开发和部署的关键，在于升级的流程要支持一键回滚，不要让升级变成要命。

3、产品交付的规划与设计

产品交付涉及到客户的环境，人员，协作，流程，制度等一系列复杂的因素，缺少规划，布局和项目化管理，很容易演绎成一场噩梦。

安全的专业性决定了很多企业的安全人员难以具备安全产品的专业部署和操作能力，缺少全面的培训和运营支持，很容易让上线的产品成为摆设，记得看过一篇报道，不少企业的安全产品购买后以默认策略空转，甚至有不少企业束之高阁，不产生价值的安全产品，前景必然堪忧。

而侵入式安全产品。例如，无论是容器化环境的Agent对基础设施的侵入，还是Iast、Rasp等产品对中间件的侵入，都面临着协同的问题，跨SRE、基础架构部门的协作成为必然，如何在侵入对性能和安全的影响层面在不同职能部门达成共识都是不小的挑战，很多项目因此无疾而终，实属可惜。

当然，每个客户的情况不同，每个产品的需求也不同，需要产品交付部门关注的是工程化的思维和标准化交付流程的调研，规划，设计与治理。

4、产品交付的组织架构与流程

产品的用户价值旅程理论涉及产品与用户的交互设计的重要性，产品的成功除了标品外，任何价值的创新与交付，在产品定义，需求调研和设计阶段甚至就需要典型客户的深度参与。我这些年与许多安全创业公司的合作，理论上都是一个产品共创的旅程，我对产品符合度60%以上的产品，在产品战略与我们需求未来发展的贴合度在90%以上的产品，开启合作，在满足我们安全需求的同时，也是帮企业完成产品的迭代升级与产品化过程。但这毕竟是零散的个案，甚至对于安全企业而言，只是CXO的个人影响力体现，从产品的客户旅程角度并没有组织架构和流程的标准化支撑。

客户参与甚至是用户参与如何作为产品标准化流程这个问题可以好好探讨。从交付的角度而言，产品线，销售，售前，实施，售后的组织分工与整合如何在组织架构和流程中实现最优解，也是需要关注的关键环节。“销售与售前挖坑，产品线规划与排期，实施和售后挨骂”情景并不少见，这是客户完整旅程的铁路警察各管一段带来的弊病。

但在产品线闭环是否可以解决问题，产品线闭环是否会带来人员的冗余和成本的飙升，既需要是实践中验证，也需要对制度和流程做实时的检讨，说到底还是个管理问题。闭环与协作没有对错，只有在制度、流程、执行能力基础上的优劣，说实话，表现优秀的，看到的不多。

有次，和某厂商朋友开玩笑，要设置一个客户成功经理（CSO）来负责客户从商机发现到产品交付运营全周期的负责人。厂商的朋友说，他们关键客户有这个角色，可能我不是关键客户，没有感受到这个角色实际的价值，但我想这个角色未必是针对某一个客户的，应该是站在所有客户的角度来不断检讨和反馈客户旅程的对所有客户成功负责的角色，需要解决的是组织的流程与制度问题。

本来想全面写一下产品化和商品化这个话题，写完了产品交付，告一段落，关于产品运营，命题更复杂，有空再写。

声明：本文来自IT的阿土，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。