devops和ci_DevOps和效率神话，第二部分
devops和ci
在上 一篇 文章中 ，我概述了DevOps为什么与效率无关 ，以及在我们现在非常复杂的世界中，通过首先解决效率来解决“复杂”问题的旧方法实际上是无效或不灵活的。 实际上， 放开我们一个世纪的直觉，运用简化派管理理论来创建高效的工作场所，可能会导致更有效地构建复杂的系统，并具有灵活性和创新的空间。 最终， 创新推动了我们公司的前进，而没有有效地保护我们已经拥有的东西 。 要发表意见，请让我知道@christianposta
顺便说一句，写这篇文章的动机是将点点滴滴与我亲眼目睹的东西联系起来，并参加了一个特别预示的DevOps Internet Unicorn和我所访问的企业所见体系结构评估，分布式系统实现，云本机应用程序，微服务，DevOps等……实际上，它们都是高度相关的……就像@littleidea在Twitter上最近发布的推文
我的立场是CD，微服务和devop是同一现象不可分割的方面
那么，这种“现象”是什么？ ……让我们尝试将点连接起来。 TL; DR版本在结尾:)
因此，让我们回到故事上来回顾一下 ：
- 我们所处的环境比以往任何时候都更加复杂
- 复杂系统的策略不能适应复杂系统
- 专注于可能适用于复杂系统但不适用于复杂系统的效率品种管理
- 为了处理复杂的系统，我们需要灵活性
- DevOps不接受Taylor等人将其神奇化的传统还原论管理技术。 等
在1960年代处理复杂系统
我喜欢斯坦利·麦克莱斯特将军在他的《团队》一书中对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）登上月球，宣扬了他现在著名的话语“人类的一次巨大飞跃”……并在其他人之前做到了这一点，在肯尼迪演讲之后不到7年。 另一方面，与此同时，欧洲发射器开发组织刚刚连续第五次未能完成完全相同的任务。
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，微服务，云等都旨在提高组织的效率 。 这为将我们的组织视为复杂的系统而不是机器奠定了基础。 这种方法使自己真正了解 反馈 ， 失败 ， 学习 ， 自主性和突发行为的价值 ，这对于任何复杂的系统在复杂而不仅仅是复杂的世界中展现并保持相关性至关重要。
点连接的灵感
我亲身经历了许多这样的力量，并且正在寻找一种整体地表达它的好方法。 到目前为止，这些书在这方面有所帮助，我强烈推荐它们：
第三部分？
那么，出现并被冠以“ DevOps”之类的炫酷技术呢？ CI / CD，构建自动化等如何？ 这些都如何影响我上面概述的叙述？ 我原本打算写两部分，但我还有更多话要说。 请继续关注第三部分！
翻译自: https://www.javacodegeeks.com/2015/12/devops-myth-efficiency-part-ii.html
devops和ci