大型电商网站是如何做SRE？
本帖最后由 monicazhang 于 2020-12-18 16:14 编辑今天的分享包含四部分：第一，电商网站业务特征对运维的挑战。
第二，SRE 的日常。
第三，速度VS稳定性。
第四，稳定性和技术流程相关。
一、电网网站业务特征对运维的挑战
这两年的话，考拉这边实际上过得挺顺利，做到跨境垂直的全国第一，最后可能还是因为各种原因被收购了。反正对我们技术来说，这个收购就不说了，我们说技术层面。实际上在过去的一二年的话，考拉的成长是非常迅速的，整个业务的发展对我们运维的挑战实际上也是非常大的。
业务增长体量的话，实际上我们有一些新的挑战，主要是这四块，容器化的路径，一些成本压缩，还有更高的效率要求，最后一个是我们一直比较头大的问题，就是说我们有太多运维不可控的因素，因为系统越来越复杂。
在能效这一块实际上怎么说呢？不像一般的网站，我相信可能隔壁的阿里或者说腾讯可能做了容器化，但是我不知道有没有get到他们新的技术点，以前可能容器还是继续虚拟机方式用，我们这边可能是全套的全部容器CNF（Cloud Native）的标准。效率的话就是要求更高的效率，业务层实际上后面我也会讲到，他们对效率的要求是非常苛刻的。
然后还有成本，成本的要求是比较大的。实际上我们这边很核心的一个点，就是单日GMV的成本压缩，要不停地压缩到业界的平均水平，然后会有更高的水平要求。
下面我来跟大家讲一下一些电商业务的特征对运维的挑战，首先是系统规模，还有一些变更频率。上线成本这块，反正每次大促容量都是很头大的，然后最后开始小要求。
规模这一块的话，实际上最近两年，尤其是去年跟今年感受是比较明显的，因为这一块实际上做了很多的业务拆分。这个图是一个我自己手动画的，不是真正的现场业务图。
可以看到，原先可能是一个中间件，然后去调各种各样的数据库，后面的缓存就太多了。最近一二年，电商的趋势可能就是有没有框架中台，然后来做结构分离和很多单元化。
因为这种拆分，带来了新的问题，我们发现整个原来只加入一种框架的格局就改变了。我们发现后端他们开始使用JAVA，前端用node.js，BI支撑就是JAVA，可能各种人工智能相关的语言他们都用了。
这些不同的语言有各自的框架，开发团队也是相对独立的跟进整个技术路线的演化。比如说JAVA的演化可能走d o路线，或者是走其他的路线，每个预案都是独立的。他们有一个独立的生态环境。js可能有前端的研发，还有他们想切入到服务器，期望后端用全js的模式。
这些东西给我们带来的变化就是，部署可能变得不能一统天下。就是说每个部署的方式或者构建环境都是相对独立，不得不依赖人性化来解决。
然后集群规模也是变化非常快，包括以前也是大规模集群的大小，现在可以到1000或者是更多的规模。
这是我们其中一个节点，是每次大促的点的扩容状态，这个是一直往上走的。就是说有些情况下可以现优化，但是涨的不是很多，但是总体还是一直往上走的趋势。其实我们就是说不停地拆出去，结果还是有部分的拆不出去，然后规模一直往上涨。然后这种规模的话，对我们发布层的发布有好处也有坏处。
我们这几年业务的话实际上最近两年也做过很多演化，就是原来单机房，就是所有的业务，新开发的时候都是只做单机房的。比如说新的节点或模块。然后做多机房，然后再做单元化。
整个过程为什么会有这样的情况？就是因为整个过程比如说新建模块，或者是比如说一个促销模块，它刚开始建设的时候整个团队还想它只能做单机房的，靠整个单机房来确立一致性。后面因为业界都推荐中台建设，多机房就很容易铺开来了。
多机房这块我觉得倒不是很难，因为多机房相对来说各个大厂或者是一般的互联网企业都是能做的。但是这个设计很考验团队能力和一些数据一致性的问题。对运维也是很多挑战，因为很多的业务逻辑非常复杂，开发只关心他业务方面，但是从来没有考虑过业务使用的一些细节或者说基础环境对它的影响。
变更频率这块我们也发现了，就是后面会讲到，会有大概很多种变更，但主要就是三个：配置变更，代码变更，环境变更。最头大的是配置变更，配置变更是运营那边比如说配环境、配促销。这种变更好多是出了线上的问题和事故的，很多时候会发生资损的事情。
这个是我贴的一个样例，比如说我们在改进整个环境里面测试线上预发和生产环境各个环节的一个入口NG，然后应用层数据库等等。比如说生产环境，我们认为所有基础数据都是1。如果线上预发单位频率是1，然后应用也是这种频率。
但是到测试环境，我们发现这个频率非常高。我后面也会讲到，应用层可能一天专门有个人一天到晚就在发布，什么事情都不能干。他本来也能写代码，又没时间。
代码变更可能是我们发现线上真的有太多问题了。有很多新问题、新的配置，老板想看到某个特性。比如因为有个标签有问题，可不可以发生一些变更。它是一些应用配置活动，都是通过我们配置作业中心来实现的，然后业务的维护。
有些东西比如说有的商品或有的页面是因为各种原因需要把它停掉，还有一些资源优化需要发起。
我们发现所有的变更，每时每刻都会发生，而且我很大的感受是从变更计划，从早上8点左右开始一直到晚上10点，然后可能每天凌晨也会发布。
整个变更的过程，实际上我这里写的是代码发布。整个变更过程中能发生很大的变化。早期我们比如说1、2年前，我们PE的那个团队，基本上负责所有的业务发布。后来做了半年左右，扛不住了。
有个核心的PE发现，真的是没有办法这样持续下去了。他会发现发布的业务从早上到晚上还没有发布完，然后整个线上业务的老板都在等着。业务就很不满意，然后我们后面推了部分的自主发布。
去年到今年的话，基本上实现了全面的自主发布，所有的业务线都是由开发可以自己点击确定来做自动化发布。当然不是说这个东西我们一开始没做自动发布，而是说从风险控制角度或者流程控制的角度，我们没有做到很完善的风险控制。从去年到今年这个时间的话，我们做了很多流程校验，来实现变更风险预估。当然，我不能说100% 风险没有问题。
在这个过程当中的话，我想感受的可能这样一个变化。原来的话是一个自己动手的角色，然后我们现在可能主要是最原始认为是一个觉得自己尽量去发布，去年开始我们做了半年校验的角色，对所有开发进行赋能，然后告诉他们技能或者工具，然后还做了放权，对所有的权限之类的都去做迁移。今年的话可能更多地在做一些产业派的角色，主要是控制质量，对变频的结构进行判定跟限制。
还有一块实际上日常这一块……还有一块挑战就是成本这一块，大家知道从去年下半年开始，互联网很多裁员大家可能都有听说，我们也对内做了一定的优化。这个怎么优化呢？我们做的就是服务器。
我们整个团队起了很多优化项目，比如说流量优化，开玩笑的说替丁老板省了1个亿。这个是做服务器优化或者是成本优化带来的收益。
然后我们发现做电商这块真的是平时资源冗余太高了，服务器实际上很多水分可以压缩，然后降机柜成本，合并服务器。各种机房搬来搬去，都会涉及到成本优化，还有一些带宽的节省。
大家可能在以前吃大锅饭的时候，可能因为部门比较多，所以很多互联网成本大概都是提供整体预算以后就没有感知了。去年开始的话，就变成单独按业务部门核算。我们做了很大的改造，后来做了这一块的成本优化。
在这块的话，我们实际上遇到了一些挑战。这个以前可能说我做资源优化无非是带宽扩容，但是很麻烦的一点，有些东西不是我们能控制的，比如说他发那个版本可能带宽一下翻了十倍。我举个例子，可能业务异常，带宽一下上去，比如说原来CPU只用1%，突然间用到10%了都有可能。
还有评估容量，评估容量现在很复杂。以前的话可能说你这个跟我做对接，你告诉我你下个月新开了多少节点，基本上就OK了。
但在我们这边的话基本上不可能实现，因为整个业务线我们估算了一下，基本上各个模块可能有400、500个列出来的，但是数不出来的模块可能更多。然后这些模块，每个模块都有自己独立的容量。这个容量的话，说实在的一个个去核对或者盘点，基本上核对不出来。
有个业务方面的主管说我也不知道容量，反正谁会来调我也不清楚。你跟他说容量规划，他基本上说反正我的容量要够用，不够我找领导申请。
今天我们监控同学也在现场。我们负责考拉业务这边同学的跟监控的同学做了很多方面的工作。比如说对监控做切片，切片比如说大促、压缩、峰值的切片数据，然后根据切片数据驱分析容量的需求，仔细地评估，用工具和人工结合的方式来确定后面扩充的计划。
当然这个最终所有扩充都是依赖于压测数据，大概会有平时数据跟压测数据两种，最终是扩容操作。我们平台是支持云计算扩容和容器的扩容，所以理论效率应该还好，只是说扩容上面需要一些流程工具建设。
最后可能是一些效率的要求，我感觉从去年开始听到电商的领导说：我们跟隔壁厂看齐，就是要求更加高效。这是我们需要更改的运维方式。我们发现规模越来越大，领导层面是不愿意业务加量，人也加量。他们希望加量不加人，整个配置和变更的时间还得缩短，然后就是自动化的流程。这些都是一环套一环的。
最简单的一个例子就是我们的硬件的配置，比如说自动测试环境搭建，当然我现在好多不能说。自动测试环境就是说配置很多东西，有严格的生效上限。它大概整体能做到30分钟。然后2.0的时候我们做到10分钟级的，就是全自动。
最近的一个版本，我们全面整个环境改进以后，我们能做到大概2分钟到3分钟这个级别，所有的配备跟整个环境构建。我们之前在测试环境做了一个很为了省钱考虑的一个设计，就是说在3分钟重新从0开始建设一套线上环境，就是一键建站。这些各个大厂都会用，而我们整个环境里跑了多套。
最后我们讲这个效率的意义，基本上就是效率的好处。我们这边一直和业务团队，或者说整个研发团队，对标隔壁厂（现在叫隔壁部门，因为被收购了）。感受最深的就是领导说：淘宝他们提说开发的需求，就是他们开发基本上3小时就完成一个需求端到线上的例子。我们还没那么快，但是也在向他们的方向努力。
第二个感受可能考拉这边最近半年有跟其他友商有扯来扯去的情况，比如说抄袭等等这种情况。这些也涉及到研发部门。实际上新的研发的特性，或者说功能的上线，实际上是意味着商业优势。然后基于这两点，实际上考拉就给搞了一个效能部，然后专门负责设计更好的跨链流程和技术，然后运维这边的话也是在往这方面努力。
二、SRE的日常
日常我们大部分时间在扩缩容。为什么？为了省成本。今天把这个容量收缩回去，明天把这个容量扩回来，就来回倒腾，左手倒、右手倒，保证全年的IDC预算不超。然后还有做价格改进，价格的话比如说多机房、双机房单元化，主要是做单元化。
这块的话肯定需要很多的应用操作，比如说数据库的表，用的集群分离，然后实现整体的配置改造。还有最后一个基础功能的建设，是运维的趋势，运维相当于要做开发嘛。然后还有一些运维赋能的工作，主要是做一些运维支持跟专家知识的落地。
实际上这个是我每天做在的事情。我们发现PE那边做的事情都是半年后才会评估。因为他们发布的那些工作都已经放给开发了，最近做的事情就是去评估容量，然后评估整个集群的状态。比如说这个状态这个集群容量是OK的，但状态有点异常，怎么样去跟进。
然后还有一个成本，每次扩容业务层面就觉得我这个业务可能接下来领导很重视，需要给我扩5倍，但是这个我们要去抢他这部分的资源。
还有一个就是评估，我们不停地在评估容量。这些总体的目标都是为了提升资源利用率，比如说单个机器的利用率，整个机房的资源利用，比如说CPU利用率从10到20，到30、到40这样一个翻1倍的情况，只有这样才能确保整体我们全年的增长百分之多少的情况下，资源的成本，或者说总体成本能够维持住。
最后一个实际上是做容器化，我们这边容器化这个东西有一个很好玩的地方，就在于说容器化的东西既涉及到技术含量又涉及到成本，因为很大的一块的考量实际上都是为了成本考虑的。
我们的架构实际上运维参与的在最近一、两年比较多的，一直在做架构方面的改进，协助团队一起做。所以我们这边做了很多的服务化相关的事情。最近可能在做事务这块东西。然后比如说以前单机房，现在多机房，现在做单元化。
整个我们发现业务对运维的要求是越来越高了，比如可能单路的时候配HA，然后我们配的Keepalived就可以了，多机房的时候我们要考虑怎么切换。业务层面他根本不关心的，比如说数据库的多机房，你们运维复制一下吧，他们从来不考虑谷峰延迟，我们需要去研究一下数据库的半同步、全同步还有对业务的影响。
这块实际上很考验运维团队的功力。然后说走单元化，单元化这一块，实际上业务层面还是想的很简单，我们的大部分业务都是无状态的，肯定是单元化的。实际上从运维角度看的话就没那么简单，比如说底层的，比如说跨机房的链路会不会有问题，数据库双写怎么搞，实际上都是我们业务人员应该考虑的。
然后我们整体的整个架构是业务团队自己推动的，就是研发效率，其次是稳定性，最后是容量跟性能的考虑。所以这个变化都是配合业务团队或者是主要由业务团队来做，然后最核心的还是稳定性是第一。因为电商这块领域的话，说实在的宕机一分钟可能就损失好多钱。
技术相关就是运维这个角色我们日常里面做了很多方案设计的评审，比如说业务层面开发了一个新的模块，然后找我们运维去评审，这个东西是不是高可用，然后有没有问题。可能业务团队想的很简单，我这个东西能跑就可以了，然后我们会去challenge，就是说告诉他们你这个东西不准备给你上，这个不给做。还有些做的很多运维和架构方面的设计、开发，后来进行一个知识沉淀。
这个是我们最近重新搞的一个知识库，实际上这是个界面，后面是一个打通的操作。然后我们在这块做了很多的探索，比如说IM+自然语言处理+CMDB+内部的系统，都有考虑整合在一起，最终是一个ChatOps的平台。这个可能跟其他厂相比也没什么特别，只是这块可能是我们运维去思考和去探索或者整合的那个情况。
三、速度VS稳定性
在整个过程中，实际上日常的考拉的运维，或者是电商的运维，可能感觉架构和技术实际上大家都是往一个方向努力的，没什么问题、没什么异议。实际上开发一直在踩油门往前冲，然后运维说实在的是希望稳一稳踩个刹车。
我们发现速度可能是越来越快的，油门踩的快，然后整个车的技术组件，比如说它的引擎、它的消息处理的速度，就是传轴之类的润滑的更高、变更密度最大，所以整个油门方面最终看可能踩的还是比较狠的。
我们这边实际上是对迭代速度影响最大，可能是有项目拆分做了很多的参与。比如说一个应用改变一个业务逻辑，可能需要把整个前端后端都糅在一起发，为了改一个前面的页面属性，把整个系统重启，实际上很重的。我们做的，基本上是从去年开始，或者说最近两年应该是差不多全部都拆掉了，有个小主页修改很快就供上去了。
还有结构改造，原来的话可能ABC可能都是相互顺序依赖发布的，应该说前年开始，基本上ABC可以随便发。
然后还有新功能引入，电商这边比如说促销，他们都会有新的产品线、新的业务逻辑，这块肯定也会很快。
最后是新特性迭代，我指的是很底层的那种特性，跟业务无关的，比如说Dook sidecar或者新技术的引入，对我们整个业务的开发模式影响还是比较大的。
这个是我对那个业务变更速度的一个简单评估。在我们最开始前端的时候可能说我们的基数是1，然后在前后端拆分的时候发现速度一直往上走，到业务结尾的时候基本上到4的程度。
全部弄完以后，我们评估了一下，可能又比原来又快了一遍，因为以前CI/CD可能是很重的，可能是说整个CI/CD以后可能还是需要运维去审核。现在只要容器被自动测试跑过，可能就容器部署，就没有什么个各种环境检查之类的操作。
然后，从业务的维度上说，它希望采用新的特性。因为它的KPI是新特性的交互，领导对他们的要求是说你今天可能要把新功能上上去，要求就今晚上上去，就很简单对吧。开发这边从个人角度来说，领导要我新特性，我希望这个新特性赶紧上线测试一下，因为我这个没有QA，然后他希望这个项目进度在周五之前就完成，因为我周末不想加班，开发都是有这些想法的。带来的问题就是说就会有很多线上问题，我们发现主要问题就是业务线很长，QA盯不过来。隔壁部门比天猫或者淘宝可能就是开发自测，我们也在推。很多的开发实际上说我有线上自主发布，但是它实际上完全不知道线上的那个怎么运作，他只知道业务的逻辑。
最可恨的是因为可以自主发布嘛，把他们整个组可能都加权限了，他们自己组长可以加权限，所以会导致有这样的情况发生。比如说进来没多久的新员工比如说刚转正，他就有权限发线上，然后他经验不足，直接把线上给搞出问题了。
我们开发自己的DevOps，当然可能跟我们想的不一样了，我们想的DevOps可能说开发跟Ops的隔离性能给去掉。最终的结果我们统计的最近一年的情况，基本上会发现所有的变更相关的事故，有很多的都是比有一半都是自己发特性，或者搞什么配置，弄上去的。
然后还有大概33%左右的软件bug，因为软件有bug。有些bug真的太复杂了，真的没法说测试环境能够完全回归到。还有一些是第三方影响，可能是我们没考虑到第三方的那种强结耦，这些都会有问题。
我们来讲讲个case，印象非常深刻的一个点就是今年差不多4、5月份，有一个项目，周末加班改进，然后晚上7点左右的样子，线上直接爆了，一堆人全部都炸上线了。为什么？查了半天，有一个业务有发布。
然后第二个是发布变更的时候没协调，实际上我们现在做的结耦，但是这个结耦真不能说是完全结耦。因为它是分布式调用，但有可能说有的组件能够变更有问题，有可能会导致上游变更调用报错，各种情况都有可能发生。
这个问题就很严重，基本上开发加班搞事情，然后我们最终的问题是运维背锅。运维就很憋屈，我给你权限、给你自动化运维、给你做了很多兜底，结果你绕过了整个流程，然后你给我搞出这样的，真的很憋屈。
我们在运维这块，实际上是也有对线上稳定性做思考，比如说我们的PE或者DBA、或者SA都想过了。线上所有的最好我们运维自己做，然后运维做的话，肯定线上都稳。因为我们都有丰富的经验和专业知识，不会有问题的。
但实际情况就是整个业务线太多了，你真的所有人都去跟一个业务线，基本上人都分不过来，分身乏术。有些时候还不能解决所有问题，因为某些领域可能也是说操作可能同时只能一个人操作，不能多人操作，多人操作可能有问题。还有大型团队的协作，可能效率会下降。
中国的互联网，有些时候老板还是喜欢有一点新的想法，像我们公司或者说腾讯的马老板，都是项目经理嘛，他会有一些新特性的需求。老板都在等，老板需求第一位，肯定会先上。
对于这一块，实际上我们在今年开始就做了一些探索性的东西，主要是平稳，速度这一块一直从去年下半年到现在一直在做这个事情。赋能，把权限都放宽，全部都放给开发，平台的话支持自主变更，比如开发点了以后，什么时间点开始自动更，更完了就不用管了。
然后，稳定性这一块，我们做了很多的那种工作，比如说对业务做了等级划分，L0、L1、L2、L3，划了三四个等级。审批流程，以前可能业务的小组长说我想发就发，现在可能会有一个升级机制或者是有个新的流程，根据不同的业务有不同的流程。
我们都对业务方说你要自主发吗？可以，还有个SLO反馈，这是最近半年在做的。
总体上来看，我们的技术+流程最终是会带来线上的稳定性，然后接下来是我们对一些线上问题的电商这块稳定的看法。
实际上跟Google一样，我们的问题是永远无法避免的，线上允许出问题，发布出问题。认为有些是没有感知的。如果说5分钟之内恢复，基本上就没感知，那么直接就pass了。
今年的话我们可能对线上的问题是可以容忍的，但是我们也设计了SLI/SLO指标，比如某个业务你要承诺你对上游的服务可靠性多少，所有这些指标以业务影响程度为准绳。比如说我可能挂半天都没影响，那这种可能就不算。
还有线上事故的处理机制，我们这边可能都会出一些紧急预案，比如说某某业务挂了之后，直接就一键止血优先。比如重启，发布，重启，然后回滚，实在不行就是全部进行销毁。然后会做很多的事后复盘，举一反三。
比如说A业务出了一个事故，然后业务方会说A业务OK，出事故了，我们认同，但是你们有没有举一反三？举一反三的意思是说你后面不只是你A业务层面有考虑到后续的类似问题，还有B业务的团队也需要去思考这样的情况。
然后我们考拉这边如果是有线上事故了，会有一个通报机制。比如说根据规范等级会通报所有的技术团队，说A业务出了问题，是事故，然后惩罚了多少，后面的惩罚机制。
这个问题我们在运维方面也是做了一些工具，比如说我们做了一些平台。这是平台的一个简单图，比如说我们平台对事故现在是人工的跟自动的发现为主，先统计到工程维度，工程维度再统计到业务线，业务线再到全站，这些都是自动化计算的。有了这些以后，我们线上问题最近下半年稍微有一点收敛。
四、技术&流程建设
最后一块可能是我们对整个电商领域的一些在运作过程中的一些技术跟流程的思考，可能不一定跟电商非常密切相关，但是感觉还是稍微有一点通用性的。
关于流程，这块可能大家，所有的部门团队或者技术团队都在做流程相关的建设。比如说很简单，所有部门都约定俗成的，比如说我有些时候跟我的团队成员说我们约定俗成啊，这个事情一定要这样做，然后再这样做，后面这样做。
OK，没问题，半年以后没人记得这个事情，所以我们会写成文档。文档写完可能会说大家所有人定期要看一下文档，按照文档来做事情，OK也没问题。但是当我这个团队比如说我这个文档需要给跨部门用的时候，没有人会care你的文档，所以我们做了平台化程序化。
运维这边我们在建设这个流程的时候发现，我们的目标总体是为了线上稳定，或者是为了一个特定问题求解，比如说线上要求做某件事情，可能只能按照它的流程来，那种可能很多都是比如说审批相关的，比如说走公司的申请流程，然后方式的话可能无外乎就是制订标准、执行标准、改进流程。
在整个过程中，我们运维是非常希望能够达成标准执行的，比如说我希望所有业务方都按照我们运维的标准做某件事情，但是实际上在现实中非常困难。
很简单，去年下半年，我们做了一个运维跟业务部门的绩效留用，比如我们运维上半年做了什么事情，然后跟业务方汇报，说我们下半年整体的运维怎么样，希望你们提什么意见。其中一个开发跳出来说，现在的流程太复杂了，我们是创业公司的，希望很多流程可以跳过来。
因为业务方是甲方，所以（流程）还是会听他们的。我们做了处理，然后在整个业务建设流程上我们发现很多问题。
当然听取他们意见，让我们发现流程实际上是有冗余的。最简单一个例子就是说我们为了线上稳定性，执行有一个标准，然后这个标准执行完了，大家都按照这个标准做.
但是真的事故又发生了，为什么？肯定会说跟代码一样的，我有一个异常CASE没考虑多，那怎么办？那加一下流程呗，反正再加一条，比如说原来要没检查A的，你再检查A吧，然后我们又发现这个流程会越来越膨胀，流程会非常低效.
比如说做一件事情，比如运维要线上改个配置，有一个流程。现在可能就是说没有流程又不行，希望通知业务部门开发，业务部门开发找业务部门老大，找集团老大，然后再找用户老大，多层审批，然后完了以后就有一点像为了规风险，大家不停甩锅的节奏。
这种流程应该是很少见，但是不能说没有，我相信各个大厂都一样。还有一个是流程建设，没有达成共识，这个是很痛苦的一点，我们运维这方面做了很多的标准化流程，结果发现有一些流程连我们内部的人都没有遵守。
还有一些是没人知道流程，因为整个的文档太多的话，会发现在制定流程的时候很爽，但是流程广播的时候发现我们内部的团队知道，外部的团队搞了半年，对我们内部的流程一无所知，最后是形式化的流程。
对于这些问题的破局，我们也做了一些探索。首先我们做了流程平台化，workflow任务落地，用新的工具技术减少人工环节，运维赋能开发，设计的时候考虑各种异常，压缩处理流程。
这是一个典型的例子，比如说我们的大促，它其实是一个非常复杂的工程流程。很多的电商平台，或者说友商，很多的流程预演、很多的跟进，很多库存的调度，这些都是流程。流程太多，刚开始都是口口相传，因为流程太多了，最后没法校验。有一些流程执行着中间就跟丢了，我们做了大促平台，还做了一些去流程化的东西。
我们现在中间加了很多自动化的机制，所有环节都是人工操作，现在中间加了一些自动化的设置，人工操作只有在自动化失效的情况偶尔去借助一下，测试环境也做了一些流程，有一些流程是不需要审批的，我们就免掉了。
这个是我们在流程方面做的很多的改变，让整个的研发效率和运行有很大的提升。业务团队这样整体执行下来，我们现在还是比较满意的。
这个是做技术改进的一个实例，我们做了很多的技术改进，这个是典型的收益。一个是Nginx的，我们在测试环境实现了全流程的配置化变更，支持复杂变更，还能够可以到多个环境需要一个集群。
这个是我们改进前后的一个对比，数字都是相对的，环境数量原来改进前只有200多套，大家开发起来也比较的痛苦，整个环境在我们管理中，可感知的环境是不多的。
改造后我们发现创建一个新的环境实在是太简单，直接在界面上很容易就配出来。配置节点，改造前预支付的测试环境跟之前的测试环境有一个交错，这样的话环境都是交错的，每一个测试环境都需要一个Nginx节点，我们测试流程完了把节点压缩到10个以下，把各个环境压缩在一起形成了2个节点。
自动化现在我们的界面直接就改一下，接下来一两分钟内马上可以看到改动的效果。基本上可以实现100%的自动化，变更的配置5分钟之内就是一个环境配置全部都生效。电商这一块对交互还是非常的挑剔，比如说我们原来交付一台云主机，大家都能做到很快的自动化、数字化。
但是每次大促的时候，数据库的一些节点不能用云主机来支撑，我们做了很多的改进，重点是提升整体的交付速度。从需求提升到节点交付基本上压缩到30分钟之内，如果节点多的话非常接近云主机的体验。
最后我跟大家来进一下整个的电商保障里面做的角色的变化。首先我们发现整个角色变化，因为发布配置变更我们都建好了平台，不太人工干预。每次发生问题时候我们不只是帮助他们检查配置。我们是平台owner的角色，这个就是运维来保证自己知识的自动化的落地。
还有很多跟开发达成共识，比如说我们做了数据查询和操作的流程，这个流程以前可能都是邮件沟通的方式。我们现在很多的做成平台，这一块实际上也出现了很多的问题。
平台参与者，我们在电商领域开发的落地能力或者执行能力是非常强的。执行的过程中，涉及到很多运维相关的东西，我们积极的参与进去，做了很多落地的事情，提升了很多效率。
API和一些性能都是可以去跟的，最后一块我们做了很多的技术改造。去年我也讲过，我们的自动化率不停的在改进。今年我们做了更多的东西。从我们整个系统的自动化率总体上涨的不多，但是运维层面的感受还是比较明显的。
整个过程我们为什么能够实现，主要是在于压缩了人工环节。最终我们发现整个运维在电商这一块，作用最大的可能是架构改造和平台化建设。比如说流量的调度迁移，一些平台建设，特定领域的运维知识的落地。比如说某一个人工操作的，可能在考拉合并阿里之前也在做类似的平台，我们运维也做了很多靠齐的事情和工具。
流程我们现在的进度已经到了做一些流程的沉淀的阶段，比如说原来电商领域都是口口相传，现在我们基本上构成了平台化；很多的巡检、发布原来都是人工干预，现在都做成自动化的流水线。
页:
[1]