【扯淡篇】从运维职级面试看运维能力要求

前天在51CTO群里面，大家问我运维知识地图的问题，我想到了一篇文章。这篇文章是在去年公司运维通道面试，自己作为评委参与了整个过程，然后写了一个总结发表在运维知识库，虽然是建议未来的运维职级晋升者如何应对（类似攻略），但其实看到的是对运维人的要求，供大家参考~

这次很有幸作为运维线的通道评审，参与部门整个职级晋升的面试过程，三天下来，我感觉自己的收获非常的大。因为从其他几位评审和各位参加通道晋升的同学们身上，的确学到了很多东西。但此文是不谈自己的收获，而是谈一些关于职级晋升的经验，总结出来供大家参考一下。

首先还是得说一说这个职级晋升的目的。个人理解，其实是公司和部门制定这一制度，想对大家的成长负责，设定一个清晰的路线图，依此往目标方向发展。从另外一个方面来说，公司把职级晋升和部分利益挂钩，其实是为了更好推行这一制度，从而驱动公司整个人才建设及个人成长进入渐进式的正循环中。当然这次从申请的数量来看，说明大家对于自己成长的诉求还是非常强烈的。其实成长是属于自己的，自我驱动会是最好的结果。

其次也谈谈在面试过程中，看到的一些问题。比如说面试者紧张、自信心不足；技术细节深入不够；有些同学存在偏科现象，对职责范围之外的运维关联知识或者业务的了解不多；业务运维的理解和思考不多，没有和业界去对齐；工作成绩不够突出，除了维护业务之外，没有更多的成绩支撑。针对这些问题，后面会谈谈个人的一些看法。

也不得不说我们公司的通道评审要求挺高的，技术能力、业务运维能力、项目管理能力等等多方面提出了很多明确而细致的要求。既然通道有明确和细致的要求，个人认为还是可以总结些方法来应对，以下就从面试中和面试前两个阶段来做个经验分享。 1、面对这次面试，你是否做了充分的准备？ A、注意点 •你是否有信心去面对这次机会 •你对你提交的资料是否有认真的梳理，以便说明自己过去的成绩和表现 •对相应职级的能力要求的技术点是否有做些准备，比如说再去重新去看一下相关的书籍或者网上资料 •对提交的评审资料中涉及到的业务、项目、故障及优化事件，你是否有清晰和深刻的理解。 •你是否对你要提交的面试PPT有认真的准备，比如说从哪些维度来介绍自己、哪些内容需要重点突出。 B、措施和建议 •面试之前把PPT内容和提交的材料在review一次，熟悉其中的细节。 •主动找你的leader和组内的其他资深运维同事，让他们给你一些通道的经验。 •邀请你的leader或者组内的其他运维同事，做一到两次模拟面试都是需要的。 •主动去了解每个通道评委的特点。其实在面试的时候，是有职责划分的。

其实不关你们需要准备，评委也在做大量的功课进行准备。

2、关于面试技巧 A、全面准确的展现。总的来说，既不能低调，也不能浮夸，实事求是的展现自己。 •呈现过去的自己，让大家了解更多一些。以timeline的形式来陈述自己过去的经验，简明扼要。 •在公司的职责经历。维护了哪些业务，承担了什么职责。 •自己的价值体现。可以把自己上次通道面试到当前的贡献呈现到一些具体的运维价值层面，比如说业务优化、项目建设、技术理解、成本优化等等。 B、自信，轻松。一个自信的面貌可以让你的表现会更好，比如说声音大一些，表达语气轻松，也要清晰条理。 C、扬长避短。从技术的维度要求的话，大家很难做到全面，并保证每个点深入，特别是团队的分工越来越精细的情况下，更难达到。但我们可以做到某些方面的专家。既然网络我不知道，但我是否有自信可以告诉评审，我们在应用相关的一些方面是专家，比如说业务优化、系统优化、应用优化等方面是专家（注：这个地方一定要和工作相关）。

D、其他的更多都是自己平时的积累。 3、过去的积累沉淀非常重要 参加面试的人千万不要以为，在面试前通过一些准备就可以应付得了。刚才也说了，其实这个成长是对自己的负责。另外随着通道能力的要求越来越高，通过准备来应付我相信是不可能的。那么我们日常的沉淀到底应该包含哪些？

A、知识点 •你对你运维的业务架构是否足够的了解，并能够识别架构中的优缺点 •你对你运维的业务指标是否有足够的了解，并了解它的性能容量 •当你的业务再放量增长的时候，你觉得你的架构是否能够支撑 •你对业务运维是否有足够的认识。一定要有相应的认识和理解 •你对平时日常业务运维过程中，所碰到的故障，是否有充分的总结和深刻的理解 •你是否对例行化的工作感到厌倦，并通过自动化的手段来改善它 •你是否对日常运维过程中涉及到的linux系统的知识有全面的归纳整理。就拿系统linux命令来说，不要做一个简单的使用者，要知道背后的原理。从这次面试的情况来看，很多人对top、vmstat等命令输出的内容都不能够足够的了解。需要关注背后的原理。 •你是否对日常运维涉及的网络知识有持续的学习。这一点要着重提醒的，因为业务运维同学日常运维的过程中，都去关注业务层面的知识了，很少去关注网络的内容。其实对于一些主流的协议，还是需要掌握，否则但一个故障产生的时候，你抓包之后，没法通过特征看问题。 •你在日常的运维过程中，是否留给自己时间关注新技术的趋势。个人认为新技术带来的驱动力非常强，大家都愿意尝鲜。 B、措施和建议 •善于利用公司的知识库。公司的知识库其实总结很多同学的好的经验，把这些经验转换成自己的，是一个低成本的学习方法。 •对技术问题要深入探索，层层分析，尽量不留技术盲点。很多人说，看过了过段时间就忘记了，其实不是忘记了，是因为你只看到了表面，没看到实质。 •挑选一个重复性的工作，然后不限语言来来改进它，从而降低你或者团队的运维成本，也加深你对自动化运维的认识。 •加强对一些协议的学习，比如说http协议、dns协议、TCP/IP、icmp、VRRP、ARP等等。TCP/IP协议这本书一定要仔细的看，RFC公布的协议也需要深入了解。另外必须通过抓包，加强对这些协议的可视化理解。 •养成勤于思考的习惯。对自己、对团队、对部门的工作，你都可以思考一下，无论深与浅，都是自己的一份认识。我的习惯是把这类思考和优化点都记录下来，以便放到下一个KPI指定工作中。 •多看看一些好的技术网站和牛人博客，关注一些新技术，并实际的测试它，如果有机会，最好能应用它 。 •多交流，多向标杆同事学习。在交流学习的过程中，其实会有很多好的idea碰撞产生,然后再去论证idea的可行性，在允许的情况下，应用它。

4、影响力非常重要 A、涉及面

•在【影响力】这本书讲到了多种影响力武器：互惠、承诺和一致、社会认同、喜好、权威和稀缺

•大部分我们都想到了权威或者互惠，很多时候忽略了其他的因素。

•在小组内、部门、跨部门的影响力

B、措施和建议

•在支撑业务运维的过程中，是否有提出原生的解决方案去优化业务，可以结合一些运维的成本、效率、用户体验优化等维度来度量这个优化效果。如果取得不错的成效，更好的影响力是让这个方案具有推广效应，这是影响力扩展的很好形式。

•是否有参加部门的TPG项目组或者自己去试验一些新技术方案，通过自己的技术预研，输出一些技术分析报告、现网使用的可行性报告，当然最好的效果就是应用到现网。

•平时多参加部门的知识分享，多参与部门知识库的建设。

•需要带领新人帮助新人成长，扩大在新人中的影响力。

•在一些项目类的工作上，能够很好的规划、推动、管理整个过程，协调相关干系人朝着一个目标前进，这也是影响力的表现。

5、个人能力的全面平衡，不能瘸腿太厉害。 很多时候，需要你有个全面的知识积累。运维技术知识、业务运维相关知识、软件知识、网络知识、ITIL体系知识等等。 从运维技术知识来说，你需要了解如下维度：

A、硬件知识，比如说CPU的知识、SSD的知识、raid的知识等等。

CPU的知识，可以深入了解一下intel系列不同的cpu架构上的差异，纳米工艺的差别，频率的差异，ticktock机制等等。说到SSD涉及的点就非常的多了，SSD的硬件特性、以及它和硬盘特性的差别，SSD的存储技术了解、SSD结合应用如何优化等等。到RAID这块也是同样，要了解各种raid卡的特性，以及各种raid下的原理、性能表现等等，甚至一些新技术的使用，比如说防止数据丢失采用ssd做raid卡缓存，采用fastpath提高raid卡的性能等等。其实说到硬件还有很多，大家都可以在平时接触的过程中，多从业务的角度思考一下。最重要的是能够按照业务的特点，自己做一些硬件选型判断。 B、业务运维知识 从通道的要求来看，其实能看到不同的层级对运维的要求是什么样子的。但我觉得这个地方需要着重强调三点。 第一、你的业务架构是什么样子的，你必须要了解，否则很容易被pk。比如说让你描述现状，说出优化的方案。最好还能了解一下我们核心业务的架构，比如说中间件； 第二、你一定要积累你的业务的性能数据，从数据上把握业务的特征，越详细越好。从数据上能看到很多规律，比如说业务压力情况，用户访问规律，读写情况、cache命中率情况等等。 第三、对业务运维来说，一定要有自己的思考，我的业务运维到底是做成什么样子是好，什么是不好？自己日常要多思考和总结。 C、软件知识 可以分成两个方面： 第一、操作系统。首先一定要找一本经典教材看一下，我的推荐是塔嫩鲍姆《操作系统设计与实现》。大家一定都有一个体会，在大学的时候看操作系统感觉不好，但是现在在回过头去看，会有很多体会；其次在回到操作系统日常使用层面上。那些命令（top、iostat、vmstat）的输出，要清楚的知道每个命令的输出含义，要追根溯源。top命令的信息量非常大，loadaverage是什么、用户态、内核态、软中断、硬中断.这个地方可以用到我之前提到的深入探索、层层分析的方法来给自己多提一些问题，比如说中断/异常/系统调用之间的区别；在我们的服务器环境中，软中断/硬中断与网卡的 bottom half/top half的区别是什么？有了网卡的上下部分，你就会了解网卡处理包的处理方式以及如何达到应用协议栈的?........会有一堆的问题出现，可以通过网上的文章和操作系统的书来对照理解。 第二、组件层面的。这次面试发现一个共性的问题，是大家对数据库的掌握，都不深，当然一些同学做过系统研发的除外。建议这块还是要找一些mysql基本的书籍看看。对于初级运维的人来说，看一下mysql 的manual手册或者《SQL必知必会》，基本上在sql层面上去使用都没有问题。从高级运维的要求来说，《高性能mysql》是必读的经典书籍，swartz是mysql领域的专家人物，他写了很多mysql方面的性能优化文章，非常的深入，另外现在网上mysql的分享特别多，都不要有意跳过。

第三、架构层面的。还是要把自己所学的知识和所理解的业务结合起来，去审视业务架构，地方运维的全面性会是一个很大的优势。另外平时要多看看各个分享大会上的一些架构分享，学习一下别人的经验，他的业务架构为什么要这么设计？解决了什么问题？但你的业务碰到类似问题的时候，其实解决方案业界已经都有了。 D、网络知识 其实网络也是我的一个软肋，因为长期从事应用运维，之前在腾讯，网络基础设施建设离我们非常遥远，公司也在倡导服务化的理念，所以很多时候也就疏于去理解网络相关的知识，特别是网络规划方面。不过在UC，网络离我们很近，是一个非常好的近身学习机会。 除了网络底层建设方面的知识之外，建议在此之上，基于《TCP/IP协议详解》这本书，深入了解主流协议，比如三层、四层以及一些主流的应用协议，另外和操作系统的学习方法类似，也要结合日常的一些使用来看，比如说traceroute的原理、tcpdump的原理、ping等等。平时也可以多用抓包工具wireshark去看看抓到的数据包。 E、ITIL体系知识 其实在非专业层面上，我看通道体系里面有时间管理和项目管理方面的能力要求，这方面的能力培养个人觉得更多的只能通过项目来培养，然后强制自己使用一些时间和项目管理的工具，避免项目过程失去控制。 这个地方我也要强调一下大家可以熟悉一下ITIL的体系，这个体系在运维的很多场景下都非常适用。很多人也许会说，这是一个流程性规范，作用不大。但我想说，从另外一个角度来看，从这些流程出发，我们如何自动化和规范我们的运维过程，还是有些指导意义的。比如说发布管理、配置管理、事件管理、问题管理等等。其实给你梳理了一个运维主线出来了，基于这个主线，我们可以结合我们的运维实际进行落地。另外随着你对运维的加深理解，也会逐渐去抛弃ITIL的一些流程做法，比如说成本管理、连续性管理等等。那个时候其实更多的思考是技术层面上来如何达到这个目标，比如说通过虚拟化、服务调度来做成本管理。

F、运维研发

每个运维人需要除了shell脚本能力之外都必须有高阶的运维研发能力，语言建议是python。研发能力是运维想象力的翅膀，平时可以多用它来把自己从一些低价值运维事务的释放出来，比如说做个数据统计、写个小工具什么的。如果更高级的要求，就自己写一个运维管理平台，比如说LVS、运维发布平台、CMDB什么的。

G、DevOps

DevOps从09年左右出来之后，一直在发展变化，特别是云计算发展之后，其呈现加速度的发展，运维应该多去深入了解其理念，甚至是背后的一些技术思路。

************补充一句，建议大家的学习状态“如饥似渴”一些，不要浮于表面，多思考和总结***************

附：

1、腾讯公司最新版的业务运维的能力要求，供大家参考！

2、应用运维高级工程师的能力雷达图。在腾讯每个能力方向（比如沟通能力）上都分了4个Level，不同的Level有不同的能力要求。