“背黑锅”的运维
上大学的时候，我所在的系有3个专业：工业自动化、检测技术及仪表、计算机，那时候我们经常会自我调侃，说我们分别是工厂里的”电工“、看水表和电表的、装电脑的。甚至到了今天，很多圈外的朋友知道我从事了将近15年的“IT”工作后，仍然会说：以后有啥电脑的问题找你行不...... “运维”，一个伟大的职业，也经常会被人调侃为“看机房”的，大家不要笑，这是个残酷的现实，即便是在圈内，在一个正常、逼格很高的企业中，运维人员仍然摆脱不了这种“贱民”的身份。
为什么会有这样的情况，我们可以从企业的组织架构谈起，以下是示意图：
这是一个非常常见的企业业务软件的产生流程，在这个流程的每一个节点上，都有相关的部门承担对应的职责，例如规划通常是企业的规划部、科技部、总工室之类的承担，而这个链条的末端，就是我们可怜的运维。
当然，很多人也在说，运维也可以吧黑锅扔给前面的开发和测试团队呀，我只能说这是个美好的愿望，因为你只能把问题往前仍，但是，软件的bug、架构的失误等等，在这个已经非常成熟的软件世界中，已经被大家接受了，你想，一个OpenSSL那么多年了，还出现天大的狗血漏洞呢， 而运维出了问题，一句话就干死了：运维能力不行！
我去他三舅姥姥！运维能力，这是一个多么可怕的名词呀，企业对运维的要求就是：不断提高运维水平，通过可靠、稳定的运维来提高系统运行稳定性、通过提升快速反应能力来降低运行风险，提高业务的无故障运行时间
看到没，人家还给你留了个口子，就是说还可以有“有故障时间”，大哥，用凉水洗洗脸清醒一下吧，那个口子的一大部分是留给规划、开发、测试的好不好。
说到这里，苦逼的运维狗们一定哭的稀里哗啦的，这还不是最严重的，我们回头再看看“运维能力”这4个字，这里面学问大了....
业务系统经过漫长的过程，最后移交到了运维团队，运维团队要做什么呢？系统部署、业务软件部署、接入运行平台（监控、备份、容灾什么的）、像看孩子一样守着（日常巡检）、应急处理....
流程好理解，但国内任何一个企业随便搞一下就几百个应用，以前还好，使用的东西无非就是IBM小机、Oracle数据库、Weblogic/Websphere中间件.... 备份、容灾也就那个几个，在企业里蹲上几年也就全了解了，至少对付一下没问题。现在国家提倡了一个去IOE、自助可控、开源，各种各样技术、软件如雨后春笋一样冒了出来，但是大数据行业，什么hadoop、spark、mesos...，有些名字列出来我都不认识，不是宝宝不学习，实在是宝宝学不过来呀。。。
这么一来，你的”运维能力“就一下子低的可怜.....
那么，如何改变这个现状呢？这个问题先容大家讨论一下，我会在后续的文章中抛准引玉，谈谈我的想法。
9同行回答
DevOps-运维的救世主？ 之前提到过运维团队的“背黑锅”命运，有些互联网出身的就开始吐槽了，说你看我们互联网里的运维团队就很NB，我们实现了DevOps，我们运维团队的工资同行业傲娇.... 这里，我想先探讨一下为什么在传统...DevOps-运维的救世主？
之前提到过运维团队的“背黑锅”命运，有些互联网出身的就开始吐槽了，说你看我们互联网里的运维团队就很NB，我们实现了DevOps，我们运维团队的工资同行业傲娇.... 这里，我想先探讨一下为什么在传统行业中会有这样一个在很多“互联网大神”们看起来不可思议反人类的组织架构，把这个问题分析清楚，我们才能不会变成跷跷板，压起这头确翘起了另一头。
首先声明，我们所说的传统行业，是要把一些“你我都明白的行业”去掉，这些行业的业务可有可无，毫无压力，不在我们讨论范围。
我们来谈一个“负责”的概念，我们通常会听到一句话：“这个出了问题，你负的起这个责吗？！”。在互联网行业中，我想不少人会说：我想我负的起！我们举两个例子，前两天某宝，把所有的用户的昵称后面都加了个“宝宝”，我脑补了一下我一个40多岁、胡子拉碴的直男被称为“宝宝”，直接口吐鲜血了。这个明显是一个“决策失误”,但是，我们从2方面来看：1. 公众怎么看这个事儿；2.这个问题出在哪个环节。
1. 唯一在能够看到的公众信息就是大家的朋友圈开始刷屏，貌似没有任何的损失，反而因为刷屏，某宝做了一次成功的”营销“。为什么会是这个样子？
2. 这个事情的决策，可能是两个产品经理头天晚上喝酒的时候定的，当晚就让码农们搞定上线了（实际情况不太清楚，随便黑一下）
实际上这种情况还出现在其他很多环节，例如前两天我某打车平台上的钱不对了，结果就是不对就不对，投诉之后，人家说我补给你就OK了，我后来拿着补偿乐开了花：）
等等
那么如果是传统企业出了这样的事情，会是一个什么结果？
大家回想一下之前的彩票事件，闹得渲染大波。
我们来总结一下不同：
1. 传统行业大多是”国“背景，除了要”赚钱“之外，还要承担”社会责任“，这个社会责任是一座大山，比如银行对于地区、国家的金融秩序稳定，彩票行业对福利、体育事业的支撑以及对国家信任的保护。这些在大多互联网企业，貌似大多只有”赚钱“。这么说可能不少互联网兄弟会不高兴，但是，我们认真想一想，你所供职的企业，承担了什么样的”社会责任“。
2. 由于”社会责任“的压力，所以要考虑到”风险“，这也是传统企业谈的最多的一个话题，“风险管控”！，在传统企业混，如果不知道如何控制风险，不管是控制个人的风险，还是团队的风险、企业的风险，都是很Low的。
所以，我们经常所诟病的传统企业的一些政策，也就容易理解了，传统企业中，我们经常说的一句话是：“会多”，什么事情都要上会，很多人会吐槽会议太多极大的影响了企业的效率和创新，但是，我们可以先思考一下“会议”的好处。
一个业务的投产，通常要经过很多轮会议，回想一下之前提到的流程中4个节点，规划、开发、测试、运维。我们可以看到，这4个环节的想法是不一样的，俗话说，屁股决定脑袋，会议，是一种手段，就是让一个问题在不同的部门内部决策、部门之间PK，从而产生一个平衡的最优解，你想，大家推崇的美国还经常大会小会不停的开呢。
那么，谈到会议，我觉得我们的企业中，并不是会多，而是会议的效率低，说道如何提高会议的效率，我推荐大家听一下《罗辑思维 开会是个技术活》，通过美国宪法的产生，思考一下我们现行的开会方式的缺陷。
再来说一下DevOps，DevOps说白了就是“全才”，开发、测试、运维都在一个团队中，我们先参照一下互联网团队的构成：
这个图，有些地方会成为“横向的服务团队+纵向的产品团队”。
设备运维团队就不讲了，基础平台服务团队，向上面的产品团队提供计算资源、平台资源、数据存储等等平台服务，并且制定运行规范，以提供几乎所有的“共性”产品/模块给到上面的业务团队。
上面的业务团队实际上就是一个一个的产品团队，每个产品团队中又包含产品经理（规划）、开发、测试和运维，很多时候，开发、测试、运维基本上就不怎么分家了，有时候一个人会同时承担多个角色，比如，一个开发人员、负责同伴的模块测试，同时还负责自己模块的运维。
实际上，基础平台服务我们也可以把它看成一个“产品”，所以，我们可以把这个架构简化为一个横向的大产品团队和若干个纵向的产品团队。在每一个产品团队内部，要承担自己产品架构设计、开发、测试和运维。
这个就是我所认识的DevOps，就是小循环内的DevOps！
这种架构对运维确实能够带来极大的好处：
1. One Team，One Dream！ 大家都是兄弟，啥事儿都好说，所以，会议效率大大提高。
2. 专业的人干专业的事儿，说起基础平台，还是搞运维这帮人最熟悉，说起业务，当然是谁设计开发的，谁最熟悉了，这样，运维的专业性、故障处理效率也会大大提高。
3. 责任划分更加清晰， 纵向产品团队为自己的业务负责，基础平台团队为基础平台的稳定性、可靠性负责，大家通过简单地“服务”实现接口。
什么事情都要看正反2面，我们反过来看一下弊端：
* One Team，One Dream！ 大家都是兄弟，很多事儿睁一只眼闭一只眼，草率决策，相互约束降低，出了问题互相掩盖。。。
实际上，传统企业中还有另一个大大的问题就是，这会设计到巨大的部门调整，这个问题基本上是个无解！
扯了这么多，该抛出一个讨论话题了，就是：
如何在企业实现DevOps从而实现敏捷的企业业务创新和发展的同时，通过什么样的手段来降低企业的风险。
收起希望借这个机会和大家一起交流自动化运维如何在传统企业进行应用，提高我们的工作效率。欢迎大家参与讨论交流。
本次讨论以如何利用自动化运维工具实现企业服务器规模在100台以上、并且系统环境是基于Unix、linux企业的2大需求：“自动化巡检、主机信息管理”展开讨论，希望能够抛砖引玉，为传统企业的自动化运维之路进行探索。
交流地址：http://www.aixchina.net/activity/?id=261
欢迎大家一起来切磋！
关于这个运维的问题，打算写一个系列：） 大家可以关注aixchina,我会近期更新：）
收起
写出运维细节方面的问题
楼主写的非常好，学习了！
收起个人认为，学无止境，学到手的，总结经验的，为自己所用。