What?网络运维中,成熟的公司必须杜绝CTO?!

作者简介:庞俊英 (Kitty Pang)

大河云联(DAHO) 创始人/CEO,阿里巴巴集团 原首席网络架构师,从事网络规划、运维、研发工作超过十五年。曾在Cisco、中国电信等公司任职,是中国获得CCIE认证的最早的女工程师之一,对网络规划、运维和研发有非常丰富的经验。

精彩语录
1、从行业歧视链到公司运维大团队工种的歧视链,网络运维都属于“背锅工种”和落后生产力的杰出代表。
2、网络上人为出的事,都是大事。
3、重复的事需要让程序来完成,同时还要注意的是,程序不是脚本,DevOps 工程师千万不要变成脚本工程师。
4、运维圈里流行的“故障预案”,越是成熟公司预案做得越多、越完整。但大家思考一下,当突然收到大量业务或是网络告警时,判断执行哪一个预案往往成了哲学题。
5、作为一个运维工程师一定不要有情怀,遇到故障第一时间是隔离故障恢复业务, 而不是花大量的时间trouble shooting找root cause。
6、核心网(也称骨干网)的运维工程师是高危网络运维工种中最高危的一种,行业潜规则是,高危变更全交给新员工或是厂家做,于是留下越来越多只做加法不做减法的配置如ACL或BGP的community。
7、从网络向业务靠拢的方法是错的,尤其对于DCI的骨干网和核心网。
8、骨干网都是长出来,而不是规划出来的。
9、成熟的公司必须杜绝CTO。

引言:授人以鱼,不如授人以渔

今天我们谈痛点和思考,不谈技术有多“牛B”,不争论技术路线。

今天我想分享的是我作为一个经历过网络系统集成商胡售后工程师、Cisco售前工程师、运营商规划和设计架构师、互联网公司运维的老网工对网络近20年的思考,只讲痛点和思考,不讲如何解决,不讲什么技术多牛逼,只希望大家分享痛点共同思考在网络方面做点什么。

昨天有人跟我说我在另一个会上不讲干货,我真心是不认同的,自认我讲出来的都是我蛮长时间里的思考,以及在平常的工作中遇到的网络设计问题、成本问题还有日常处理的故障所引发的思考点。

有些思考我有答案,有些思考我也没有答案。不过即使我有答案,也不想参与到技术路线的口舌之争里,容我通过团队的努力做起来时再讲我的答案,否则大家打的是无聊的口水仗。

一、网络一直存在的痛点

1、运维无小事

在过往的顶级运维大会上,基本没有关于网络运维的Topic,网络运维工程师被俗称为“网管”,从行业歧视链到公司运维大团队工种的歧视链,网络运维都属于“背锅工种”和落后生产力的杰出代表。

行业歧视链表现为:红包发不出来,手机显示“网络不给力”,大家骂你们阿里就不能招几个靠谱的网工吗?

在互联网公司的运维支撑团队中的工种歧视链为:应用开发鄙视PE(Product Engineer or Privision Engineer),PE鄙视SA(System Administrator), SA鄙视NE(Network Engineer),NE鄙视IDC工程师,IDC欺负现场外包。

外界是很少知道一个互联网公司的NE需要做哪些网络运维的事情的,网络专业一直存在的痛点又有哪些?

其实,一个网络架构师的每一代架构设计需要做哪些取舍,规模、效率、成本,每年的要求是不同的,架构师要关注IDC的趋势,关注结构化布线的趋势,关注芯片、关注CPU、关注存储等等。

现场提一个问题:如果让某云北京的一个Region整体脱网,会有几种可能?

我的答案是两种可能:
一种是北京地震;
另一种是网工做变更了。

网络上人为出的事,都是大事。

一定会经常有一个声音“招靠谱的工程师”。我想说的是:没用的,凡是软件都有Bug,凡是人干的事都一定会出错,只是早晚而已。

每个公司都会有几个神一样的工程师存在,小公司里也一定会有一个神一样的网络运维工程师,所有的网络拓朴和每个IP段是什么含意他全清楚,这个人不能出差、不能休假、不能离职,否则没有准确的网络拓朴,没有准确的IP地址归属表。

所以,重复的事需要让程序来完成,同时还要注意的是,程序不是脚本,DevOps 工程师千万不要变成脚本工程师。

接下来,我想分别从DCN(数据中心网络)、DCI(数据中心互联)两个场景来分别讲解痛点,再从业务和运维两个不同的视角来分析痛点。

2、数据中心网络(DCN)的痛点

针对数据中心网络,从运维视角看,运维复杂度和难度源于设备规模化带来的规模效应。

总结DCN运维的核心问题有:日常变更如何保障、如何进行大规模交付、当出故障时如何做到故障的快速定位并采取隔离手段。

今天DCN的主要问题在于网络是端到端,但我只看到了交换机端口,对于网卡和内核一窍不通,另外就是见鬼的静默丢包。

在此要强调的是在运维圈里流行的“故障预案”,越是成熟公司预案做得越多、越完整。但大家思考一下,当突然收到大量业务或是网络告警时,判断执行哪一个预案往往成了哲学题。

我的另一个观点是,作为一个运维工程师一定不要有情怀,遇到故障第一时间是隔离故障恢复业务, 而不是花大量的时间trouble shooting找root cause, 那么对于一线运维网络工程师而言,是不是一个网络技术高手好像并不那么重要,成熟的公司必须杜绝CTO(Chief Troubleshooting Officer)。

在DCN(数据中心网络)的问题里,我认为成本问题是一直在争论但还没有达成共识的表象问题,并且一直在变幻出各种花样的伪命题。网络架构师们用各种收敛比、各种混搭不同厂家设备,以求达到更低的网络设备采购成本。

但是必须要算一笔帐:硬件节省的成本 vs 非标架构带来的运维成本的增加。

问题、需求、技术是一直在不断发展变化的,曾经还有个争论了很久很有趣的关于TCP incast的Buffer大小的问题,出了很多顶级论文然后随着软件应用的调优不再是特定交换机厂家的独特特性,最终也成为了伪命题。

从目前的业务视角看,DCN现在面临的网络虚拟化需求是一个刚性需求,也给技术发展带来了新的诉求。

3、数据中心互联(DCI)的痛点

对于DCI(数据中心互联)的环境,运维视角的核心问题有:变更问题、成本问题、以及专业层壁垒问题。

在骨干网上的变更问题尤为突出,在应用发布时会有A/B测试和灰度发布,但在网络界和运营商界是没有A/B测试的,原因是这么大一张骨干网,没有谁有财力做一张一模一样的网做为影子测试网。

另外,目前阶段我认为用分光分流的方式做“网络大数据的业务可视化和运维可视化”是个表象的问题,甚至可能是个伪问题,不太相信天天被告警短信吵得睡不了觉的软工可以通过大数据分析预警网络故障。

总的来看,核心网(也称骨干网)的运维工程师是高危网络运维工种中最高危的一种,行业潜规则是,高危变更全交给新员工或是厂家做,于是留下越来越多只做加法不做减法的配置如ACL或BGP的community。成本是数据中心互联骨干网需要非常重视的问题,规划得不好及运维自动化做得不好带来的投资和故障带来的业务损失都将是巨大的。

4、网络本身的痛

所有的这些问题,从网络本身的历史来看也存在很多原罪,程序员经常会问“为什么只要一遇到DCI就会有应用不友好?”、“为什么网络不能是平的”、“为什么网络不能即插即用”。

在网络运维团队中通常有一项KPI是要做网络感知业务,在我不算长不算短的网络运维经历中,我的心得是:从网络向业务靠拢的方法是错的,尤其对于DCI的骨干网。

需要强调一下,Internet的骨干网和DCI的骨干网的网络特点是有很多不同的,在Internet上用DPI的想法用于DCN和DCI的TAP的方法一定是无效的。我阴暗地认为,这是因为硬件厂家想多卖一套网络设备而产生的“用钱解决的业务问题”。

网络路由协议有二十多年没有突破式的进步,路由协议第一天是为Internet而生的,但当年的发明网络路由协议的殿堂级的人物们一定预料不到Internet会变成现在的样子,上个世纪的路由算法早已不适用于现代网络,可是没有新的协议出现的原因是什么呢?

我认为并不是不发明新的网络协议,而是全分布式的自路由、自收敛的网络协议的方法论走到了尽头。

我们需要思考其它的网络架构的方法,不再是Halabi的Internet Routing Architectures。

针对骨干网或是俗称的大网,流量和拓朴是两件事,拓扑是路,流量是车。我们讲的全网拓朴是指路,如何能够可视化一张流量拓朴?

我指的是业务级的流量拓朴,而不是Cacti、Nagios,更别提MRTG 这些工具,多少年来为什么没有一统天下的工具或平台出来?每个略有点开发能力的运维团队都自己开发一套网络管理平台?这件事如果做得好,势必是个很了不起的事,但是为什么没有商业的NB产品,希望大家思考下。

做过多年大网的人的经验是:骨干网都是长出来,而不是规划出来的。

所以网络规模小时人肉运维是可以的,当一个一线运维团队超过20人,人肉运维将是整个系统链条里最大的隐患。

二、网络发展带来的思考

1、网络界的一项人类级发明 —— CLI

让我们回味一下网络界的一项人类级的发明Cisco Style CLI。

作为行业事实标准的 Cisco 命令行使得网络圈有:思科网工、华为网工、Juniper网工。

道理想透很简单,由于存在学习成本。在我当年考CCIE时,我们经常拼的是谁脑子装的命令行最多谁就最牛,我们比拼的CTO是首席Troubleshooting Officer 就是比谁知道的命令最多,谁运用的最出神入化。

CLI这项发明的结果就是,当一个公司的运维团队里最熟悉某一个厂家的命令行的人最多时,这个公司的设备选型就最被这个厂家锁定。

2、路由协议是落后的生产力

前面提到过网络协议二十年不变,成为落后生产力,导致网工成为了所有工种的落后生产力,分析下原因。

在90年代,互联网路由协议强调的是自愈合,所以没见过哪一张大网是全静态路由配出来的,动态路由协议做到了自己管自己,非常典型的全分布式,在所有路由协议里都没有考虑Utilization,从未考虑过“软件定义”。

在2000年MPLS 带来了一次小变化,但现在可以给MPLS TE下一个“死刑”的结论了,没有最终得到业务上大规模应用的原因是:配置过于复杂,基本没有办法进行大规模规划,点对点的在实在必须用的地方配置几条TE tunnel。

那么,是不是也可以说是因为它也没有根治分布式的问题呢?其实Google 的B4也是MPLS TE的思想,但提出来“自己管自己,上帝管大家”,有了一个“大脑”SDN Controller。

我相信凡是有情怀的工程师都会酸酸地说“为啥Google做了大家就能当成事实的真理来相信,我们国内的公司做啥都被当成瞎折腾”。嘿嘿,我也不知为啥,我也很被这个现实问题困扰。

3、DCN及DCI的复杂性决定了骨干大网都是长出来的

总结一下前面讲的内容,DCN的复杂性是由Fabric的设备数量带来的,主要体现为运维自动化和运维排障的难度高。

DCI的复杂性在于流量是以拓朴的矩阵关系为基础,所谓的流量智能调度是件很难的事,看每个单点很简单,而组网后IP网与光网的联动,业务路由的选择是件很难的事。希望大家重视骨干网的自动化运维,不是靠谱运维团队的价值观来保证。

另外,想要再念叨一下:骨干大网都是长出来的,骨干网的规划要有工具,但不是有工具就能规划好,如何保证联动业务反馈是提出SDN的驱动力。

三、说说我对SDN的理解

历数了网络协议的那么多原罪,还有网路运维那么多痛点,有解吗?

1、SDN的S是啥?
在近几年对SDN的实践中,我对S的理解总结为下面几点:

  • Software,由网络的用户决定转发路径,不再是RFC Routing Protocol;
  • Service Business Driven和Service 定义网络;
  • SLA 的业务持续性,不再是四个9还是五个9

所有的基础设施都是不可靠的,如果从网络本身追求几个9那么只有一个办法,就是花钱做全冗余,而我们要思考的是如何做“业务的持续性而不是业务不丢包”。

2、SD-WAN为用户带来了什么?
新技术的发展总是能给我们带来很多惊喜,SDN也已然吊足了网络圈大拿们的胃口。比如SD-WAN,为网络用户带来的价值有下面这样的递进关系:

  • 原始连接
  • 快速连接
  • 自定义的快速连接
  • 可视化可感知的自定义快速连接
  • 最高境界是如氧气般必须存在而无需在意的自由连接


同时,SD-WAN给基础运营商能够带来的是:新业务也能改变传统的老业务,如:MPLS/VPN、VPLS这样的因技术本身不具有扩展性而影响到业务发展的状况,SDN可以带来骨干网的按需平滑扩展,保障核心网可以按照软件定义的方式“长出来”,并通过API实现业务编排的快速开发和自定义。

3、SD-WAN为基础设施运营者带来了什么?

这里打个广告,我创立的大河的SD-WAN方案,通过自主开发的CanalOS SDN平台,实现了广域网从局部优化向全局大脑管控的全局平衡优化的过渡;从黑盒子网络到有请求交互与状态的自调节网络发展。

从前的网络连接交付,经历了线下工单方式到用户自助服务,未来将会通过API由应用自调用。

这个方案实现的网络选路,会将物理路径和所选路径的模型体现在SDN 平台系统中,曾经通过CLI完成的依靠人经验的调度,进化到依靠算法分析的自适应实时调度。

4、 从传统网络到SD-WAN

其实,我认为SDN广域网的落地商用并不是一件容易的事情,当我们真正开始动手尝试SD-WAN网络时,会遇到不少问题,比如开源版本的“晦涩”难用,大量的开发需求、人力投入,还有后期运维上痛苦的转型,复杂的控制关系等等。

更重要的是,技术之外,我们是一群热血网工,奔着“Net work for you, not you work for net”的目标,在SDN应用方面,希望从用户视角引入创新业务、通过开放软硬一体平台从业务驱动科学规划、从规划变革成本、从业务定义网络的连接和SLA,重连接方向轻路由路径。云计算的三大要素的网络的变革势必是由SDN点燃。

OK,在SDN正在悄然快速落地的时代,让我们一起拭目以待。
文末福利
GOPS2016全球运维大会·上海站火热报名中,DAHO CEO 庞俊英届时在主会场有一个主题演讲,《网络运维的昨天、今天和明天》。详情:http://gops2016-shanghai.eventdove.com/


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/17765.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-09-02
0