企业运营对 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 意味着流程失控。有两个简单的度量可用于了解你对流程控制的程度:交货时间和报废率。交货时间代表改变所需的时间。废品率是返工频率。预演和可核查的流程可以通过降低废品率和稳定交货时间帮助获得控制过程。流程管控的最大好处是提高可预测变化的能力。业务依赖于这种可预测性。可预测性的业务可以提前规划移动速度的快慢。

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

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

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

生产环境的可见性对于开发人员来说是至关重要的,从而他们可以建立一个类似的环境。模拟声场环境建模开发和测试环境是减少变数并让一切都在控制中的有效手段。

这是否意味着允许开发者进行 Shell访问?

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

这是临时或生产环境中 Shell 访问的请求吗?Shell 访问请求可能是即席改变方法的一个标志,从而改变一个环境的稳定性。因此,对改变方法进行自动化封装非常重要。

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


本文作者:OneAPM 工程师

来源:51CTO

相关文章
|
2月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之如何将个人账号下的Git仓库转移到企业账号下
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
2月前
|
运维 监控 Devops
DevOps文化下的企业运维转型
【8月更文挑战第22天】在数字化转型的浪潮中,DevOps不仅仅是一种技术实践,更是一种企业文化。本文将探讨如何在DevOps文化的引导下,实现企业运维的高效转型,包括理念更新、流程优化和团队协作等方面。我们将一起思考如何打破传统壁垒,构建一个更加灵活、高效和协同的运维体系,以应对不断变化的市场和技术挑战。
39 1
|
21天前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
27 3
|
2月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之缺陷等级管理是否是企业自己划定
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
2月前
|
运维 Devops 应用服务中间件
阿里云云效操作报错合集之从企业仓库里拉取依赖报错403,该如何解决
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法,包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台,为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑,致力于提升企业的研发效能和创新能力。
阿里云云效操作报错合集之从企业仓库里拉取依赖报错403,该如何解决
|
2月前
|
弹性计算 监控 Devops
"揭秘!阿里云云效如何以戏剧性飞跃,重塑企业门户网站部署,一键解锁DevOps魔法,让您的网站秒变行业巨星!"
【8月更文挑战第8天】阿里云云效企业门户网站部署解决方案是一站式DevOps平台,集成云效Flow、Codeup、Testplan等,支持自动化构建、部署与测试。通过ECS实例等资源准备、云端代码托管、持续集成与部署、及全方位监控,实现网站高效稳定运行。采用YAML配置简化流程,确保快速迭代与优化,适用于各类企业的数字化转型。
70 3
|
2月前
|
Kubernetes Devops 测试技术
DevOps实践:持续集成和持续部署(CI/CD)在现代企业中的应用
随着软件开发行业的迅猛发展,DevOps文化及其核心实践—持续集成(Continuous Integration, CI)与持续部署(Continuous Deployment, CD)—已成为提升软件交付速度和质量的关键策略。本文将深入探讨CI/CD的理论基础,并结合真实案例分析其在现代企业中的实际应用效果,旨在为读者提供一套可行的实施指南。
|
2月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之如何管理企业的组织架构
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
2月前
|
敏捷开发 测试技术 API
阿里云云效产品使用合集之一个企业可以绑定几个云效
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
4月前
|
运维 Kubernetes Devops
阿里云云效操作报错合集之Message: code: 403, 当前代码组下无法创建可见性为企业可见的代码库,该如何处理
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法,包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台,为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑,致力于提升企业的研发效能和创新能力。
下一篇
无影云桌面