（接前文）
需要转变
文化转变
从竖井到DevOps
企业IT常常被组织为一些竖井：软件开发、QA、DBA、系统管理、运营、发布管理、项目管理等。这些竖井往往有不同的管理层次、工具集、沟通方式、词汇和激励形式。这些不同鼓励了做事方法的不同。
一个常被提到的例子是开发和运营的不同。 开发的任务是开发功能，往往是通过向企业IT中引入更改来实现的。所以开发部门的任务可以说成是“交付变化”，自然开发部门也往往是鼓励交付更多的变化。
另一方面，运营的任务则可以说是“防止变化”，运营的任务是保持可用性、弹性、性能和持久性。他们往往被鼓励保持KPI，比如平均错误间隔，平均恢复时间等。然而对于保持这些指标来说，最大的风险就是引入变化。结果就是，运营经常不是想办法怎么安全地引入开发期望的变化，而是想办法把让引入变化更痛苦，从而降低变化的频率。
这种不同的做事方法显然带来了低效的合作。协作、沟通、交接工件变得非常乏味和痛苦，甚至是混乱和危险。企业IT往往企图修复这种状况，构建了通过ticket系统和会议驱动的重流程。结果是工作变得更加慢和浪费了。
像这样的环境跟云架构快速的理念完全相左。竖井诞生的原因，往往是希望带来更多地稳定和安全，但实践证明，作用甚微，甚至有时候会带来反作用。
DevOps的核心就是打破这样的竖井。构建共享的工具、词汇和沟通结构，建立文化，为着同一个目标：快速安全地实现价值。围绕这一目标建立激励机制。官僚机构和流程被信任和责任心取代。
届时，开发和运营向同一个直接领导负责，共同寻找办法，既能持续产出价值，又能保持可用性、弹性、性能和持久性。现在发现，云架构相关技术能够为之提供支持。
从Punctuated Equilibrium1 到持续交付
企业往往引入了敏捷过程，比如Scrum，但一般限于开发团队。
我们已经相当成功地将单个的开发团队变得敏捷。我们做了很多改进：结对编程、测试驱动开发，持续集成……，我们已经能很高效地完成“从用户故事到Demo”的循环。但我们的问题是：功能什么时候能上生产呢？
这个问题我们很难回答，它迫使我们考虑一些我们不能控制的因素：
- QA流程需要多少时间？
- 我们啥时候能加入版本计划？
- 什么时候运营能准备好环境？
这时候我们意识到我们陷入了“Water-Scrum-fall” ，我们的团队已经开始敏捷了，但我们的组织还没有。结果，我们每个迭代的成果并不能体现到生产部署，代码其实还堆积在传统的发布循环中。
这种工作模式实际上抹杀了敏捷的两个关键好处。
- 客户仍然要隔好几个星期才能看到新东西，感觉不到敏捷的好处，所以并不能如约与开发团队建立信任关系。他们倾向于回到老的工作方式：把尽量多的需求都塞到版本里——由于他们不太相信软件能够快速发布，于是宁愿最后好不容易发布的时候能多交付点东西。
- 开发团队可能要好几周才能得到真正的反馈。Demo是很不错，但开发人员都知道，只有真正的用户使用了真正的生产软件，才能产生好的反馈。这样的反馈才能提供有效的修正，团队才能真正做到“build the right thing”。如果反馈延迟了，错误堆积起来，返工的成本就很高。
想要得到云架构的好处就需要转变到持续发布。
技术上我们可以做到每个迭代（甚至每次代码提交）自动部署到生产。我们建立部署管道，在此执行自动测试，防止生产问题。现在唯一需要做的是业务决策：现在是否是发布新特性的好的业务时机？由于部署管道是全自动的，业务决策好后可以一键实施。
从中央集权到分散自治
Water-Scrum-fall文化中有一点值得特别指出，因为我感觉是使用云的过程中的一个绊脚石。
企业经常围绕应用架构和数据管理建立中央集权组织，负责维护守则和标准、审批设计和更改。中央集权确实有几点帮助：
- 可以防止技术栈的不一致。降低组织的维护总成本。
- 可以防止架构选择的不一致。
- 合规管理之类的Cross-cutting concerns可以在组织内保持一致。
- 数据的所有权可以一目了然。
这些组织建立起来是为了提高质量和降低成本。但收效甚微。同时还影响了云架构在快速方面的努力。单体架构可能成为技术创新的瓶颈，巨大单一的管理组织也一样。有时候一个小的变化只需要几分钟就能完成，而且也肯定会通过评审，但却需要很长时间来等待评审会议的召开。
使用云架构几乎总是伴随着去中心集权。开发云架构应用的团队（“Business Capability Teams”2）几乎拥有了交付所需要的所有的能力。他们拥有数据管理、技术栈、架构、每个部件的设计以及API合同。如果有什么决定需要做，那就是这个团队就能做了。
去中心和自治的团队通过集成模式规定的机制来制衡，这些机制存在于团队开发的服务之间，通常很小很轻。（比如使用HTTP REST JSON风格的API，而不是各不相同的RPC接口。）这些机制通常最先出现在基层，用来解决一些共有问题，比如“错误容忍”。我们鼓励各团队自己设计解决方案，然后自组织地与其他团队一起形成公用的模式和框架。如果出现了对整个组织都好用的模式和框架，那么就将这些模式、框架转交给“云工具、框架团队”。工具框架团队可以是平台团队3的一部分，也可以不是。在整个团队对架构形成共识的过程中，工具框架团队和他们的方案，将起到带头作用。