DevOps和效率神话，第二部分-CSDN博客

在上一篇文章中，我概述了为什么DevOps与效率无关，以及在我们现在非常复杂的世界中，通过先解决效率来解决“复杂”问题的旧方法实际上是无效或不灵活的。实际上， 放开我们一个世纪的直觉来应用简化派管理理论来创建高效的工作场所，可能会导致更有效地构建复杂的系统，并具有灵活性和创新的空间。最终，创新推动了我们公司的前进，而没有有效地保护我们已经拥有的东西。要发表意见，请让我知道@christianposta

顺便说一句，写这篇文章的动机是将点点滴滴与我亲眼目睹的东西联系起来，并参加了一个特别预示的DevOps Internet Unicorn和我所访问的企业所见体系结构评估，分布式系统实现，云原生应用程序，微服务，DevOps等……实际上，它们都高度相关……如@littleidea在Twitter上最近的推文

我的立场是CD，微服务和devop是同一现象不可分割的方面

那么这个“现象”是什么？ …让我们尝试将点连接起来。 TL; DR版本在结尾:)

因此，让我们回到故事上来并进行一些回顾：

我们所处的环境比以往任何时候都更加复杂
复杂系统的策略无法适应复杂系统
专注于可能适用于复杂系统而非复杂系统的效率品种管理
为了处理复杂的系统，我们需要灵活性
DevOps不接受泰勒（Taylor）等人创造的这些传统的简化论管理技术。等

在1960年代处理复杂系统

我喜欢Stanley McChrystal将军在他的《团队》一书中对NASA太空计划所做的叙述。它说明了DevOps原理的基础，并且显然（如您将很快看到的） 并不局限于开发人员或运营世界。实际上，这些原则植根于系统思考，而这种思考要比现在大肆宣传的DevOps运动要早得多。

1962年9月12日，总统约翰·肯尼迪（John F. Kennedy）在赖斯大学（Rice University）的35,000人面前发表了“我们选择登月”的演讲。他宣布，美国将派遣人类在月球上着陆，并安全返回，而其他任何人都不会：

Wwe将送往距离休斯顿控制站240,000英里的月球，这是一颗高度超过300英尺的巨型火箭，由新金属合金制成，其中一些尚未被发明，能够承受高温并承受数倍的压力比以往任何时候都拥有的经验更多，配备的精度比最好的手表还要好，携带了推进，制导，控制，通讯，食物和生存所需的所有设备……做到这一切，正确地做，并首先做在这十年结束之前，我们必须大胆。

总统说这简直是大胆。当时美国在太空和月球竞赛中令人尴尬地落后，而他宣称“即使没有发明金属合金”，美国也将首先登上月球，这简直令人可笑。一些。大约四年前，苏联成功发射了第一颗人造卫星Sputnik 。他们还把第一只动物送入了太空，进行了第一次月球飞越，第一次进行了月球撞击，不久之后，第一个人类进入了轨道 -第一个进入太空的人。

另一方面，美国有一些重大的失败记录。 1960年11月，美国国家航空航天局（NASA）进行了首次无人驾驶试飞，水星-红石一号（Mercury-Redstone I）升空了4英寸，然后降落下来。它的逃生火箭弹折断了，飞向空中。几个月前，发生了类似的事情：水星飞船与Atlas火箭之间的结构不兼容导致这些努力失败了。

然而，在肯尼迪发表演讲不到7年后，尼尔·阿姆斯特朗（Neil Armstrong）登上月球，宣扬了他现在著名的话语“人类的一次巨大飞跃”……并在其他任何人之前做到了。另一方面，同时，欧洲发射器发展组织刚刚经历了连续第五次未能完成完全相同的任务。

NASA和ELDO之间的差异与技术，专业知识，资源等无关。后来的差异归因于组织的结构和合作方式。

NASA“系统思考”的成功

在载人航天飞行办公室（OMSF）项目启动之前，NASA的组织方式似乎类似于我们今天在大公司中看到的“效率孤岛”，这是受到泰勒简化主义思想的启发。有些小团队孤立地工作着自己的难题，而没有考虑大局。整个火箭的不可预测的振动影响了所有学科（结构工程，推进工程，电气等），但没有在自己的高度受控的专业环境中经历这些力。从未有如此多的电子设备紧密地紧紧卡在一起，以至于每个组件都受到电磁干扰，这又是他们在孤岛环境中不会遇到的东西。当他们将这些高效创建的作品放在一起时，它们将以意想不到的方式一次又一次地失败。

NASA将通过系统管理，系统思考和解决其组织问题来克服这一问题，为20,000个承包商，200所大学，80个国家/地区管理300,000个人，并耗资190亿美元。他们不得不；总统已经公开签署了这项任务！

1963年，美国国家航空航天局（NASA）带领乔治·穆勒（ George Mueller ）领导（OMSF）项目。 Mueller最初反对，直到NASA同意重组他领导的项目后才接受。 MuellerSwift淘汰了旧的组织结构图，并要求经理，工程师和高管（他们很乐于在自己的范围和孤岛中进行工作）每天互相交流并共享信息。这在NASA总部造成了严重破坏。

穆勒（Mueller）创造了一个环境，可以即时共享信息，每天进行跨学科会议，设有实时更新信息，测试结果等的现场中心。来自整个组织的团队可以即时进行交流。它是互联网之前的“互联网”。 “您可以即时上下沟通”…“在组织内即时传播知识”一位管理员说：“它起作用并且我们如期准备就绪的原因是，我们每个人都需要在这个房间里进行决定……到了关键时刻，我们可以在早晨发现问题，并且通过停业就可以解决问题，分配资金，做出决定并使事情正常进行。”

在ELDO池塘的另一侧，不同的国家生产了火箭，助推器，卫星测试车等的不同部件。他们没有共享信息，承包商直接向自己的国家机构报告，并且各自寻求最大化自己的实力。经济优势。多种界面故障导致5次单独发射失败，法国记者让·雅克·塞尔万·施雷伯（Jean-Jacques Servan-Schreiber）认为，欧洲在太空竞赛中的滞后不是金钱问题，而是他的《美国挑战 》一书中的 “首先是组织方法”。

系统思考

这种方法，即系统管理/思考，是基于一个核心租户，该租户本质上与还原主义思维背道而驰……对于具有许多复杂交互作用的系统而言，它是复杂而未知的：

如果没有对整个系统的基本了解，就无法理解系统的一部分。

最后，NASA创建的是整个项目所有团队之间的“共享理解”，即使建立这种理解耗费了其他职责，并且“效率低下”。 NASA领导层了解到，当创建高度复杂甚至未知的产品时，将专家局限在筒仓中是愚蠢的。高水平的成功取决于低水平的效率。 Wernher von Braun甚至是最热衷于反对Mueller的方法之一的高层管理人员，也透露“使NASA滴答作响的真正机制是在房子的左右两侧之间不断进行交叉喂入”。

这是否意味着我们都应该成为通才？

没有。

专业化仍然是必不可少的，但是关键是要具有“整体的基本理解”。在McChrystal的书中，他将其称为“共享意识” ，其中不同的专业团队“对操作环境和组织有基本的整体理解”。

在吉姆·怀特赫斯特（Jim Whitehurst）的开放组织（Open Organization）中，他谈到点燃激情并将这种激情引导到一个共同的，共同的目的。

无论您怎么说，我们的团队都应该意识到共同的目标，在各个阶段都看到并理解更大的愿景，等等……并且为此付出的努力必然是“低效率的”。

那是否意味着我们正在“杀死开发人员”？

那么， DevOps如何杀死开发人员呢？

因此，当我们谈论“ DevOps”时，我们谈论的是在开发人员和运营（以及其他人员）团队之间创建“共享意识”。 “开发人员”的步骤，过程，自动化和实施实际上是在团队之间创建“共享意识”，每个组织可能有自己的方式，这些方式是特定于该组织的上下文的。 DevOps仅仅是“自动化构建”或购买工具。实际上，使无效的事情高效运行是对时间的可怕利用，而不管您尝试使用什么流行语来进行辩解。

那么我们是“杀死开发人员”吗？

关于“杀死开发人员”的文章试图在“ DevOps”之间划清界限，这是对其余跨职能职责的熟悉程度，然后跳到需要“全栈开发人员”的位置。由于作者声称这种全栈式开发人员思维方式源自初创公司，因此我们正在通过使他们成为通才来杀死开发人员。

不。 DevOps使开发人员更有效。

让我们更进一步：DevOps，微服务，云等都旨在提高组织的效率。这为将我们的组织视为复杂的系统而不是机器奠定了基础。这种方法有助于真正理解 反馈，失败，学习， 自主性和突发行为的价值 ，这对于任何复杂的系统在复杂而不仅仅是复杂的世界中展现并保持相关性至关重要。