治理工程打破管制软件中的隔阂
治理工程打破管制软件中的隔阂
治理工程只是将治理人员也包括在内的良好 DevOps。
译自 Governance Engineering Breaks Down the Silos in Regulated Software 。
只要我们还记得，软件工程中的大讨论一直集中在开发人员和运维人员之间的紧张关系。核心的长期冲突归结为两个不同语言的部落，拥有不同的价值观，并受不同激励的驱动。更糟糕的是，这些不同派系还被隔离到组织中独立的单元，几乎没有合作的动力。
这一认识催生了 DevOps 运动，开启了一种新的协作、自动化、测量、精益和共享的文化。
但是，如果您从事受监管行业的软件交付，比如金融服务或医疗保健，您可能也正在经历一种新的冲突。
在这些行业中，DevOps 带来了额外的挑战，这些挑战仍未解决。因为尽管工程团队在技术上有能力每天部署多次，但他们在合规性、审计和安全方面仍有治理问题，这些问题仍由过时的手动流程来执行。这些治理要求是由组织中孤立的安全、变更管理、审计和风险管理部门设置和监控的。
好消息是，解决这类问题的方法已知：DevOps。或者正如马克·吐温所说，“历史从不重演，但它经常押韵。”
受监管的软件
在当今互联的世界里，软件渗透到我们生活的各个方面。它使我们能够分享猫图，阅读电影评论，以及(我最喜欢的)玩 Wordle。然而，软件的影响远远超出娱乐；它驱动我们的金融系统，推动我们的车辆，甚至控制救命药物。
当如此重要的软件失败时，后果可能非常严重。开发关键软件的公司必须应对由法律要求和维护品牌声誉的迫切需要带来的重大风险。
管理这些风险的复杂任务称为软件治理。然而，在许多组织中，负责确保软件治理的个人在隔离的筒仓中运作，彼此脱节，也脱离更广泛的背景。
治理隔阂的挑战
在高风险环境中运营的组织中，已经建立了特殊的治理流程和角色，以有效地管理风险。这些角色涵盖了各种各样的专家，包括风险官员、变更经理、安全专家、合规和法律专业人员以及质量官员。尽管他们的头衔和职责各不相同，但他们的总体目标仍然相同：防范公司的风险。
每组专业人员都使用风险语言进行交流，重视安全，并根据合规性由公司进行奖励。这些人拥有建立标准、政策和护栏的权力，以降低风险，并且经常被任务检查和确保遵守这些标准。
这种隔离安排令人惊讶的一点是，它往往是有意而为之的。例如，金融机构采用三道防线战略，为风险管理提供独立的监督。
然而，这种设置带来一个显著的挑战：这些治理专家很少对涉及的技术风险有全面的了解。他们的专业知识在各自的风险管理、合规性和法律框架领域，可能不包括软件系统本身的复杂性。
这种知识差距对于确保有效的治理构成重大障碍，因为它削弱了这些专家评估和处理受规制软件基础技术风险的能力。
工程隔阂的挑战
随着组织认识到技术带来的巨大价值，每家公司都成了软件公司。
工程师是软件开发的支柱。他们使用技术语言进行交流。他们重视工作中的自由，并根据交付速度获得奖励。但是，他们经常发现自己使用的语言与治理专家完全不同。
技术人员难以理解为何会有如此之多的繁文缛节和官僚化流程围绕他们的软件开发。他们可能感到与治理和合规要求脱节。他们在很大程度上感到无力影响或改变这些流程。
治理中的困惑之墙
语言、价值观和奖励的鸿沟导致工程团队与治理专家之间出现断层，最终导致慢性故障——困惑之墙。
治理隔阂制定工程师无法理解或控制的规则
困惑之墙的关键问题之一源于工程团队经常难以理解或控制的规则和流程。这些规则的示例包括职责分离和变更批准。这些指令通常在缺乏关于基础风险的清晰上下文或解释的情况下被施加。更糟糕的是，这些规则的实施往往在与其他技术改进脱节的过时的一刀切流程中僵化。
所有这些都导致工程师感到沮丧和困惑。如果没有对这些规则的存在、或它们旨在减轻的具体风险的全面理解，工程师可能会认为它们是不必要的官僚障碍。这种缺乏背景和透明度可能滋生抵抗、不遵守和治理不善。
工程提供治理无法理解的合规证据
困惑也是双向的！当需要通过审计验证合规性时，所提供的证据是工单、docker 镜像 sha 和 git 提交，对非工程师来说不可能导航。
因此，审计员的简单问题如“您能告诉我对生产的每次变更吗？”很快就会升级为在大量难以理解的 CI 日志中挖掘。
所有这些都导致糟糕的风险管理、大量的苦工和审计时的挫败感，并最终阻碍和使工程师失去动力。
采用治理工程实现更好的方法
令人振奋的是：我们之前已经看到过这个问题，我们已经知道解决方案。这正是过去开发人员和运维人员之间紧张关系的描述——答案就是 DevOps！
解决方案是将这两门学科聚集在一起，使用两边知识进行风险管理的协作。文化、自动化、精益、测量和共享(CALMS)以及整体思维的组合可以产生巨大的积极影响。
我们已经看到许多将治理和工程结合在一起的第一步。人们已经就这个题目写了书，一个社区也在形成之中。
缺失的是对此的命名。然后 Bill Bensing 在去年的 DOES Vegas 演讲中分享了一个见解：如果我们将 SRE 原则应用于软件治理会怎样？或者用他的话说:
“治理工程就是当你要求一个软件工程师设计一个治理团队时所发生的事情。”
那么什么是治理工程呢？当然是 DevOps！
只是这次将治理人员也包括在内。