我们离DevOps有多远

renyanping

　　Wikipedia对DevOps的定义是：
　　　　DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。
　　持续集成思想
　　怎样才能达到这样一种状态呢，我们先放一下，看看持续集成（Continuous Integration）体现出来的一些思想。
　　纵览全局（打破职责界限）
　　rd，qa，op，如果仅仅按照这样的角色标签去处理事情，那就和圣经里的巴别塔一样，大家不说同一种语言怎么能劲往一处使呢。
　　我们把目标放得更远一些，不再为了赶代码而将质量保障交给qa和op，不是为了增加测出bug的数量而和rd争论，不是为了减少变更而是积极的适应变更，我们共同的目标是实现商业目的，确保软件质量（也包括变更质量和运行质量）也是其中的一部分。频繁的变更不是质量的杀手，而应该在软件开发整个流程多个环节进行质量的保障，并频繁的运行这些保障。
　　这种方法就打破了目前的rd->qa->op流水线的流程，而是将三者紧密的结合在一起。从实践的结果来看，rd每次提交代码都会触发一系列的自动化步骤，包括编译，单元测试，代码覆盖率，功能测试，部署测试，性能/容量测试（注：后两者受限与时间要求，实际实施不会每次提交代码都触发）。Rd，qa，op都在过程中做质量保障。

　　是努力减少变化还是在变化发生时做好准备。一定是后者，因为当一件事情频繁发生时，问题才会大量的暴露。解决暴露出来的问题才能促进业务更好的发展，也是对团队能力的提升。
　　拿一个的实际例子，部署测试（Deploy check）和性能/容量测试（capacity test），我们比QA有更多的资源和条件，那么我们就应该主动承担起这份工作，然后将其加入到整条质量保障线的必要环节上。

　　浑然一体（而非七零八落）
　　代码树被管理起来——主干开发

　　主干开发的好处是每个rd都知晓整体的变更，所有的feature作为一个整体发布，对OP的现实意义就是上线变得更有规律，非计划的、临时的上线最后消失。
　　代码和周边（配置，数据，构建脚本，单元测试，测试用例）统一作为产品被管理起来——一键式产构建，测试，部署，完成产品的最终发布。
　　SVN结构样例
　　module
　　|--product
　　|----code
　　|----bin
　　|----scm_product.conf（描述程序地址）
　　|----module_control
　　|----conf
　　|----data
　　|----data_description（描述数据存放地址）
　　|----ci-script
　　|----test_case
　　|----build_script
　　|----test_script
　　|----deploy_script
　　|--development
　　|--test
　　好处易见，生成一个完整的产品的所有原料都被管理起来，上线仅需要一个版本号，不会出现上线时冗长的步骤，做版本diff，部署环境diff，测试case diff都非常简单。而且，环境的备份也变得简单和纯粹了。
　　研发（开发，测试，发布，部署）全过程被管理起来。所有角色在一个界面下工作，使用共同的平台，统一的源码管理，共享。

　　大家都在一个平台上工作，所有的任务都在这个平台下，各角色间对互相的工作有更深入的了解，并且，工作状态也可以共享。
　　少就是多，简洁就是美（用简单的方法解决问题）
　　持续集成的解决方案是简洁的。产品由SVN去管理，构建过程由CI server负责，而构建过程包含了编译，测试，发布，部署过程

　　没有封闭的系统，没有蹩脚的流程，配合开放的系统（Code Review/wiki）所有的信息被自然的整合在一起。而一切都是以提高变更速度，提高产品质量为目标。
　　当解决方案让你觉得不自然（或有很多内容无法囊括，或需要人为干预）的时候，那这个方案就不是一个完美的方案，必定在某一些方面受到了限制，这些限制有可能是历史造成的。要勇于质疑，扩展角度，提升高度。去掉角色的限制，站在产品的角度去思考，对于整体的优化的解决方案就产生了。
　　以终为始（一直以发布级的质量要求产品）
　　写代码都是为了要发布的，也就是需要上线使用的，那在开始编码就以产品的质量要求代码，要求check in的代码就是能够完成编译的，具备一定功能并且可以部署的产品。
　　将质量内建于产品中。每次代码的提交都会经历单元，功能，部署，性能/容量测试。在上线前我们就能够知道是否能成功部署，线上的服务器是否能撑住。这样的产品在上线时我们就不会有那么大的压力了，OP也不需要担心回滚的风险了，即使回滚，那么回滚也是one step。小菜一碟。
　　我们与DevOps的距离
　　那么我们离DevOps有多远呢。从各个公司放出来的技术资料（flickr最全面），最经典的是flickr的10+ deploys per day，他们的最佳实践有以下几点，而起穿针引线作用的是持续集成（技术上）和思考方式（文化上）。
　　Culture：
　　1.respect
　　2.trust
　　3.healthy attitude about failure
　　4.avoiding blame
　　从文化上，我们需要一种氛围，不仅仅把自己看作rd，qa，op这样的角色，哪里有质量缺口，我们就要把它补起来；哪里有不通畅的地方，我们就要把它疏通。RD了解op的部署方式，能够获取OP提供的监控指标；OP也了解RD的开发方法，开发流程，所面对的问题。放开自己的眼界，从更高的视角看待和解决问题。
　　Tools：
　　1.Automated infrastructure（自动化，系统之间可集成）
　　2.shared version control（SVN共享源码）
　　3.one step build and deploy（持续构建和部署）
　　4.feature flags（公司内部称为single branch，主干开发）
　　5.Shared metrics
　　6.IRC and IM robots（信息整合）
　　技术上的这些要点被3（持续集成/部署）一线贯穿。
　　4点（主干开发）是持续集成的前提
　　1点（自动化），2点（代码及周边集中管理）是实施持续集成的必要条件
　　5点是1的一部分（图表是由自动化系统产生的）
　　可见，技术上的核心是持续集成/部署
　　5所提到的有较高的技术要求。要求我们将业务/运维上的指标变得可测量，直至可预测。这里面的两个核心技术内容就是：
　　容量测量（Capacity management）
　　容量的变化体现在用户行为（流量）系统变更（软件性能）和资源（服务器数量，冗余度计划）等几个因素的变化上，将容量和这些变化挂钩，在每一个因素变化下重新得到系统的容量，从而在变更中控制容量不足造成的风险。有一个要点，我们需要的是系统的容量而不是单个模块的性能。
　　质量反馈（Quality feedback）
　　变更会导致质量变化，而质量变化体现在各种指标上，而测量这些指标（包括应用指标：平响，处理效率等和系统指标：负载，网络流量），发现指标之间的规律，将指标share给整个团队，从而有效的达成质量的反馈，控制变更（包括内部变更和外部条件的变化）造成的质量下降的风险。本质上说，容量测量也是质量反馈的一部分。
　　在实施持续集成的过程中，并行实施的三个项目：
　　持续部署/一键式部署（continuous deployment/one step deploy），
　　容量测试/管理（Capacity Test/Management）
　　质量反馈（Quality feedback）
　　分别对应于上面三个要点，共同支撑系统的高速迭代，减少系统频繁变更引发的风险。
　　借助于持续集成，我们在实践中向DevOps迈进了一大步，离业界的最佳实践已不远。dev和ops说着同一种语言，共同为业务发展和质量保障做出贡献。
　　敏捷/精益开发方法可以提高应变业务变化的能力，并内建质量。DevOps把开发和运维的沟壑抹平。那么我们的development和ITIL就能够结合到一起了。

　　我们曾经愿景将服务器放到机架上，一键就能完成服务上线，我们已经有了一个好的开始，这个目标就会实现。

【本文首发于：百度运维空间】http://hi.baidu.com/ops_bd/blog/item/74d7710916d8aafe37d1225a.html
【关注百度技术沙龙】