在苦难中的成长--从某宝某程故障看互联网业务系统可用性

＂鹅厂网事＂由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。 网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！

背景回顾

2013年7月22日，由于道路施工致光缆被挖断，腾讯微信出现长时间服务异常。2015年5月27日，由于市政施工，杭州市某地光缆被挖断，进而导致某宝一个主要机房受影响，随后全国部分用户约2小时无法进行支付。2015年5月28日，中国最大的在线旅游某程网站遭到不明攻击，导致网站和客户端无法登录。每次故障都会引发大家对互联网业务系统可用性的质疑，为何所说的业务可用性5个9、两地三中心、异地多活等等听起来挺高大上的东东都敌不过“一铲子”呢？

术语解释

可用性是指系统在执行任务的任意时刻都能正常工作的概率。可用性越高，表明系统的稳定性越好。

通常大家都经常会看到可用性4个9或者5个9这样的指标。

4个9：(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。

5个9：(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

可用性的计算

举个例子：如果系统1是依赖于3个串接系统（可用率99%）的，任何一个串接系统出现故障都会导致系统不可用，那么系统1的整体可用率：99%*99%*99%=97.03%（见图一）。

如果系统2是三个并行系统（可用率99%）构成的，任何一个并行系统可用业务及可用，那么系统2的整体可用率：1-（1%*1%*1%）=99.9999%（见图二）。

从这个分析来看，提高系统可用性一方面可以提升每单个系统的可用性，另一方面可以通过冗余并行的设计。

如果系统设计时能有多条通路，即便一条出现问题业务可用性依然可以得到保证，同样是99%的系统实际是可以达到6个9的可用性。当然这个是比较理论化的，实际工作中采用并行意味这增大投入，如果本身串行的步骤比较多，每级都再采用并行的方法，最终的成本可能是业务负担不起的。再举个实际点儿的例子：

大家为了确保线路的可用，通常会做1:1的冗余，这样在一条线路中断的时候，另外一条线路可以做到完全的承载，考虑到流量突发以及扩容周期问题，通常40%就要启动扩容了，换句话说2*10G的数据线路在跑到8G的时候就需要扩容。10G线路的底层如果是承载在DWDM系统的话，通常DWDM会进行波道保护，每条10G的波道会对应有一条保护波道，也就是说2条10G的数据线路实际上占用了4条波道，支撑了8个G的流量，平均到波道的话，每个10G的波道承载2G流量，相当于有效利用率仅有20%，浪费高达80%。

为了提高线路的可用性付出的代价不可谓不大，但如果承载这些波道的底层物理光纤没有进行物理分离，在故障时非常容易出现全部中断的情况，上层的所有努力都没有意义。

注:腾讯通过SDN技术在广域网线路上已经突破40%的限制，从另外一个层面解决了部分问题，这里对此新技术不做累述，有兴趣的可查阅之前文章《数据中心间网络SDN解决思路探讨》

业务运营可用性

我们把一个业务系统可用性分为三层来看，分析每层的特点，有助于我们选择最适合的组合达到我们的可用性指标。

基础资源

依赖运营商，承诺未必可信，限制较多

网络架构

网络团队可控，但通常会有成本压力

业务系统

业务可控，但业务不同发展阶段对可用性投入不同1基础资源

对于某宝由于光纤被挖断导致业务不可用报以理解之同情，长期以来业务的超高速发展，各互联网公司为了追求容量、性能的提升不断从运营商租用大量的机房、光纤等资源，但对这些资源实际控制力度并不强，更多只是依赖于运营商自身的管理能力，没有端到端整个链条去控制业务风险，出现类似一铲子断网的事情这不是第一次也不会是最后一次。关键是在出现类似问题后要痛并思痛，想办法去解决或者规避类似故障。

想从根本上去解决最好的办法当然是自建了，机房自建、光纤自建、能控制底层的资源互联网公司才可能从根本上去控制自己的服务质量。所以大家会看到海外的互联网公司google就在自建的道路上一路狂奔，自建机房自不必说，光纤，入股建设海底光缆，建立谷歌光纤高速接入。google的解决方案当然是比较彻底的，但实际推进速度就未必让人满意，毕竟这种解决方案涉及了太多相关的利益，即便在美国这个相对比较开放的电信环境中依然存在较大挑战。在国内BAT也都走向了自建机房的道路，例如腾讯的天津备份数据中心、设计服务器规模就达到20W。但是光纤等资源是运营商垄断的，没有一家互联网公司有自己的长途骨干光纤，都是从运营商租用，运营商又是属地化管理，经常一条长途线路开通就需要几个月的时间，后期一旦出现故障排查处理都比较复杂。不仅仅是长途光纤，本地光纤也一样是运营商垄断的，2013年722微信事件其实就是本地光纤被挖断导致的。从当前国内环境来看，互联网企业想根本解决底层资源问题是不现实的，依然要走与运营商合作之路。

2网络架构

既然底层资源不可控，那就想办法在更上层来进行冗余性的设计来规避底层风险，就像IP传输不可靠的时候我们还可以依赖TCP来提供相对可靠的网络传输一样。网络层及业务层都需要有高可用的架构设计。腾讯在这两年间内部的的MAN、DCI、TIX等基础网络架构平台都进行了不小的架构改造。MAN的直通车设计降低了超级核心节点的流量压力，极大的提升了城域网的冗余能力；DCI平台在多专线的基础上进一步使用自研BOBCAT设备搭建基于互联网的V**传输平台；TIX平台实现了多地运营商BGP出口，并实现了全网调度，例如当运营商网内出现故障，采用该平台的腾讯云外网流量可自动切换至异地出口规避对用户的影响。

其实在某程倒掉的第二天5月29日腾讯也遇到了一个不小的麻烦，天津到上海的数百G线路全部中断达90分钟，这些线路在向运营商申请的时候也是要求进行了不同路由，但是说断它们就真的一起断了，无语了吧，但是它就这么发生了，不过由于网络架构足够的强壮，带宽容量管理得当，在中断期间流量绕行深圳进行中转，虽然延迟增大了20~30ms，但业务仅仅轻微波动了一下，广大的QQ、微信用户几乎未感知到此次的故障。

从2013年7.22微信故障全国用户抱怨无限，到2015年5.29沪津数百G线路中断业务无影响，腾讯网络可用性不断在提升。据不完全统计截止到2015年6月份

腾讯内网链路中断200+次，98%业务无感知，2%有网络质量影响，未出现完全中断情况，架构的优化对业务可用性提升作用明显。

3业务系统

同样业务层面的高可用设计也是极其重要的，正如某宝所说的异地多活，这个是几乎所有互联网公司都希望做到的，但由于业务的架构不同，实现起来的难度也不相同。类似搜索或者门户网站类做异地分布通过DNS进行全局调度，实现业务的高可用相对比较容易。但是所有涉及到数据需要实时同步的业务，实现高可用的难度可就大多了，此次某宝故障时未能快速切换至其他异地中心可能就是担心数据不一致性导致的。社交类的业务如QQ、微信当前都已经实现多地多中心的冗余，在倒了一个机房业务也依然能正常工作，甚至通过业务的柔性策略，在更极端的情况下依然能确保核心功能的可用。

小结

业务可用性是由上述三层的可用性结合而成的，通过不同的串并组合付出不同的成本得到不同的可用性。但是这些还只能算是我们对可用性的规划设计，最终的可用性还要依赖运营能力，任何的设计最终都是要通过运营来落地的，再好的设计如果运营能力没有跟上，最终业务的可用性也达不到预期。

人、工具系统和流程是运营的几大纬度，前文讲了对底层资源的控制力度由于一些限制所以没办法根本解决，但并不意味着不能做些事情，不仅投入巨资进行架构的升级优化，同时腾讯也在不断提升自身的运营能力。

建立及优化了新建设转运营、演习、运营商管理等流程，完善了备件管理系统、CMDB信息自动化审核等。从之前申请一条线路只需要运营商给个线路编号和保障电话，到现在线路需要提供各跳接点的信息；从之前只管向运营商提需求，到现在通过各种信息去核查运营商提供的线路是否真的能达到要求；从在故障时才发现信息不准确到现在每一条专线在进入运营的时候都会进行自动化信息审核与人工演习。腾讯磐石项目对数千条的线路进行信息的校准，每年数十次的演习也提前发现了网络中的隐患，通过架构的优化＋运营能力的提升，腾讯在网络规模不断扩大的情况下整体网络稳定性不断在提升。

每一次的故障都是我们自我反省的机会，都是让我们能做得更好的动力，在苦难中成长，与业界所有运营同仁共勉！

正如pony所说的互联网终究也会成为传统行业，我坚信互联网最终也会进入比拼运营能力的时代，运营的春天将会到来，运营能力将会成为互联网公司核心竞争力之一！

后记

NOC（网络运营中心）作为腾讯公司基础架构侧7*24的专业运营服务入口，在ITIL体系和工具系统的支撑下对基础架构的运营状态实时看护、故障综合处理、流量智能调度。确保基础架构侧的高可靠性和业务高可用性，同时具备较完善的运营体系，为亿万用户保驾护航！欢迎业界运营同仁一同加入探讨。

注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利； 注2：本文图片部分来至互联网，如涉及相关版权问题，请联系judithliu@tencent.com。