想要落地DevOps却不知道如何入手？本篇文章将带你深入学习关于DevOps的关键概念及最佳实践。

　　DevOps的起源

　　一般认为，DevOps的出现源于两个因素：敏捷软件方法的广泛采用以及IT基础设施及代码的管理方式。

　　我们先看敏捷软件开发方法。20世纪末，主流软件开发方法是所谓的瀑布模型，需要花费大量时间，适用于对快速产品交付需求不大的大型信息系统，这个模型能够确保产品的高质量和精细的成本控制。

　　20世纪90年代，随着互联网和Web技术的发展，瀑布模型的消极作用开始显现：如何满足不断变化的客户需求的同时，还要按时交付同时不降低产品质量，就变得极为困难。

　　因此，IT管理方法也需要随之变化，逐渐从聚焦IT系统逐渐转变为聚焦IT服务的管理模式。

　　从2000年开始，这些涌现出来的管理实践，被先行者工程采纳之后，成为所谓的最佳实践，有些最佳实践进一步被业界广泛接受，甚至成为标准。

　　我们以IT服务为例，20世纪80年代，这样的想法开始出现：信息技术以服务的形式提供价值，以流程的形式组织IT活动。随后ITIL（IT基础设施库）等被阐述出来，使得这些实践进入最佳实践之列，在2002年成为IT服务管理的首个标准。

　　如今，新涌现出来的实践，被打上DevOps（开发+运维）的标签。实际上，DevOps的内涵，已经大大超出了原始含义。那么究竟什么是DevOps呢？

　　何为DevOps？

　　随着与客户交互的新方法的出现，以及敏捷开发技术的充分应用，业界迫切需要一种新的IT管理方法。而以虚拟化和云计算技术为支撑的基础设施即代码的出现，为IT管理新方法的出现提供了机遇，基于敏捷软件开发和精益生产演进的IT管理新方法DevOps应运而生。

　　DevOps是一种敏捷软件开发和精益制造想法的演变，应用到IT端到端的价值链，归功于文化、组织和技术的变革，使业务能够通过现代信息技术更多地达到预期，更快满足用户的业务需求，提升资源利用率。

　　首先，DevOps是对敏捷软件开发和精益实践两者的演变，是吸收，而不是取代。

　　其次，DevOps 被应用到IT端到端的价值链，其本质就是：DevOps所考虑的不仅仅是软件开发，而是整个价值链。整个价值链始于业务干系人的新想法，经过需求分析，设计，开发，测试和部署，到运维，最后到交付给客户。端到端价值链的方法有助于从宏观上整体地分析，识别和消除瓶颈。

　　为什么要采用DevOps？

　　首先，企业落地DevOps是提升产能和效率的必然选择，可以大幅提升新产品或新应用的上市时间。

　　传统企业新产品上市涉及到相当大的时间跨度，对于响应的IT部门，这个时间可能包括以下环节：

　　针对一种或若干种业务想法构建和起草方案，以及业务论证；

　　评估和选择一个业务想法进行实施；

　　规划实施所需的行动，获得资金；

　　员工和业务流程准备；

　　同时进行需求规范化，原型开发，初始测试，全功能IT系统开发，全面测试，发布和部署；

　　同时进行营销活动，市场准备，销售渠道和工具的准备；

　　新产品或服务的推出。

　　上述流程需要花费几年时间，然而业务部门希望缩短到数月。拥抱DevOps的理由是显而易见的。

　　创造数字化产品的充满活力的公司，习惯于快速行动。相对于严谨，详细计划，他们更推崇可安全失败的实验。这时，流程可能是这样的：

　　建立一个假设，开发验证方法；

　　假设的实际实现；

　　结果评估，A / B测试，与目标的比较；

　　根据分析进行调整，返回第一步或第二步。

　　很容易看到这是一个循环，预期时长是几周。这就是小步快跑的策略。这样快速的步骤是必须的，因为DevOps的本质就是持续的探寻。最终状态是不可知的，指定长期的计划没有意义。

　　为了尽可能缩短上市时间，DevOps提供了多种技术：

　　减少批量大小；

　　减少交接次数；

　　持续识别和消除损失；

　　自给自足的团队，传统IT部门为成本优化，DevOps为速度而优化；

　　自动化。

　　其次，减少技术债务也是企业拥抱DevOps的一大原因。技术债务是在团队成员选择一个非最优的方式解决问题以缩短开发时间时产生的。这是一个自然的过程，问题是累积的非最优方案导致了开发产出逐步恶化，必然导致产品质量下滑。

　　DevOps持续重构程序代码，重视在操作中取得的经验，鼓励持续识别并消除瓶颈，认为这些工作和技术创新同开发新产品功能同等重要。

　　同时，DevOps强烈建议使用“尽可能频繁面对问题”的实践，以便防止问题的“停滞”，即所有人都知道，但没有人能够处理的情况。

　　除此之外，采用DevOps可以帮助企业排除脆弱性。通常组织中最重要的和业务收益最相关的系统是最脆弱的。

　　DevOps能够以最激进的方式改变脆弱性，做到完全排除；

　　在DevOps中，代码和系统作为一个整体，在某个时刻是全功能的，如果接下来的变更破坏了性能，就要马上回滚并且让系统持续正确地工作；

　　DevOps的实践，有意地引入混乱和不稳定性到生产环境，目标IT系统必须以独立和快速的方式做出反应，探测到故障并恢复它们的正常运作，理想情况下最终用户是无感知的，当然数据也不会丢失。

　　DevOps常见误区

　　常见误区1：“DevOps不过是延续敏捷的想法”

　　企业在落地DevOps前，首先要明确一点，DevOps并不仅是敏捷的一部分。

　　尽管DevOps在很大程度上基于敏捷，然而扩展了敏捷开发到通用的敏捷IT交付，覆盖整个组织、整个流程以及完整的价值链；

　　获得DevOps的回报需要在公司中进行比以往敏捷所做的更为显著的文化变革；

　　DevOps的目标集合不仅限于加速交付：也需要减少技术债和排除脆弱性。

　　常见误区2：“工具能够给你极致的DevOps”

　　其次，我们需要意识到DevOps是一系列的组织文化和工作方式变革，而不仅仅是工具和自动化。

　　虽然个别的软件解决方案被广泛接受，但没有也不可能有一个完整的DevOps必备软件列表；

　　DevOps依赖确定的自动化工具的可用性和有效性。但是严格来讲，这些工具的最小集可以缩减到用于存储所有源代码的版本控制系统、IT基础设施配置数据、软件交付流水线自动化系统；

　　任何特定的DevOps实施都需要从企业自身组织情况出发，专业的商业化厂商可以帮助企业快速理清流程、加速实现组织变革。

　　常见误区3：“DevOps是一个全能士兵，能写代码，做测试，部署环境，并管理基础设施”

　　最后，我们需要了解DevOps并不是一个新职业。

　　DevOps是一种对IT部门的基本面有深远意义的变革，并不是通过招聘一些DevOps工程师或邀请DevOps专家就能达成的；

　　具有实施软件交付流水线的能力也不能保证成功；

　　短期来看，不大可能通过应用DevOps的实践就立即节省成本，但长远来看是在为更大的降本增效做准备，因而选择一个具有过硬技术实力和丰富实践经验的厂商十分重要。