天猫双11数据中心断网88秒修复所引发的思考

一年一度的天猫双11又在不断刷新数据记录，0点过后0分26秒扛住58.3万笔/秒的订单创建新峰值，30分钟实时成交额就突破3723亿元，截止23点实施物流订单已达22.5亿单，约等于2010年全年中国快递量的总和。

今天，阿里巴巴CTO程立首次向外界披露了一条秘密突袭行动的视频，证明了上述数字是多么来之不易。视频显示，6天前，阿里巴巴内部曾先后发起了断网、断电的突袭，而这些突如其来的意外一旦真实发生，都会对双11造成毁灭性的打击。

发现断网后，阿里工程师快速发现定位到故障，并完成了主备切换，仅仅88秒后，一切恢复正常。断电则更为粗暴，数据中心工程师直接拉下电闸，随后，备用蓄电池第一时间为服务器供电，几秒种后柴油发动机自动启动，所有设备恢复正常。据悉，此次突袭没有任何提前预警或通知，而最终所有业务没有受到影响，用户也毫无察觉。

阿里的这次突袭行动，实际上勾起了很多运维攻城狮们的痛苦回忆......所谓外行看热闹，行家看门道。在整个事件中最难的一个环节，莫过于第一个环节，就是应急小组收到信息。故障信息收到时间的长短，往往直接决定了整个故障的定性。 

这句话并不是什么危言耸听，只有做过运维工作的小伙伴，才能理解这其中的痛。小月月这一个半月没有闲着，一直在出差。金融、医疗、制造业、游戏公司等企业的信息中心（信息科）的领导们见了得有几十个。虽然是不同行业、不同区域，但是用户与我交流的过程中有四个问题，达到了惊人的一致。

问题一：故障出现后，无法快速判断故障范围，且消耗的时间过长

问题二：故障范围确定后，又无法准确定位故障点

问题三：故障出现后，无法清晰划分责任，网络运维和数据运维相互推责

问题四：很多故障处理完毕，却没有数据支撑证明原因在哪

运维人员的压力是很大的，由于平时故障判断的周期和处理的周期都很长，导致领导问责时，根本没有解释的机会，而当有解释机会的时候，又没有办法提供有力的数据支撑，去证明故障原因，所以经常出现不同部门之间互相推责的现象。

说的简单一些，所有的故障几乎都是后知后觉，故障发生后又没有办法提供数据依据。做了好事不被认可，出了坏事一定是跟自己有关，及时没有关系有没有办法立即证明，莫名其妙的背了很多次锅，这才是所有运维人员真正的苦。

昨晚五刷《寒战》，看到这突然间莫名的菊花一紧，替阿杜捏了把汗，这不就是运维人员的真实写照么。

为什么会有此类的事情发生呢？这里面就要提到传统的网络故障监测以及处理手段存在着很多短板。

传统的故障检测方式，一般包括标准协议拨测和模拟客户协议拨测，常见的包括ICMP Ping、TCP Ping、UDP Ping、HTTP GET、DNS拨测和专用私有协议拨测，有众多开源工具，比如Nagios和Zabbix（https://www.zhihu.com/question/19973178），也包括一些主机参数的提取。

但是其缺点也很明显，拨测协议与用户实际使用的数据，并不走同样的路径，比如ICMP协议，路由器就是通过CPU处理，而不是经过数据平面的转发，和用户使用有较大认知偏差，经常出现拨测很好，但是用户投诉。另外就是拨测频率过低无法准确，频率过高就容易对网络形成额外的压力，很多私有协议无法模拟，所以不能拨测。

 传统的主动测量手段

作为一名运维工程师，对于投诉或是故障也是有喜爱程度的。

最喜爱的故障：业务中断型，相对来说这种故障的告警机制以及定位方式更为简单，现在基本上可以做到秒级的监控。

最讨厌的故障：业务卡顿型，这种故障最不好判断，需要从终端、网络、服务器等多方面排查，会消耗几个小时甚至几天都无法发现问题。

最上火的故障：单个业务不连续卡顿型，这种故障最烦人，除了不好监控，不好处理以外，还非常容易造成网络、数据等多个不同角色的运维人员之间产生争执。

在一次次的小故障处理不及时升级为大投诉后，即使信息化建设、等保建设、视频会议系统等项目做的再有意义，也会因为这些繁琐的故障问题处理不得当，而大打折扣。随着各行业的信息化高速发展，摆在运维团队面前的最大的难题不是产品部署、产品使用，而是常常被人们最不重视的小投诉、小故障，俗话说“千里之堤，溃于蚁穴”，只有老运维才会时刻提醒自己一定要重视、重视、再重视。

实际，这种问题并不是不能解决，思路也很明确。

+

 要细化业务监控的颗粒度

上面已经多次提到过，拨测是无法实现真实业务级别的监控的，在面对越来越多的软件应用、服务器、用户终端时，实现对流量的七层应用级识别是十分重要的基础。

简单的来说，只监控道路是不起作用的，要对道路上的每一辆车都清晰的识别，并加以监控。

实现流量应用级的监控

+

 对每一个应用进行时延记录

只有实现对每一个应用所产生的所有会话进行时延记录，才可以快速判断“某个用户的某个特定应用卡顿”这类故障的范围，缩短故障判断的时间，并且清晰划定责任界面。

基于应用的网络性能监控模型

如果想更加精准的实现故障的监控，需要在互联网出口、数据中心、汇聚交换机等位置部署测量探针。

+

 会话日志一定要全量留存

 会话日志的1:1 记录，是为了在故障溯源时，让故障汇报有理可依。它需要完整记录每一条会话信息的协议类型、接口、访问时间、连接时间、源地址、目的地址、 NAT 地址、用户账号、域名信息、上下行流量、所属运营商、地理位置等信息。这就为故障回溯提供了最真实有效的依据，让一切只要发生过的问题都有迹可寻。（注意一定是会话日志1:1留存，可不是其它什么随便日志留存，千万不能被忽悠）

 会话日志

+

 数据展示一定要方便

用户是使用者，不是研发者，客户需要的是简单易用的检测工具，而不是什么高深莫测，所谓的高端产品。买一台设备还要招两个HCIE、CCIE高工去使用那就不值得了。所以，一定要简单，易用最好能直接出电子报告或是告警才最好。

都说到这了，有人开始疑问了，哪里有这种设备呢？既能在100G以内大场景下做到流量的精细化识别，还能实现应用级流量监控能力，更细致的监控服务质量，并且还能自动推送网络质量报告，让用户轻松掌握网络状态，从此告别故障的后知后觉，告别故障的无据可依。

想知道答案的，请点击文章下面的二维码，小月月将为您详细介绍，如何在减轻运维工作量，提升工作质量，避免同事投诉，拒绝领导问责的方法。让您从此升职加薪，赢取白富美，出任CEO，从此走上人生巅峰。

更多精彩：