【51CTO专访】在2012年12月4日召开的Velocity China大会上，大家翘首以盼的、有关淘宝双十一的分享，终于正式跟大家见面啦！虽然这一场被安排在了下午5点以后，但现场的观众们仍然很热情，同时很多场外的观众们也大呼可惜，感叹自己没能请假来跟台上的讲师交流一番。
《购物狂欢节的运维故事》，站在台上的讲述者是刘勇，花名仲明，阿里资深技术专家，任职阿里集团技术保障-应用运维一部。仲明跟其他很多运维的不同之处在于，他在进入阿里集团搞运维之前，是一名做开发的。而很多搞开发的观众们在听了他做的这场分享之后，纷纷表示恨不得立刻跑去搞运维了。
仲明在会后已经将他本次分享的PPT公布了出来，大家可以在微盘上下载，也可以到微博上跟他交流。而另一方面，51CTO编辑本次也有幸跟仲明进行了一些其他方面的沟通，做了下面这个专访。
本次专访的主题是：阿里集团运维部的发布、监控与故障响应。
希望对大家有所帮助！
---采访实录正文---
软件发布
51CTO：先请您介绍一下淘宝运维部的代码部署机制是怎么样的吧。首先，你们用什么工具？
仲明：其实整个公司的现状我们是用自己研发的东西，但是里面也集成了一些第三方的东西。比方说我们一些打包的机制，用的是rpm。
51CTO：打包用rpm？
仲明：对。我们部署里面用到了yum这个工具。其实yum是基于rpm之上来发展的，它解决了rpm之间的依赖关系的问题，这个我们是集成在里面的。所以基于这个之上，我们再有一个叫做pubfree的东西，专门做发布的，内部运维使用的工具系统。
51CTO：专门做publish？
仲明：对。我们yum解决的问题是说包与包之间的依赖关系的问题，它解决的是这个，它的使用场景更多的是在单机上做软件的升级和发布。那么对pubfree来说，我们要解决的是我们的批量。我们维护网站的话，有很多集群，每个集群有几百台机器，我们怎么批量部署，同时又解决风险控制的问题，比如说我们的发布——在生产环境下——一般走预发，再走分批发，因为这样是为了规避风险，比如预发有问题的话，能够及时的退回来，而不影响用户。
51CTO：预发和分批发是什么意思？
仲明：预发是这样的，比如说一个集群有200台机器，先把一台机器摘下来不提供服务，把程序推上去，再验证这个程序在这个地方是不是跑的正常。如果跑的正常，那么预发就结束了。然后我们可以在200台的机器里面先推50台，挂上去提供服务，如果运行一切正常，我再会把其他的全部更新程序。这些是为了规避一些潜在的隐患，因为有一些问题，在测试环境下，不一定百分之百覆盖到的。
51CTO：所以你们都是用yum直接做包的操作，而没有用git或者puppet这样的机制？
仲明：没有。git更多的是一个源代码的工具，包括svn也是，它们都是用来管理source code。我们从运维的角度，更多的管理是生产环境的软件。我们的source code主要是生产环境之前的过程：不管是Java还是C，都要有一个build的过程，就是先把source code给check出来，然后build，build完了会生成一个要发布的软件包，这个包我们有可能做成rpm的，我们自己做一个tgz也可以，这个没什么差别的。只有这个做完之后，我们才会拿这个做完的包推到生产环境上去运行。
所以生产环境不会直接git或者svn。在生产环境下，我们不会直接去check出来源代码在上面build。
51CTO：所以你们都是以软件包的形式控制的。
仲明：是的。可以发布的东西才可以转到生产。
51CTO：那你们这样比较可控。那版本控制是什么呢，就是软件包自身的版本机制？
仲明：对，其实我们打软件包的话就会产生一个版本，每一次build一个包，都有一个新的版本出来。就是说，只要你一build，就会有一个新的版本出来，这样的话你每一个版本都不一样的，就可以区分。那我们每次发布就会标识，我这一次发布要发什么样的程序过去，我们是看build出来的package的版本，要发布的人就说，我要发这个版本的package。
51CTO：那像您提到的分批发布，比如说200台的服务器的集群，我先走10台再走一半，再全部走，这个是怎么实现的？
仲明：这个就是用刚才我说的pubfree的这个工具，这个工具就是解决这样的问题，第一个是分批的问题。其实往一台机器上推程序是很简单的事情，我基于yum就可以更新这个程序。但是一个集群我要怎么管理，这就涉及到第一个是要分批的事情；第二个分批即使发了，你要校验是不是正确，你还可以随时停止；第三个就是你还可以随时回滚，比如说第一批发上去，一check的时候，发现有问题，那我还可以退回来。
51CTO：比如说1.0.2发布了之后有问题，你们是再退回1.0.1？
仲明：差不多，比如说我现在的版本是1.0，我现在要发一个新的版本叫1.1，1.1推到一台的时，预发的时候，大家没有发现问题，我现在推10台，结果到了10台1.1后，发现出问题了，这种时候，我会把这10台回到1.0的状态。这就是pubfree这个工具能够控制的事情。这个工具纯粹是我们自己开发的。
51CTO：这么好的工具，以后会开源吗？
仲明：这个，有可能会啊。
51CTO：机制我大概了解了。那么，整个发布的审查过程是怎么样的？
仲明：审查过程是这样的，两种方式结合，第一是自动化的审查，我们每一个产品有一个preload的脚本，这个工具是可以调用这个脚本的，这个脚本运行的时候会做很多的探测，探测我的服务是不是正常的。说个最简单的，比如web服务，有可能在web服务上加一个脚本或者是一个内部页面，这个页面实际上是一段程序，程序员写的，这个程序会check我们内部的一些接口之类的。check接口会形成一个test的逻辑，返回一个结果告诉你是否正常，比如一个产品提供的接口有20个，每个都check是不是ok的。
51CTO：这部分就是机器自动在那里做么？
仲明：对，这就是一个程序，可以跑的，一个程序就可以调内部的任何一个接口。那么跑完一看，这个程序就会反馈一个状态（结果），我们这个平台会去调这个程序，拿到结果，来做一个判断，如果这20个接口你认为都是ok的，那就ok。这是一个自动化的。
第二个就是我们的QA（测试人员）也会参与这个过程，他们去会跑一些核心的测试用例，一些关键的测试用例，来看这些用例是不是正常的。如果这些用例跑完都是ok的话，他就认为这个服务是没有问题的。
我们说的这个是预发阶段，因为用户没有参与进来。那么我们在预发阶段的这些验证的手段如果都过了，我们认为预发就ok了。然后我们就推一批机器，比如说200台，我先推20台。那么推20台的时候，这些机器就会对外提供服务，用户可以访问这20台机器，用户的流量就会进来。流量进来之后我们还会观察，包括我们的监控系统都会看，去分析这些日志，是不是有错误日志啊，会不会有不正常的日志打出来。即使我们的日志方面没有任何告警出来，有时候也有用户的反馈进来。
51CTO：所以这个阶段就是看log和用户反馈了。
仲明：对。实际上这时候对用户是有损伤的，但是没办法，因为我们之前做完了离线的测试，包括我们生产环境的预发，用了这么多的检测手段，都没有办法出发现这个问题的话，那么我们唯一能够规避的，就是缩小对用户的影响，所以这是我们批量发布的原因。我200台分几次发，第一次发20台，也就是十分之一的用户受到影响，就缩小了影响的范围。分批发布的目的是这个。
如果这一关还过了的话，那证明我们真的是正常的，这时候就200台机器全部把新的程序推上去。
51CTO：这个有不同的级别吗？
仲明：是有级别的。我刚才说的是一个全流程。其实分批有一个东西，我们有一个名词叫灰度，我刚才说的分批有几种情况，一种分批就是我们平时的操作过程可以做分批，这种分批的间隔是比较短的，有可能是一个小时；但是我们如果说到灰度的话，这个间隔是很长的，我们一般的灰度至少要求24个小时的间隔，就是说，200台，我发了20台上去，我要观察24个小时，然后才可以决定是不是要推新的上去。
灰度实际上专业名词叫bucket test，就是桶检测，抽一部分用户去检测。这个有几种方式，一个是按流量比例来抽，按流量比例来抽就是随机命中的，有可能百分之百的用户有可能都会被命中。还有一种情况是根据用户来抽，比如说根据用户的cookie来判断是不是该进入到桶里面。这是另外一种方式。
我们现在对于灰度的应用是可以选择的，不是每一次发布我们都要做灰度，因为这个代价太高，会导致发布的效率很低，刚才说了一个灰度至少24小时，这种是对我们很核心的应用。比如说淘宝，淘宝最核心的交易流程上的应用我们是这样控制的，让你去走灰度。但是对于非核心应用，我们一般不严格要求你去走灰度的。
51CTO：所以一般涉及到支付的更新肯定是要做灰度的。
仲明：对，涉及到交易付款，这些程序的变动我们是要求走灰度的。
51CTO：其他的像页面展示之类的就不用了吧。
仲明：其他的我们就是普通的预发，分批发。
51CTO：这种观察期都在1小时？
仲明：对，一般控制在一个小时之内，所以这样效率高很多。
51CTO：那你们的发布频率很高啊。
仲明：对，发布频率非常高。因为我们分很多应用，应用实际上说白了就是集群，node group，每个node group是可以单独发的。像简单的，比如淘宝网，淘宝网就有好几百个node group。
51CTO：相当于几百个业务？
仲明：应该算是几百个service吧。这些服务当然不能单独对外提供一个业务流程，一个完整的业务流程会把很多服务串起来，这样的话，我们是切分成很多这样的服务的。一台机器是一个node，一组机器做一个group，里面的每台机器做同样的事情，这样的一组node group 提供相同的一个服务，我们多个这样的集群才会完成一个完整的业务流。这样一个完整业务流上的每一个node group都可以单独升级的，所以你就发现发布量是很大的。
淘宝网大概有500个以上node group。每个node group一周只发一次的话，一周就要发几百次。当然，实际上没有这么恐怖了，因为每一个node group更新的频率是不一样的，越往底层的node group更新的频率就越低，越接近用户展现层面的，这个node group更新频率就越高。一周一百个左右是有的。
51CTO：那也很多了，一天是十几二十个？其实挺紧张的吧。
仲明：当然我们不是串行的，它有可能会是并行的，根据业务的相互的关系来判断。比如说你两个node group之间的变更如果没有依赖关系，他们是可以并行去做的。
下一部分：监控
#p#
51CTO：那部署这一块的大概情况基本上您也介绍的差不多了。下一个问题是有关监控方面，首先主要是想了解一下你们主要都做哪方面的监控，可能尤其是网络方面，我们会比较关注一些。
仲明：这样来说吧，我们是分三层做监控的。一层是基础的，这种基础的包括网络，比如说我们的路由器是不是通的，我们的交换是不是有问题啊，DNS服务是不是有问题啊，等等，就是一些基础服务，我们都放在基础里面，包括我们OS层面的，比如磁盘是不是已经快满了，包括我们内存的使用问题，这都属于基础层面的，我们叫基础的监控。
基础层面之上我们叫应用监控，应用监控更多监控的是这些容器，比如说我们的JVM，是不是跑的正常，是不是有频繁的GC（垃圾回收），这些是应用层面的，包括我们近来的流量是多少，每秒的请求量QPS是多少，是不是QPS有抖动。然后我们的RT（反馈时间），也要监控，比如说平时的反馈时间都是100ms，是不是有突然的变化，比如超过了200ms我们就要报警，因为我们的服务质量已经下降了，这是应用层面的监控。
再往上是业务层面的，业务层面就很多了，比如说像淘宝的业务，有创建订单，用户下单买这个东西我们叫创建订单，那么我会监控这个创建订单的数量。比如说每秒创建多少笔，这个曲线发现突然的一个波动，本来每秒创建是2000笔的，现在突然一下降成500笔了，这就有问题了，但是这个东西要通过业务层面的数据才可以发现的，不是说系统。系统还很正常，load很低，CPU也没有什么消耗，但是它已经出问题了。
所以说三个层面去做。
你说的这个网络监控，我这么认为，一个是包括内部的网络状况的监控，第二个包括外部用户的网络状态。从用户端看我们的行为，用户端是一个完整的访问过程，从客户端发起到服务端响应，到用户拿到结果，这么一个完整的过程来看，我们的应用是不是正常的。
51CTO：对，因为有时候我们的监控是正常的，用户访问起来就有问题。
仲明：在我们公司有两套手段，一个就像基调这个，我们是用了他们的服务的。他会从全国各个点探测我们的服务是不是正常的，我们判断是不是某些区域出了问题之类的。另外我们公司有一个工具叫Alibench，它在全国有很多client，在用户这一端有很多的志愿者会去装这个客户端。这个client会去探测我们的服务，我们拿到探测的数据进行分析，我们的服务是在DNS解析上有问题，还是在建立连接过程慢，还是什么其他原因。这些数据我们可以看到，我们怎么去优化我们的网站，是不是有哪些用户访问的网站已经出现了性能瓶颈。这是我们现在主要使用的两套工具，来判断用户使用网站的体验。
51CTO：刚才您说的应用层面和业务层面的监控，能不能多介绍一下？
仲明：应用层面更多的还是从内部在看。刚才我说的Alibench和基调，其实是从用户的角度去看，完全从用户端去看。
从服务提供端来看，我们说应用监控，大部分都是在这个地方做的。我们会在内网，就是我们的机房，去发起这个探测。一种是我去探测我业务的接口是不是正常的，模拟用户行为去看我这个服务反馈是不是正常的。
51CTO：这个也是自己编写的功能？
仲明：对，这是一种。还有一种我会检测各个业务流程的数据。比如说我会看，现在用户过来请求任何一个服务，他的QPS是多少，他的RT怎么样，反馈出来的响应时间是不是正常的。我还会监控我们的slow query（慢查询），就是用户访问我们网站的时候，我会把slow query全部记录下来。比如说一个网站，用户会有很多的URL来访问我们的网站，那么我就会把响应时间超过一秒的，所有的URL 日志里面全部会拿出来。这个URL ，一般来说我们会有一个比例，比如说我这个网站每秒的请求数是1000个，那这个slow query有可能根据我网站的特点，我应用的特点，有可能是千分之一的，我会去监测它。如果这个slow query出现了波动，我就知道，我的网站有可能出现了问题，这个问题有可能来自于一个新的发布，我新的一个程序更新，导致我slow query的比例提升了。这种情况下，我就知道应用发上去之后，网站对用户的感受是降低的。因为我服务端去响应的时候，服务端耗时已经变长了。这种情况下，我们会把这些slow query抓出来分析，到底是哪些slow query新增了，要求开发团队把它改掉。
51CTO：意思是找到造成slow query的那些URL么？
仲明：其实我们每个人请求网站的时候，web服务端都会留下一个日志，这些日志会记录下谁来请求我，请求我的哪个URL地址，你耗费了多长时间。所以我们会基于这个东西来做分析。
51CTO：这个抓取数据是用什么做的？
仲明：我们的web容器都会打一个日志文件叫access log，这个里面你是可以配置的，我记录哪些信息。最主要的信息就是我刚才说的，从哪来的请求，谁来访问我，访问我什么URL ，返回的状态是什么，花费了多长时间，你是什么agent过来访问的，是IE浏览器还是Chrome浏览器，它会记录这些信息在里面，那我根据这些信息可以做很多分析的。
服务端的东西其实完全都在我们的控制之内，因为用户只要访问网站就会留下痕迹，我都可以记录下来。服务端是可控的。因为这个服务器都在我们手上，包括服务端的网络，路由，网关，我们都是可以控制的。但是用户的感受是什么样子，比如说用户的接入端，其实是不可控的，它的接入我们是不知道的，有的用户接入网很差，他的体验就会很差，这个我们是不知道的。这就只有通过基调或者Alibench这种工具来看。
51CTO：那除了您提到的响应时间这些，其他监控的参数还有哪些？
仲明：QPS和response time这是最基本的，每个服务都会有。跟业务相关的监控，不同的服务会不一样，比如说web容器，QPS和RT是最核心的指标，代表我是不是可以快速的响应用户需求。再就是看容器的一些状态，刚才也说过，比如说我们的JVM，是不是频繁的发生GC。还有系统层面的很多东西，包括内存的使用。JVM实际上是一个虚拟机，它自己会控制一部分内存，这部分内存的使用是什么状态，这个是我们随时要跟踪的。
再往上走，到不同的业务，比如说我是一个cache，那跟web容器又不太一样，cache更多的是看命中率怎么样，命中率有没有变化，比如说以前的命中率90%，你现在命中率可能下降到70%，这个是很危险的，所以对于cache来说，我们监控的东西就不一样，首先同样的我们会监控QPS和RT，另外我们主要看他的命中率怎么样，数据交换出来的速度怎么样。
还有其他的，比如说像消息队列，这个监控又不太一样了，我要看队列的长度。你队列太长的话，证明这个消息在里面等的时间太长，代表着你的服务对用户的响应时间会变的越来越长，不够及时。
51CTO：怎么算长呢？
仲明：不同的业务是不一样的，因为不同的数据我们需要的响应时间是不一样的。如果你要做队列的话，证明你已经是异步的处理了，就是说你没必要同步响应用户，是一个异步的过程。但是，其实又有很多的异步服务是为了响应用户的实时服务的。这是什么意思？比如说用户现在要下单，下单的时候，我为什么要加一个队列呢？就是因为我后面依赖于另一个服务，另一个服务的速度和我前面服务的速度不匹配，那就必须有一个队列做缓冲。比如前面的服务每秒钟处理1000个请求，后面服务每秒钟只能处理800个请求，这就出问题了，当你达到峰值一千的话，你发现后面响应不过来了。这种时候我就有一个队列做缓冲，缓冲你200个，那么因为你的服务不可能一天一直是满的，你会有一个低谷，稍微峰值一过，低谷来的时候，就可以把这个队列消化掉。
但是我们又要去看，这个队列到底排多长，如果队列太长的话，你发现就出问题了，比如说我们以前用户从前端过来，200个ms回去，当我出现队列的时候，有可能变成300个MS回去，那这个有可能还是可以接受的。如果说我们的业务要求这个用户超过了500个ms就不可以接受，那我们就可以算出队列多长是合理的。所以就是根据不同的业务判断你的队列到底多长是一个可以接受的范围。
51CTO：500个ms算是一个标准吗？
仲明：不一定了，对于不同的业务，不同用户的忍受程度是不一样的。从服务端来说，500个ms其实已经算不短了，因为服务端的响应时间，还要加上用户网络请求、往返的时间，建立连接的时间，DNS解析的时间，在用户端的反应有可能已经超过1秒了。
当然了，对用户来说，一般觉得1秒是可以接受的。就像今天上午Google的那位同学讲的，有可能到3~5秒，用户才可能不访问你的网站了，走了。其实用户的接受度还是比较高的，1秒是可以接受的。
51CTO：那CDN方面，也是您关注的范围吧？
仲明：当然是了，CDN也是我们的服务内容之一。CDN的目的很简单，就是加速——提升我们网站的速度，因为我们一个网页下来，你发现，特别是像淘宝、天猫这样的网站，有大量的图片。你说我们打开Google首页看一下，内容很少，所以很快，但是电子商务不可能做成那个样子，因为用户就是为了看商品的，不可能说图片没有了，那这个用户的体验就会下降很多。所以电子商务网站面临着很大的问题，用户一个页面打开，请求数是很多的，他要请求大量的图片和网页内容。这种情况下，我们就会很依赖CDN。我们在全国布很多点，用户拿数据的时候，直接从离他最近的CDN服务器上拿想要的数据，这样的话，用户的体验就很好，速度就会很快，所以CDN对我们很重要。
我们CDN的建设，今年已经是超过了两个T的带宽了，就是在峰值的时候，每秒出去两个T的数据。
51CTO：那你们现在整个的监控力度是什么样的，到秒级还是分钟级？
仲明：监控力度现在还是在分钟级的，一般是两分钟计算一次数据。所以说有可能最晚的情况是两分钟之前出现问题，我们现在才知道。
51CTO：这样的话，你们这个监控系统本身的数据和处理量也是很大的？
仲明：对。但是我们现在监控系统是分布式处理。所谓分布式处理就是说，有一部分计算逻辑是在本机的，就是被监控对象上的。比如说我们有一万台机器，那我们会向每台机器要数据。如果我把所有的数据拉过来再集中运算的话，会有两个问题：一个是我要拉的数据量太大，会占用很多带宽；第二，去集中运算的话，运算的成本太高，发现你会算不过来，好比我们两分钟拉一次数据的话，这么多数据有可能两分钟还没有算完，这就麻烦大了。
所以我们现在是分两阶段计算，一阶段就是在本地我去找你要数据的时候你计算一次，这个时候你会发现，你的数据量已经变的很少了，比如说两分钟你要分析，举个最简单的例子，分析日志，access log，两分钟的log有可能有几十个兆，或者是上百兆的原始日志。如果把100兆拉回去的话，这个就很麻烦了。所以我们在本地会做第一次分析，把100兆分析完，分析完之后，有可能形成了两K的文件。那么1-2K的数据上传到服务端，然后再去做二次运算。二次运算基本上是做什么样的运算呢，因为我们很多数据是按集群来看的，在本地这台机器上，只能运算本机的数据；如果我要看集群的QPS，就是整个集群的请求数，那我就会看，在一台机器上我的QPS是多少，再把整个集群的数据拿到一个集中的监控平台之后，它会做二次运算，运算的时候就能看出这个集群的指标是一个什么样的值。
所以说是两阶段来算的。
51CTO：这样，基本上两分钟拉过来的数据可以几秒处理完？
仲明：很快，在秒级就处理完了。实际上你会发现在本地运算是在毫秒级的。本地分析是很快的。当然，这个对本机会有一些性能消耗，但是这个基本上可以忽略不计的。因为两分钟才运行一次。本地做简单的日志分析是非常快的。
下一部分：故障响应机制
#p#
51CTO：监控这方面有很多细节，我想很多人都会感兴趣；但是今天时间有限，我想我们先进入下一个话题吧。您能大概介绍一下淘宝运维系统的故障响应机制么？
仲明：故障是这样的。我们会对故障进行定级，定级有P1-P4，四个等级的故障级别。P1是最严重的故障，P4是最轻微的故障，每个定级是根据每个产品，每个业务来定的。你会发现没有一个统一的标准，它不是说，整个所有的业务，什么样的是P1——不是这样的。我们会分开业务，根据业务的特质来确定，你应该根据什么样的指标判断，这个是不是一个P1。
举个最简单的例子，对于淘宝网来说，很多是看交易的，因为交易是一个很核心的指标，影响到用户，这是用户最核心的指标：一个电子商务网站，用户不能买东西了，你想想这是什么影响。所以，一个故障如果影响到用户在上面买东西了，我们会根据这个比例，你影响了多少用户买东西，来判断你是P1还是P2。这是一个核心指标。
P3、P4，这种我们认为是比较小的故障是怎么产生的呢，它是跟用户的体验相关的。比如说我们有一些用户投诉过来，用户的投诉量达到一定的数量的时候，我们就认为是一个P4故障了。比如说我们发生了几例相同问题的投诉，同一个点，同一时间，发现了好几例用户投诉过来，那我们认为这是一个很轻微的P4故障。
为什么定级呢，有几个方面，第一个就是你刚才问到的响应的问题，故障发生了我们怎么响应。不同的P级，响应级别是不一样的。像P4的故障，我们会走到技术支持，技术支持会响应它，他们会排查这个问题到底是什么样的，去联系投诉的用户，分析判断这个问题。这个不是很紧急。像P1的故障就很紧急，它的响应级别是不一样的。如果我们出现了P1的故障，会需要通报到副总裁。
51CTO：其实是上升到一个行政层面了。
仲明：升级是深度和广度两方面都有的，不仅在行政层面，更大范围的相关人员会知道。为什么非要上升这个东西呢？是因为让更多的人知道，并且会有更多的人来协助处理。对于P1的故障，我们要求一定要在最短的时间内处理掉。那P1的故障，如果问题停留在某个一线员工手上，他可能无法最快解决故障。有几种情况，一种是这个员工不知道公司有哪些资源可以帮助他处理这些问题，这是一个现实的状况，不是所有的员工清楚公司所有的资源。而且，即使他知道，也不知道该找谁，因为公司大了，上万人的公司，很难每个员工明确知道，什么事情找谁。
所以，我们要求有一个升级的机制。像P1级的故障，我们会升级到副总裁的，他需要知道我们的服务出现了什么重大问题，对用户的影响范围。像P2的故障到总监这一层的。P3的故障，到经理层，他们会为一线工程师处理故障提供合适的帮助。
51CTO：是不是可以理解为，故障升级之后，一线员工已经没有办法把控了，不能预估什么时候可以解决这个问题？
仲明：一线员工对系统最熟悉，他们有能力解决问题，但我们的故障信息要透明出来，方便其它部门和管理人员提供帮助，这些会提升故障处理速度。比如说我们发生一个故障，最开始根据我们的故障定级判断是一个P3级，那么一线的leader就会指挥一线的员工去处理。但是处理了一小段时间，比如说处理了20分钟，发现还不知道怎么搞定这个事情，那么这个时候，这个故障就会发生变化，它会从P3升级到P2故障。这样的话，他就必须通知到这条线上面的主管，比如说有可能是一个总监，他要跟总监说明，这个问题我们已经处理了一段时间，现在还不知道什么时候能处理完，现在已经升级为P2故障了，那这个总监就会参与进来，调度相关的资源，协助整个故障处理。尤其当你上升到P1故障的时候，就不仅仅是技术方面的问题了，包括我们客服的问题，因为你会有大量的投诉进来；包括公关的问题，我们怎么向用户解释这个问题，这个范围就比较大。
51CTO：一开始定级有一个算法吗，还是都是人工定？
仲明：定级方面，正如我刚才所说，不同的业务有不同的指标来衡量。但这个定级的过程是一个协商的过程，也不能说谁说我该给你多少，比如说你这个业务就是按PV来做了，PV降多少就是P1、P2，这样作为一个建议当然是可以的，不过我们做为互联网公司，像这种生产环境的故障，第一责任人是我们运维的人，但是实际上，你要知道，大家都是要去负这个责任的，不管是研发还是测试，他们相应的要去承担这样的责任。因为我们知道，一个故障的发生有很多的环节。有可能是你程序的bug；从测试的角度也会承担一定的责任，比如用例覆盖不全，漏掉了这个bug；从运维的角度也会承担责任，你虽然有这么一个bug，但是你在运维的过程当中，你是不是按照标准的流程执行了，这是第一个，第二个你是不是执行到位了，还有的时候，运维的人直接接触生产环境，你的操作是不是导致了一些这样的隐患在里面，都是有可能的。我们故障是共担的。
所以在我们的故障定级这个方面，一定会达成一致的，让大家心里都清楚。在我服务出现什么情况的时候，大家都心里很清楚，这是一个P1，而不是说有的人认为这是一个P1故障，有的人认为这就是一个小故障，P3。这样的话，会不利于我们调动资源。比如说我们出现了一个P1故障，我们会要求客服、运营、公关都要快速协同做事情，如果客服的人认为这是一个P4，我们运维的人认为是一个P1，公关的人认为是一个P3，这就麻烦啦。所以说这个东西一定是要概念一致的。
51CTO：能谈谈你们最近发生的一次故障么？
仲明：最近是有一个P2级的故障。这其实是一个很隐藏的故障：我们天猫的一个服务，把程序发上去以后，发现服务的性能下降了很多，用户响应的时间变长了。我们发现这个问题其实是在预发之后，因为一开始做预发的时候，没有用户流量进来，这个性能下降你感受不到的——测试请求是很少的。但是我们发了一批机器上去，用户流量进来了，发现性能下降了。
51CTO：在分批发之后的1个小时后发现了？
仲明：用户性能下降其实一发上去就知道了。我们的服务都是有监控的，它的RT变长了我们是知道的。所以一推上去我们就知道了。那么知道这个问题了，知道用户的访问时间变长了，但是并不知道是哪有问题了，到底哪里出了问题导致的。对于我们来说，我们不是去查问题的，我们处理故障都是用最可靠、最快速的方法去解决这个问题。
很简单，我不管你是什么问题，回滚程序。这是我们的处理方法。
那么我们就去回滚。但是，回滚完了以后，我们发现有一些小问题：回滚的版本有一些依赖的包出现了冲突。这是一个很复杂的问题。你就发现这个服务还是没法正常的提供，这个时候这个问题就开始升级了，就升级到我这里来了，我就知道这个问题了，我就会上线去参与他们的处理，为他们提供一些帮助。当时做了一个决定，很简单，我们把流量分流。因为当时我们还有正常的服务存在，那我们就把这些所有已经坏掉的这些服务上面的流量全部切走了。
51CTO：当时已经推到多少了？
仲明：大概已经到一半的样子了。我们就把所有的流量切到另外的一个集群，那个集群还是正常的，让它提供服务；这个集群留下来，大家来排查问题。
这个时候你会发现，故障已经结束了。因为对于用户已经没有影响了。这时候我们的系统其实还是在做恢复的事情，不过这个没关系，故障到这个时候就已经close掉了。
51CTO：所以，你们一般还是会优先考虑回滚。
仲明：对。如果我们在生产环境上做了变更、发布程序之类的，只要出现故障，第一策略就是回滚。因为这个时间是很宝贵的，我们总是要找最可靠的方法去把问题解决掉。
51CTO：不管哪个级别，都优先回滚？
仲明：对，变更引起的故障优先回滚。具体是什么问题，我们线下可以分析，因为我们的系统会保留所有的日志。你可以分析，还有我们历史的监控数据都是有的。出故障的时间点，这时候的请求是什么样，响应时间是什么样，当时的memory使用是什么样，IO状况是什么样，CPU运行是什么样，各种指标你可以看得到，你可以故障结束后过来分析的。
51CTO：像这种因为变更造成的问题，占的比例大概是多少？
仲明：这个肯定是比例最高的。
做运维的人都知道，变更是万恶之源。大部分问题都是因为变更引起的，我们知道引起故障有几方面，大概可以分为三方面：一方面是发起变更，程序的变化，不管是什么样的变化，包括网络结构的变化等等，这些都是我们发起的变化；另一方面是用户行为的变化，用户行为的变化也可能导致故障，比如说突然间一个大的流量进来，已经超过了你的服务的处理能力，这个时候你就会出现故障；第三方面就是我们本身谁都没动，但是有一台交换机，坏了，它跑的时间太长了，累了，休息一下，那这也有可能导致你的系统出故障。
那这三方面，我们内部在运维过程当中发起的变更，其实是导致故障最大的来源，差不多到70~80%这样。
51CTO：好的，那这次问题就到这里结束。十分感谢仲明的精彩回答！
