转载

企业对DevOps的偏见，及几个转型建议

【编者按】近日，Alex Honor在 dev2ops 上撰文阐述了当下企业对DevOps所存在的偏见，并就造成这些问题的原因分享了企业该如何向DevOps模式切换。

以下为译文

笔者曾帮助多家大型企业深入了解DevOps，帮助他们理解如何改善服务交付能力。这些公司大多听说过DevOps，也在四处寻求一个策略来采用DevOps方法，从而进一步占领市场，提升产品质量。出于各种原因，并非所有人都信任DevOps。有些人觉得DevOps只不过给开发者改善产品提供了一个途径而已，还有的人觉得DevOps是一堆悦耳的空头支票，甚至有人认为DevOps根本无法采用，因为其所在领域所必须的自动化工具根本不存在。

通常在企业里，运维通常由一个集中且独立的团队完成，同时他们需要支撑多个应用程序组。如果网站的可用性出问题，责任就落在运维团队身上。一旦出现性能问题、宕机或故障，运维团队无疑是第一道防线，但有时问题升级会返回到应用组去修复bug或者帮助诊断问题。

对DevOps感兴趣的企业往往实践或采用了一个对运维需求非常搞的敏捷技术，比如建立一个测试环境，或者测试节后发布软件到生产环境。持续加快的步伐给运维团队施加了很大的压力，因为大多时候工作集中在项目后期（例如，是时候发布到生产环境中）。迫于时间压力或者过量工作，运营团队很难完成相对请求，甚至有时听到开发者埋怨想亲力亲为。那些用户可能想重建服务器、获取shell访问、安装软件、运行命令和脚本、设置虚拟机、修改网络ACL和更新负载平衡器等。他们认为有些事情还不如自己来做，从而不再需要高度集中的运维小组。

如何让运维团队，一直负责生产环境运行时的部门能扩展其支持的环境？他们应该如何避免成为各应用团队项目周期尾端的瓶颈？如何让业务更加稳定可靠，而不是混乱、中断或不按预期执行？

如果你身处这种企业环境，又该如何进入DevOps？如果你身处高度集中的运营团队，又该解决采用DevOps的压力，这里有几个问题需要企业团队谨慎考虑，问题的答案则是一步步形成DevOps战略的重要步骤。

那么，一个高度集中的运营团队如何处理必要任务，使得应用程序可以在生产环境或其他环境下顺利运行？

在有些企业中，初期会创建一个名为“devops”的专业团队来解决各种“devops问题”，这便是良好运营的开端。这个团队可能会负责接手开发团队的应用程序，使用自动化工具进行打包，进行部署并将其转交给Site Reliability团队。不幸的是，集中式的devops团队也可能变成“silo” ，也要不断接受传统运维组所面临的“项目末期”交接挑战。同时，随着更多的开发者和开发项目涌入，devops工程师和devops团队再次成为瓶颈。集中的devops团队和传统的QA部门一样，当他们尝试“添加质量检测”作为一个独立过程阶段时，也不得不面临同样的压力。

为了确保应用程序可以在生产环境以及其他环境下正常运行，devops重点必须嵌入应用体系结构。这就意味着，让应用程序易于配置、部署和监控均在开发阶段完成。集中的运维团队必须学会开发一个共享式软件交付流程和工具链。在交付工具链内部，任务可以分布在多个团队。集中的运维组可以支持工具链，正如架构师和服务提供者提供给应用开发团队一个基础框架，而在填充所需的构件就可以驱动这个管道。

什么是合规策略（compliance policies）？

大多数企业都遵循一个修改策略，即预先指定谁可以在生产过程中做出修改。很多时候，这一策略常常被理解为除了运维组以外，其他人都不能发布更新。这种切换可能导致交付时间拖延，同时如果在传递过程中丢失信息，甚至可能导致故障发生。

这些规则都是由企业制定的，但事实上，在交付端的职员从未去认真地去理解这些政策的语义，他们通常根据想象或者习惯去判断。而随着时间推移，工具和流程往往发酵成无效率的官僚机构。

基于应用或客户类型，通常会形成不同的限制规则。当涉及到如何缩短交付周期时，这些差异应该纳入考虑，因为它能帮助你发现究竟谁可以做出更改，以及修改该如何进行。

除了主动理解规则，规则同样需要做到快速和便捷地审校：

简单易懂的规则能清晰展现以下内容：>

谁做出了变动以及是否有权限
改变应用在哪里
具体的改变内容，这些调整是否能接受

这种查询应该能即时访问，而不是在某个事情后（比如故障发生）通过人工收集得到。当你拿到服务器过去24小时的工作报告时，便能轻而易举了解到环境中发生了哪些变化。

这些审计视图应该包含基础设施和工件信息，因为不管是开发者还是运维人员都想清楚软件和服务器的信息，一堆不明所以的修改信息和错误链接报告无论如何也无法组成一张全景图。

如何开放访问又不会失去控制？

通过审视软件交付的整个过程工作流全时监控将变得简单，在以往这个工作通常由一个独立的团队完成，他们往往以往竞争优先级导致的上下文切换而变得没有效率，这种情况通常在运维团队发生。运维团队需要平衡来源于应用开发团队的工作（例如，参与敏捷开发冲刺）、网络操作（例如，处理中断和生产问题）、企业用户（例如，收集信息用于控制策略）。最后，运维还需负责维护或改善基础设施等项目工作。

为了释放这个流程的瓶颈，企业必须发掘应该如何重新分配工作，或者建立一个自服务流程。因为部署、配置和监控都是需要设计到应用中的运维问题，一次需要将之一定程度地传递给开发人员。聚焦这一系列动作，运维团队需要维护一组基本的自动化模块，给开发人员相应方法来参与。创建一个开发环境和工具允许开发人员在自己的沙箱中将所需的改变整合到这个框架中。通过自助服务界面让开发人员可以便捷地创建托管环境，打开VMs或者容器，允许他们测试运维管理代码。

给运维管理框架构建合规的审计日志，便能跟踪到哪些资源被创建和使用。一旦资源发生冲突，这些日志将会有非常大的帮助，并让你了解到哪里需要更多的沙箱或者哪些更细粒度的配置需要定义。

欲速则不达，速度越快反而导致质量下降？

对于企业来说，不断提升创新速度才能保持竞争力，所以速度至关重要。因此这里需要更快的软件交付速度，也正是采用DevOps做法的主要动机。

许多DevOps成功案例都在展示其一天能部署多少次，10还是1000。但是在现实世界中，这些指标简可以称得上是神话。有些企业尽量一个月实现一次部署，还有些企业一个主要版本更新需要按年计算，而发布给用户更需要30天的时间。这三十天的滞后时间，同时生产环境处于不一致的状态，所有人都难以应付生产中出现的问题。“是新版本还是旧版本造成了这个尚未确定的问题？”操作无法加快的一个主要原因是无法确定问题究竟是发生在改变期间或改变后。

当改动导致问题，可能导致以下结果：

添加更多控制过程（审批门槛更多，改动窗口更小）
改变批次变大（更多的工作塞到给定的变化窗口）
增加“紧急修正”（高优先级功能得到快速跟踪，才能避免正常的变化流程）
因为批系统和非正常软件发布流程，应用程序快速更新将带来很大压力。

鉴于以上后果，加快改变速度的想法显得不切实际，因为它确实可能诱发更多的问题。

问题是企业该如何快速给系统做更新？首先，指定更新过程中的安全策略非常重要。快速转变意味着能安全地快速改变。下面是一些常见策略：

小批量

大批量改变所带来的工作量需要耗费大量的人力和时间。

解决办法是利用这种策略：变化越少越容易实现，完成后也便于检查。

预演

这里有一个很好的谚语，“Don’t practice until you get it right. Practice until you can’t get it wrong”。当然，你不能在生产环境中实践这个途径。将更新应用到生产环境之前，你应该在非生产环境下进行多次实验。不要依赖于运气，要抱着必然存在故障的理念。

可核查的流程阶段

不管是新建立的一个网站或者是现有应用程序需要更新，请确保已经为先决条件做好了足够的检查。也就是说，如果你要部署一个应用，在这之前你就要准备好脚本测试，来证实你的外部或环境依赖性。如果你正在构建一个网站，在安装操作平台之前，保证你已经确认好硬件和网络环境。在流程阶段边界构建这种自动化测试，对于防止问题遗漏是一个巨大的安全保障。你可以使用这些验证检查来决定“stop the line”。

流程规则

是什么导致了环境中布满了特殊定制的服务器和网络？缺少规则。如果企业无法统一管理变动，每个人都会按自己的方式行事。那如何对流程进行管控？搜寻所有不同的版本。如果流程在两个版本中不同，那么就意味着这里存在一个variation。流程variation意味着流程失控。有两个简单的度量可用于了解你对流程控制的程度：交货时间和报废率。交货时间代表改变所需的时间。废品率是返工频率。预演和可核查的流程可以通过降低废品率和稳定交货时间帮助获得控制过程。流程管控的最大好处是提高可预测变化的能力。业务依赖于这种可预测性。可预测性的业务可以提前规划移动速度的快慢。