运维开发工程师在线评测：http://www.gtalent.cn/exam/interview/nsYteJ5wFfWkMdb2
我会分为下面三个维度来讨论下。
1.公司对你的定位
2.业务价值和技术价值
3.关于运维开发的推进方法
1.公司对你的定位
在IT行业其实不乏换工作的机会，关键是看你是怎么定位的，是怎么理解你的期望的。
而把这个问题做一层收敛，其中的一个面就是公司对你的定位。
技术上能够很深入，而脱离了业务，其实话语权就会少一些。
业务上关注更多，技术上其实少了很多的钻研，竞争力就少了一些。
而工作经验的核心其实就是解决问题的能力，新浪的肖总说过，这个是和你处理的个数是成正比的。
公司不养闲人，公司的核心就是要盈利，所以很多时候其实我们考虑问题的时候要么太简单了，要不太过于现实了。
这句话怎么理解，如果做过客户现场支持的同学就会有一种很明显的感受，在前线的压力实在太大了，但是一旦深入了技术细节，感觉好像一下子耳根清净，是另外一番境地了。
最终问题要解决，势必会牵扯业务，而通过技术的手段去解决，认为简单是很多人其实更愿意去从事技术价值更高的工作，当然这个出发点不一定错误。
而另外很多人过于现实，是一切都会以业务价值来衡量。我给一个非运维的朋友说过，如果按照你一切按照业务价值的衡量，运维这个岗位就不需要了。
在这里我倒不是和大家讨论运维的位置，而是从公司对你的定位来理解你的角色。
我也帮助过不少公司做过一些招聘的推荐工作，根据我的理解，他们更倾向于找到经验丰富，有自己想法的人，如果技术足够好，没有管理经验可以慢慢培养，而如果只有管理经验就比较尴尬了。
运维的工作其实很难去根据业务价值的维度去衡量，打个比方，如果有1000台数据库要维护，你说你很累，但是加加班也能做到,那么开始的时候你是很有幸福感的。
那么第二年还是1000台服务器，有些人就会疑惑了，1000台也好好的，已经稳定运行了，所以运维的工作就相对来说没那么重要了。
很多时候你没法直接根据一些体面的数字来关联起来，所以我们一般采用的方式就是减少服务器规模，提高性能之类的。很多人的公司没BAT那么大体量，所以性能提高个2倍，5倍对业务来说影响可能没那么关键。
所以我们想做很多事情，但是得不到更多的认可，这就是技术价值的一个痛点，而如果只是承接了业务，业务非常熟，但是脱离了这个平台，公司对你的依赖会大大降低。
因为你的经验很难在其他公司去复制，这是业务价值的一个痛点。
所以说运维的路子本身会越走越窄，我提了很多次运维开发，以至于现在我都懒得提了，具体进步了多少呢，其实发现很多人，包括我自己，都有强烈的拖延症，事情就这么拖下来了。
2.业务价值和技术价值
先来说一个常见的漩涡，业务价值低的系统产生的业务价值不高，所以很多新技术在这里使用的意义不大，被认为不值得做。
业务价值高的系统产生的业务价值高，新技术使用的风险较大，所以很多新技术的推动就有一定的阻力或者更多的考量维度。
如果在一个漩涡之中，那就是新技术推广真难，如果用混合思路，那就可能是在业务价值低的系统中试水，然后在业务价值高的系统中逐步推进，所以没有了前奏，后面的事情要推动就很难了。
混合可能是个好事，但是最终会导致事情和原来的预期差别很大。差别有多大呢，比如你目前使用的是油气车，以后的大趋势又是电能，在两者之前权衡，可能最后选择的就成了油气混合动力汽车，因为从很多人的角度来说，需要一个过渡，过渡中就需要有一个特殊的载体，既能满足需求A,也能满足需求B.
最后我们的需求就可能是C而不是A或者B了，这是好事还是坏事，真不好说，也不能一棍子打死，在不同的场景下可能意义大不同。
这是一个比较经典的图。
在我们的工作中，做业务肯定会和业务方打交道，我们的工作中有太多的琐事或者碎片时间是被这一类工作涵盖的。
做过很多业务的同学，肯定会有一肚子的苦水，各种不规范，不标准，最后很多问题处理协调起来最终都是在做妥协。
我的理解是业务的高度就是信任，如果达到一种高度的信任，那么去推动任何的事情来说都会容易很多。比如开发提了一个需求，只要你否定，而且给出理由，他们就绝对的信服。
这种状态肯定是你们彼此做了很多的磨合和摩擦之后才可能有的。当然还是需要你能多为他们着想，从换位思考，能够快速解决问题，而不是过分看重形式，其实很多事情都不完全是流程，甚至带有个人情感的因素了。
为什么在这里提一下业务价值和技术价值，其实做运维开发的方向也是如此。用刘强东的话说，运维就好比在高速公路上给赛车换轮胎的角色，保证赛车的成绩，同时能够更快更好的支持。
3.关于运维开发的推进方法
很多人一看我们在做运维系统，都会不大理解，我们找一些专业开发很快也能做好，或者总喜欢先从这个东西的核心价值入手。我的想法是运维工作本身就很难体现出成绩，但是如果能够提高效率，降低出错的概率，而且这个事情很有挑战，那么这个事情还是值得考虑去做一下的。
做好了，你就是这个问题的终结者，触类旁通，否则，就还是守旧。
关于运维平台的事情，其实做了很多的磨合，摆在我面前的有很多的难点：1.做平台的方向问题 2.做平台的人员投入不足 3.做平台的技术储备不足 4.上层对这件事情的认可和支持。
上面的每一个点，都需要做很多的工作，事情要做，要推动，光有支持还不够，细节的事情怎么推动，团队的人员怎么聚合起来，从思维上到行动上，感觉是一个又一个的漩涡。
所以我总结了以下几点，供参考。
1.主动思考，规划，产出一定是文档，形式不重要，但是没有输出就没有开始
2.共同提高，发挥团队成员的优势，不一定要让所有人都全面掌握，要带来希望，当然最好的方式是只需要成员做功能接入就可以，那么前期的工作就得自己做，这个工作量的事情就是另外一个大坑了。
3.怎么做事情，无论规划讨论，原型讨论，需求讨论，讨论都建议是半成品，成品，没有基本的东西没有说服力
4.关于进度的把控，如何跟进让别人不觉得催，同时也不用所有细节都要一一来跟进，避免太琐碎
5.从上到下如何来沟通，支持和明确支持确实不同，明确支持的话需要人，需要时间，需要价值产出，需要考虑资源的事情怎么平衡。
所以面对一些问题和走过的一些坑，我开始做一些细节的改进了。
大家能够根据自己的情况来参考，希望对你有一些帮助。
我的分享就到这里，谢谢大家。
群友互动：
问题1:
问：做平台的一个继承性问题我觉得比较大，核心人员走了的话，来了新人，有可能带来一套新的系统，甚至原来的系统觉得太复杂，觉得烂代码不想看，甚至一样的功能在他熟悉的系统中做一次
答：这种情况在开源社区里也很常见，很多开源产品维护一段时间就不维护了，要不开分支，要么重新开发设计。达到一定程度之后就会有这种情况。公司里来说，这种造轮子的现象，在人员流动较大的一些公司里是比较普遍的了。这种情况下，如果有一些完善的文档，稳定的使用场景，或者是技术架构，代码层面好一些，被替掉的可能性也会小一些。
问题2：
所以从开始开发就要详细的文档纪要，写个架构图呢，还是要写个详细的uml类图呢，很多人觉得开发的功能你看代码就好
话外音：这个是最受不了的，代码看得懂业务逻辑不清楚也是一脸懵逼，连蒙带猜的，再要是代码又不规范，命名完全不知所以的更是大坑了
答：
我觉得界面上的变化很大，但是能够保留一些也不错。主要是需求和通用设计层面的东西。
我以前也不爱可以写文档，但是发现都整理好了，没文档没法体现。
这样很多事情还是不明确。看不懂，不会做的概率就会大一些。
话外音：我想这就是大部分人看了一眼之前别人写的代码就像自己重新写的原因吧
【王老师说运维】：运维之linux基础入门实战(http://www.codeforest.cn/course/443)
