本篇开始学习DevOps基础的第二张，第一章4篇文章介绍了什么DevOps的概述。可以肯定的是，你对DevOps依然没有一个明确的概念定义，但是有一些懵懂的概念。从顶层思想上对DevOps有了一个理解。就好像，即使你学习完了本系列的所有DevOps基础课程，你依然不是一个DevOps从业人员，因为你没有实战过。
我敢肯定，一般而言，IT部门并不是业务中最受欢迎的部分。 几十年来，企业一直在使用技术提供服务，但IT的成功率和满意度仍然很低。内部技术组织有许多队伍构成，开发人员，系统管理员，安全专业人员，网络管理员，还有DBA。
所有的这些组之间，经常发生冲突。不幸的是，当你想要完成你的工作时，并不是那么有趣，似乎没有人希望你成功。 在DevOps中，这被称为混乱之墙。我们最能体会的就是开发和运维之间的矛盾，就下下面这张图。典型的场景就是，开发人员写完了代码，直接丢在墙上（实际是公司内部一个文件服务器地址），然后让运维人员去墙上取下代码文件去进行运维更新活动。这样，在开发和运维两个组之间就产生了间隙额，但是他们又要完成实现同一个目标。
人们常常任务，这些分歧是由于不同组之间的主要的专业技术能力之间不同而产生的。这忽略了混乱之墙产生的原因。真正的原因是，组织在激励反对的行为。他们反对，开发干运维的活，运维干开发的任务。在传统IT领域，开发团队被定义为这样的一个团队：尽可能快地开发软件新功能，更新错误。与此同时，运维团队被这样定义：负责维护稳定和代码控制变更带来的冲突。这种职责分离会导致有害的利益冲突并减少反馈循环。同时激励团队只优化他们自己关注的领域会给整个组织带来不太理想的整体结果。
开发团队至少通常由业务部门或应用程序开发组成，但基础架构团队（IT基础设施和运维团队）通常由技术堆栈组织。这会在基础架构团队中创建额外的墙。 现在您可能需要六个团队来进行更改，而不是仅仅是开发和运维团队，来自网络团队，UNIX团队，Web团队，数据中心团队和DBA团队。
你要知道业务和IT一致性已经成为IT组织整个历史中争论不断的话题，而技术组织也因此内部不合理组建而遭到破坏。通常，这是我们自己的IT流程和组织，无法跟上步伐。 早在2004年，我（原作者）就领导了一个网络运维团队，我们与另一个基础架构团队合作，需要向他们申请一台新服务器，获得一台新服务器花了六周时间。整个流程很规范化，它将通过采购流程，从供应商处订购，交付，装配和插入数据中心，将操作系统加载到其上，最后交给我们使用。(ps 这个流程，我经历过，我作为一个QA，需要美国那边基础设施团队，给我配置一台linux机器，整个申请流程然后审批，最后发邮件通知我，机器好了，前后差不多一个月的时间。)
然后有一天，虚拟化厂商来了。 他们展示了如何在15分钟内配置新的虚拟服务器。（ps这个事情我也经历过，前段时间购买了一个洛杉矶的虚拟主机服务，下单，付款到收到邮件可以登陆这台host，真的在十分钟之内搞定。）（前面说过作者经历六个礼拜才申请到一台新主机）太好了，我们下了订单。 在那之后，猜猜我们的团队需要多长时间才能获得新服务器？ – 15分钟怎么样？ – 那会很棒，但不是。 四周。 唯一节省的时间是从供应商处完成硬件订单所花费的两周时间。本来只需要15分钟就能得到一台新的linux服务器，结果我们经历了4个礼拜才完成，两者对比，这真的是一个很糟糕的事情。
这样的事情是无论如何都不可以接受的。我们之前遇到的那些IT事情，就像一部喜剧。都倾向于以技术专家为中心，一个人花很长时间从硬件采购到部署，只因为，他们不懂DevOps这项技术。但是，由于大多数企业高管都非常精通技术，而且当他们看到本来需要花费15分钟的时间，他们却需要四周时，他们才开始寻找答案。 尝试找到为什么他们的时间和金钱正在消耗掉那些不会让他们在市场上有更具竞争力的东西的答案。
真的，这是一个公平的问题。 因此，许多人转向外包和影子IT以试图解决这个问题，但很多时候这些新方法会导致他们解决的问题。围绕IT构建的组织和流程已经成为企业成功的直接障碍。 当这个模型以及我们的行为基于其假设时，随着时间的推移变得如此根深蒂固的文化？ 这是我们将在本章其余部分探讨的主题。第二种的主题就是DevOps是一个文化问题。
