以系统工程思想构建DevOps体系

本次我将从信息化到数字化发展的要求来谈下正确理解 DevOps 及其体系内容，为什么要以系统工程的思想来思考和建设 DevOps。

数字化特点和要求

当前都正在快步迈向了数字化时代，那么 从信息化到数字化，有什么不同和区别？当前大部分企业从信息化进入数字化，也都在谈数字化转型，作为云原生重要组成部分的 devops 也是数字化转型中的一部分，那么，到底什么是数字化？数字化和信息化的区别是什么？数字化的本质、特点和要求是什么？云原生 DevOps 又承担了什么角色和职责？还有就是为什么中台的概念曾经会很火热而项目却几乎没有成功的？ 我们谈双态运维，稳态和敏态是不是就是矛盾的、隔离的？厘清楚了这些基础的内容，才能更好的理解 DevOps ，更好地去推动数字化转型。

我们都知道，信息化解决了单点的 IT 工具化与效率问题，比如说人力系统、财务系统等，后来一些大公司推出了企业工具套件，比如 SAP 、 EBS 等。将一些系统和能力进行了整合和融合，具备了更强的业务处理和数据分析能力。 但这些还不够，所以我们这些年不断的做集成，比如典型的 SOA-ESB 方式。但 ESB 没有从数据层面做整合重构，数据依旧散落，从而也导致整个系统层次复杂，调用链路复杂，单体的变更依旧不敏捷。后来又出现微服务架构，将单体系统进行拆分，以实现敏捷更新。所以 SOA-ESB 架构和微服务架构虽然都是服务化架构，但其目的是不一样的。 ESB 为了系统间集成共享，而微服务是为了分解笨重而响应缓慢的单体业务应用而出现的。所以我也说过， ESB 重在集成，微服务意在重构。但不管集成或者功能分解重构，其实都带来了更细粒度的服务管理要求，从而也带来了服务管理的复杂度。系统集成就不展开说了，单体系统的分解有两个方向，一个横向功能的分解，一个纵向能力层次的分解。纵向的层次架构出现了 “ 中台 ” 概念，目的是为了实现复用和共享，比如在数据层的复用，在技术层的复用，以及业务层的复用等，所以出现数据中台、技术中台、业务中台等概念。这里强调下，中台本质上是一种架构方式，目的是为了系统间的复用、跨系统复用，把单体系统拆分为微服务从而实现系统间的共享和复用，这就和中台概念结合起来了。也使复用和共享提高到了企业级系统间复用的层次。所以说，微服务架构横向分解、中台架构纵向分层，这样一横一纵架构分解复用思想，提供了一种新的系统架构思路。

这就是融合架构思路。数字化要求从技术、架构、数据、应用、业务、组织等整体上实现协调融合和联动，技术、架构支撑数据、应用以满足业务需求和企业战略，而组织需要适应新的技术和架构要求，适应新的生产力要求，敏捷响应和配合。比如说，云服务 IaaS 为业务系统提供基础设施资源服务，而 PaaS 则屏蔽了基础设施资源服务细节，直接为业务应用提供了应用部署、应用运行、应用运维运营的平台和工具能力。而应用的生命周期管理则会涉及研发运维 DevOps 、微服务架构应用、微服务弹性敏捷的容器运行环境、基于微服务架构实现的可复用中台服务等。如果不考虑当前存量的业务系统，设想一个全新的环境，全部采用微服务来实现企业所有的业务应用系统，全部服务化，而且服务做到了复用，企业是不是看起来就是一个系统了？原来单体系统经过重构可能就变成了一个个模块或应用，而一些共性的能力提取出来成为中台服务，比如日志系统，一家企业有一套标准化的日志服务就可以了，不需要每个系统都开发一遍日志服务。也就从原来的一个单体扩展到了企业级的复用，我称这样的架构为 “ 融合架构 ” ，部署在云平台之上采用云原生技术则称为云原生融合架构，支持企业随时随地随需的业务需求。

所以从信息化到数字化，最大的不同是单点与整体、局部与全局的区别。数字化构建起了业务应用体系，打通了数据之间的关系，数字化转型则深度分析和洞察数据之间的关系，找到数据变化趋势和规律，并有效利用这些数据关系、趋势和规律促进企业业务的变革、创新。所以说数字化本质：是以数据为要素、技术为工具手段，实现对数据的分析和洞察，找到数据之间的关系、联系、趋势、规律等，比如风险控制中关联分析等，从而支持和促进企业业务、流程、组织架构等的变革和创新。说到底，其实还是追求效率，但数字化不再是单点或局部的效率，而是整体和全局的效率。从数据角度来说，数据是生产要素，需要提升数据质量，实现数据融合；从技术角度来说，技术是工具手段，是生产力，是变革基础，需要实现赋能；从架构角度来说，架构决定着响应能力和响应效率，需以复用实现提效；从组织关系角度来说，需要协调好彼此之间的利益关系，满足彼此的关切。所以数字化特点可以说包括全局性、系统化，通过融合、协调，来实现复用、敏捷等。

那么，一家企业要构建和实施 devops ，首先要正确认识理解 DevOps ，对 DevOps 有正确的认知。我们上学的时候都应该学过《庖丁解牛》吧，为什么庖丁能够迅速的分解一头牛？无他，熟尔。他对牛的整体骨架和关节非常的熟悉，所以心中有架构，下刀自敏捷。有句话叫，会者不难，熟能生巧，所以要做好 devops ，首先要了解 devops ，正确认识 devops ，深入理解 devops 。

正确理解Devops

那么 DevOps 是什么？是 CICD 吗？ DevOps 是否包含持续交付？和持续交付时什么关系？ Google 为什么关注 SRE ？很多人说 SRE 是 DevOps 的具体实践，但 SRE 其实是偏运维的，目的是确保站点稳定性，虽然 SRE 也做开发，但做的是运维工具等的开发，不涉及业务开发，所以归根结底 SRE 还是运维人员。不过从 SRE 自身角度来看他们形成了一个小的闭环，自成开发运维一体化。

从整体上看，运维的稳定和敏捷才能真正支撑研发的敏捷。我们想一下，为什么 SRE 要持续不断的开发运维工具？一是为了保障系统的稳定，二是通过工具来提升运维效能，做到运维的敏捷。如果运维做不到敏捷，即便应用一天敏捷发布 1000 次，也难以保障敏捷部署并更新到运行环境，甚至可能导致运行环境的灾难性故障。从应用整个生命周期过程来说，其 80% 的生命周期过程可能都是在运维阶段，所以我也一直说在上 DevOps 之前要先构建敏捷运维的能力。这也是我们先去实施容器云、容器化 PaaS 平台的原因之一。容器化 PaaS 平台提供了应用部署、运行的弹性敏捷环境，实现可视化、可观测能力、链路跟踪能力等，基础打牢了，再去做研发端的敏捷就会容易些。当然具体的架构和能力构建需要基于实际的需求来确定，比如容器云，并不适合所有场景，每种技术都有其优势和不足，我们在构建系统时往往需要多种技术的有机配合。运用 DevOps 的思想方要实现研发和运维的一体化，也往往不是一个平台就能实现的。

从管理和项目管理角度来看，其涵盖的内容要很多，不仅限于研发运维。从需求，立项采购到人员评价等，虽不是 DevOps 关心的重点，但也都是密切相关的。所以我们不能割裂开来看，而是需要放在一起整体来考虑他们之间的关系。另外，要实现跨项目、企业级的复用和共享，比如说日志服务、权限服务、认证服务等，没有必要每个应用都实现一遍，一个企业有一套这样的服务就够了，这也是中台服务复用的最大价值体现。我也一直在考虑如何能更好的从定量和定性方面对整个流程中的人员和工作进行评价，指标当然也很重要，但如果结合 DevOps 从工作量的定量和内部客户的定性反馈来综合评价，可能会相对更客观、更公平些。其实从技术实现角度都不存在问题，关键在于思想的转变，这也是我们今天讨论系统工程思想的一个原因。

从技术角度来说， DevOps 过程会涉及很多种不同的技术，比如说， 研发 Dev 阶段应用研发可能用到微服务开发框架 SpringCloud 等，这些开发的微服务通过持续集成、持续部署流水线部署到容器化 PaaS 平台，微服务可以提取可共享复用的服务来构建中台服务，在 PaaS 平台上可以实现微服务治理。理想情况下，新的业务应用需求可以通过服务的编排来敏捷响应。应用服务运行在 PaaS 平台上，其资源按需调度来自其下层资源管理平台，这个资源管理平台可以是多云管理平台，也可以是内部的一个资源调度管理平台，统一管控企业内外的基础设施资源，提供标准化的资源服务。这样其实也就实现了纵向分层，横线分段的矩阵式架构。最终趋势可能向融合架构方向发展。

除了纵向分层、横向分段，通过 DevOps 思想实现闭环，其实还有一维是组织安全管控角度，这就是系统三维视角，也是在建设 DevOps 时需要考虑的方面。组织协调、安全管控是很重要的一个方面，是 DevOps 能否真正落地，真正适应生产力发展要求的关键。这可以看作是生产关系方面，生产力决定生产关系，生产关系又影响着生产力的发展。采用什么样的生产力和生产关系，和认知又相关，所以认知和思维很重要。

回过头来，再看 DevOps ， DevOps 并不只是 CI CD ， CI CD 只是实现 DevOps 研发过程的自动化集成和部署， DevOps 更应该看作是一种思想，一种方法论，是一套体系，包含一些列的工具和平台，它用于促进应用开发、应用运维和质量保障（ QA ）部门之间的沟通、协作与整合。 DevOps 中，开发专注于业务应用的生命周期管理，运维专注于自动化环境资源的维护，QA专注于自动化业务运行环境的供给和质量跟踪保证 。 DevOps 的核心在于消除研发运维流程中的堵点，就像人的血管种如果有血栓，需要溶解血栓、疏通血管一样，否则就可能偏瘫。我非常喜欢用社会系统或人体系统来类比，人类社会和人体系统经过数十万年的进化，整个体系非常严密，可以用于软件架构和设计思维参考。 DevOps 的思想就是要融化、疏通血管种的血栓，从而实现平滑衔接，提升开发和运维的效率。部门内部的协作通常还好，跨部门的协作往往就很难，因为利益不一样，所以 DevOps 很重要的一点就是平衡开发和运维之间的利益，而不是简单上一个平台或一套工具。

Devops体系内容

DevOps 是一种思想一种方法论，要把这种思想和方法落地，就需要工具和平台的支撑，需要技术的支持，实现持续交付能力。

在云原生体系中， DevOps 优化组织间的协同，满足彼此的关切，指导 C ICD 的落地和持续交付，实现应用全生命周期管理；十二个要素应用为云原生应用的设计提供了原则指导；微服务架构为云原生应用架构设计、分布式部署、敏捷变更等提供了方案；容器则为云原生应用提供了弹性伸缩、一致性环境等能力，和微服务结合，支撑应用随需扩展；自服务敏捷基础设施则提供了云原生应用持续交付的基础设施资源等保障，可以和容器化 PaaS 平台共同支撑云原生应用的自动化弹性扩展、可视化监控、自动化智能化运维运营等，使用户无需关注基础设施资源，无需运维基础设施资源，无需关注应用部署位置等；服务网格支撑着服务的管理和治理；混沌工程则持续增强系统的韧性和稳定性；声明式 API 则实现了服务标准化发布和服务之间的协同；安全则涉及云原生架构体系的方方面面，比如 DevOps 安全 D evSecOps 、容器镜像安全、网络安全、应用安全、 API 安全、认证授权、访问控制等等；所有这些技术、方法和原则满足客户随时随地随需的需求，简化客户操作，提升客户体验。所以这些技术并不是割裂的，是相辅相成的。是系统化、体系化的。

从 DevOps 应用研发一体化过程来说，整个闭环流程也包含很多的功能和能力，涉及多种技术和工具。 QA 在很多公司和测试放在一起，其实 QA 的职责不止是测试，还有一些治理的职责。当前我们在实施 DevOps 时往往强调平台和工具，往往也只关注研发端，运维端都很少涉及，持续部署的能力都很难实现，因为需要有很多的审批环节，这其实和 DevOps 的思想是相悖的。这是因为传统管理思想的局限比较难突破。举个例子，曾经在讨论云管需求时，有的运维人员考虑的不是如何用简单高效的方式来实现需求，他考虑的是尽可能不改变现有流程，去让厂商做定制化。所以事倍功半，上那么多系统，效能反而更低。仅关注研发和运维一体化的 DevOps 可以称之为狭义的 DevOps ，不过仅流水线不能称为 DevOps 。 而广义的 DevOps 应该包含应用的全生命周期管理过程，包括从需求到架构、到设计、到研发部署，到监控反馈、到应用下线及资源的调度管理等全过程，也包括人员的激励和组织协调。

其实我个人觉得 DevOps 思想很重要的一点在于组织和人员间的利益协调和平衡。企业内整个 DevOps 流程可能涉及众多的部门、团队和人员，如何平衡这些人员的利益，如何激发这些人员热情和责任感、如何让这些人员觉得自豪有成就感，在 DevOps 构建过程中可能需要认真的考虑。 DevOps 为什么强调闭环思想？我觉得闭环、持续的反馈才能有全面的了解，从而促进改正和提升。另外 SRE 实践表明，通过自动化的工具和手段实现各层次和各环节的无缝衔接，系统之间的配合和全局的可见性、可维护性、韧性等将非常关键。因此，我们可以看到，研发和运维过程中涉及到众多的技术、应用、平台、工具、人员、数据、架构、业务等等，它不再是信息化阶段的一个单体系统，而是一个由众多子系统组成的相互联系、相互影响的复杂系统。

以系统工程思想规划和设计devop

所以在设计构建 DevOps 时，需要以系统工程的思想来思考和规划。

系统工程是为了最好地实现系统的目的，对系统的组成要素、组织结构、信息流、控制机构等进行分析研究的科学方法。它运用各种组织管理技术，使系统的整体与局部之间的关系协调和相互配合，实现总体的最优运行。

系统工程包含三个维度，管理、技术和思维。它把研究对象作为一个整体来分析，看他们之间有什么联系、有什么关系，使总体中的各个部分相互协调配合，服从整体优化要求 ; 在分析时，综合运用各种科学管理的技术和方法，定性分析和定量分析相结合；以及对系统的外部环境和变化规律进行分析。我个人觉得重点在思维，思维方式往往决定了一个人思想的深度，也决定了所采取的管理方式和技术手段。所以需要持续不断的学习，持续提升认知和思维能力。

前面我们也提到，数字化转型要求业务应用系统可能向融合方向演进。包括基础设施、数据、应用、业务、组织等的融合。其实中台架构的提出就是融合演进的一个很好的指向。其实从基础设施的资源池、超融合、云计算等发展来看，而不同的技术和方案逐步融合为一体，成为一个相互协同、相互促进又相互影响的融合系统，逐步提供更简单更便利的服务。

我们也提到， DevOps 的核心是协调研发和运维的协作，满足彼此的关切。那么在 DevOps 落地时，就需要考虑通过一些方法来减少彼此之间的交互协作，通过自动化的工具和流程来提升效率。比如以镜像仓库为媒介实现研发和运维的协调，研发关注的是业务应用的研发，交付标准化镜像，通过自动化流程提交到镜像仓库，运维则提供镜像部署和稳定运行的环境，提供自服务化的应用部署管理、监控、告警通知等服务能力，开发人员成为了运维的内部客户，开发人员在使用应用部署运维平台的过程中可以根据使用体验提出平台的改进需求，从而不断的完善研发运维平台的功能，持续提升其韧性和稳定性。

DevOps 实施路线图可以参考这样的步骤，首先要建设应用的运行时环境，比如说容器云平台或容器化 PaaS 平台，最好呢能够具备统一的基础设施资源的调度能力，这其实也是我一再强调云管的定位，现在的云管都是个大杂烩，什么都做，什么都做不好。其实云管更应该定位于多云和跨云基础设施资源的调度管理，屏蔽异构资源的复杂性，为 PaaS 平台提供标准化的基础设施资源服务。然后在容器云或容器化 PaaS 平台之上要完善应用的管理和治理能力。应用管理和治理跟容器云和容器化 PaaS 不是分离的，也不是两个平台，而是一体的。现在很多厂商把这些功能都拆分出来成为两个独立平台，额外带来众多的复杂的集成工作，造成重复建设，非常低效。当具备了相对完善的运行时支撑能力之后，可以构建 DevOps 体系，将开发和运维整合为一个有机整体，稳定的部署运行平台可以有效的支撑研发的敏捷部署和更新需求。然后呢需要构建和完善自服务的基础设施工具，最后持续提升系统和应用的稳定性和韧性，提升敏捷响应能力和安全性等，构建持续的闭环反馈流程以促进持续的完善和提升。

最后呢，谈一点 DevOps 实施中的难点和注意事项，我个人觉得最大的难点在于认知，国内 DevOps 厂商认知及格的不多，大部分人其实都是在忽悠。这么说可能得罪很多人，不过我还是希望能让更多的人认识到本质的东西，能让大家多一些思考，能持续的提升自己。选择 DevOps 厂商时，一个自己都不用 DevOps 的厂商，一定是不能选的，它一定是不懂 DevOps 的。 DevOps 不是一个部门或者一个团队的事情，也不是一个项目的事情，是一家企业研发运维的整体能力体现，所以 DevOps 的建设要考虑全局系统化建设，而不是一两个项目。国内都侧重于研发，而不重运维，大部分厂商的 DevOps 工具平台也都是倾向于研发管理，增加众多的研发绩效统计管理功能，并不能带来敏捷，反而带来更多的额外工作量

DevOps 的重点在于运维，运维的响应能力和平台的稳定性、韧性和可见性、可观测性等是基础建设 DevOps 的目的一定不是为了看研发绩效，关键在如何协调、激发相关人员的主动性和责任感，看整体研发运维一体化的能力。