网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

DevOps的目标不仅只是增加变更的频率，而且也支持在不中断和破坏当前服务的基础上，确保功能部署成功，同时也可以快速检测和修复缺陷。这引入了服务设计，事故和问题管理方面的ITIL新准则。

2004年，我与Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》，可视运维是一个说明性的指南，该指南使得高性能IT运维能顺利实现“从优秀到卓越”的转变，关键点之一是如何控制和减少计划外的工作。

在开发和IT运维之间，DevOps不仅聚焦在创建快速和稳定的计划工作流，而且DevOps也有一个更全面的方法来系统的消除计划外工作，定义开发弹性准则，并负责管理和减少技术债务。

在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的书里，我们描述了DevOps的支撑原则——“DevOps三个基本点”，所有的DevOps模式都可以源自这3个基本点。

第一个基本点强调整个系统的性能，而非将性能局限于特定的工作领域里，这个工作领域可以大到一个部门（例如开发和IT运维）或者小到一个个人贡献者（例如开发者，系统管理员等）。

重点是由IT推动的的业务价值流，换句话说，它始于需求定义（比如被业务或IT部门定义），进行开发构建，又交给IT运维，最后价值以一种服务的形式交付给客户。

实践第一个基本点的结果——决不传递一个已知缺陷至下游，决不因小失大，总是致力于改进流程，执着于深刻理解系统需求（根据戴明的理论）

第二个基本点是关于创建从右至左的反馈回路，几乎所有的流程改进计划的目标都是缩短和放大反馈回路，以便可以持续进行必要的修正。

应用第二个基本点的结果——包括理解和回应所有内部和外部客户，缩短和放大所有的反馈回路，必要时，非常容易的嵌入客户需要的知识。

第三个基本点是打造一种文化用来促进两件事情——持续不断的探索精神，勇担风险的精神以及从成功和失败中来学习的能力，同时也得谨记：重复和实践是融会贯通的前提。

这两件事情对我们来说同等重要，探索精神和勇担风险的精神可以确保我们持续改进，它甚至意味着我们可能到达了之前曾未到过的危险区域，因此这也迫使我们去学习，掌握并融会贯通那些技能，因而使得我们能够顺利离开危险区。

第三个基本点的结果——分配时间去改进每天的例行工作，培养一种奖励冒险精神的风气，同时主动引入故障到系统中，从而提高弹性。

在《DevOps Cookbook》里，我们将DevOps模式分成4个领域，

领域一，将开发延伸至生产中——包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署，。

领域二，向开发中加入生产反馈——包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。

领域三，开发嵌入到IT运维中——包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，而且开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。

领域四，将IT运维嵌入至开发——包括嵌入和联络IT运维资源至开发，帮助开发创建为IT运维(部署，生产代码的管理等)使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。

我相信企业在应用了DevOps之后可以得到3个业务优势：产品快速推向市场（比如，缩短开发周期时间和更高的部署频率），提高质量（比如，提高可用性，提高变更成功率，减少故障，等等）并提高组织的有效性（比如，将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中）。

产品快速推向市场：

2007年，在IT流程协会，在评测了超过1500个IT组织结构之后，我们得出结论：相比较于一般的组织，高效的IT组织的效率要高出5到7倍。变更要多出14倍，变更故障率只有前者的1/2，第一次修复率要高出4倍，而且一级事故时间要短10倍。 重复审计发现要少4倍，通过内部控制来检测漏洞方面要高出5倍左右，并且8倍于前者的项目到期日表现！

在我们的研究中，观察到的最高部署频率大约是每周1000次生产变更，变更成功率为99.5%，我们认为这真得很快……