【51CTO专稿】前几天，51CTO系统频道推出专访新浪刘宇的系列文章中第二部分《专访刘宇：解密新浪CDN服务器监控机制》，今天专访的第三部分新鲜出炉，本文中，主要讲述了新浪CDN故障响应机制及其修复措施。对此感兴趣的朋友，可以看看下面的访谈实录。
SinaEdge平台运维主管 刘宇（@守住每一天）
【嘉宾简介】刘宇：SinaEdge平台运维主管，LinuxTone.org的创造人之一，在自动化运维方向有一定的研究，目前正在筹备《Puppet实战》一书，大家可以在微博上@守住每一天和他联系。
【采访实录】
51CTO：刘宇您好！首先请您谈谈您在公司主要负责的内容。
刘宇： 好的。公司配有全网络监控，7*24小时值班的体系，我主要负责负责CDN的监控。我们CDN有自己的响应机制，这个响应机制和其他各大公司是类似的。会有统一的小组或部门来负责。打个比方说，除了响应提示他就涉及到故障了，如果没有故障的话就不会有响应。
51CTO：对，响应就是针对故障。
刘宇：和其它公司一样，新浪针对不同的故障有着不同的级别对待，目前来说跟微博相关的级别***，非微博相关的排其次。但并不代表就不重要。在CDN不管是什么项目，只要在CDN加速的，就是重要的。在大故障与响应方面，会更多地按照公司的标准执行。
51CTO：这个只是按业务来分层级？就是这个业务出什么问题都是最重要的。
刘宇：那不一定，你说的这个就涉及到它的影响范围了。
像一级，重大故障，影响微博主功能的，比如：无法登陆微博、刷不了微博、登不进去的用户投诉、图片打不开等种种情况，而跟我这边最相关的可能就是图片打不开。还有另外一个业务比如说大面积的视频无法播放，微盘用户投诉，像你们现在去微盘，你们看到的比方说预览。看不到找我，下载不了找我，所以我们会根据影响重要的功能（重要的功能，通常就是说这种大面积的访问不了，然后下载不了的）。另外一个是主要的一些功能在于非这几大类的，如果出了前面的问题，涉及到的用户面是多少，其他的就是刚才我们说的那些不痛不痒的。
通常情况下会定位只有三级。然后分不同的权重比。再根据除了这三个之外，再根据现在影响用户的范围是多少，***用户不可达，还是百分之三十、百分之五十、百分之十……类似于这样的情况再排，接着用不同的东西再去说明。比方说百分百的用户是完全不行，部分用户不行，偶尔不行，然后乱七八糟的部分，比方说故障不可信或是不可重现，然后因为那只出现过一回啊，后来就好了，类似于这种，级别***的那种。比方说完全不可用那解释说，那就是说在我加速的这个应用里面全部都挂掉了。
其实对于CDN运营级别***的就是所有服务都不可用了，就是这是级别***的。在不可用的情况下，比方说微博所有的图片都打不开了，在我手上应用，所有图片打不开。当然我们刚才所说的，再往下排一级别的情况下，比方说网通这一个用户全都都打不开了。然后再网上升一层面，比方说再往下降广州市这一个用户打不很开了，再往下降，那就比方说广州市里面的百分之三十的用户打不开了，如果再往下降层面百分之十的用户偶尔打不开，就类似于这样子往下去排，那么公司有一定的这样的算法，就是要有个公式然后去算。当前这个情况然后影响多少，然后会定级为ABCDE，类似这样的故障级别，A***，然后E***，***根据这样算出来，从而定故障级别，发通告。举个例子：EF级别内部通知，然后刚开始所说的涉及到行政那块东西，AB级别了，涉及到行政当中，行政的话那块就是要固定的模板，例如故障时长，故障处理部署，故障处理人员，故障最终结果，然后这个故障的后续的改进，后续的跟进，记录号你做什么改进，然后跟进周期是什么时候，你要做A改动，什么时候做完，要特别注重这些细节。类似于AB级故障都是要这样去做，这个时候涉及到的人员跟进得有四五个了，公司会有专门的处理这种故障的小组来跟进处理，挖掘故障的根本原因，避免以后再出类似的故障。也算是一个故障的总结，个人认为这是非常有必要的，公司在这方面也一直很得很好。
51CTO：就你们组而言，优先是恢复业务为主的？
刘宇：我处理故障的思路是，首先确定故障，一定要先把故障定死了，清楚了是什么样的故障，再分配人员去查，然后预估这个故障大概会影响的范围和警示度，这个时候是需要跟所有人去说明白的，这个故障既然已经定下来了，你要先确定你有多少把握在多少时间之内能ok，在你没有任何把握它在某一定时间能ok的情况下，我就会通知几个人员专门去通知业务部门，做紧急预案，这个时候预案的话就是属于故障的另外一个流程，就是说这个故障已经在我手上就不可控了，然后我已经无法去控制这个故障了，我会让他们去走另外一个流程说，让不同的人负责通知不同的业务，走相关的故障切换流程，故障处理预案，走切换服务的处理。***时间先保障业务可用。从操作到生效服务恢复的时间几乎是一个TTL时间：60s，除响应时间外。
51CTO：什么？60s？
刘宇：对，我们的TTL设置是60s，也就是说这个故障只要我们操作，在60s之内就能解决，然后就是说先保证用户可用；当然这也不排除DNS缓存与个别生效延迟情况。
如果说出现了那种特别大面积的故障，我已经完全不可控了，通过我的这种几个级别的故障处理，我已经无法解决问题的时候，就需要快速上报，并通知四五个部门，以报将故障降低至***，各部分也会针对这个故障应用不同的策略。
有了这层通知，公司陆陆续续的各种各样的投诉，并且有大面积反馈到前面其他部门的时候，他们心里都知道有什么事情，有一个说辞。我们会在这个时间之内提出我们这边出现什么问题，大概多长时间会ok，如果有人问起，你就用怎么样的语言去说，然后可以快速进入下一步处理，因为通过这种情况的话我可以更加地快，一分钟之内就可以把这个部门全部都沟通过。然后比方说再涉及到的那种故障的那种流程的情况下，不可用了，说要切换服务，要保证服务质量的情况下，因为这才是优先的，这个时候会通知相关的部门去走以前商量好的，定制好的那个预案，按预案走就OK，那种情况会非常的快。
整个故障上报除了电话通知，还会通过固定的邮箱模板，在后台里面啪点一下send，将故障邮件发送至相关人员。也就是说我这个预案前期做得有多好，到你出现故障的时候，响应速度就有多快，这就所谓的应急措施，这就是要向公司特别强调你要去做预案的重要性，平常一年可能用不到，但是关键时候用了一次，那就减一半，我们只需要在后台你比方说我点一下这邮件就啪的一下全部都出去了，非常的快。你不需要琢磨这个邮件要发给谁，邮件内容要写什么这样累世的问题。只需要简单的改几个字，然后点个send发送，你就不用管了。所以说，我一般在这个里面充当的角色就是，前期的确认和后期的协调，然后因为故障用的解决了的那种请况下我必须要按照别人去配合，我不可能就说因为那个时候出现那种大故障的情况下，我的电话是不会断的，所以说更多的就协调，让你们去查，然后尽快的找到原因，然后再一方面就是就是开始着手做协调了。不管什么时候出现故障，我们小组的响应速度一般都很快。
51CTO：那这个预案系统是你在的时候做起来的？
刘宇：公司一直就有，每个人都有，只是说我需要去针对我现在这个负责的业务情况，可能会增加一些不同的方式或者说解决方案。
51CTO：嗯，那比如说，不管在哪个层级从技术上面处理可能思路差不多吧？先去确定故障，然后快速把这个故障修复。
刘宇：对，通常一般的情况下会***个先想变更，这个思路我觉得跟别的公司没有任何区别，我觉得是没有任何区别，因为真的，十有八九就变更，先想想有没有变更，没有变更再想下一步。通常就是***反应，有没有变更，脑子里先过一遍这两这几天的东西，你有没有变更，如果没有，ok，再往下走。
51CTO：它也是有几套模板的，除了变更之外，还有什么快速定位故障的？
刘宇：程序。我们有编写了几个程序，如果出现这方面问题的时，我敲几个命令，就能够快速先排查几个问题。可能在哪一个环节发生了问题我们就开始写程序，因为CDN盘子比较大，涉及到的业务线会比较多，所以先从核心层面去排查，然后核心层面没什么问题然后再往接着往下，这份故障的话，会根据业务来，比方说你这个大文件的还是小文件的，还是直播的？会根据这几个业务来分。
51CTO：每个业务出现的故障可能是不太一样。
刘宇：除了大的故障之外，就没有什么相同的。
51CTO：那么采取的措施是什么样的？
刘宇：措施是类似的，但是可能在定位的那块不一样，所以说我们对于不同的应用，有不同的程序去探测，我们直接在一个后台里面。最开始形成的时候采用的是程序，每个人电脑上装一个，根据不同的业务进行检测业务的可用性。如果对业务有影响的情况下，先保证服务，这也是响应机制。快速影响每一个投诉与反馈，并快速进行定位判断。
51CTO：要不讲讲最近遇到的故障？
刘宇： 可以聊聊最近遇到的一个劫持事件。很多公司都有劫持。通常最多的DNS劫持，不是跳转劫持，我们把它定义为成了TCP层面的劫持。用户去看的时候，通过各种排查方式，出现问题，用户说我访问同一个页面里面的不同的视频，然后A同事看不了，B同事能看，然后同一家公司里面，你能看，我不能看。但是后来，就是说因为用户就觉得，我同一家公司的，为什么我能看，他不能看，为什么今天我这部分视频能看，明天我这部分视频不能看。其实这个问题相当诡异的。可能很多人遇到问题的时候，要不然就是全公司的都不能看，要不然固定的时期不能看 。我们遇到的问题是说，同一家公司的，然后今天是这个不能看，明天是那个不能看，然后有些时候你能看，有些时候你不能看。然后当时我们遇到这个问题的时候，觉得是挺诡异的。不过后来我们去分析发现用户，它出口那个IP是变的，这是一个规律，用户他有两个出口，走A出口的时候正常，走B出口的时候不正常，这个是我们在客户端去模拟用户请求，然后在服务器端抓包发现的。
51CTO：他们公司有两个外网出口？
刘宇：这个也能理解，很多公司都有。这是一个问题。第二个我们发现用户出来的时候，它是固定的一个域名是不正常的。因为在我们的一个视频里面会有不同的域名来调用，其中发现只是某一个域名是不正常的，另外一个域名是正常的，由此可以判断出为什么他们会出现这部分能看，这部分不能看，落在这个域名下面的是不能看的，后来我们就集中去排查，发现最开始以为是劫持，很简单，如果你DNS被劫持了，然后我们发现，你去dig、ping或者去定缓存，然后就是说各种尝试你发现没问题，他的解析是正常的。
dns层面是完全没有任何问题的，因为dns在windows下是有本地的缓存的，你要把他清掉的情况下，像是去跟全部DNS去查询的，所以说这种情况下，如果你要是清掉还不正常，那说明他没有劫持，没有任何问题。后来我们在用户那一层面模拟用户的请求，因为我们有使用302跳转技术，用户跳转之后302收到的请求是正常的，但下一次去访问时异常了，通过这次判断，应该是用户走这个出口，公司有限制。这种做法在小运营商里面是常见的，但通常都是采用DNS劫持，叫内部Cache，这样做的好处是可以节省大部分的带宽，因为视频的钱成本是很高的。为此我们判断出来，用户只要走这个出口，公司是采用的白名单政策，只要是在非白名单之内的都会走内部的Cache。然后我当时和他们的工程师去协调，对方反馈并没有去做这种cache。但是我们从模拟出用户的请求各方面来讲，已经确认了绝对是内部Cache导致。后来让他再去沟通，通过多次沟通发现是他们公司集团，某一个出口里面是有cache的，然后他去走了个申请开放了一下我们这个运营的cache限制，就好了。
51CTO：挺有意思，看起来比较随机的问题。这个后来是算哪个层的问题？
刘宇：后来定义为用户自己的问题。
51CTO：用户层自己的问题，当时在你们这儿判断是算紧急度是怎么样的？
刘宇：嗯……优先级挺高的。
51CTO：它不是只有一个公司出问题？
刘宇：没错，但是那个公司是属于付费公司，我们公司跟他们公司是有一种合作的关系。有着大量的推广与合作，在微博儿里面是有推广的，然后如果微博上面看不了的话，其实影响面还是挺大的，但是恰恰只影响他们公司自己人看不了。我是领导我花了钱了结果发现我看不了，所以说在我们这边排优先级其实算挺高的，因为涉及到这里面的***一点，算是一场商务上的。
51CTO：这个层级这个也算一个评级标准？
刘宇：这个也算。公司里面对于这一方面其实也挺多的，因为商务合作，有可能涉及到是微博的，比如战略发展方向什么的。
好了，今天的采访就到这里了，感谢刘宇的分享！此次专访到此也画上了圆满的句号。如果没来得及看前两篇专访的朋友，在此回顾下。专访***部分：《专访刘宇：探秘新浪CDN系统的代码发布机制》、专访第二部分：《专访刘宇：解密新浪CDN服务器监控机制》。再次感谢您的持续关注，如有问题，欢迎在评论栏中留言讨论。
