你跟技术专家的距离有多远？
文章来自 DevOps // 欢迎进入本博客网站，本博客专注于DevOps，分享DevOps的干货教程，期待共同学习进步。
主页
|
编程开发
DevOps
运维架构
系统架构
云计算
运维基础
技术管理
|
博客介绍
|
归档
|
标签
>文章转载请注明出处[www.leexide.com](http://www.leexide.com) 希望每一位寻求转载的朋友都能够按照要求进行，鼓励原创，尊重原创。 微信公众号：DevOps运维运营之家 QQ号码：1045884038 E-mail：leexide@126.com 如有问题或建议，请关注微信公众号   ### 1 概述 写下这篇文章，是源于去年年底参加公司大比武的比赛最后的专题讲座：如何成为技术专家？以及网上看到鹅厂对不同级别的技术人员的要求，即职位能力框架。 担任导师期间，在与新同事的沟通中，经常会发现一个问题，就是新员工入职的时候都会给自己定位一个目标，比如成为一名业务专家或者应用系统专家，但在实际的工作中，却发现自己不知道该通过何种途径和方式去实现这个目标。这样的疑问，同样发生在我入职初期。 而在公司的大比武的比赛最后的专题讲座：如何成为技术专家？中，通过与技术专家的头脑风暴，要成为技术专家，需要具有如下的特点： - 技能面广，基本功扎实，一专多能，善于研究，有技术情怀，对产品深层次的机构、产品改进演进有自己深刻的理解； - 有影响力，树立技术标杆； - 具备问题分析的方法及能力，且具备问题全局观，处理问题思路清晰； - 除技术能力强，还应具备良好的沟通协调能力，资源集结能力； - 工作上善于计划和规划，熟悉流程并遵从流程； - 获得内部项目组认可，同时获得客户认可，能够帮助客户解决实际问题； - 传帮带，能够带领团队，并充分发挥团队每一个人的能力； - …… 在我们公司内部，其实对技术人员的职业发展是有明确要求的。在每次的调级答辩PPT中都会写有明确的要求。公司和部门制定这一制度，设定一个清晰的路线图，依此往目标方向发展，这样公司和个人都会达到双赢的效果。只不过大家很少会去关注这些。 一直以来，我都会很积极与我们的系统专家、业务专家、研发专家进行沟通，发现他们在日常的工作中都会有很多的相似点，比如： - 日常运营过程中，对应用系统架构和业务流程有足够的了解，能够根据自己的了解识别应用系统架构中的优缺点 - 对业务指标有充分的认识，了解业务或者架构的性能容量，能根据业务量的上涨趋势提出扩容。 - 考虑业务量增长的时，应用架构是否能够支撑，保证业务的连续性。 - 对平时日常业务运维过程中，所碰到的故障，有充分的总结和深刻的理解 - 对例行化的工作感到厌倦，通过自动化的手段进行改善 - …… 说到这里，再看看鹅厂对运维技术人员的要求，如下图：  大家有没有发现，结果总是那是惊人的相像。那么，如何缩短自己与技术专家的距离或者达到技术专家的目标呢？下面结合我自己的理解，在运维工作中如何达到技术专家的层次。 ### 2 专业技术能力 很多时候，作为一名技术专家需要有个全面的知识积累。就运维技术而言，包括的技术点不外乎如下几点内容： #### 2.1 服务器知识 包括机房的基本认识，服务器的认识，服务器TPMC的认识，存储Raid的知识，系统集成知识等等。比如让你从零开始负责一套系统环境的搭建，你如何去评估需要的服务器数量，多少TPMC才能满足业务需求，集成环境如何搭建才能满足高可用、业务连续性的要求，等等。  #### 2.2 操作系统知识 曾经我以为我自己掌握了Linux的大部分命令，但后来再回去反思，才发现自己理解的还是表面的。比如，在vmstat命令中，如下的输出代表什么含义呢？  这两个值过大或者过小会有什么影响，如果过大需要进行什么样的处理。再比如，top命令的信息量非常大，load average是什么、用户态、内核态、软中断、硬中断又是什么，在这个地方我们可以不断深入探索、层层进行分析，不断给自己提出问题，然后通过日常实践或者网络资源来对照着进行理解。 #### 2.3 业务运维知识 首先，你应该知道我们的业务架构是什么样子的，核心业务的流程是什么样的； 然后，一定要积累你的业务的性能数据，从数据上把握业务的特征，越详细越好。从数据上能看到很多规律，比如说业务压力情况，用户访问规律，数据库压力等等。 最后，对业务运维来说，一定要有自己的思考，我的业务运维到底是做成什么样子是好，什么是不好？自己日常要多思考和总结。 #### 2.4 业务组件 目前在互联网中都有个特点，就是拿开源的软件结合自己的产品业务特征包装成满足自己业务需要的业务组件，比如我们经常接触的IHS，就是IBM通过封装开源软件Apache软件而来的。而这个通过开源软件包装成满足自己业务需求的业务组件并将是一个业界的趋势（可以透露的是，我们下一代的系统也是这样），那么这样就要求我们必须了解不同的业务组件在整个应用系统架构中充当什么的作用。在我日常休息时间学习过程中，对业务组件的学习我总会不断问自己，这个业务组件的应用场景是什么。结合架构或者应用场景进行了解，可以让我们很快了解这个业务组件的作用。 #### 2.5 网络知识 其实在网络方面，我会的东西也不多，因为在大学期间除了应付考试，也不了解这些网络知识的实际应用情况，同时长期从事应用系统运维，而网络这块归属与其他厂商负责，这样也就疏于去理解网络相关的知识，特别是网络规划方面。 不过，结合日常遇到的故障，我觉得我们起码要知道traceroute的原理、tcpdump的原理、ping等等。平时也可以多用抓包工具wireshark去看看抓到的数据包并能进行简单的分析。 #### 2.6 ITIL体系知识 作为一名运维人员，ITIL是必须需要了解的体系，这个体系在运维的很多场景下都非常适用。很多人也许会说，这是一个流程性规范，作用不大。但我想说，从另外一个角度来看，从这些流程出发，我们如何自动化和规范我们的运维过程，还是有些指导意义的。比如说发布管理、配置管理、事件管理、问题管理等等。如果我们可以梳理一个运维主线出来了，基于这个主线，我们可以结合我们的运维实际进行落地。另外随着你对运维的加深理解，也会逐渐去抛弃ITIL的一些流程做法，比如说成本管理、连续性管理等等。那个时候其实更多的思考是技术层面上来如何达到这个目标，比如说通过虚拟化、服务调度来做成本管理。 #### 2.7 运维研发 说到运维研发，很多人都会发出疑问，我们搞运维的，怎么还要研发能力呢？其实，目前在业界中，流行的自动化运维，就重要的是每个运维人需要除了shell脚本能力之外都必须有高阶的运维研发能力，语言建议是Python。平时可以多用它来把自己从一些低价值运维事务的释放出来，比如说做个数据统计、写个小工具什么的。如果更高级的要求，就自己写一个运维管理平台，比如说任务调度系统、版本交付平台等等。 #### 2.8 应用系统架构 在我担任导师期间，我一直跟新同事强调一点，每周必须多看几次应用系统架构，但往往收效很低，甚至一些同事会认为看这个图没什么实在的意义，还不如看看Shell脚本的编写。其实，当你工作几年后，如果还是停留在一条命令的使用，那么基本上技术专家是与你无缘了。 要把自己所学的知识和所理解的业务结合起来，去审视业务架构，多问自己这个业务架构为什么要这么设计？解决了什么问题？有没有更好的办法？ ### 3 通用能力和影响力 #### 3.1 通用能力 在鹅厂的技术能力要求中，对沟通能力，解决问题能力，项目管理能力，学习能力，客户导向都进行了详细的说明，这里就不一一进行展开，但想说的是需要特别注意细节的问题。 在日常的工作经历中，我对自己有一个要求，就是不放过任何细节的地方，比如在整理客户或者领导需要的报表数据时，我一定会要求Excel表格或者World文档的排版必须是最好的。 #### 3.2 影响力 首先，在团队中，影响力很重要。而如何在团队或者项目中具有影响力呢？我认为，当你的技术能力达到一定程度的时候，对周边同事的求助应该积极去响应，而不是一句“这块工作不是我负责的”来回应。 #### 3.3 学习能力 就拿系统linux命令来说，不要做一个简单的使用者，要知道背后的原理。很多人对top、vmstat等命令输出的内容都不能够足够的了解。需要关注背后的原理。 我们还要善于利用公司的知识库。公司的知识库其实总结很多同学的好的经验，把这些经验转换成自己的，是一个低成本的学习方法。同时对技术问题要深入探索，层层分析，尽量不要给自己留下“技术债务”。很多人说，看过了过段时间就忘记了，其实不是忘记了，是因为你只看到了表面，没看到实质。 同时，还要多交流，多向标杆同事学习。在交流学习的过程中，其实会有很多好的idea碰撞产生,然后再去论证idea的可行性，在允许的情况下，应用它。 ### 4 总结 最后，展示一下鹅厂技术专家（鹅厂内部级别为T3）的要求和雷达图。 #### 4.1 技术专家要求  #### 4.2 雷达图  在后续的工作中，希望大家能根据自己的目标，达到技术专家的层面。 下面的是我的公众号二维码图片，欢迎关注。文章转载请注明出处[www.leexide.com](http://www.leexide.com) 
Pre:
Go语言基础05-Go流程控制
Next:
消息中间件MQ概述
Submit
Sign in
to leave a comment.
No Leanote account?
Sign up now.
0
comments
More...
No Leanote account? Sign up now.