大型电商网站 SRE 运维的挑战与思考

彭小阳

作者简介：顾贤杰，就职于网易，现任资深系统运维专家一职。作为行业享有盛名的大咖，顾贤杰行事低调，对工作热情饱满，多次受邀作为嘉宾出席各类大会，并发表了精彩演讲。

今天的分享包含四部分：
第一个，电商网站业务特征对运维的挑战。
第二个，SRE的日常。
第三个，速度VS稳定性。
第四个，稳定性和技术流程相关。

一、电网网站业务特征对运维的挑战

这两年的话，考拉这边实际上放的挺顺利，做到二线的全国第一，最后可能还是因为各种原因，反正对我们来说，这个就不说了，我们说技术层面。实际上在过去的一二年的话，考拉的成长是非常迅速的，整个业务的发展对我们运维的挑战实际上也是非常大的。

业务增长体量的话，实际上我们有一些新的挑战，主要是这四块，我们容器化的路径，一些智能压缩，还有更高的效率要求，最后一个是我们一直比较头大的问题，就是说我们有太多运维不可控的因素，因为系统来复杂。

在能效这一块实际上怎么说呢？不像一般的网站，我相信可能隔壁的阿里或者说腾讯可能做了容器化，但是我不知道有没有get到他新的技术点，以前可能容器还是继续这种方式用，我们这边可能是全套的全部容器CF的标准。效率的话就是要求更高的效率，业务层实际上后面我也会讲到，他们对效率的要求是非常苛刻的。

然后还有成本，成本的要求是比较大的。实际上我们这边的话，很核心的一个点，就是单日GMV的成本压缩，要不停地压缩到业界至少ERP的水平会有更高的水平。

下面我来跟大家讲一下一些电商业务的特征对运维的挑战，首先是系统规模，还有一些频率。上线成本这一块反正每次大促容量都是很头大的，然后最后开始小要求。

规模这一块的话，实际上最近两年是去年跟今年感受是比较明显的，因为这一块实际上做了很多的业务拆分。这个图是一个我自己手动画的，不是真正的现场业务图。

可以看到，原先大家可能是一个中间件，然后我们去调各种各样的数据库，后面的缓存就太多了。最近一二年，电商的趋势可能就是有没有决策框架，然后来做结构分离，然后做很多单元化。

因为这种拆分的话带来了新的问题，我们发现整个原来加入一种天线的格局就改变了，我们发现后端他们开使用JAVA，然后前端用node.js。然后BI支撑就是JAVA，可能各种人工智能相关的语言他们都用了。

这些不同的语言他们有各自的智能推荐，然后开发团队也是相对独立的，跟整个技术路线的演化，比如说JAVA的演化可能是走doublu路线，或者是走其他的路线，都是独立的，他们有一个独立的生态环境。js他们可能有前端的研发，还有他们想切入到服务器，奢望后端用全JAVA的模式。

这些东西给我们带来的就是说部署可能变得不能一统天下，就是说每个部署的方式或者构建环境都是相对独立，不得不依赖人性化来解决。

然后集群也是变化非常快，包括以前也是大规模进行的一块，现在可以到1000或者是更多的规模。

这是我们其中一个节点，是每次大促的点的扩容状态，这个是一直往上走的。就是说有些情况下可以现优化，但是涨的不是很多，但是总体还是一直往上走的趋势。其实我们就是说不停地拆出去，结果还是有部分的拆不出去，然后规模一直往上涨。然后这种规模的话，对我们发布层的发布有好处也有坏处。

我们这几年业务的话实际上最近两年也做过很多演化，就是原来单机房，就是所有的业务，新开发的时候都是只做单机房的。比如说新的节点，或者是模块。然后做多机房，然后再做单元化。

整个过程为什么会有这样的情况？就是因为整个过程比如说新建模块，或者是比如说一个促销模块，它刚开始建设的时候整个团队还想它只能做单机房的，靠整个单机房来确立。后面因为业界都推荐右戳弹框，多机房就很容易铺开来了。

这块我觉得倒不是很难，因为多机房相对来说各个大厂或者是一般的互联网企业都是能做的。但是这个设计很考验团队能力和一些数据一致性的问题，对维稳也是很多挑战。因为很多的业务逻辑非常复杂，开发只关心他的方面，但是从来没有考虑过用的一些细节或者说基础环境对它的影响。

然后变更频率这块我们也发现了，就是后面会讲到，变更的话我们会有大概很多种变更，但主要就是三个，一个配置变更，大脑变更，最头大的是配置变更，配置变更是运营那边比如说配的环境、配的促销，这种变更好多是出了线上的问题和事故，很多时候会发生自忖的事情。

这个是我贴的一个，比如说我们在改进整个环境里面测试线上预发和生产环境各个环节的一个入口NG，然后应用层数据库等等。比如说生产环境，我们认为所有生产数据都是1，如果线上预发肯定你的环境层面单位频率肯定就是米，然后应用也是这种频率。

但是到测试环境，我们发现这个频率非常高。刚开始基本上我后面也会讲到，应用层可能一天专门有个人一天到晚就在发布，什么事情都不能干，他也能写代码，又没时间。

变更520可能是我们发现线上真的有太多问题了，就是有很多新问题、新的配置，然后老板想看到某个特性，比如说因为有个标签有问题，可不可以发生一些变更。它是一些应用配置活动，都是通过我们配置作业中心来实现的，然后业务的维护。

有些东西可能说有的商品或者有的页面是因为各种原因需要把它停掉，还有这些资源优化可能会发起。

我们发现所有的每时每刻都会发生，而且我很大的感受是从变更设计，从早上8点左右开始一直到晚上10点，996，然后可能每天凌晨也会发布。

整个变更的过程，实际上我这里写的是发布，实际上是整个变更过程中能发生决策很大的变化。早期我们比如说1、2年前，我们P的那个团队，基本上负责我们所有的业务发布。后来做了半年左右，扛不住了。

有个核心的PE发现，真的是没有办法这样持续下去。会发现我发布的业务从早上到晚上还没有发布完，然后整个线上业务的老板都在等着你，就很不满意，然后我们后面推了部分的自主发布。

去年到今年的话，我不基本上实现了全面的自主发布，所有的业务线都是由开发可以自己点击确定来做自动化发布。当然不是说这个东西我们一开始没做自动发布，而是说从风险控制角度或者流程控制的角度，我们没有做到很完善的风险控制，从去年到今年这个时间的话，我们做了很多流程校验，来实现风险预估。当然，我不能说100%风险没有问题。

在这个过程当中的话，我想感受的可能这样一个变化。原来的话是一个自己动手的角色，然后我们现在可能主要是最原始认为是一个觉得自己尽量去发布，去年开始我们做了半年校验的角色，对所有开发进行赋能，然后告诉他们技能或者工具，然后还做了放权，对所有的权限什么的都去做迁移。今年的话可能更多地在做一些产业派的角色，主要是控制质量，对变频的结构进行判定跟限制。

还有一块实际上日常这一块……还有一块挑战就是成本这一块，大家知道从去年下半年开始，互联网很多大家可能裁员都有听说，我们也对内做了一定的优化。这个怎么优化呢？我们做的就是服务器。

我们整个行业有一天就起来很多影子优化，有一天流量比较缓，流量替爸爸省了1个亿，这个是做服务器优化或者是成本优化带来这么多收益。

然后我们发现做电商这一块真的是平时冗余太高了，服务器这边实际上很多水分可以压缩，然后降成本合并，各种机房搬来搬去，都会涉及到成本优化，还有一些带宽的节省。

大家可能在以前吃大锅饭的时候，可能因为部门比较多，所以很多互联网成本大概都是提供效率以后就没有感知了。去年开始的话，可能就变成单独按功能核算，我们做了很大的改造，后来做了这一块的成本优化。

在这块的话，我们实际上遇到了一些挑战。这个以前可能说我做资源优化无非是带宽扩容，但是很麻烦的一点，有些东西不是我们能控制的，比如说他发那个版本可能带宽一下翻了十倍这种感知。我举个例子，可能异常带宽它一下上去，比如说原来CPU只用1%，突然间用到10%了都有可能。

还有评估容量，评估容量现在很复杂，以前的话可能说你这个跟我做对接，你告诉我你下个月新开了多少节点，基本上就OK了。

但我们这边的话基本上不可能，因为整个业务线我们估算了一下，基本上各个模块可能有400、500个能数出来的，但是数不出来的可能更多。然后这些模块，每个模块都有自己独立的容量，这个容量的话，说实在的一个个去核对或者盘点，基本上核对不出来。

有个业务方面的主管说我也不知道，反正谁会来调我也不清楚，你跟他说容量规划，他基本上说反正我的容量直接够用，不够我找领导申请。

所以今天我们监控也在，我们的监控，我们考拉这边的同学，我们负责考拉业务这边同学跟我们这边监控的同学做了很多方面的工作。比如说对监控做切片，切片比如说大促、压缩、峰值的切片数据，然后根据切片数据驱分析容量的需求，仔细地评估，用工具和人工结合的方式来确定后面扩充的计划。

当然这个最终所有扩充都是依赖于压缩数据，大概会有平时数据跟压缩数据两种，最终是扩充操作。以前的话我们平台是支持云计算的这种扩充和容器的扩充，所以理论上应该还好，只是说扩充上面也会有一些流程建设的问题。

最后可能是一些效率的要求，我感觉从去年开始听到电商的领导就说，我们跟隔壁厂看齐，就是要求效率。这是我们改的一种方式，我们发现实际上规模越来越大的话，领导层面是不愿意业务加量，但是人得加上去。他们希望加量不加人，然后整个配置和变更的时间是得缩短，然后自动化的流程都是一环套一环的。

最简单的一个例子就是我们的硬件的配置，我们发现智能环境，当然我现在好多不能说，智能环境就是说配置很多东西提回来，有严格的上限，它大概整体能做到3分钟。然后2.0的时候我们做到10分钟级的，就是全自动。

最近的一个版本，我们全面整个环境改进以后，我们能做到大概2分钟到3分钟这个级别，所有的配备跟整个环境构建，相当于我们之前说那个一点，我们之前在测试环境做了一个很为了省钱考虑的一个设计。就是说在3分钟重新从0开始建设一套线上环境，就是一键design，就是可能各个大厂都会用，我们整个环境里跑了多套。

最后我们讲这个效率还有意义，基本上就是效率的我们这边一直往业务团队，或者说整个研发团队，就是隔壁厂，现在叫隔壁部门，因为被收购了。感受最深的就是领导他们提说开发的需求，就是他们开发需求基本上3小时就完成一个需求端到线上的例子。我们还没那么快，但是也在向他们的方向努力。
第二个感受可能考拉这边最近半年或者怎样，可能跟其他友商或者是项目扯来扯去，比如说抄袭等等这种情况，也涉及到研发部门。实际上新的研发的特性，或者说功能的上线，实际上是意味着商业优势。然后基于这两点，实际上领导就给搞了一个项目部2.0，然后专门负责设计更好的跨链流程和技术，然后运维这边的话也是在努力。

二、SRE的日常

日常我们大部分时间在扩充，为什么？省成本。今天把这个容量收缩回去，明天把这个容量扩回来，就来回倒腾，左手倒、右手倒，保证全年的IDG计算不超。然后还有做价格改进，价格的话比如说多机房、双机房单元化，主要是做单元化。

这块的话肯定需要很多的应用操作，比如说数据库的表，用的集群分离，然后实现整体的配置改造。还有最后一个基础功能的建设，是运维大家的趋势，运维相当于要做开发嘛。然后还有一些运维赋能的工作，主要是做一些运维支持跟专家的落地。

然后实际上我每天做的事情，我们发现PE那边做的事情都是半年才评估。因为他们发布的那些都已经放过去了，最近做的事情就是去评估容量，然后评估整个集团的状态。比如说这个状态这个集群容量是OK的，但状态有点异常，怎么样去跟进。

然后还有一个成本，每次扩容业务层面就觉得我这个业务可能接下来领导很重视，人家给我扩5倍，可能我们要去抢他这部分的资源。

还有一个就是稳固，我们不停地在稳固。这些总体的目标都是为了提升资源利用率，比如说单个数据激活，整个资源利用，比如说从10到20，到30、到40这样一个翻1倍的情况，这样的话能确保整体我们全年的增长百分之多少的情况下，资源的成本，或者说总体成本能够维持住。

最后一个实际上是做容器化，我这边容器化这个东西有一个很好玩的地方，就在于说容器化的东西既涉及到技术含量又涉及到成本，因为很大的一块涉及的实际上都是为了成本考虑的。

而我们的架构实际上是运维参与的可能是最近一、两年比较多的，一直在做架构方面的改进，协助团队一起做。所以我们这边做了很多的服务化，最近可能在做实务性的这块东西。然后比如说以前单机房，现在多机房，现在做单元化。

整个我们发现对运维的要求是越来越高了，比如可能单路的时候配HA，然后我们配的PIO就可以了，多机房的时候我们要考虑怎么切换。业务层面他根本不关心的，比如说数据库的多机房，你们复制一下吧，他从来不考虑谷峰延迟，我们需要去研究一下数据库的半屏幕、全屏幕还有对业务的影响。

这块实际上很考验运维团队的功力，然后走单元化。单元化这一块，实际上业务层面还是很简单，我业务都是无状态的，肯定是专业化的。实际上大家看的话就没那么简单，比如说底层的，比如说跨界的电路会不会有问题，数据库双写怎么搞，实际上都是我们业务人员考虑的。

然后我们整体的整个架构是业务团队自己推动的，就是研发效率，其次是稳定性，最后是容量跟性能的考虑。所以这个变化都是配合业务团队或者是主要由业务团队来做，然后最核心的还是稳定性是第一。因为电商这块领域的话，说实在的宕机一分钟可能就损失好多钱。

技术相关就是运维这个角色我们日常里面做了很多方案设计的评审，比如说业务层面开发了一个新的模块，然后找我们运维去评审，这个东西高可用，然后有没有问题。可能业务团队想的很简单，我这个东西能跑就可以了，然后我们会去challenge，就是说告诉他们你这个东西不准备给你上，这个不给做。还有些做的很多运维和架构方面的设计、开发，后来进行一个资源的沉淀。

这个是我们最近重新搞的一个知识库，实际上这是个界面，后面是一个打通的操作。然后我们在这块做了很多的探索，比如说IM+自然语言处理+CND+内部的PNC，都有考虑说整合在一起，最终是一个China
OS的平台。这个可能跟其他厂也没什么关系，只是这块可能是我们运维去思考和去探索或者整合的那个情况。

三、速度VS稳定性

在整个过程中，实际上日常的考拉的运维，或者是电商的运维，可能感觉架构和技术实际上大家都是往一个方向努力的，没什么问题、没什么意义，实际上开发一直在踩油门往前冲，然后运维说实在的是希望稳一稳踩个刹车。

我们发现速度可能是越来越快的，油门踩的快，然后整个车的技术组件，比如说它的引擎、它的消息处理的速度，就是传轴之类的润滑的更高、密度最大，所以整个油门方面可能踩的还是比较狠的。

我们这边实际上是对迭代数据影响最大，可能是有项目拆分做了很多的参与。比如说一个应用改变一个业务逻辑，可能需要把整个前端后端都糅在一起发，为了改一个前面的页面属性，把整个重启，实际上很重的，我们做的基本上在去年跟最近两年应该是全部都拆掉了，有个小主页修改很快就供上去了。
还有结构改造，原来的话可能ABC可能都是相互顺序依赖发布的，应该说前年开始，基本上ABC可以顺便发。

然后还有新公式引入，电商这边比如说促销，他们都会有新的产品线、新的业务逻辑，这块肯定也会很快。

最后是新特性迭代，我指的是很底层的那种特性，跟业务无关的，比如说Dook sca或者新技术的引入，对我们整个业务的开发模式影响还是比较大的。

这个是我对那个业务变革速度的一个简单评估，在我们最开始前端的时候可能说我们的基数是1，然后在前后端拆分的时候发现速度一直往下走，到业务结尾的时候基本上到4的程度。

全部弄完以后，我们评估了一下，可能又比原来又快了一遍，因为以前CICD可能是很重的，可能是说整个CICD以后可能还是需要运维去审核，现在只要容器被自动测试跑过的柒，可能就容器不足，就没有什么个各种环境检查之类的东西。

然后，从业务的维度上说，它希望采用，因为它的KPI是新特性的交互，我们领导对他要求说你今天可能要把新功能上上去，要求就今晚上上去，就很简单，开发这边从个人角度来说，领导要我新特性，我希望这个新特性赶紧上线测试一下，因为我这个没有QA，然后他希望这个项目进度在周五之前就完成，因为我周末想完成，开发都是有这些想法的。

带来的问题就是说就会有很多线上问题，我们发现主要问题就是业务线很长，Q盯不过来，隔壁部门比天猫或者淘宝可能就是开发自测，我们也在推。很多的开发实际上说我有线上发布，但是它实际上完全不知道线上的那个怎么运作，他只知道业务的逻辑。

最可恨的是因为可以自主发货嘛，把他们整个组可能都加权限了，他们自己组长可以加权限，所以会导致有这样的情况发生，比如说进来没多久的新员工比如说刚转正，他就有权限发线上，然后他经验不足，直接把线上给搞出问题了。

我们开发自己的Ops，当然可能跟我们想的不一样了，我们想的DevOps可能说开发跟Ops的隔离性能给去掉。最终的结果我们统计的最近一年的情况，基本上会发现所有的变更相关的事故，有很多的都是比有一半都是自己发特性，或者搞什么配置，弄上去。

然后还有大概33%左右的软件bug，因为软件有bug，有些真的太复杂了，真的没法说测试环境能够完全递归到。还有一些是第三方影响，可能是我们没考虑到第三方的那种强结耦，这都会有问题。

我们来讲讲case，印象非常深刻的一个点就是今年差不多4、5月份，有一个项目，我周末加班改进，然后晚上7点左右的样子，线上直接爆上了，一堆人全部都炸上线了，为什么？查了半天，这个业务有发布。

然后第二个是发布变更的时候没协调，实际上我们现在做的结耦，但是这个结耦真不能说是完全结耦，因为它是分布式调用了，但有可能说有的组件能够变更有问题，有可能会导致上游变更调用挂错，各种情况都有可能发生。

这个问题就很严重，基本上开发加班搞事情，然后我们最终的问题是运维开机cord，运维就很憋屈，我给你权限、给你自动化运维、给你做了很多兜底，结果你绕过了整个流程，然后你给我搞出这样的，很憋屈。

我们在运维这块，实际上是也有对线上稳定性做思考，比如说我们的PE或者DD、或者SV都想过了，他说线上所有的最好我们运维自己做，然后运维做完的话，肯定线上都稳，因为我们都有丰富的经验和专业知识，不会有问题的。

但实际情况就是说很严重的问题，整个业务线太多了，你真的所有人都去跟一个业务线，基本上人都分不过来，分身乏术。有些时候还不能解决所有问题，因为某些领域可能也是说操作可能同时只能一个人操作，不能多人操作，多人操作可能有问题。还有大型团队的协作，可能效益会下降。

最严重的问题是我们对稳定性这块有所破坏了一点，中国的互联网有些时候老板还是喜欢有一点新的想法，像我们公司或者说腾讯的马老板，都是项目经理嘛，他会有一些新特性的需求，都在等，老板需求第一位，肯定会先上。

对于这一块，实际上我们在今年开始就做了一些探索性的东西，主要是平稳，速度这一块一直从去年下半年一直在做这个事情，赋能，把权限都放宽，全部都放给开发，平台的话支持自主变更，比如开发点了以后，什么时间点开始自动更，更完了就不用管了。

然后，稳定性这一块，我们做了很多的那种工作，比如说对业务做了等级划分，L0、L1、L2、L3，划了三四个等级。审批共制，以前可能业务的小组长我想发就发，现在可能会有一个升级机制或者是有个新的流程，根据不同的业务有不同的流程。

可能我们都对业务方说你要自主发吗？可以，还有个SO反馈，这是最近半年在做的。

总体上来看，我们的技术+流程最终是会带来线上的一点稳定性，然后接下来是我们对一些线上问题的电商这块稳定的cofan。

实际上跟Google一样，我们的问题是永远的，线上允许出问题，发布出问题，认为有些人没有临岗，他直接说5分钟之内回复，基本上就没感知，直接就pass了。

今年的话我们可能对线上的问题可能是容忍，但是我们也设计了SLI/SLO指标，比如某个业务你要承诺你对上游的服务可靠性多少，所有这些以业务影响程度为准绳，比如说我可能挂半天都没影响，那这种可能就不算。

还有线上事故的处理机制，我们这边可能都会出一些紧急预案，比如说某某业务挂了之后，直接就一键咨询优先，比如重启发布，重启，然后回滚，实在不行就是全进行销毁，可能就这样子来，然后做很多的事后复盘，举一反三。

比如说A业务出了一个事故，然后业务方会说A业务OK，出事故了，我们认同，但是你们有没有举一反三？举一反三的意思是说你后面不管是你A业务层面有考虑到后续的类似问题，还有B业务的团队也要去思考这样的情况。

然后，我们考拉这边如果是有线上事故了，会有一个通报机制，比如说根据规范等级会通报所有的技术团队，说A业务出了问题，是事故，然后惩罚了多少，后面的惩罚机制。

这个问题我们在运维，在这些问题实际上也是做了一些工具，比如说我们做了一些平台，一个平台，这是平台的一个简单图，比如说我们平台对事故现在是人工的跟自动的发现为主，先统计到工程维度，工程维度再统计到业务线，业务线再到全站，这些都是自动化计算的。有了这些以后，我们对线上问题最近下半年稍微有一点收敛。

四、技术&流程建设

最后一块可能是我们对整个电商领域的一些在运作过程中的一些技术跟流程的思考，可能不一定跟电商非常密切相关，但是感觉还是稍微有一点通用性的。

关于流程，这块可能大家所有的部门团队或者技术团队都在做流程相关的建设，比如说很简单，所有部门都约定俗成的，比如说我有些时候跟我的团队成员说我们约定俗成啊，这个事情一定要这样做，然后再这样做，后面这样做.

OK，没问题，半年以后没人记得这个事情，所以我们会写成文档，文档写完可能会说大家所有人定期要看一下文档，按照文档来做事情，OK也没问题。但是当我这个团队比如说我这个文档需要给跨部门用的时候，没有人会care你的文档，所以我们做了平台程序化。

运维这边我们在建设这个流程的时候发现，我们的目标总体是为了线上稳定，或者是为了一个特定问题求解，比如说线上要求做某件事情，可能只能按照它的流程来，那种可能很多都是比如说审批相关的，比如说走公司的申请流程，然后方式的话可能无外乎就是制订标准、执行标准、改进流程。

在整个过程中，我们运维是非常希望能够达成标准执行的，比如说我希望所有业务方都按照我们运维的标准做某件事情，但是实际上在现实中非常困难。
很简单，去年下半年，我们做了一个运维跟业务部门的绩效留用，比如我们运维上半年做了什么事情，然后跟业务方汇报，说我们下半年整体的运维怎么样，希望你们提什么意见。其中一个开发跳出来说，现在的流程太复杂了，我们是创业公司的，希望很多流程可以跳过来。

因为业务方是甲方，所以还是会听他们的，做了处理，然后在整个业务建设流程上我们发现很多问题。

当然听取他们意见，让我们发现业务实际上是有冗余的。最简单一个例子就是说我们为了线上稳定性，执行有一个标准，然后这个标准执行完了，大家都按照这个标准做.

但是真的事故又发生了，为什么？肯定会说跟代码一样的，我有一个异常CAS没考虑多，那怎么办？那加一下流程呗，反正再加一条，比如说原来要没检查A的，你再检查A吧，然后我们又发现这个流程会越来越膨胀，流程会非常低效.

比如说做一件事情，比如运维要线上改个配置，有一个进程，现在可能就是说没有流程又不行，希望通知业务部门开发，业务部门开发，业务部门老大找绩效老大，然后再找用户老大，多层审批，然后完了以后就有一点像为了规风险，大家不停甩锅的节奏。

这种应该是很少见，但是不能说没有，我相信各个大厂都一样。还有一个是流程建设，没有达成共识，这个是很痛苦的一点，我们运维这方面做了很多的标准化流程，结果发现有一些流程连我们内部的人都没有遵守。

还有一些是没人知道流程，因为整个的文章太多的话，会发现在制定流程的时候很爽，但是流程广播的时候发现我们内部的团队知道，外部的团队搞了半年，对我们内部的流程一无所知，最后是形式化的流程。

对于这些破局，我们也做了一些探索，首先我们做了流程平台化，worwflow任务落地，用新的工具技术减少人工环节，运维赋能开发，设计的时候考虑各种异常，压缩处理流程。

这是一个典型的例子，比如说我们的大促，它其实是一个非常复杂的工程流程，很多的电商平台，或者说友商，很多的流程预演、很多的跟进，很多库存的调度，这些都是流程，流程太多，刚开始都是口口相传，因为流程太多了，最后没法交验，有一些流程执行着中间就跟丢了，我们做了大促网络平台，还做了一些去流程化的东西。

我们现在中间加了很多自动化的机制，所有环节都是人工操作，现在中间加了一些自动化的设置，人工操作只有在自动化失效的情况偶尔去借助一下，测试环境也做了一些流程，有一些流程是不需要审批的，我们就免掉了。

这个是我们在流程方面做的很多的改变，让整个的研发效率和运行有很大的提升，业务团队这样整体过来，我们现在还是比较满意的。

这个是做技术改进的一个实例，我们做了很多的技术改进，这个是典型的收益，一个是Ngigx的，我们在测试环境实现了全流程的配置化变更，支持复杂变更，还能够可以到多个环境需要一个集群。

这个是我们改进前后的一个对比，数字都是相对的，环境数量原来改进前只有200多套，大家开发起来也比较的痛苦，整个环境在我们管理中，可感知的环境是不多的。

改造后我们发现创建一个新的环境实在是太简单，直接在界面上很容易就配出来。配置节点，改造前预支付的测试环境跟之前的测试环境有一个交错，这样的话环境都是交错的，每一个测试环境都需要一个Nginx节点，我们测试流程完了把节点压缩到10个以下，把各个环境压缩在一起形成了2个节点。

自动化现在我们的界面直接就改一下，接下来一两分钟内马上可以看到改动的效果，基本上可以实现100%的自动化，变更的配置，5分钟之内就是一个环境配置全部都生效。电商这一块对交互还是非常的挑剔，比如说我们原来交付一台云主机，大家都能做到很快的自动化、数字化。

但是每次大促的时候，数据库的一些节点不能用云主机来支撑，我们做了很多的改进，重点是提升整体的交付速度，从需求提升到节点交付基本上压缩到30分钟之内，如果节点多的话非常接近云主机的体验。

最后我跟大家来进一下整个的电商保障里面做的角色的变化，首先我们发现整个角色，因为发布配置变更我们都建好了平台，不太人工干预。每次发生问题时候我们不是帮助他们检查配置，我们是平台owner的角色，这个就是运维来保证自己知识的自动化的落地。

还有很多跟开发达成共识，比如说我们做了数据查询和操作的流程，这个流程以前可能都是邮件沟通的方式，我们现在很多的做成，这一块实际上也出现了很多的问题。

平台参与者，我们在电商领域开发的落地能力或者执行能力是非常强的，很强的过程中，涉及到很多运维相关的东西，我们积极的参与进去，做了很多落地的事情，提升了很多的效应。

API和一些性能都是可以去跟的，最后一块我们做了很多的技术改造，去年我也讲过，我们的自动化率不停的在改进，今年我们做了更多的东西，从我们整个系统的自动化率总体上涨的不多，但是运维层面的感受还是比较明显的。
整个过程我们为什么能够实现，主要是在于压缩了人工环节。最终我们发现整个运维在电商这一块，作用最大的可能是架构改造和平台化建设，或者流量的调度迁移，一些平台建设，特定领域的运维知识的落地，比如说某一个人工操作的，可能在考拉合并阿里之前也在做类似的平台，我们运维也做了很多靠齐的事情和工具。

流程我们现在的进度已经到了做一些流程的沉淀的阶段，比如说原来电商领域都是口口相传，现在我们基本上构成了平台化，很多的巡检、发布原来都是人工干预，现在都做成自动化的流水线。