DevOps有“政治性”

Jun 19, 2018, by John Contad

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

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

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

DevOps是非范式的

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

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

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

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

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

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

• 选择一种技术时，存在组织预设和指引吗?您的组织是否偏好某一组特定的技术?

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

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

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

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

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

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

因为选择都是由人决定的，所以，

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

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

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

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

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

这听起来并不新奇

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

安德鲁•考斯格里夫Andrew Cosgriff 曾经反复地痛苦地表达：一切都是一种权衡。

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

这意味着什么？

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

强烈的观点，松散的把控。

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

同理心就是一切。

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

持续的沟通是关键。

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

不要试图做出正确的选择，而是尽量选择深思熟虑后的结果。

至少，在DevOps上下文中，没有最终正确的选择，这实在是太难啦！我们必须努力确保我们的选择中，那些因素是被公平对待，没有裙带关系，要谨记自己的偏见。

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

原文链接： https://medium.com/%40jpcontad ... a223c （翻译：易理林）