|
大河云联创始人/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 (庞俊英)的文章，总能引发诸多思考，下面这篇文章，是之前高效运维社区发表的一篇，阅读人数突破一万，敬请欣赏： 《》
在12月16-17日两天，以“DevOps 2.0：重塑运维价值”为主题的 GOPS2016 · 北京站将在国际会议中心举办，汇集国内一大批运维界牛人，包括
Google、baidu、阿里、腾讯、京东等讲师齐登台，带来50多场时间更加持久的培训式演讲。
而且有机会见到本文的作者--庞俊英(Kitty)，你可以当面膜拜大神！oRZ
|
点击联系发帖人
