近日，来自国内优秀的电子签约平台上上签创始人万敏，发表了一篇关于《再换一张画皮：混合云是任人打扮的小姑娘》的深度长文。在文中，这位创始人指出，即便是投资人对电子合同头部企业的伪混合云都难以分辨，而一些使用传统OP系统伪装的“混合云”系统是假SaaS，电子签约行业最需要的是诚实与契约精神。

前言：有时候觉得在一个鱼龙混杂的市场里当投资人当真不容易，因为总有无良企业绞尽脑汁、铆足劲披张画皮去骗他们从LP那里辛苦募来的投资款。

最近行业内出现了大量把“传统软件OP模式”包装成“适合中国市场的混合云”的问题文章——其实这种方式可以理解为，有问题者在自身企业巨额亏损、收入暴跌、负增长的环境下，在从来就没有几个SaaS头部客户的生死压力下，东施效颦的把戏。

01 混合云的通用概念

到底什么是混合云？

根据Google Cloud对混合云（Hybrid Cloud）的定义： “混合云是指应用在不同环境的组合中运行的一种云环境。”

Redhat在其官网上对混合云（Hybrid Cloud）的定义是这样的： “混合云是一种IT架构，在两个或更多环境中进行某种程度的工作负载移植、编排和管理。”

随着云概念的普及与云服务成为全球的趋势，公有云中国市场规模高速上涨，SaaS成为各种云服务中最有前景的选择之一。混合云应时而生，软件行业一般理解的混合云，是指公有云和私有云之间组成一个网络互通的基础设施架构，其核心价值在于“数”、“用”分离，也就是可以将企业的关键“数”存在私有云，而“应用”存在公有云端。这样既解决了对于“数”安全的关注，又能发挥出“应用”在云端快部署、弹性拓展、敏捷迭代、广泛链接的诉求。

因为“应用”一旦在客户本地，就会遇到这些应用的升级、维护、拓展的问题，本质上就是软件模式OP的问题。那些传统软件企业遇到的问题和瓶颈，都会重现。

02 电子签约行业的混合云

与软件行业通用的混合云不同，在电子签约行业，考虑到合同文件等信息作为企业的机密数据，一般部署在企业内部的应用只能单向请求部署在公有云的服务，所形成的混合云是一种单向请求的“软件应用架构”。这与软件行业一般理解的公有云和私有云之间网络互通的混合云并不相同。

在电子签行业的混合云架构下，混合云的服务能力是由两个部分提供的：

（1）本地化应用

（2）云端平台

上上签的混合云是基于云原生SaaS架构，以相对标准化和易维护的方式把合同数据存到客户本地，解决部分客户对数据原文的物理占有诉求。即便如此，上上签混合云仍在收入占比中极小。

上上签的混合云实际上是分布式系统。在客户本地的不是私有云，而是一个文件存储节点。也就是说，这种仅仅在客户的内网中，部署了一个用于存储、处理合同文件的文件节点而已，因此在架构上，上上签混合云和上上签的公有云系统并没有任何不同。

如果将上上签的电子合同SaaS系统比作Windows操作系统，上上签的公有云不过相当于D盘，而客户的“混合云”，仅仅相当于E盘、F盘……而已。当操作系统有更新的时候，D盘、E盘……是根本就不需要动的。上上签通过一系列设计，将合同文件的存储分离开，用时髦的话讲，是“存算分离”，一切计算包括但不限于签名计算、存证、公证，甚至UI，通通都在上上签的云端完成，合同签署页面、动态模版系统、证书系统、存证系统等系统有任何更新升级，99％的情况下，用户都不需要更新所谓的“混合云客户端”，上上签推出任何新功能，客户也立马可以使用到。

因为只是一个文件节点，客户方自然也不需要什么复杂的维护，不需要庞大的专业的运维团队，这样的解决方案才是真正能帮助客户在电子合同领域上实现“降本增效”的。这才是真的SaaS，用户随时都可以使用最新功能。

03 如何识别伪混合云

关于“全网络互连互通”，以大家都非常熟悉，每天都在使用的“邮件系统”来做一个生动明晰的例子。

邮件系统必然是互连互通的。因为有统一的电子邮件数据的格式标准，如SMTP、POP3、IMAP等。电子合同是否也有相应的标准协议呢？这里需要注意到一个区别，也就是邮件是单向数据发送出去以后，对方是不需要在原数据上操作的。

而电子合同则不尽相同，合同数据从甲方系统发出去之后，乙方仍然需要对原合同数据进行操作，比如填写一些业务字段，进行电子签章的操作，这些新增的数据，也是基于原电子合同数据进行操作，而不是一份新的电子合同数据。这就是说，一份电子合同，发到对方手里以后，对方还要继续在这个合同上操作盖章，并不能在数据层面处理成一个全新的合同，仍然是旧合同。

可见，电子合同并不能像电子邮件一样，通过“数据格式标准”的方法达成互连互通。那么，电子合同怎么才能达成互连互通呢？只有一个答案，就是用统一的SaaS平台提供商。

多数传统电子合同厂商自身是清楚这个“局域网互连”和“互连互通”的区别的，他们当然也非常想做真正的互连互通。他们是如何宣称OP也可以互连互通呢？

电子签名／章OP厂商某企业对于互连互通的“处理”，采用的方式是“复制账号数据”。用本地的账号体系，通过把云端的企业账号数据复制到本地来实现连通。

如上图所示，例如A公司是本地化定制化的大客户，B公司也是本地化定制化的大客户，为了OP大客户可以向电子签约SaaS平台上的云端客户发起合同并签署，唯一的技术手段就是把SaaS平台上的云端客户的账号分别复制一套到A公司和B公司的本地。这样A公司就可以对SaaS平台上的企业发起合同并且签署了。B公司同样如此。

但要注意的是：

a． A公司和B公司，两家都是本地化，彼此之间不能签署。

b． SaaS云端客户依然无法主动给A公司和B公司发起合同并签署。因为账号是复制到本地，云端要发起的话，还是没法互连互通。

所以这张网并不是真正的互连互通。只有所有的客户都在云端，才可以令企业之间真正互连互通互信。

《天印6．0重磅升级，全面领跑中国电子签名市场》中有这么两段话，可以看出这种“混合云”方案自相矛盾，识别这是切切实实的伪混合云。

原文如下：

“其三，混合云模式之下，企业放在云端的数字证书和签章可以被复用，不需要反复验证，可以极大提升客户签约效率。随着天印6．0的发布，以混合云为基础的签约网络将有望快速织就。一方面，与公有云SaaS模式相比，天印6．0采用的混合云让企业的签章与核心数据都可以在本地保存。”

我们可以清晰地看到，这个伪混合云方案中，云端有一套独立的数字证书和签章，本地也有一套独立的数字证书和签章。也就是说，某企业“公有云”和“本地化OP”并存，是两套体系。

在某企业的这种模式下，所谓的“混合云”把本地签章系统和云上SaaS客户试图打通，采用的是把云端账号复制到本地的做法。实际上，这个签署过程中，数据的生产、处理仍然是在本地，只有传输到云端。那么，对于各家企业而言，这意味着要把自己的数据交给签约的相对方企业，自己的数据在对方的系统中生产和处理，这样显然有着严峻的数据安全问题。

因此，这种伪混合云对所有企业客户，尤其是大企业客户来说，很明显地存在着印章外泄的安全问题以及文件零散管理的问题——

复制账号，指公司公章也被复制到另一家企业的本地局域网，意味着在云端被复制的这家企业让自己公司的账号体系与公章全都放置在了自己相对方企业的系统中去处理，存在巨大的用印安全隐患。众所周知，凡是对自身印章安全管理有基本要求的企业，都不会接受这样的方案。

同时，所谓的复制账号的互通后，外部的企业和外部的人也能访问这家客户本地的数据，这跟本地化本身的诉求“不能被外界访问本地数据”也出现冲突。

也许，在5年后，地球人可以自由移民火星，但是在电子合同领域而言，不要说5年后，就算是10年后，OP也不可能互连互通——因为商业和技术的底层逻辑让其无法互通，以及网络效应的先发优势是惊人的。那时候的电子签约赛道早已被真正互连互通的平台一统江湖。

真正的SaaS可以实时享受产品迭代更新、降本增效，而伪混合云则和这些完全不沾边。

SaaS，是云计算的一种形式，顾名思义，它是以软件方式提供服务，核心是服务。而传统软件的成本是由软件维护成本、软件开发成本、IT基础设施的成本等等构成的。在混合云模式下，其总体成本是由本地化应用涉及的规模决定的，这种混合云模式下的本地化应用也是如此。

所以混合云的使用和维护成本高低，不取决于混合云这种模式，而是取决于在混合云模式下，OP本地化部署的应用涉及的功能规模和部署规模大小。

那么某企业声称其天印系统是一个混合云系统，我们可以看一下其本地化的部分规模究竟是怎样的，答案就会显而易见。首先在搜索引擎中所找到《天印电子签章系统产品使用手册》多达141页，这其中大部分都是本地化的功能，本地化的功能规模相当大。

另外在《天印电子签章系统产品使用手册》明确写到：“系统采用微服务模式，间可能减少服务之间的耦合。并且提供丰富的API接口以及控件，满足企业用户对接的扩展性。并且支持一定程度的客户定制化需求。”

也就是说，天印在本地部署的不止一个。所以天印系统在本地这一侧的系统还是非常复杂的，维护成本相当高，压根不能帮助用户达到“降本增效”的目的。SaaS之所以受追捧，不就因为它从本质上为用户实现了“降本增效”。

根据贝恩公司《2022年混合云市场展望》报告，2021年有20％左右的CIO会在本地化向云转型过程中，提到会考虑混合云方案。混合云作为重要的客户方案，是一种依赖客户偏好，保证数据安全同时升级到SaaS产品方案；而不是借助“混合云”概念的私有云本地部署OP方案。但现实中总有厂商利用子虚乌有的案例，强行将本地化方案包装成“混合云”方案。如果连方案都不诚信，怎么指望公司能够诚信呢？