TICA 2019 国际化业务的稳定性实践

张国顺：大家下午好，我来自阿里巴巴国际速卖通的张国顺，花名果老，今天跟大家交流一下国际化业务测试下的稳定性测试。这里面有两个关键词：国际化业务、稳定性测试。稳定性的定义，在我看来是稳定性是正常运行过程中的稳定性的保障的专门技术领域。而国际化业务在最近一年多，不管在新闻还是在哪里可以看到政府提出来的概率非常高，就是我们很多头部的互联网公司在今年的财报里面，大多数的公司都会提到他们在海外业务的发展情况，他们在国际业务的营收是什么。因为在此之前很多年里面，大多数的头部公司都在靠国内的红利市场做营收。随着中美贸易战打的越来越激烈，传统的贸易进入相对瓶颈状态，相关的国际化业务就成了整个政府希望大家能够打出去，能够在海外赚一些除了现在低附加值的、传统的、加工密集型的赚外汇的手段，希望有一些更高大上利润率更高的国际化业务走出来。所以最近两年内，抖音和微信都在发展国际业务，所以整个国际业务成为目前技术和发展上比较热的话题。国际化业务在阿里巴巴集团内最近一年多的时间，也做了很多次技术交流，在这里借机会跟大家做一下探讨。我会从国际化业务发展的架构严谨和挑战介绍背景，另外从稳定性治理的组织结构，从飞虎队到SRE来发展安全生产。到最后，大家看稳定性跟架构的关联更高，我们在稳定性测试里面能做哪些事情？就是测试在这里能发挥哪些价值，最后做一下相关的展望。

国际化业务矩阵

这张图是整个阿里巴巴国际化业务的矩阵。这是我们目前电商类的业务矩阵，因为阿里的业务比较多。在国内业务有toB和toC，大家接触最多的是淘宝、天猫，这是toC。我所负责的网站是速卖通，它是做国际化业务，直接面向海外业务。整个阿里集团内除了速卖通的网站，还有阿里收购的东南亚的LAZADA网站，还包括之前阿里巴巴最开始发家的业务阿里巴巴网站，也是做跨境的。其实阿里巴巴最初创立就是一个全球化定位的一家公司。在整个业务版图上，可以看到toC成为阿里巴巴集团，包括大家看相关的财报，会发现阿里巴巴国际化战略放在整个战略的首位。我们在国际化业务上跟一些友商的差别是什么？整个阿里业务和亚马逊有哪些地方有直接的竞争？其实就是AliExpress，我们面对的用户直接跟亚马逊100%重叠，可能天猫和淘宝在国内跟亚马逊的竞争相对少，而AliExpress直接在海外面向外部用户（海外用户），包括我们今年收购了网易的考拉海购，包括天猫超市。因为这两块跨境业务主要是跨境，朝国内进行的，所以我今天重点介绍的我们在海外的背景。AliExpress网站和亚马逊的差别是什么？业务模式上的差别会带来技术架构和设计的差异。大家注册亚马逊账号就会发现，你在中国注册亚马逊账号，你到美国亚马逊上买不了东西，也不能到日本亚马逊上买东西，它的技术架构是在中国部署一套，数据和相关系统都是完全独立运维的。这样的话，它就由部分员工负责系统的维护，你在中国负责的数据只要按中国政府的政策进行相关维护，它是局部的矩阵，多个国家之间隔离的。但这样会带来一个劣势，就是当一个商家要做一个生意，我要卖一件商品出去，卖给全球用户，我要到中国亚马逊注册一个账号，要美国亚马逊注册一个账号，这样对商家的运营成本非常高。而AliExpress，你只要在我们的网站上注册一个账号，我们是面向全球的，全球200多个国家就是一套账号体系。LAZADA的模式跟亚马逊比较像，它以马尼拉、泰国等6个主要国家为主，每一个国家独立站点，是每一个技术体系完全隔离的单元化了模式。这样的网站，这样就导致一个网站面向全球，就会遇到亚马逊的优势，就是各国政策不一样，今天美国制裁伊朗，不允许伊朗数据流进美国，我们在一个网站支持整个全球的业务，我们如何保证局部国家政府或政策上的调整，来保障我们的数据不出境或者不被美国霸权国家制裁？这就是业务上带来的技术挑战。除了业务的差别，既然是全球化的业务，最直接的就是我们的机房和人员在全球，分布在各个地区。

国际化业务的技术挑战

国际化业务的技术挑战。从美国的服务器、美国的机房或者美国的用户访问到国内的话，这样的物理的距离会带来的时延200毫秒，这是逃不掉的，无论你今天用5G技术还是什么样的技术，网络延迟200毫秒，这是一个非常硬性的时间差。这样就对网站的性能和方案的挑战，因为200毫秒在计算机是零介质，很多RPC的远程服务中，很多系统的超时时间都是200毫秒。所以我们最开始在俄罗斯和西班牙成立几个当地办公室，当地招了一部分海外研发工程师，他们把系统编译好之后，因为当地没有测试开发机房，连我们国内机房，直接超时了，导致任何操作做不了，这是研发体系的挑战。是否每一个办公室配一套开发测试机房？这个成本很大，因为我们系统非常多，可能数千个应用系统，甚至整个业务体系非常庞大，包括中间件和运维体系很大，如何保障他们正常做研发的工作？这就变成了最直接的挑战。另外一块是用户，我们在全球有200多个国家的用户，访问一个网站的话，比如说俄罗斯用户或者在北欧国家的用户物理距离非常远，他访问网站就会带来一系列的性能问题。由于距离，会给人和机器两个方面都带来一系列的挑战。 

性能对业务的影响

这一块是我们做的相关的统计分析，我们也是站在用户的视角，最终在用户终端渲染出来的性能时间和我们整个用户的购买转化率做了统计分析。发现当我们的响应时间越长，我们的转化率是非常快的下降；当达到一个基点，下降的速度反而没有那么快。像巴西这样的国家，大家在国内对于网络好坏没有感受那么明显，但如果去欧洲其他国家，类似电信、移动的运营商的能力比较差，稳定性非常差，像巴西本地会有一个大一点的运营商，但是他们提供的网络服务抖动非常大，给用户提供的访问带宽非常低，所以他们打开一个页面正常需要十几秒甚至更长时间。这个时间，在国内大家很少能感受淘宝或者天猫因为性能差影响大家不去买东西，但是在海外不同国家，因为最终用户感受的性能一个是服务器端的性能，它的请求能力和系统，系统做完一个计算之后做快速的回应。但是在网络传输过程中包括用户本地渲染的过程，花费的时间占了更大的模块。所以我们做的更多的事情是面向最终用户体验的性能优化，不止把自己服务器端的性能提升到多高的程度，而是真正面向用户体感，因为用户不知道到底是本地网络还是你的网站性能差带来的影响。 

其他影响因素

还有其他国际化过程当中遇到的问题，首先是语言，最国际业务最基本的是英语。因为我们是面向200多个国家，所以我们将近支持200种语言。语言质量也是要经过我们的测试，因为英语和西班牙语世界前两大语系的词根很多都是罗马语系，有很多词相近，有可能是英语，也有可能是西班牙语。所以你做大量业务页面的时候，它上面的语言到底是错的还是对的？这就带来语言上的挑战。还有中东国家、阿拉伯国家的展示格式是逆向的，是从右到左，跟我们的阅读习惯完全相反，这样的话任何一个业务上线之后，每一个业务都会面临数百种语言的测试过程，会带来一系列大的挑战。另外是日期、时间，大家在国内没有时间的感受，但在其他国家可能有冬令时、夏令时，所以大量系统在监控的时候，因为监控本身是很平滑的过程，突然因为冬令时、夏令时切换，会有一个小时的折叠，比如说本来现在已经到4点钟了，但它由于冬令时、夏令时的切换，突然跳到3点了，对于服务器的挑战也是很大的。就像2000年的千年虫的概念，在系统上也有很大的挑战。上星期我们做个业务项目，新同学测业务项目，测的过程中，因为他正好做交付验收，他做一步操作，系统登出了，他就要登录一遍账号，做做一遍又要登出了。我说频繁登出不正常，为什么要频繁登出？他检查了一下，没有查到原因，但凭我的感觉是两台机器的服务时间不一样。因为AliExpress机器服务器时间是美国时间，他用的是国内机器北京时间，所以两台时间差了15小时，立马就会超时。蚂蚁也是一样的，由于不一样的时区、时间点，大家采取的政策和汇率点都不一样，会带来一系列的挑战。还有钱这一块，不同国家币种展示也不一样，日元没有角和分，直接是多少元，直接在数据存储、展示过程中包括费用计算过程中也会产生大量的汇率计算，因为实际上汇率是持续波动的数据，由于波动带来的钱的计算过程中的精准度包括结算的流水，就会产生一系列的金融问题，可能有止损，也会因为汇率波动带来收益。但作为一个网站，每天有这么大的业务流水的情况下，还是要保障它的稳定性。还有数据中心，我们是一个网站卖全球的技术架构，它的数据中心部署在哪里比较合适，因为我们的用户在全球200多个国家，如何选择比较合适。另外是网络，这个网络是我们自己机房内的，是我们几个机房之间会有专线，而用户到机房的过程的网络抖动了怎么办？这边也可以举一个生动的例子，因为我负责AE和LAZADA国家中台的安全生产，前一段时间发生两个PE故障，大家会快速上线签到来应急，但都发生了PE故障，当地驻扎在马来西亚和印尼的同学和本地研发同学上线就没有做任何动作，我是很着急，我就问他们，他们说不要着急，我先给你查新闻。查了一下，是因为印尼发生地震，因为用户要逃命了，没有时间上网了，正常的业务下跌，其实系统没有出现任何问题。这是正常的，因为有地震，导致用户没有时间上网。还有是发生海啸，把海底电缆振断电。这是新闻小概率事件，但是在国际化业务上，这种事情几乎变成每天都会发生的事情，可能法国又罢工了，我们监控又下跌，你会分析今天是因为法定节假日还是游行导致业务抖动。另外是整个CDN这一块，因为有大量进来的资源，它对于性能的消耗会比较大，所以我们会在全球范围内选择边缘节点进行加速。后面还包括监控相关的事情。另外是品牌政策和标准化的东西，包括下面的政策。其实各国的政策对于电商的容忍度不一样，可能大家在国内发展中，整个国内20年的时间对互联网的发展，政策上比较宽松和支持的。但是很多国家对这一块是很严格的，而且还有很多政策性的问题，比如说伊拉克打仗或者伊朗发生军事冲突，快递公司关闭不提供服务了，我们的系统要快速跟进。还有奥巴马制裁哥伦比亚，要求它的数据不能进入美国，我们数据中心就要把用户数据调拨到其他的地方。 

组织成长：从飞虎队到SRE

讲了业务和技术的一系列挑战，我们看一下过程中做的事情，首先讲一下我们在人和组织上的变化，后面讲一下技术的部分。组织上的变化，我估计各个公司都一样，就是为了应对故障会成立应急小组，当我们出现故障的时候大家快速上线进行处理，这些上线处理的人可能是个人能力比较强的开发或者架构师或者一些测试同学，我们的DevOps也是业界推崇的全职能力的。当然到了2014年、2015年的时候，我们发现他们在故障事中做一系列的恢复动作，我们后来分析在故障发生事前还是可以做很多事情，包括事后也可以做一系列的优化措施。所以我们跟海外公司做交流，当时谷歌也是提出SRE（稳定性工程师）的角色，我们就进行了转型，就是从飞虎队的应急变成体系的SRE。其实西方技术和理论产出比较先进，因为他们各种情况出现之后很快能产生技术理念。当西方的技术理念遇到东方的互联网的爆发式增长的时候，就会产生差异化的中国特色的东西，就是我们今天提的安全生产。 

上纲上线：阿里巴巴安全生产规范

讲到这里就要上纲上线讲一下，前面老师讲到支付宝20分钟的故障，在很多社交媒体有大量的用户反馈。但如果回到传统企业，比如说化工厂发生安全事故，企业的法人代表是要负刑事责任，要被问责。但今天互联网这一块，目前我们的用户容忍度相对比较高，所以对大家有一定的放松，没有那么高的要求。但阿里的业务已经很大了，支付宝不可用，成千上万的商家生意做不了。今天杭州包括很多城市接了阿里云的城市大脑，城市大脑的交通指挥系统是在阿里云上的，包括一些高铁订票系统和一系列其他的天气预报系统用阿里云的系统，如果阿里云出了问题，这些系统也会产生一系列的问题，包括交通指挥出错就会产生生命财产安全问题，后面有可能政府会逐渐把它纳入安全生产法律。但政府没有纳入之前，我们自己也做了反思，所以今年阿里巴巴内部做了生产规范，要对每一个负责这个业务的人，我们有一套整体的规范，哪些事情做的不到位，你要为此负责。 

系统升级：从单元化到区域化

我讲一下技术体系的变化。淘宝和国内的业务服务的是数十亿的消费者，其实我们很难在一个机房里面把这么多用户全部服务好，所以我们做了单元化架构。其实单元化架构和区域化架构是阿里巴巴电商业务的顶级化差异。但在国内业务中，我们考虑的时延很短，可能二三十毫秒，对大家的体感没有那么明显，但对国际化业务这一块影响更加大。国内用户体量比较大，当然我们全国用户都在访问淘宝的时候，它的红分比DDOS攻击的流量还要猛。所以正常的用户访问已经超越了安全防护的一系列的措施，所以我们把它做了一系列的措施，就是按算法把用户分配到不同的机房，我们叫做单元化机房。这样的话，你在杭州，你账号访问我们的机房可能是在东北或者在深圳某个机房里面，这样就可以实现海量用户进入到不同机房。但是进入到区域化架构，因为时延问题没有解决，而且各个政府政策性要求都在变化，所以我们做了区域化架构。区域化架构跟单元化架构的差别是什么？单元化架构是按用户固定的算法，把你分配到某一个机房，不管你什么时候访问，你都在那个机房。但进入到区域化的架构里面，如果特朗普说继续扩大范围，说其他国家的数据也不允许进美国，当然的单元化架构是不能解决这个问题，因为有一个用户算法是固定的，很难调整，因为相关的数据落库都在这里。我们就做了区域化架构，区域化架构可以按单个用户粒度灵活调拨，说你今天数据归属到美国这个机房了，因为政策调整说你不能进美国了，我们可以把用户一键切到其他国家，比如说切到俄罗斯或者切到杭州，是这样的架构区别。另外，它的价值中，刚才说这是为了满足政策性的要求，另外是满足性能上的延迟。我们会取不一样的用户，尽量让大多数用户就近访问他的机房，而不像国内完全是随机散列到不同机房。全球用户中，如果你在北美，我们尽量让你进入美国机房。当然这个过程中我们开始是随机的，然后逐渐判断把你切到不同机房进行相关数据分析，分析用户进入A机房的效率更高，我们就把这个用户归属到A机房。当政策调整说你不能进入某一个国家，我们就会调拨，这样就带来国际化业务在技术架构上，跟国内电商业务在顶层设计上的差异。 

稳定性策略：机房间容灾切流

前面是技术背景和挑战，还有我们现有在开发设计上为了满足全球化业务所带来的两个变化之后，我们讲一下测试同学在质量保障上做的事情。首先我们做了战略分析。我们在海外有单元化机房，单元化机房的能力是按单个用户粒度调拨，所以我们就可以做到机房间容灾切换。这是我们核心的容灾能力，上次蚂蚁的故障也是一样的，当我们发现某个机房不可用的时候，其实它18分钟的恢复是靠机房的切换来实现的，容灾的速度最快，当我们发现某个机房不可用的时候，可以立马一键把这个机房切到另外一个机房，就可以实现我们这样的差异。这一块是容灾测试，根据我们刚才的架构设计的容灾测试。另外一块是灰度。我们做灰度之前做了大量灰度调研，也分析了亚马逊的灰度策略。其实亚马逊的AWS会提供大量的服务，对它来说计算成本非常低，所以亚马逊的灰度模式叫做蓝绿发布，你更新A用的时候，整个集群里面有两套机器，就是你先发到A的机器，但并不是把原先的机器关掉，进程还在，当一个新的业务上线之后，大家发现有问题，需要回滚。过去其他公司都是发现有问题，我需要回滚，而亚马逊机器资源很充足，所以直接用成本换了速度，一键切了就可以，因为当前两个版本是并行的，只是说另外一个老的版本没有对外暴露服务。但发现新业务不可用的时候，它直接把调度关系切换一下，让用户流继续进入老的系统，就可以实现灰度过程。我们也看了Google的模式。其实Google的技术特点是有很多技术创新，会吸引有很多极客精神的人过来体验他的新产品，所以我把这一类公司叫做酷公司，做很酷的产品吸引一部分人，这些人愿意牺牲稳定性要求尝试新产品，所以有一些新品直接进入Google实验室，有一批用户尝试这个产品替代它做公测。微信也做了用户调研，用户也是按圈发布的，比如一个圈一百万用户，发一个版本，如果没有问题再扩大一千万，然后一个亿、两个亿。 

稳定性策略：特色的分机房灰度

我们根据自己的特点，分析完了这些模式，对我们都不能用。我们根据自己的特点，进行了分机房。我们先在上海机房发一下，发完了之后东南亚地区的用户访问上海机房，业务正常，没有问题，那就发欧洲机房。如果发欧洲机房过程中发生故障，因为美国机房还没有发，我们直接可以把欧洲机房的用户切到美国，保证发布过程不出现问题。我们的用户数量非常大，怎么做稳定性测试？AliExpress比阿里巴巴集团做微服务改造早一点，因为我们当时面临要发展国际化的团队，希望能够吸引更多开源社区开发者进入我们的组织，所以我们在2014年底开始发展微服务。用了大半年的时间，把整个系统改造成微服务的架构。在做改造之前，当时做了一个判断，我们原来有两三百个系统，微服务改造之后，我们的系统数量会膨胀，原来很多逻辑放在一个业务系统，今天拆到三个或者五个业务系统。整个业务系统，原来只有两百个，就变成两千个。大量的系统变化，导致系统依赖关系变得更加复杂。所以我当时提供一系列的工具，分析每个业务系统可以依赖哪个服务，每一个服务在哪个应用，帮你断掉服务之后，来判断断掉服务之后，你的功能是否正常，如果功能出问题，你是可以降级。类似的可以做一系列的预案，当发现流量比较大，机器资源不足的时候，我可以把一系列的服务断掉。

稳定性策略：强弱依赖分析

还有是某个服务断了之后，业务系统就挂了，这就是强依赖的服务，对于强依赖的服务我们要重保，我们会给予更好的支持，包括限流上会给予更多的支持，这样就可以帮我把整个网站，在应用很多的情况下把逻辑关系理顺，就是谁到底是强依赖、谁是弱依赖，做好相关的措施。 

稳定性策略：混沌工程

还有是混沌工程。我们当时实施的比较早，其实我们2011年开始做这件事情，当时还没有混沌工程的概念，整个阿里集团都在靠写代码来注入，就是你要在代码生明哪个服务超时或者某个服务不可停，来做一系列的破坏性验证，来验证我们整个业务系统到底是否可用。我们后来逐渐进行了发展，就是在前面的架构上，在做强依赖分析的过程中，发现我可以判断你对哪个系统的依赖，我也可以断掉某一个服务，所以最早设计基于RPC的故障注入平台，当然后来很快发展了MK，其实MK在业界刚开始提供了Chaosmonkey工具给大家使用，然后你觉得很不错，然后在阿里很快落地发展。当然今年整个混沌工程成为集团里面的核心战略之一，我们昨天进行了阿里集团和蚂蚁集团的联合攻防演练，是大规模的演练，一方面来考验系统的容错设计，另外一方面是不同团队的人在相互协调上的配合、在处理问题上的速度。所以蚂蚁出的故障还是很大的故障，18分钟可以回复，主要得益于混沌工程在蚂蚁有很深入的应用和实践。包括下面的CnaosBlade，也是阿里提供开源的混沌工程。我们通过这个过程，能把大量的人员的技能，有很多新人过来之后就可以上线迎击，熟悉所有线上的运维系统以及开发问题的能力。通过实战化的锻炼，让人员和系统达到稳定的水平。我们核心的策略是什么？就是机房间的容灾。我们持续在练这个水平，就是不管稳定性、预案等一系列的措施，但是最核心的就是机房间的容灾，这是国际化业务的特点，就是我们可以做不同的机房，可以按单机房的粒度切流。我们抓住这个特点，就做机房依赖容灾，不管有什么故障，都可以做到机房间快速切换，来保障我们的能力。机房上线三年，我们的可用性实现100%。在上这个之前的2016年上半年，可用性已经破4个9，当时的质量比较差。 

应用稳定性模型

除了刚刚讲的策略，我们还在做应用，就是健康度模型，会分析应用到底是否健康。前面几位老师介绍他们会看一些指标，我这边围绕稳定性来看的，就是上线之后的系统启动时间是怎样。启动时间代表什么？代表启动应用大还是小，一旦我们发生故障，电商的可用性时间按10分钟来算，如果超过10分钟，就会影响可用性。如果超过10分钟，你做任何回滚都来不及，所以能够留给你系统启动包括有时候要应急，这个过程时间去除之后，能留给你的应用启动时间是184秒，如果你的系统184秒不能启动，即使一个故障过来，你立马知道如何修复它，你可能回滚的时间都要超过10分钟，就会消耗可用性，所以我们会度量每一个系统的可用时间，如果超时了，我们也会给予一系列的优化建议，让它把整个相关的应用时间降下来。另外一块是Jar冲突，大多数应用是Jar应用，Jar里面有大量的容器，其实容器里面的核心就是Jar包。应用是面对运维层面的最小单位，因为你要部署的话，必须要在一个机器上布一个应用，那是一个应用的最小单元粒度。对于整个逻辑单元，我觉得是一个Jar包，因为一个Jar包里面有你的业务逻辑，不一样的Jar包有不一样的业务逻辑，而一个业务中到底含有多少Jar包？每个Jar包是什么版本？之前是不是有版本出现问题或者有哪些版本是不需要依赖的，就可以剔除掉。包括我们要升级了，整个全栈都要升级某个版本，过去可能要靠扫描一下让大家做一系列的升级发布，而现在是通过卡口，发现应用启动中含有我们规定不能使用的版本或者规范，只要不符合，你的应用是不允许上线。另外是容量水位，我们的核心策略是容灾切流，你把这个用户切到另外一个机房，如果另外一个机房不能承担这么大的量，能否承载两个机房的用户量？它原来承载一个亿的用户，一下子切流要承载两个亿的用户，它的容量是否充足？如果容量不足，切过去也不能用，所以我们要考虑每一个机房的容量储备。所以我们设计了健康度模型，实时分析每一个应用当前到底怎样，以及需要做哪些措施，因为这样的话给出的措施，对开发来说，他的可接受度非常高。因为过去给他打一个分，你只有80分或者更差60分，他不知道该做什么动作。而我现在给出的动作是告诉他你启动超时了，其实你的Jar包是可以优化的。还有容量不足，上线之后无法容灾，会给他更加精准的提升，告诉开发你需要做哪些优化，这样开发也很乐意拿着这样的战略优化，最后变成接手这样的应用之后，原先的启动时间是5分钟，在我负责期间提升了80%，这样的话大家做的事情的结果也可以度量了。 

未来：高可用与研发效率

展望未来。刚才讲了很多，重点还是围绕ROI来进行。我们刚才讲稳定性规范，整个规范会定义一系列的流程，比如说审批流程、卡口，这是直接增加我们的研发成本。正常发一个应用、改一个代码，就可以提前发布，这样的效率比较高，我们每天可能都有上万次这样的发布。当你加一道流程就需要大量的审批，就会消耗研发工程师的时间。换算到公司成本，就是大量钱的消耗。另外一个是研发成本，如果我们有足够的钱，不成本，我们建更多的机房，有任何问题就容灾，这样的话效率也很高，但是资源成本消耗很大。亚马逊之前为什么可以做蓝绿？因为他资源成本相对比别人低，所以可以用大量机器成本换稳定性。另外我们很多业务在高速发展中，能否用可用性换业务高速发展？这也是各个网站CTO要做一个权衡，尤其是阿里很多业务都是在高速发展，很可能我为了业务高速发展放弃一部分可用性，就跌了4个9，我也可以接受。最后，我希望在这些指标都保持的情况下，如何提高效率？是通过一些工具化、智能化的手段。刚刚讲应用健康类模型是其中一个，其他还有各种发布，因为一次发布，刚才有三个机房发完，现在有更多机房的时候，你做一次代码变更，发布三个机房要十几个小时，时间非常长。我们后来做的无人职守，就是流程规范并没有减少，但只是把过程做成自动化。包括系统上线之后异常增多了，你的某个指标抖动了，我们都可以通过刚才的应用健康度模型更加精准地体现出来。所以可以通过工具和智能化的手段来降低这几个指标对研发效率的消耗。 

未来：分级治理

分级治理这张图讲的是核心的思路，就是变更的维度上，我们把变更数字化之后可以控制70%的故障，因为大量的故障是由于变更导致的。刚才说有一些网络或者其他的外部因素导致的，所以我们会持续做分机房的灰度发布，包括蚂蚁上次出现故障，蚂蚁和机房也是分机房灰度提到更高的策略上。另外，如果想做灰度，必须机房容量充足，如果不充足没办法做灰度，所以机房容量要充足。我觉得阿里做的先进一点，因为阿里每一年双11面临的性能挑战很大，它比DDOS攻击的访问量还要大，所以我们有大量压缩的工具来验证我们的容量，一个是压测，压测完了之后我们的容量需要怎样扩容等等，有时候会有这样的关系图，这个关系图也会帮助我们判断当先出现故障的时候是否能切流。前面两个程度都达到一定稳定的情况下，下一个就是容灾动作，单元化架构情况下切的话，很难把一个用户归属到其他地方。而我们的区域化架构，就可以灵活调配用户到另外一个机房。刚刚说架构上的实现是这样的，但真正执行能否达到这样的效果？也是需要不停的演练，所以我们每一周持续做容灾演练，来保持容灾的保鲜度。上面几个因素是我们自己打内功，把自己修炼好，提升自己的容错能力，但是对网络层面的因素，比如海底电缆断了，某一个机房电缆被挖断了，这种外部因素不可控制，但是我们的可用性指标上，无论是外部因素还是内部因素。出现问题怎么解决问题？这里面也有一个创新的思路，2017年阿里的吴翰清工程师获得了MAT35岁最年轻科学家，他当时获得奖项的关键原因是因为他提出了弹性网络，当时要解决整个网络安全，吴翰清是业界安全这一块大师级的人物，他当时提的概念跟我们GTR的网络切换理念相同。其实我们当时也做了一件事情，就是面对欧洲和东南亚国家基础设施很差的情况下，我们能做什么事情？我们设计了类似打地主的模式，当我们发现有一些网络攻击或者网络运营商网络有错误的时候，我们会快速切DNS，就是整个用户最终访问你的机房，是他访问你的域名到DNS解析，到最近的POP点，POP点走网络专线进入到我们的机房。我们可以分析一下我们可在全球哪些地方来部署这些POP点。就像我们是一个地主，当别人遇到各种灾害打击我们的时候，我们如何逃逸的问题，如何跟安全攻击进行隔离，是一样的道理。所以我们会在全球各地选取相对比较好的运营商网络POP点，当发现某些用户经过POP进入我们的机房，他的延时最短，我们就会调拨用户经过这条线路进入我们的机房。因为这一块有一块问题，就是各个厂商数据不互通，很难有一个全局来控制走哪一条DNS解析的线路最优，所以这个数据在阿里内部又没有海量用户，所以我们可以通过不同用户进来所走的DNS的解析路径，来分析我们选取哪些POP点作为我们网络接入最为合适，所以做了全球不同地区的网络POP点的服务。当一个地方发生故障的时候，我们把某个DNS解析切换到一个正常的地方，或者某一个地方发生攻击，我们把整个对应攻击网端的用户流量直接隔离，实现了吴翰清说的弹性安全的能力。然后就这些数据分享给社会上其他公司，就可以打通网络全域DNS解析。

以上是我的全部分享，谢谢大家。

关注「阿里巴巴技术质量」阅读更多