一名运维工程师对运维工作的认知

一名运维工程师对运维工作的认知从毕业之后阴差阳错进入运维这个行当已经三年时间了对运维工作积累了一些认识也产生了一些感情的。借此文章整理下自己之前的经历反思下自己的工作看看能否理清今后的发展思路。什么是运维什么是开发14年毕业至今前后换过三份工作每一次都对运维工程师这个职位有一些新的认识。第一份工作是在一家比较小的安全公司大四实习之后直接转正做工作有老员工带着遇到问题可以直接请教老员工。那时候的工作就是跟着前辈部署一些程序排查下性能问题重启下服务器每天最大的乐趣就是写一点小shell脚本简化下繁琐的工作。所以那时候的认知就是在服务器上执行命令处理问题的就是运维根据需求写代码完成功能和修复BUG的就是开发。第二份工作呢则是进了一家小型的创业公司。作为公司唯一的一名运维工程师并没有人能指导我的工作没人告诉我该干什么怎么干我只知道如果应用系统出了问题领导就会找我。 为了避免系统出现问题影响业务我需要做负载均衡、高可用、监控、制定问题处理的流程规范。这时候的认知变成了运维工程师是保障系统可以稳定的为业务提供服务开发工程师是让系统更友好的给业务提供服务研发创造价值运维避免风险。第三份工作也就是目前的工作 则是就职于某大型电商集团中间件部门DevOps小组重新做回了小小螺丝钉的角色。与之前工作不同的是我们所有系统都是服务于集团内部的研发人员而且很多系统和其它部门的系统之间相互依赖。为了完成工作除了一些技术问题处理更有一部分精力需要花在和各种同事沟通寻求最优解或者双方都可以接受的妥协方案。 这时候对运维工作的理解就是与开发人员一起配合尽可能的给用户优质的体验。So区分运维和开发的并不是工作方式并不是说研发就是一直在写代码运维就是一直在插拔网线、部署程序、重启服务器而是大家的职责不同仅此而已。运维工作真的比研发low吗发现周围好多同事朋友不过运维还是研发包括HR部门领导猎头都感觉运维比研发low相应的同等能力下运维工资貌似也普遍略低于研发这里的运维包括具有一定开发能力的运维开发工程师。认真想了下出现这种现象的原因可能有以下几个1、大部分运维工程师的时间充斥着琐碎事务完全就是一个客服加打杂的工作2、运维工作并不能直接的创造价值3、运维普遍要求24小时on call。 凌晨接到电话时Fuck在心口难开但是这些问题其实并不是没有办法解决的。相信现在很少再有那种单纯的系统运维或者应用运维工程师了大家多多少少都掌握着一两种开发语言。而大多琐碎的事务都可以通过自动化来完成。再有就是现在大多数系统都是分布式的高可用架构只要系统避免到单点故障真的很少有问题需要当晚立刻处理完全可以等到第二天工作时间在进行操作。当然具体操作起来还是有很大难度会遇到各种各样的问题。比如工作被各种琐事填满完全没有时间进行工程性的工作提高工作效率。部门间信息共享不够比如服务器连通性报警对于我们来说单台连通性报警并不是什么大问题但是监控部门的同事会认为比较重要不管几点都会电话通知我们。后来经过和监控部门沟通之后监控部门同意类似问题只通过短信等发送报警不打电话叫醒我们之后又会有部分研发恰巧没睡着看到报警信息之后打电话来咨询这里指大型公司。但是办法总比困难多不能因为这些困难就放弃以更优雅的方式处理运维问题而是直接认定 运维工作比较low。之前我们说了运维只是要保障系统稳定性和可用性和工作方式方法无关。这样看Google的SRE说白了不也是运维工程师虽然没有真正接触过不过看《SRE Google运维解密》中写的还是很有技术含量很高大上的。 那50%的时间分配原则真真让人羡慕。如果排除上述那些因素只看工作本身的话其实运维的技术含量并不比研发低。要保证系统的稳定性、网络协议、操作系统、开发流程规范各种都需要有一定的了解而且可以开发自己的运维平台简化工作自己本身既是开发人员又是最终用户省去了和产品经理及业务方的各种扯皮可以安安心心按着自己的心意创造产品还是很美好的不是吗。如何让我们的工作变得高大上既然有着光明的前途那我们需要怎样做才能过上美好的生活呢作为一个一线基层运维我觉得自身能做的就是学习学习学习。学习专业技能学习如何沟通学习通用技能如英语能力文档能力。提高专业能力你才能实现你想做的运维平台解决你遇到的那些问题。 提高沟通能力你才能让你的直属领导和同事支持你做你想做的事情自动化也好学新知识也罢都需要时间。 提高英语能力可以让你更快的学习专业技能提高文档能力可以让你的工作成果在不同部门之间推广让你得到其它同事的认可。 并且不要放弃任何学习和练手的机会如果同一份工作手动解决和通过编写自动化脚本所需时间相差并不多那一定要选择用脚本来实现多动脑子少动手。自动化运维平台空想没事儿的时候总喜欢瞎想运维平台应该做成啥样趁着这个机会也顺便落到纸面上说不定以后有机会真的付诸实践别到时候再忘了。一体化 既然是叫做平台就应该有完善的功能从硬件资源申请持续集成到监控到批量命令执行failover都应当包括在内。后台可以分为不同的子系统但是用户操作时应该是统一的入口各系统间数据应当共享所有操作日志清晰可审计。少量并多样的交互 交互频率应当越少越好只要有人参与到整个流程当中那处理周期怎么也是分钟级的如果涉及到多人操作可能需要几个小时甚至几天。 理想状态下最好是监控系统发现异常后直接通知异常处理系统进行处理流量迁移故障判断一步到位如果可能最好能直接恢复如果是硬件故障可以直接报修IDC或者硬件供应商。只需要在这一切完成之后给运维人员一份记录即可。不用业务的异常处理流程可能有所不同这一部分最好做成可配置的。有特殊需求的用户可以自行定义异常处理流程。 相反的交互方式应当越多越好手机APP,chatbotWEB页面。自主进化 由于统一了所有操作的入口而且有着完备的数据所以应该能够通过机器学习等方式让平台越来越智能。由最开始的我们指定平台应该怎么做到平台根据实际情况给出处理意见由运维人员确认是否可以进行该项操作到运维人员制定约束避免一些危险操作其余的由系统通过自主的学习来判断应该如何去做故障处理性能调优等工作并具体执行。用户要执行查询等操作时也可以由最开始的命令模式改变为自然语言。《网络安全从零到精通全套学习大礼包》96节从入门到精通的全套视频教程免费领取如果你也想通过学网络安全技术去帮助就业和转行我可以把我自己亲自录制的96节 从零基础到精通的视频教程以及配套学习资料无偿分享给你。网络安全学习路线图想要学习 网络安全作为新手一定要先按照路线图学习方向不对努力白费。对于从来没有接触过网络安全的同学我帮大家准备了从零基础到精通学习成长路线图以及学习规划。可以说是最科学最系统的学习路线大家跟着这个路线图学习准没错。配套实战项目/源码所有视频教程所涉及的实战项目和项目源码学习电子书籍学习网络安全必看的书籍和文章的PDF市面上网络安全书籍确实太多了这些是我精选出来的面试真题/经验以上资料如何领取