这篇文章是为那些在大型公司或“企业”工作的人而设计的，他们正在探索“ DevOps”的真正含义以及为什么要为此而努力。 我已决定将其分为两部分，以简化本文中的一些想法。 我怀疑我会在这里写很多东西，并在其他一些帖子的基础上继续写作。 在Twitter @christianposta上打我以表达分歧。
关于网络上的DevOps，同理心和组织变革，有一些很棒的东西。 我广泛地帮助企业开发和设计分布式系统（传统的，云原生的以及中间的），以提供业务价值。 企业希望更快地交付业务价值以在各自的市场中保持竞争力并不奇怪，而软件/技术可以帮助他们做到这一点。 不，scratch一下。 软件/技术是实现该业务价值的关键要素和交付手段。 但是，即使有如此多的讨论，博客，会议讨论等，公司仍在努力了解DevOps的真正含义以及如何实现它。 如果您看到过“ DevOps工程师”的职位发布或对加入“ DevOps团队”的疑问，您将确切地知道我在说什么。 为了更快地交付业务价值，我们必须采取与传统方式不同的方法。
我已经写在小团队，是典范的的DevOps和微服务工作运动的影响 ，并一次次我尝试借鉴这些经验，帮助指导客户来与这些概念的正确的道路 。 但是，互联网独角兽如何实施（并不断评估和发展）DevOps方法与成熟的大型企业对此进行思考之间存在脱节。 对他们来说，这只是另一个“团队” ..或“职位名称” ..或“他们可以购买的技术”……因为过去130多年的公司就是这样思考做事的。 我坚信，上一点的症结在于，为什么企业很难绕开“ DevOps”和必然的“微服务”来解决问题，以及如何充分利用云技术带来的优势。 这些都是相关的概念，因此让我们退后一步，了解我们应该从哪里来。
复杂与复杂
我们生活在一个复杂的世界中，而不仅仅是一个复杂的世界。 情况一直如此，但是由于技术的原因，复杂性正在越来越多的地方出现。 那么复杂，复杂之间有什么区别，我们为什么要关心呢？ 将系统视为复杂，实际上却是复杂的，可能会产生深远的负面影响 。
简单的系统就是这样。 易于理解，可预测且运动部件很少。
[简单系统]包含很少的交互，并且非常可预测。 考虑打开和关闭电灯：每次相同的动作都会产生相同的结果。
复杂的系统是可以理解的，尽管它具有更多的活动部件。 有一组可预测的输入，也许是用于组合这些输入的众所周知的公式，模式或过程，以及一个易于理解的输出。 例如，汽车发动机非常复杂。 有许多活动部件，它们以明确定义的方式相互连接和交互，可以将它们分解成它们的组成部分，分别理解，然后根据某些手册进行重新组装。
关于如何处理和管理复杂的系统， 另一种表达方式是 ：
一个复杂的系统需要专家和理性的领导者，自上而下的计划，平稳的策略实施以及运行平稳的类似时钟的组织。 指定工作并将其委派给特定单位。
另一方面，复杂的系统由许多交互组成，这些交互的输入/输出/行为是不断变化的，并且是不可预测的。 例如，城市是复杂的系统。 金融系统，气候模式，抚养子女和商业市场也是如此（例子很多！）。 尝试尝试预测和应用过去可能有用的输入，但将来可能会或可能不会产生所需的输出。
换句话说，复杂的系统具有基于输入的预期输出。 无论输入看起来如何，而且会不断变化，都无法根据输入来预测复杂的系统。
你问“我为什么要在乎”……好问题。
处理复杂性
我们的商业市场瞬息万变。 技术使我们的业务前景比以往更加复杂 。 社交媒体使我们能够获得比世界历史上任何时候都多得多的联系和互动，其结果未知/无法预测。 几年前乘飞机飞往联合航空的吉他手戴夫·卡洛尔（Dave Caroll）到达该目的地时，发现他检查飞行的吉他已损坏。 曼联拒绝支付任何赔偿，因此他发布了一段名为“ United Breaks Guitars”的歌曲的视频 。 该视频广为传播，在大约一个月的时间内就获得了500万次点击。 在4天之内，联合航空股价下跌10％，使股东损失了1.8亿美元的价值。 没有人能预料到发布该视频的效果。 另一方面，技术是同样强大的破坏力量。 虽然您的公司/公司可能会影响一些差劲的客户服务并在一夜之间带来负面影响，但是采用新方法进入现有市场的初创公司可能会在周末突然冒出病毒，大肆宣传并严重破坏现有市场。 否则该周末启动的公司对任何市场的影响都绝对为零。 由于技术的原因，我们市场的不可预测性使事情变得更加复杂。
为了处理复杂性，系统（或公司）必须能够Swift做出反应。 这就是对“敏捷性”的需求。 不仅是“业务级敏捷性”，而且由于我们的公司越来越受到软件和技术的支持，我们需要敏捷的软件系统和软件交付团队。 但是其中存在着本文标题的动机。 在过去的130多年中，我们一直在为提高公司效率进行优化。 这种效率带来了惊人的成就，但是对于处理复杂的问题（例如制造汽车发动机）而言，效率非常高。 处理复杂的问题还需要其他的东西。
效率不再足够
早在1800年代，很常见的是，工匠根据学徒/指导，经验和潜在的有害错误来从事其行业（例如，切割，成型，安装钢材）。 每位工匠都以自己的贸易方式，就好像他们知道正确的贸易方式一样。 随后出现的弗雷德里克·温斯洛·泰勒 （ Fredric Winslow Taylor ）似乎创造了奇迹：他在1900年为巴黎世博会经营的钢铁切割厂中重建了一小部分。他为这项“发明”赢得了金牌。 当当时的标准速度约为9英尺/分钟时，他的一对夫妇和几台车床的团队能够每分钟切割50英尺的钢材。 当时，这是革命性的。 类似于史蒂夫·乔布斯（Steve Jobs）首次推出iPhone。 这个奇迹归因于不是新的车床或新技术。 相反，这归因于泰勒的还原主义管理方法：通过许多实验，测量和Craft.io变更，泰勒发现了切割钢材的最佳温度，工人彼此之间的最佳距离以及他们的工具，以及进行切割的最佳方法。用水冷却钢等。 简而言之，泰勒专注于流程的效率。 在他的钢铁厂，他不仅可以非常有效地生产钢屑，而且可以以比任何其他人都便宜的价格做到这一点：不仅他有效率，还可以解雇昂贵的工匠并用更少的钱代替他们。 -熟练的工人，可以按照taylor及其“经理”列出的工作表进行操作。
这听起来与几年前的软件模型有些相似吗？ 瀑布式效率，外包开发商等？
在20世纪的大部分时间里，“效率”的目标是目标，并且建立了管理结构以挤压尽可能多的效率并消除昂贵的Craft.io。 我们被进一步分为几个专业小组，告诉我们不需要只关注我们的一小部分整个过程。 此外，在复杂的机器中，我们被视为笨拙，昂贵的代码猴子，可更换部件。
当我们只处理复杂的系统时，这非常有用。 有了已知的投入，已知的流程，18个月的计划周期以及对复杂情况的预测，我们就可以使用这种简化高效的模型可靠地生产产品。 但是，当事情复杂，未知，不可预测时，尝试使用相同的规则手册可能会使您破产。 只需询问柯达…或《边界》或《大片》。
问题在于，效率集中在减少可变性和预定产出上。 但是，在我们这个复杂的世界中，我们需要准备好灵活应对突发事件，市场状况，竞争对手等，并通过为可变性（通过定义）留出与高效时钟不一致的空间来实现灵活性。工作模式，我们非常珍惜。
DevOps与效率无关
环顾您的组织：至少从IT角度来看，您可能以效率的名义设想了“专业化”和角色：黑客对代码进行开发的开发人员； **数据库的DBA； 管理服务器的运营团队； 建立和发布将代码插入应用服务器的团队； 宣布安全要求的infosec； 等等等等 游戏的名称是“您的开发人员可以有效地编写代码； 不必担心其余的过程，只需按照您的说明进行操作即可…………“您的DBA ..安装，管理和调优数据库……无需担心应用程序”……“您是质量检查人员，只需测试该死的软件，不用担心它在哪里运行或如何创建”，等等。 效率FTW！ 我们个人的效率越高，我们就会越好！
实际上，团队的这种“效率”和筒仓/专业化导致了更多同步需求。 它会导致更多的“不良沟通”……甚至会导致不良行为：
当您抽象化人们的行为后果时，就会出现不良行为
实际上减慢了我们团队交付软件的速度，进而反过来带来了业务价值。 在这方面，DevOps与效率无关。
第二部分
在第二部分中，我们将研究美国太空竞赛的历史性事件，以及我们所谓的“ DevOps”如何使之成为可能。 管理层，团队等是与众不同之处，而技术是第二要考虑的因素。 听起来有点熟？
翻译自: https://www.javacodegeeks.com/2015/12/devops-myth-efficiency-part.html