吴林松：运维没有 out of control一说

编者按： juliuswu(吴林松)，基础架构部运维中心负责人，05年毕业后一直从事业务运维，先后供职去哪儿，百度，思科，拉手网，经历过处于不同发展时期、不同管理风格的公司，见证了运维的起步、发展到现在的繁荣，始终对运维职业保持着热情。

当我们邀请Julius在运维日下午茶跟伙伴们聊聊运维职业成长的经验，他很爽快的答应了，又很谦虚的说希望别把兄弟们带沟里去了。事实究竟如何，来不及解释了，一起看看吧。

谈运维的职业成长，借用很多人都听过的观点，首先保证你的工作不可被别人取代，在此基础之上做到能取代任何人做好这份工作。怎么理解这两句话？如果运维只是做纯operation的工作，其实公司招一个应届毕业生也能够做到，为什么还需要付出更高的成本请一个高级工程师来做？如果你是公司管理者，你会怎么考虑？这是从公司用人管理成本角度来看；从运维个人来看，比如说开发做了一套运营系统，运维能做的最多只是上去写个脚本发布，其他的都干不了，然后拿人去堆效率，这样的运维工作如何让老板看到价值所在，自己累不说，也很难有什么工作成就感、价值感，更谈不上未来的职业规划与成长。

——1——

回顾自己这么多年做运维的经历，我想分享三点供大家参考：首先是要能耐得住寂寞。理解这句话我想先分享一个大的背景，05年整个互联网发展也处于起步阶段，行业里还没有“运维”的概念，那时候叫技术支持，可能划分到项目里更有效，在整个IT信息部下面，会有岗位专门叫system operation，系统工程师，网络工程师，存储工程师，或者是数据库，那时候谁也不会预见所谓运维将有能产生多大的价值。因为那时候BAT公司的市值远没有现在高，行业上整体运维的投入量及产出比也没有现在这么大的规模。现在BAT，做一个成本优化项目一年就能节省几个亿，相比之下，外部其他创业公司一年的营收都不可能达到几个亿，更没有条件去做所谓运维成本优化。所以能看到现在整个行业发展趋势对运维都还是看重的，这本身对运维人员的发展来说是非常有利的。

回到个人发展，我讲耐得住寂寞有两层含义：一是能否把前五年的精力投入在提升专业技术深度，而不受其他外界因素的影响。举例来说，在深圳大环境之下，大家很习惯聊三句话就话题转移到最近哪个小区房价又涨了，后悔没有早点买房，当然话题也可能转移到买车、炒股之类。这里申明一下不是说不应该聊这些话题，只是以此为例想对刚毕业几年的伙伴们说，在你入职场的头五年，是否能够把精力投入在关注如何提升专业技术深度，不要受环境影响，不要在意这些物质追求，而应该把眼光放得长远些，想明白自己到底追求的是什么，想办法让内心安静下来，专注于你眼前要努力提升的技术、能力短板，为实现你的长期目标做充分准备。

耐得住寂寞的另一层含义是努力拓展运维技术的广度。谈到运维与开发的区别，很多人会说运维其实没有开发有价值，但实际来看，开发的技术主要关注几方面，如精通一门编程语言，对底层容器的理解、网络交互，文件存储，内核计算的调用。而运维如果要做的很专业，其实需要涉及到安全，系统 、网络、中间件、工程语言、DBA、应用存储、网络存储等等很多模块的内容，维度划分很广。所以很多人做运维，能力却并不被开发认可，很大程度上说明头五年是没有投入充分的时间来提升技术能力。

以我为例，很多人会觉得我的职业生涯跳槽挺频繁，面试时Tomxiao也问我“为什么你中途还去了一趟思科”，我的回答是，当时认识到自己的专业技术有一块短板，对网络的认知深度不够。去了思科后，我才知道思科能把CCIE划为了六个，Routing & Switching、VOIP、storage、data center、security。理解了思科整个网络跟计算机OS的五大系统是一模一样的，对应区分开的，它的data center是后来基于云计算兴起，开始做整个数据中心解决方案的时候加的一个CCIE新认证。而我有幸在思科待了三年，再出来时我对网络技术的认知和理解对比之前有了明显提升，理解所有的计算机包括网络其他设备的设计，最终都会追溯于整个TCPIP大的网络结构，所有网络存储实际上都会划到单机的文件存储disk，所有SWAP交换的策略也会划到单机的内存，是一一对应的，因为互联网整个TCPIP的框架现在是没有变过的，这是我跳槽思科带来的收益。这也是人们常说，从本质来讲，如果把一门技术钻研的很深，再去投入学习其他的技术，是会触类旁通的。我举这个例子当然不是为了鼓励大家跳槽，是想说无论是跳槽还是停留在原有平台发展，你都要努力拓展自己运维技术的广度，如上面提及的运维需要学习的技术领域，时刻对标身边的技术专家，看看自己在哪些方面存在短板，寻找合适的方式方法让自己快速学习成长，即便有机会去到一个新的平台，也要清楚你去到这个新平台的目的是什么？是希望自己的视野、专业技术、管理经验等方面有哪些提升？而不仅仅是奔着所谓的物质待遇更好。

再补充一点，为什么要鼓励大家在头五年耐得住寂寞，还因为头五年你单身，年轻，熬夜什么都没有问题，精力足够旺盛，比打兴奋剂都好使。过了三十岁，精力就没法保证跟以前一样了。你熬夜连续加二十小时班，一天休整也缓不过来，而应届毕业生，加班二十四小时，一觉都不用睡，甚至一小时都不用睡，该打篮球玩王者荣耀一点都不耽误。从精力上来说你已经拼不过别人了，如果你还不在前五年牟足劲提升专业技术，还能拿什么跟小鲜肉拼。

——2——

我的第二点建议是保持好奇心。在整个职业生涯中，我们会遇到各种各样的问题和挑战，希望大家无论工作、生活都记住一个原则，就是保持好奇心，让自己无论是面对技术、工作、生活都多一些思考、追问。只是很多人在职场习惯这样一种做事风格，他知道老板什么风格，于是老板说这样做就这样做，从来不问为什么；也知道客户要什么，因为客户天天只要这个不要别的，所以不需要开口问为什么。实际上在专业技术成长过程中，要有足够的好奇心才会驱动你去研究这个技术，才会刨根问底到底是架构还是底层核心有问题，才会一步步去深入，既拓展视野也强化深度。如果不问为什么，比如领导安排你去做一个事情，旁边的人告诉你我觉得不太好，你说我觉得做的OK了，旁边的人还可能会说，我认为应该这样做，而你可能会很诧异，因为在你的理解下，已经认为这样是最好的。别人会告诉你还有更好的方法，而你不以为然，不会认为别人的提示对你来说有什么帮助，因为你没有好奇心。那你对做好这个事情的理解也就是有限的，更谈不上在技术深度上有什么拓展。好奇心是外在的，有好奇心会让你不断的往前走，然而现实中很多人是因为别人都是这样所以我也这样，主动放弃思考、追问。

再提另一点题外话，我自己也会看一些周易方面的书，周易有一个风水学方面的观点，说人一旦有一个势，势不能改。就是说，当我们刚毕业很年轻的时候，人生不能算最低谷，只能算职业生涯的最低谷，是得一直往上走。大家觉得是当k=1走的最快，还是k=无穷走的最快呢？很多人会觉得我努力了，始终在往上去奋斗的时候发现自己一直在往上升，突然有一天安于现状，突然觉得自己舒适了，觉得自己达到了目标，那个时候整个势就不变了，这里面有个很浅显的道理，就是你的势一旦变了，做什么都回不到原位了。

——3——

第三点建议是保持运维的核心竞争力，比如掌握一门能够落地实现的工程化语言。现在有运营开发，行业里Devops、SRE讲的很火，但你会发现所有运维不受重视的本质问题是，自己没有工程实现能力。开发会把一个产品写成代码，我们运维的时候却发现，最大的挑战是需要开发帮忙写一个系统。而如果自己掌握一门开发语言，比如Python，可能早期是Perl，还有最早期用shell。这个技能可能最开始写基于OS内核以上的脚本工具化的东西，做不了图形化，但是这是你整个自动化核心竞争能力的第一步。第二步是，如果开发能用一个语言写出一个产品工具化，为什么运维不行。如果你掌握这个核心技能，是谁也无法替代的。比方说现在的主流是Python、Go，有人可能还会说Ruby，Perl也行，我记得早些年写Perl很牛逼的人，一般在业界都被评价是神经病。因为Perl的复杂度，它的逻辑思维跟我们的正常生活不太一样，有幸我有同事也的确Perl写的很牛逼。因为Perl在正则表达上面，即使现在的Python的正则表达上也没有Perl强。比方说，nginx的转发配置， apache的后面的版本，都是基于Perl的正则表达去改的。

这里面就回到一个问题，当你知道做一件事情，并且具备工程化实现能力，自然就会把周遭所有的，比如说数据化，图形化，web界面化的东西就能做到水到渠成。如果没有工程化语言的能力，运维就叫operation，后面加个s，是最不会被人所接受的，在任何一个团队任何一个公司，可替代性为百分之百。如果掌握核心的工程落地实现的语言能力，你可以追求如果这门语言学的很好，例如Python学的很好，加一个框架也做的很好，将来可以转运营开发，做web开发。其实现在有很多公司，主程，包括运营系统全是用Python开发的。你也可以用技术推动运维团队向大家聊的很high 的自动化，智能化，AI运维发展，因为现在基本上都是把开源软件一些核心框架的轮子，零件拿过来，自己修一修，把发动机重新拼装一下成为一个超级跑车。没有谁自己重新去建一个车，轮子，包括BAT，所有大公司很牛的公司，因为业内已有很多开软软件，框架底下逻辑演变的复杂度，稳定度是需要时间衍变的，很难有一个团队去做开发，去做工程化的实现这么去做，但是做理论研究，做学术会这么去做。

——4——

最后跟大家一个建议是，自己保持对职业的热情，要有内驱力。前面提到好奇心是外在的，内在是取决于你是否有足够的内驱力。什么叫内驱力，内驱力就是做所有的事情包括追求人生目标，都是自己内心愿意去为之付出、努力争取的，为了达到目标，你知道遇到任何问题都会多问一个为什么。

有人可能会问，Julius你是如何坚持一直做运维？尤其运维从最开始的价值就不高。我说其实很简单，最开始我们很多人梦想说改变世界，长大后世界改变不了改变他人，他人改变不了，改变自己，最后连自己都改变不了，就混日子，逻辑是这样的。我相信如果一个有恒心的人，你愿意去做成事的人，你可以克服很多困难。你会追求先把自己做到最好，然后去影响改变他人。怎么让自己过得更好，这需要有足够定力跟驱动力，我头五年可能跟大家一样苦，曾经在去哪的时候，也有加了九十六小时班没有睡觉。大家也许关心一个问题，这么辛苦付出，老板能否看得到？其实这根本不是你需要关注。如果你能做的到，把自己做到极致了，该付出都付出了，老板是一定可以看到的，也会给予你应得的报酬。

——Q&A——

Q：做运维的工作因为经常半夜接到告警，就会觉得心很累，也想问问Julius怎么保持对运维工作的热情呢？

A：头五年在面对告警问题时，我能做的就是尽量收紧所负责系统的告警数。但我也发现其实很多人做监控告警的策略是，只要出现问题就告警，例如只要是有事件，有信息，有异常，就都告警。而忽略去考虑一个问题，实际告警得到的信息有什么意义？我会建议设计监控系统时，告警策略应该是能确切反馈问题出在什么地方才告警，而不是只给一个告警，因为只有做到清楚了解问题，将来才能推进往所谓的运维自动化和智能化方向发展。否则即使让AI去学习，AI也只能通过常理去学习，理解你告诉它的问题是什么，基于问题给建议或者引导下一步的处理措施。

很多人也会说监控告警的过程中，一种做法是有设计，另一种做法是最开始不设计，就只是添加告警，但是就会产生很多告警，而你能够充分理解业务逻辑，当线上出问题时，才能确保快速定位问题。比如请求到底穿没穿防火墙，穿没穿安全策略，这个模块有没有被流量清洗，是旁路还是直流下来，或是中间有没有经过第三方做数据处理，你能够清晰这背后的逻辑架构是怎样的，面对面沟通时就不会还在讨论到底是你的服务器有问题还是他的监控有问题，原因一目了然。我一直坚持平台的运维往业务化去做，更多的去理解客户的想法，客户的需求，业务往平台化去做。很多人会产生这样的观点，我负责的平台量很大，每天承载几十万、几百万用户，可以选择忽略有些人的告警，因为他不是我的VIP。我的观点是，如果你负责的平台没有区分VIP和非VIP客户，参考二八法则，你的非VIP客户会决定平台的生死和将来的成长，反过来业务发展势头很好，但是你没有考虑往平台方向做，就会让自己非常吃力。

运维没有out of control一说，对每一个模块必须要有足够的掌控能力，如果没能掌控这个模块，你就没有资格做这个运维。如果能够做到掌控所有的点，比如告警的收敛，告警的策略就可以自己来设计，有人说这还是没有解决告警很多的问题。确实告警会多，但你可以做到，知道这一条请求数据流下来，十个节点中只有一个节点是致命点，其他节点都是关联告警。如果是关联告警，你觉得系统有容错设计，即便报关联告警，可能还可以抗五个小时或者抗两个小时，那告警无需设计成电话告警，邮件是不是也可以解决。甚至到你有足够掌控能力时，是否可以设计成十一点到第二天早上六点之内不告警，只报致命告警，其他都不报，你可以逐步调整系统告警的阈值，各种策略，足够去做收敛。我经常也会听到团队成员吐槽告警太多了，没时间干别的，我一贯的回答是，告警是太多，但你想不想未来过好日子，那就去做，你不做我找别人去做。我对他们有一句听起来很理想的话，就是希望有一天运维可以坐在这里啥事也不干，喝咖啡就行了。

我也跟团队举过这个例子，大家做运维久了都有个习惯，拿着手机有电话有告警，突然有一天十分钟没有收到告警，就看一下手机有没有信号。为什么总有这种担忧，因为你觉得自己的系统不靠谱，真正觉得系统靠谱的时候，即便没有信号，你都会相信自己的系统没有问题。所以大家说告警这个问题收敛不好，其实根本问题还是在于要把自己的专业度，对整个业务模块的掌控度逐步的提升到一个很高的水平；把告警收敛好，才有更多的时间去投入到钻研技术的深度，才有更多的时间去学习新东西，才会放眼去看整个行业或者业界有什么新技术/新发展趋势，如果天天来上班看到告警，回家收到告警，半夜还被告警惊醒，我相信你就是有心想做去看业界去想学更多的东西，也没有足够的精力了。