2017运维/DevOps在线技术峰会上，阿里云平台研发高级专家连铭带来DevOps的相关演讲。本文主要从什么是DevOps开始聊起，接着对比了DevOps与传统模式的区别，并且列举了DevOps的难点和需要解决的问题，包括寻找平衡点、责权划分和制约考核，最后进行了简要总结。一起来了解下吧。
以下是精彩内容整理：

近几个月，运维事件频发。从“炉石数据被删”到“MongoDB遭黑客勒索”，从“Gitlab数据库被误删”到某家公司漏洞被组合攻击。这些事件，无一不在呐喊——做好运维工作的重要性。然而，从传统IT部署到云，人肉运维已经是过去式，云上运维该怎么开展？尤其是云2.0时代，运维已经向全局化、流程化和精细化模式转变。与此同时，人工智能的发展，“威胁论”也随之袭来——运维是不是快要无用武之地了？如何去做更智能的活，当下很多运维人在不断思考和探寻答案。
什么是DevOps？
DevOps 是一种工程模式，本质上是一种分工，通过对开发、运维、测试，配管等角色职责的分工，实现工程效率最大化，进而满足业务的需求。
DevOps的核心是角色的分工，而不是组织架构变化，垂直化的组织架构不代表可以实现DevOps所需要的分工模式，横向的组织架构也不代表传统的分工模式。
DevOps的目标是工程效率最大化，它本身也只是一种方法论，是为了实现工程效率最大化的目标而存在的。
DevOps与传统模式的区别

传统分工模式下，PD将需求提出来，开发者根据需求写代码，然后告诉SCM，SCM拿着代码去打包，打包后告诉QA，QA测试完成后通知运维OPS上线，OPS进行上线部署，最后整个需求得到release。
它的优势在于：分工与责任清晰，质量有保障，层层制约，容易把控。
它的劣势也很明显：沟通成本与等待成本高，每一个环节都有成为瓶颈的风险，比如DEV知道怎样写代码，但QA也需要了解需求才能知道怎么做测试，OPS也需要了解需求维持线上稳定性，OPS负责交付，容易演变成擦屁股的角色，包括日常出现的bug。

在DevOps分工模式下，一切都改变了，不再是每个人做完自己的事情然后交给下一个人。这个分工模式下，开发通过工具驱动所有流程运转向前走，比如开发写完代码通过工具驱动自动化打包，自动化测试，自动化部署或升级，还会配备监控；SCM、OPS和QA等在工具的外围，确保在工具中的每一个环节可以正常运转，它们支撑工具的目的是确保DEV可以使用工具完成人肉完成的事情，这是决策的变化，还要保证工具中的几个模块可以支撑最新的业务变化，当业务有了更新的变化时，须保证工具可以支撑开发。
DevOps分工模式的好处很明显：可以减少沟通成本与等待风险，降低正常需求交付所需时间，DEV负责交付，避免交付扯皮。
DevOps分工模式的劣势也很突出：每个环节参与角色较多，风险较高，对于业务形态比较多的企业较明显，工具支撑多种业务形态的成本是非常高的，当工具搞不定时，需要人肉补位保证业务发布，如果补位较多，那么DevOps分工就失败了；专业度会有降低，工具只能支持在精确输入的情况下以非常精确的方式完成一件固定的事情，一旦输入有变化而超出规则，该环节就比较麻烦了，工具的专业提升比人要慢的多；DEV权利过大，容易军阀化。
DevOps的难点和需要解决的问题
寻找平衡点
DevOps是为了追求工程效率最大化而存在的，但是工程效率和稳定性的目标在大部分场景下都是相悖的，如何能够在工程效率提升的前提下，保证稳定性不出问题？
传统分工模式是OPS团队负责，在DevOps分工模式中已经没有OPS团队了，只能开发团队负责，当一个团队同时负责两个相互有冲突的case时，该怎么办呢？如果分成两部分人分别负责业务KPI和稳定性KPI，就回到了传统的分工模式。
责权划分
对于开发者而言，主业是coding，其它包括打包、测试、发布都是辅业，它是工具的使用者，并不能完全将所有事情做得完美，在除coding以外的所有环节中，责任和分工要怎么来分，除了开发以外的事情要占用开发人员多少精力，才能保证DEV使用顺畅，跟上公司业务发展？
其中核心是工具，工具是将二者粘合在一起的，工具起到了赋能和粘合的作用，工具还须可介入，需要人肉补位；另外，工具的进化要运维团队、测试团队和SCM团队来负责，工具自己要足够开放，才能让其它团队可以不断优化某一环节；工具也要保证可持续成长，跟上时代的发展。
制约与考核
打破原先的平衡以后，新的平衡如何建立？重新建立平衡是需要时间的，DEV在工程中话语权加大，权利是一定会被制约的，不是内部，就是外部市场。
每一个问题都要根据公司的实际情况寻找一个平衡点，找到责权划分，怎样去考核和制约，只有将这三个点解完，才可能活下来将分工模式持续跑下去。
DevOps怎么衡量？

DevOps可以由四个角度做衡量：

• 工程效率：从某一个开发的团队接到需求，到需求交付上线的时间有多长。工程效率能够提升多少代表DevOps发挥作用的大小；
• 稳定性：当稳定性没有保证时，效率越高死的越快；
• 非研发工作占比：当占比非常大时，离失败就不远了；
• 业务规模与运维人员比例：谷歌的每一个SRE也要管理2000台机器的业务。

总结

1. 实现自动化运维后，很多运维人员就会面临失业，但这是时代发展的必然结果，我们只需欣然接受；
2. DevOps没有最佳实践，我们该更关注一些案例的环境和业务背景，DevOps本身不是目标，是一个方法，一个理论；
3. DevOps和传统模式没有好坏之分，只有适不适合。

技术原创及架构实践文章，您可通过公众号菜单联系我们或21CTO网站注册后发布文章。