通常不同的层次都由不同的团队来负责运维管理

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

作者简介:

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

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

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

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

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

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

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

开篇:

面对复杂的异构环境,如何及时全面地掌握网络、服务器、数据库、存储、安全等各类设备的运行情况?

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

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

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

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

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

作者介绍

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

面对越来越复杂的业务、越来越多样化的用户需求、不断扩展的IT应用,如何保障IT服务灵活便捷、安全稳定地运行?

故障情境再现

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

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

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

精彩看点

熊亚军

本文将给大家介绍在超级互联网公司如何基于网络的故障根因自动定位技术,提高故障定位速度,从而提高业务可用性。规模效应和云的效应极大提升了运维的复杂性

IT运维应运而生。

故障排查过程

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

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

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

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

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

灵犀技术总监,原百度系统部高级项目经理,负责百度IT基础设施监控团队,其带领的团队经历了百度服务器规模迈入几十万量级,网络架构数次演进,对服务器尤其是网络层的监控和运维自动化智能化有丰富的经验。

首先我们先来看看超级互联网公司的业务架构示例图:

随着云计算、大数据、物联网、互联网+、IAAS的不断冲击,信息化部门也在考虑如何实现高效率的运维,将繁琐、重复工作简单化、自动化,DevOps自动化运维就显得尤为重要。

故障解除

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

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

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

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

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

网络工程师的价值

开篇:

必威 1

DevOps故名思议就是Development和Operations的组合,是过程、方法和系统的统称,主要是为了把软件开发、技术运营和质量保证进行有效的结合,从运维到管理。

事后反思与总结

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

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

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

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

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

必威 2

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

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

运维,就是日常的运行维护,而DevOps是从制定计划到运营终止全生命周期的管理,那么DevOps自动化运维如何实现呢?

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

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

本文将给大家介绍在超级互联网公司如何基于网络的故障根因自动定位技术,提高故障定位速度,从而提高业务可用性。

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

了解应用在全生命周期中每一个周期都需要什么样的工作、平台、组织、人员进行匹配支撑,如敏捷管理、持续性的交付、IT服务管理等。

之前的故障处理模式

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

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

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

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

必威 3

规模效应和云的效应极大提升了运维的复杂性

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

持续性交付是核心,持续性交付的起点是应用需求的形成,重点是应用的高效运行,持续的优化、改进、审查、测试、部署、运营,形成PDCA闭环维度。

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

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

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

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

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

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

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

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

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

完整版网络运维三十六计

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

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

群满请加微信:gaoxiaoyunweiliuce

关注 DevOps 三十六计公众号

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

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

更多相关文章阅读

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

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

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

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

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

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

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

只需要5天!

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

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

这份含金量超高的证书:

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

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

也欢迎企业和我们联系:

刘琳,微信/电话:13910952502

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

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

首先,我们先来看看超级互联网公司的业务架构示例图:

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

传统运维面临的问题

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

必威 4

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

传统的IT运维是将数据中心中的网络设备、服务器、数据库、中间件、存储、虚拟化、硬件等资源进行统一监控,当资源出现告警时,运维人员通过工具或者基于经验进行排查,找出问题并加以解决。但是,随着互联网+时代的到来,移动互联网、云计算和大数据技术得到了广泛应用,从而导致企业所管理的IT架构不断扩大,服务器、虚拟化、存储设备的数量越来越多,网络也变得更加复杂,业务流程越来越繁琐,传统的运维管理也越来越力不从心。主要表现以下几个方面:

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

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

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

必威 5

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

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

运维平台繁杂多样,

IT环境异构:系统软硬件种类繁多,导致运维人员运维监控压力大,日常工作量繁重。

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

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

运维小组之间沟通滞后,

故障发生后,运维工程师花费大量精力排查问题,无法快速和准确的定位问题,治标不治本。

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

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

告警信息共享程度低,

由于设备数量巨大,日常巡检占用大量时间,导致工作效率低下,事倍功半。

应急抢险

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

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

工作机制混乱,面对庞大的IT系统,缺乏有效、自动化的运维流程,缺乏有效的绩效考核依据。

必威 6

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

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

缺少自动运维机制:IT部门人员过少,导致运维压力大;由于误操作,导致无法挽回的灾难;大而全的系统,对运维人员技术能力要求越来越高。

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

  • 运维平台繁杂多样,
  • 运维小组之间沟通滞后,
  • 告警信息共享程度低,
  • 工程师水平参差不齐,故障处理自动化程度较低。

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

系统内数据非常重要,如果遗漏备份,系统瘫痪/误操作等出现时会导致无法估量的后果。

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

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

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

自动化运维为你排忧解难

局部优化

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

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

自动化运维,可实现日常设备监控、主动发现问题、自动分析定位、基于标准化流程工具规范化处理、通过自动化运维操作工具处理修复等功能,最终实现监管治自动化运维。

必威 7

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

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

勤智运维深刻理解当前运维所面临的问题,根据多年来积累的经验,结合ITSS服务标准、DevOps、Iaas而推出的OneCenter系列产品,包含统一运维门户、多客户端移动运维、运维服务管理系统ITM、服务流程管理系统ITSM、运维自动化管理系统ITAM、运维大数据分析系统ITBA,为各行业信息化提供智能、高效、简单、自动化的IT运维管理解决方案,为企业业务提供强有力的IT支撑和质量保障。

本文由必威发布于必威-运维,转载请注明出处:通常不同的层次都由不同的团队来负责运维管理

相关阅读