银河国际手机版最新百度网络运行最近几年经验的变革和方法论,怎么样防止成为

如何避免成为“消防员”式的网络工程师?,消防员工程师

作者简介:

张永福
大河云联解决方案架构师,一名从事传统网络工作十几年的网络老兵,参与过运营商、金融、政务、交通等多个行业的几十个网络建设项目。自2016年开始加入大河云联公司从事SDN网络相关工作,先后参与SDN产品设计、网络架构设计、运维自动化系统设计、解决方案设计,致力于SDN在商用项目的落地部署,与热爱先进技术的小伙伴一起推动SDN行业发展。

对网络工程师而言,不管是基础网络的运维还是业务驱动的运营,在日常工作中都会碰到各种技术问题及不同类型的网络故障,我们根据经验总结出“网络运维三十六计”,帮助网络工程师在运维工作中减少故障,防微杜渐。“网络运维三十六计”可归纳为如下三类。

  • 基于技术知识的排障思路:工程师通过学习掌握必要的技能知识,提升自身技术水平,善于从每次故障处理过程中吸取教训总结经验,不断提高逻辑思维能力。

  • 运维自动化和运维流程制度:从人工运维到自动化运维,可以降低运维成本及维护复杂度。同时,在流程制度的保障下,能够提高工作效率,减少沟通成本。

  • 跨部门协同工作:网络是衔接各业务系统的中间纽带,网络工程师在工作中与上下游部门的配合必不可少,协作处理恰当可事半功倍。

下面请看两个比较有代表性的案例。

文末观看完整版网络运维三十六计

案例一、在网络排障中锻炼”抽丝剥茧”的能力

网络工程师对技术的掌握可以通过看书、查阅文档、做实验等手段实现,而排障思路不仅需要扎实的基础知识功底,还需要经历大量的现网实战,并善于对故障解决的经验做总结。

这里讲述一个由于欠缺基础知识导致故障处理思路不清晰的案例,希望大家通过这个案例进行反思和总结。我们不怕犯错,但犯错以后一定要及时总结经验和吸取教训,为以后的工作铺平道路。

老高是某运营商骨干网络资深运维工程师,经历无数风风雨雨,处理故障果断沉稳。在一次内部的运维培训课上,老高分享了自己的一段亲身经历,向运维新手强调故障现象分析判断的敏感度非常重要,也就是根据故障现象理清处理思路的能力。如果基础知识不牢固,可能会导致问题恶化,甚至导致最终都无法解决故障。

作者介绍:宋磊毕业于武汉大学,09年加入百度,现任百度网络与服务器运维团队技术经理。

故障情境再现

当老高还是一个初出茅庐的小高时,曾担任某二级运营商运维部门网络工程师,经常需要值夜班。有一天半夜12点多,值班大厅内的告警铃声突然响起,监控大屏上也翻滚着告警日志信息。

这天正是小高值班,而对于这种场景,小高在运维值班的过程中碰到过多次,基本上都是某个骨干传输瞬断或个别硬件设备故障等容易判断的问题;传输中断的问题一般会直接转到传输部门进行排查,硬件设备故障的问题一般会直接呼叫厂商工程师,值班人员配合厂商工程师做一些信息收集工作。

由于小高勤奋好学,所以也积累了很多通过日志判断故障原因的经验。

精彩看点

故障排查过程

小高根据公司规定的处理故障流程,首先查看监控告警日志信息,确认告警设备是某个地区的
PE(Provider
Edge)路由器设备,随后登录设备进行故障排查,通过查看设备日志,发现设备上有大量
BGP session 频繁的 flapping:

进一步查看路由器的物理端口,均处于 up 状态,查看 CPU
时发现路由器的第四块板卡的 CPU 维持在80%左右,这个水位的 CPU
利用率明显不正常:

小高此时有点无从下手,继续查看分析日志信息,希望能够找到其他信息,果然,在大量日志信息中夹带了少量的板卡报错信息:

看到 ipc_send_rpc_blocked
字段后,小高眼前一亮,他隐约记得协同厂商工程师处理过 IPC
告警故障,当时原因是板卡 IPC 处理通道被 hold
阻塞,导致板卡无法正常工作,可以通过重启板卡恢复业务。根据经验判断后,小高随即执行板卡重启,但是重启后故障仍然存在。

  1. 网络工程师在业务需求不断变化和网络规模急剧增长下都会遇到哪些挑战?技能短板、各方的认可度、成就感和成长空间,这些是否能与你产生共鸣。
  2. 百度网络运维这些年的变革和方法论转换,从应急抢险、到局部优化,数据测量,再到能力建设,你的网络目前处于哪个阶段?能否从这里得到一些经验和帮助
  3. NetDevOps是网络工程师职业发展的新方向,企业内部如何培养网工DevOps的能力,除了技能学习,还应该有管理方法和团队协作模式的变化。

故障解除

经过一番故障确认,板卡重启,小高的思路完全陷入到如何解决 IPC
日志告警上,此时仍认为是板卡问题导致 BGP 的
flapping,所以小高联系设备现场值班人员采用排除法进行板卡互换操作,当现场工程师将路由器的第四槽和第三槽的板卡互换后,故障现象仍在第四个槽位上。

小高有点懵,排障思路越来越局限,为了尽快恢复业务,继续采用排除法,将故障板卡上的物理端口逐个关掉再打开,同时观察故障现象。

当执行关闭到第五个端口时,路由器停止了 BGP flapping,并且 CPU
也恢复了正常,虽然小高还不知道是什么原因导致的故障,但是找到了触发故障的端口,恢复了大部分业务。

小高进一步排查发现这个端口采用的是 VLAN
方式接入,并且作为客户的网关接入了上百台电脑的一个二层网络,公司规定所有端口均需要采用三层端口
BGP
接入或者点对点静态路由方式接入,小高联系到第五个端口所连接的客户询问情况,客户反馈正在做割接,操作过程中出现了二层环路,导致网内出现大量
ARP 广播报文。

客户网络恢复后,小高配合在 PE
路由器上连接好线路,至此,所有业务恢复正常。另外,小高联系业务规划部对客户接入方式进行规范化治理。

网络工程师的价值

事后反思与总结

第二天,小高寻求其他网络专家的帮助,并查阅路由器设备文档,了解了此次故障所有的具体原因,以及应对类似问题的技术排查方法,同时针对故障处理过程总结经验如下:

  • 受影响的路由器是几年前的老设备,自己对这款设备的数据包处理流程并不了解,在对基础知识了解不够透彻的情况下,需要找相应专家工程师进行支撑。

  • 处理故障时,不仅需要查看日志信息,更需要确认设备配置信息,核查是否有不规范接入。

  • 多种故障现象叠加时,需要从全局分析,打开思路,不能在一个故障点上纠缠。

老高分享案例后,补充了一句话:“常在河边走哪有不湿鞋,各位运维老司机也不能掉以轻心。”

银河国际手机版最新 1

案例二、利用自动化运维工具提升工作效率

伴随近些年互联网的蓬勃发展,百度的产品线日益丰富。业务上从搜索变现一枝独秀到现在
O2O、互联网金融、公有云服务崛起。但是所有业务对基础设施的稳定运行、随需而变的要求没有变化。这也是网络运维团队工作的核心目标,提供稳定优质的网络基础设施,同时高效的满足业务需求,保持业务的正常运行。

之前的故障处理模式

我目前就职的公司是一家 SDN 软件开发公司,刚开始我对于 SDN
的理解是,不需要网络工程师登录设备输入各种命令行就能够通过可视化方式完成所有运维工作。

但当我进入这个公司并且开始 SDN
网络建设和网络运维工作后,发现和想象中有很大距离,虽然所有的业务开通都是通过
SDN
控制器完成的,但是当网络中出现故障后,还是需要运维工程师根据经验进行全网的故障发现及修复工作。

我们日常运维工作中发现一些故障后,并不能第一时间判断出故障的影响范围,以及是否真正影响了客户业务,例如当一条传输线路中断后,需要运维工程师登录
SDN
控制器系统及网络交换机进行排查,确认有多少业务发生了收敛,哪些敏感业务受到了影响,是传输故障还是网络交换机故障,等等。

这些问题都需要人工确认,值班和运维工程师的苦逼程度可想而知。这种运维处境和维护一张传统网络几乎没有区别,公司的运维能力完全依赖于运维工程师的水平。

银河国际手机版最新 2

开发自动化运维平台来提高效率

作为一个拥抱新技术、拥抱 SDN
的新兴软件公司,面对网络工程师碰到的种种困境,公司决定采用 DevOps
理念开发基于 SDN 的自动化运维平台,成立虚拟工作小组。

小组成员包括一线运维网络工程师、系统工程师、研发工程师、大数据分析工程师,从系统规划设计、一线需求收集、开发设计、编码、测试,到系统发布、系统部署、系统运行、系统再规划设计,形成一套完整的
DevOps 能力环。

项目立项后采用敏捷开发、快速迭代的精益管理模式,一期自动化运维平台自项目启动到上线仅用了2个月时间,解决了运维工程师40%的需要手工确认的工作。自动化运维平台架构设计如下图所示。

在运维平台中对运维工程师帮助最大的是监控告警模块,通过各系统间关联调用和大数据分析,做到告警自动合并、自动过滤,同时对于定义的不同级别的告警进行不同的告警通道发出,例如对于有业务影响的高优先级告警将直接电话呼叫运维人员,对于中等优先级的故障则通过微信、钉钉等进行通知,对于低优先级的故障则不通知,仅存储在运维平台内供运维工程师线上查询。

自动化运维系统上线后,值班人员无须盯屏式监控,只需要保持手机畅通即可得知发生故障后的影响范围和严重程度,以及需要协调哪些资源可以处理故障。

同时,无论是运维工程师还是值班人员,均可以根据自己的经验和碰到的问题提出开发需求,由研发工程师设计并编码,进入下一阶段的版本迭代开发、测试和发布,需求提出者做验证确认符合要求后关闭需求,若不满足功能需求,则进一步优化,直至功能符合预期为止。

同时,运维部门根据历史经验和对现有运维系统的理解,制定了故障处理流程,包括需要人工介入的故障和需要软件识别的故障,通过每个案例完善内部知识库体系及自动化运维平台故障自愈模块的开发迭代。故障处理流程如下图所示。

截至目前,公司的自动化运维系统已经开发至第三阶段,帮助网络运维工程师降低了60%的工作量,曾经烦琐重复的工作都交由软件完成,工程师有更多的时间用在技术创新和提高工作效率上,每个人都能创造出更多的价值。

完整版网络运维三十六计

想与众多参与 DevOps 三十六计创作的老师近距离交流?

请扫描下方二维码入群参与交流

群满请加微信:gaoxiaoyunweiliuce

关注 DevOps 三十六计公众号

我们将长期发布 DevOps 三十六计完整内容

如果您对其中内容表示质疑,欢迎指出并发表意见,一经采纳,您将成为内测版读者,《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。

更多相关文章阅读

有赞数据库自动化运维实践之路

运维版《成都》,听哭了多少人…

同样会 Python,他的工资比你高一倍

阿里万亿交易量级下的秒级监控

IT 运维的救赎——顺丰运维的理想践行

学好 Python、拿高薪、竟是如此简单

快加入高维学院直通车成为认证运维开发工程师

只需要5天!

在5天内集中向你传授面向 DevOps 的运维开发工程师所需要掌握的所有精华。

更有含金量的是,学习结束你还将拥有一张【运维开发工程师认证证书】

这份含金量超高的证书:

如能被推荐进入上述大厂,您的培训费将被退回一半!!

更多企业直通车,正在路上。

也欢迎企业和我们联系:

刘琳,微信/电话:13910952502

参与报名及课程详情、请点击阅读原文链接

任何一个团队的成长都是从平凡一步步鲜血淋漓的走向卓越,百度网络运维团队也不例外。在追求稳定和高效的过程中不断遇到挑战。技术方面的挑战主要来自于业务需求的不断变化和规模的增长:

业务需求的不断变化推动技术发展和规模发展,百度的业务形态很长时间以来都是类似搜索、贴吧等页面展现类服务。随着百度云、百度钱包这些新形态服务的发展,连带推动了一大波网络技术的迭代,这是一个各种技术不断出现又消失,逐渐趋于稳定的收敛过程,在这个过程里工程师需要投入大量精力去了解新技术并进一步判断技术的发展方向。

随着网络规模不断增长,变更和监控也变得更加困难。特别是架构和策略复杂的情况下,人工决策风险难以控制,考虑不周的变更会对整个网络造成影响。规模增长的同时,网络监控也在逐步失效。传统基于SNMP、SYSLOG的监控可以测量到一部分网络特征比如流量和协议状态,但是对于全网时延、丢包这些重要的网络特征无法监控,从而忽略了这些业务有感问题的监控。

与此同时,网络工程师的个人发展也遇到了的挑战:

  1. 技能存在短板,好想法落地困难。经常能遇到网络工程师有好想法,但是在项目落地的过程中只能依赖外部开发团队,排期和项目完成度较难控制,甚至因自己不具备
    coding
    能力,在前期的数据分析阶段项目就夭折。网络工程师coding能力的不足成了项目落地中的一个困难。
  2. 认可与理解,每天报警不断,家人不满意。故障处理速度慢,业务不满意。网络故障业务先感知,自己不满意。必须跳出救火式运维的套路,提高网络运维的能力和效率,让大家都满意,从而得到更多的认可和理解。
  3. 成就感和成长空间,项目无法快速落地,工作成绩不被认可,每天疲于奔命没有成就感,成长空间有限。如何突破个人的瓶颈?

改变的最重要一步是根据实际情况建立合适的方法论,调整工作重心。下面给大家介绍百度网络运维这些年的变革和方法论转换。

应急抢险

银河国际手机版最新 3

和绝大部分公司一样,百度网络运维团队早期最主要的工作是应急抢险。当年的网络是一个用商用设备组成的STP+VLAN大二层,除了有一些商用负载均衡设备外,同时还有一些服务器直接接入到公网。

大二层带来的最明显的问题是广播风暴,08年某数据中心有4000多台服务器,在这个网络里面常态有1Gbps的单播泛洪流量,时不时还会有广播风暴。网络监控用MRTG做流量图、用正则表达式匹配SYSLOG做告警,工程师则拿着手机随时等着收报警短信。

局部优化

银河国际手机版最新 4

第二个阶段开始做一些局部优化。此时网络架构由大二层改为三层,网关终结在TOR上,网络设备仍然是商用黑盒设备,开始自研负载均衡器等网络组件。网络运维团队在这个阶段的主要工作是联合开发团队做监控和自动化定制,同时在网络架构上做一些深度优化。

告警根因定位系统是当时的标志性项目。百度线上每天有几百万条原始日志告警,通过决策树推理聚合同一事件的日志,可以将告警收敛到几百个事件,今年的目标是告警量控制在每天100条以内。

另外一个例子是做OSPF路由优化。当时全网运行OSPF,在优化之前核心交换机上维护了6万条LSA,路由震荡频发,一次收敛需要1到2分钟。当时做了大量分析,花了几个月时间对全网OSPF整体进行了优化,包括协议定时器的调整、各种路由汇总等,做完之后核心交换机LSA减少80%以上,接入层交换机路由条目减少90%,路由收敛时间降低一半且故障不再频发。这里可以跟大家分享一下我们的经验,如果用OSPF来做组网,服务器规模没超过15万台前可以通过各种优化手段维持网络稳定运行。超过15万台后就需要从架构和路由上进一步优化了。

数据测量

银河国际手机版最新 5

第三个阶段我们在做数据测量,也是最近这一两年我们的核心工作,此时的网络里运行有大量的自研交换机和NFV,DCI网络也有了一定的规模。右下角这张图简单描述了数据中心网络的结构,包括数据中心核心、集群核心等。大家可以看到整个网络里面,链路的数量非常多,如何知道每一条链路质量是什么样的,几乎是不可能的任务。再看上面那张图,黑色的大点可以认为是三个核心节点,其他小的是分布在不同城市的数据中心。每个节点到数据中心之间实际有几十条物理链路互联,两个数据中心间路径有上万种组合。在这种规模的网络中人工快速定位某条链路丢包几乎不可能,但这又是必须要做的事情。

面对了很多因规模问题造成的困难后,我们提出一个解决问题的思路,测量-优化-评价。

首先想办法测量你需要的数据,比如网络丢包率、时延抖动。拿到数据以后去做网络架构或测量方法的优化,同时建立评价体系去看是否已经优化的足够好。不断的重复测量、优化、评价这个过程,直到数据满足业务要求。

银河国际手机版最新 6

举一个具体的例子,某数据中心出口有两条链路,主用的一条是时延较低,另外一条平时备份。从图里可以看到网络正常时延大概是在23毫秒左右,在故障的瞬间时延飙升,绿色曲线是网络中默认QoS等级的服务,故障更早影响到了这个队列。恢复期间也发生过几次链路切换,时延有抖动。当每一次抖动都是可以具体量化的时候,就可以轻松判断出来故障对业务有什么样的影响,乃至不同服务等级的业务能感知到什么现象。

网络质量监控的例子是我们内部协作的一种方法,即运维团队不直接开发,和开发团队一起协作达成目标。在网络质量监控项目中,网络工程师翻阅大量业界和学界的论文进行调研,向开发团队提出需求、给出测量方法、指导网络部署方案。开发工程师则聚焦在怎样去实现这种高并发的测量,如何用合适的算法计算具体哪些物理链路有影响,以及如何将最终结果呈现出来。最后这套监控系统除了能呈现整体丢包率和时延外,还可以通过端到端的测量,从数十万种链路组合中直接定位到发生丢包的是哪一条链路后节点。

能力建设

银河国际手机版最新 7

2016年我们关注的方向叫网络能力建设,为了进一步提高运维能力,缩短网络能力落地周期,运维团队开始转向DevOps。网络最基本的能力是路由转发,除此以外DIFFSERV、流量调度、快速故障恢复是等能力。这些能力之前或者缺失或者分散在不同系统里,现在我们来填补空白同时整合能力。网络工程师要做的是去开发与业务逻辑强相关的内容,比如怎样做流量调度,怎么去做故障切换等。像ODL框架在线上应用的性能问题、容灾能力等问题则由开发团队去解决。

银河国际手机版最新 8

谈到NetDevOps就有必要提下SDN。我们所理解的SDN是指在数据基础上根据策略执行动作,从而干预网络。

首先先看左边的图,两个数据中心间通信,常态下路由协议会帮你计算出来他们之间的访问路径,但当带宽突然少了四分之三,网络严重拥塞时应该怎么办?

我们的解决方案是网络工程师自己开发BGP控制器,
通过干预BGP属性和路由,在整个核心网的范围内疏导流量。开发控制器本身并不算非常复杂,更有挑战的是落地过程中遇到的大量需要网络工程师处理的细节,比如如何发现流量拥塞出现,如何选取调度路径,网络架构在非稳态下是否会造成调度失效,各个核心节点下发路由的顺序应该如何,哪些流量可以做调度,调度引入的时延增长是否会影响业务等等。这些细节需要网络工程师一点一点的去分析琢磨。

另一个是即将落地的项目,网络集群自动故障隔离。右图是一个CLOS网络,spine-leaf中间的连线可以多达上万条。这个项目的目标是当监控发现一组spine出现异常时,可以自动隔离故障区域。技术实现方面基于ODL整合监控和策略执行动作。这里有个特别的地方,是把现场操作工程师作为SDN的一个组件插入到流程里面,包括自动下发工单,提供清晰的操作指引和自动验证能力,反馈操作结论到流程等。这样争取在网络工程师不介入的情况下,做到故障自动隔离和恢复。

银河国际手机版最新 9

DevOps知易行难,转型从铺垫到落地,花了大概1年半时间。

以前百度网络工程师主要来自银行、运营商和互联网企业,这些工程师有丰富的网络设计运维经验;校招的学生很多还没毕业就拿到了CCIE证书,了解网络协议和设备。但是这个团队里没有人是非常擅长coding的。为了进一步提高运维能力,缩短网络能力落地周期,在这种背景下我们开始了DevOps转型。配合转型,从管理策略到团队协作模式都需要做出相应调整。

  • 首先管理策略上要发生变化,明确告诉大家除了深度了解路由协议和网络架构设计外,转向DevOps是职业发展的一个好的方向。
  • 第二个是成员转型意愿非常强烈。尤其是入职一年两年左右的同学,因为招到的人本身素质非常好,都是来自于重点高校计算机或通信专业,本身有一定
    coding 基础,进一步提升
    coding能力并不是非常困难的事情。这样经过一年的培养和锻炼,我们终于有了一些能coding
    的CCIE!
  • 第三个难点是理清和其他团队的关系。特别是运维平台研发团队,要分清哪些是网络工程师应该做的,哪些是适合研发团队做的。网络工程师擅长的领域在设备、协议和业务逻辑,但涉及到平台级开发、算法优化等方面时,需要研发团队来一起实现。以前的合作模式是网络运维工程师提需求,现在的合作模式是网络运维和开发团队是一个联合开发团队。
  • 第四个是教练式辅导。让网络工程师写程序在起步阶段最难,我们聘请了资深的研发工程师对网络工程师从设计思想、实现方案到开发规范全方位辅导,大幅降低学习成本。

总结

银河国际手机版最新 10

这些年百度网络运维思路和方法论上不断进行着变革,应急抢险、局部优化、数据测量、能力建设,这四个阶段也是方法论的不断转变的过程。在这个过程中,我们看到网络工程师的工作重心在不断调整,工作成绩和个人价值在也在不断提高。期待通过DevOps和自动化释放更多网络工程师的能量,在技术和个人成长方面取得突破,对业务发展提供更多帮助。希望百度的经验对大家有所帮助,期待与各位更多的交流。

【编辑推荐】

发表评论

电子邮件地址不会被公开。 必填项已用*标注