大多数的IT从业者可能都对传统IT陷入的恶性循环三部曲很熟悉。

 

IT恶性循环 第一部曲开始于IT运维 。

 

我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。更令人担忧的是，我们最脆弱的组件正支撑着最重要的业务系统或者最关键的项目。

 

换句话说， 那个最容易发生故障的系统就是我们最重要的系统，也是所有紧急变更的中心。当这些变更失败的时候，那些最重要的公司承诺，例如客户服务可用性、营收目标、客户数据的安全性和财务报告的精确性等，就会直接受到危害。

 

IT恶性循环 第二部曲始于有人必须去弥补最近未兑现的 承诺 。

 

这可能是某个产品经理承诺了一个更大规模、更大胆的吸引客户的功能，或者是业务主管设置了一个更高的收益目标。然而，他们无视技术能实现什么不能实现什么，以及到底为何没能兑现之前的承诺，而是让技术组织按照新的承诺交付成果。

 

结果，开发团队被指派去做另一个紧急项目，这个项目必然需要解决新的技术难题，需要利用各种捷径以赶上承诺的发布日期，而这又导致了技术债务的增加——此时我们又承诺一有时间就处理这次产生的所有问题。

 

在这样的背景下，产生了IT恶性循环第三部曲，也就是最后一部曲。在这里，所有事情都变得更加困难—— 所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的

时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想使之继续转动，就需要付出更多的努力。

 

尽管当我们身处其中时很难察觉到，但是当你退后一步，就会发现这个恶性循环是显而易见的。你会注意到产品代码部署消耗的时间更长了， 从几分钟到几个小时，再到几天或者几周。更糟的是，部署的效果越来越差，这导致客户服务中断的次数越来越多，需要运维部门来救急，而他们也因此无法偿还技术债务。结果，我们的产品交付周期越来越长，做的项目越来越少，项目目标也越来越小。而且，对所有人工作（尤其是对来自客户的反馈信号）的反馈越来越慢，且越来越弱。不管我们做出怎样的尝试，事情似乎总是变得越来越糟糕——面对日新月异的市场竞争， 我们不再能够快速响应，也无法为客户提供稳定、可靠的服务。我们最终因此失去了市场。 

 

我们反复地看到， 一个IT做得失败的公司，整个公司也都是失败的。

 

用DevOps打破恶性循环 的 11 个措施 ：

 

1. 开发：理想情况下，小团队的开发人员独立地实现自己的功能，在类生产环境中验证其正确性，再把代码快速、安全、可靠地部署到生产环境里。代码部署是日常的且可预测的工作。部署工作不是选在周五的午夜开始、鏖战整个周末才完成，而是在每个人都在办公室的工作日进行，大多数时候甚至不会引起客户的注意（客户兴奋地看到出现了新功能或者旧缺陷被修复了的情况除外）。

 

2. 运维：由于代码部署是在工作时间段内进行的，几十年来，IT运维人员第一次可以像其他人一样在正常工作时间段工作了。通过在流程中的每一个步骤创建快速反馈回路，每个人都可以立即看到工作效果。只要代码变更提交到了版本控制系统，就会在类生产环境中运行快速的自动测试，这持续地保证了代码和环境符合设计预期，并且总是处在安全的可部署状态。

 

3. 自动化测试。自动化测试可以帮助开发人员快速发现错误（通常在几分钟之内），实现更快速的修复以及真正的学习。如果错误是在6个月后的集成测试中发现的，那时相关的记忆和因果关系早已消退，想从中学习是不可能的。自动化测试使技术债务不再积累，问题在发现之后就立即被修复了。如果需要，这还可以调动整个公司参与问题的处理，因为总体目标高于局部目标。

 

4. 遥测技术。在我们的代码和生产环境中无处不在的遥测技术，保证了问题能被迅速地发现并纠正，确保一切都能按照预定的方式进行，并且客户能从我们创造的软件中获得价值。在这样的场景下，每个人都感觉富有成效——这种架构使得小团队能够安全地工作，同时在架构上和其他团队的工作解耦，这些团队使用了集运维和信息安全最佳实践于一体的自服务平台。团队独立、高效地处理小批量工作，快速且频繁地为客户提供新的价值，而不是每个人都在等待，面对大量迟来和紧急的返工。

 

5. 黑启动（dark launch）技术。通过黑启动技术，即便是复杂的产品和功能发布，也变得稀松平常了。早在发布日期以前，我们就已经将所有功能的代码部署到了生产环境中，它只对内部员工和部分真实用户可见。这使得我们能够测试和改进其功能，直到达到预期的业务目标。想要让新功能生效，我们只需要改变一个功能开关或者配置项即可，而不再需要经历数天或者数周的辛苦工作。这个小变更使新功能对更大规模的客户群可见，一旦出现错误，就会自动地回滚。因此，发布新功能变得可控、可预测、可逆，且压力也小了。

 

6. 问题修复。除了新功能的发布变得更加顺利外，各种问题都能在其规模小、修复容易且成本低的时候发现并修复。通过每次的问题修复，我们也让公司得到了经验和教训，能够防止问题复发，并且能在未来更快地定位和修复相似的问题。

 

7. 组织文化。此外，每个人都在不断地学习，从而营造出了一种假设驱动的文化，用科学的方法保证一切都得到了充分的验证——在对产品开发和流程改进进行有目的的衡量和实验之前不做任何工作。

 

8. 团队的稳定性。因为我们珍惜大家的时间，所以不会花几年的时间去打造客户不想要的功能，不会部署根本就不能用的代码，也不会修复非问题根源的缺陷。由于我们关心目标的实现，所以建立了长期的团队责任制，负责目标的实现。在一般的项目团队中，每次软件发布以后开发人员就被打散并重新分配了，他们没有机会得到自己工作的反馈；我们则保持团队的完整性，这样团队可以进行迭代和改进，用团队各成员所学到的经验来更好地实现目标。对于给外部客户解决问题的产品团队，以及帮助其他团队提高生产力、可靠性和安全性的内部平台团队来说，这一点同样重要。

 

9.团队文化。我们的团队文化体现了高度的信任与合作，而不是指责，人们会因为冒险而获得回报。他们可以无所畏惧地讨论问题，而不是把问题隐藏起来或者往后拖延——毕竟，我们只有先认识到了问题，才能解决问题。而且，因为所有人都需要对自己的工作质量负完全的责任，所以每个人在日常的工作中都创建自动化测试，并且使用同行评审的方式来保证在问题影响到客户之前就解决它。与从管理层向下授权审批的方式相反，

 

10.内部反馈纠错系统。上述过程降低了风险，让我们能快速、可靠、安全地交付价值，甚至可以在挑剔的评审人员面前证明我们拥有一个高效的内部控制系统。在出现问题时，我们进行不指责的事后分析 ，这并不是要惩罚某人，而是为了更好地理解导致事故的原因，以及如何防止事故再次发生。这个方法强化了我们的学习文化。我们还通过举办内部技术研讨会来提高技能，保证所有人不是在教就是在学。

 

11. 故障演练。因为注重质量，所以我们甚至会故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的。我们按照计划做大规模的故障演练，随机结束生产环境中的进程，中断正在运行的服务器，同时还注入网络延迟以及其他恶意因素，以此来确保系统的可靠性。这样的方式为我们的系统带来了更高的可靠性，同时为整个公司提供了更好的学习和提高机会。

 

参考资料《devops实践指南》

 

翰德恩洞见 ：

 

过去很多年以来，本文所述的传统IT陷入的三大恶性循环发生在各种类型、各种规模的公司里。但是，在很多传统企业里，陈旧的理念是IT是成本中心，非利润中心，因而对于IT所陷入的恶性循环重视不足。随着数字化时代的到来，越来越多的传统企业都认识到，每家公司都是一个数字公司，不论他们处于哪个行业，数字化就像我们呼吸的空气、喝的水一样不可或缺。无论他们认为自己处在哪个行业。IT也不仅仅是成本中心，而是起到关键的业务赋能作用。企业领导者想要实现业务目标，对有效IT管理的依赖程度远远超出了他们的预想。

 

DevOps能够提高公司业绩，实现开发、测试、运维、信息安全等各技术角色协同的目标，同时改善IT员工的压力。这是为什么DevOps近些年在全球软件生态激发出了这么大的热情。 本文小编总结了DevOps的11个措施，相信能够给到您关于如何打破传统IT陷入的恶性循环一些启示。