devops实施难度_实施DevOps时要避免的10个陷阱

devops实施难度

在各种规模的公司中，由于技术团队定义成功的方式发生了变化，软件正越来越多地提供业务价值。 它们比以往任何时候都更受其构建的应用程序如何为客户带来价值的定义。 凭空说票和稳定已不再是IT的关键价值。 现在，通过与企业合作来提高开发人员的速度。

为了跟上这一更快的步伐，领先的技术专业人员正在构建具有精确性并接受持续交付，集成和DevOps标准的软件。 Liu Shanhong表示 ，“截至2018年，负责Web和移动应用程序开发和质量的技术专业人员中，只有9％的人表示他们尚未采用DevOps，也没有计划这样做。”

在DevOps文化中，一个重要的价值就是接受失败，这是通往价值之旅的一部分。 对于软件，旅程以持续交付的形式出现，期望我们会定期发布代码。 快速的步伐可以确保失败，但同时也可以确保您在失败时能够从错误中吸取教训并Swift适应。 这就是您业务发展的方式：您会获得更多见识，并让他们引导您走向成功。

由于那些已经采用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的核心Struts在实施过程中保持稳定，但它们会进行内部修改，这对于衡量其预期结果至关重要。

4.选择速度胜于质量

许多公司专注于产品交付而没有对产品质量给予足够的重视。 如果工作的关键绩效指标（KPI）仅在生产时间上居中，则质量很容易在流程中下降。 可以监视性能的端点留给将来的版本使用，并且由于尚未快速投入生产，因此尚未投入生产的软件被视为成功。

在快速发展的市场中，团队无法承受客户或内部需求所规定的时间要求来提供最佳产品质量。 许多公司急于在较短的时间内完成并完成尽可能多的DevOps项目，以保持其在竞争激烈的市场中的地位。 这听起来似乎是个好主意，但期望DevOps快速发展可能会带来更多的痛苦而不是收获。

实现速度和质量改进是DevOps的基本价值。 它很难实现，并且要求操作员和开发人员以新的和改进的方式编写测试。 如果做得好，质量和速度会同时提高。

5.建立一支专门的DevOps团队

从理论上讲，组建一支专门的团队专注于培训最新的IT专业人员是有意义的。 完成DevOps旅程的过程必须轻松无阻，对吗？ 但是很快出现了两个问题：

• 现有的质量保证（QA），运营和开发团队成员被忽略了，可能会妨碍新团队的努力。
• 这个新团队成为另一个孤岛，提供新技术，但并没有在DevOps旅程中促进公司的目标。

最好由QA，ops和dev的新团队成员和现有员工组成，他们很高兴加入DevOps计划。 后者拥有大量的机构知识，这些知识在您实施如此庞大的倡议时非常有价值。

6.俯瞰数据库

数据库是构建DevOps时被忽略的最重要的技术领域之一。 新的临时应用程序可以以前所未有的速度通过DevOps管道。 但是，数据繁忙的应用程序并不容易部署。

无需集中精力有效地使它们自动化，单独环境中的数据快照可以而且将朝着不准确的方向发展。 专家们强调不断的集成和代码处理，但是无法自动化数据库。 数据库管理应正确完成，尤其是对于以数据为中心的应用程序。 数据库在此类应用程序中起着重要作用，可能需要单独的专业知识才能与其他应用程序一起自动化。

7.事件处理程序不足

万一出了问题（并且会发生），DevOps团队应该制定事件处理程序。 事件处理应该是一个连续的，活跃的过程，为保持一致性并避免错误而明确列出。 这意味着为了记录事件处理过程，您必须捕获并描述事件响应要求。 对运行手册文档和无罪的验尸有很多研究，这对于学习成功至关重要。

8.对DevOps的了解不足

尽管近年来DevOps的接受度Swift增长，但应用专家可能没有精确的质量控制程序就在工作。 团队进行DevOps成功所需的所有技术，文化和流程更改的能力有时会不足。

采用DevOps做法是明智之举，但成功需要足够的经验和准备。 在某些情况下，获得合适的专业知识以满足您的需求意味着您需要聘请外部专家（免责声明：我管理着DevOps咨询公司）。 这些训练有素的专家应具有所需技术的认证，并且公司应避免做出快速的DevOps决策，而不能很好地处理结果。

9.忽视安全

安全性和DevOps应该并排移动。 许多组织都拒绝安全准则，因为这很困难，而且DevOps的旅程可能很艰难。 这导致了一些问题，例如最初使开发人员的输出最大化，后来意识到他们忽略了保护这些应用程序的安全。 认真对待安全性，并研究DevSecOps，以了解对您的组织是否有意义。

10.实施DevOps时会感到疲劳

如果您成立了一个DevOps团队，目标是从每年一次产品部署到每周进行10次推送，那么它很可能会失败。 获得在演示文稿中看起来不错的任意指标的途径不会激励团队。 DevOps不是一个简单的技术运动； 这是一次巨大的文化升级。

企业规模越大，坚持DevOps实践所需的时间就越长。 您应该以阶段性和可衡量的方式应用DevOps方法，并将实际结果作为值得庆祝的里程碑。 在开始第一轮应用程序部署之前，培训您的员工并安排充足的休息时间。 第一个DevOps管道的实现速度可能很慢。 这就是现实生活中不断改进的样子。

底线

公司正在Swift向DevOps迈进，以跟上竞争步伐，但在实现过程中会犯常见错误。 为避免这些陷阱，请精确计划并应用正确的策略以取得更成功的DevOps结果。

翻译自: https://opensource.com/article/19/9/pitfalls-avoid-devops

devops实施难度