最近我阅读了很多有关 DevOps 的文章，其中一些非常有趣，对于Devops的见解也是见仁见智。在效率和质量日益重要的今天，Devops已成为炙手可热的话题，由于目前业内对于Devops的理解众说纷纭，且Devops还是一个比较抽象的概念体系。因此想做一个系列，对于DevOps整个体系做一个详细的分析。
本篇会从最简单的Devops的理论基础开始带领大家一起走进Devops的世界。
谁应该关心Devops : 如果你的工作与构建软件系统有关，并且你所在的组织有意增加产品质量和缩短新功能推向市场的时间，那么，您就应该要关注Devops。
一.什么是Devops
DevOps，字面理解是Develop+Operation， 以及他们之前千丝万缕的联系。
目前对于Devops的定义，主流有4中观念：
1. DevOps 是一种角色 ： 当Devops成为一种主流，很多人会倾向去找做"Devops"的人,并希望能提升自己组织的Devops能力，因此设置了一些称之为"Devops工程师"的岗位和角色，主要有如下几种，但是很多都不是一个完善的定义：
• 作为Dev的Ops(会开发技能的运维工程师) ：忽视了开发和运维的专业性和差异性
• 作为Ops的Dev(会运维技能的开发工程师) : (同上)
• 基础设施开发工程师：基础设施开发者(InfrastructureDeveloper)或者云计算工程师(CloudEngineer)
• 全栈工程师：DevOps 是一个团队属性，而不是一个人属性，不能保证整个组织内部全是全栈工程师，而且能处理所有事情。
2. DevOps 是一组技术/实践：提到Devops，我们不可以避免的会提到工具的使用，Jenkins，GitHub，Sonar....等等， 当然，好的工具选择以及组织结构可以促进工程师用更有效率，更优雅的方式解决问题。但是，仅仅是简单的工具组合，可能适得其反。如果你不能有直观的理解，可以想象下周星驰电影里"要你命3000"。下面列一些Devops高频搜索的话题：
• 高频部署: DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值，甚至是安全措施。换句话说，DevOps 不是一种对质量的平衡和妥协，它是一种全局改进。全局的改进就意味着以价值为最高原则所度量的相关指标是不能有所下降的。
• 持续交付: DevOps 的核心实践之一，因为如果你没有实践持续交付。那么根本不能称之为DevOps。
• 云计算/虚拟化技术：共有云的高可用架构设计以及其天然的IaaS/PaaS/SaaS层服务优势，为Devops提供了强力的支撑。
• 基础设施即代码(AWS CloudFormation) : 基础设施即代码除了工具以外，更是一种Dev 和 Ops 之间相互沟通的媒介，能够让开发人员和运维人员相互理解。所以，基础设施即代码毫无疑问的是DevOps 的核心实践之一。
• Docker : 更简单的解决了基础设施即代码和虚拟化在实践中的问题，进一步提升了自动化能力以提升效率，并且对开发人员和运维人员都十分友好。
• 自动化运维: 虽然 DevOps 里的一个重要特征是“自动化”，但拥有自动化运维，并不代表你就正在实践DevOps，很可能你仅仅提升了运维部门的效率，但并没有从全局的角度提升开发和运维之间的效率和端到端价值的流动。因此，仅仅有自动化运维，还不足以称之为DevOps.
3. DevOps 是一种工作方式:比较贴近 DevOps 的目标的定义，但是，片面的理解和机械的模仿都会给组织带来不必要的资源浪费或者损失，DevOps 的工作方式，有以下四个常见的理解：
• 用Dev的方法做Ops的事：Develop占主导地位，Operation仍然是一个鸡肋位置
• 换了名字的Ops团队：Operation占主导地位，出了问题全部抛给运维团队
• 一个有Ops的Dev团队：Ops和Dev组成一个团队，但是如果Ops和Dev依旧各自为政，效率反而会大打折扣
• 一个Dev和Ops合作的团队：
这就是 DevOps 所要达到的目标，它不是一个人的属性，而是一个团队的属性。它让利益相关方坐在一起解决问题，而不是相互甩锅。然而，由于"合作"的定义很简单，也很空泛，导致"合作"难以落地。DevOps 合作方式：
• 共同进行架构设计、共同进行技术决策
• 持续交付流水线的建立
• 共同Pair 和 Review代码和环境的配置
• 共同参与回顾会议
• 通过定期的内部Session增加相互的理解
• 共同处理运维的问题
从项目管理角度来说，就是Dev和Ops必须把彼此作为项目中的重要干系人，进行任何的设计以及决策都要进行沟通以及分享。
4. DevOps 是一种组织文化
文化包括组织过程资产和事业环境因素，devops文化可能会跟目前您的组织文化有不一样，但 却是一种健康积极的因素：
• 相互信任
• 有效沟通
• 共同学习
• 分享/共担
• 不要指责
总 结 ：总的来说，Devops 是一套实践方法， 是一种工作方式，是一套组织文化，在保证高质量的前提下，缩短系统变更从提交到部署至生产环境的时间，以及在此过程中形成的良好的组织结构，沟通方式以及责任分担模型 。
二.DevOps生命周期
了解了Devops的概念，我们从实践方法的角度一起来看下其生命周期：
Devops能力环
1.Plan : 需求阶段，无论该需求来自客户的新需求还是BUG修改，这是触发整个Devops流程的起点，因此，作为Devops团队，开发团队需要把运维团队作为首要干系人，在进行开发之前获取他们的意见，比如运维人员可能会对日志文件的类型和结构提出建议。
2. build：开发/构建阶段，该阶段需要开发人员开发和运维团队也要保持密切的沟通，对于开发进度，单元测试的执行等，构建工具的使用，持续集成等运维人员也需要有所了解
3. Test：测试阶段，测试方案的规划，使用什么测试工具，是否使用自动化测试等（有一种新的Taas服务，将测试作为一种基础服务提出），都需要跟开发和运维沟通。
4. Release : 该阶段主要是对新版本的上线做的一系列准备，例如release之前需要对该版本支持的平台版本进行确认，测试结果进行确认，安全检查等报告进行核实，确保上线之前最后一套手续的完整性
5. Deploy ： 部署阶段，部署工具的使用，部署方案的制定（A/B部署，金丝雀部署等），以及回滚方案的确认，确保在服务不受影响的情况下，顺利将新版本发布。
6. Operation / Monitor: 运维阶段，对于已经上线的服务做一系列的性能监控（CPU , Memory等），日志分析，执行系统及软件的例行审计，执行备份，对操作系统的更新补丁升级，优化系统性能等，并及时发现监控过程中的问题，以及搜集来自于客户的问题清单，并将此作为下次版本更新的需求。
总 结： Devops生命周期是一个环形结构，它不会以项目上线为终止，而是不断会搜集来自于客户的需求，以对整个软件服务做不断的更新以及优化，这种结构就要求Devops整个流程的高效性。
三. 一个使用DevOps的案例：
IMVU是一家娱乐社交公司，他的产品允许以一种3D阿凡达式的体验互相连接起来，IMVU使用了持续集成（CI）：
1.开发人员尽早并且经常提交
2.提交完成后会触发测试套件的执行
3.IMVU有上千个测试文件，为了保持性能，这些测试文件分布在30多台机器上，所有case执行完需要9分钟
4.通过了所有测试之后，会自动实施部署，需要6分钟
5.代码移动到集群中数百台机器中，会使用金丝雀部署方案，测试性能
6.取样金丝雀结果，如果回归数量很多，则会进行回滚操作，否则集群中其他机器就会启用最新版本。
这个case主要说明了目前主流的DevOps 的技术/实践，下一章将会详细从该角度讲解当前DevOps生命周期中各个阶段使用的热门技术/工具。
曾经有人跟我很自豪的聊他们的devops系统，他们的Devops系统每天会发布500多次新版本。我问他，真的有那么多新需求要开发？有没有分析下这500多次的发布有多少是因为自动化测试不通过而产生的代码修改，或者甚至连最基本的静态代码检查都没有通过？
因此，运维一套完善的Devops系统，并不能成为可以忽略质量的理由，毕竟，质量，才是一个产品的一切~
