几乎每天我都能在推特上看到或听到有人谈论倦怠。倦怠正成为我们生活中普遍存在的一部分，尤其是在科技和开源社区中。在关于开源社区倦怠您需要了解的知识中，我定义了倦怠，并探讨了其原因、症状和潜在的治疗方法。但一个更好的问题是关于预防：我们如何改变潜在的流程、文化和工具，以防止倦怠在第一时间发生？
倦怠的催化剂是计划外的工作
让我们首先回顾一下关于倦怠原因的已知信息。2019 年，PagerDuty 发布了计划外的工作：永远在线的世界对人类的影响。超过 35% 的研究受访者正在考虑因压力和工作/生活平衡问题（也称为倦怠）而离职。使用自动化并拥有文档化响应计划的公司，计划外事件较少，员工压力也较小。
现代软件组织使用自动化和文档化的响应计划来更快地行动。更快地行动对于保持竞争力是必要的。我们正处于一个永无止境的循环中，客户期望更多，这给公司带来更大的压力，要求他们交付更多、更快地交付，这反过来又给员工带来了压力。
然而，在拥有防止计划外工作和倦怠的保护措施的同时，快速行动是可能的。《Accelerate State of DevOps Report》已经跟踪 DevOps 趋势六年了。它允许团队将自己与行业中其他低、中、高或精英绩效者进行基准比较。2019 年 State of DevOps 报告的发现之一是：“生产力可以推动工作/生活平衡的改善和倦怠的减少，组织可以进行明智的投资来支持它。”
生产力意味着完成更多的工作。因此，交付更多的价值。生产力的关键在于平衡：不要以牺牲员工的倦怠为代价，在短期内做更多的工作。需要有流程和工具来防止人们感到工作过度和不堪重负。
为了支持不会导致倦怠的生产力，组织需要对工具进行明智的投资，并减少技术债务。投资工具意味着购买有用且易于使用的解决方案。偏好构建而不是购买可能会导致生产力下降和倦怠出现。为什么？开发人员没有专注于构建具有竞争差异化优势的功能，并帮助公司实现关键业务目标，而是花费无数时间试图构建供应商可以快速提供的东西。
随着开发人员花费时间构建非核心解决方案，技术债务累积，功能被推出。与其构建所有东西，不如购买支持业务但非战略性的工具，并构建对您的业务战略至关重要的东西。您不会使用开发资源来构建自己的电子邮件程序，因此对待其他工具也应如此。低绩效团队使用的工具中，有 20% 主要是在内部开发且为组织专有的，而中、高和精英团队的这一比例为 5% 到 6%。
值得投资的倦怠解决方案
如果您想预防倦怠，以下是一些值得投资的领域。它们与DevOps 文章中经常讨论的内容重叠并非巧合。
沟通与协作
沟通是我们所做一切事情的核心。Laurie Barth 很好地总结了这一点：“随着时间的推移，我了解到最大的失败根源通常是人和团队。缺乏沟通和协调可能会导致严重的问题。” 使用视频会议、Confluence 和 Slack 等工具来确保沟通和协作的发生。
但要围绕这些工具的使用制定规则。确保在非工作时间关闭 Slack 通知。我从晚上 6 点到早上 8 点禁用我的通知。
定义哪种类型的沟通最适合哪种情况。Slack 对于实时的、短暂的沟通非常有用，但它可能会导致人们感到需要始终在线。如果他们不在线，他们可能会错过重要的对话。如果在 Slack 线程中做出重大或次要的决策，请将其记录在更长期的记录系统中，以便所有团队成员都能访问必要的信息。
尝试调试事件？通过 Slack 进行沟通。需要撰写事件后审查报告？将其发布到 Confluence 或 Wiki。
Zoom 或 BlueJeans 等视频会议工具可以帮助实现远程工作。拥有远程工作（兼职或全职）的能力可以减轻通勤或搬迁的压力。视频会议使与分布式团队保持联系变得容易，因为有时面对面的对话比通过电子邮件或 Slack 更容易解决问题。
不应使用这些工具来鼓励人们在休假时工作。休假意味着离开工作岗位休息、恢复和充电。
发布和部署
根据 2019 年 State of DevOps 报告，精英团队的代码部署频率是低绩效团队的 208 倍，他们从提交代码到部署的提前期快 106 倍。看起来部署次数越多，倦怠的可能性就越大，但事实并非如此。使用持续交付的团队有安全的部署流程。
首先，将发布与部署分开——仅仅因为您部署了代码，并不意味着所有用户都应该访问它。环形部署使功能可供一小部分人使用，例如内部员工或 Beta 客户。这些用户可以帮助您识别错误或提供反馈，以便在广泛发布功能之前对其进行微调。
接下来，创建关于部署质量的反馈循环。当部署代码时，事情并不总是按计划进行。当事情出错时，您需要能够快速停止。反馈循环包括实施监控和可观测性工具。通过使用遥测数据和终止开关，您可以快速关闭行为不端的功能，而不是回滚整个部署。
[需要帮助选择监控部署的内容和方式？下载我们的开源 DevOps 监控工具指南]
最后，运行 A/B 测试和实验，以了解客户的反应。基于指标的方法可以深入了解哪些有效，哪些无效，并可以帮助您验证假设。与其使用部分功能创建技术债务，不如收集数据以查看该功能是否尽早提供预期的转化率。如果它没有，就不要发布它。
事件解决
解决事件的一部分意味着知道在出现问题时该怎么做。不断扑灭火灾可能会导致倦怠。我们无法阻止所有事件的发生，但我们可以做好更充分的准备。使用 Gremlin 等工具进行混沌实验或游戏日可以帮助公司为意外情况做好准备。
通过混沌实验，您可以了解您的系统、服务和应用程序在特定场景下的响应方式。了解事物在损坏时的行为方式可以缩短事件解决时间。它们还可以帮助您在事件发生之前识别和修复漏洞。
您可以自动化哪些操作来减少事件解决期间的苦差事？例如，当您积极处理事件时，是否可以自动生成专门用于该事件的 Slack 频道？或者您可以使用 LaunchDarkly（完全披露：我在那里工作）之类的解决方案创建功能标志，以便在事件解决期间执行常见任务？这些可能包括
- 动态配置更改，例如在触发警报时自动调整日志记录级别以收集更多信息
- 负载脱落，在系统负载过重时禁用非关键元素，以确保完成基本任务
- 终止开关或断路器，在功能影响您的服务可靠性时将其关闭
这不是魔法
没有解决倦怠的灵丹妙药；它需要拥有正确的人员、流程和工具。人员有助于创造心理安全的环境，让人们可以自由地提问、实验、犯错和发挥创造力。考虑对您的组织最重要的事情，并投资于正确的工具来支持这些目标以及为这些目标努力的人员。
5 条评论