为何 DevOps 会给开发人员带来压力和倦怠？

企业正在享受 DevOps 实施带来的好处，但这也是有代价的。开发人员需要承担额外的责任，可能会导致他们感到疲惫不堪。因此我们可以采取一些方法来确保 DevOps 工程师的满意度。

DevOps 的支持者通常将这一概念说成是提高效率和生产力的好方法。通过加强开发人员和 IT 运维工程师之间的协作，DevOps 能让每个人都朝着共同的目标更有效地工作。在很多情况下可能都是如此。然而，有人认为 DevOps 也有一个重大缺点：负责保持 DevOps 流程运行的工程师的压力水平增加。

以下是 DevOps 可能使开发人员的工作更具挑战性的原因，以及组织可以采取哪些措施来确保他们从 DevOps 中受益而不会让工程师抓狂。

DevOps 如何为企业带来效益

首先，让我们来了解一下 DevOps 的含义及其对企业的帮助。

DevOps 的理念是开发和 ITOps 团队应该紧密合作，即开发人员和 ITOps 之间的密切合作确保两个团队能够相互支持。

DevOps 的出现是为了解决许多组织在过去几十年中面临的一个挑战，即开发人员在编写代码时往往很少或根本得不到 ITOps 团队的反馈。这导致了沟通孤岛、效率低下，在某些情况下，开发人员和 ITOps 工程师之间关系紧张。通过帮助每个人持续合作，DevOps 可以让企业避免这些陷阱。

因此，从企业的角度来看，DevOps 是一件好事，因为它有助于确保工程师尽可能地提高工作效率。它能最大限度地减少时间和精力的浪费，通常还能提高企业推出新软件的速度，这反过来又能为企业带来市场竞争优势。

DevOps 对工程师意味着什么

对于开发人员本身来说，DevOps 并不总是那么美好。DevOps 迫使工程师做两件事，这会增加他们的工作压力：

承担更广泛的责任：DevOps 要求工程师们同时负责两类流程，而不是只负责软件开发或 IT 运营。
适应节奏更快的发布周期：DevOps 与 CI/CD 等实践齐头并进，DevOps 团队通常需要每周至少发布一次新的应用程序更新，有时甚至需要每天发布一次。这与 "瀑布式 "软件开发战略的时代大相径庭，在 "瀑布式 "软件开发战略下，新版本即使一年发布一到两次，也是如此。

这两个因素都会使工程师的工作变得更加紧张。在采用 DevOps 的企业中，工程师被要求做得更多、更快。

当然，DevOps 为软件交付流程带来的高效率有可能使工程师在满足这些更严格要求的同时，总体压力水平低于没有 DevOps 时的水平。如果没有 DevOps，团队通常会浪费更多时间来修复代码，并在出错时相互指责，这本身就是一种压力。通过减轻这些挑战，一个实施良好的 DevOps 战略可以让工程师们在整体上更轻松一些。

但并不是所有 DevOps 战略都能得到很好的实施，DevOps 本身就存在一种风险，那就是过多的 DevOps 实践只会导致工程师压力更大，更容易倦怠。他们可能会设法更快地发布新版本，但会牺牲工程师的工作满意度作为代价，这种成就是以高昂的代价换来的。

让 DevOps 工程师更轻松

为了避免这些问题，选择采用 DevOps 的企业应确保设定合理的期望值。例如，每周发布一次新版本可能会给工程师带来过大的压力，至少在一开始是这样。设定更适度的目标有助于降低 DevOps 工程师倦怠的风险。

限制 DevOps 工程师的职责也会有所帮助。虽然 DevOps 通常鼓励 DevOps 团队中的每个人共同承担软件交付流程中每个环节的责任，但让某些工程师牵头负责某些流程（如开发、测试和部署）通常更为现实。集体责任感仍然普遍存在，但为不同类型的任务指定牵头人可以让团队成员优先处理某些任务，而不是试图掌控软件交付生命周期的每个阶段，从而减轻每位工程师的整体压力。

在某些情况下，企业首先应该限制采用 DevOps 的范围。并不是每个应用程序都需要持续开发；有些应用程序（如传统软件）的变化频率并不高，不值得被嵌入 CI/CD 流水线。企业在实施 DevOps 时要有战略眼光，这样才能降低将过多 DevOps 实践强加给没有能力或时间处理所有实践的工程师的风险。

总结

在 DevOps 领域中，需要谨慎执行，因为过度的任务和压力可能会减弱其优势。虽然毫无疑问，DevOps 为企业带来了显著的优势，使开发人员能够实现更高的效率和生产力，但同时也可能给他们的团队带来负担。为了防止 burnout 的风险，请避免过度采用 DevOps 实践。

参考链接：

https://www.itprotoday.com/devops/downside-devops-stress-and-burnout-engineers