在“为什么医生讨厌他们的电脑”一文中，Atul Gawande 描述了医务人员在使用电子健康记录 (EHR) 系统记录患者互动时，因为该系统强加的要求阻碍了他们与患者互动的挫败感。 EHR 公司 Epic 的高级副总裁 Sumit Rana 将其中一个令人沮丧的问题称为“辅助人员的复仇”。 Gawande 写道：
“在构建一个给定的功能——比如大脑 MRI 的订单表格——设计选择更多的是政治性的而非技术性的：行政人员和医生对于应该包含什么有不同的看法。医生过去拥有所有投票权。但 Epic 安排了会议来尝试解决这些差异。现在，工作人员有发言权（有时医生甚至没有出现），他们添加了一些问题，这些问题使他们的工作更容易，但使其他工作更加耗时。医生过去经常跳过的问题现在让他们措手不及，并显示“必填字段”警报。一个简单的请求现在可能需要填写详细的表格，这会占用与患者相处的宝贵时间。”
这个问题可能会出现在任何具有足够自动化，并且对其需求给用户带来的总体负担缺乏可见性的系统中，包括 DevOps 实现。
任何满足以下条件的系统都可能出现“辅助人员的复仇”问题：
- 系统中的自动化确保在可以完成操作之前强制执行要求
- 系统的用户很容易添加新要求
- 不会公开强加给其他用户的综合负担
DevOps 实践迫使组织接受新的自动化学科。 这些有助于添加部署前检查，例如自动化单元测试，这些测试可以阻止部署。 组织通常有专门的个人或部门负责确保满足安全性、合规性或业务要求。
DevOps 管道鼓励扩展以激活 DevSecOps、DevComplianceOps 或 DevBizOps 部署前检查。 但是，大多数管道几乎没有提供或根本没有提供关于系统部署前检查人员给开发人员和运维人员带来的负担的信息，以便部署他们的应用程序。 这使得 DevOps 管道容易受到“辅助人员的复仇”问题的影响，并且必须采取措施来防止它。
Gawande 描述中的一个关键观察是，医生经常不参加设计会议。 因此，防止此类问题的第一步是确保参与系统维护和使用的所有利益相关者之间进行开放式沟通。 大多数 DevOps 指南，包括 The DevOps Handbook，都提出了实现这种沟通水平的建议。
其次，负责确保代码合规性的人员必须与开发人员、运维人员和其他合规性代表会面，以了解和协商总体负担。 站点可靠性工程 提倡专门的技术专家与所有利益相关者合作，以增强整个系统，以确保特定的可靠性级别，同时解决合规性问题。
第三，必须开发提供快速反馈的新方法，这是一项关键的 DevOps 学科。 在用户部署新的部署前检查之前，必须通知他们这将给其他用户带来的负担。 此反馈可以采用多种形式，例如接收新部署前检查将使其他应用程序脱机或阻止更新的列表。
另一种形式的快速反馈可以采用站点可靠性工程所倡导的各种类型的风险指标的形式。 这些指标将衡量不合规软件保留在生产中的风险、中断造成的收入或生产力损失的风险，以及阻止应用程序新功能流动的机会成本。 它们可以在仪表板中可见，并用于开发基于针对每个应用程序量身定制的服务级别目标 (SLO) 的错误预算。 部署管道可以确保开发人员和运维人员可以继续推出新功能，直到达到某个错误级别。 然后，它将阻止进一步部署，直到开发人员通过解决技术债务将错误级别降至可接受的水平。 当开发人员和运维人员可以识别负责特定部署前检查的个人并协商特定应用程序的临时（和即时）延缓时，可以实现额外的快速反馈。
最后，DevOps 管道中的所有用户都必须意识到每个人都在同一个团队中，这一点很重要。 他们都希望确保部署高质量的软件，从而让他们的用户满意、提供重要的服务或提高用户的工作效率，同时减轻对整个机构的风险。 这就是 DevOps 的“无责事后分析”学科可以发挥关键作用的地方。 用户必须愿意提供有用的、建设性的反馈并听取反馈而不进行辩护。 这将确保 DevOps 管道满足每个人的需求。
评论已关闭。