如何做一名优秀的运维工程师--职称能力要求解读

[摘抄自"百度运维团队技术博客"]

等级与能力

T4需要具备什么样的能力?

你熟练掌握运维基础技能么?

如(仅举例): SSH的原理是什么?如何保证安全性?什么是非对称加密?什么是中间人攻击?SSH是如何避免中间人攻击的?这个特性对传输正确性有哪些影响?known_hosts和中间人攻击是什么关系?为什么里面写的密钥和我写到远程的公钥不一致?这个密钥又是什么?会有什么影响?

你了解服务么?

你的服务的瓶颈在哪?容量是多少?有多少指标是你关注的,哪个指标现在处于有风险的状态,你的服务器每个时刻都在做什么?能够通过曲线图读出目前系统所处的状态或者正在执行的任务么?常用的模块间的连接策略和负载均衡策略有哪些?每种的优势和缺点是什么?你的服务适合使用哪种策略?

你是一个合格的管理员么?

线上的每一个细节都知道么?有哪些种任务调度的方式?分别适合哪些场景?你的服务是什么样的?有没有重复的代码,和不一致的脚本?举几个例子?你的服务是“干净”的屋子,还是一个“肮脏”的杂物堆?你能给新人讲清楚服务的细节么?你带的新人踩过坑么?

如果上述三个问题的回答是yes。并且能够在你做的运维工作中结合自己的知识能够有效的解决问题。那么你具备T4工程师的能力了。这是一个必要非充分条件!!

T5需要具备什么样的能力?

当到达T4的时候,已经积累的足够的经验,包括在运维技能上的,服务上的,成本和效率上的考虑。

在遇到一个比较复杂的问题上。要能够有自己的思考和分析了。什么样的情况,该选择什么样的方案解决问题。每个方案的特性是什么?不要说你的方案好,这个方案的缺陷是什么?会引发哪些新的问题?引发的这些新问题该如何的去解决?什么时候开始解决?什么时候我的方案已经不适宜了,该被推翻重来了?当你在提出一个方案的时候,能够很好的回答这样的问题。那么你已经具备了权衡的能力。那么说你已经有的经验,你的思维判断能力能够支持你解决比较复杂的问题了。没有完美的方案,如果能够针对比较复杂的问题。采取有效的折中,突出方案的有点,弱化方案的缺点。要时刻记住一点。没有完美的方案。但是有美的、简单方案。如果用简单的、美的、有效的方式解决了问题。能够带领工程师完成工作。这是T5应该有的能力。

以数据存储方案为例。为什么选择左面的方案而没有选择右面的方案。有哪些条件?数据支撑是什么?左边的方案为什么选择mfs,而没有选择hdfs,数据支撑?论据支撑?为什么选择入口服务器,而不是直接mount磁盘,存在的风险是什么?数据是?为什么选择4台入口机,而不是3台,5台?为什么选择lvs,而不是bvs?mfs的副本对下载速率有哪些影响?改选择多少副本?有数据么?整个方案穿透了都少层?哪层会先成为瓶颈?什么时间,达到什么条件,我们可以过渡到右边的方案,前期需要做什么?如果遇到风险我们该怎么办?能够通过有效的方式监测和预知风险么?

T6以上需要什么样的能力?

需要更多的技术积累。积累先进的技术,跨工种的技术。比如:系统底层的原理,如何提高编程的效率,快速实现自己的想法?什么是design?如何做好的设计?我们的测试团队都在做什么?如何保证软件质量?软件质量只是QA的事情么?我们日常使用的运维工具,哪些是合理的?哪些是不合理的?什么样的系统是美的?如何以最简洁的方式解决一个问题?为什么搜索广告是key word->ad , 而网盟是url->key word->ad?研发工程师做的运维方面设计决策是否是合理的?我们的理由上和数据上的支撑是什么?

listhost设计的初衷,设计的折中?有哪些特性和缺点?作者的考虑是什么?如果没有listhost呢?同样的问题,服务树呢?如果你只能告诉我5点,我认为深入思考的还不够。数据传输有哪些种方式,什么时候选择推,什么时候选择拉,之间的区别又是什么?gingko对kfp的改进是什么?gingko和kfp对数据传输脚本设计有哪些影响?

足够的积累+解决问题+影响别人 = T6,T7……

更正一些错误的理解

关于好的产品:

一个成功的产品(系统,工具,尤其是底层的)一开始都是在满足自己的需求。在把自己的问题很好的解决了之后,发现它确实是一个伟大的产品。linux,git,perl,ruby都是这样。当然也不是说不要胸怀大志,只顾解决自己的问题。同样,这也不是一个好的工程师。理想的情况应该是,先把自己的问题解决掉(用功能和代码抽象等等技术),在解决问题的同时兼顾别人对同样的问题的看法和需求。一个工具和解决方案必有它的优势和弱项。如果一开始就想去解决所有人的问题,那必将得到一个毫无特色的,处处充满妥协的产品。最有多问问自己,你有没有“真正”“好”的解决了自己的问题?

为脚本正身:

说道这里,我想说一下“脚本”。“脚本”指的是用python,perl,ruby,shell等语言写出来的工具。在我们眼中貌似成了一个贬义词。一个解决方案如果是脚本的,就会被认为功能低下,无法复用,简单临时的拼凑。(不知道大家是否都存有这样的偏见,但在我周围的环境中是有的)。我想在这里为“脚本”正正身。一门语言,我们不能够简单说他好与不好。不能说c就是好的,脚本就是不好的。关键在于如何使用,在什么场景下使用,写的是一个没有参数处理,没有文档,没有异常处理,没有单元测试的脚本肯定不是一个好的脚本。

破除浮华的“平台”:

“平台”虚无缥缈,只要是工程师工作的”界面”,都可以认为是“平台”,比如linux是一个操作系统平台,git是源码管理的平台。我们对“平台”的看法是偏执的,但我们指的“平台”大多是web的平台,要登陆,有花哨的人机交互界面。但是缺少编程交互接口。部分工程师还引以自豪学会了javascript。但是你的问题是否需要用web的解决方案来解决?能不能用工具就搞定了?如果,我是说如果,必须要开发web,有没有考虑面向资源的web?开发RESTful的web?引入一些框架,提高开发效率。有多少项目大家在排期的时候都是按照半年排期的?原因就是一个web,一个所谓的“系统”。我曾经在主机管理工具中尝试引入rails开发web,2个小时主体的功能就完成了。完成了页面,数据库设计,同时支持API,能够直接通过curl添加、修改、删除、查询。如果必须开发web,那么至少是这样的web。

 

推荐一本小书–“你的灯亮着么?”,中文版已经绝版,这儿有部分中文翻译。主要是教你如何定义问题,看待问题,解决问题,思考问题的奇书。

简短说明:这是一本关于“问题”的书。问题的产生,问题的解决方式,问题的演化等等。从这本书中我学到了:问题不能够被解决,只能够被转化。在我每次遇到问题解决问题的时候这句话都受益匪浅。这是一本建议大家每年都要读一遍的“小书”,每次读完后都会有新知。

你可能感兴趣的:(Others)