复杂场景下,式的网络工程师
分类:网络运维

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

作者简介:

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

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

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

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

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

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

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

开篇:

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

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

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

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

在超级互联网公司,随着服务器规模都早早迈过 10 万台量级,加之业务模式的多样性和 IT 架构的云化迁移,其 IT 运维团队面临的挑战与日俱增,常规的系统和经验都需要不断迭代更新。

故障情境再现

当老高还是一个初出茅庐的小高时,曾担任某二级运营商运维部门网络工程师,经常需要值夜班。有一天半夜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 路由器上连接好线路,至此,所有业务恢复正常。另外,小高联系业务规划部对客户接入方式进行规范化治理。

图片 1

事后反思与总结

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

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

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

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

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

在超级互联网公司中,通常不同的层次都由不同的团队来负责运维管理,同层次不同的硬件/系统/应用都由不同的小组来负责运维管理。

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

就基础设施即服务这层来说,随着IT设备规模的不断增加,IT 设备故障的告警种类与告警数量也随之急剧增加。

之前的故障处理模式

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

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

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

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

告警的多面性、冗余性、耦合性,导致某些核心层面的故障会引起大面积告警的现象,而这些告警又有可能分属不同小组,运维人员处理故障会增加排查问题的难度以及增加小组间沟通成本。

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

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

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

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

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

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

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

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

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

完整版网络运维三十六计

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

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

群满请加微信:gaoxiaoyunweiliuce

关注 DevOps 三十六计公众号

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

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

更多相关文章阅读

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

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

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

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

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

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

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

只需要5天!

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

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

这份含金量超高的证书:

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

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

也欢迎企业和我们联系:

刘琳,微信/电话:13910952502

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

同时因为对故障信息缺乏统一的管理,无法对告警系统进行反馈优化,致使误报漏报频出。同样也无法进行全面的故障信息统计分析,不知道如何对基础设施资源进行风险管理。

众所周知,IT基础设施层的运维工作,直接影响公司服务稳定性。一次服务中断事件便会对公司造成极大的经济损失。

但正如上述现状描述中提到的问题:

运维平台繁杂多样,

运维小组之间沟通滞后,

告警信息共享程度低,

工程师水平参差不齐,故障处理自动化程度较低。

告警系统缺乏有效的反馈机制进行系统优化,同时缺少全面有效的故障信息沉淀,无法帮助预算与评估采购系统进行合理采购。

这些都极大约束了运维水平的与时俱进,新的方法论和新的运维技术有迫切的内部需求。

我们收敛汇总一下复杂运维场景下的主要痛点:

如何在告警风暴时压缩告警

如何快速从大量告警中找到故障根源

如何提高不同运维小组的故障处理协作效率

如何实现对IT基础设施的风险管理如何应对?打造以故障定位为核心的运维生态体系!

基于上述背景下的痛点问题,一套以故障定位为核心的运维生态体系的建立便成为高逼格的不可或缺:

统一故障信息入口,使用机器学习的算法对信息进行分类整合和推理,自动定位故障生成case,设计开发统一故障处理平台,通知工程师来平台进行处理故障。

同时将所有数据进行沉淀分析,反馈给告警系统和质量管理系统,提高故障处理效率,加强基础设施风险管理。

而在这套生态体系中,故障自动定位技术便是体系是否能够成功建立的核心要素。

图片 2

故障根因自动定位简要科普

故障根因自动定位系统为人工智能的分支,属于诊断性专家系统,专家系统通常包含:

人机交互界面

知识库

推理机

解释器

综合数据库

知识获取

其中最重要的是知识库和推理机。知识库用于专家经验的存储,是一种静态规则,推理机根据现象结合知识库中的规则反复推理得出结论。规则集的组成形式有多种方式,本文重点介绍的是二叉决策树。

图片 3

故障根因定位系统的设计架构系统

故障根因自动定位系统主要由监控系统、接入系统、推理系统、通告系统四个部分组成,分别的功能如下:

监控系统:监控系统负责各类探针数据的采集,根据监控规则产生告警;

接入系统:接入系统负责对各类监控系统的告警信息进行汇总并格式化处理;

推理系统:推理系统根据专家推理树进行故障根因定位推理,定位最终告警原因,确定故障根源;

通告系统:通告系统根据定位出的故障根因进行故障信息通告。

图片 4

看个实际案例,看看到底能解决啥问题?

故障推理算法是整个故障定位系统的核心,这里重点阐述下故障推理算法的实现方式。故障定位算法采用机器学习中的二叉决策树的方式实现:

一方面希望将故障所产生的所有告警信息整合为一条信息,减少告警量;

另一方面希望能够智能定位出故障点,减少工程师排查问题的时间,并引入自动化处理。

以某公司网络故障根因定位为例,实现上述目标需要三步:第一步:将问题排障过程的经验提炼成二叉决策树;第二步:将告警信息按照时间分片算法进行分类分组;第三步:将分组的告警信息输出给决策树进行自动推理输出推理结果。看看推理树是怎么构建的呢?

本文由威尼斯手机娱乐官网发布于网络运维,转载请注明出处:复杂场景下,式的网络工程师

上一篇:三要素融入公司IT与事务 下一篇:数据流量爆发,运营商网络运维转型进行时
猜你喜欢
热门排行
精彩图文