通过避免其他人所犯的错误，使DevOps实现过程更加顺利。
图片来源:Opensource.com在各种规模的公司中，由于技术团队定义成功的方式发生了变化，软件正越来越多地提供业务价值。它们比以往任何时候都更取决于其构建的应用程序如何为客户带来价值。门票和稳定的代价是说不，这已不再是关键价值。现在是通过与业务合作来提高开发速度。
为了跟上这种更快的步伐，领先的技术专业人员正在精确地构建软件，并采用持续交付、集成和DevOps的标准。据刘善红表示，“截至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的基础知识非常重要，尤其是平静(文化、自动化、精益、度量和共享)支柱，为技术进步奠定基础。但是没有一种通用的DevOps实现。通过认识到这一点，DevOps团队可以构建一个计划来解决主动性工作的关键原因，并从过去失败的结果中进行构建。团队应该准备好修改计划，同时保持在DevOps基本原则的建议范围内。
4. 选择速度而非质量
很多公司只专注于产品的交付，而没有对产品质量给予足够的重视。如果工作的关键性能指标(kpi)只集中在生产的时间上，那么质量很容易在过程中下降。可以监视性能的端点留给未来的版本，而没有准备好生产的软件被认为是成功的，因为它被快速地向前推进。
在一个快节奏的市场中，团队无法在客户或内部需求的时间要求下提供最好的产品质量。许多公司都急于在较短的时间内完成尽可能多的DevOps项目，以在竞争激烈的市场中保持自己的地位。这听起来像是一个好主意，但是期望DevOps是一个快速的过程可能会带来更多的痛苦。
实现速度和质量的改进是DevOps的基本价值。这并不容易实现，需要操作人员和开发人员以新的和改进的方式编写测试。如果做得好，质量和速度同时提高。
5. 建立一个专门的DevOps团队
从理论上讲，建立一个专门的团队来集中培训it领域的最新专业人员是有意义的。完成DevOps之旅的过程必须是没有任何麻烦且无缝衔接的，对吗?但很快就出现了两个问题:
现有的质量保证(QA)、运营和开发团队成员感到被忽视，并可能试图阻碍新团队的工作。
这个新的团队变成了另一个竖井，提供了新的技术，但是没有在DevOps的旅程中推进公司的目标。
最好将新团队成员和来自QA、ops和dev的现有员工混合在一起，他们对加入DevOps很感兴趣。后一种人拥有大量的机构知识，当推出这么大的项目时，这些知识是有价值的。
6. 俯瞰数据库
在构建DevOps时，数据库是最基本的技术领域之一。新的临时应用程序可以以与以前任何应用程序不同的速度通过DevOps管道。但是，需要大量数据的应用程序并没有看到同样的部署简便性。
如果不集中精力有效地自动化，独立环境中的数据快照可能会变得不准确。专家强调持续集成和代码处理，但在自动化数据库方面失败了。应该正确地进行数据库管理，特别是对于以数据为中心的应用程序。数据库在这类应用程序中扮演着重要的角色，可能需要单独的专家来将其与其他应用程序一起自动化。
7. 不足的事件处理程序
万一出了什么问题，DevOps团队应该有适当的事件处理程序。事件处理应该是一个连续的、积极的过程，为了一致性和避免错误而清晰地描述出来。这意味着为了记录事件处理过程，您必须捕获并描述事件响应需求。有很多关于runbook文档和无可指摘的事后分析的研究，这对于学习如何成功是很重要的。
8. 对DevOps的了解不够
尽管DevOps的接受程度近年来迅速提高，但应用专家可能没有精确的质量控制程序。团队完成在DevOps中成功所需的所有技术、文化和流程更改的能力有时会不足。
采用DevOps实践是一种明智的做法，但是成功需要大量的经验和准备。在某些情况下，获得正确的专业知识来满足您的需求意味着雇佣外部专家(声明:我管理着DevOps咨询公司)。这些训练有素的专家应该拥有所需技术的认证，公司应该避免在没有很好地处理结果的情况下做出快速的DevOps决策。
9. 忽视安全
安全性和DevOps应该并驾齐驱。许多组织对安全指南不屑一顾，因为它很难，而DevOps之旅可能已经够难了。这就导致了一些问题，例如最初最大化开发人员的输出，然后发现忽略了保护这些应用程序。认真对待安全性，查看DevSecOps，看看它对组织是否有意义。
10. 在实现DevOps时感到疲劳
如果启动一个DevOps团队，目标是从一年一次的产品部署到一周10次，那么很可能会失败。获得在演示中看起来不错的任意度量的方法不会激励团队。DevOps不是一个简单的技术运动;这是一个巨大的文化升级。
企业越大，使DevOps实践得以坚持的时间就越长。应该将DevOps方法应用到一个分阶段的、可度量的方法中，以实际的结果作为里程碑来庆祝。培训员工，并在开始第一轮应用程序部署之前安排足够的休息时间。第一个DevOps管道实现起来比较慢。这就是现实生活中持续改进的样子。
底线
公司正在迅速地向DevOps靠拢，以跟上竞争对手的步伐，但在实现过程中也会犯一些常见的错误。为了避免这些陷阱，需要精确地计划并应用正确的策略，以获得更成功的DevOps结果。
