当您正在愉快的度过周末时光的时候，而手机突然将您的注意力转移了。收到一条服务故障的消息。运维团队除了重启或回滚外没有其他能力，但最后一个好的副本已经存在了几个月。谁知道从那以后还有什么变化。由您自己解决泄漏问题，但与办公室和计算机相距遥远。您的应用程序可能有这些特征：- 经常遭受内存泄漏并通过重新启动操作“修复”的应用程序。
- 现在正在部署后的几分钟内耗尽服务器资源。
- 该应用程序实际上无法使用。
在传统的企业IT模型中，这样的事件太常见了，在该模型中，开发和运营位于墙的相对两侧。但这不一定是这种方式。DevOps不仅适用于初创企业。它也可以在企业中使用。像自动化和客户服务一样，“运行自己构建的内容”可以成为使用DevOps模型改善企业IT交付的有效原则。在传统环境中，开发人员设计和设计解决方案，然后将其移交给运营。有时他们很友善地就如何处理生产问题提供了一些指导，有时他们对生产环境一无所知。当这些团队保持各自独立的实体时，每个团队都几乎没有其他团队如何工作以及他们需要什么的信息。运营团队通常拥有运行手册，SOP（标准操作程序）或某种其他机制来解决生产中出现的问题。当您需要快速修复时，这些方法可能会非常有效，但是当根本原因没有找到和解决时，就像使用口香糖修补漏水的船。最终，您将陷入困境。
DevOps可以提供更好的方法
云帮助拆除了这堵墙，因为有了它，您的基础架构开始看起来很像软件。API驱动的特性使您可以将基础结构视为代码，这是开发人员可以理解的。既然每个人都离基础架构越来越近，那么操作自然就变得更加重要。同时，越来越多的软件作为服务出售，您的客户理所当然地要求不断改进。他们可能会在这里和那里容忍一个错误，但前提是必须立即解决这些错误并且不要一直发生。为了跟上这些变化，您需要倾听客户可能未明确与您直接沟通的线索和见解。像您一样，他们忙于其他事情，当他们打电话给您反馈时，他们可能会感到不满意。尽管与客户的互动都是学习的机会，但最好按自己的条件安排他们。要在开发和运营之间架起一道墙，就很难找到这些见解-通过快速修复，运营可能会扫清一切，所有这些都是从传统的IT模型向着DevOps文化转变的充分理由，在DevOps文化中，开发和运营共同成为唯一的焦点。我试图鼓励高管在以DevOps为驱动力的组织中将“运行自己构建的东西”作为至关重要的原则。这只是我从组织中获得的一些好处和行为：生产设计运行构建的内容会迫使开发团队在设计软件时考虑其软件在生产中的运行方式。这可以帮助您的团队避免在最后一刻出现争吵的情况，当团队试图将其构建的内容强制适应生产环境以在截止日期前完成时。我不记得有多少次看到这种实质性的质量下降了。您可以在部署时更改某些内容，以解决生产与开发之间的不同之处，运行您认为是相关的测试，然后发现此更改在系统中的其他地方引起了错误。更大的员工自主权
根据您的经验，建立自己的思维方式会鼓励主人翁精神和责任心，这会导致更独立，负责任的员工，甚至组织中的职业发展。
更高的透明度
没有人希望他们的个人时间被打断。接听电话的人将尽一切可能避免将电话置于第一位。您的团队自然希望在环境中具有更大的透明度，并且将实施主动监视，以便他们可以在问题变得广泛之前识别问题或有关模式。除了在问题发生之前就发现问题，这种透明性还应该使查找仍然存在的问题的根本原因变得容易得多。
更加自动化
开发人员讨厌重复人工任务，因此，如果发现他们不得不在生产中一遍又一遍地做某事来解决问题，那么他们更有可能找到根本原因，并一路实现自动化。
更好的运营质量
诸如透明度和自动化之类的事情将使您的团队更高效，并将继续提高卓越运营的标准。
客户更满意
运行您构建的内容将迫使整个IT团队更多地了解客户。这些知识将不再仅限于产品或销售团队，这些见解在用作不断改进产品的反馈回路时会非常有用。
