【www.shanpow.com--网络散文】
网络架构师一:网管，网工，Or 网络架构师？你觉得自己是哪一个？
作者简介：
庞俊英
大河云联创始人/CEO阿里巴巴集团 原首席网络架构师从事网络规划、运维、研发工作近二十年。 曾在Cisco、中国电信等公司任职，是中国获得CCIE认证的最早的女工程师，对网络规划、运维和研发有非常丰富的经验。
曾任阿里巴巴集团首席网络架构师，也是集团技术保障部的架构委员会主席，她是阿里云网络基础架构的奠基人，也曾主导了中国最大规模的数据中心SDN网络的实践。
她曾受邀登上全球开放网络峰会（ONS）主会场进行主题演讲。
前文
我的身份是一名网工，我做了十几年的网络工程师。入行就是网络工程师，创业仍然是在做网络的事情。
为什么在前几年，很少有人讲网络运维这件事？因为在软件工程师的眼里，网络是一条线，在运营商眼里网络是一朵云，有幸的是我在思科待了小十年，在阿里待了6年，运营商也待过，每个角色都做过，现在自己创业。
所以我把自己所理解的网络的昨天、今天、明天，以及为什么网络突然变重要了，网络运维为什么被大家提及并变得很重要做一个梳理，当然这也是我个人的理解
在昨天：一切都很简单
图片里我是举了几个关键时间节点来梳理近十年网络架构的变迁。在2007年的时候，中国互联网起来了，这是一张2007年阿里巴巴B2B的网络拓扑图。它是一张过去真实的拓扑图。
那时候，网络工程师就是个网管
大家可以看到那个时候网络非常非常简单，当时网络圈对于互联网公司的网络工程师的理解就是一个网管。我在2009年加入阿里巴巴，之前在思科工作，思科同事说：“你最多待三个月，那个公司什么都没有，你就是一个网管。”
其实回过头来看，这也不是件很奇怪的事情，在2007年的时候，互联网公司的网络很简单，网络工程师就是一个网管的能力要求。基本技能是懂得生成树、懂得静态路由，懂得 OSPF 就不错了，高级点技能是写个脚本、刷个 ACL。
网络架构和运维配置、设备选型都是由设备厂家工程师做的，比如这张拓扑就是典型思科的三层网络架构。在2007年，互联网公司的网络现状是很挫。
但是那时候运营商很牛逼，运营商的网络核心网络架构分为超级核心、普通核心，有大区，有省网，省网下面有本地网，有接入网。
那时候我们用的设备是图片里这样的集群，当时我第一次到互联网公司看到一个分布式计算，看到Hadoop的时候我就很困惑，这个技术在思科2004、2005年我们搞的的集群式路由器 CRS 不就是这样吗？
那时候，运营商的网络工程师真的很厉害
用在中国电信核心区的集群路由器的样子就是这张照片。所以2007年作为一名运营商的网络工程师感觉很厉害，技术要求也不一样，工程师不但必须要懂ISIS、BGP、MPLS，要非常非常熟练 QOS、HQOS、Traffic Engineering 等等，2007年网络界工程师的高级技能懂点芯片、Serdes 等等这些很硬的知识。
那个时代作为一名运营商的工程师会经常向设备厂商提出来你给我做什么什么，我们的流量模型是什么什么样子，我们网络需要要做什么什么，这是2007年的时候。
那时候运营商的网络工程师会认为 NOC 和 TAC 工程师是很厉害的技术工种，而互联网公司的网络工程师只是一名网管。在思科工作时，我们很尊重电信集团 NOC 的人，他们真的很厉害，被称为网络工程师。
此时，网络运维不再叫做网管了
在2012年情况发生了哪些变化，在2012年，互联网公司的数据中心网络演进成这样，这时候互联网公司的网络运维不再被称为网管而是被称为“互联网公司网络架构师、网络工程师”， 请注意称呼的改变一定是有外因的。
基本技能也潜移默化地发生改变， 精通 BGP，要懂，深谙硬件行业趋势，需要懂一些系统知识甚至会要求有能力写些代码。
大家看到5年发生了一个巨变，这个巨变是什么带来的呢？是服务器的增长带来的。服务器在哪儿呢？服务器在互联网公司，所以互联网公司的网络发生了变化，那它也会带来一个工种的变化，即网管变网工。
多张网的时代
再看一下2014年运营商网络的情况，还是一个 NOC。工程师有什么技能变化呢？我列不出来技能的变化。“我有一张网、两张网、三张网”，“我要运维的网元越来越多”，“我们的人越来越少”，个人技能变化不大。理由是什么呢？
图片来源于互联网，我们看一下中国两大T的骨干网，中国电信有一张 ChinaNet，有一张 CN2， 还有国家级的 DCI，可是这三张网为什么不能在一起呢？反正就是“我有一张网、两张网、三张网”，网多力量大。
中国电信是多张网来适应多种业务要求，中国移动和中国联通是不是好一点？CU 也差不多，有169、A网和B网。
之前我看到联通A网在做 SDN 的事情，中国电信也早几个月发布了2025网络重构，说明大家都是意识到，反正不发展就等死。无论主动还是被动的，变化都是好事。
从大概 2007年—2014年，我觉得运营商真的没变化，网络运维自己就是一个 NOC，没有什么核心的变化，因为没有什么外因推动运营商网络必须发生改变。
互联网公司服务器变了，网络架构必须变，任何厂家都不能告诉我们网络长成什么样，因为他不知道我们有多少服务器、多少应用。OEM 设备厂家的核心技术能力是设备端口密度、散热、软件 Feature。
网路架构要如何匹配成本、规模、应用性能发展到需要“用户”自己设计，于是这5年来，互联网公司的网络工程师从网管变成了一名网工。
在今天：我们背负巨大压力
远远超过我们的网络架构
再看看现在，当网络变成下图这样时，我们还能是一名网管吗，还能是一名网工吗？当然不能！
这是 Facebook 和 Google 的网络拓扑，在这种情况下我们如何做网络运维？你能一根根线去数有多少条链路吗？线上产生丢包、线上发现流量不对称，你怎么去查？业务告警、应用变慢了，如何定位问题？
网工写了那么多故障预案，但发生故障时应该用哪个预案？可能对我们来说， Facebook 和 Google 的规模和技术超前我们八年不止。
今天的 BAT 网络架构虽然没有这么复杂也不会太简单，如果今天 BAT 在网络规模、运维遇到问题，可能再过两、三年其他的公司也会面临这样的问题。
既然我们今天已经知道了未来两年内要遇到的网络运维的问题，那为什么我们今天不去改变呢。
所以，在今天这个时间点，我们可以享受技术的红利，但是我们是不是也要为我们自己的工种，网络工程师的工种做一点事情。
不要让老板知道你是谁
最苦逼的网络运维团队的状况是这样的，如果不出故障，那么今年绩效中等或稍微好一点，出了事老板经常就知道了一个网络运维工程师的存在，说明这名网工今年总出故障；老板不知道你就是安全的。为了让老板认识，我们付出的代价很高。
当然也有好的例子，比如大概在几年前，淘宝运维团队每年的1月1号的凌晨老板会发一封邮件，表扬今年的变更王， 变更王一般就是新进来的小伙子，过一年变成老头，因为他一年需要变更200多次，每次都是凌晨。
我负责一线运维时，我的手机短信半夜不停地响，甚至养成手机不响不习惯，感觉肯定出大事了，漏短信了或者是报警没发出来。这就是我们这些运维工程师的生活，我是觉得变更这件事情在互联网公司是尤其严重。
可能运营商好一点，运营商 NOC 变更不是非常频繁，还有花钱请一些驻厂工程师、厂家工程师做些一线运维的工作。可是互联网公司的运维工程师没有办法，要为生产负责。
如果我们今天不去改变运维的话，那我们的血、泪、白头发全是为机器做服务了。
网工是一个很厉害的专业工种，上次我开过一个玩笑，如果让某云在北京一个Region 整网脱网，要么地震了，要么是网络工程师作变更了。只可能这两件事儿才能让一个 Region 能够脱网。一条命令可以让一个 Region 脱网。
大家可以看到上图，如果找一些论据来证明过去的悲惨经历，大家可以看到的是，在所有的故障原因里面，敲错命令行是排第二的，硬件的问题是排第一的。
这意味着网络运维是一个非常高危的工种，那怎么解决网络运维非常高危的问题呢，一定要把命令行消灭掉。不然的话一年200多天的变更，还是半夜去操作，你怎么变更都会有故障。
在明天：我们是一名网络架构师
我希望未来的网络工程师可以说我是一名网络架构师，我们很骄傲地说我是一名架构师，不是网管也不是网工。
一个网络架构师具备什么样的能力？
首先是成本的问题，网络架构师必须考虑整体成本而不是局部成本。前段时间我在微信上跟人讨论万兆光和电问题，表现为 AOC 这个产业的存在，我认为万兆光电之争没有绝对的对和错。
与使用公司的体量和业务架构有关、跟产业时间点有关。我们不能说 Google 现在全部是光，国内的万兆网络就要选择光。
从网工的角度来说，一根 AOC 的线不贵；一个服务器的工程师说，一个网卡光口比电口便宜50块人民币，但是作为一名架构师同时需要考虑布线的成本、库存的成本、供应链的成本是什么，都要综合考量。
作为一个架构师要去想整体成本是什么，而不是只关心自己本专业覆盖的成本。所以我列了整体成本和局部最优，架构师是考虑整体成本的最优，只有一个网管和网工才会考虑局部最优。
第二个是说用新技术颠覆成本还是躺在技术红利上的Cost Down。前面教主说了，我们软件写不过美国人，因为编译器是他们写的，编程语言是他们发明的，也就是说某些技术红利 Google 和 Facebook 先享受了，我们该如何看待和享受技术红利？
我认为技术团队应该不是让采购不停地讨价还价，让采购压榨市场供应链，让我们国家的每个人都很苦逼。我觉得做工程师要有情怀，要做一些颠覆性质的技术创新，以技术颠覆成本，而不是躺在那儿享受技术的伪红利，这是我对网络架构师的看法。
一种关于运维复杂度的情怀
还有一种情怀，关于运维复杂度和情怀，工程师很容易陷入技能情怀里，将简单的事情做复杂。我自己每年也会反思，做架构师是很纠结的事，有些技术选择是猜的而不是有什么理论模型。在这里面的选择要放弃一些情怀，不要将简单的事做复杂。
我还发现一个特点，所有的互联网公司都有一个神一样的运维工程师存在，所有的拓扑都在他脑子里，所有的IP地址都在他的脑子里。我觉得在未来的网络里不要神一样的运维工程师的存在，让机器去做重复和大规模的工作。
我觉得今天是应用在驱动改变，那作为一名网络架构师，应该考虑业务驱动改变。应用驱动业务，业务驱动基础设施。
举个例子，在过去是厂家有什么、芯片有什么，我们就用什么。当我们面临发生Silence drop的时候，就会有芯片的厂家说他们的芯片有一个功能，可以告诉你什么时候丢包。通常再需要写个Tools来可视化“哪里丢包了”。
可是我们换位思考芯片发生 Silence Drop 是什么触发的？如果是芯片集成度的问题是不是下一代就能解决它，再反推在现在的时间点如何做技术取舍后的workaround，如今的运维团队里面有非常多的工具，这些工具使用频率低也没有人维护，作为网络架构师，需要从根本上思考如何解决本质问题。
还有一个期望，整个网络设备的上线、运维、配制管理是否可以像服务器一样？其实不是的，这不是语言的问题，是系统开放性的问题。
当然这也是一个期望，可能需要推动用户驱动厂家开放，而不是等厂家主动说它如何开放，如果网络的上线、变更等等跟服务器一致，将会是多节省成本。
最后，现在大家都在讲SDN，但是我很担心一件事情没有想清楚，会不会有一天网络运维团队运维的不是几百台路由器而是万把台服务器；一个网络运维团队运维的是一大堆服务器，这是一直比较困扰我的东西。我是坚定地站在 SDN、NFV 阵营的，但是 NFV 的运维形态如何？
再引用下 Google 的一句话“要么发展，要么死”，也引申下今天的主题，我们要重新定义运维，而不是运维向运营转型。
我不太相信一个运维团队说“我从成本中心变成效益中心、运营中心。”
我认为运维是为运营服务的，所有运维得想怎样解放自己。
看Kitty (庞俊英)的文章，总能引发诸多思考，下面这篇文章，是之前高效运维社区发表的一篇，阅读人数突破一万，敬请欣赏：
《What？网络运维中，成熟的公司必须杜绝CTO？！》
来GOPS2016 · 北京站可能有机会见到Kitty
在12月16-17日两天，以“DevOps 2.0：重塑运维价值”为主题的 GOPS2016 · 北京站将在国际会议中心举办，汇集国内一大批运维界牛人，包括 Google、baidu、阿里、腾讯、京东等讲师齐登台，带来50多场时间更加持久的培训式演讲。
而且有机会见到本文的作者--庞俊英(Kitty)，你可以当面膜拜大神！oRZ
今日起，购买普通票或团体票的小伙伴将可在GOPS大会现场免费领取《凤凰项目 - 一个IT运维的传奇故事》特别版！
本次大会有多精彩？视频给你答案
想了解更多，请点击"阅读原文"进入GOPS2016 · 北京站官网
网络架构师二:网络架构师：各大型网站架构分析收集 及大型高负载网站架构的感想
网络架构师：各大型网站架构分析收集 及大型高负载网站架构的感想
1. PlentyOfFish 网站架构学习
http://www.dbanotes.net/arch/plentyoffish_arch.html采取Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 “OnlineDating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况Markus Frind 每天只用两个小时打理网站–可操作性很强嘛。2. 从LiveJournal后台发展看大型网站系统架构以及性能优化方法http://www.example.net.cn/archives/2006/03/olivejournaloio.htmlLiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能：*博客，论坛* 社会性网络，找到朋友*聚合，把朋友的文章聚合在一起LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。在上线后，LiveJournal实现了非常快速的增长：*2004年4月份：280万注册用户。* 2005年4月份：680万注册用户。* 2005年8月份：790万注册用户。*达到了每秒钟上千次的页面请求及处理。* 使用了大量MySQL服务器。* 使用了大量通用组件。3. YouTube的架构扩展http://www.dbanotes.net/opensource/youtube_web_arch.html在西雅图扩展性的技术研讨会上，YouTube的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video上有(地址)，可惜国内用户看不到。Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes的介绍是本文的主要来源)4. WikiPedia 技术架构学习分享http://www.dbanotes.net/opensource/wikipedia_arch.html维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。来点直接的数据：*峰值每秒钟3万个 HTTP 请求* 每秒钟 3Gbit 流量, 近乎375MB* 350 台 PC 服务器5. Tailrank网站架构http://www.dbanotes.net/review/tailrank_arch.html每天数以千万计的Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。专门爆料网站架构的 ToddHoff 对 Kevin Burton 进行了采访。于是我们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank所用的爬虫现在已经成为一个独立产品：spinn3r。6. LinkedIn 架构笔记http://www.dbanotes.net/arch/linkedin.htmlLinkedIn 雇员有180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600万，现在每月新增 100 万，50％ 会员来自海外(中国用户不少，也包括我).7. Yahoo！社区架构http://www.dbanotes.net/arch/yahoo_arch.html旧金山举行的QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站”晒架构”也是个比较过瘾的事情。请参观并收藏这个页面：Architecturesyou’ve always wondered about。8. Craigslist 的数据库架构http://www.dbanotes.net/database/craigslist_database_arch.htmlCraigslist绝对是互联网的一个传奇公司。根据以前的一则报道：每月超过 1000 万人使用该站服务，月浏览量超过 30亿次，(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18名员工(现在可能会多一些了)。9. Fotolog.com 的技术信息拾零http://www.dbanotes.net/review/fotolog_arch.html尽管是世界上最大的图片服务网站,Fotolog.com 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的,Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 9000 万美金. 算下来的话, 1个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.10. Digg 网站架构http://www.dbanotes.net/arch/digg_arch_cache_and_shard.htmlDigg工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。11.Amazon 的 Dynamo 架构http://www.dbanotes.net/techmemo/amazon_dynamo.html我在DBAnotes.net 上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ，Amazon一直找不到太多的资料。国庆期间读到了一篇关于 Amazon Dynamo 的论文，非常精彩。Amazon Dynamo这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.12. 财帮子（caibangzi.com）网站架构http://www.dbanotes.net/arch/caibangzi_web_arch.html财帮子(caibangzi.com)定位在”基金理财社区”。是国内访问量最大的基于 Ruby on rails 的 startup项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内”理财”是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。13.了解一下 Technorati 的后台数据库架构http://www.dbanotes.net/web/technorati_db_arch.html目前处理着大约10Tb 核心数据, 分布在大约 20 台机器上.通过复制, 多增加了 100Tb 数据, 分布在 200 台机器上. 每天增长的数据 1TB. 通过 SOA的运用, 物理与逻辑的访问相隔离, 似乎消除了数据库的瓶颈. 值得一提的是, 该扩展过程始终是利用普通的硬件与开源软件来完成的. 毕竟 , Web 2.0站点都不是烧钱的主. 从数据量来看，这绝对是一个相对比较大的 Web 2.0 应用.14. 说说大型高并发高负载网站的系统架构http://www.toplee.com/blog/?p=71我在CERNET做过拨号接入平台的搭建，而后在Yahoo&3721从事过搜索引擎前端开发，又在MOP处理过大型社区猫扑大杂烩的架构升级等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。15.大型高负载网站架构 的感想
http://atman.memoab.com/articles/194
摘自：http://blog.csdn.net/lovingprince/article/details/3379710
网络架构师三:资深网络架构师揭秘：这样的骨干网是如何炼成的？
骨干网(Internet Backbone Network)是连接国与国、城市与城市之间的高速互联网络。如下图所示，它通过海缆和路缆，将分布在世界各地的数据中心连接起来，是互联网服务提供商和云计算服务提供商的重要基础设施，肩负着满足全球范围内网络数据通信需求的重任。
全球骨干网示意图
骨干网的角色如此重要，以至于与此有关的话题，常常会引起业界的关注和讨论。作为云计算的基础，国内的云计算服务提供商是如何运维自己的骨干网的?又是如何实现自动化运维的?有哪些值得分享、思考的经验和做法?作为一名从业10年的网络架构师，我向大家介绍一下金山云骨干网的现况，希望对大家有所帮助。
如何快速发现骨干网级别故障?
首先简要介绍一下建设进展。金山云目前在北京和上海两地之间租用专线搭建起了骨干网络，按照计划，今年金山云会在广州部署节点，将进一步扩大环网规模，搭建北上广骨干环网，大幅提升金山云公有云服务的网络质量SLA。
当然，这并不是说建设骨干环网后就不会出故障了，对于互联网公司和云计算服务商来说，运营商的骨干网络故障是很让人头痛的，因为在通常情况下，这种故障会影响到多个省份用户网络的访问质量。
例如，2016年11月19日晚8点，包括华南、西南、华中等在内的国内多个地区，超过10个省份的用户，在访问华北地区的服务节点时，均出现了问题。测试结果显示，ICMP丢包率高达30%，延迟增大了约100ms，这种级别的丢包率和延迟情况，如果不及时处理，将导致用户的业务严重受损。
那么，对于这种骨干网级别的故障，云服务商能否做到快速发现定位呢?当然是可以的。
金山云的做法是，通过自研开源监控的方式，研发出服务于金山云整个骨干网的网络质量监控系统(Netbench)。
金山云网络质量监控系统监控图
如上图所示，金山云的这套系统支持多地区、多ISP监控，可在运营商发生骨干网故障时，快速发现并准确定位故障，同时采用电子地图这种直观形式，显示出各省份各地级市的网络质量(延迟、丢包等数据)，如果某地出现问题，地图上相应位置的颜色就会变得不同。
金山云网络质量监控系统架构图
金山云这套网络质量监控系统的主要特点，分为定位策略、主要功能、应用场景三部分：
一、定位策略
抓取访问客户服务的用户IP作为监控目的IP;
多对多的监控模式，多个源IP监控全国各个省市的用户IP(保证数据的准确性避免路由ecmp不均匀的问题);
通过对抓取到的IP进行筛选，排除掉一些不准确的IP，最终筛选出每省份数百个有效IP进行监控;
商用的IP地址库与BGP IP结合对抓取到的IP进行区分(ISP、省、市等);
Master-Slave的部署模式，监控周期可精确到分钟级(每1分钟)。
二、主要功能
提供短信、微信、邮件告警;
提供故障时的MTR数据(平均每省份多个MTR)，可帮助判断loss节点;
提供柱状图、历史数据展示等功能，可追溯故障，查看故障时的丢包以及延迟情况;
可针对重要的IP进行指定监控。
三、应用场景
可覆盖CDN、静态、BGP等多网络类型;
目前可针对EIP(计算)、KS3(存储)、KLS(视频)等业务类型进行监控。
骨干网调度架构图
如何快速解决骨干网级别故障?
对于骨干网级别的故障，除了需要快速发现，更需要快速解决。
有些互联网和云计算服务提供商，会通过多线BGP切换故障ISP流量至其他的ISP的方式绕开故障点，由于我国南北互通问题，跨网访问的质量很差，丢包和延迟都无法保证，而且在跨网切换时，会有较长时间的路由收敛，导致客户长连接业务中断。
金山云避免了这些问题。因为金山云的自建骨干网络拥有支持跨区域调度能力，当出现故障时，能够通过骨干网跨地区调度故障运营商流量，这种调度只是在同ISP不同地区之间的调度，只增加地区间的延迟，对整体丢包并无影响，这样一来，整体服务质量就得到了保障，同ISP内的路由切换收敛时间，可保证用户无感知，在近几次运营商南北骨干网故障中，金山云均做到了故障的快速调度恢复，客户也不必再因为运营商骨干网的故障而头疼了。
骨干网络调度前后对比图
这里解释一下原因。金山云可以做到以省市为单位的出口切换级别，比如目标浙江省出现了故障，会优先尝试调度浙江省出向流量至正常地区节点，在丢包恢复后将不会有下一步切换动作，不会导致全国切换而加大其它省份的延迟，只有在多省份同时异常而且调度出向无效后才会切全局入向流量。当前已经定义了一整套切换规则来判定什么情况下切换，什么情况下不切换。
骨干网运维自动化
每当出现骨干网级别的故障时，工程师很容易出现误操作刷错脚本等低级错误，导致业务受影响，故障处理速度上也得不到最有效的保障。
目前金山云上线的骨干网自动化运维平台，可实现对这种骨干网级别的故障的自动化判断和处理等一系列自动化流程，减轻了工程师的压力，它有着如下特点：
首先，Netbench提供判断依据，给出当前网络的质量情况，作为自动化脚本的触发条件开始进入自动化流程;
第二，通过Python脚本定义多个故障场景，当出现不同类型的骨干网时可根据脚本库调出对应的脚本;
第三，通过Netconf下发所需要调用的脚本策略配置到对应的核心网络设备上;
第四，直接对接邮件系统，从Netbench调用MTR发送给ISP进行自动报障;
第五，对接微信、短信告警平台，在故障时让客户能第一时间知道当前故障状态以及故障的处理进度。
自动化调度架构图
在两三个Region级别的骨干网通过“人”计算还是可以实现最优调度的，但是随着Region的增加，“人”计算的方式效率会越来越低，准确度也会越来越差，那么如何解决多Region骨干网调度呢?我总结出了几种方法：
1、通过Netbench的MTR功能定时定点采集每Region到每ISP的数据，平均每省份保证10-20个IP即可(排除路由Ecmp hash不均的问题);
2、对采集到的数据进行分层分级，区分到运营商层面的超核、核心、省市等，并在这些层级的IP上保留MTR当中的延迟值(运营商的设备都会对ICMP有保护所以不采用丢包值);
3、通过脚本分析构建ISP的逻辑IP网络拓扑图;
4、在运营商骨干网故障时能够清晰的描述到是哪个层级哪个核心节点出现的问题，能够在拓扑上清晰地看到问题所在;
5、在故障时可通过构建的逻辑IP拓扑计算出调度的最优RTT路径;
6、结合自动化调度实现最优调度。
随着客户对网络问题的重视程度的增加，骨干网以及多Region骨干网结构已经是现在的互联网服务提供商和云计算服务提供商不可或缺的重要环节。越来越多的重网络业务的出现，比如实施对战类的手机游戏、视频直播等对网络质量要求非常高的业务，不能一而再再而三地把我们所谓的SLA推到运营商的层面，站在客户业务的角度去考虑这是极其不负责任的态度，我们要在有限的网络环境中尽可能把客户的问题合理解决，这样客户才能把重要的业务托付到你那里。
由于运营、成本问题、运维、网络现状受限等复杂的因素，金山云目前并没有使用商用SDN的技术来实现骨干网自动化，，而是通过实践，使用了BGP、Python、GO等网络协议以及脚本工具配合Netconf来实现对于金山云骨干网的自动化。我希望通过介绍金山云在骨干网运维方面的思路，能给大家带来一些启发和帮助。
