过去，基础设施部署和应用程序更新一直是减缓开发生命周期的两个主要障碍。在云计算蓬勃发展的今天，企业用户可以在几分钟内完成过去需要数月的资源分配工作，从而给应用程序生命周期带来相应的变化。话虽如此，虽然DevOps确实可以提供很多帮助，但只有积极超越“文化变革”的视角，这种新方法才能真正使持续部署成为可能。正如我在上一篇专题文章中所说，很明显，云计算为应用程序带来了更多的可能性、要求和巨大的变化。通过那篇文章，我着重讨论了技术变革，评论了云计算对应用架构的影响——相信你已经感觉到，今天的应用架构开始支持不断增加的规模和负载变化，更强的性能要求，以及云计算引发的定价模型的变化被纳入设计思维。但是我并没有说到当时云计算颠覆的另一个传统应用元素，即应用生命周期。具体来说，云计算需要匹配更快的应用程序管理节奏，这将迫使IT部门做出相应的调整。从表面上看，可能很难理解为什么云计算带来的技术能力会对IT部门及其运营流程产生影响。然而，云计算通过技术能力带来的关键基础——即自动化特性——必然需要更快的应用程序生命周期来匹配。云计算给IT带来压力——而不是基础设施问题。在这种情况下，底层基础设施资源将承受巨大压力，因为应用程序功能的快速改进和生产环境的频繁更新成为运营流程的前提。应用程序开发和部署的周期时间很少是主要冲突，因为采购、安装和配置基础设施需要很长时间。换句话说，基础设施挑战掩盖了应用程序周期。云计算的自动化特性消除了所有基础设施冲突。今天，大量新的计算资源在几分钟内可用——这在过去是不可想象的，因为在过去通常需要数周或数月才能使新的基础设施资源投入运行。显然，当前基础设施配置所需的具体时间取决于IT部门的执行过程，不再受限于底层基础设施资源本身。与此同时，数字信息越来越多地与主流商业产品相结合。以联网的Nest恒温器为例。这类产品意味着业务执行的实际效果开始高度依赖于应用功能可用性的交付速度。没有基础架构施加的限制，主要障碍现在已经转移到应用程序生命周期本身。因此，我们可以预见，下一阶段的主要矛盾将是云计算与应用开发部署流程错位造成的。简而言之，IT部门必须加快应用程序的生命周期。面对这样的矛盾，DevOps应运而生。这个混成词结合了“开发”和“运营”，代表了原本相互独立的组织和流程的正式整合。这个新术语所代表的愿景是通过简化的集成组织的联合操作流程来加速应用程序更新，将应用程序生命周期从几周缩短到几个月，再缩短到几小时或最多几天。但是DevOps如何给我们带来神奇的提升效果呢？文化变革是必要的，但仅靠变革本身还不够。文化变革是我们经常听到的解决方案之一。从这个角度来看，开发人员和系统管理员通过加入同一个团队来相互协作，从而增强联动效果，最终加快应用程序的生命周期。我个人不太看好这种方案。是的，开发系统和运营系统之间经常存在冲突，让来自同一团队的人加入肯定可以改善关系。平心而论，此类计划确实有可能通过促进协作和减少责备来推进当前的工作状态。然而，在科学层面上，很难明确证明改善的关系与更快的应用程序功能发布周期之间的必要联系。无论如何，渐进式改进是不够的。企业不能仅靠功能构建效率提升20%来保证在未来数字化商业环境中的成功。因为在这种情况下，实际效果只能是把项目的开发周期从过去的21天缩短到现在的18天，或者举个更通俗的例子，把原来的6个月缩短到5个月。要想在当今激烈的竞争中保持优势，业务流程的速度提升至少要达到200%才算合格。此外，“文化”一词也具有误导性。文化关注人的因素而不是过程——过程的中断。话又说回来，即使速度提高了，流程本身也需要真正贯穿应用程序生命周期，才能交付真正的结果。也就是说，我们在软件工程层面取得了重大进展。在过去的十年中，开发实践、灵活的工作方式、频繁的签到以及自动化机制的创建和测试导致了相当大的加速。这场被称为“持续集成”的革命帮助我们缩短了开发周期，减少了项目事故，并使整个项目过程更具可预测性。但对于大多数IT部门而言，当涉及到将新代码投入生产时，应用程序生命周期的加快步伐往往会止步于此。在运营情况下，由于每个下游团队都需要使用他们选择的工具来完成任务，每个环节往往需要手动重复执行，重复重复——这破坏了流程的自动化特性。唯一的解决方案是确保IT部门实现持续部署。在这种情况下，代码修改将贯穿整个自动化应用程序的生命周期。业务流程的快速响应和频繁的功能更新带来的稳定性影响也将得到解决。消极的一面是，持续集成增强了IT对自主解决方案的信心，使企业难以将应用程序供应商纳入整体操作系统。我听过很多关于持续部署的争论。他们分歧的核心是恶意代码进入生产环境的可能性，以及端到端自动化实施后恶意软件的严重后果。归根结底，争论的本质是自动化流程在没有人为因素的情况下可能会出错。先不说这样的结论和胡说八道的区别。其实根据我个人的经验，即使有人为干预，还是有可能出现问题。此外，人为干预也可能是问题的原因，所以我不赞成那种说辞。在任何情况下，手动执行流程的要求最终都会被用户要求所否决。固守既定的方法将是完全徒劳的。如果您不相信，只需询问VMware的系统管理员——要求开发人员等待数周才能获得使用虚拟化巨头内部资源的批准的开发人员将他们的虚拟机直接交给了AmazonWebServices。持续部署需要一个自动化的、集成的、平衡的激励机制。为了实现持续部署过程，必须满足以下四个先决条件。一套简洁的自动化流程。如果流程中包含审计委员会设定的阶段性目标，未经批准无法进入下一步执行，或其他形式的人为监督机制，那么整个系统的运行效率必然会大大降低。虽然我们认为某些更改应排除在自动化流程之外——可能是由于复杂性或其他特定因素——但这与将所有更改都视为人为干扰不同。理想情况下，在必要时引入人为干预，否则常规更改由自动化流程处理。集成的端到端工具链。很明显，自动化工作流程是一个死胡同，除非整个过程得到其底层理想工具的支持。从本质上讲，这些工具在某一阶段输出的内容必须是下一阶段工具可以接受的，也就是各种工具之间可以顺利衔接。今天，我们可以直接从大厂商那里购买昂贵的专有产品，也可以基于开源组件自主构建适合实际需求的功能集。任何解决方案都有优点和缺点。随着该领域的重要性与日俱增，市场对它的关注度也会随之提高。相信很快市场上就会出现更灵活、更实惠的解决方案。共享应用程序工件。新工具中使用的组件必须能够与整个系统顺利连接。由此产生的可执行文件和配置，甚至包括自动操作指令的开发，都可能导致潜在的错误，进而影响功能的快速可用性。相比之下，最理想的处理方式是全程使用单一的组件集，通过增减权限划分适合需求的组织结构。确保指标和激励措施在整个企业内保持平衡。说到激励，我们又回到“文化”这个话题。如前所述，我个人不相信仅仅发展关系就足以将不同的群体聚集在一起，甚至完全消除协作中的摩擦和错误。要真正达到这样的效果，平衡的评价指标和激励机制是重中之重。如果我们以功能更新的发布频率作为一个团队的评价标准，而以运行的稳定性作为另一个团队的评价标准，那么双方就会因为没有可比性而在性能评价上产生冲突。我们需要通过一系列更多的举措，把每一位成员紧密地团结在一起。不要以为把上面提到的所有指标都塞进去就能得到想要的结果。事实上，要求同一个团队频繁发布更新并保证结果的稳定性，这本身就会引起严重的不满。——显然，这样的目标需要多个团队的配合才有可能。当然，这些建议也有一定的缺点。其中最主要的是它们难以实施并且会严重破坏现有流程。是的，如果我们十年前生活在IT世界，就不需要这样的颠覆性创新。然而，历史的车轮无法倒转。在当今的科技世界中，企业变革的步伐正在逐渐加快，我们不得不对运行多年的IT流程进行调整。为了追求效率和降低运营成本，我们需要面对否定过去三十年经验的痛苦和阻力。过去总是美好的，但IT部门永远无法重拾当年用三十年完成同一任务的无情日子——今天，有一个更严格，但没有妥协的要求，除了接受，别无他法.英文原版：DevOps如何加速云应用生命周期
