想要从 Ops 转向 DevOps 吗?以下是你需要了解的内容。
什么是 DevOps?
DevOps 优势
DevOps 与传统 Ops 有何不同?
心态转变
基础设施
自动化是关键
失败和错误
提高可见度
工具
入门
DevOps 方法在软件团队中越来越受欢迎,有助于在竞争激烈的市场中取得进步,并高效地交付创新产品。如果您已经读过《凤凰项目》,那么您对从 Ops 到 DevOps 的转变有所了解,在本例中,我们来看看一家美国科技公司是如何决定从 Ops 过渡到 DevOps 的。
如今,许多公司都选择走这条路。软件团队认为 DevOps 可以为他们节省大量精力,让他们专注于实际产品。为什么呢?从 Ops 转向 DevOps 有什么好处?嗯,首先,我们来聊聊。
什么是 DevOps?
DevOps 是一套鼓励敏捷思维的实践,旨在提升软件交付流程的速度和质量。在瀑布式开发等以往的方法论中,开发和运维团队被视为各自独立,各自承担特定任务,并且只负责交付流程的一部分。而 DevOps 模型则将开发和运维团队视为在整个软件应用程序生命周期中相互依存、紧密合作的团队。
在 DevOps 出现之前,传统模型涉及一组定义好的阶段,其中一个阶段的输出是下一个阶段的输入。这使得所有阶段相互依赖,导致新功能的交付和错误修复耗时更长,成本更高。
DevOps关键要素的关键要素是协作、自动化、持续集成、持续交付、测试和监控。
在本文中找出最常见的 DevOps 误区。
DevOps 优势
DevOps 最显著的优势之一是它提供了短而快的反馈循环。这使得企业能够快速识别错误,并了解客户的需求。它还能让他们快速交付功能。此外,它还能提高效率,打造更优质的软件。
DevOps 的另一个优势是能够交付更高质量的产品,并减少故障。衡量软件质量的关键方法之一是软件中的缺陷数量。根据CA Technologies 的一项调查,采用 DevOps 和敏捷方法论带来了巨大的积极影响,使开发流程的质量(缺陷数量)提高了 41%。毋庸置疑,开发团队和运营团队之间的协作对于产品质量的提升至关重要。
采用 DevOps 有助于营造稳定且均衡的工作环境。发布时产生的紧张和压力可能会破坏团队的稳定性,并降低他们的工作效率。
重复性任务的自动化为团队带来了更大的创新空间。此外,自动化和监控可以应用于软件开发过程的每个阶段,从集成、测试、发布到部署和基础设施管理。
如果实施得当,DevOps 有助于降低企业的生产成本和非生产成本。维护成本、人员成本、质量成本等等都可以降低,从而提高公司运营效率和盈利能力。
DevOps 与传统 Ops 有何不同?
当开发和运营团队分离时(传统运营就是这种情况),每个团队负责各自的交付部分——开发人员负责开发,然后运营团队负责运营。换句话说,IT 运营只有一个目标:确保生产环境中一切顺利运行。他们确保资源可用并达到最佳性能。他们提供可靠且优化的基础架构,这意味着要确保尽可能少的变更来保证这一点。
相反,DevOps 鼓励这些团队齐心协力,了解彼此的任务和关注点,并始终掌握全局。根据一份IT Ops/DevOps 生产力报告,DevOps 团队每周用于“救火”的时间减少了 21%。由于更高水平的自动化和自助服务工具,他们在行政支持上花费的时间也减少了。有了这些额外的时间,团队可以专注于改进基础设施、进行创新和自我提升。
心态转变
从 IT 运维转向 DevOps 的第一步是了解整个交付流程的控制权。IT运维人员负责确保系统的稳定性和可靠性,确保更少的变更、更少的变量,并建立最终用户流程。
但在 DevOps 中,这种思维模式行不通。工程师现在成为了组织的方向盘。他们构建自动化,改进应用程序交付,寻找确保安全的新方法,并且能够坦然面对失败和错误。
在 DevOps 中,决策更接近实际执行工作的团队。
基础设施
基础设施设置过去是由一些脚本组成的,这些脚本可以自动执行部分流程,但需要手动触发。这花费了大量时间,并且产生了许多本可以避免的错误。
在 DevOps 中,运维工作远不止脚本编写。它实际上就是编码——基础设施本身也变成了代码。通过代码构建和配置云基础设施。这是从“服务器思维”到“服务思维”的转变,大多数开发人员都持有这种思维。基础设施即代码使您能够定义基础设施组件的外观。如何配置它的逻辑捆绑在组件中。您需要为该组件准备部署所需的步骤定义一个流水线。
要成为基础设施编码员而不是基础设施管理员,您需要考虑工作负载和服务而不是服务器。
自动化是关键
在传统的IT实践中,自动化部分旨在创建一致性、记录所有内容并减少变量。文档固然重要,但它绝不能减慢自动化的速度,更糟糕的是,它不应该成为不实施自动化的借口。
手动工作和重复性任务总是容易出错。一遍又一遍地进行相同的配置会变得非常无趣且低效。
自动化贯穿于开发周期的每个阶段。从代码提交、构建触发、单元测试、打包、部署到环境、验证、冒烟测试、验收测试,到最终部署到生产环境。
自动化基础设施设置、环境配置和软件部署是 DevOps 的主要优势。这有助于在数小时内交付从代码到生产的功能,并更快地获得产品反馈。
失败和错误
DevOps 秉承“尽早失败”的理念。在传统的 IT 环境中,失败不是一种选择。你会尽一切努力避免损失风险:引入会议、流程、审批……
在 DevOps 中,失败是游戏的一部分。它不可避免。如果失败规模小且早期发生,你就能控制失败,从而快速恢复。讨论失败至关重要,因为它是一个学习的机会。哪里出了问题,哪里做对了,甚至比哪里做对了更重要。DevOps 是一种不责备的文化。
DevOps 实践支持这种文化,从测试驱动开发、小批量部署、自动化开始。
提高可见度
传统IT公司对用户可见内容有着严格的流程和限制。监控权限曾被视为一项巨大的负担。
在 DevOps 中,每个人都必须拥有软件的访问权限和可见性。这有助于开发人员提前发现问题,更好地检测和解决问题。应用程序日志记录应与环境日志记录相结合,以便开发人员了解应用程序在不同环境中的工作方式。
访问监控有助于团队识别故障点,提高自动化和软件质量。
工具
DevOps 的最佳盟友是那些带来效率的工具。在整个软件交付周期中,你需要多个组件来实现自动化:
- 协作工具:如沟通聊天和知识共享
- 构建工具:源代码控制管理、持续集成、数据库管理
- 测试工具
- 部署工具、配置管理、工件管理、编排和调度
- 监控工具、日志记录和商业智能
学习所有这些不同的工具本身就很有挑战性,但您还需要确保所选工具兼容。
自动化工具旨在支持发布速度和应用程序质量。它们将帮助您快速轻松地恢复任何不必要的更改。如果代码之外发生更改,工具将恢复更改并维护您的服务器处于稳定状态。
入门
DevOps 没有简单的指南。它绝对应该从改善开发和运维团队之间的沟通与协作开始。这将帮助他们更好地理解需求和彼此的任务,从而能够共同努力实现目标。运维工程师已经具备使用工具、构建自动化和支持环境的能力。他们需要转变思维方式,专注于持续开发方法。
从小规模开始,逐步扩大规模。将 DevOps 文化融入小团队并观察其成效始终更为安全。从中学习,并调整公司的结构和方法。这样,你就能找到适合自己业务的平衡点。
链接:https://dev.to/microtica/want-to-move-from-ops-to-devops-here-is-what-you-should-know-le9