devops 解决方案_DevOps是值得投资的职业倦怠解决方案

devops 解决方案

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

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

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

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

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监控工具开源指南 ]

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

事件解决

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

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

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

• 动态配置更改，例如在触发警报时自动调整日志记录级别以收集更多信息
• 减载以在系统承受重负载时禁用非关键元素，以确保完成基本任务
• 在影响服务可靠性的情况下，杀死开关或断路器以关闭功能

这不是魔术

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

翻译自: https://opensource.com/article/20/1/devops-burnout-solution

devops 解决方案