近期因为工作方向上的变化，需要学习一些新东西，通用技术还好说，网上又大把的资料可以看，但面对只有几个人知道的业务问题，我也只能依靠其他人教我了，但从我过去两年的工作经历来看，我感觉整个团队的的新人培养存在 很大的问题。接下来我就结合我过去经历，加上《SRE》和《The effective engineer》两本书里的部分内容，总结出以下几点建议（或者说想法）。
1. 对新人设立明确的阶段性目标
大家对新人的目标基本上都是尽快成长为一名合格的pe。什么样是合格的pe？每个人都有自己的标准。怎么样成长为合格的pe？基本上都靠新人自己摸索了。对于已有相关经验的人来说还好，对于经验匮乏的新人可能就得跟个无头苍蝇一样乱撞、乱学，运气好哪一天就开窍了。也许大家都知道细化目标对结果有结果有非常大的影响，但不太会在新人培训上做这件事，所以就有了下一条。
2. 提高新人培训的优先级和重视程度
《the effective engineer》一本关于如何提高效率的书，作者Edmond在书中写道新人培训其实有非常高的ROI。每天花1小时指导新人，连续指导一个月，乍看起来这是非常大的一个投入，但其实连你全年工作时间的1%都不到，但对新人和团队的影响可能是巨大的。
3. 完善师徒体系
必须有人对新人的成长负责。mentor需要为新人设定完整的成长过程，并时刻关注新人成长情况，适时调整培训重点。建立高频的反馈-调整机制可以更快让新人成长起来。
4. 增加理论知识的比重
这点我没有第三方的论据支撑，举自己两个例子。我之前一直负责java的运维，经常遇到很多问题很难解决，最后要不不了了之，要不丢给开发处理了。后来自己学了些java相关的东西，尤其是真正写代码之后，回想起之前的一些问题，突然会有一种顿悟的感觉。
By the way，大家老说要逆向反推什么的…… 抛开难度不说，这个真的很低效。 虽然上图左侧也提到了反向工程，但这个工具我们也许用的有点过了。
5. 模拟实战
不用说任何人都不敢让新人上来就处理大问题，那让新人熬吧，熬到前人跑路，你不得不上的时候再来接手处理，有种媳妇熬成婆的感觉。像《SRE》中所说的，并不需要等到真正的问题发生了，才让新人去处理、去学，而是制造出一种可控的真实线上问题去让新人处理。美军海湾战争时候的王牌飞行员计划，其实就是通过红蓝对抗模拟实战的方式培训出一批优秀的飞行员，在战争中创造了1架飞机击落33架敌机的记录。
6. 经验分享
谷歌的验尸文化，故障review，从故障中学习，可以避免类似的故障再次出现。 回归到每个个体身上，也没多少人把自己的经验总结出来分享给别人（可能是觉得不值得分享吧）。所以基本谈不上从其他人那吸取经验了。。
7. 定期培训
我觉得这点不仅限于新人培训，还有助于团队成长。还是《the effective engineer》中，作者Edmond给出了6个评估一个团队是否值得去的指标。 快速增长、培训、开放性、迭代速率、人员素质、自治程度。培训不仅是新人成长的机会，也是老人巩固自己知识体系的机会，更是吸引人才的一种方式。可能大家工作的内容不一样，但也可以用比较通俗易懂的方式把自己知晓的东西讲给别人，为别人开拓思路的同时也找出自己的问题。
由于每个人的先验知识和经历不同，所以没有普适的培训方法，但也许有普适的培训理念。我觉得最重要的其实是每个新人有个靠谱负责的mentor，mentor根据每个新人的现状和特点制定相应的培训节奏和方法。
题外话：
我猜好多人都有过这样的感受，『哎呀 怎么这次招的这个人不行呢，看来下次还得找个经验丰富的人』。。就如同教育孩子一样，好多家长老抱怨自己孩子学习成绩差、不听话，而对自己的教育方式避而不谈。好在工作和教育子女不一样，员工不行，可以再换一个别人培养好的就行。
还有人说『为什么同样的新东西，我学两天就学会了，而他要一周，肯定是他学习能力差』『作为一个ｘｘ工程师，连这个都不会』。《了不起的比尔盖茨》（其实是盖茨比）中有一句话，"当你想要批评别人的时候,要记住,这世上并不是所有人都有你拥有的那些优势"。
说这些题外话，其实是想说好多人把『聪明』这个词看的太重了，而忽视了更重要的后天培养。
