DevOps 文字培训
什么是 DevOps？
DevOps 是开发、交付和运维软件的过程。这个说法看似简单，但不要低估真正理解 DevOps 的重要性。书架和互联网中充斥着各种定义，有的为自身利益服务，有的即便没有这种问题，也不完整且令人困惑。
某些受商业利益驱动的定义，把 DevOps 与特定的构建和交付工具或云基础设施平台紧紧绑在一起。这些工具和平台确实可能有助于借助 DevOps 实现 IT 和组织目标，但仅仅接入又一款工具（往往还不是你自己编写的，因而难以掌控），或把软件应用迁到云计算平台，就宣称自己和组织已经在用 DevOps 交付，未免令人发笑。
另一种稍好却仍有误导性的定义，把 DevOps 看成 IT 组织中工作和人员的交集，将软件开发人员、测试人员和生产运维工程师聚到一起。读到本书末尾，你会发现这种定义有多么空泛。
定义 DevOps 的最佳方式，是将它与迭代式敏捷软件开发和流程改进框架联系起来，例如 Scrum、精益、ITIL、IDEAL（启动、定义、建立、行动和学习）和六西格玛 DMAIC（定义、测量、分析、改进和控制）。
敏捷 Scrum、精益、ITIL、IDEAL 和六西格玛 DMAIC 都能有效支持 DevOps，但不应将 DevOps 视为这些方法与技术合并后的改进版。原因很简单：除了敏捷 Scrum，这些方法和框架都不是专为解决软件行业的问题、服务这个行业而提出的。
许多 DevOps 实践和原则源自精益运动，经过针对软件开发、交付和运维的调整、实验、验证和完善而成。此外，DevOps 还借鉴并改造了持续交付运动、Toyota Improvement Kata、约束理论、敏捷宣言和敏捷基础设施中的诸多技术与理念。
精益运动：
精益运动可概括为七项原则：
- 着眼整体，用系统思维为客户创造价值。
- 将质量融入流程，创造流动，以拉动代替推动。
- 尽快交付，缩短将原材料转化为成品的前置时间；在软件领域，就是缩短将想法转化为生产系统中可用功能和实际收益的时间。
- 促进学习，采用科学思维。
- 授权团队，谦逊地领导，尊重每一个人。
- 消除浪费，包括工具、系统，尤其是可能花在低效活动上的时间。
- 尽可能晚地作出决定，在需要时及时决策。
持续交付运动：
通过部署流水线实现持续交付。部署流水线有三项重要职责：提供可见性、反馈和持续部署。
- 可见性—— 让团队内外的成员都能看见交付系统的各个方面，包括构建、部署、测试和发布，借此促进团队协作，并让客户和利益相关方了解进展。
- 反馈—— 让你和团队成员在问题一发生时就知情，趁问题还没有进一步累积，迅速解决。
- 持续部署—— 通过完全自动化的流程，把任意版本的软件部署并发布到任意环境，包括测试环境和生产环境。
Toyota Improvement Kata：
将 Toyota Improvement Kata 用作例行方法，以富有创意、目标明确且有意义的方式，从现状过渡到新状态。它基于一个由四部分组成的模型：
- 考虑一个更长远的愿景或更好的方向……
- 了解当前状况。
- 然后确定下一个目标状态。
- 最后，通过持续迭代，努力向目标状态迈进。沿途找出需要克服的障碍，并解决它们。
其他改进方法往往先预测路径，再专注于实施。使用 Toyota Improvement Kata 时，你会在过程中不断学习，并在新发现的基础上推进。你和团队用它来边追求目标状态边学习，并根据所学内容作出调整。
约束理论：
包括你所在组织在内，任何交付软件的组织都面临 IT 与业务之间持续存在的冲突。迅速响应业务需求，同时确保生产环境稳定且可预测，是 IT 需要不断权衡的问题。生产发布不可能完全没有风险。在像你所在组织那样复杂的系统中，如果想确保生产发布风险较低，速度就难以足够快；如果想快速将代码发布到生产系统，也就难以确保发布风险较低。
以下做法可以帮助你处理这种冲突：
- 将 IT 组织划分成许多规模较小、自主、独立、能自行完成工作且高度协作的团队。你应开始将团队视为肩负使命、能够独立思考的单元。
- 缩小交给每支团队的工作批次，也就是减少在制工作量。
- 缩短前置时间，即把想法和需求转化为生产系统中可用功能和实际收益所需的时间。
- 建立更快速、可靠、持续的反馈循环，确保部署就绪。
敏捷宣言：
采用 DevOps 时，你遵循敏捷宣言确立的核心价值观：
- 相较于流程和工具，你更看重个体和互动。
- 相较于详尽的文档，你更看重可工作的软件。
- 相较于合同条款和谈判，你更看重客户协作。
- 相较于遵循计划，你更看重响应变化。
敏捷基础设施：
无论组织规模大小，我们都在采用混合云基础设施，将公有云、私有云和专用服务器结合起来，你所在的组织可能也不例外。这样既能获得托管设施的安全保障，也能享受公有云的灵活性和可扩展性。
敏捷基础设施有助于实施 DevOps，主要原因包括：
- 按使用量付费，定价透明且简单。
- 可以通过代码库快速预配和撤销测试环境及生产环境（IaC，基础设施即代码）。
- 架构更灵活。
- 可以轻松拓展到其他地区。
- 安全性可能更高。
- 无需审计和额外成本即可保持合规。
总结
本节说明了什么是 DevOps、什么不属于 DevOps，也介绍了 DevOps 源自哪些主要运动和原则。
值得留意的是，多年来许多敏捷从业者不幸把敏捷实践的定义当成一成不变的规则。不要以同样的方式套用僵化的 DevOps 定义，规定自己的组织、产品、服务，尤其是团队必须怎样使用 DevOps。敏捷与 DevOps 都没有放之四海而皆准的方案。
请始终记住，核心在于学习、实验和调整。DevOps 能为我们发挥许多积极作用，而我们最大的责任是找到真正适合自己的 DevOps 实践方式。Google、Amazon、Facebook、Netflix 和 Apple 等成功的 DevOps 组织都是这样做的。
