在各种规模的公司中，软件越来越多地提供业务价值，这归功于技术团队定义成功的方式发生了转变。他们比以往任何时候都更以他们构建的应用程序为客户带来的价值来衡量成功。以拒绝为代价的工单和稳定性不再是 IT 的主要价值。现在的重点是通过与业务部门合作来提高开发人员的速度。
为了跟上这种更快的步伐，领先的技术专业人士正在以精确的方式构建软件，并拥抱持续交付、集成和 DevOps 的标准。根据 Shanhong Liu 的说法，“截至 2018 年，只有 9% 的负责 Web 和移动应用程序开发和质量的技术专业人士表示，他们尚未采用 DevOps，也没有计划这样做。”
DevOps 文化 的一个重要价值是接受失败是通往价值之旅的一部分。对于软件而言，这个旅程以 持续交付 的形式出现，期望我们定期发布代码。快速的节奏确保了失败，但也确保了当您确实失败时，您可以从错误中学习并快速适应。这就是您作为企业发展的方式：您获得更多见解，并让它们指导您走向成功。
由于那些已经采用 DevOps 的人已经犯了错误，您可以利用他们的经验来学习并避免重复同样的错误。本着 DevOps 和开源的精神——快速迭代，在前人的工作（和错误）的基础上构建——以下是企业在 DevOps 之旅中遇到的一些最常见的错误以及如何解决这些错误。
1. 交付顺序错误
有时，开发人员会同时执行持续交付 (CD) 和持续集成 (CI)，以加速自动化测试和反馈周期。CI/CD 作为一种实践，在软件交付速度方面有很多好处。风险在于，不正确的代码配置可能会被交付到生产环境，而没有对其影响进行足够的探索，从而否定了扩展前自动化测试的价值。
我认为，在代码完全通过软件交付周期之前，手动确认仍然至关重要。必须有一个预生产阶段——在生产之前进行部署和测试的层——允许开发人员纠正和修正用户在代码直接推送到生产环境时可能遇到的错误。
在代码到达最终用户之前，设置监控非常重要。例如，构建 CD 管道，以便在开发过程中进行测试，这将确保更改不会自动部署。
虽然 DevOps 标准声明团队必须扩展到孤岛之外，但部署应始终由熟悉管道末端输出代码的人员进行验证。这要求在代码到达客户之前进行彻底检查。
2. 误解 DevOps 职位
一些组织对 DevOps 职位感到困惑。他们认为 DevOps 工程师的目标是解决与 DevOps 相关的所有问题——即使 DevOps 意味着开发人员和运维人员之间的协作。
DevOps 集成开发和运维角色的方式可能是一个困难的职业发展。开发人员需要更多地了解他们的应用程序如何运行，以便保持其运行，并在应用程序宕机时可能需要随叫随到提供支持。运维人员必须成为如何扩展和理解适合更大 监控和可观测性策略 的指标的专家。
实际上，DevOps 帮助公司加速 IT 运维中耗时的任务。例如，自动化测试为开发人员提供更快的反馈，而自动化集成将开发人员的更改更快地合并到代码库中。DevOps 也可能被要求自动化围绕收集、扩展和运行应用程序的程序。
贵组织的基本需求决定了您的 DevOps 专业人员的技能组合是需要在运维方面更强还是在开发方面更强，并且此信息必须与您选择或聘用 DevOps 团队的方式保持一致。例如，当自动化是关键时（而不是需要围绕容器化的专业知识），优先考虑过去的软件开发和脚本编写技能非常重要。根据您独特的 DevOps 经验需求进行招聘，并让人们在工作中学习其他技能。如果您聘请愿意学习的人，您将为您的组织建立最佳团队。
3. DevOps 程序方面缺乏灵活性
虽然 DevOps 原则提供了基础，但每个组织都必须准备好根据其期望的结果定制其旅程。公司需要确保，虽然核心 DevOps 支柱在实施过程中保持稳定，但他们创建了内部修改，这些修改对于衡量他们的预测结果至关重要。
掌握 DevOps 的基本原理非常重要，尤其是 CALMS（文化、自动化、精益、衡量和共享）支柱，为技术进步奠定基础。但是没有一种通用的 DevOps 实施方法。通过认识到这一点，DevOps 团队可以制定计划来解决该计划的关键原因，并从过去失败的结果中构建。团队应该准备好修改他们的计划，同时遵守基本 DevOps 原则的建议。
4. 选择速度而非质量
许多公司专注于产品交付，而没有充分关注产品质量。如果该工作的关键绩效指标 (KPI) 仅以生产时间为中心，那么质量很容易在过程中下降。可以监控性能的端点留到以后的版本，而未准备好生产的软件被视为成功，因为它被快速推进。
在快节奏的市场中，团队无法在客户或内部需求规定的时间要求内提供最佳的产品质量。许多公司都在赶时间在更短的时间跨度内获得并完成尽可能多的 DevOps 项目，以保持其在竞争激烈的市场中的地位。这听起来可能是一个好主意，但期望 DevOps 是一次快速的旅程可能会导致弊大于利。
同时实现速度和质量的提高是 DevOps 的一项重要价值。这并非易事，需要运维人员和开发人员以新的和改进的方式编写测试。如果做得好，质量和速度会同时提高。
5. 建立专门的 DevOps 团队
从理论上讲，建立一个专门的团队来专注于培训 IT 领域最新的专业人员是有道理的。完成 DevOps 之旅的行动必须是轻松无缝的，对吧？但是很快就会出现两个问题
- 现有的质量保证 (QA)、运维和开发团队成员感到被忽视，并可能试图阻碍新团队的努力。
- 这个新团队变成了另一个孤岛，提供新技术，但没有推进公司在 DevOps 之旅中的目标。
最好是将新团队成员和来自 QA、运维和开发部门的现有员工混合在一起，他们很高兴加入 DevOps 计划。后一组人拥有大量的机构知识，在您开展如此庞大的计划时，这些知识非常宝贵。
6. 忽视数据库
数据库是在构建 DevOps 时被忽视的最重要的技术领域之一。新的、短暂的应用程序可以以以前任何应用程序都无法比拟的速度通过 DevOps 管道。但是，数据密集型应用程序看不到同样的部署便利性。
如果不集中精力有效地自动化数据快照，那么单独环境中的数据快照可能会并且将会逐渐变得不准确。专家强调持续集成和代码处理，但在自动化数据库方面却失败了。数据库管理应正确完成，特别是对于以数据为中心的应用程序。数据库在此类应用程序中起着重要作用，可能需要单独的专业知识才能与其他应用程序一起自动化。
7. 事件处理程序不足
如果出现问题（而且肯定会），DevOps 团队应制定事件处理程序。事件处理应是一个持续且积极的程序，明确概述以确保一致性并避免错误。这意味着为了记录事件处理流程，您必须捕获并描述事件响应要求。关于运行手册文档和 无责事后分析 有很多研究，学习这些对于取得成功非常重要。
8. DevOps 知识不足
尽管近年来 DevOps 的接受度迅速扩大，但应用程序专家可能在没有精确的质量控制程序的情况下工作。团队完成在 DevOps 中取得成功所需的所有技术、文化和流程变更的能力有时会不足。
采用 DevOps 实践是一个明智之举，但成功需要丰富的经验和准备。在某些情况下，获得满足您要求的正确专业知识意味着聘请外部专家（免责声明：我管理一家 DevOps 咨询公司）。这些训练有素的专家应具有所需技术的认证，公司应避免在没有充分掌握结果的情况下做出快速的 DevOps 决策。
9. 忽视安全性
安全性和 DevOps 应该并驾齐驱。许多组织不理会安全指南，因为它很困难，而 DevOps 之旅可能已经够困难了。这会导致一些问题，例如最初最大化开发人员的产出，然后才意识到他们忽略了保护这些应用程序。认真对待安全性，并研究 DevSecOps，看看它是否对您的组织有意义。
10. 实施 DevOps 时感到疲惫
如果您启动一个 DevOps 团队，目标是从每年一次产品部署到每周 10 次推送，那么它很可能会失败。达到在演示文稿中看起来不错的任意指标的路径不会激励团队。DevOps 不是一个简单的技术运动；而是一次巨大的文化升级。
企业规模越大，DevOps 实践扎根所需的时间就越长。您应该采用分阶段和有条不紊的方法应用 DevOps 方法，并将实际结果作为值得庆祝的里程碑。在开始首轮应用程序部署之前，培训您的员工并安排充足的休息时间。第一个 DevOps 管道可能很难实现。这就是现实生活中的持续改进。
底线
公司正在迅速转向 DevOps 以跟上竞争对手的步伐，但在实施过程中会犯常见的错误。为了避免这些陷阱，请精确计划并应用正确的策略，以实现更成功的 DevOps 成果。
评论已关闭。