26、DevOps相关概念及实践解析

DevOps相关概念及实践解析

1. DevOps的融合

DevOps正受益于一系列管理运动的融合，这些运动相互促进，有助于形成强大的联盟，改变组织开发和交付IT产品与服务的方式。以下按大致时间顺序介绍促成DevOps的各种元素：
- 精益运动（Lean Movement） ：始于20世纪80年代，试图将丰田生产系统规范化，推广了价值流映射、看板管理和全面生产维护等技术。精益的两大原则是：前置时间（将原材料转化为成品所需的时间）是质量、客户满意度和员工幸福感的最佳预测指标；小批量生产是实现短前置时间的最佳方式，理论上的理想状态是“单件流”。精益原则注重为客户创造价值，包括系统思考、明确目标、采用科学思维、创建拉动式生产、保证源头质量、谦逊领导和尊重每一个人。
- 敏捷运动（Agile Movement） ：2001年，17位软件开发领域的领军人物创建了《敏捷宣言》，旨在将轻量级方法（如动态系统开发方法和快速原型开发方法）发展成一场更广泛的运动，以对抗重量级软件开发流程（如瀑布式开发）和相关方法论（如统一软件开发过程）。其关键原则之一是“频繁交付可用软件，周期从几周至几个月不等，更倾向于较短的周期”，同时强调小而自驱的团队、高信任管理模式和小批量生产。敏捷还与Scrum、每日站会等工具和实践相关联。
- Velocity会议运动（Velocity Conference Movement） ：2007年，Steve Souders、John Allspaw和Jesse Robbins创办了Velocity会议，为IT运维和网络性能领域提供了交流平台。在2009年的Velocity会议上，John Allspaw和Paul Hammond发表了具有开创性的演讲“每天部署10次：Flickr的开发与运维合作”。
- 敏捷基础设施运动（Agile Infrastructure Movement） ：2008年，在多伦多敏捷会议上，Patrick Debois和Andrew Shafer举办了一场关于将敏捷原则应用于基础设施而非应用程序代码的专题会议，迅速吸引了包括John Willis在内的众多志同道合者。后来，Debois受Allspaw和Hammond演讲的启发，于2009年在比利时根特举办了第一届DevOpsDays活动，并创造了“DevOps”一词。
- 持续交付运动（Continuous Delivery Movement） ：基于持续构建、测试和集成的开发原则，Jez Humble和David Farley扩展了持续交付的概念，包括“部署流水线”，以确保代码和基础设施始终处于可部署状态，并将所有提交的代码部署到生产环境。这一理念于2006年在敏捷会议上首次提出，Tim Fitz也在一篇博客文章中独立提出了“持续部署”的概念。
- 丰田套路运动（Toyota Kata Movement） ：2009年，Mike Rother撰写了《丰田套路：培养改善、适应和卓越绩效的人才》，总结了他20年来对丰田生产系统因果机制的研究和实践经验。丰田套路描述了丰田在持续改进和适应方面取得成功背后的“无形管理流程和思维方式”，以及其他公司如何在组织中培养类似的流程和思维。他认为精益社区忽视了最重要的实践——改善套路，即让改进工作成为组织中每个人日常工作的一部分。丰田套路采用迭代、渐进和科学的方法解决问题，以实现组织的共同目标。
- 精益创业运动（Lean Startup Movement） ：2011年，Eric Ries撰写了《精益创业：当今创业者如何运用持续创新打造成功企业》，总结了他在硅谷初创公司IMVU的经验，结合了Steve Blank的《四步创业法》和持续部署技术。Eric Ries还定义了最小可行产品、构建 - 测量 - 学习循环等相关实践和术语。
- 精益用户体验运动（Lean UX Movement） ：2013年，Jeff Gothelf撰写了《精益用户体验：运用精益原则提升用户体验》，阐述了如何改善产品开发的“模糊前端”，并解释了产品负责人如何构建业务假设、进行实验并在投入时间和资源开发功能之前验证这些假设。通过引入精益用户体验，我们能够全面优化从业务假设到功能开发、测试、部署和服务交付的整个流程。
- 坚固计算运动（Rugged Computing Movement） ：2011年，Joshua Corman、David Rice和Jeff Williams认识到在产品生命周期后期保障应用程序和环境安全的徒劳，提出了“坚固计算”的理念，试图定义系统的稳定性、可扩展性、可用性、生存能力、可持续性、安全性、可支持性、可管理性和可防御性等非功能需求。由于DevOps可能导致高发布频率，给质量保证和信息安全带来巨大压力，坚固计算运动认为当前大多数信息安全项目对抗脆弱性的方法是无效的。

2. 约束理论与核心、长期冲突

约束理论知识体系广泛讨论了创建核心冲突云（通常称为“C3”）的方法。在20世纪80年代，制造业存在一个著名的核心、长期冲突：工厂经理既要保护销售又要降低成本。为了保护销售，销售管理部门倾向于增加库存以满足客户需求；为了降低成本，生产管理部门则希望减少库存，避免资金积压在未完成的产品上。通过采用精益原则，如减小批量大小、减少在制品和缩短并放大反馈循环，他们成功打破了这一冲突，显著提高了工厂生产率、产品质量和客户满意度。DevOps工作模式的原理与制造业的变革相同，能够优化IT价值流，将业务需求转化为为客户提供价值的能力和服务。

3. 向下螺旋的表格形式

以下表格展示了《凤凰项目》中描述的向下螺旋情况：
| IT运营视角 | 开发视角 |
| — | — |
| 脆弱的应用程序容易失败 | 脆弱的应用程序容易失败 |
| 需要很长时间才能找出问题所在 | 更多紧急、有时间要求的项目进入队列 |
| 检测控制由销售人员负责 | 更脆弱（安全性更低）的代码投入生产 |
| 恢复服务需要太多时间 | 更多版本的安装过程变得越来越混乱 |
| 太多救火和计划外工作 | 为了分摊部署成本，发布周期延长 |
| 紧急的安全返工和修复 | 更大规模的部署失败更难诊断 |
| 计划内项目工作无法完成 | 最资深和资源有限的IT运维人员没有足够时间修复底层流程问题 |
| 沮丧的客户流失 | 有助于业务获胜的工作积压越来越多 |
| 市场份额下降 | IT运维、开发和设计之间的紧张关系不断加剧 |
| 企业未达到华尔街的预期 | - |
| 企业对华尔街做出更大的承诺 | - |

4. 交接和队列的危险

当存在大量交接时，高队列时间的问题会更加严重，因为交接会产生队列。队列大小和等待时间与工作中心资源利用率的关系如下图所示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(资源利用率%):::process --> B(队列长度/等待时间):::process

从图中可以看出，当资源利用率超过80%时，等待时间会急剧增加。例如，一个“简单的30分钟变更”可能需要数周才能完成，因为特定工程师和工作中心在高利用率下往往会成为瓶颈。在《凤凰项目》中，Bill和他的团队意识到，一个“简单的30分钟任务”实际上需要7次交接（如服务器团队、网络团队、数据库团队、虚拟化团队和明星工程师Brent）。假设所有工作中心的利用率均为90%，每个工作中心的平均等待时间为9小时，那么总等待时间将达到63小时。这意味着，在总前置时间中，增值时间（有时称为处理时间）仅占0.16%，而99.8%的时间工作都在队列中等待处理。

5. 工业安全的误区

对复杂系统的数十年研究表明，一些安全对策基于以下误区：
| 误区 | 现实 |
| — | — |
| 人为错误是事故和事件的最大单一原因 | 人为错误是组织内部更深层次系统漏洞的结果 |
| 只要人们遵守规定的程序，系统就会安全 | 仅仅遵守程序并不能解释人们为何会做出那样的行为 |
| 通过设置屏障和保护措施可以提高安全性，保护层次越多，安全性越高 | 只有不断发现并解决系统漏洞，组织才能提高安全性 |
| 事故分析可以确定事故发生的根本原因（“真相”） | 事故分析往往无法准确找出根本原因 |
| 事故调查是基于事实对原因进行逻辑和理性的识别 | 事故调查往往受到多种因素的影响，难以做到完全客观 |
| 安全始终是最高优先级，永远不会被妥协 | 在实际情况中，安全可能会因为各种原因被妥协 |

6. 丰田安灯系统

很多人会问，如果丰田的安灯系统每天被拉动超过5000次，工作如何能够完成？实际上，并非每次拉动安灯都会导致整个装配线停止。当安灯被拉动时，负责该工作中心的团队领导有50秒的时间解决问题。如果在50秒内问题未得到解决，部分组装的车辆将越过地板上的一条线，装配线将停止。

7. 商用现货软件（COTS）

为了将复杂的商用现货软件（如SAP、IBM WebSphere、Oracle WebLogic）纳入版本控制，我们可能需要避免使用图形化的点击式供应商安装工具。具体操作步骤如下：
1. 了解供应商安装工具的工作原理。
2. 在干净的服务器镜像上进行安装，比较文件系统的差异，并将新增的文件纳入版本控制。
3. 将不随环境变化的文件放在一个位置（“基础安装”），将特定于环境的文件放在各自的目录（“测试”或“生产”）。
4. 将应用程序配置设置转换为可进行版本控制的形式，例如将存储在数据库中的配置转换为XML文件，反之亦然。

通过这些操作，软件安装操作将成为简单的版本控制操作，提高了可见性、可重复性和速度。

8. 事后分析会议（回顾会议）

事后分析会议的示例议程如下：
1. 开场声明 ：会议主持人或协调人强调这是一场无责的事后分析会议，不关注过去的事件，也不进行“本可以”或“本应该”的猜测。主持人可以宣读Retrospective.com网站上的“回顾会议首要原则”。
2. 责任分配提醒 ：协调人提醒与会者，任何对策都必须分配给具体的人，并且如果在会议结束时某项纠正措施不值得列为首要任务，那么它就不是真正的纠正措施，以避免会议产生一堆未实施的好主意。
3. 确定事件时间线 ：与会者就事件的完整时间线达成一致，包括问题的发现时间、发现人、发现方式（如自动监控、手动检测、客户通知）、服务恢复时间等。同时，将事件期间的所有外部沟通信息纳入时间线。
4. 记录事件和假设因果关系 ：尽管“时间线”可能让人联想到线性的问题解决步骤，但在复杂系统中，可能有许多事件导致了事故，并且采取了多种故障排除路径和行动。在这个环节，我们要记录所有事件和相关人员的观点，并尽可能建立因果假设。
5. 分析事件因素 ：团队列出导致事件的所有因素，包括人为和技术因素，并将它们分类（如设计决策、补救措施、问题发现）。团队可以使用头脑风暴和“无限追问法”深入分析重要因素，尊重所有观点，不允许否定他人提出的因素。事后分析协调人要确保有足够的时间进行这一环节，避免团队过早确定“根本原因”。
6. 确定纠正措施 ：与会者就会议后将列为首要任务的纠正措施达成一致。制定这份清单需要进行头脑风暴，选择能够预防问题发生或实现更快检测和恢复的最佳行动，也可以考虑其他改进系统的方法。我们的目标是确定实现预期结果的最小增量步骤，避免采用“大爆炸式”的变革，因为这种变革不仅实施时间长，还会延迟必要的改进。
7. 列出低优先级想法 ：我们会生成一份低优先级想法的清单，并为每个想法指定负责人。如果未来出现类似问题，这些想法可以作为制定对策的基础。
8. 确定事件指标 ：与会者就事件指标及其对组织的影响达成一致。例如，我们可以使用以下指标衡量事件：
- 事件严重程度 ：问题的严重程度，直接关系到对服务和客户的影响。
- 总停机时间 ：客户无法使用服务的时长。
- 检测时间 ：我们或系统发现问题所需的时间。
- 解决时间 ：从发现问题到恢复服务所需的时间。

Etsy的Bethany Macri指出，无责的事后分析并不意味着无人承担责任，而是要了解导致问题发生的环境和背景。通过消除指责，我们可以消除恐惧，从而获得真实的信息。

9. 猿猴军团（Simian Army）

2011年亚马逊美国东部地区发生故障后，Netflix进行了多次讨论，旨在设计能够自动应对故障的系统。这些讨论催生了“混沌猴子”（Chaos Monkey）服务。此后，混沌猴子发展成了一系列工具，内部称为“Netflix猿猴军团”，用于模拟越来越严重的故障场景：
- 混沌大猩猩（Chaos Gorilla） ：模拟整个亚马逊可用性区域的故障。
- 混沌金刚（Chaos Kong） ：模拟整个亚马逊区域（如北美或欧洲）的故障。

猿猴军团的其他成员还包括：
- 延迟猴子（Latency Monkey） ：在RESTful客户端 - 服务器通信层引入人为延迟或停机，模拟服务降级，确保依赖服务能够正确响应。
- 合规猴子（Conformity Monkey） ：查找并关闭不符合最佳实践的亚马逊实例（如不属于自动扩展组或服务目录中未列出升级工程师电子邮件地址的实例）。
- 医生猴子（Doctor Monkey） ：监控每个实例的健康检查，发现不健康的实例，并在所有者未能及时解决根本问题时主动关闭它们。
- 清洁猴子（Janitor Monkey） ：确保云环境没有杂乱和浪费，查找并处理未使用的资源。
- 安全猴子（Security Monkey） ：作为合规猴子的扩展，查找并终止存在安全违规或漏洞的实例（如配置不当的亚马逊安全组）。

10. 透明的正常运行时间

Lenny Rachitsky阐述了“透明的正常运行时间”的好处：
- 降低支持成本 ：用户能够自行识别系统范围内的问题，无需致电或发邮件给支持部门，从而减少猜测问题是本地还是全局问题的时间，更快地找到问题根源，减少向我们抱怨的情况。
- 提高沟通效率 ：在停机事件期间，我们可以利用互联网的广播特性与用户进行更有效的沟通，减少反复传达相同信息的时间，将更多时间用于解决问题。
- 节省用户时间 ：为用户提供一个在停机时可以直接访问的单一明显位置，节省他们在论坛、Twitter或博客上搜索信息的时间。
- 建立信任 ：信任是成功采用软件即服务（SaaS）的基石。客户将业务和生计托付给我们的服务或平台，他们需要在遇到问题时获得实时信息，以建立对我们服务的信心。因此，每个严肃的SaaS提供商都将提供公共健康仪表盘，这只是时间问题，因为用户会对此提出要求。

总之，DevOps及其相关的各种运动和实践为组织提供了一系列工具和方法，帮助优化IT价值流，提高产品质量和客户满意度，增强组织的竞争力和应变能力。通过理解和应用这些概念，我们能够更好地应对现代软件开发和运维中的挑战。

DevOps相关概念及实践解析

11. 各运动对DevOps的综合影响

上述这些不同的运动从多个维度共同塑造了DevOps。精益运动提供了基础的生产管理理念，强调价值创造和流程优化；敏捷运动则聚焦于软件开发的灵活性和快速响应；持续交付运动确保了代码和基础设施的可部署性和连贯性。这些运动相互交织，形成了DevOps独特的方法论和实践体系。
例如，精益创业运动中的最小可行产品和构建 - 测量 - 学习循环，与持续交付运动中的持续部署相结合，使得企业能够快速验证业务假设，及时调整产品方向。而敏捷基础设施运动将敏捷原则引入基础设施管理，为DevOps实现开发与运维的无缝协作提供了可能。

12. 应对挑战的策略总结

在实际应用DevOps的过程中，会面临诸多挑战，如交接和队列带来的高等待时间、工业安全误区等。针对这些问题，我们可以总结出以下应对策略：
- 优化流程 ：借鉴制造业采用精益原则打破核心冲突的经验，在IT领域减少批量大小、缩短反馈循环，优化IT价值流。
- 提高资源利用率意识 ：通过了解资源利用率与等待时间的关系，合理安排工作，避免资源过度紧张导致的瓶颈问题。
- 建立无责文化 ：在事后分析会议中推行无责文化，鼓励团队成员坦诚分享问题，找出问题的真正根源，而不是互相指责。
- 模拟故障场景 ：利用猿猴军团等工具模拟各种故障场景，提高系统的容错能力和恢复能力。

13. 未来发展趋势展望

随着技术的不断发展，DevOps也将不断演进。以下是一些可能的未来发展趋势：
- 智能化运维 ：借助人工智能和机器学习技术，实现自动化的故障检测、预测和修复，提高运维效率和准确性。
- 安全融入DevOps全流程 ：将安全理念贯穿于DevOps的各个环节，从代码开发到部署上线，确保系统的安全性。
- 跨组织协作加强 ：随着企业数字化转型的深入，不同部门、不同组织之间的协作将更加紧密，DevOps将促进这种跨组织的高效协作。
- 绿色DevOps ：关注可持续发展，优化资源使用，减少能源消耗，实现绿色IT。

14. 案例分析：Netflix的成功实践

Netflix作为DevOps的成功实践者，其猿猴军团的应用为我们提供了很好的案例。通过模拟各种故障场景，Netflix的系统能够在真实故障发生时快速恢复，保障了服务的高可用性。
例如，混沌猴子会随机终止运行中的实例，促使系统具备自动恢复和容错能力。这种主动式的故障模拟，使得Netflix的工程师能够在日常工作中不断优化系统，提高系统的稳定性和可靠性。同时，Netflix还通过透明的正常运行时间策略，及时向用户通报系统状态，增强了用户对服务的信任。

15. 实践建议：如何在企业中推行DevOps

如果企业希望推行DevOps，可以参考以下实践建议：
1. 文化变革 ：建立开放、协作、无责的文化氛围，鼓励开发、运维和其他部门之间的沟通与合作。
2. 培训与教育 ：为员工提供DevOps相关的培训，使其了解DevOps的理念、方法和工具。
3. 试点项目 ：选择合适的项目进行DevOps试点，积累经验，逐步推广到整个企业。
4. 工具集成 ：选择适合企业的DevOps工具，并进行有效的集成，实现自动化的开发、测试和部署流程。
5. 持续改进 ：定期进行回顾和总结，不断优化DevOps实践，提高企业的整体效率和竞争力。

16. 总结与结论

DevOps是多种管理运动融合的产物，它涵盖了从开发到运维的全流程，为企业提供了优化IT价值流、提高产品质量和客户满意度的有效途径。通过了解和应用DevOps相关的各种运动和实践，企业能够更好地应对现代软件开发和运维中的挑战，实现业务的快速发展。
同时，我们也应该认识到，DevOps的实施是一个持续的过程，需要不断地学习、实践和改进。在未来，随着技术的不断进步，DevOps将不断发展和完善，为企业带来更多的机遇和价值。

17. 相关概念对比

为了更好地理解DevOps及其相关运动，我们可以对一些相似的概念进行对比：
| 概念 | 重点 | 应用场景 |
| — | — | — |
| 精益运动 | 优化生产流程，减少浪费，提高效率 | 制造业、软件开发等多个领域 |
| 敏捷运动 | 快速响应变化，强调团队协作和客户反馈 | 软件开发项目 |
| 持续交付运动 | 确保代码和基础设施的可部署性，实现持续部署 | 软件开发和运维 |
| DevOps | 促进开发与运维的协作，优化IT价值流 | 整个IT产品的生命周期 |

通过对比可以看出，这些概念虽然有一定的相似性，但各自的重点和应用场景有所不同。DevOps整合了这些概念的优势，形成了一套全面的方法论和实践体系。

18. 实际应用中的注意事项

在实际应用DevOps的过程中，还需要注意以下事项：
- 避免盲目跟风 ：企业在引入DevOps时，应根据自身的业务需求和实际情况进行选择和调整，避免盲目跟风采用不适合的工具和方法。
- 关注人才培养 ：DevOps需要具备跨领域知识和技能的人才，企业应注重人才的培养和引进，建立一支高素质的DevOps团队。
- 平衡自动化与人工干预 ：虽然自动化是DevOps的重要特征之一，但在某些情况下，人工干预仍然是必要的。企业应合理平衡自动化和人工干预的比例，确保系统的稳定运行。
- 数据安全与隐私保护 ：随着数据的重要性日益凸显，在DevOps过程中，要特别关注数据的安全和隐私保护，采取有效的措施防止数据泄露和滥用。

19. 未来研究方向

未来，关于DevOps的研究可以关注以下几个方向：
- DevOps与新兴技术的融合 ：研究DevOps与人工智能、区块链、物联网等新兴技术的融合，探索新的应用场景和解决方案。
- DevOps的量化评估 ：建立科学的量化评估体系，评估DevOps的实施效果和价值，为企业提供更准确的决策依据。
- DevOps的社会影响 ：研究DevOps对社会、经济和环境的影响，推动DevOps的可持续发展。

20. 结语

DevOps已经成为现代企业提升竞争力的关键因素之一。通过深入理解和应用DevOps相关的各种运动和实践，企业能够优化业务流程，提高产品质量，增强客户满意度。同时，我们也应该关注DevOps的未来发展趋势，不断探索和创新，以适应不断变化的市场环境。希望本文能够为读者提供有价值的参考，帮助大家更好地理解和应用DevOps。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(DevOps):::process --> B(精益运动):::process
    A --> C(敏捷运动):::process
    A --> D(持续交付运动):::process
    B --> E(价值创造):::process
    C --> F(快速响应):::process
    D --> G(可部署性):::process

以上流程图展示了DevOps与精益运动、敏捷运动、持续交付运动之间的关系，以及这些运动各自的重点方向。通过这种综合的体系，DevOps能够为企业带来全面的提升。