响应有回声、应答之意；响应力常比喻应答敏捷，反应迅速。从业务部门看，IT组织响应力就两种体现形式，第一需求转化周期；第二故障恢复时间。
随科学技术进步，各行业信息化、智能化步伐进一步加快，IT技术深入工作中各个环节，IT系统面临的应用场景越来越复杂，随市场变化越来越快。在这种背景下大公司不一定能够战胜小公司，但反应迅速的一定能战胜反应慢的，思科CEO钱伯斯用“快鱼吃慢鱼”总结internet时代。
在这个时代，几乎人人都有移动设备接入互联网，因此很多商业模式都要通过IT信息系统落地，很多市场变化，要通过IT信息系统应对。这是业务部门渴望IT响应力的原动力。
记得2016年支付宝用2.6亿拿下猴年春晚的独家互动权，而红包创始人微信却意外落选，由此引发了双发红包大战，据传双发IT部门为了支撑自身红包业务发展，应对市场环境变化（PS——主要针对对方）平均不到3个小时就发布一个版本，并且全国投产。这仅仅是金融支付市场血战的一个缩影。
今天，金融市场竞争非常激烈，支付宝、微信支付、P2P等小贷公司蚕食银行传统市场；社保卡增加金融功能、利率市场化等政策压力；各地更有很多信用合作社大批涌现，与我们展开全面竞争。IT响应力对于现代企业就像燃料对汽车一样重要，已经是现代企业核心竞争力之一。
不过在传统的IT组织中，由于当时技术所限，安全是通过不同角色间的复查、审核实现的。相关角色形成部门，部门职能是相互制衡的，简述如下：
维护部门目标是提供稳定、安全、可用的服务。
开发部门目标是响应变化，按时交付变更。
质量管理部门（泛指质量保证、质量检验）目标是找bug，把风险扼杀在萌芽态。
目标的设定决定了彼此之间的竞争关系，无论处于哪个位置，尽责就要和另外两个角色“打架”。结果是我们不得不停下手中工作，花大量时间开会同步信息，以求达成一致认识。等待协调上花费的时间不仅延缓进度，而且磨灭我们的激情。在外部，业务部门会质疑我们的效率，会试图缩减IT预算转求外包；在内部，团队成员加班加点、赶工交付，但因为各种原因被迫等待，辛苦得不到收获，工作没有成就感，慢慢变得消沉甚至跳槽。
响应力不仅是组织的核心竞争力，也是团队成员成就感的源泉。响应力的反馈作用，让团队成员看见自己努力的成果，即增加团队成员成就感，也帮助团队及时纠偏。业务上对IT部门响应力的诉求、IT人提升成就感、存在感的意愿推动了DEVOPS的发展。可以把DEVOPS认为是开发(软件工程)、技术运营和质量保障(QA)三者交集，如“图1 DEVOPS角色关系”所示。在DEVOPS中开发人员称为“development(software engineering)”；系统、应用等的运维人员统称为“operations”；质量保证人员、测试人员称为“quality assurance（QA）”（这里的QA不仅是软件质量保证，还包括运维等质量保证）。
图1 DEVOPS角色关系
图2 DEVOPS能力环
DEVOPS希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。业内总结出了“图2 DEVOPS能力环”，良好的闭环可以大大增加整体的产出。吸收CI、CD等传统工艺，又大大平滑了传统开发向DEVOPS过度过程。
当然，DEVOPS不仅是CI+CD，DEVOPS是一种企业文化 、工艺、工具技术有机融合的工程实践。它起源于敏捷社区，主要由三部分组成，文化是基础，因为检查复核成本很高，培养相互信任、有共同行为公约的企业文化是优质高效的基础；其次是工程方法，包括流程机制、各种技术规范等，工程方法指导大家工作，提高配合程度。在文化和工程方法之间就是工具技术，用来将工程方法落地实施，提升工程方法实施效率，更为重要的是为文化建设提供及时、精准的反馈。
DEVOPS文化融合了敏捷思想和质量文化，不同于敏捷主要关注需求交付，DEVOPS更为重视产品生命周期的管理。也不同于质量文化中要求责权津渭分明、各管一片（受笔者视野所限，不代表全部），DEVOPS更为强调系统的思考，对产品生命周期负责、对最终结果负责。在工艺上，更多的是博采众长，只要能够促进提升响应力这个目标，就引入使用。工具上(受笔者视野所限)目前能看到的主要是融合CI、CD以及围绕CI、CD开展的提升业务连续性的支撑技术、质量检查技术。
在DEVOPS建设过程中，需要细分需求转换时间和故障恢复时间这两个指标到工程过程中去，统筹开发、测试、运维过程，促进各角色深度合作，使他们的工作过程更连贯紧凑，为提升响应力服务。按照TOGAF企业架构设计方法，在确定提升响应力为我们DEVOPS的“愿景”后，我们需要把愿景转换为管理目标和架构目标，这样才能形成过程、工具方法、人的有机配合。
图3 DEVOPS 目标分解 如“图3 DEVOPS目标分解”所示，愿景可以进一步细分为业务目标，包括缩短需求转换周期、缩短MTTR时间、提高业务连续性、促进开发、测试、维护等角色深入融合。依据业务目标，团队在尝试DEVOPS实践时管理目标就明确了，管理目标中包括了团队工作流程、工作规范、开发工艺标准等。为提升团队过程执行效率、保证管理目标有效落实，我们定制了一套工具用来支撑我们的管理目标实施，这就是我们称之为CDP的持续发布平台，CDP不是一个系统，而是多个系统工具的整合平台。在DEVOPS建设中首先通过标准化，提升协作默契，然后通过工具化，自动化提升效率，最后通过数字化、可视化缩短反馈周期。因此，我们DEVOPS建设目标是“标准化、工具化、自动化、数字化、可视化”。
围绕DEVOPS目标，我们将整个建设过程分四个阶段：
夯实传统工艺，提升持续集成、持续部署、自动化质量检验、产品可用性等质量检验能力。
打通CI、CD，在固定的物理机/虚拟机上实施应用程序的CI、CD，在这个阶段DEVOPS需要手工准备系统、中间件等配置，需要手工编写好作业流，CD过程只能在固定的环境上重复运行。业内有人也将这种DEVOPS称为第一代DEVOPS。
基于资源池的全栈自动部署，这个阶段的显著特征是引入Iaas云平台，或者其它等价的资源池化技术，IT基础架构中有“配置中心”能够实现任何服务全栈快速重建（全栈指从虚拟机创建到应用部署验证过程）。实现产品环境全栈自动化、IT环境一键部署、资源按需分配、集群故障感知。
跨云DEVOPS，这个阶段的DEVOPS能同时使用不同的资源池化技术，能够平滑的在不同的云平台上按需移动。这阶段主要是考虑不同公有云有不同的优势（区域性优势、竞争优势等），共有云和私有云可能会混合使用，因此DEVOPS需要支持跨云持续交付的能力。
DEVOPS的愿景是提升IT组织响应力，这很难通过买个工具来实现。DEVOPS的建设过程是文化、工艺形成的过程；是不同角色之间、人与工具之间就是默契配合的过程。DEVOPS的核心是融合PO、QA、开发、运维等角色，减少他们之间的PK、返工、等待、转换适配。通过DEVOPS，全职能团队能够快速交付成果，检验那些软件特性能够提升用户体验，推进组织战略目标。
而SA、DBA、QA、INFOSEC等角色把专业知识注入检查工具、平台系统和工程方法中，这样不仅保证了团队节奏不被技术管理打乱，有促使技术管理在项目初期就进入项目，提高整体质量，进一步避免返工。
在“快鱼吃慢鱼”的时代，敏捷是我们的心法；DEVOPS是我们绝招利器，我们以快应变。
(本文于2017-03-02首次发布)
