Redgate是如何做出架构决策的?

21-11-19 banq

架构决策“最简单”的解决方案是让拥有巨大大脑的人做出所有决定。这种“Megamind”方法当然有一些优势——一个人可以快速做出决定,并且有一个人负责;缺点使这些优点相形见绌。把责任推给一个人是有风险的——人并不完美(对不起!)。

让我们尝试改进一下:我们可以任命一个变革顾问委员会 (CAB)。CAB 是一个具有相关领域经验的小组,负责审查决策并提出改进建议。CAB 听起来像是一种改进;不同的群体做出更好的决策,相关领域的专业知识必然会让事情变得更好。不幸的是,研究表明拥有变更审批流程并不是一个好主意。

 

“……发现外部批准与提前期、部署频率和恢复时间呈负相关,与变更失败率无关。简而言之,外部机构(例如经理或 CAB)的批准根本无法提高生产系统的稳定性,以恢复服务的时间和更改失败率来衡量。但是,它肯定会减慢速度。事实上,这比根本没有变更审批流程更糟糕。” (加速:妮可福斯格伦)

 

我们在 Redgate 的核心信念是“我们相信制作软件的最佳方式是让拥有明确目标、行动自由和学习动力的团队参与进来。”。提交设计以供批准与行动自由的原则背道而驰。但是,我们也认识到,有时单个团队可能不具备整个环境,并且局部决策可能是局部最优。

我们如何解决这个问题?

圣达菲潜艇的船长大卫·马奎特已经给了我们答案。在被置于一个陌生的环境后,他形成了一种强调地方决策而不放弃控制的领导风格。基于意图的领导赋予团队决策权,但使用“意图检查”让其他人提供洞察力。

 

我们已经将这种方法体现在我们如何做出架构决策中。在开始工作之前,我们要求工程师记录他们的决定决策。把事情写下来改进了设计(毕竟,如果你不能把它写下来,你到底要如何实现它),但它也为那些有不同观点的人提供了一个意图检查。

我们的方法借鉴了两个既定流程,为 Redgate 构建了一些东西。

  • RFC(征求意见)文件起源于 1969 年互联网的早期。这是一个正式的流程,公开工作以向每个人提供意见。RFC 过程今天仍然用于定义互联网的关键部分。例如,您可以查看有关 IPv6完整讨论记录(引入是因为现在有数十亿台设备连接在一起)。
  • ADR(架构决策记录)是另一端工程决策的轻量级记录。ADR 日志与源代码一起保存,让工程师可以很好地概览决策背后的历史背景。

我们将两者结合起来——并提出了一种我们称之为“架构意图检查”(AIC)的东西。在开始架构更改工作之前,AIC 充当非阻塞检查。我们要求团队寻求相关利益相关者的反馈,如果发现可能改变决策的新信息,我们将改变决策!我们假设我们的大多数工程决策都是好的,因为我们一直在努力确保工程团队拥有更广泛的业务背景。

 

1
猜你喜欢