软件开发经过多年的发展，从互联网史前，到移动互联网，再到 AI、大数据、云计算、物联网、区块链等的时代，其本质并没有发生根本性的改变，但组织形式却在持续演化，其中以敏捷和 DevOps 为特征的两个典型阶段，在今天得到了较大规模的应用。
本文将尝试探讨在 DevOps 时代，软件过程改进的必要性及其理念与方法方面的新挑战，并对 Cloud Native 云原生生态的 DevOps 略作展望，希望对读者有所启发。
01 重新审视软件过程改进
SPI 相关的概念比较多，我们在此先回顾最基础的两个相关概念：
软件过程（software process）： “软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
人们在开发和维护软件机器相关产品时所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。”
过程模型（process model）：“ 所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。
对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。 常见的模型包括瀑布模型、螺旋模型、增量模型、迭代模型、V 模型等。”
现实往往更加残酷，在绝大部分中小企业，软件开发过程相对粗放，并不严格遵循某种模型或范式，基本是 KPI 驱动和 BOSS 驱动。
与此同时大型企业尤其是如今的互联网巨头公司，对效率和质量的要求较高，所以在软件开发过程方面愿意投入，在每天/每周/每月的版本迭代过程中，组织层面会更加关注每一次迭代的效率和质量与上一次相比是否有保持或者提升（下降通常是不可接受的），此时 SPI 就该出场了，这是让迭代效率和质量持续提升的法宝！ 也许很多组织内已经在做这类工作，但并没有明确把它定义为 SPI。
一般大型管理咨询公司会更乐意提及 SPI，他们更加擅长帮助客户梳理和优化业务流程，给出改进建议或方案，并通过使用他们销售的产品来落地。
在互联网企业中，版本迭代的典型特点是周期较短，我们从 BAT 及京东、携程、美团、字节跳动等企业的工程效率相关团队发布的数据看到，大家通常会使用平均发布周期、发布成功率、日构建及发布次数等指标来观察和衡量软件开发与交付的效率和质量。
建立可观测的指标，是过程改进非常重要的一个步骤！ 只有建立核心指标，才能直观地看到改进活动的效果，举个例子： 某开发团队把版本控制工具从 SVN 要切换到 Git；实践中这项工作的实施通常不会进行充分评审，最多做一个开发者调查，因为大家潜意识里认为这是”行业趋势“，我们要跟着同行的步伐；
但是如果从问题的本质思考，即使是”行业趋势“，一个团队应该在什么时间点切换比较合适，切换后带来的具体收益是什么？
是否因为新工具/新方法的引入，短期内团队交付效率会有所下降，而长期会上升？ 这是非常典型的一个改进活动，我所服务过的雇主，有 3 个团队经历过 SVN 切换 Git，并没有一个团队从 SPI 的角度去评估过。但是如果建立了最基础的度量指标，即使没有评估，我们也可以从版本迭代和交付数据上看到变化。
02 DevOps 时代的软件过程改进
DevOps 理念在推广初期，受到不少人士的质疑甚至反对，比如有人担心运维工程师会丢掉自己的工作；后来的结果大家都看到了，非但运维工程师没有消失或减少，有些组织反而多了一种专职 DevOps 的角色，而原有的运维工程师其效率更高，单人可以维护的系统数量和复杂度都显著提升。可以说按照新技术应用周期，验证了这一事实：“新技术在短期内其价值通常被高估，而长期被低估”。
DevOps 从理念甚至组织文化层面为软件开发与交付带来了新的提升，开发从系统设计和实现阶段就考虑到对持续交付的支撑，与此同时运维也从系统设计和实现阶段就开始关注整体技术方案，让其面向持续交付来保证一定的可运维性。
因此可以说 DevOps 让软件系统的开发与交付环节更加紧密，这对过程改进来说是好消息；更紧密的协作，会让过程指标传递更加高效，开发与运维甚至 QA 等角色，能共用同一套衡量指标体系，用同一把尺子衡量各环节及过程整体的效率和质量。
所以，DevOps 时代，SPI 的必要性不言而喻，甚至 SPI 的效果和意义会更容易凸显，更容易通过指标体系观测到。
那么 DevOps 时代的 SPI 工作会有哪些新的挑战呢？理念方面，需要在组织层面持续加强对过程改进的认可度，越是紧密的协作，越是需要更灵活的过程度量方法，过程改进工作的价值也就越容易得到体现。常见的认识误区是，采用了 DevOps 就是引入了一个标准范式，无需过程改进；
相反，DevOps 对每一个过程的要求相对更高，能持续对瓶颈或薄弱过程进行改进，会让 DevOps 的价值更大。方法方面，除了常见的新方法导入、工具引入或替换，还有一个方面是，现有方法或工具自身的持续改进。
比如自动化测试，要求在 CI 环节全部自动化，甚至在 CD 环节可以进行预发布/线上环境的无损测试，更进一步需要在红绿发布/金丝雀发布过程中通过自动化测试来判断发布是否达到预期。再比如监控和告警，要求相关信息必须做到可视化，并让开发、运维、QA 在同一个 dashboard 里观测，这样可以提高沟通效率，减少术语和指标定义不一致带来的沟通成本；可以说，优秀的监控和告警体系，会让 DevOps 链条上的所有角色能及时感知系统各部分及整体的任何风吹草动。
##
03 从 Jenkins 发展轨迹窥视软件过程改进
Jenkins 在 CI 及 DevOps 生态扮演者非常重要的角色，可以说是软件交付史上的活化石！我们来回顾下 Jenkins 的发展轨迹：
Hudson 时代，更多的是希望把写完的代码能自动编译、测试，做一些基本代码的分析，最后输出合格的部署包。这些最基本的追求，还不是每个团队都有甚至能达成共识，更多团队依然是比较粗放的开发方式，稍好一些的会通过自动化脚本来实现类似目的。
在大约 2013 年之前，国内其实对于 Jenkins 的认知和应用依然只停留在“一个能自动构建项目的工具”层面上。当然也有不少团队会依赖 Jenkins 来进行部署，但主要针对把部署包 scp 到有限的物理机或虚拟机上然后执行部署 shell 脚本等场景，基本没有成品仓的概念，也没有 Docker 容器及镜像级别的打包部署。后来随着 Docker 和 K8S 的流行，以及 Jenkins 自身的快速进化，到 2016 年几乎是一夜之间所有招聘网站的相关职位 JD 里都增加了 Jenkins 技能要求。
因为比较早地使用 Jenkins，并且在社区内参与了一些翻译工作，2017 年我与 Jenkins 社区的 Maxwell 沟通后在深圳发起了国内首次 Jenkins Area Meetup，受到了广泛支持和热烈欢迎。
本来预期是办一个小型的 Meetup 活动而已，30 或 50 人的交流活动，结果办成了 100+人次的小型会议；实在没想到一个 Jenkins 怎么吸引了这么多人，会后我们还分析了一下报名及参与的人群特点，发现不只是开发人员很有兴趣，还有运维人员，配置管理人员，测试人员，甚至云计算和基础设施的人员。
后来业内其他社区很快在北京、上海等城市发起了 Jenkins Area Meetup，并在 2017 年底于上海，召开了国内第一次 Jenkins 中文用户大会，Jenkins 作者 KK 也从 2017 年开始频繁在国内的相关会议和活动上露面。
今天 Jenkins 中文社区也蓬勃发展，不但有了中文版的网站 https://jenkins.io/zh/，还有运营微信公众号 “Jenkins”。
作为 Jenkins 中文社区的一员，非常欢迎大家积极参与到社区活动中来，包括但不限于代码提交，测试用例提交，文档优化，文档翻译，Meetup 活动组织等。
至于后来 Jenkins 2.x 的出炉，以及 Pipeline 特性的持续增强，甚至到目前 Jenkins X 的发布和流行，让开发者们真正感受到了“一切皆可编程”的真理！ 我们发现不只是可使用的资源可编程，比如云计算的本质可以理解为
让各种基础设施可编程，而且过程也可编程，而且是超越了资源调度或任务编排的水准。
也许不远的将来，开发人员真的只要关注业务逻辑的实现即可，其他都交给可编程的自动化过程来完成，包括资源的获取、初始化、启用等；当然，这些自动化过程依然需要专门的开发人员来实现。
通过以上 Jenkins 的发展轨迹，特别是国内外社区的发展状况，我们可以明显地感受到，组织和个人对软件过程有着越来越高的要求，更加追求效率和质量，过程资源调度的可编程性和自动化程度日益提高。可以认为，是 Jenkins 把过程改进相关的工作串联了起来。
##
04 云原生生态的 DevOps 与软件过程改进展望
Cloud Native 生态目前已经进入快速发展阶段，参考新技术应用周期，笔者认为已经在”快速成长期“的尾巴上了，可能很快要进入”成熟期“了。
关于云原生的定义，可以参考https://jimmysong.io/kubernetes-handbook/cloud-native/cloud-native-definition.html
笔者的个人观点是：云原生是软件交付方式的突破性进化，而不仅仅是效率的提升。
云原生所需的能力和特征：
https://jimmysong.io/kubernetes-handbook/cloud-native/from-kubernetes-to-cloud-native.html
云原生时代大规模微服务的出现，让质量保证工作也面临新的挑战，目前比较火热的 CHAOS 混沌工程，是解决方案之一，可以通过随机给系统注入故障来验证系统整体的健壮性。
这无法通过常规的测试工作来解决，一方面系统间的关系变得更加复杂，几乎无法遍历所有路径；另一方面，不同微服务相对独立迭代，版本差别较大，只有线上拥有真实的系统演化过程信息，其他环境几乎无法模拟。
云原生时代 DevOps 的挑战将会更大，还体现在开发人员离线上系统更近，对线上系统的操作会更加频繁；资源和过程的可编程性让系统复杂度持续提升，大规模微服务已经不像之前的中小系统，运维人员可以全面掌握整个系统的拓扑，必须依赖可观测性工具，甚至只能了解复杂系统的某个部分。
微服务时代必备的调用链工具，在新的发展阶段，可能已经不是“链式”关系可以覆盖的了，可能是“网状”结构，虽然从系统设计角度我们追求更加优雅的拓扑结构。
此时的软件过程改进，已经超越了某个方法和工具的引入或替换，更需要具有良好可集成性的解决方案级别的服务导入，AIOps 就是典型案例。国内外大部分互联网企业的研发体系中，软件过程改进的相关工作通常归属在“工程效率”、“基础设施”等团队中；
理想的研发体系中，比如云原生技术栈的引入，可能来自业务需求的驱动，而实践中通常是基础设施提供方来直接驱动的，因为后者更加关注资源使用效率、系统可用性与成本，并在这几个方面对业务团队的技术方案进行评估，对业务系统建立考核指标。
所以此时要让软件过程改进工作顺利进行，必须进行大范围的效率、质量与成本意识培训和提升，然后给出适合组织文化的行之有效的举措，逐层实施，毕竟此时牵一发而动全身。
再次回到 Jenkins ，云原生时代的 Jenkins 进化为了 Jenkin X，依赖 Git & K8S 来完成云上的超级 Pipeline ，Jenkins X 还在快速进化，笔者相信它在 KK 的带领下依然是云原生时代的 CI/CD 领跑者！此时的软件过程改进依然可以极大程度地参考 Jenkins X ，任何效率和质量瓶颈都值得去做改进！
