不要轻视英语
算起来已经工作了快7年了，一开始我就是在外包公司混着。欧美外包项目是相当的养人，老外没有加班文化，朝九晚五。回家就是跟小伙伴们打dota。还总能去国外出差兼旅游，用乐不思蜀来描述是比较贴切的。那是一段不思进取的时光，技术再倒退。在学校学的那点东西忘了个七七八八。
人都说毕业后的第一份工作很重要，显然我浪费了这个机会。这般混混度日的时光一直持续到了与女王大人的相遇。我发现那点微薄的工资实在不足以撑起我俩的未来，自己这点匮乏的知识也支撑不起更高的报酬。所以游戏戒了，美剧戒了，漫画戒了，小说戒了。把之前丢掉的技术慢慢捡回来，那时候很勤奋，疯狂的想把丢掉的时间找回来。
好在欧美外包的经历把英语练起来了，为之后的学习打下了一定的基础。英语对技术学习有极大的影响力，不要不重视它。 最前沿的技术文档都是用英语写的，不要等到别人翻译成书，姑且不论翻译的质量如何，就是这个时间我们一般也等不起。也不要寄希望于网上大神的技术博客，虽然大神们一般都染指了最新的技术并也愿意记录下来，但技术博客的风格向来比较随意，文法不通，不成体系，内容较少，受众较小。
限于作者的个人时间，文中记录的都是作者碰到的一些主要问题，没碰到的和一些细枝末节的东西不会出现在文章中。而我们都知道在工作中向来是那些最细枝末节的东西卡的你痛不欲生。所以技术博客可以是一个好的引导，而不该是我们主要的学习材料。 而且技术这个东西国内向来都有滞后性，国外火了一阵子以后国内的大神们才开始接触，国内继续发展了一段时间后才会有人写技术博客。这时候你碰到什么问题是很难找到中文的解决方案的，一般都是去stackoverflow上，或者官网上，或者直接在github上搜issue才能找到解决方案。
例如我前几天写的kubeadm 搭建kubernetes集群中列的heapster 异常的问题，搜遍Google也只能在github上找到有人曾提过一个issue，也正是这个issue让我找到了解决方案。没有一定的英文阅读水平，不建议碰新技术。据我所知最近国内测试圈子比较火的rest-assured到现在也没有像样的中文教程，allure，selenide，assertJ等优秀框架甚至国内还少有人用。如果只看中文的kubernetes书籍，我这个测试环境的容器集群也是搭不起来的。所以如果你不想在技术上总是落后他人好几年，建议在英文上下下功夫。
努力成为最强的那个人
实力不是打了鸡血发奋图强一番就能取得的。 业余选手拼了老命也不可能战胜专业运动员，即便业余选手比专业运动员更努力也不行。业余选手没有专业的教练，称职的陪练，合理的饮食，丰富的大赛经验。
不说别的，一个没有任何专业大赛经验的雏儿上了擂台能在经验丰富的赛场老流氓面前走几招？业余选手缺少了太多太多的资源--只有专业运动员才能获得的资源。 所以我们要努力的获取这些资源让我们变的更专业，那对我们来说这些资源都是什么？ 领导肯让你去调研技术的时间，供你实战的业务场景，领域专家同事的帮助，解决成堆问题增长的经验值等等。
我们每到一个地方，都要尽快的成为当前团队实力最强的那个人，老外管这种人叫key person。因为你最强最靠谱，所以碰到什么问题都会让你解决，有什么重要的项目都会提供给你最好的资源去做。然后你变得更强，有机会获取更多的资源去做更重要的事--良性循环。如果我们不是最强的，光是业务压力就让你喘不过气来了。还有多少时间去学习技术？如果我们不是最强的，就算从海绵里挤出时间去学习，又有多少领导肯给实践的机会？
如果我们不是最强的，私底下再怎么努力也只是业余选手。 强者越来越强，弱者越来越弱。宁为鸡头，不做凤尾，起码要在某一领域内成为团队中说一不二的人，你才能继续在这个领域内走的更远。这是我的职场哲学。就像摔跤吧！爸爸中对获得了银牌的女儿说：你必须要拿金牌，没人会记住第二名
贪多嚼不烂，要精研某一个领域
测试圈子里有一句话很流行：测试这个职位什么都要懂，但什么都不用懂多深。 我觉得这句话害了不少人，什么都懂点又什么都懂的不深，那只能是上面说的业余选手了， 用脚趾头想也知道谁也不会把核心的东西交给一个略有涉猎的人手上。
面试官当久了都有一种惯性，一看到简历上写着什么都会的人就想fail掉他。因为根据以往的经验，候选人几乎确实样样都懂，但每样只懂皮毛，没亮点，我们不放心把任何事情交给他。人的精力是有限的，顾的了这头，就得放下那头。 我是毕业很久之后才明白的这个道理。以前凡是跟测试沾边的都研究。最后我发现哪头都没顾上，面试的时候忽悠门外汉一套一套的，一碰上专业的就露馅了。
也有人跟我说身为一个高级工程师，你就得什么都会，什么都精。 这更是不切实际的想法。 如此小看一门技术是可笑的，任何一个领域的掌握都要经过长时间的实践总结，踩过无数前人挖的坑埋的雷，学习涉及到的衍生到的相关知识才能说有所成就。能在一个领域内达到专家级别已属不易，不是人人都能做蝙蝠侠，精通130多种武功。如果你问精通一个领域有多难？ 以docker的学习路线为例
第一阶段：学习原生docker的命令，dockerfile，docker-compose，可以应付简单的日常需求。
第二阶段：更深入的使用docker，知道docker的所有网络模型及其使用场景。知道如何正确的设置docker的启动参数，知道如何分配ip池，dns，网关。懂得使用路由方法改造docker的网络模式。懂得哪个storage driver适合自己。懂得一些简单的traboule shooting方法。能够将各种资源容器化(编译容器，部署容器，测试执行机容器，基础服务容器等等)
第三阶段：懂得使用mesos，k8s和swarm其中的一个来搭建并维护私有云环境，对编排工具有一定程度的理解。搭建各种产品需要的容器服务(监控，overlay网络，ingress网络，DNS，NFS，镜像仓库等等)。能够调用编排工具暴露的REST API 做2次封装以符合开发测试的需求。
第四阶段： 懂得docker更深入的原理(虚拟网卡设备对，名称空间，linux桥接设备，iptables，overlay网络原理等)。熟知linux系统与网络。越懂linux，越能解决时不时出现的问题。这一阶段不是在学docker，而是学习网络，学习操作系统。扎实的功底能够让你找到各种方便的解决方案。
第五阶段： 对docker和编排工具有极其深入的了解，熟知linux底层知识。能编写容器网络插件，能对社区做出代码贡献。
你看要把docker玩精了要学多少东西, 所以每当有人夸我docker用的好，我都特心虚。有人跟我争论过玩docker不需要懂什么底层原理，能用能满足开发测试的需要就行了。其实在一定程度上这是没错的，开车的人不一定要知道怎么修车，因为我们有4s店呢。只是在我们的这个行当里，并没有4s店。出了问题要自己扛着，不能事事都依赖运维，毕竟QA不是开发的保姆，运维也不是QA的保姆不是么。所以如果我们不懂原理的话，出了问题怎么办？随便谁谁谁一不小心把ip_forward给关了我们查不出来，随便谁谁谁安个什么软件的时候自动再iptables里添加了什么规则把容器网络给堵死了我们查不出来。或者再有那手残的把网桥给删了(我曾经就是那个手残)我们也没办法。 测试环境什么都可能发生?? ?? ?? ?? 我就是血淋淋的例子~~~
也许有人说这个标准太高了，我们只是测试，掌握到xxx程度对测试来说就可以说是精通了。这是一个误区，一门技术从来不以你的职位划分等级。同样的程度，不会因为你是测试就是精通，他是开发就是入门。这个说法只是自欺欺人罢了。有些时候，我们对自己的要求委实有点低。
MKTEST(2017-08-11 11:37:37)
初入门看到这篇文章，真的很幸运，谢谢大神分享。