彩世界平台-彩世界时时app-彩世界开奖app苹果下载

热门关键词: 彩世界平台,彩世界时时app,彩世界开奖app苹果下载

您的位置:彩世界平台 > 活动会议 > 互联网技术员成长日记162-网络程序员的固定

互联网技术员成长日记162-网络程序员的固定

发布时间:2019-10-05 11:38编辑:活动会议浏览(61)

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

    作者简介:

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

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

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

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

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

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

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

    这是我的第162篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人

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

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

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

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

    图片 1

    故障情境再现

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

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

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

    有人会说,扯淡,网络工程师有个什么定位,好好上班就行了

    故障排查过程

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

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

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

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

    没有错,这就是个普通的IT岗位

    故障解除

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

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

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

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

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

    前几天的一件事情促使我还是要和各位交流一下

    事后反思与总结

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

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

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

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

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

    一位刚刚开始实习的大学生,是因为我推荐到一家从事网络技术的公司中,他所在的公司差不多有50多人

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

    但是干了半个月,这个实习生“领导”了另外两个人的情绪,和所在公司的HR发生了争吵之后,离职

    之前的故障处理模式

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

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

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

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

    我不觉得意外,我已经遇到过多次这样极端的例子

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

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

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

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

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

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

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

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

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

    完整版网络运维三十六计

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

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

    群满请加微信:gaoxiaoyunweiliuce

    关注 DevOps 三十六计公众号

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

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

    更多相关文章阅读

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

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

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

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

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

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

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

    只需要5天!

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

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

    这份含金量超高的证书:

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

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

    也欢迎企业和我们联系:

    刘琳,微信/电话:13910952502

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

    不去评价这个事情本身谁对谁错

    我想今天谈谈定位这个事情

    我也面试过很多人,不太夸张面试过2000人以上绝对有了(大概估算,不要较劲)

    不管面试多少人

    现在回想一下,这么多人其实就是两类人

    两类人的定位不一样

    我讲讲一个真实的故事

    我面试过程中所遇到的两个女孩

    不提真名,也别对号入座

    不管我讲到销售岗位还是技术岗位,对于网络工程师这个行业的朋友,都有学习的意义

    一、来自著名营销团队的总助理

    我刚到一家公司负责组建团队

    公司除了老板没有一个人,我是第二名员工

    我的核心任务就是立即组建销售团队和技术团队

    如果招聘不到人我就要滚蛋了,所以我还是比较用心的招聘

    筛选无数人之后

    遇到一名女孩

    来自某著名企业管理培训的总助理

    过去的工作就是专门做会销,客户群体就是老板和总经理,就是让这些老板报班学习管理课程,客单价2-10万

    面试的时候

    第一,对方沟通看起来不错

    第二,对方对于新成立的团队也比较有信息

    第三,我经过授权,给对方的底薪是4000,绩效6000,对方很满意

    她过来之后,我希望招聘,培训,日常管理,市场都能做

    但是事与愿违

    也就是几天的时间,人就显出自己的能力了,外强中干的一个人

    平台给了,钱给了,当初谈得很好,就是没有成果

    个位

    这一幕是不是在很多公司,很多岗位都发生

    团队中有人常说这一句:这不应该是我做的

    听到这句话的时候,我已经不能说什么了,长痛不如短痛

    一个人定位自己是某个岗位的人,就会说:这不是我应该做的

    一个人定位自己是那多少钱工资,干多少活,就会说:这个我做不了,我才拿多少钱工资

    这类朋友面试和工作中比较容易识别,就是你和他一沟通,往往能看到的反应就是:他不会或是给他的钱不够,特点就是对工作没有任何特别大的热爱和激情,只是一份工作

    二、来自一个普通二本的普通女孩

    经过太多的打击,我对于招聘来的人一开始不抱太大的希望,都是从普通岗位干起

    但是这位

    的的确确不一样

    本文由彩世界平台发布于活动会议,转载请注明出处:互联网技术员成长日记162-网络程序员的固定

    关键词: