DevOps有“政治倾向性”


我在这里断言:很多人都认为技术及技术相关部分,本质上与政治无关。但事实并非如此。在接下来的10分钟里,我会试着证明我的观点,希望其中的有些观点可以取得大家的认同。

进一步澄清一下:我所说的政治,并不是类似于“我投票给绿党!”或者“我是自由主义者!”的政治。而且从组织的角度来看,我们愿意因为某些考虑,而做出一些权衡。
图片_1.png

需要权衡或称为分歧的关键是:我们所创造的技术是我们内在信仰系统的一种表达。如何构建事物是以一种非凡的方式来展现我们内在的价值体系。

DevOps是非范式的

DevOps这个词流传甚广,对它的理解也因人而异。Jez Humble将其定义为一种系统的操作方式,所操作的系统具有快速变更的特征,例如I.E.,CI/CD,快速反馈环等。还有人将它定义成操作人员,他们使用开发人员的模式来更加快速的运行和部署应用。但在很大程度上的事实却是:存在一种伪共识,认为DevOps与开启组织敏捷性有关系。却没有提及敏捷对不同的组织会意味着不同的东西。

从组织的角度来看,我认为DevOps没有规范的实现方法。如果这么说有点难以理解的话,让我进一步展开。因为语言对不同的人有不同的含义,所以我要在这里做些说明,概述一下我所说的“不同的实现”是什么意思,但不提供我个人的观点。一个组织通常有以下几个关键点:

团队管理的基础设施 VS 集中式管理基础设施

团队有自己的基础设施吗?还是有人在中间专门提供运行?
图片_2.png

如果是前者,开发团队是否必须学习运维?意味着开发人员是否要对自己的基础设施负责?他们是否需要随时保持响应?他们是否可以以任何想要的方式运行他们的应用?

而如果是后者,那么是否意味着有一个专职的操作团队?意味着开发人员是否只需关注自己的应用?那非工作时间的应用支持怎么办呢?换个角度,如果不清楚问题的根源是应用程序还是基础设施时,怎么办呢?

选择一种技术时,存在组织预设和指引吗?您的组织是否偏好某一组特定的技术?
图片_3.png

如果组织没有任何预设意见,是否意味着团队可以运行任何想要的东西?如果是这样,是否有一种机制确保任何人都知道每个人在做什么?当外部团队从安全性或可用性的角度影响了某个服务时,如何看待责任问题?

如果组织有某些预设意见,如何判断一个团队是否可以偏离?如果一个团队决定偏离,决策人员是否有足够的上下文信息(业务和技术)来做出决策?我们又如何确定以上的信息?

如果组织有特定的要求,这是否意味着有业务单元会在更新、更好的技术选择上进行创新?如果是,他们可获得足够的支持吗?相反,其他团队的交付速度是否会成为瓶颈?

以上选项信息,我们会根据我们认可的价值和对事物的评价选择其中的某个选项。

没有正确的选择,只有深思熟虑后的结果

我很抱歉不能在此给出一个解决方案,我能够且愿意提供的最好意见是深思熟虑。在选择一种或另一种方法时,都需要慎重考虑多个因素——在理想的情况下,所做的选择都是透明的和经过考虑的。然而,在大多数情况下,它们都是偶然的或随机的。

因为选择都是由人决定的,所以,选择往往受限于决策人知道多少以及知道哪些部分。也许他们所在的公司选择了一条不成功的道路。也许他们已经在这个组织工作多年,并且经历了其他所有方法都失败了(直接或间接的)。

选择受限于人际关系,尽管我很讨厌这么说。但人们更倾向于听信于和自己关系好或相处融洽的人。“我更喜欢和不会给我带来压力的人在一起。我们交谈的频率以及交谈的对象影响着自己的决定。”我在某种程度上,对此表示同情。

选择受限于我们的个人倾向,通常会坚持自己的观点。我想将有强烈感的观点和能严格控制的观点区分开来。完全有可能有选择某个观点的强烈感,但一旦有足够的证据支持它,就可以理解为能严格控制的观点,而选择这个观点。

选择还受限于组织内部的价值体系。如果我们允许团队管理自己的基础设施,这是否意味着我们信任他们?如果我们不这样做,是否意味着我们希望团队能够安全地部署应用?

综上所述,选择会因人而异,由我们所掌握的知识,我们周围的人,以及我们改变立场的能力来决定。最终选择的结果都是基于我们的个人信仰体系。这听起来很像政治。

这听起来并不新奇

这个主题的不同方面以前都讨论过,可能有更好的方法来阐述这个事实。如康韦定律说,一个组织创建的软件是该组织通信模式的一个提喻。Edgar Schein认为,我们的价值观影响着我们的文化,而文化又影响着我们所创造的人工制品。
图片_4.png

Andrew Cosgriff曾经反复地痛苦地表达:一切都是一种权衡。

我想说的唯一一件事是:在我们开始谈话之前,我们要敏锐地意识到以下这些因素:

这意味着什么?

我知道我并没有给出一个固定前进的路径,但是我认为DevOps的“政治倾向”意味着有些事情非常重要。

强烈的观点,松散的把控。有强烈的观点并没有错。它鼓励我们去告诉自己,用知识武装自己,这样我们就能捍卫自己的观点。但当我们在面对相反的证据时不放弃我们的想法,或者我们在选择事实时变得有选择性时(“架构Y很好地应用于X公司,所以它在其他地方应用也没有问题!”)强烈的观点就不再强烈啦。

同理心就是一切。“他者化”描述的是将他人贴上不属于这个群体标签的粗暴行为。对方也存在同样的心理。例如:“别听索尔的,他说了那么多废话。”这将产生排斥的效果,让我们在理解他人的观点时,无形中就带入了偏见。在DevOps的上下文中,很容易陷入自动忽略对立阵营观点的趋势,而不是将他们的观点理解为对方汇集经验的结果,甚至可能会质疑这些经验。

持续的沟通是关键。意见必须经过考验、公开发表和公开辩护。当我们社会中那些更应该受到谴责的部分拥有了同等的支持空间时,真理才会繁荣起来;这也会影响其他人——包括那些还没有下定决心的人(骑墙派)。

不要试图做出正确的选择,而是尽量选择深思熟虑后的结果。至少,在DevOps上下文中,没有最终正确的选择,这实在是太难啦!我们必须努力确保我们的选择中,那些因素是被公平对待,没有裙带关系,要谨记自己的偏见。

在一个没有客观“正确”做事方式的世界里,我们能做的最好的事情就是确保我们被外界所告知:我们是公平的,我们保持谦虚,并一直互惠彼此。
图片_5.png


原文链接:DevOps is political.(翻译:易理林)

0 个评论

要回复文章请先登录注册