DevOps入门
开始使用DevOps所需了解的一切
07分钟阅读
什么是DevOps，为什么组织正在迁移到“DevOps运营模式”？
让我们先来看两个定义，均来自超大规模云供应商——Microsoft和Amazon：
“DevOps是人员、流程和技术的结合，旨在实现持续向客户交付价值。” - Microsoft.com
“DevOps是文化理念、实践和工具的结合，提升组织以高速交付应用和服务的能力：以比传统软件开发和基础设施管理流程更快的速度演进和改进产品。这种速度使组织能够更好地服务客户，并在市场中更有效地竞争。” - Amazon.com
这些定义在几个关键因素上达成一致，这对DevOps初学者来说非常重要——
- DevOps不仅仅是工具——它结合了人员、文化、流程、实践、工具和技术
- DevOps以客户为中心——致力于交付价值，更好地服务客户。
- DevOps关注缩短上市时间——以“高速”（或持续）交付价值，但重要的是，不牺牲应用/服务的稳定性、可用性或安全性。
为什么需要DevOps？
在深入探讨这三个领域之前，重要的是要问：“为什么选择DevOps”？
现有的开发与运维管理方式（“DevOps”中的“Dev”和“Ops”）存在哪些问题，促使需要改变？
这是在开始自己的DevOps转型之前也必须问自己的一个重要问题——你当前的交付模型未满足哪些客户需求？你能否衡量（量化）当前提供的与客户需求之间的差距？这将帮助你构建“DevOps的商业案例”，以获得实现DevOps转型目标所需的投资和资源。
简短的答案是，在许多组织中，开发和运维是各自为政的孤岛，目标不同，管理汇报线路不同，文化也不同。这导致工作——尤其是新应用发布——无法快速顺畅地从开发者的工作站通过发布管道进入生产环境。系统变更被视为高风险，可能引入缺陷，导致生产系统不稳定和可用性差。
这反过来导致客户不满和投诉。运维部门因稳定性和可用性受到激励，常与以尽快将新功能交付客户为目标的开发部门发生冲突。
随着许多开发团队采用敏捷和持续交付软件开发方法，强调更小、更频繁的发布，这种冲突和不协调加剧。运维部门没有“文化理念、实践和工具”来满足这一需求，至少不能在不危及生产系统稳定性的情况下满足。因此，DevOps应运而生，以满足速度与稳定性的双重需求。
你的DevOps模型应包含哪些内容？
既然DevOps不仅仅是工具，那么“DevOps模型”的关键要素是什么？
DevOps社区中一个流行的框架是CALMS模型，最早由Jez Humble在《DevOps手册》中讨论。表1 - CALMS模型细分了模型的五个要素。
向DevOps运营模型转变的挑战，尤其是对IT部门的技术人员来说，是我们擅长实施自动化和工具，但在培养强大文化、进行精益流程分析或有效衡量客户成果（而非仅监控系统指标）方面经验不足。这凸显了DevOps转型人员需要超越IT部门，推动变革。例如，人力资源部门应有在推动文化变革方面更有经验的人才。如果你的组织涉及制造业，可能在业务的其他部分拥有深厚的精益经验。向DevOps模型的转变不是IT部门可以孤立于组织其他部分单独完成的变革。
| CALMS模型 | |
文化 |
“DevOps文化”强调拥抱（而非抵制）变革，团队内及团队间协作以实现共同目标，信息自由流动，以及“心理安全”（“相信[群体/团队]环境对人际风险承担是安全的——提出想法、问题、担忧或错误会受到欢迎和重视”）。 |
自动化 |
自动化使任务能够快速且可重复地完成，避免人为错误。自动化能快速反馈任务成功或失败，支持决策。自动化可提升速度和成本效率，同时减少返工和错误。DevOps的自动化方法通常被描述为“代码化”方法——基础设施即代码、配置即代码等，使用如Terraform和Puppet等工具。 |
精益 |
“精益”是一种制造方法，专注于减少浪费和缺陷。精益关注整个价值流，提升效率和效能。忙碌不等于创造价值；精益帮助识别浪费资源的不必要工作。 |
测量 |
测量支持基于实证而非意见或“直觉”的更好决策。测量正确的指标为团队提供快速反馈，使其保持与客户价值目标一致。需注意，设定目标可能带来意想不到的文化后果，即“系统投机”。四个受Dr. Nicole Forsgren等人在《加速：精益软件与DevOps科学》中推崇的流行“DevOps指标”是部署频率（DF）、变更交付周期（LTTC）、平均恢复时间（MTTR）和变更失败率（CFR）。 |
共享 |
共同目标创造共同使命，共享经验和教训支持组织学习。仅有“共享文化”还不够——必须有机制赋能共享。这可能包括Slack或Zoom等协作工具、维基、团队活动如重大事件后的“无责备事后分析”、午餐学习培训，甚至日常活动如每日Scrum站会或促进团队成员间信息和知识共享的“结对编程”。 |
以客户为中心及利益相关者对齐
接下来，我们必须探讨作为DevOps转型一部分的“以客户为中心”意味着什么。
对于任何领导角色，尤其是大型分布式企业组织来说，“IT”与“业务”不“对齐”的抱怨可能很熟悉。
许多其他部门的[内部]客户或终端用户觉得IT“没有给他们想要或需要的东西”，无法满足其真实外部客户的需求。IT被视为组织内的独立孤岛，反应迟缓，目光短浅，过于专注于“做技术IT的事情”，而非交付客户价值。
虽然这对IT部门内部许多人来说可能显得不公平，但只需看看许多IT部门的结构就能看出这一点。大多数传统IT部门围绕技术孤岛组织，例如DBA在一个团队，网络与通信在另一个，服务器基础设施又在另一个。要实现端到端的客户成果，如新产品或服务的发布，需要跨越所有这些孤岛的协调，这既昂贵又耗时。
“产品对齐”是解决方案的一部分吗？
作为DevOps转型的一部分，许多组织正在转向“产品对齐”模型，即跨越传统IT孤岛的多学科团队，专注于交付满足特定客户需求的产品/服务。这些团队也称为“价值流对齐团队”，因为它们对齐于客户价值流，能够“端到端”交付新产品或产品功能，从最初的想法到开发阶段，再到生产中的部署和运维。这些团队“拥有”他们的产品，其成功指标应与真实客户指标如客户满意度、采用率、增长等保持一致。
加速变革
最后，当我们关注“上市时间”以及 DevOps 如何实现“速度与稳定性”时，
许多传统 IT 组织因糟糕的代码质量、不充分的测试以及易出错的手动发布流程导致灾难性的产品发布而受挫，害怕变革。因此，他们发布频率很低，有时甚至是按年度或季度周期发布。这些“轰炸式发布”反而更难管理和协调，增加了风险。如前所述，这也导致“业务部门”对 IT 反应迟缓且繁琐感到极度沮丧。反过来，这促使业务用户试图绕过 IT 部门……这就是令人畏惧的“影子 IT”——不受 IT 部门控制的 IT 产品和服务——这可能对企业及其客户构成安全和其他风险。
与此同时，用户对新功能的需求和对长期承诺但尚未发布功能的耐心日益减少。能够快速满足或预见客户需求，且对现有服务几乎无干扰、成本更低、质量更高的组织，能够从无法做到这些的竞争者那里赢得市场份额。DevOps 研究表明，拥抱 DevOps 的组织，特别是在前文讨论的四个 DevOps 指标上表现出色的组织，能够超越客户增长、市场份额和盈利能力的目标。
通过培养拥抱变革的文化并利用自动化等技术实践来提升质量、减少人为错误，并在出现问题时提供快速反馈，DevOps 使组织能够更频繁地发布更小的变更，且风险更低。许多组织每天向生产环境发布数百甚至数千个变更，变更失败率极低，变更交付周期极短。这令内部和外部客户都感到满意，提高了客户满意度，并开启了价值流每个环节性能提升的“良性循环”。
祝您 DevOps 之旅顺利！
关于作者
