企业运营对 DevOps 的「傲慢与偏见」

摘要：出于各类缘由，并不是全部人都信任 DevOps 。有些人以为 DevOps 只不过给开发者改善产品提供了一个途径而已，还有的人以为 DevOps 是一堆悦耳的空头支票，甚至有人认为 DevOps 根本没法采用。

【编者按】近日，Alex Honor 在 Dev2ops 上撰文阐述了当下企业对 DevOps 所存在的偏见，并就形成这些问题的缘由分享了企业该如何向 DevOps 模式切换，本文系 OneAPM 工程师编译整理。

笔者曾帮助多家大型企业深刻了解 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 意味着流程失控。有两个简单的度量可用于了解你对流程控制的程度：交货时间和报废率。交货时间表明改变所需的时间。废品率是返工频率。预演和可核查的流程能够经过下降废品率和稳定交货时间帮助得到控制过程。流程管控的最大好处是提升可预测变化的能力。业务依赖于这种可预测性。可预测性的业务能够提早规划移动速度的快慢。

更多途径进入运维管理环境？

每一个人都更好地了解生产中各部分是如何执行的，能够帮助企业设计更好的系统来支持业务。若是开发人员或测试人员都难以发现服务运行的问题，只会耽搁有利于用户操做的改进。让任何人都能容易地了解到应用版本在主机是如何部署的，以及主机配置和应用程序的性能。

有时数据隐私规则使得数据访问并不那么直接。一些日志包含客户数据和规则可能限制有限的用户访问。不要说「没有」或手动地去收集和清洗，这里须要存在一个自动化的自服务，从而让开发者或审计人员能够本身获取。

生产环境的可见性对于开发人员来讲是相当重要的，从而他们能够创建一个相似的环境。模拟声场环境建模开发和测试环境是减小变数并让一切都在控制中的有效手段。

这是否意味着容许开发者进行 Shell访问？

这个问题是传统企业运营团队的弊病。一般这个问题是另外一个问题的征兆。为何一个开发者要 Shell 访问运维支持的环境？在开发或早期的测试环境下，开发人员可能须要Shell访问来实验开发部署和配置代码。这的确是申请 Shell 访问的一个合理理由。

这是临时或生产环境中 Shell 访问的请求吗？Shell 访问请求多是即席改变方法的一个标志，从而改变一个环境的稳定性。所以，对改变方法进行自动化封装很是重要。

归根结底，Shell 访问生产环境确实有很大的风险。

原文连接：http://dev2ops.org/2014/06/adopting-devops-in-enterprise-operations/

本文系 | 31a86d24833cfae285650a96be0588874 | 工程师编译整理。想阅读更多技术文章，请访问 OneAPM 官方博客。