雾里散步——这次聊聊自已

2016/1/7 1 Comment 1,209,520 Views 3 Times

很多时候还没开始其实早已经结束

终于结束了本命年，其实总结计划早已经码好了几千字，但是在跨年之后，我还是决定重新写一篇，无论从技术角度还是生活角度，我都打算自私一回，写回我自已。很多时候因为执着总是会迷失了自已，只要有光，人不怕在雾里散步，怕的是明明有光却还是迷路了，这次，我要以我的角度来阐述这个故事。

关于技术的那些事儿

人人都在雾里：

在技术的路上，人人都在雾里，在过去的五年里，不断的有人问我以下类似的问题

“Stat，你觉得我学XXX怎么样？”

“XX（某厂商）的XXX好像不错，你们都会了，我还没会”

“现在没人用XXX（某厂商）了，都用XXX（某厂商）的”

“OpenStack好像蛮屌的，而且互联网公司都在用“

“虚拟化？不就是XXX（某厂商）嘛，我会”（面试中）

这些问题本身并没有什么问题，我一般也是看在心里，不作回答，一方面年轻人无论以什么理由多学点技术总是没错的，另一方面，我担心我的言论影响他们自已的思考。但是今天我想以个人的名义，好好表达下关于这些问题我个人的愚见。学习技术我认为要认定方向，在系统这块，除非你全副身心都投入（比如我大学时期），否则很难实现像ITDev中所阐述的”全栈“能力。在中专时代，我了解到很多人背井离乡去大城市工作，大部分是因为大城市才能找到符合自已专业能力的工作（比如我现在），所以在那时我就渴望去改变这一个现状，直到07年、08年我了解到虚拟化（并非如Workstation的Guest级别虚拟化），我就明白了，这就是我的方向，虚拟化本身及其所衍生的技术栈可以使IT资源形成一个池，并且让所有人可以不用去接触到物理本身去获取资源，通过互联网，实现万物互联，最终实现IT资源Any Time、Any Where、Any Work（请注意是IT资源，并不是终端资源）。这就是我雾里的第一道光，我的心愿意追随这道光。

大一（很庆幸能够进入华南最具技术实力的院校学习）时，那个时候我跟老师交流过关于整合IT资源，老师告诉我“并行计算”。追寻一道光，我至少要知道这道光来自哪里，所以我对并行计算做了一些粗浅的了解，实际上并行计算并不等同于虚拟化，并行计算是类似天河超算中心里面的机器，将处理器等计算资源做并联，使其看起来像是一台机器，更加像是一台超大水车在河流上运作，水车同时同步在跑，水流加快，整条河的流动速度也大大增加了（关于这方面的技术，我也跟在超算中较有造诣的中科院博导张云泉老师学到了不少知识）。虚拟化，更多的是将分散的资源整合，并在其上实现硬件隔离的虚拟技术，并不是“一个大水车对应一个河流的关系”，而是每一个水车之上的扇叶做了隔离，需要多少力度就开启多少扇叶，利用各种群集技术，可以根据水流的需求调整多台水车的扇叶。了解了光的方向，我就开始真正的去追了，技术的界定永远是无界的（所以我现在自称无界工程师），我选择从VMware View（现在叫Horizon）入门，在Microsoft架构深入，最终跟开源技术整合，一路走来其实涉及了很多厂商不同的技术，但是唯一相同相通的都是一个，那就是方向。

我在雾里，我知道我希望看到什么，追寻的过程总是漫长而又枯燥的，还好明确，才使得我没有动摇过，所幸方向所到之处都或多或少有些许收获：

（这些年以来涉及到各个产品）

所以，技术本身并不存在什么开源、闭源，也不存在什么Windows、Linux、VMware、Microsoft、Citrix、KVM、Openstack、Docker之类的，在雾里，要能有一道光指导你的技术方向，追寻这道光，无论什么具体的技术、产品都好，只要能够离这道光越近，你就算翻越几座山峰又有什么呢？

（类似带着这样口吻的广告，本身就是不专业的）

明明在雾里迷路，却以为已经抓住了光：

技术的学习，向来应该是全面的，全面不是指你的广度，而是维度、深度，深浅靠勤奋，维度靠经验与领悟。我曾经见过很多人，上来就是说

“不就是个域吗？几台服务器就搞定了”

“不就是虚拟化吗？VMware就可以了”

”不就是个xxx吗？XXX足够了吧“

“这个网站啊？4G内存应该就够了吧！”

“这么简单你都要做得这么复杂，你多虑了”

“这样不行，那样不行，这个项目怎么进行下去？“

诸如以上的言论，且大部分来自带着“有经验”面具的“专家”们，或许是现实的残酷亦或是技术难度导致他们变成这样，大家本都是在雾里的人，我不应该嘲笑或是挖苦讽刺，但是我起码得表明一些立场。尤记得，年中去一家师兄的公司面试，我一个不经意说了句“好像”就被师兄当头一棒“技术是严谨的，只有是与否”，这句话可谓是2015年我听到最为雷霆的一句话，本来我快麻木，认为我“以为的不是我以为的”，当时一训反倒清醒了，无论是技术还是项目管理，本身就应该是严谨的，没有那么多借口。转而来看前面所陈述的问题，就拿“简单”的域来举个例子，真的那么简单吗？

1、域的基本概念弄清了吗？我作为CDM的MVP，我可以说我只能领悟到域的1成。

2、域的设计怎么设计？几台服务器到底是几台？为什么要这几台？

3、两台互备，考虑过互备之间的流量跟可能产生的风险吗？

4、消耗流量少不用担心，请问流量少是个什么量词？凭什么以这个量词说明风险少不用担心？

5、全国各地的公司之间的线路清楚吗？是不是对等？是不是一样的质量？

6、域就真的只是域吗？用域本身的目的是什么？基于域架构搭建的IT基础环境是怎么考虑的？

7、靠着所谓的经验，请问场景都一样吗？条件都一样吗？人为因素都一样吗？

问到这里可能有些朋友会说，你钻牛角了，哪有你说的这么复杂。事实就是这么复杂，你放弃对技术的追求我没意见，即使退一万步讲，你如何跟老板（客户）讲好这个故事并使老板（客户）掏钱？老板问到以上问题你怎么回答？没问到出了问题你怎么解释？

很多情况下，人们在雾里被迷住了双眼却以为抓住了光，站在甲方乙方两方面来看，基本都存在这样的情况：

把设计看轻了，向来是大忽悠PPT先上，设计文档胡乱复制（甚至有时候连设计文档都没有），不考虑业务与场景，以为“一招鲜吃遍天”，终于靠着东凑西凑起来的所谓“技术方案”开始了期待已久的实施，然后迎接的就是各种实施故障（大部分人所认为的“坑”），好不容易安抚好客户了，要验收才翻出点截图来做第二张大忽悠PPT。钱赚了，问题出了，人心没了。

设计文档是用来干什么的？怎么来的设计文档？在两年前我不会说，好在，越来越多人已经开始明白这一点了，今天我觉得是时候聊聊了。从项目管理的角度最粗浅最低级的来说“需求调研——设计——实施——测试——验收”，这里已经不掺杂任何管理领域的东西都足够很多所谓的“工程师”好好看看了，很多人把设计文档看成用来“交差”的，实际上设计文档是你经过前期调研收集资料（比如物理环境、逻辑环境、人员因素、经济因素、业务因素、需求因素等等，特别是人方面的因素）来决定的，而不是就着几个概念去某度拼凑而成的，大部分的技术都是要依照本身的需求来定，而不是看你的技术能力来定，如果你的技术能力或者现实因素满足不了业务需求所要求的，请体现在设计文档里。我的习惯是，需求调研，我会列一个List去收集，没收集完整我绝对不动手。你可能觉得没必要，抛开一切来说，这些收集的资料必将是你老板（客户）将来所要跟你探讨的，一切理论的依据来源于数据，而不是你的空口白话，上面所述的问题，并不是多余的问题，而是天经地义应该考虑到的问题，有人或许会说，你这样只会累到自已，实际上在前期不累，后期会更累，且负担更重。很少人愿意干擦屁股的活儿，却不愿意在设计方案这件事上多下点思考的成本，总是自欺欺人的以为在雾里抓住了光。

说到这里不得不拍下二东家的马屁，为什么马云提到“DT”时代，实际上也是这个道理，一切以数据说话，以数据产生业务价值，你的老板（客户）越来越不可能在你的胡说八道下信任你，因为数据的时代已经来了，且早已经来了。说到这里，据说马老板的阿里云团队里有专门一支算法团队，专门针对云服务的各种业务建立数据模型，最为好的例子就是，阿里云的IaaS带宽可以精确的告诉你多少兆带宽能支撑多少的并发（连PV跟UV都可以告诉你），现在你还好意思说“XXX就足够了吧”这样没有数据上下文的话吗？只要能够认真在数据上下功夫，你就会发现，最后所需要交付的资料其实早就已经积累起来了，而且有实打实的数据支撑。

追寻的过程也是产生光的过程：

运维本来就是很大的学问，大部分人觉得是“维稳”即可，实际上运维的学问远远超过“稳”字，在DT时代下，“稳”已经不够用了（请注意，是不够用，而不是刚刚好），前面讲过不要轻视设计，是因为数据的重要性，实际上运维的工作也跟数据息息相关，很多运维人总以系统稳定作为标杆，但我觉得当前有众多技术支撑的前提下已经不能以系统稳定作为标杆了，而是应该以系统的生命力，或者预测系统的生命力来作为依据。如果把运维工作比喻成雾里追寻光的过程，其实追寻光的轨迹本身也是一道光，这些光就是由运维产生的数据所积累而成的，运维人的价值通常比研发人员要低（现在已经好很多），很多时候其实就是价值没有可视化出来，或者勉强的去套用所谓“成熟”的体系导致运维价值低下。真正的运维应该是多合一的，也是循序渐进的，不是一开始就能登天的。比如可以在运维体系趋于完善的时候引入SLA机制，将具体的允许故障时间量化（数据化）：

（具体SLA对应的可停机时间表）

我见过比较好的例子就是“连续无重大故障时间”，先将故障定级，然后根据某个特定级别的故障出现时间进行记录，统计出无故障天数，激励团队去努力营造“稳”且前进的业务运维生态，这是很好的手段（我前东家在这个记录上接近300天），包括报表报告、阶段性总结、年度总结这些都是价值可视化的最佳时机，千万别再“应付式”的去“交差”。当然，价值可视化不是让你“装X”，无中生有是大忌，实际能产生什么效果就该说什么效果，达到什么数据有什么风险该说清楚就应该说清楚，允许无意的错误，但是为了凸显价值而去“无中生有”，这必然也会在雾里迷路（博主也犯过这种错误）。

退一千万步讲，你想体现自身的价值并且得到应有的尊重与相应的报酬，也得把你所努力的东西让别人知道，而不是自以为是的以为别人很清楚。

VMCloud的价值

VMCloud实际上就是我追寻光的轨迹，有时候很匆忙，我不能说VMCloud是尽善尽美的，但起码是有轮廓的。从11年VMCloud创建，12年底VMCloud云平台系列博文出来到现在基础篇完结，一直有人问：

“你这个赚钱了没？”

“没赚钱有啥意思？”

“分享？你都蛮傻的”

赚钱，人人都有的想法，我为什么不赚？

1、因为思考所产生的利益比金钱值钱太多了，在这个过程中，我积累的很多，这些积累足够我在雾里去追逐光了。

2、我凭什么能赚？这些知识只是最基础最普通不过的笔记，很多深层次的东西靠文字根本无法表达，更别说金钱能够购买。

3、我怎么好意思赚？我写的博文角度通常都是“诡异”的，看似Step By Step实则思考的成本比金钱要多很多，我只是表达的看起来似乎很“简单”，所以免费其实才是最贵的。

回归价值，思考成本低深度够的知识很少有，深度的知识需要思考成本、时间成本，给人如果产生这些额外的成本，那就根本不值得购买，既然不值得购买，不如免费。（比如我51CTO的第一部教程就是免费的）

如果有一天我能够这般觉悟（比如胖老师，他通常能把复杂的概念幻化成简单易接受的语言）加上足够的知识维度（比如96年生人的MVP老王），我才会考虑物质价值，否则，我还是在追寻光的过程中去积累这些宝贵的“精神财富”吧，关于VMCloud，14年的年终总结已经聊了很多，这里不多阐述。

（简化后的VMCloud计划）

在技术这一块，有个观点，技术是需求决定的，需求是业务决定的。我深有同感，同时这也是一个非常无奈的观点，这就意味着你可能需要关注一些额外的点，但是没关系，IT技术向来是允许互通的，只要你能在不同的技术中找到相同方向，借助这些技术提升业务的价值就够了。

关于生活的那些事儿

三岔口，如何选择：

我还没毕业就加入了我的前东家公司，老师说的一句话（实习生的待遇问题还不是因为你们没给企业一种信任）使我留在前东家三年，然而我的实际行动证明，即使证明了对企业足够的忠诚，即使提再多的意见，也仍然改变不了顶层的心。直到我离开，我最后跟领导说的一句话就是，现在的实习生待遇还是那样吗？“是的。”，三年来，我兢兢业业的学习，珍惜着前东家给我的每一份营养，虽然我的行动改变不了顶层的想法，但是这仍然不是我离开的主要原因。

作为学生，我踏进社会，无论我在学校多优秀，那也没办法给予企业多大的信心（现实）。而前东家给予我充分的信心，且实习阶段就提供环境让我负责研究许多新鲜技术，甚至公费让我参与MVP OpenDay这样的盛会，这样的信任虽然没有体现在待遇上，但是对于当时渴望得到实验环境的我是最具杀伤力，可以说当时的“设计”完全符合我的“业务需求”。但是望梅始终止不了渴，我在里面三年，每年都有人问我同一个问题，“你还在那家吗？怎么还在那家！”甚至于老师也是这么问我，不以为然久了，心里也就多少有点触动，更可怕的是我的生活质量像中国股市一样一路下滑，丝毫望不到边界。

恰好是8月，我有幸得到钉子老师（丁国茂，微软元老级MVP）的赠书，来自开复博士的《向死而生:我修的死亡学分》，我花了1个月时间去品读，我觉得我是时候得到我应得的且对应的待遇了。这时候，雾里的三岔口出现了，同时有七家公司向我抛来橄榄枝，当然我本身也努力去找我向往的公司（然而都是无功而返），在七家公司中，我挑选了其中最为关注的三家做了一个评测表（维度分别是：待遇、环境、人文、企业文化、企业背景、行业、把握程度、IT系数），最终决定了我现在的东家，虽然并不是待遇最好的，但却是我最想做的一份事业（请注意，我用了事业，而不是职业或工作）。

（选择可以量化）

有选择是件很幸福的事情，好过不得不选择，所以有得选择请珍惜并好好思考如何选择，对于工作，我想你需要定一条底线，很多人的底线是薪水，薪水我承认很重要，但是请不要单一拿薪水做底线，而是应该全方面的，价格并不能决定一切，决定一切的是性价比，而这个性价比是双方的，你得值得起那个价格，以及人家觉得你值得起那个价格，加上你做得出那个价格。这个道理，在生活中也是一样，想要得到某些东西时，总是要使你自已能够驾驭得了某些东西，这个跟你追求的技术方向不同，它并不是一道光，而是一条路，不要怪走到了死胡同，只能说自已还没能把握路的方向（或者说没了方向感）。

技术与生活的平衡木，没有任何事情会因你而改变：

在开复博士的《向死而生:我修的死亡学分》这本书中，最震撼的一句话是“经历了死亡之后，越发清晰没有任何事情会因你而改变”，一直以来开复博士都是以改变世界为己任的一个人，甚至于写出《世界因你不同》，而现在为何发出“没有任何事情会因你而改变”这样的声音？开复博士没有变，只是他看得更清晰了。过分的关注某个方面（比如技术），总会多少失去了生活，我曾经以做实验为乐趣，为骄傲，并且将实验作为生活的一部分，很长时间以来，我拒绝生活，我甘于沉醉在各种各样的Demo中去。这并不是堕落，但对于我个人而言显然也是一种病态，我越发发现我的逻辑能力、表达能力下降，甚至有时候思维完全混乱，无法完整表达我想说的话。

现在我意识到这一点了，技术与生活，其实是一杆秤，你把技术的砝码放在生活上多一点，生活就会显得很沉重，圈子便越来越小，直到有一天你喘不过气来再想透气就晚了。So，还是老话要懂得追随本心，心想生活，就去生活，把这个当成借口也好，稍微让技术与生活更加平衡，放下执念，学会接受“没有任何事情会因你而改变”，微微一笑，你就明白为什么世界会因你不同了，更加清晰的对待身边的事儿跟人儿。有能力者，就应该拿得起放得下，敢于面对自已，尊重自已，担负起自已的责任，真正参与到未来的进程与生活中去，并在其中找到属于自已“业务需求”的平衡。

~~（从这段字的篇幅你可以看得出来实际上我还是放不下。）~~

我与VMCloud共同在雾里散步：

VMCloud从2011年初创到现在，已经5个年头了，一直以来我都不认为它具备“组织”的特性，VMCloud与我一样，一样有血有肉，会哭会笑。就像前面所说的一样，追寻雾里的光可能是我的目标，而VMCloud的目标就是使追寻更加精益，更加锐利（这是VMCloud在年中更换Logo的最主要原因），同时更加坚实有力（盾牌的意义）。

VMCloud正式发力是13年，至今坚持下来也有近3年了，在2015年，我的本命年，VMCloud完成了以下List：

2015年3月 VMCloud 微信公众号 正式开通

2015年3月~12月 VMCloud 微信公众号 一共完成了12篇“进阶”版微文

2015年6月 VMCloud开源军团 正式成立，VMCloud Blog更换风格

2015年7月 VMCloud云平台 SC基础篇正式完结 完成从零到一的转变

2015年 8月 VMCloud Monitor++产品Demo完成，VMCloud更换Logo

2015年 9月 VMCloud Line++产品Demo 完成（同时Agent++宣告失败）

2015年11月 VMCloud 迎来了真正意义上的 第一百篇 博文

2015年12月 VMCloud云平台 Microsoft平台基础篇正式杀青，一共104篇，涵盖了SC全系列+Azure Packs产品线

有人说，“事不过三”，VMCloud有5年了，年度计划第3篇了，博文127篇了，微文14篇了，专题3个了，线下讲座也举行了3场了，广科视频也2部了，网站点击量也超百万了，51CTO 访客量也过八万了，我的MVP，也三年了，新人也变老戏骨了：

（MVP襟章，2014年我称之为坚持，2015年我称之为责任，2016年我称之为勇气）

三年，坚持是一件挺不容易的事儿，无论从生活到技术第三年都是个坎儿。有些事情还没开始其实早已经结束，但是即使开始了，你也不一定抓得住，所以，未来谁知道呢？可以确定的是，参与未来，是每个有能力者共同的责任，即使在雾里需要翻越几座山，绕了几次路，也请一定要坚定方向，相信未来终有一天会看到雾后清晨的第一缕光。