devops入门实战手册

devops入门实战手册内容摘要：

程的，那么为什么叫它 “DevOps”呢。 在我看来，早期 DevOps 的一个不足之处是没有直接地明确 DevOps 问题的真实范围，即它的问题域到底有多大。 经过一年的观察和思考，事实证明，我们正在解决的是对所有企业来说最大的问题之一： 如何面 对市场压力做出尽可能迅速的反应从而实现业务目标。 可惜的是， DevOps 必须从某个地方开始，于是我们碰到了一个几乎非常普遍的问题：开发者文化与运维文化之间存在的冲突和脱节。 尽管每个企业 的组织结构图各不相同，但是为了有个共同的讨论点，我们能够非常容易的将其划分为开发阵营与运维阵营（当然，现实世界远比这复杂和无趣）。 如上图所示，在开发和运维之间存在着一面混乱之墙，在这种情况下，大部分早期DevOps 的注意力都放在在改善 部署活动 上。 因为部署活动构成了整个 IT 组织的大部分工作，所以从部署开始改善，这是一个合理而自然的选择。 也许 Patrick 应该将他的第一次活动称为 “业务人员开发人员质量保障人员安全人员运维人员云服务用户日 ”或者 “比敏捷更牛叉日 ”又或者其他的什么东西，但是我强烈怀疑有人会认为其炫耀，所以低调的结果就是 DevOps 叫了 DevOps。 DevOps的特征 DevOps是处于 软件 产品开 发 和 运营 之间的 ，它关注于如何开发对基础设施友好的软件，而这些基础设施正是商业软件赖以生存的环境。 有时， DevOps 也指代开发基础设施软件以及软件部署。 DevOps 有如下的特征： 1) 编写复杂应用的能力， 而不仅仅是简单的脚本 显而易见的必要条件 2) 关注稳定性和无故障时间 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 稳定性和无故障时间永远对 DevOps们充满吸引力 3) 额外关注状态间的迁移 在开发领域，我发现人们很少跳出功能点本身考虑软件。 一个系统如何从它当前的状态迁移到未来我们所希望达到的状态。 这一点很少被纳入考虑， DevOps运动对这个容易出错的领域格外关注。 4) 关于营业收入的不同视角 开发人员通常工作于增加或者保持营业收入，而 DevOps常常工作在那些可以避免营业收入减少的事情上，这很象体育中进攻与防守的概念，关键点在于 “平衡 ” 5) 我们是自己软件的用户 这是一个非常重要的区分，与开发人员创造别人使用（内部客户，终端客户，网站访问者）的软件不同， DevOps更关注内部需求，比如，你当然可以草草的写下错误日志，但为此付出代价，花费大量时间查找的人将是你自己，而不是别人。 6) 架构师、开发者、测试人员、产品经理、项目经理五位一体 
 我的个人经验是，在 DevOps团队中， 个人／团队更有舍我其谁的气质，指定优先级，找出依赖，对意料之外的事情做出响应，管理资源，所有一切都被同一个团队中的不同个体完成。 7) 对意外更为关注 8) 工作于产品环境的 QA 一些 DevOps任务无法在小规模的测试环境中被充分测试。 缺乏大规模的集群，缺少独特的硬件，缺乏足够的用户数，这一切都会决定测试是否充分，结果是否可信。 被划分为不同阶段的部署以及其它技术常被用于减少彻底不工作的风险，但真相是，我常常发现我不得不在产品环境下运行测试以得到可信的结果。 9) 先手动，再自动 在我的经验里，一个 DevOps 任务常常是首先 手工完成，在稍后自动化，而在开发人员的世界里，写程序之前很少还存在一个手工过程。 10) 分布或者超级分布式环境 关于 DevOps的澄清 现在某些系统管理员正在试图把自己的岗位名称改为 “DevOps”。 但是， DevOps 不应该是一个单一的位置或职称。 把 DevOps 变成一个新职位名称或特定角色是一件非常危险的事情。 例如这会导致以下错误端点：你是一个 DBA。 或者是一个安全专家。 那么不用担心 DevOps，因为那是 DevOps 团队的问题。 设想一下，你不会说 “我需要招聘一个 Agile”或 “我需要招聘一个 Scrum”或 “我需 要招聘一个 ITIL”，而只是会说需要招聘了解这些概念或方法的开发人员、项目经理、测试人员或系统管理员。 DevOps 也是同样道理。 2 为 什么 要引入 DevOps。 当软件行业进入互联网时代，市场对软件产品和服务的交付提出了更高的要求：不仅要快速实现需求，而且要快速发布上线，并且必须保证业务可靠、高效运行。 为了满足这些要求， IT组织需要强有力的流程、技术和人员作为保障 ，而 人们 也 越来越意识到传统意义上的 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此 DevOps应运而生。 ThoughtWorks 很早就认识 到发布与运营对于成功交付的重要性。 我们的创始人 Roy Singham 在《走完业务软件的 “最后一公里 ”》一文中指出： 所谓 [软件开发的 ]“最后一公里 ”，是指软件满足了功能需求之后，尚未投入实际运行并创造业务价值的阶段。 软件开发者 ── 尤其是面对交付压力的软件开发者 ── 常常对 “最后一公里 ”视而不见。 但它确实正在成为业务软件交付中最大的压力点。 混乱之墙 正如李 汤普森（ Lee Thompson）和安德鲁 谢福尔（ Andrew Shafer）所言， 在开发和运维之间存在一面 “混乱之墙 ”。 相互冲突的 动机 、 流程 和 工具 导致 了这面 “墙 ”的存在。 角色认知不同  以开发为中心的人 通常认为， 变化会带来回报。 企业依靠他们来应对不断变化的需求。 因此他们被鼓励尽可能进行变革。  而运维人员则往往视变化为敌人。 企业依靠他们维持正常业务运维和实施让企业赚钱的服务。 由于变化会影响稳定性和可靠性，运维业务有理由对它说不。 我们已经多次听到过如下统计数字：在所有宕机事件中有 80%情况是源于自杀式的改变。 开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。 他们都认为自己的做法是正确的。 的确，孤立的来看他们都是正确的。 更糟糕的是， 开发和运维团队通常处于公司组织架构的不同部分 ，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 所用工具差异 让混乱之墙更坚固的 还包括 开发和运维工具之间的错位。 看一下开发者要求和日常使用的常见工具，再看一下系统管理员，你会发现两者存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然；而且两部分工具之间也不存在重要的集成。 即使在某些工具类型上有一些重叠之处，使用方式也完全不同。 当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在则将变得更加 明显。 有人将其称为一个 “版本发布（ Release） ”，有人则称其为一次 “部署（ deployment） ”，但有一件事情是公认的，问题可能会随之而来。 下图虽然是一个抽象化场景，但是如果你经历过这一过程，一定会感觉到它的真实性。 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 开发人员把一个软件版本 “扔 ”给墙对面的运维人员。 后者拿到该版本产品后开始准备将其部署。 运维人员 手动修改由开发者提供的部署脚本或创建自己的脚本。 他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。 最完美的情况是，他们重复在此前环境中已完成的工作； 而糟糕的情况是，他们将引入或发现新的漏洞。 运维人员然后开始进行他们自认为正确的部署过程。 由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。 当然，期间如果发生一个问题，开发人员会被要求来帮助进行排障。 运维人员会说开发团队给的产品存在问题。 而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过 程中做错了什么。 由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。 没有一个可靠的方式来把环境回滚到此前已知的正常状态。 本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。 部署阶段已经非常明显的需要 DevOps理念来解决问题，但需要 DevOps的绝不仅 仅是这一阶段。 正如约翰 阿尔斯帕瓦（ John Allspaw）所指出的那样， 开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 企业 的需求分析 企业的 需求 1. 快速响应 传统观念中规模庞大、发布周期长达数月乃至数年的软件产品研发方式正在发生变化。 在 “快鱼吃慢鱼 ”的互联网时代，上市时间（ Time To Market）成为衡量软件组织能力的重要因素：能快速接纳需求、快速完成开发、快速上线投入使用的软件产品，才能有效占领市场、吸引用户。 在以迭代式开发为特征的敏捷开发方法和以 Ruby on Rails 为代表的一批高效开发工具帮助下，很多软件组织在实现功能性需求方面的能力得到了显著提升。 然而从业务负责人的角度来说，仅仅提升开发阶段的效率还不足以实现端到端的快速响应。 很多软件组织虽然以迭代方式进行开发，但发布和部署仍然按照从前的节奏，每隔几个月才进行一次。 这时从客户与最终用户的视角看来，这些软件组织的交付仍然是以瀑布方式进行：客户与最终用户并没有直接感知到开发能力提升所带来的利益（如图 1）。 不能有效缩短部署上线的周期，就无法真正实现快速响应业 务需求、快速实现业务价值。 如何缩短发布和运维工作的周期，已经成为困扰很多软件组织领导者的问题。 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 图 1：迭代式开发 +瀑布式发布 2. 质量 大型软件组织通常都很重视产品质量，并在开发 /测试阶段投入大量成本与精力进行 质量保障活动。 但软件产品的质量问题不仅在开发阶段引入，靠传统意义上的测试工作也不能完全发现。 有相当比例的质量问题是在开发 /测试阶段之后引入或发现的。 造成这一现象的原因有：  开发人员对生产环境缺乏了解，在代码中引入了只有在生产环境才会暴露的缺陷。  开发人员对非功能性需求缺乏关注，并且没有相应验证环境，导致非功能性缺陷。  生产环境和测试环境缺乏有效管理，因为环境差异引入缺陷。  部署和维护工作缺乏自动化，在发布过程中手工操作引入缺陷。  缺乏针对生产环境的回归测试，导致缺陷不能及时被发现。 通过引入自动化测试、测试 驱动开发、持续集成等敏捷实践，开发 /测试阶段的质量保障活动能够得到有效改善。 然而对于客户和最终用户来说，不论哪个环节引入的缺陷都同样会给业务造成损失。 如何在部署上线的紧迫压力下保证质量，这也是众多软件组织领导者关注的一个问题。 3. 敏捷拉通的尝试 一些软件组织意识到这些问题的存在，并希望以敏捷开发方法为出发点，将下游的发布、部署、运维等工作环节拉通，从而提升整体响应能力。 但由于软件开发与运营之间存在一些固有的差异，这样的拉通活动往往困难重重：  开发团队与运营团队的关注点不同。 开发团队重视以功能性需求实现业务价值 ；运营团队重视以非功能性需求（稳定性、性能、安全性等）实现业务价值。  开发团队与运营团队的技能结构不同。 开发人员通常缺乏服务器管理的技能，运营人员通常缺乏软件编程的技能。  开发团队与运营团队日常使用的工具不同。 针对开发阶段引入的配置管理、 IDE、测试工具等很少为运营团队使用。  开发团队与运营团队日常工作的环境不同。 开发人员通常在公司内的桌面电脑上工作，运营人员经常在客户现场、在服务器上工作。  开发团队与运营团队通常属于不同的部门。 由于存在这些固有的差异，单纯从开发团队的角度出发、将敏捷软件开发的实践推广到运营团队，很难有效帮助运营团队改善。 需要从运营维护工作本身的特点出发，引入符合客观情况的流程、技术和工具，才能有效改善运营维护工作的质量和效率。 北京宽连十方数字技术有限公司 公开 内部公开 √ 机密 绝密 对策 针对现代大型软件组织在软件发布、运营与维护过程中面临的种种挑战， ThoughtWorks 建议在软件组织中建设 DevOps[3]能力， 从而提升整个组织的 IT 融合程度，改善软件交付 “最后一公里 ”的质量和效率，为实现业务敏捷打好基础。 DevOps 是一组流程、技术与工具的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。 “DevOps”这个名称即是指开发（ dev）与运营（ op）的无缝融合。 具备DevOps 能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维，使其能够与开发过程的创新保持同步，从而使得敏捷开发的优势在组织层面上得到展现。 1. 精益运维 传统的软件运营人员通常倾向于尽量避免修改功能，从而降低满足非功能性需求的风险。 但如果拒绝了小的修改，而给定时间段内需要修改的总量不变，那么每次变更的规模就会变大，从而增加每次发布的风险（因为变更涉及的范围更大）。 DevOps 的指导思想是 “精益运维 ”。 精益生产的很多原则，例如缩短交付周期、消除浪费。