摘要： 文章内容主要来源于光环国际2022年第三届中国科创者大会徐磊老师的分享，原分享名称为"企业开发者平台建设思路，云原生技术如何赋能开发者"。简述当前软件工程中Devops平台还缺少一个软件调试环境环节，这个环境其实尤为重要，它使得落地性更好。
徐磊老师在过去20年只做了一件事情，就是软件工程方面咨询及工具落地。软件工程和软件开发还是有很大的区别。简单来说软件开发服务的对象是大众消费者、各行业应用场景，软件工程主要服务对象是各位开发者。
分享主旨主要分为以下四个部分：
一、软件工程的第一性原理
第一性原理这个词最近被说的比较多，它是来自马斯克的说法，因此这个词也火了，在这里也借用这个词来说明对于软件工程到底在解决什么的问题。
先给出答案，软件工程只解决一个问题：解决终态问题，即软件最终状态问题。这里将软件工程放在时间维度上去观看，去看这些年里软件工程的发展，如何去解决终态问题。
终态问题主要包含：底层硬件、虚拟化平台、操作系统、系统组件、应用服务器、其他中间件、应用代码配置项构成了这个软件环境堆栈管理。下图右侧也可以看见一些devops比较熟悉的说法，基础设施、即代码、云平台、Paas、k8s、容器化技术，可以看出每一个技术点在这个环境堆栈中解决的领域是有区别的。
从静态的角度来看，所有的软件系统都是由这个堆栈来构成。
具体的软件系统中，需要横向铺展，从左侧创立，然后有需求、开发、流水线、测试环境、服务用户的生产环境。在下图有几个黄色填充色的标签框，这里代表从不同的阶段进行状态转移的对象，从开发环境到测试环境再到生产环境。 比如开发人员打包好应用放到测试环境，由测试来验证其正确性，验证后再由运维人员将同样的版本放到生产环境。如果这一切都是依靠人来操作，可以认为目前你的软件工程还处于石器时代，非常原始的时代。在这种状态下，软件的状态能最终被确认吗？只有进入到最终的生产环境才会被确认下来，比如我们的终态确认是在最右侧。
我们怎么把终态向左移动，因为终态不被确认，在整个软件工程实践过程中质量、使用场景都是没有目标，不能知晓软件做成什么样子，如何去保证质量，这就变成一个悖论。至少在进入生产环境之前，明确告诉用户软件会为你形成什么样的特性，用户才会有一个预期，愿不愿意为这个软件特性买单，所以这个终态至少要前移到部署之前。最开始这个状态确认可以通过人工去确认，把它变成自动化以后，就可以终态向左移动，因为有人的参与就会出现各种各样的问题，因为人是会出现错误的。所以我们要用自动化系统去替代人的重复性操作，比如修改配置项、软件运行应用放到特点目录、配置目录权限等这些非常多细节操作，这些通过自动化方式解决掉。
通过自动方式部署到生产环境时，可以认为终态是在生产环境之前。在制品的情况下已经确认，制品包含应用程序本身、相关配置项及其他相关配置内容。如果做到这一步，可以认为软件工程来到了青铜时代。
对生产环境做自动化以后，对测试环境也因该被自动化，测试人员在确认一个版本是否满足应用需求时也需要一个目标来确认这件事情。意味着在进入测试环境之前，测试人员需要一个固定目标来确认测试用例是否编写正确，如果目标发生了变化，测试用例肯定是存在问题。终态可以左移到测试环境阶段，这里测试环境是一个泛指，你可以有多个测试环境、测试阶段，这些都是不影响。
这里将状态移动到测试阶段之前，开发阶段之后，可以帮助测试人员确认最终交付内容怎么去验证，可以认为软件工程来到了铁器时代。
从源码到测试环境中间还会有一个过程，开发人员交付的是源代码，大部分并不能直接运行，需要将配置文件和代码进行打包形成一个可交付制品。这个过程需要通过SRM（配置管理）从代码库中拿出某一个特定版本，进行编译打包形成制品，然后通过自动化部署到测试环境中及之后的生产环境。
如果从代码库中提取代码，到进入测试环境这个过程也自动化，编译打包自动化，不是开发人员从代码库中下载代码，在开发人员自己电脑上编译代码，再上传制品到测试环境。通过自动化CI/CD系统来完成这个工作，可以认为软件工程来到了蒸汽时代。
这里我们可能会产生疑问，都做到了CI/CD为什么还是蒸汽时代，再往后还可以做些什么？
分析刚才所有的事情都是针对整个环境堆栈最上面两层（源代码、配置项）做努力。其实这个领域在软件工程里称之为软件传统配置领域。传统配置领域极限就是把源代码及配置项标准化，并且把它的终态向左移动。其实也就是说当下所说的一起努力还远远没有达到确认终态的状态，因为从源代码往下应用运行时到服务器、中间件、操作系统、网络存储、硬件都没有标准化，这些内容是超出传统配置项管理能力，那么就需要回到底层去解决这个问题，比如目前的云计算。
用一个简单概念来定义云计算，云计算主要做了三件事情，把计算、存储、网络标准化，把计算、存储、网络软件化、可编排化。将以前只能靠硬件来实现的内容变成软件化以后，意味对这部分内容可以配置，所以出现了一个概念基础设施即代码（Infrastructure-as-Code，IaC）意味着使用代码来定义和管理基础设施。通过一个配置文件来定义需要多少台虚拟机，每台虚拟需要多少CPU、内存、存储、网络带宽、网卡等等内容，业界有很多此类软件的解决方案。
做到基础设施的软件化，可以认为软件工程来到了电气时代。
可以看见还有系统组件、应用服务器、应用运行时三项还是没有纳入到配置环境，那怎么解决它们的问题，这里就是容器所要解决的问题。比如 Docker 解决了操作系统之上到软件应用之下这层内容，应用本身也被纳入容器管理范围。在原有的配置本身也是可以覆盖，比如更换容器后就换了一种管理方式。但是无论如何有了云和容器以后，整个环境堆栈被配置管理起来。
所以这个阶段，云平台加上容器以后 IaC 就提升到可以完整管理环境堆栈，这也就是容器化技术在出现以后（2013年Docker开源项目）迅速火热，在全球的 IT 界掀起了完全容器化的浪潮。现在很多大企业说到建立云平台的时候，会说我们建立了一个企业级的云平台，其实说的就是容器化平台，但是云平台和我们定义的云平台是有差异的。
那么基于以上终态问题是否已解决，可以看见离终态确认中间还有一个，就是流水线。在流水线的环境里，它存在一个问题。比如流水线需要去编译代码、去测试代码、运行单元测试、静态代码检查等，所有工具的运行也需要自己的环境，流水线本身也需要环境堆栈管理。
在这两年（2016年）也出现了新的趋势，很多流水线产品从原有脚本化工具变成采用 IaC 实现方式体系化工具链，称之 PaC。可以看见通过 IaC 方式把终态推进到了配置管理线上，现在我们可以做到源代码上传后的阶段都标准化。
可以看见目前就只剩下一个环节，开发环境没有纳入到终态管理，有没有必要将开发环境乃入到终态管理，可以参考举例：在 Devops做的比较好的企业，做了完整的 IaC 体验，各个环节都可以通过配置文件动态生成出来。这个时候如果开发人员在自己源代码里面引入了新的开源组件，组件在原有的体系中是没有，这个改动会造成从流水线到环境全部需要重新编排，产生连锁效应。
目前很多企业应对措施是，给到一个模板，只能用这个框架里面的东西，不能随意的变动。这样会造成和现在快速变化的商业环境形成冲突。比如对应用运行环境追求更加稳定，不要发生变化，但是开发人员发现有一个开源组件可以大大提高效率，短时间内完成业务需求。从企业角度肯定是选择前者稳定，所有开发环境没有标准化，变成了自动化最后的一个壁垒，下图也是我们最终要达成的目标。
越早确认终态，就能协助整个链条各个角色确更早发现问题，提高效率和持续改进。这是一个根本性问题，如果没有办法解决这个根本问题，在软件工程中做的很多努力都是枉费。
吴军：功夫没下够，用什么方法都是在浪费时间。
二、云原生给开发者带来的挑战
云原生开发时代，对于开发者来说开发是不是变得简单了？
在实际工作中，我们一定遇到过下面漫画的情况。
三、云原生时代的开发组一体化平台特点
软件环境安装是一个简单工作，但是又不得不去做，那么这个问题我们如何去解决？
回到 Devops 系统上，Devops 系统究竟做了什么？所有的Devops系统主要解决了以下四个问题：支持、流动、聚合、决策，在任何一个企业中，落地一个Devops平台系统，第一件事情就是要使用工具、方法、流程让整个交互链条、角色能够被支撑起来。比如需求人员需要有方法把需求录入，有工具帮他拆分，在拆分以后还能跟踪到所有拆分的细化需求和原始业务需求的关联关系。进入到开发环节后，开发能够领取任务，知道每天需要做什么，需要通过怎样的设计在代码里面落地，代码通过代码工具进行提交，通过流水线进行编译打包部署到测试环境等等。所有的工具都需要流程、方法支撑，使其运转起来，运转起来后，我们需要保证流动，流动的是最终交付用户的价值。比如用户提了一个需要，在订单中可以商品数量设置，需要先去拆分需求、开发人员编写、提交代码、编译部署到测试环境、测试通过部署到生产环境，流动就是用户想要的场景。所有底层的支撑都是为了上面的流动走的更快、更顺畅，流动的过程中不要出现返工的情况。
在流动的过程中，聚合了大量的数据，在软件工程领域中称之为研发效能。也被很多人简单理解为大屏，呈现开发人员写了多少代码、流水线在单位时间内触发了多少次、解决了多少BUG、解决时长是多少等等仪表盘的数据分析。这些数据给到管理者后要做决策，需要找到其中的问题，想出解决方案。比如为什么这个系统这段时间出现了更多的问题、更多的返工，需要通过指标看到问题，找到团队找出解决方案，帮助团队做出改进，改变底层支撑措施，加速价值流动，在通过指标去判断管理决策是否正确。
目前市面上的 Devops 存在一个问题，在向右输出价值，为管理者输出了漂亮的仪表盘，对左侧的开发者没有什么帮助。开发者反而变成了不用Devops平台以前2分钟搞定，现在需要提交代码后等待10分钟才能编译好，再等10分钟部署到测试环境，等2天以后测试人员告知有Bug，再回去修改。可能管理者看起来透明了，管理诉求达到了，但实际上在效能是否真的有提升？
我们要做的就是将这些聚合数据，不仅仅向管理者输送，也要向左侧的开发者输送。
下图是基于Devops平台特性做的个人分析，从开发者使用的IDE角度来观看，从中可以看出在向一个方向努力，为了开发者能更准确、更方便去完成开发，并不犯错误。
第一代到第二代提供了更多智能辅助能力，到了第三代结合云的能力，把远程云端工作区引入进来，帮助开发者运用云端算力更容易发现问题。举一个大家平常可能没有太注意的例子，在开源的平台上（比如：Githuab、Gitee）搜索最多的关键字是密钥或者是password，这些信息泄漏事件源头都是来自于开发者不小心将密钥数据提交到共享代码库或者资源上，被黑客发现拿走，做一些不应该做的事情。
为什么开发要做这样的事情，其实他不是故意去做，原因是在于开发环境中编译一个一个的文件，其中有一个文件需要连接到正式环境，一番操作下来密钥就被公布至平台。这些类似的问题，通过云端工作区很好解决，本地也可以解决，但是由于某些配置太复杂，开发者懒的去做或者关掉，在云端工作区更加容易去保证安全工作落地。
现在软件在一个笔记本或者台式机上已经很难完成，比如做几十个微服务系统里面的某一个微服务开发，如果没有另外的微服务配合或者供应链的配合，这个应用跑不起来。如果需要开发在本地把环境搭建起来这也是很困难。所有开发者变成了就算在本地运行代码，也需要远端环境的基础中间件，形成配合才能完成开发工作。所以容器基础设置在企业里面落地后切实为开发者解决了很多问题、帮企业解决了很多问题，也带来了很大的开发调试体验。
Devops平台里面的质量、安全等管理措施也需要通过把开发环境上云的方式才能去解决，比如上面提到密钥的问题。云端工作区主要还是通过Devops平台体现在效能、安全、质量上。
四、企业开发者平台建设思路
通过上面的分析，我们知道向哪里走，接下来了解怎么走的问题。
下图涵盖了整个开发过程的逻辑结构，从左侧的需求到右侧的交付过程，图上的点和线在成套的Devops平台上都有对应的解决方案。但是，只有中间版本管理部分，就是从一个想法让开发人员编写的这个开发调试环境唯一没有纳入管理体系中的一个过程。
纵向看，从企业级研发管理平台工具链体系架构来说，基本分为三层：第一层为企业级的管理架构，企业要立多少项，每一个项目上投入多少资源，最后需要多少产出，项目执行多久，整个过程需要那些团队实施，也称之为PM层。第二层为研发管理平台（Devops平台），也称之为SE层，这里面主要管理需求列表、Scrum、看板，配置管理、测试过程、流水线、环境创建等，在这层支撑不同角色，开发、测试、运维、质量QA等。第三层就是涉及到非常多的工具，从开发过程、代码管理、质量控制扫描工具，再到自动化工具，再到环境配置管理工具，这些工具都需某种方式互动。
所以现在在企业中造成一种状态，一个开发者或者某一个在工具链条工作的角色，需要和多个系统互动，最后才能去完成所有操作。所以它们需要一个统一的入口，这个入口就刚才提到 IDE as Code，在最底层和SM层之间需要插入一个 IDE 环境。这也是未来 3 ~ 5 年 整个业界都会朝着这个方向发展的方案，没有 IDE 配置很多难以落地。
这里演示一个视频，是徐磊老师过去3年在做的一个产品 SmartIDE，视频暂不支持，感兴趣的可以通过下方链接体验：
SmartIDE 管网：
https://smartide.cn/zh/
对于安全，目前正在尝试 “星型流水线” ，比如以前流水线是串行的，现在直接将流水线围绕 IDE 环境进行星型配置，也就是说在编写代码的时候，就已经对代码进行检查，保证提交代码时候就已经达到高质量标准。
另外在企业中也需要定制化场景，比如自动化测试流程、架构设计流程。
在容器里面模拟一个虚拟机，容器本身是运维优化，但是开发者要在容器中开发需要做一些其他的配置。
最后就是也可以使用熟悉的编译器，非必需使用浏览器。使用常用的 Visual Studio Code 连接到云端工作区，就可以即享受云端工作区体验又可以不改变自己开发习惯。
最后总结一下，希望通过云端 IDE 模式，帮助开发者能够实现对软件工程终态左移的最后一个状态，开发调试环境支撑在云端完整运作，赋予开发者云原生的超能力。
五、在线答疑
1、企业开发者平台基于企业中台化架构，要如何做好长远规划和设计？ 2、云原生和Devops是什么关系，研发人员也需要了解Devops吗？
