系统稳定和安全是命根子

【13551字全文照发】SaaS公司的系统稳定和安全机制——中国有赞投资者交流专题电话会纪要

大家下午好，我是中国有赞IR侯蕾，感谢大家参加我们中国有赞举办的关于系统稳定及安全机制的投资者交流专题电话会，我们注意到本周行业内某公司出现了一些严重的系统安全事件，然后有很多投资人和商家朋友都来询问有赞，比如说有赞有没有这样的问题，有赞是如何做系统稳定和安全管理的？花心思做好这个事情要多少成本？

基于大家的疑问和担忧，我们觉得有责任跟大家就“系统稳定和安全机制”这个话题做一个交流。那么今天参加我们分享的是中国有赞的CFO俞韬先生和CTO崔玉松先生。

大家好，我是有赞的桃子，截止到今天为止，我们关注到的事件应该已经是中国互联网公司历史上持续时间最长的一次宕机了，再往后每多持续一个小时都在创造记录。

所以今天我们分享的主题就是SaaS系统稳定和安全。

昨天晚上有一个朋友问我，他说你一个CFO能讲清楚系统安全和稳定相关的问题吗？

我们有赞有句话叫“真诚的友谊来自不断的自我介绍”，所以开始之前我先简单自我介绍几句：我觉得我非常庆幸也非常幸运，大概在10年前开始在一家中国互联网公司巨头工作的时候，就以一个财务的角色参与过中国互联网历史上非常著名的去IOE的项目。去IOE项目，就是去IBM的小型机oracle的数据库和EMC的存储设备，用我们自研的系统取而代之，还有各种各样灾备机房、灾备体系的建设，还有某云计算的历史性的一个登月项目等等。平常都是以CFO的身份跟大家打交道，其实在有赞我还全面负责有赞的安全跟风控团队。从2014年开始，我们整个团队就在持续对抗着各种DDoS攻击、有组织的黑产攻击，以及各种信用卡盗卡、网络欺诈等安全事件。

今天我们的分享分三个部分。

第一部分，我们希望给大家分享跟系统稳定和安全相关的因素、角色有哪些。大家可能从各种地方都能看到各种各样的文章，但可能都比较术语话化，我们尽量白话的表述来帮助大家去理解这些东西。第一部分会由崔来说。

第二部分，想跟大家介绍一下常见的影响系统稳定安全的事件有哪些，行业里面是怎么去应对的。

第三部分想跟大家交流一下，所谓的删库对于一个商家或者对于一个用户来说，到底意味着什么。

我们先开始第一部分，就先有请我的战友，也是我们的CTO崔玉松先生来分享。在有赞我们都叫他崔神。

大家好，我叫崔玉松。我之前的经历，在创立有赞之前，是在刚刚桃子提到的中国最大的电商公司里面工作了很长的时间，其中有比较长的一段时间也是在中国现在最大的云计算公司里面。我当时加入有赞这家公司的时候人还比较少，所以亲眼见证了很多的过程，所以也是自我感觉比较幸运。加入有赞之后，很多东西开始用得上。

第一部分，我先简单跟大家介绍一些关于系统安全和稳定相关的一些概念，因为这些概念相对来讲，不是这个行业的人来讲的话，相对比较深奥一些，我尽量用一种通俗易易懂的话，来跟大家简单的介绍一下这些概念。

第一个是稳定性的衡量，在行业里面也通常叫做SLA，就是稳定性的一种承诺。

所以我们经常会听到一些术语，比如说“99.99%的可用”。我们日常的对话里面也叫“三个9”或者“四个9”。三个9就是99.9%，四个9是99.99%。但是很少人真正的把它换算成大家能够理解的概念。它其实是一个相对一个服务周期来算，这个服务周期常是“按年”，也有一些会把它按照月来分，通常来讲越底层的公司越把它按照颗粒度分更细，因为这样的话他的保障周期会更长一些，越往上一点它会颗粒度会更大一些。

比如说按年来算，一年365天，如果是三个9，差不多有5个小时左右的不可用时间。如果是四个9差不多只有50多分钟不可用的时间。一般来讲，业界大概会在三个9，四个9其实能做到的其实是非常少的。那么，两个9相当于什么概念？拿我们每个人的工作时间来类比，“两个9”是99%，相当于是大家正常的上班，有双休日有节假日；“三个9”就是有双休日，没有节假日；“四个9”的话相当于基本上是全年无休的状态。

有赞核心的系统里面，其实已经做到了“四个9”，也就是每年大概只有万分之一的时间不可用，换算下来就是3000多秒。

还有一些基本的概念。关于硬件，比如说，大家会经常听到的IaaS层的一些东西，比如机房里面有服务器、硬盘、光纤，对吧？

硬盘大家可能会更有概念，比如说大家在电脑里面都会有硬盘，硬盘是一个最基础的存储单元，大量的东西都存在硬盘里面，硬盘在服务器里面，服务器部署在机房里面，机房一般是由现在的IaaS层的厂商提供的，但也有一些是用自己独立的机房，但现在通常来讲都是由类似于像AWS、华为云提供的这样的一些机房。

国内现在的云厂商主要有腾讯云、阿里云、华为云、AWS、Ucloud，还有微软。然后他们主要是把这些存储资源虚拟化之后，给上层的应用使用，主要是一些互联网公司。

除了这些刚刚介绍的一个关于SLA稳定性的东西，然后基本的硬件的概念之后，还有一个重要的概念就是网络运维。运维其实在国内叫运维，它是一个非常中性的概念，在Google有另外一个叫法叫做SRE，网站可靠性工程师，从这个称呼上来看，它实际上会更明确一些。当然因为国内叫法的运维和网站可靠性工程师之间还是有一点点的工作的差异，但是其实整体上来讲差异不大，实际上都是帮助网站变得更加稳定了。

这里面还有一个概念，就是关于软件生命周期的成本的概念。实际上一个软件，尤其是互联网软件，从出生到最后，它都是有周期的，从生产出来到最后下线的整个生命周期里面，实际上只有25%的成本是花在研发上，就是真正的用来开发软件，而75%的成本实际上都是在这后面保障它的稳定，以及一些bug的修复上面，也就是说，真正的成本其实是在后面。

Google有一篇专门的论文去讲这个，所以他们把运维叫做SRE。也是因为这篇文章，他们自己研究的原因，就是整个的生命周期的一个价值。这里面除了运维或者SRE，还有一个叫DBA的角色。DBA主要就是数据库管理员。数据库管理员是干嘛的，他其实主要就是相当于管了一些最核心的资产，然后只有DBA是可以自由进出的，其他的角色都是不可以自由进出的。他是帮忙去把一些数据库备份，包括取数、维护都是由DBA来完成。

IaaS层的厂商相当于建了一个办公楼，然后又装修好的工位，能够给到我们这样的SaaS公司来租用，需要多少就租多少。比如说有赞租了一层办公室，然后我们的DBA相当于是行政，把一层办公室再分割成不同的办公区域，指派给不同的业务单元和工程师来工作。负责办公室的区域安全，主要是由DBA和运维这两个角色来共同完成。

办公室当然可以是精装修的，也可以是毛坯的。各有各的好处，这取决于你自己的想法和你自己想要的东西。比如说精装修的好处，就是你马上就能用，做的更豪华一点，你马上就能住进去，但是它的坏处就是它的自定义程度就会低一点。做成毛坯的好处，就是你可以按照你自己的想法来设计，但是坏处就是你要花成本、花时间、花更多的精力去装修。它的好处也特别明显，就是通常来讲越大的公司会采用这种毛坯的方式，因为他按照自己的想法去装修更能适合自己的业务。

以上就是我简单跟大家介绍一下关于稳定性相关的一些概念，后面让我们桃子来再继续下一部分。

刚才崔提到的很多概念，比方说可用性、IaaS服务商、网络运维、 DBA、数据库等等。后面第二部分我想讲的是，到底整个影响系统安全跟稳定的事件风控到底有哪些？

在这部分开始前，我想说的是，其实所有人都知道，所有的风险都是伴随着一定的概率，所谓的风控措施，就是将风险的概率降低到一个可接受的水平，或者说当风险事件发生的时候，把它带来的损失控制在一个可接受的水平。当然所有的风控措施都是有对应的成本的，成本要么就是钱、要么就是资源，或者说从终极上来说，其实都是钱。

对于每个公司来说，什么是你可接受的风险水平，都有自己不同的判断，对于降低风险或者说降低风险带来的损失所要付出的财务成本，每家公司意愿和能力都是不一样的。其实这才是导致了不同的互联网公司，保持系统稳定跟安全的能力是不一样的。

所以，从这个层面上来说，互联网公司保持系统稳定跟安全的能力，不仅仅是一个技术能力的问题，它更多的是一个态度和意愿的问题。

白话一点来说，不仅仅是你行还是不行，更多的是你愿意还是不愿意。

先说第一类，就是我们觉得这个行业里面普遍会存在第一类影响系统安全跟稳定的事件，我把它叫做灾害或者不可抗力。从性质上来说，它是一种被动的风险事件。

举个例子，比方说轻一点的，大家经常会听到说某机房断电了，或者说机房的光纤被施工单位挖断了，这都是真实存在的案例。严重一点的也是比较少发生的，比方说一些机房所在的区域遭遇地震了、洪水了、火灾了，也就是机房不可抗拒地被团灭了。这种就是属于不可抗的偶发事件。

这种怎么办？既然是灾害，其实大家都比较经常听到就叫“灾备”，顾名思义就是灾难的备份。所有的数据你一个不够，你就得备份两个。你如果担心备份在一个机房里的数据挂了，那你就数据放在多个地方。你担心多个机房都是同一个云服务商的，你担心云服务商挂了，那你就有两个以上的云服务商。所以这个核心的意思就是你不要把鸡蛋放在同一个篮子里，这其实是行业比较通行的做法。当然不同的层级的备份，其实对应的不同的成本。

有赞是怎么做的呢？在IaaS云的层面，主要的服务商有腾讯云跟Ucloud的两个，而且他们两个相互备份的。而且我们在每个服务商的不同的机房里有备份。也就是退1万步讲，即使一个云服务商出现问题，我们在技术上都可以自动切换到另一个云服务上，并且从技术的角度，从数据的角度，我们可以在5分钟之内基本上恢复95%的流量。在非常极端的情况下，比方说我们遭遇了非常极限的灾难的时候，我们可能最长的时间——按我们现在预估——大概30分钟可以完全恢复。

当然，不同的公司遭遇这样的事情的时候，切换机房的速度，切换不同云服务商的速度，预警的速度，修复的速度，这个能力可能就因为技术能力有很大差异。

当然刚才说的更多的是一个备份的存储的地方，另外一个角度就是你备份的方式。一般分两种方式，一种叫冷备，一种叫热备，我们现在就是冷备热备并存的。所谓的热备份就是数据的实时备份，也就是说你一边生产数据一边就在备份数据了。冷备份是指数据的离线备份，也就是说可能每天或者说定期的某一个时间段去备份。

其实所有的备份想要抵抗的都是一个灾害发生的一个概率。大家说的不可抗力，其实在很多人看来它是一个小概率事件，他确实也是一个小概率事件，所以并不是所有的互联网公司都做了灾备的，有些人可能觉得心存侥幸，可能觉得这种事情反正发生的概率不大，我可能就是99%或者说不会发生灾难的那一部分，或者说有些可能会觉得灾备的成本太大了，财务上觉得不划算，或者说觉得不想做，都有各种各样的原因。

从成本上简单的算，比方，1个备份的成本是1，10个备份的成本就是10，有三个云服务商可能备份的成本就是30。所以成本的投入跟安全系数是相对相关的，当然技术能力的提升可以去优化成本跟备份数之间的线性的关系。无论如何，技术是有成本的；想做好，就一定要重视，要愿意花成本。这就是我想说的第一部分，就是灾难和灾备对应的系统稳定、安全。

第二类，其实大家也可能经常会听到，我们把它归类为网络攻击。第一类刚才说的灾备其实是一个被动的风险事件，网络攻击就是一个主动的风险事件。

比方说，最常见的网络攻击，就是我前面提到的叫DDoS攻击，DDoS是分布式阻断服务的英文简称，DDoS利用攻击器控制大量机器来达到妨碍正常使用者使用服务的目的。

相对用白话一点来翻译一下，比如说一个互联网公司的系统服务是一个城市的交通网络，正常的客户的需求就是在这个城市里正常通行。而DDoS就是人为的在各种交通要道，比方说立交桥、高架、隧道、用车、设置路障，人为的造成了交通堵塞，甚至于交通瘫痪，这种时候正常出行的人就没有办法正常通行了。基于这个特点，DDoS有两个特点，第一它一定是人为的，第二攻击方式有成本的，因为如果你要造成交通堵塞，你需要调用大量的车，租车是要钱的，或者买车是要钱的。所以DDoS就是花自己的钱让别人不爽。

我们偶尔也会被DDoS，这事很烦人，攻击方要花费成本，我们也需要花费成本来应对。

这是网络攻击的一种，我们估计还有另外一种，拖库。

用白话一点来说，就是找黑客溜进你的技术系统里拿走或者复制走他想要的东西，一般的就是数据。大家可能经常在新闻里听到的，就是某某公司用户数据泄露或者什么酒店的入住记录被泄露之类的。人家拖走或者复制走的数据一定是有它的价值的。

这种怎么来防护呢？最基础的就生产网络跟办公网络完全隔离，测试网络跟真实网络的确认，分别部署各种各样的堡垒。比方说你在自己家一定防小偷来入室盗窃，无非就是在家里装防盗窗、防盗门，家里有院子建围墙，围墙上要不要加个电网？你要不要用钢板来加固你的墙体？你要不要装红外报警装置的？你要不要备一些武器来对抗武器入侵？当然这些层面都还是在我们说的防御的层面，就是防它怎么进来。

除了这个之外，对抗这些主动的入侵，我们还有一种方式，我们会组织各种各样的模拟攻击，有点像军事演习。行业内也会做通用的两种方式，比方说有赞自己每个月都会组织内部的团队进行模拟的网络安全渗透，说白了就是让我们自己内部相对比较牛的工程师来攻击我们自己的网络，当然是在测试环境下，以己之矛攻己之盾。目的不是为了测试矛行不行，是测试盾行不行。希望看到的结果就是攻击的矛都折了，盾还是完好无恙。

还有一种是会请第三方叫安全众测。我们每个季度都会做安全众测。我们会邀请白帽子来模拟攻击我们，会按照他们找到的漏洞来优化升级我们的系统。这两种都是像用极端真实的军事演习来模拟战斗能力来提高防护能力。

有些人可能会问说为什么要持续的这么频繁的去做。我经常问我们的一些比较资深的工程师一个问题，就是工程师的技术能力有没有极限，或者说有没有天花板？他们告诉我的是工程师的技术能力是没有极限的。虽然是一句玩笑话，那代表的就是一种趋势，就是技术能力它是随着时间、科学和科技进步的，安全层面需要魔高一丈道高一尺。

今天你觉得自己有一个相对安全的防护能力，不代表明天，后天，明年这个时候还是。所以如果你不持续去迭代、去优化、去升级你的防护能力，今天好的防护水平在下一个时期内可能就是差的。

当然对于系统安全来讲，最最关键的是，我们坚定认为，这个东西不是说天天靠谁在外面喊就喊出来系统安全的，基本上系统安全一定是靠做出来或者打仗打出来的。

我们在系统安全跟稳定方面还会去邀请很多的国际顶尖去做一些国际领先的认证，我先赘述一堆术语。有赞主体的SaaS业务拥有ISO27001信息安全管理体系认证、CSA C*STAR云计算安全国际认证、信息安全等级保护（三级）等认证；持牌公司“高汇通”的支付业务通过 UPDSS银联卡支付信息安全管理标准，信息安全等级保护三级 ，监督保护级等认证。这些认证的证书，我们一直公示在有赞官网的“权威认证”页面。

以上一堆认证，我用一句话来帮助大家理解，就是有赞，今天我们的安全防护水平是银行级别。

前面说了两类安全事件，第三类我想说一下就是服务器的瞬时峰值的超载，这一类其实是常规原因导致的不稳定。

举个例子，大家都比较熟的双11，或者说某个商家在做大促销或者做活动的期间，它的流量比较高，就可能会出现这样的情况。就是瞬时的使用的峰值超过了这个系统能够承载的最大值。

还是打个比方来说，就是一条高速公路平时可能都不太堵车，一旦放长假了，大家都涌过去，尤其在某一个时点，就可能造成交通堵塞。平常大家上下班也会堵车，应对这个情况其实需要去做的就是不断优化系统性能。

今天我们在做的事情是，高速公路上行驶路还是那条路，但是车突然多了起来，流量突然多起来的时候，我们可以通过优化来保证每辆车都快速通行，比方说我们可以优化信号灯，优化交通要道的通信能力，去扩建车道，去优化路面之类。

举个实际的例子，去年2019年双11的时候，我们的订单跟访问的浏览量和访问的峰值差不多是平常的10倍以上，但是我们整个系统没有任何的波动。双11值班的人只是在值班的状态，基本上没有投入战斗。我们去年做的一个事情是动态的去调整了我们系统的峰值。

这里会涉及到一个跟财务相关的问题，因为理论上来说，你想把你的峰值，你的承载能力调到无限大，也可以，只要付钱。但是当峰值过去的时候，你平时流量没有那么多的时候，如果你还维持在峰值上其实是一种浪费。所以这里存在一个平衡，就是你到底在什么程度上去满足峰值的需求，同时又能解决成本的问题。

有赞可以去做到的是动态的调整峰值。基本上是在双11前一周就开始动态调整我们系统的承载能力峰值来迎接峰值。我们做到的是既满足了系统峰值的需要，又实现了满足这个业务需求的成本不过高。

从技术性能上，有赞系统支持每秒6万笔交易，也就是同时6万人在同一秒下单支付也没有任何问题，页面打开仅需1秒。有赞云开放接口数量1000+，日调用量超5亿，吞吐自如。

除了前三个之外，第四类风险或者说是影响系统安全跟稳定的因素，我们把它归类为内部管理，它应该是一种管理因素，或者说人的因素，它包括人为的操作失误、操作错误，或者说人为主观故意的破坏，比如说“删库”，就数据库被删了。

所有的代码都是人写的，所有的系统也都是需要人维护，有人的地方就有风险。

大家可能会问说，这是不是无解？其实也不是，尤其在资本市场朋友一定很熟悉，一个非常简单也经常听到的一个词，就是内控。

他在做的其实是什么？比方说流程管理，比方说前面崔提到的数据管理工程师、数据管理员、数据库管理员和运维管理员，他就需要角色是分离的。有些公司它为了节省成本，它可能让一个人干多个角色的活，看起来好像省了几个人的成本，但其实大大增加了这种风险。

再比如权限的隔离，你生产用的数据库和刚刚提到的备份用的数据库，就应该在不同的DBA手上管理。如果一个DBA管理所有的数据库，你备份了等于白备份。这就像每一家公司在银行账户需要财务打款的时候，一定需要两个以上的UKey才能完成支付是一个道理。

在有赞，CTO崔、CEO白鸦都没有权限，可以用一台电脑、一套账号、一套密码完成删库的动作，是做不到的。

再退一步讲，为了防止这种风险，能不能禁止所有人去删除数据库，这其实也是行不通的。有点像一个厨师做菜，他需要菜刀，菜刀有可能会伤害到旁边的人，但是你不能说因为菜刀有可能伤害到旁边人禁止厨师用菜刀，对吧？

所以这个时候这里的防控的措施就是万一出现菜刀伤人的事件，我们可以怎么去做？万一被删库，其实很多互联网公司都经历过，怎么办呢？

你这个时候要做的就是你找到你的灾备机房的备份，去快速的去启用去恢复你的备份的数据，当然备份恢复的时间跟你的技术能力跟你的数据存储量都有关系，但通常来说差别基本上在分钟级别或者小时级别，最多几个小时级别，几天都还恢复不了是不可思议的，除非还有更多没有公开的信息。

还有很多的措施，来防止这些所谓的人为管理的错误。

比方说，机房的部署，一定需要有严格的访问控制，员工的授权一定需要分角色。还有有一个在产研团队的授权原则，叫最小授权原则。什么叫最小授权原则？就是产研团队授予一个员工的权限，一定不能大于他工作职责的需要。

比方说，还有各种各样在测试环境里需要经常演习各种人为操作，还不单是攻击，还要去演习各种人为操作造成的风险事件，团队怎么去应对。因为你不能保证每个人不失误，但是当出现失误或者造成一定的后果的时候，团队里每个角色他知道该干嘛，他应该听谁的指挥，各种各样的工作先后顺序应该是什么，会不会产生二次灾难？这个时候如果没有灾害演练，没有预演，没有预案，其实真的出现问题的时候，可能逻辑上技术上好像什么都可以做，但对于团队来说，可能他们已经完全失去了战斗能力。

当然最基础的还有一些，比方说，主动的预警跟监测，我觉得这些是行业最基础的，比方说你进入生产网络需要有最基本的操作日志，你必须得做到追溯什么人，什么时候做了什么事情，一旦有异常的操作系统就要自动响应。我们运维团队，他们基本上都是7×24小时在线。多说一句，互联网行业运维团队的工作是非常辛苦的。整个团队要时时刻刻保持在战备和战斗的状态。

还有一类第五类比较特殊，尤其在我们这样的交易类的SaaS公司里面特别重要。

因为商家在用有赞系统，会做各种各样的在线营销活动，发个优惠券、发个代金券、发个优惠卡，而所有的营销活动它都是有实际价值的，都是商家计划好的实实在在的营销预算。对商家来说，它的原意是希望把自己的一些促销让利给消费者，由此来带动消费者的消费意愿，或者扩大整个社交的传播。

但始终在这个行业里面都会有各种叫黑产和灰产。黑色产业的人，他们就像秃鹫一样，永远盯着全网各种各样的营销活动，有组织有技术的盯着各种各样的营销活动，用技术的手段来薅羊毛。把各种各样的营销活动利益最终流入了这些黑产跟灰产的口袋里。

这个问题涉及的是商家的资产安全，对于有赞来说，我们叫做反作弊。有赞过去在帮助商家反作弊上也投入了非常多的精力跟力量。虽然有时候在这些活动上的保护和防控的措施，商家都不一定能感知到，但是我们希望去保证的，除了系统安全，还保证商家的钱用在刀刃上，而不是被这些技术性的、组织性的、薅羊毛的人薅走。

前面这里大概说了五大类跟安全跟稳定相关的风险点以及常用的一些措施。然后第三部分我想请崔来跟大家分享一下，数据库被删到底意味着什么？

因为对大家来说，可能觉得好像说数据被删了没什么概念。所以后面交给崔来跟大家分享一下。

说到删数据库，我先跟大家解释一下，互联网行业数据大概分为几部分。

通常来讲数据分为两部分来存储，一部分就是我们叫在线的实时数据库，通常意义上大家理解的删库的部分。还有一部分的数据是存在我们叫离线数据系统，也就是大家通常认知上大数据的系统。

这两部分数据有什么差异呢？大数据肯定是会包含实时的数据，但是大数据的数据会远远大于实时的数据。以有赞为例，实时数据大概只占到整个数据体量的5%~7%比例，越大体量的公司比例可能会越低。

为什么会这样？比如刚刚前面桃子讲到的关于交易订单，比如说你买一个东西，你下了一个订单，这个订单会存在实时的数据库系统里面。但是在下单之前，你可能浏览了100次，可能浏览了100页，每一页上面可能还会点击了，在每一页上面你还点了三次加在一起就有300次的行为数据，数据量远远大于你刚刚下的那一单的数据量。

所以大数据里面有非常多的关于行为数据，更多明细的一些数据，只有通过这些数据可以反推出来一个消费者怎么买到这个单，从而可以去优化提高购买的转化率，提高营销的效率，诸如此类的一些东西，这些都在大数据的这一层去完成的。

如果是实时的那部分数据库删了，它被删的那一刻开始，接下来在恢复之前，它都不能交易了。还有你的订单被删了，用户有损失、商家有损失之外，实际上它带来最大的损失是履约的损失以及消费者的不信任。

这具体会表现在什么？比如说你这条订单删了，但是你钱已经付了，对吧？但是你再去找这个商家说我这个钱付了，那你这东西给不给我？商家又没有看到订单，你说他到底给还是不给，不给得罪消费者，给他可能又亏本了。

进一步说，你下了一笔订单应该有20个积分，然后这个积分给还是不给，以及这一系列的这些东西，这都会出现很大的风险。所以在系统发生宕机故障彻底混乱的时候，商家和消费者之间会的矛盾会集中爆发，这就是我们认为的叫履约风险。就是他消费者下了单，但是商家没有办法进行履约的，整个活动交付，整个的后台的逻辑都乱。消费者跟商家扯皮，不信任商家，就是要商家的命。

还有一个就是大数据的这一部分，大数据这一部分如果出现了问题的话，它带来的不仅仅是一个商家履约不成功的后果，它会导致一系列的后台的问题。

现在大家都在讲说大数据、人工智能、AI，所有的东西其实都是以数据明细为起点的。比如说像我们要的精准营销，推荐，针对不同人群发送不同的优惠券，都是要靠消费者每一次点击的行为数据，通过一种机器算法来识别的。丢掉的每一条数据都会导致识别的准确度会下降，如果你全丢完了，那就没有什么人工智能和大数据精准营销可言了。所以对于一家公司，最重要的可能就是这个部分。

当然商家这一端肯定也会面临一些损失。因为从他删库的那一刻开始的话，他后面所有的生意就中断了。尤其是像现在疫情期间，大家线下不能做生意，开始把生意往网上转的时候，基本上像我们的一些商家，一天有几百万的交易额。

有赞2019年前三季度GMV是380亿，差不多平均一天1.4亿。实际上在疫情期间，一些传统商家转到线上来，实际上可能还会比他之前要更好一些。所以疫情以及电商的这种模式，实际上给商人们开了一个窗户。然后现在很多地方很多人窗户又被关上，所以我们自己也确实比较忧虑这些商家的生存状况。他们的线上线下都休克了，这也是我们昨天为什么有在业务层面上发了一个公告的原因。希望能帮上忙。

既然有损失，作为一家公司肯定是要对于商家的损失不能视而不见，所以肯定会牵扯到一些赔付。

有赞的核心服务，我们都给予102.4倍的服务期的补偿。如果不稳定一分钟补偿就是102.4分钟。通常来讲，这个行业里面的补偿是超过某一个期限，比如说大家去看几乎所有的云厂商，他们通常的算法是这样的，就是说比如说这个月没满足99%，没有满足三个9，四个9就是他承诺的期限，然后从它没满足的那一刻开始，他给你算钱。

比如说我承诺你四个9，也就是说我承诺你一年宕机不超过50分钟，在50分钟之内我是不会赔的。但是有赞只要宕机一分钟都是会补偿的，所以实际上是我们按照承诺的是按照100%的承诺补偿。

所以不稳定一天实际上就会补偿商家102.4天，按照我们现在的客单价来说，相当于大概3500块钱。如果你宕机一天影响1万个商家，那就是补偿了3500万，如果是10万个商家就一天就补偿了3.5个亿。如果不稳定五天，这个账，没敢算。

2017年11月27日，为了让“系统稳定高于一切”不断地做到极致。有赞推出了“护航计划”，并正式宣布：有赞微商城如果出现系统不稳定影响了客户的生意，就按照不可用时间给予对应 102.4 倍的补偿。这是整个信息服务行业里没有的最最高规格的“承诺”。2020年1月1日，有赞零售、有赞美业也正式加入“有赞护航”。有赞因技术故障对商家的每一次影响，我们都公开、自动、动态显示在有赞护航的官网上，符合护航补偿界定范围的，都有护航补偿公告。因为透明，所以信任。因为信任，所以承担。

也可以一并说说腾讯云、百度云服务不可用的赔偿标准。

腾讯云是低于99.9%但等于或高于99%，赔偿相当于月度服务费10%的代金券；低于99%但等于或高于95%，赔偿相当于月度服务费25%的代金券；低于95%，赔偿相当于月度服务费50%的代金券。而百度云是低于99.99%但是等于或高于99%，赔偿相当于月度服务费10%的代金券；低于99%但等于或者高于95%，赔偿相当于月度服务费25%的代金券；低于95%，赔偿相当于月度服务费100%的代金券。

当然，腾讯云和百度云这类IaaS和有赞这样的SaaS还是有些不一样。有赞在SaaS行业3年前就公布了护航计划，坚持影响做生意就补偿，对自己的严格苛刻，都是源于要让商家安全、稳定、放心地做生意。

这个就是我们我简单介绍了一下关于删库以及数据的基本的一些东西，希望大家能够理解。

最后其实我还想就回应一个问题，很多人也比较关心：发生这样的事件，大家问我说公有云是不是不安全，是不是应该整个行业或者说整个社会就应该回到私有云？

其实这个问题的回答特别简单，就是所有在公有云上遇到的风险和问题，在私有云上一模一样的会遇到。因为所有的架构、协作方式，生产流都是一模一样的。所以，在公有云层面遇到的问题，在私有云层面一模一样的会遇到，但是在公有云层面，有更多专业人、专业的角色一起去解决问题，去维护稳定和安全，私有云的层面只有自己的IT团队来解决问题，而绝大部分想做私有云的客户没有一定的技术能力，更别提一些安全防护的能力，要有也是需要极高的代价（人工）。所以从行业的角度，我觉得大家完全不用担心这个问题。

还想重复一下最前面说的几句话。

所有的风险都是伴随着一定的概率的，风控措施就是将风险概率降低到可接受的水平，或者说将风险事件带来的损失控制在可接受的水平。当然所有的措施都是有成本的，也就是钱，每个公司愿意接受什么样的风险水平，愿意接受风险带来的损失的程度都是不一样的，这就导致了每个公司保障系统稳定跟安全能力是不一样的。所以互联网公司系统稳定安全不仅仅是你行不行的问题，更多的是你愿不愿意的问题。

过去我经常也会跟大家沟通的时候会聊到说，我觉得有赞是一家产品和技术主导的公司，我们的技术非常好。过去大家可能没什么感觉，你们老说自己好，哪里好？

还是打个比方，比方说我们在建房子，系统的稳定跟安全就像房子的地基，这个地基其实大家都是看不到的，大家看到的是说楼有多高，这楼装修的多漂亮，大家不知道这个地基有多深，但只有在坍塌的时候知道。所以其实只有两个人知道，就是造房子的人和灾难知道。

所以，我们始终是把系统的稳定跟安全放在第一位，这是我们有赞的产研团队最核心的OKR。在有赞的内部，我们会把各种各样的业务项目用P1、P2、P3来分优先级，数字越小就代表这个项目或者说这个事情重要性水平越高。只有两类事情，无论是什么时候永远是P0级别的，就是我们的系统安全事件和我们的资金安全事件。

今天其实过去差不多快一个小时的时间，跟大家交流的更多的是系统安全的问题，关于资金相关的问题，我觉得今天可能没有时间跟大家分享，如果大家有兴趣，我们可以下次再跟大家分享。

在有赞团队构成上，过去和现在，包括未来也一直会是，我们的产研的团队一直保持在占总人数的一半以上。其实大家从我们发布的各种各样的财报和路演资料里面都能看到，我们的目的和希望就是以足够充足的研发能力来保证有赞持续的研发迭代能力和安全防护能力。

今天的最后我想再分享给大家一个故事，这个故事就是霸王龙的故事，作为今天的结尾。

很多人都知道霸王龙是有赞的吉祥物，昨天我们在给大家发的ConCall的邀请函里面也有一个霸王龙的水印的图像，很多人可能不理解，为什么你们一个IT公司的吉祥物是一个霸王龙。

在2014年的时候，那时候有赞还不到两岁，我们的系统还不很稳定。不可用的时候，我们的后台显示页面就有一只霸王龙。那时候我们和我们的商家都知道，一旦页面出现霸王龙就代表有赞的系统服务不可用，所以那个时候只要有商家打电话给我们，或者在微信群里艾特我们说你们霸王龙了，你们赶紧处理，我们就特别紧张，当然也特别不安。

所以，霸王龙从过去的历史上来说，对有赞来说，它代表的就是“不稳定”，代表的就是“不可用”，它其实代表了一种耻辱。

我们为了提醒过去的、现在的、未来的所有有赞人，时时刻刻记住这个耻辱，我相信我们是可能是全世界把一个耻辱变成吉祥物的，我们把霸王龙变成了我们的吉祥物，我们把它放在我们办公室的每个楼层，把它做成各种各样的钥匙扣、工牌，然后把它贴在墙上，放在所有大家能想到的能看到的地方。我们就是为了时时刻刻提醒大家，系统安全跟稳定是互联网公司、是有赞的基石，也是永远是第一优先级的。

我们认为，在互联网行业、尤其是SaaS行业，系统的安全和稳定就像一幢大楼的地基，地基不稳、大楼迟早坍塌。但是地基是看不见的，牢不牢只有自己知道，只有灾难知道。

为此，我们始终坚持“系统稳定高于一切”，为商家保驾护航，帮助每一位重视产品和服务的商家成功。

我觉得我们今天的分享时间也差不多，我们今天分享就到这里，大家如果有更多的问题，随时欢迎大家联系我们的IR团队。她们的联系方式，她们的邮箱在邀请函里都有，我们今天的分享就到此结束，非常感谢大家，谢谢！