浅谈开发与运维之间的矛盾在用户手中的根源、表现与解决方案。 从之前的敏捷过程来看，其实开发/测试甚至QA团队的目标都是一样的。 运维团队的目标：品质永远第一。这就引出了一个有趣的现象： 变化是失败的主要原因，你同意吗？ 之前在一篇论文中给出了数据，无论是硬件维护还是网站维护，人为改动都是引入失败的主要原因（图1）。在没有找到有效手段之前，尤其是在人工时代，运维必须要抗拒变化。你同意？ 图一：人主导的变革是失败的主因想像中，尤其是一些不断迭代的2C产品，“变化是唯一不变的法则”，也就是说变化是常态。 至此，我们可以得出一个非常有用的结论。开发和运维之间的矛盾在某些情况下会被放大，比如运维能力薄弱、出现部门墙等。图2进一步总结并说明了这种冲突的原因。 两个不同的团队将各自的目标和要求推送给了另一个团队，但是部门墙的存在阻止了这种推送。 图2：Dev/Ops中冲突的根源 甚至，我有时会把这张图比作两个击剑手进行对抗比赛的舞台（生产环境）。 2.矛盾的表现 企业矛盾最直接的表现就是抱怨。抱怨最直接的感受，就是你总是站在自己的角度，觉得对方不够好。 因此，我从整个软件或功能交付的角度分析，将流程分解成几个典型的阶段，看看这个抱怨是怎么产生的。 您也可以根据自己的经历，总结一下您感受到的矛盾和您的抱怨从何而来（尽量明确具体），然后我们一起走向下一个解决方案。2.1. 开发者在程序发布前的投诉： 没有那么复杂。 ◆运维资源交付流程太长，能不能快点？ ◆运维的交付过程能不能更透明一点，不要让我经常提醒运维，进度如何？ ◆运维流程太多。通过OA和领导批复不是更容易吗？ ◆我感觉运维的第一要求就是时刻盯着我们的服务器。是不是太多了？ 运维投诉： ◆开发永远是发布程序，只告诉运维怎么做？！ ◆老开发者拍拍脑袋告诉我给多少资源，为什么不合理评价一下？！ ◆为什么没有邀请运维参与开发技术架构评审？ ◆开发的技术架构对运维需求的考虑太少，很多研发都是真正的程序研发。 ◆开发作为资源提供者/事务进行运维，最好让他们自己运维。 2.2。程序发布时开发者的抱怨： ◆运维发布过程非常复杂和暴力。它不区分业务和发布类型。必须经过多位领导审批，深夜发布。 ◆明明写了详细的部署文档，为什么每次部署都需要深度参与研发？ ◆运维发布很慢。一个发布要半天，感觉比我们的研发流程还长。 ◆运维部署不能自动化吗？为什么经过这么长时间还需要手动工作？我想建立自己的发布平台。 ◆一些不重要的release，R&D自己能搞定吗？不想每次都去接触复杂的运维流程。 运维投诉： ◆这个部署文档很复杂，里面有很多坑，需要注意，每次部署都需要很多时间。 ◆这个程序的开发写的不错，我之前也反馈过他们，不是每台机器配置都不一样，但还是没改。 ◆研发是否遵守运维规范，不跟我沟通，自己方便写业务流程，让我运维。 2.3。程序发布后 开发的抱怨： ◆程序有问题，为什么运维不能自己定位问题？这一切都需要我的深度参与。 ◆程序发布后出现了一个bug。这时候就需要一个紧急流程，leader必须要经过。真的有必要这么麻烦吗？ ◆节目发布后看不到状态。看看能不能做成一个系统给我看相关的信息。 ◆运维的监控能力真的很弱，问题都是用户或者我们看日志发现的。 运维投诉： ◆开发的程序太烂了，刚发布，有bug。 ◆程序有bug，催我赶紧解决。甚至研发本身也没有那么快找到bug。我怎么可以这么快！ ◆开发程序异常日志输出过少，不利于快速定位问题。 2.4。来自 开发在持续运营阶段的抱怨： ◆为什么运维不能给我账号，让我登录服务器看看服务状态。 ◆我应该在运维内部给平台一些权限，我想看看服务的运行状态。注：很多公司估计R&D从来没有登录过监控系统，更不用说CMDB了。 ◆运维的日志分析能力很弱。我必须编写一个临时程序来进行日志分析。 ◆没有故障，感觉不到运维的存在。 运维投诉： ◆开发编写的程序又出bug，又出现重大故障，又要救火了！ ◆开发的程序架构设计的不好，没有事先考虑到这个技术问题，所以这个问题必须要靠人来解决。 ◆制定的KPI体系应该包括运维的质量指标和成本指标，他们需要一起战斗，否则压力永远压在我们运维身上。 ◆我们做了一些数据报告，开发者根本不在乎。他们只关心需求的实现，不关心运维的需求。 如果你深入技术分析，你会发现一些冲突的根源： ◆研发和测试部门由敏捷方法论驱动。 ◆运维部是建立在ITIL系统之上的ITSM管理理念。 前者有一些管理工具（持续集成、看板）/实践（站会/试驾/极限编程）/文化（价值观/团队整合）等。 后者所依赖的ITSM流程体系明显落后于前者敏捷体系的能力。 也就是说，两个团队的IT思维/能力不同导致产出的差异，这就是技术冲突的根源。 所以为了解决问题，核心思想是找到一个统一的方法论（DevOps？）来整合两个IT团队的目标和方法论。当然，运维团队的影响最大。过程能力转化为自动化平台的能力。 从方法论的角度，我认为DevOps是Agile方法论的自然延伸。 其实从他们各自的角度，我们都能看出彼此的顾虑。这些担忧中有些是重叠的，有些则完全没有重点。 3。解决矛盾 寻求解决方案比抱怨更重要。哪里有抱怨，哪里就有改进的机会。但我一般避免使用DevOps一词来寻求解决方案。 我个人认为需要做出一些改变。核心变化有两点：第一是拆墙；拆墙，研发/运维团队可以互相触及对方的力量，感受对方的需求和能力。 换个阶段，换个底层的阶段，“经济基础决定上层建筑”，底层换了，上面的思维也会随之改变。 措施1：共享一致的目标/价值/状态 对于研发/测试/运维团队来说，需要让大家的目标/价值/状态保持一致。之前写过，IT运维的目标体系是质量/成本/效率/安全。其实这个完全可以传递给研发/测试团队，和业务功能需求完全不冲突。 在目标、阶段性目标和长期目标方面： ◆阶段性目标其实可以看业务部门的短期需求和规划，从而反推对IT能力的需求，比如敏捷的基础设施交付，连续释放。 ◆长期目标其实就是规划IT能力的主线，比如容器化、架构服务，然后分解成阶段性的目标。这个目标需要与研发保持一致。 我说的状态比较特殊。其实我希望运维能够让线上服务的运行状态透明化、可视化。然后交付给我们的研发/测试部门，不要让自己的能力成为黑匣子。就这样： ◆一方面，督促自己不断提升自己的能力。 ◆二是分情况推进研究试验，不断优化技术服务能力。所以，更需要将这种思维传递到开发中，让它构建一个非黑盒系统。 研发有技术和责任协助运维实现这个目标。 状态一致性其实是一种具体的驱动措施，俗称状态看板，分为业务价值看板BVD和服务状态看板，如交易看板、服务可用性看板、服务成本看板、服务绩效看板、事件看板、问题板等。 措施二：平台驱动的IT能力 在上一章中，我说过ITSM的运维系统能力远远落后，显然不能满足当前业务快速迭代的需求。运维的问题还是要靠运维来解决。 在生产环境中，运维是第一负责人。需要改变过去的流程思维，建立自动化、数据化的运维平台。 从环境管理的角度，首先要覆盖生产环境的平台管理能力作为灰度点，然后逐步覆盖预发布/测试环境，最后是开发环境。有了平台能力，运维角色可以顺利提升到研发和测试。否则，就会有规定无法执行。 不信你能定义一个实时网络日志监控规范吗？ 所以，我把图4中绿色部分的能力实现看成是运维部门。你觉得你在搭建一个舞台吗？确实是这样！ 图4：平台化是扩展运维能力的最佳方式 措施三：“把想法放到别人的脑袋里” 每个团队都不能孤立地看待问题或解决问题。当我们把能力延伸到对方后，其实就是在做“把想法装进别人脑袋里”的事情，这对双方球队来说都很难。 我之前讲过研发团队的Ops-friendly和运维团队的Dev-friendly，也说过要照顾到别人的诉求才是友好的。 2014年的puppet报告也谈到了在团队内部培养DevOps的重要性。事实上，它是在谈论将概念和实践更新为一致的状态。 图5：思维多元化，事半功倍 任务冲突在所难免，冲突的形式多种多样，解决冲突的方法也各不相同。 这篇文章是我对这个问题的整体思考，希望能引发大家一起思考。最后引出一个话题——“NoOps”（无运维）。让我们一起考虑一下。是否可以？其实这篇文章也有一些答案。
