讨论：未来的运维方式：DevOps？（获奖名单已公布-2014-7-31）

dc222222222

首先说下，我是做运维的，在我离开我的项目时，开发团队都认为我是一个极好接触的运维，我特别感到欣慰。
我见过很多运维抱怨“1个开发累死10个运维”，也见过很多开发抱怨“运维经常电话不接，找不到人”。就我的经验而言，运维跟开发主要有以下矛盾：
1，一个关注功能，一个关注性能：有的开发为了追求速度，1下开100个线程，导致服务器load 100+，cpu100%，运维不断收到短信，也有运维为了提高服务器性能利用率，很多应用都跑在同一台服务器上。
2，各自只能组织KPI，开发要求快速上线，并且稳定 ，运维要求成本节约，而且在没有好的上线机制的前提小只能手动去上线代码，成本节约跟高效稳定在初期阶段看起来绝对是一个矛盾体。
3，各自知识点的欠缺，开发为了给运维将他们软件的实现原理而大伤脑筋，运维为了教开发使用linux也是苦不堪言。
如果开发要跟运维做好协作，我认为应该做好以下几个事情：
1，对于一个项目，双方应达到共识，早期关注功能，后期关注功能，早期，运维可多参与开发的会议，了解产品是如何工作的，后期开发一定要找出产品的风险点，配合运维降低因用户量大引起的各种性能问题。
2，kpi互通，毕竟是在公司嘛，谁还没有个kpi了，一般情况这些kpi都是合理的，其实也是做好一个项目必须做成的，所以大家需要了解彼此的kpi，协助对方去达成，这样才能有个好的合作关系。
3，技术学习，互联网的确是一个很庞大的体系，不管是开发还是运维，学到的都是冰山一角，就技术本身而言，最终都是对内存，磁盘，cpu等硬件资源的使用，只是所处层次不样，如果双方都对计算机有很好的认识，肯定能杜绝很多问题，双方合作也跟顺畅。
关于devops，我推荐以下工具：
1，gitlab。天生的版本控制工具，配合jinkens，测试，上线，一步到位。
2，puppet。服务器状态保持利器，可减少运维很多工作量。
3，docker，资源分片利用，提供最合理的测试环境。

cfan0330

在亚马逊看了样书的目录，觉得这个可能对刚刚接触运维的，或者是IDC的人比较有用，但如果要说devops,个人感觉就差太远了，通篇书就只是说了咋个处理查看一般的机器网络环境问题，其他就呵呵了，简单一句话，跟dev（开发）根本不着边

haide1014

运维其实是高层