DevOps是值得投资的职业倦怠解决方案[DevOps]

首先，需要做更多的事情来防止倦怠，而不是开始解决倦怠。 这里会告知产生原因和解决方案。

A person choosing between several different incentives

我每天都看到推文，或听到有人谈论倦怠。职业倦怠正在成为生活中普遍存在的一部分，尤其是在科技和开源社区中。在需要了解的有关开源社区中的倦怠的内容中，我定义了倦怠并探讨了其原因，症状和潜在的治疗方法。但是，关于预防的一个更好的问题是：如何改变基础过程，文化和工具，以防止职业倦怠的发生？

倦怠的催化剂是计划外的工作

首先回顾一下有关倦怠原因的知识。在2019年，PagerDuty发表了《计划外的工作：永远存在的世界对人类的影响》。由于压力和工作/生活平衡问题（又称倦怠），超过35％的研究受访者正在考虑离职。利用自动化并记录了响应计划的公司，较少的计划外事件和较少的员工压力。

现代软件组织使用自动化和记录在案的响应计划来更快地移动。为了保持竞争力，必须采取更快的行动。我们正处于这个无休止的循环中，客户期望更多，这给公司提供更多和更快交付的产品带来了更大的压力，进而给员工带来了压力。

但是，在有保护措施以防止计划外的工作和倦怠时，可以快速移动。 《 DevOps加速状态报告》已经跟踪了六年的DevOps趋势。它使团队可以与业内其他低，中，高或优秀绩效者进行基准比较。 2019年DevOps状况报告的发现之一是：“生产力可以推动工作/生活平衡的改善和工作倦怠的减少，并且组织可以进行明智的投资来支持它。”

生产力意味着更多工作要做。因此，可以提供更多的价值。生产力的平衡点是：不要在短期内做更多的工作，而要消耗大量的精力。需要采用适当的流程和工具来防止人们感到过度劳累和不知所措。

为了支持不会导致倦怠的生产力，组织需要在工具方面进行明智的投资并减少技术债务。投资工具意味着购买有用且易于使用的解决方案。选择建造而不是购买可能会导致生产率下降并出现倦怠现象。怎么样？开发人员没有专注于构建具有竞争力的差异化特征并帮助公司实现关键业务目标的功能，而是花了无数时间来尝试构建供应商可以快速提供的产品。

随着开发人员花费时间来构建非核心解决方案，技术债务增加了，功能也被推出了。与其构建所有事物，不如购买支持业务但不具有战略意义的工具，并构建业务战略核心的事物。您不会使用开发资源来构建自己的电子邮件程序，因此请以相同的方式对待其他工具。绩效低下的团队使用的工具有20％主要是公司内部开发的，并且是组织专有的，而中，高级和精英团队的使用率为5％至6％。

有价值的解决方案

如果想防止倦怠，可以在这里进行一些投资。它们与DevOps文章中的频繁讨论没有重叠，这并非巧合。

沟通与协作

沟通是所做工作的核心。劳里·巴特（Laurie Barth）很好地总结了这一点：“随着时间的流逝，我知道失败的最大根源通常是人员和团队。缺乏沟通和协调会导致严重的问题。”使用视频会议，Confluence和Slack等工具来确保沟通和协作的发生。

但是围绕这些工具的使用制定规则。确保在下班时间关闭Slack通知。我从6pm到8am禁用通知。

定义哪种通信最适合哪种情况。 Slack对于实时的短暂通信很有用，但是它可能导致人们感到需要始终保持打开状态。如果他们不在线，他们可能会错过重要的谈话。如果在Slack线程中做出主要或次要决定，则将这些决定记录在寿命更长的记录系统中，使所有团队成员都可以访问必要的信息。

尝试调试事件？通过Slack进行通信。是否需要撰写事后评估？将其发布到Confluence或Wiki。

Zoom或BlueJeans等视频会议工具可帮助实现远程工作。具有远程，兼职或全职工作的能力，可以减轻通勤或重新安置的压力。视频会议使与分布式团队保持联系变得容易，因为有时通过面对面的对话来散布事物比通过电子邮件或Slack进行散列更为容易。

这些工具不应被用来鼓励人们在度假时工作。休假意味着需要下班休息，恢复精力。

发布和部署

根据2019年的DevOps状态报告，精英团队部署代码的频率是性能低下的团队的208倍，从提交代码到部署的交付时间快了106倍。似乎您进行的部署越多，倦怠的可能性就越大，但这不一定是这种情况。利用持续交付的团队已经制定了可以安全部署的流程。

首先，将发布与部署分开，仅是因为您部署的代码并不意味着所有用户都应有权访问它。 Ring部署使功能可供一小部分人使用，例如内部员工或Beta客户。这些用户可以帮助您识别错误或提供反馈，以在广泛发布某个功能之前对其进行微调。

接下来，创建有关部署质量的反馈循环。部署代码时，事情并非总是按计划进行。需要能够在出现问题时快速停止。反馈循环包括实施监视和可观察性工具。通过将遥测数据与终止开关一起使用，可以快速关闭行为不佳的功能，而不必减少整个部署。

[需要帮助选择什么以及如何监视部署？下载我们的DevOps监控工具开源指南open source guide to DevOps monitoring tools]

最后，运行A / B测试和实验以了解客户的反应。基于指标的方法可洞察有效的方法和无效的方法，并可以帮助验证假设。与其创建具有部分功能的技术债务，不如收集数据以查看该功能是否尽早提供了预期的转换。如果没有，请不要释放它。

事件解决

解决事件的一部分意味着知道发生故障时应采取的措施。不断灭火可能导致倦怠。无法阻止所有事件的发生，但可以做得更好。使用Gremlin之类的工具进行混乱的实验或比赛，可以帮助公司为意外做好准备。

通过混乱的实验，可以了解系统，服务和应用程序在特定情况下的响应方式。了解事物破裂时的行为方式可以缩短事件解决的时间。它们还可以帮助在事件发生之前识别和修复漏洞。

在事件解决期间，可以自动执行哪些操作以减少工作量？例如，当积极处理事件时，是否可以自动生成专用于事件的Slack频道？还是可以使用LaunchDarkly之类的解决方案（完全公开：我在那儿工作）创建功能标记，以在事件解决期间执行常见任务？这些可能包括：

动态配置更改，例如在触发警报时自动调整日志记录级别以收集更多信息

减载以在系统承受重负载时禁用非关键元素，以确保完成基本任务

当它们影响服务可靠性时，请杀死开关或断路器以关闭功能

这不是魔术

没有解决倦怠的灵丹妙药。它需要拥有合适的人员，流程和工具。人们帮助创造一种心理安全的环境，使人们可以自由地提问，实验，犯错误和具有创造力。考虑什么对组织最重要，并投资于正确的工具以支持这些目标以及为之奋斗的人们。