几乎每天我都能在推特上看到或听到有人谈论职业倦怠。 职业倦怠正成为我们生活中的普遍现象，尤其是在科技和开源社区中。 在关于开源社区中职业倦怠您需要了解的内容中，我定义了职业倦怠，并探讨了其原因、症状和潜在的治疗方法。 但一个更好的问题是关于预防：我们如何改变底层流程、文化和工具，以从一开始就防止职业倦怠的发生？
职业倦怠的催化剂是计划外工作
让我们首先回顾一下关于职业倦怠原因的已知信息。 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 条评论