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

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

等级与能力

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。

 

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

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