百度网络运维这些年经历的变革和方法论

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

精彩看点

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

   网络工程师的价值

   

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

   

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

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

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

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

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

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

      应急抢险

      

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

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

      局部优化

      

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

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

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

      数据测量

      

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

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

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

      

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

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

      能力建设

      

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

      

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

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

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

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

      

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

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

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

      总结

      

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