我是如何走上运维岗位的？谈谈新人入职运维发展的注意事项

我是如何走上运维岗位的？谈谈新人入职运维发展的注意事项

我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。

聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。

我是怎么开始做运维工作的？

我做运维是在加入华为1年后开始的。在华为内部，我从来没有听说过任何贬低运维的说法，反倒是从华为出来，才开始听到一些言论，比如运维背锅、运维层次低等等，当时感觉还有点怪怪的，这一点下面会再详细讲到。

我当时是在华为电信软件部门，大家熟知的短信、彩信、智能网、BOSS计费系统以及运营商客服系统等都是这个部门的产品。我到公司没多久就进入了一个新成立的项目组，为运营商开发一个阅读类互联网产品，因为是工作后参与的第一个正式项目，从需求讨论、方案选型、代码开发到上线这样一路跟来下，几乎倾注了我所有的热情。当时完全是封闭式开发，除了吃饭睡觉，其它时间基本都用在这个项目上，周六日都是泡在公司的。

项目上线之后，基于运营商海量用户的积累，业务量很快就增长上来了，按照惯例，各种系统问题、故障宕机也随之而来了。当时我们团队规模不大，大家也都是齐心协力，出现问题我们总是一群人一起冲上去解决问题。之所以有这样的反应，主要是因为不忍心看到自己和团队一手打造出来的系统出问题。在华为，软件质量的荣誉感胜过一切。

因为我经验尚浅，所以一开始都是跟在后面看着主管和老员工解决，后来对于一些疑难问题，我就会主动要求接过来研究一下，有时候一个问题要研究好几天才会有些眉目，不过也是在这样的一个过程中，随着解决的问题越来越多，经验也就越来越丰富，很快就成长了起来。

再加上我一直是出现问题后，第一个做出响应和冲到最前面的那个人，主管和团队也对我有了足够的信任和认可，也正是因为获得了这样的信任和认可，后来我得到的成长机会就越来越多。

这里就分享一点：

• 要敢于承担责任，敢于表达自己的想法。特别是对于职场新人，只有承担，且敢于承担更多更重要的责任，才能够快速成长起来。一些重要事项，主管肯定是优先安排最稳妥和靠谱的人去做，这个时候老员工的优势会更明显，作为新人或经验尚浅的员工，如果没有积极主动的态度和令人放心的表现，很多好机会往往就与你失之交臂了。

当时，我们解决完问题，不仅仅是内部解决完就好了，还要给客户汇报。说简单点，就是把问题原因、处理过程和后续改进措施，用客户能够听懂的表达方式讲出来。一般都是先用邮件发送正式的报告，然后再当面做解释和汇报。当客户不理解、不认可的时候，你就要花更多的时间和精力想办法去表达清楚。

说实话，我当时认为这是非常浪费时间的事情，我想要是把这些时间都花在技术研发上该多好。不过，多年以后回过头来看，这个过程对于培养、提升自己的“软技能”是很有帮助的，主要锻炼了以下几个能力。

• 能站在客户对方的角度考虑问题，或者说要有服务心态。很简单的一点，你不能拿着一堆晦涩难懂的技术术语去给客户解释，而是得用客户听得懂的业务语言解释。
• 文字表达和口头表达能力。不论是书面的还是口头的，表达一件事情都要有清晰的逻辑，把前因后果理顺畅，先有结论，然后分条陈述。我现在能写这么长篇幅的专栏文章，很大程度上也是受益于这个过程中写报告的锻炼。
• 从更全面的角度看待问题。有时候有些问题可能不仅仅是技术层面的问题，也可能出在其他方面比如业务逻辑、第三方、用户自身以及信息沟通上。一开始，面对这种问题我都是直接反馈说不是技术问题，跟我们没关系，可以想到这样的回答总是会被客户诟病。慢慢地我才发现，即使问题最终不是由你来解决，也应该全面考虑问题，跟客户一起讨论最终的解决方案，这样才会得到认可。后来我发现这是一个技术人员普遍存在的问题，比如，“我的代码没问题”，“在我的电脑上是好的”等等，其实就是缺乏全面看问题的意识，也是缺少站在对方角度考虑问题的意识。
• 首问负责，问题闭环。问题找到你，你就要端到端负责解决，最终要给客户一个满意的答复，即使问题解决不了，也要能够获得客户认可的反馈。而且，如果这个事情是比较复杂的，需要时间和一个过程来解决，一定要在过程中及时反馈，而不是迟迟不响应。一个最常见的反模式就是“这个跟我没关系，你去找谁谁谁吧”，一句话就把客户的满意度给消磨没了。

这么多年工作经历下来，我感觉对我个人职业发展帮助最大的，恰恰是上面这些良好的工作习惯，没有这些好习惯的扶持，单纯的技术技能成长很容易遇到瓶颈。而且，如果说技术技能是在不断更迭变化的，上面这些做事的基本原则却可以随时随地迁移使用。趁早养成良好的职业习惯，会对个人发展有巨大的好处。

对这个阶段做个总结，我更愿意承担一些非常具有挑战性的工作，成长得就比较快。同时，在客户层面，我又相对比较愿意表达见解和意见。虽然那个时候没有什么沟通技巧，也没什么表达技巧，甚至有些时候是笨嘴拙舌的，但是，很多时候技巧是次要的，最关键的是要敢于表达，当团队需要这样一个角色时，是不是有人能够站出来承担起这个职责。慢慢地我在客户层面也得到了一定的认可和信任，成为一个真心诚意、关键时刻能靠得住的一个人。通过这样一个阶段，我不但在技能深度上有了积累，在广度上也体现出了明显的优势。

我为什么会把运维当作职业发展的方向？

这个阶段大约也就1年左右，我的主管就开始跟我沟通，由我来组建这个产品的运维团队，把线上运维、稳定性和部分客户沟通工作完全交给我。

可能有些人觉得做运维是很低级的事情，让你做运维就是让你去填坑，其实对于这样的言论以及今天开头提到的什么运维背锅论，我是十分反对的。当然，更多的时候我也不是去解释，而是靠做事情来证明。

说回到当时的事情上，当时主管在跟我沟通独立带一个运维团队时，我的感受不仅仅是晋升层面的喜悦，更多的是因为能够做运维而感到非常自豪。

为什么会非常自豪，这就不得不提到华为内部，在当时来讲，就已经有非常完善和先进的运维体系和运作机制了，我们一起来看一下。

在华为内部，运维是非常受尊重而且非常关键的岗位。如果你在研发团队中一直写代码，没有做过运维工作，是很难晋升高级别岗位的。

所以华为的架构师、技术经理甚至是更高级别的研发主管，按照不成文的规定，都默认要在运维团队轮岗过，然后再选拔出来。而且这里面最最关键的是，运维这个岗位不是你想做就能做的，是有条件要求的。

下面我们就来看看有什么样的条件要求。我当时是在华为电信业务软件部，华为的运维体系分为一、二、三线，我们分别来看。

一线维护

这个团队是负责产品的交付服务和后续的客户服务工作。从技能上，很像传统运维，主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理；另一方面，也是非常重要的一点，要对一线客户满意度负责，也就是客户反馈的所有问题，甚至是客户工作中表现出来的喜怒哀乐都要关注。

一线维护，最重要的就是必须要有非常强的服务意识。

二线技术支持

因为一线维护面对的是单个具体的运营商，在遇到一些问题的时候，往往没有经验，但是二线因为要面对某个产品全球的局点问题，所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时，二线有可能就可以很快很好地帮忙解决，而不用直接透传到三线。

同时，二线还要做好统筹协调，因为一线过来的问题不仅仅是产品本身问题，也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题，这就需要二线帮助一线协调专家资源进行处理，而不是一线再一个个找人，这时一线只管反馈问题即可。

二线技术支持，大多由产品研发或者一线维护经验的人员抽调上来的，即使没有这些经验，也要下放到一线去锻炼很长时间，两三年都有可能，所以技术和经验上都相对更加全面，同时能够有较强的推进协调能力。

三线研发维优

到了三线就是研发团队中的运维团队了，这个团队在华为叫做维优团队。这个团队就很牛了，一般都是从开发骨干精挑细选出来的，一方面是为了锻炼人，另一方面也是为了在出现问题时，能够有最专业、能力最强的人响应处理，因为电信级业务是国计民生的基础设施，一般传递到三线的问题，都是比较严重或者疑难的了，必须投入精兵强将第一时间解决问题。

处理问题的过程中，还会不断完善工具体系，提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题，所以7*24响应，而且常年无休，比我们现在互联网运维的工作负荷要大得多，所以这个团队成员一般做个1~2年就会转岗晋升，不然身体肯定是承受不住的。

三线研发维优，这个团队的成员就像军队中的突击队或尖刀连一样，总是冲在最前面，在高压状态下，解决最复杂、最棘手的问题，所以从选拔阶段，就有非常高的要求。最终经过这个团队磨练出来的人，技术能力、沟通协作能力以及全面解决问题的能力，都是非常突出的。自然地，在晋升发展方面就会有更大竞争优势。

上述这样一个非常严密的一、二、三线运维机制和协作体系，各条线各司其职，发挥各自优势作用，串联起了客户、产品和研发整个技术支持体系，基本上就支撑起了华为电信软件在全球局点的技术支持和服务工作，这一点还是很强大的。

也因为各自都有独特的价值体现，所以运维岗位上人员的存在感和成就感就会比较强，当然就不会觉得做运维是很低级的事情。同时，因为人员非常优秀，能力突出，这个岗位得到尊重也是必然的，甚至是令人向往的。

其实，能够得到尊重，还有非常重要的一点，就是来自华为对客户和用户的尊重，真正的把“客户第一”融入到了整个公司的组织架构和运作机制中。

这里我们不做过多发散，理解下来就是谁离客户最近，谁对客户负责，谁就能代表客户，谁就有最大的话语权，甚至是指挥权和决策权。体现在上述我们所说的运维机制上，就是：一线的声音，代表了客户声音；一线反馈到二线的问题，二线必须响应；二线传递到三线的问题，三线必须响应。

当然，问题级别不同，响应效率可以不同。同时，三线可以根据客户现场情况，以及问题严重程度，对问题进行升级，以知会到更高层级的主管进行关注。

在考核上，如果一线提交的问题，最终被定性为二线支持问题，或者三线研发质量问题，那二、三线的全年考核将会受到影响，如果是频繁出现问题，那就会受到严重影响，而且各级主管要承担连带责任。

这套机制的根本目的，还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念，就自然会对质量和问题有敬畏感，研发维优那个时候大多都是远程电话与一、二线沟通，潜意识里就会把一、二线作为他们的客户，同样保持谦卑和尊重。

所以，无论是从对运维的定位上，还是整个公司文化以及运作机制上，都形成了对这个岗位的高度定位和尊重。

说回到我个人，因为当时项目性质的原因（前面提到本质上是一个互联网形态的项目），是高度定制化的，并不是传统电信业务的产品形态，所以当时我们无法直接获得一、二线的支持，所有的运维工作都由研发团队完全独立承担，当时我就是把一、三线的事情都做了，前面很长一段时间是既做开发又做三线维优工作，对我技能上的提升帮助非常大。再往后因为精力有限，在后端维优团队建立起来之后，我就花更多时间做一线工作，贴近客户多一些，这里就对我之前说的职场软技能的提升有很大帮助。

当时华为的三线研发维优，其实很像Google的SRE岗位，各方面能力要求很高，不仅仅是软件开发这么简单，所以当时让我去做运维，并且给到我足够的授权去组建和带团队，就相当于让我去做SRE这样高端的岗位，我自然会觉得非常自豪。

再往后，在这个专业方向上做精做细，形成差异化的优势，自然就会有更大的收获。

给我们的一点启发

这样的一个发展过程并不是我刻意设计过的，机会也不是刻意争取到的，就是平时多做一点，做得认真一点，确保最终能够拿到结果，而且稍微努力一下，尽量拿到比预期好一些的结果。

在这个过程中，随着个人能力的提升和全面发展，后续各种机会也就随之而来了。

如果让我总结就是这么平淡无奇，如果让我给出个人发展建议，想要从普通做到优秀的话，就是上面几句话。

岗位上，可能不会跟我一样去做运维，但却一样可以做到优秀的架构师、技术专家、项目经理或产品经理等等，只要你有心即可。

精选提问

1. 大部分的程序员都局限于技术开发范围，对于产品的责任心和认同感并不强，常见的说辞是出于明确的职责划分，但更多的原因来自于团队文化的影响。而对于产品的开发，很少有团队能有合理而明确的职责划分，大部分都是基于传统开发领域的认知，对于职责的边界划分其实都含糊不清。尤其在小的团队中，运维的职责可能落到项目管理者或专职的运维人员身上，其他开发人员的参与度不够，自然就不对线上和客户有多少的责任感，如果能让这些人员也参与进来，那么所有人的能动性应该会有所提升的。

   责任可以有边界，但是做事不能有边界，你的我的分太清楚了，有时候事情就没法做了。
   

2. 表示身同感受，选择了就把他做精做细形成差异化，职场越往后软技能和Owner精神很重要，做事不设边界对不确定的事情保持乐观；很认同轮岗或到一线体验，但很多公司很难有这样的机会。我们遇到人员骤增导致生产力严重下降的问题，往往都为了甩锅撇清干系，哪怕是一个非核心的小问题也要花费很大的时间精力沟通或公关，反过来受影响的却是用户，时间久了就形成了很不好的习惯和文化，没有大公司的命却得了大公司的病，赵老师有好的建议吗？

   团队氛围和体制上的问题，只能在氛围和体制上改进，我也没有太好的办法。
   
   不过对你个人来讲，可以坚持你认为正确的做事方式，不必去纠结非常细致的责任问题，这样你看问题会更全面，对你个人成长还是有好处的。
   
   最后，完成工作的基础上，一定要关注个人成长。
   

3. 态度决定高度

4. 前几个月我还有过类似的疑惑，那段时间我在公司是兼做开发和运维。做了比较长的时间业务开发，和一小段时间的运维，隐隐约约觉得运维相关的活给自己带来的挑战更大。但是和一个主要做运维，偶尔做些许开发的同学沟通，他却说运维太low 了。

   这里面我相信有一些原因是各自有各自的舒适区，对于自己比较熟练东西，可能会主观的认为没那么难。但是，客观的层面，我觉得运维确实有一些工作，会对工程师个人能力的要求更高，同时也会给工程师带来更快的成长。尤其是一线业务的线上运维工作。

   对于想要成为一个合格的Backend架构师的我来说，运维岗位的锻炼是不可或缺的。

   加油，只要你有心！
   

标签：三线,运维,职运维,问题,华为,客户,注意事项,团队
来源： https://www.cnblogs.com/passzhang/p/13363235.html