云原生技术管理实践：业务引领的DevOps持续交付体系

导言：

云原生技术生态除了上述篇章已经讲述的微服务架构、容器技术（Docker）、容器编排技术（Kubernetes）、ServiceMesh技术（Istio） 等技术体系，还有一个很重要的管理实践—— DevOps，在进行深层次的微服务或云原生应用架构改造后，进行对应的DevOps整体研发流程改造，可实现业务流程的自动化。下面我们就来了解一下 DevOps 这种产品研发管理实践。

---

软件工程的发展

“如何在满足质量要求的前提下快速交付产品价值”是研发活动的最终目标，但在“质量”（做得正确）与“速度”（做得快速）之间长期存在着矛盾，如何有效地解决这个矛盾？其实也正是一部“软件工程”的发展史。

一、瀑布式开发

瀑布模型是一种重量级的软件开发过程，特点是需要大规模的作业和长周期交付。

二、精益运动

精益运动始于20世纪80年代，衍生自丰田生产系统（TPS）。TPS 包括价值流映射、看板和全面生产维护等。
精益思想的两个主要原则包括：

1. 坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；
2. 小批量任务的交付是缩短前置时间的一个关键因素。
   根据精益思想，也衍生出了软件开发中的7项原则，它们分别是：
   1、消除浪费；2、内建质量；3、创建知识；4、推迟决策；5、快速交付；6、对人尊重；7、整体优化。

三、敏捷开发

始于2001年的敏捷运动推出了轻量级的敏捷开发流程，它包含了精益思想，主要特点是：“一个小型的、自我激励的团队，在高度信任的工作模式下频繁地交付可工作的软件，每次只发布最低限度的功能集，然后听取客户的反馈，进行持续改善。”敏捷还和一系列的工具和实践相关，如 Scrum、每日站会等。

图 瀑布VS敏捷

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。大家发现从软件功能开发完成到正式上线这段过程中（即集成测试与上线部署阶段）依然存在着高度的不确定性和不可控性，造成了“最后一公里”的难以到达。于是研发和运维的衔接，成为了新的瓶颈。

四、持续交付运动

在持续构建、测试和集成等开发实践的基础上，发展出了持续交付的理念。《持续交付：发布可靠软件的系统方法》一书中，持续交付被描述为“一种‘持续’的能力，以‘部署流水线’的方式，将所有类型的变更安全且迅速地交给客户或发布上线，无论这些变更是新特性、配置变更，还是已修复的缺陷，或者新的测试实验。它的目标是高质量、低风险地快速发布软件价值”。

五、DevOps持续交付体系

综合以上研发模式和思想的发展，DevOps持续交付体系（以下简称DevOps）应运而生

• DevOps工作模式背后的原理是优化IT价值流，将业务需求转化成为向客户提供价值的能力和服务。
• DevOps是一种软件工程文化和实践，旨在统一整合软件开发、质量管理和软件运维。
• DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，兼顾高水平的生产能力（速度）和可靠性（质量），与业务目标保持一致。
• DevOps的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。

DevOps文化

一、DevOps的组织文化

1.交付“价值”

研发组织交付的不仅仅是可工作的软件，而是对企业的商业价值和对用户的需求价值。

交付“价值”往往是绝大多数研发组织所没有意识到，或者消极地认为主导全权在于产品组织，自身对此完全不可控。其实在产品准备期（产品探索），研发组织应该参与进“业务需求协作管理”环节，和产品人员一起对业务目标进行理解（商业价值/用户价值）；进行业务领域角色与流程识别（用户故事），探索解决方案；进行重大风险识别与验证（可行性）；最后与产品人员精炼并达成最小可行方案的共识；并最终对最小可行解决方案进行初步的工作量与时间评估，制订相应的交付计划；然后再进入研发主导的产品交付期。

在这个过程中，研发组织不再是被动的任务接受者，而是核心的价值参与者。比如对于“用户想要快速达到目的地”的需求，产品组织限于专业技术认知也许只知道提供给客户一匹跑得更快的马，但是研发组织却可能已经具备了造汽车的技术。

另外对于组织中的个体而言，当他们的个人目标和明确的价值紧密关联时，他们会更有激情和干劲，也会对工作的全貌有深刻的理解，知道各个不同部分是如何互动工作的，从而能主动改善工作。

2. 允许失败、获得反馈、持续改善

虽然无法保证每个方案、每个探索活动、每个流程动作都会获得成功。但是，我们可以获得反馈，从失败中学习，从而构建安全、可靠的工作体系。

在常见的管理文化中，对失败的恐惧常常笼罩在每个人身上，所以经常出现对责任的推脱、争执情况，让团队趋于保守；也造成了整个研发流程的黑盒化，造成了潜在的隐患。作为研发管理者需要让高层管理，同级协作组织意识到错误是事物演变过程中的自然连带部分，打造允许犯错，但不容忍罔顾教训、一错再错的文化.

3. 持续学习、彼此信任

我们要打造出一种教学相长的学习方式和高度信任的文化，并将对组织的改进和创新作为日常工作的一部分。

不论是通过传统的说教方式（如上课、培训），还是通过更具实验性或开放式的方法（例如会议、工作坊、指导），动态的学习文化都不仅能为每个人创造学习条件，还能创造教学的机会。我们可以投入专门的组织时间来促进这种教和学。

二、DevOps的研发文化

DevOps的研发文化也就是“持续交付”文化

1、目标：高质量、低风险地快速发布软件价值

部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。

图 部署流水线

2、核心模式

部署流水线

3、核心原则

• 质量内建；
  • 测试前置，在产品准备期的“业务需求协作管理”环节，便需要梳理出测试用例，确定产品交付标准以及指导代码编写；
  • 在部署流水线的整个环节进行自动化的单元测试、组件测试、集成测试等；
  • 测试也不纯粹或主要是测试人员的领域。交付团队的每个人都应该对产品的质量负责。
• 小批量开发；
• 尽可能将所有事情自动化，让计算机做重复的事情，而人来解决问题；
• 可度量，持续不断且不遗余力地改进；

对于工作过程、工作成果、组织能力而言……，可度量才可以知道差距和改进的方向

• 交付是所有人的责任。

理解IT价值流

图 IT价值流

如上图所示，IT产研团队主要参与的价值流分为产品准备期、产品交付期、产品运营期三大阶段。最终我们是想围绕IT价值流来进行DevOps的实践，利用kanban管理做到关键产研流程的可视化管理；利用部署流水线、运维自动化做到业务流程的自动化管理；利用各种工具平台采集到的流程点及各级组织指标数据来进行产研流程及组织能力可衡量的数字化管理，最终打造快速且高质量交付用户价值或商业价值的产研文化。

预告：后续文章会从IT价值流的产品准备期、产品交付期、产品运营期三大阶段分解来介绍我们的实践。

更多内容更新请关注本人Github：
https://github.com/yaocoder/Architect-CTO-growth