如何避免成为“消防员”式的网络工程师？如果您对其中内容表示质疑，欢迎指出并发表意见，一经采纳，您将成为内测版读者，《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。

87 阅读 0 评论 58 点赞

我是靠谱客的博主冷酷爆米花，最近开发中收集的这篇文章主要介绍如何避免成为“消防员”式的网络工程师？如果您对其中内容表示质疑，欢迎指出并发表意见，一经采纳，您将成为内测版读者，《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

作者简介：

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

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

基于技术知识的排障思路：工程师通过学习掌握必要的技能知识，提升自身技术水平，善于从每次故障处理过程中吸取教训总结经验，不断提高逻辑思维能力。
运维自动化和运维流程制度：从人工运维到自动化运维，可以降低运维成本及维护复杂度。同时，在流程制度的保障下，能够提高工作效率，减少沟通成本。
跨部门协同工作：网络是衔接各业务系统的中间纽带，网络工程师在工作中与上下游部门的配合必不可少，协作处理恰当可事半功倍。

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

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

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

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

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

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

故障情境再现

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

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

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

故障排查过程

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

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

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

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

故障解除

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

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

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

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

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

事后反思与总结

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

受影响的路由器是几年前的老设备，自己对这款设备的数据包处理流程并不了解，在对基础知识了解不够透彻的情况下，需要找相应专家工程师进行支撑。
处理故障时，不仅需要查看日志信息，更需要确认设备配置信息，核查是否有不规范接入。
多种故障现象叠加时，需要从全局分析，打开思路，不能在一个故障点上纠缠。

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

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

之前的故障处理模式

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

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

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

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

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

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

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

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

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

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

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

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