工程师的自我突破

写在前面

第一次写非技术分享的话题，而促使我提笔的动力源自去巴黎参加Openstack Kilo Design Summit大会之行，我被许多外国工程师的对于技术的执着精神感动不已。在本文中，我想探讨的是如何实现工程师的自我突破，因为初入茅庐的工程师更关心的是如何从一个菜鸟成长为某个领域的专家。那么这个关键的突破点在哪?

Emilien Macchi

故事从一年前说起，我正在参与Puppet-Openstack社区开发和代码审查，来了一位名叫Emilien Macchi的新面孔，他持续地向社区提交了大量高质量的patch，我开始关注他，了解到他是eNovance公司(年初被RedHat收购)的一名Openstack开发工程师。他非常积极主动，我和他在Gerrit和IRC上有过许多交流。

后来他加了我的Linkedin，于是我随意瞄了一眼他的profile，非常翔实的简历，给我的第一印象很是惊讶：任何人都可以迅速了解他从07年到14年专业上的经历包括专业技能，参与项目和荣誉证书。甚至同事和上级对其工作的评价都能一览无遗;

一番浏览后仍是更多的惊讶：Emilien是在12年底才开始接触Openstack，他之前工作经验是做网络设备维护方面的，虽然一堆网络相关的证书能证明他的专业性，但突然转换方向从零开始接触Openstack?

Emilien在12年开始了解OpenStack后，13年开始专注Puppet和Openstack相关的自动化部署工作。我记得在HongKong Design Summit上，他并没有参与太多的讨论，而在时隔一年后，在Paris的Design Summit上，他不仅主持会议的Agenda，更重要的是他在社区做出的很多重量级的贡献被大家认可，虽然他的语速很轻缓，但他的发言却变得掷地有声。

(图为Emilien Macchi在主持Puppet-Openstack Kilo Design Summit)

一个完全没有Openstack项目经验，一个完全没有Python和Puppet语言基础的网络工程师如何在这么短的时间内实现自我突破?

会议当天刚好是他生日，会后我送给他一个从国内带去的小礼物，我好奇地问他：Hey, How do you make it ?

他腼腆地对我笑：I write puppet codes except eating and sleeping.

Wow.我和边上的人都在惊叹。

他走后，我站在法国国际会议中心的Room 101门口思考了好久。

故事到此就结束了，细节可能远不止我所了解的这些，但Emilien却勾起了我的思索：工程师如何去摆脱固定思维的束缚，突破自我?

态度决定一切

记得在刚进入Sina云计算部门的时候，团队协作平台的副标题是28号加粗的一行文字：Develop is not easy。虽然不知道是哪位大牛写的，直到现在我仍然记忆犹新。Develop不光狭义地指开发，而是囊括了所有的技术岗位，我们要时刻清晰地认识到把事情做好并非易事。这里不仅指技术本身，还涉及许多相关的细节，这些细节常常被多数工程师忽略，而正是这些细节才能体现出一个工程师的闪光点。

细节是由你的态度决定的。有句老话叫作：态度决定一切，你的态度如何，在一定程度上已决定你是失败还是成功。我觉得这点在做技术时体现得淋漓尽致，就以Openstack项目为例，在其中发现一个bug，其实不是难事。那么在发现某个Openstack服务的bug时，不同的工程师有着不同的态度：有的人随意Google一下找到解决方法然后接着干活，有的人尝试阅读源码后去自行修复bug，有的人会把写好的bugfix尝试推送到社区的upstream去。我们都会以工作太忙为理由，只以问题的解决作为目的驱动，从不去细究问题的源头。因此，这就导致了若干年后，有的工程师还只在原地踏步，有的已经不仅深入掌握源码，还能快速地做二次开发，还有的人不仅养成了良好的代码风格，还能积极地参与到upstream的开发中去。

所以我会喜欢用“业务素质”来评论一个工程师：这个工程师的业务素质很高指的是他不仅在专业技能上出类拔萃，更重要的是在做事上非常认真，事无巨细：小到代码格式，注释，变量名称，代码提交信息，文档等，每个细节都能体现出其难得可贵的认真精神。凡是做过技术的朋友应该都会有所共鸣，应该能跟我一样立马脑海中会浮现出那些闪闪发光的人名来吧。

你的心灵鸡汤

保持努力

在中国我们从小就被灌输“努力”的重要性，在努力这一点上，不用我来举例来说明努力是你将成功多重要的因素。但是我想说的是：在正确技术突破的道路上，你必须不停地更新自己的知识和技能，才能越走越远。

又想起我的另一位朋友，社区核心开发者，当我询问他圣诞节打算去哪里过时，他给我的回答是：I’m not going anywhere, just writing codes at home.所以，那些外国工程师之所以如此牛逼，并非他们生来如此，而是他们的不懈努力。

所以请一定要做到保持这份干劲，并且时不时来一些心灵鸡汤激励自己，就像老罗所说：恶心一下自己，保持大脑亢奋。现在我脑子里只要一想到Emilien的那句“I write puppet codes except eating and sleeping”，就开始失眠，这鸡血的剂量使得我的生物钟又延时了一个小时。

充满热情

从我所了解的出色的技术人，他们都有一个相同特点：富有激情，他们总以一种积极主动的态度去对待生活和工作。我相信所有刚入IT行业的同学们都是满怀对于未来的憧憬，只是这种弥足珍贵的热量很容易被许多外界的负面因素慢慢磨灭：工作单调乏味，生活压力太大…但不要因此就把你的热情埋藏起来，一旦你习惯了埋藏，你就慢慢会变成一个了无生气的人。

如果你失去了对于追逐技术的热枕，那么很难在技术的道路上有所突破。激情，在很多时候，往往能点燃我们创新的本能。有了激情就有了不竭的动力，你的内心同时也会变化，越发有信心，别人也会逐渐认识到你与众不同的价值。

善于沟通

工程师们常常把精力放在编码上，而很少去关注自己沟通能力的培养。我曾遇到过一些大牛，有的不屑写文档，有的不会用git等团队协作工具，还有的连话都说不清。不能否认他们在自己各自的领域中耕耘得很深，但是在分工如此细化的时代，大多数项目都需要团队协作才能完成，因此沟通是无法避免的：产品经理和设计师之间的沟通，后端组和前端组之间的沟通，研发部和运维部之间的沟通…这就是为什么有时候对方听不明白我们想表达的意思，导致跨部门的工作步履艰难。

TED上有个有趣的演讲题目叫作：怎么说话人们才听?声音学专家朱利安给我们上了生动的一课，列举了为什么没人愿意听我们说话的原因，关键所在就是：我们在与别人打交道的时候，我们必须明白对方在想什么，也要让对方明白我们想表达什么。

除此之外，对于工程师而言，沟通能力并不局限在语言沟通上，还有在协同开发时的沟通，例如对于使用git做版本控制的项目，若是没有掌握好git工作流，沟通将异常困难。代码审查系统上的交互，也是沟通方式的一种，你需要理解他人给你的意见，你能够向他人表达清楚你的意思。

成长无需设限

了解自己

在大学课堂里，工作面试和入职培训时常常能听到一个词“职业规划”，就是对职业生涯乃至人生进行持续的系统的计划过程，它包括职业定位、目标设定、通道设计三部分内容。职业定位主要是指：一是确定你是谁，你适合做什么工作;二是告诉别人你是谁，你擅长做什么工作。人生是应该有一个规划，这样可以对于未来设立一个期望，明白前进的方向。但这类职业规范往往过犹不及，觊觎通过把自己的人生画在纸上，然后按图施工的想法是不切实际的。

仔细想想，你真的能在刚踏入社会时就能透彻了解自己擅长做什么工作，适合做什么工作?

乔帮主说过一句话：“如果你了解自己，能够明白地做自己，职业规划如同虚设”。所以，你只要清楚自己想要什么，然后朝着这个目标去做自己想做的事，就可以了，为什么要给人生设限?何不尝试一下跨界?

我的团队故事

前文中我谈到了一个网络工程师的华丽转身，接着聊一聊我们运维team从UnitedStack刚成立伊始到现在发生的一些故事。

从理想国际大厦走出来开始创业的第一天，一个现实摆在了我们面前：采购服务器和交换机，选择IDC。在新浪，服务器选型有专门的部门做，采购硬件有专门的部门做，交换机配置有相应的部门做，服务器上架有相应的部门去做，我们只有基础运维和业务运维的经验，原先所擅长的只是一个狭小的领域…

看来唯有自己动手，才能丰衣足食，我们着手开始调研服务器的选型，交换机的配置，IDC的选择。通过不断的摸索，现在我们制定了一套成熟的机制去根据不同业务来选型服务器，形成了一套完善的网络拓扑去连接分布在全国多个机房的公有云和托管云集群，也有了稳定的IDC合作伙伴。

许多朋友可能还记得UnitedStack去年发布的UOS 1.0发行版，其后端代码完全由运维组编写。当时，我们转身从运维变成研发，调研了主流的StackOps, Fuel Web，根据产品设计的需求，开发了一套由Python+Puppet编写的后端代码，实现了Openstack集群的自动化部署;内部的持续集成&持续发布系统也全由运维组负责，我们根据研发工程师的实际需求对持续集成工具链做了多次整合以匹配整个研发体系的日常工作;14年初公司业务开始涉足公有云和托管云，我们和研发部门共同设计了公有云，托管云的整体架构。由于业务量的急剧上升，我们着手开发了资产管理，节点管理等多套运维平台。同时，和一般的运维团队不同，我们还负责虚拟服务器的镜像自动化制作和维护，参与Openstack最庞大的计算项目Nova的定制开发并一直保持与社区upstream同步，参与puppet-openstack社区的开发，一直在向社区贡献源码。

因为我们清楚所做的一切都是为了能把“事”做成，因此做什么并不重要。而且通过这两年的磨练，我们在技术上最大的收获在于大家的视野不再局限于各自的一亩三分地里，在面对新问题时，可以站在不同的角度去思考，这种在大公司里无法获得的经验就显得弥足珍贵。因此了解你自己，明白你自己想要什么，然后把握好方向。

全面？专精？

以部署系统为例，早先的部署系统针对公有云设计，只要求做到细粒度控制，而现在要用同一套部署系统同时管理公有云和数量庞大的托管云集群，并且每家在架构上都会有所差异，这就要求部署逻辑解耦，灵活可变，支持不同环境，不同拓扑，不同软件栈，还要解放实施人员，降低软件部署时间。

但由于每个人的精力都被分散到多个领域，因此很难集中精力把部署系统做好，于是我们开始从多面手向专一转变，避免自己走向迷茫：自己什么都懂，但又什么都做不精。

那么问题来了，学技术到底是…到底是精通一种还是全面发展好?

Take it easy，在技术的道路上看似会有两种截然不同的方向：横向扩展和纵向深入。横向的犹如瑞士军刀，十八般武艺样样精通;纵向的是削铁如泥的倚天剑，倚天不出，谁与争锋。横向扩展可以拓宽你的视野，让你不再局限在某一种技术中，并也给你的未来多了一种可能;而纵向扩展，可以使用你深刻理解一项技术的细节，让你静下来思考问题的本质，你可能会惊讶地发现某些原理都是相通的。这两个方向都没有对与错，发展到一定程度都会相互溶合，就好比中国佛家禅修的南顿北渐，其实到了最后，渐悟与顿悟是一样的，顿由渐中来。

不过哪个在前，哪个在后，我个人认为还是先做到对某一个领域有较深的理解和掌握后，进而去学习其他方向，这个道理就如同精通一门语言的程序员再去学习其他语言时就能驾轻熟路。

关于这两点的结合，我有很深的感触，如上面提到的情况，刚开始的时候，运维相关的事情繁杂，每个人都得是多面手，要去cover多个领域，也因为此只能把每件事情做好而无法做精。在集群规模不断扩大和业务量的增长后，原先不是问题的地方开始暴露出来，这就有精通该领域的工程师来独挡一面。这是一个自我学习，自我改变的过程，也是自我突破的关键。

FIN

在互联网的浪潮下，产品在快速地更新换代，技术在不停地推陈出新，在这种大环境下，人心趋于浮躁，往往很难静下心专心做技术，唯有耐得住寂寞，才守得住繁华。

真切希望诸位在面对机遇和挑战时，能够坚忍。