上一篇文章《深入思考软件工程，开启 DevOps 之旅》，详细阐述了我们对软件工程和 DevOps 的理解，并且明确 DevOps 已是软件工程领域集大成者的结论。

那么，作为企业的 CIO，身处信息化浪潮中，面对 DevOps 的命题应该如何应对：

• 企业能从 DevOps 中获取什么收益？

• 企业应该如何规划 DevOps 体系并选择合适的切入点？

• 企业应该选择什么样的 DevOps 平台、方案、厂商？

希望阅读完本篇文章，能给您一些启发。

一、企业 DevOps 体系建设背景

企业选择 DevOps 的外部环境

市场环境

在 “VUCA” 的数字化时代，企业的生产经营由原来的“完全按照规划完成工作计划、部署执行、跟踪”的过程，开始向“在行进过程中不断探索和调整，用最小代价逼近战略目标”演变。因而，更快的生产、销售、交付客户价值、获取反馈、持续改进，自然成为企业致胜的法宝。

而对于企业来说，无论处在什么行业，要想获取客户并向客户交付价值，都离不开 IT 技术与软件。如何通过 IT 技术与软件，达成“更快的生产、销售、交付客户价值、获取反馈、持续改进”的价值交付体系？DevOps 作为当前软件工程界的集大成者，无疑是现在最佳的选择。

行业标准

2018 年 7 月 26 日，工信部中国信息通信研究院牵头《DevOps 标准：研发运营一体化成熟度模型》在联合国 ITU-T 正式立项。成为全球首个 DevOps 国际标准。DevOps 标准评估体系主要包括敏捷开发管理、持续交付、技术运营、应用设计、安全及风险管理、系统和工具等部分。

《研发运营一体化（DevOps）能力成熟度模型》系列标准是由中国信息通信研究院牵头，云计算开源产业联盟、高效运维社区、BATJ 等顶级互联网公司以及各大金融、通信企业共同制定的国内外首个 DevOps 系列标准。

国家政策

2017 年 7 月发布的《中国金融业信息技术“十三五”发展规划》提出：“优化金融信息技术治理体系，提升信息技术服务水平”。

2016 年 7 月银监会发布的《中国银行业信息科技“十三五”发展规划监管指导意见》中提出：完善银行研发管理体系，并要求自主研发团队超过 100 人的银行应达到中等以上的软件过程能力成熟度。

产业应用

在国内外先进科技企业的 DevOps 实践影响下，很多国内大中型传统企业也开始同步接收、尝试，推行 DevOps 实践。以信通院 DevOps 能力成熟度评估认证为纬度统计，截止 2021 年 Q3，通过信通院 DevOps 能力成熟度评估的组织及项目累计已超过 100 余个。

不同行业对于 DevOps 的诉求

艾瑞咨询 2020 年的“中国 DevOps 应用发展研究报告”，将企业对于 DevOps 的诉求做了总结和归纳，按照“传统行业”和“科技行业”的分类方法做了如下阐述：

传统行业：数字化转型捷径

传统行业的主营业务并非软件的研发与运营，IT 上的人才和基础设施相对薄弱，因此这类组织的数字化水平整体相对较低。在数字化转型的大趋势下，找到适合企业的高效数字化转型道路将意味着在市场竞争中取得先机；

在传统行业中，金融和能源等行业由于资金充足、技术实力相对领先，且对于各类软件和在线应用的需求较高，在传统行业中走在数字化升级的前列，也是率先引入 DevOps 方法和工具的行业。

另外，对于政府部门而言，将能够更好地构建数字政府和数字政府服务体系，提高地区乃至全国的信息化基础设施水平。而新零售、智能制造等近年来逐步兴起的互联网+行业也正在积极拓展互联网能力构建渠道以及市场优势。

科技行业：软件工程新纪元

相较于传统行业以及公共事业机构，包括软件、电商和电信运营商在内的信息科技行业一直以来是 IT 科技创新的领跑者。软件开发和运维架构是支撑上述企业业务运营的核心能力，但也因为其 IT 架构复杂、团队庞大，在管理和协同优化上面临诸多困难。

DevOps 理念和工具的有助于科技类企业更快地响应客户需求、交付客户价值、统一 IT 环境、提高团队反映能力和研发质量，是企业提高市场竞争力的核心助力。目前我国的头部科技类企业的软件部门大都是 DevOps 的主要践行者。

企业能通过 DevOps 解决的问题

企业在进行软件研发与管理时，内部环境典型反映出的问题与痛点如下：

需求开发过程协作困难，存在浪费

以 DevOps 价值流的视角来看，从业务部门提出需求，到 IT 部门收到需求、分解需求、计划排期、开发测试到上线，中间会经历多个部门、多个团队、多种角色的协作。在这一过程中，会存在着很多可优化的地方（对于产生价值没有帮助的活动或投入、等待时间都是浪费）。

DevOps（平台）和（平台内嵌的）敏捷实践方法可以解决从需求到交付过程中的协同反模式：重文档轻交流、围绕文档的低频重型交流/大型需求澄清会、需求澄清不清晰难以理解、需求跟踪困难。通过 Scrum 及其他方法和工具去完成更敏捷化、精益化的需求开发协作过程。

研发测试过程缓慢

在没有实施 DevOp 和流水线的情况下，团队需要花费大量时间在编译构建和测试上。缺乏自动化编译构建、自动化测试的方法和有效工程实践、没有工具去支撑重复的、可自动化的、占用大量人工时间的必要工作，都是在研发测试过程中存在的浪费。

通过 DevOps（平台）和（平台内嵌的）流水线的建设，团队可以节省大量的编译构建及测试时间。比如可以通过自动化的编译能力，实践每日构建、基于分之合并的构建等实践方法，让代码集成的时间提前，以控制代码的质量、降低集成的风险；通过可以与流水线集成的自动化的测试能力，实践自动化（功能）单元测试、自动化接口测试、自动化业务场景测试等实践方法。

代码管理混乱

代码是软件开发活动产生价值的初步成果物。而在当前复杂的业务需求和系统架构环境下，大规模并行开发是很常见的场景。从而很容易产生代码管理混乱、 SCM 工具管理混乱等问题。具体表现如：没有统一的代码管理工具、缺乏有效的分支管理策略、代码分支策略混乱、团队对 SCM 工具掌握程度深浅不一、缺乏从需求到代码的跟踪等。

通过 DevOps（平台）和（平台内嵌的）代码管理方法，可以帮助企业建立组织级的代码管理规范和方法，统一代码管理工具，有效降低因代码管理混乱而导致的各种风险。

手工应用发布操作复杂并且风险

软件制品的发布是软件交付到用户手中并体现价值的最后一步。对于承载着复杂场景、关键业务的应用系统来说，传统的全人工发布存在诸多缺点，虽然我们可以通过部署指导文档来辅助，但仍然有着各种无法避免的问题，比如：发布过程易出错、无法跟踪发布过程、每个应用有自己单独的发布工具和发布规范、组织级发布管理规范和执行流程难以执行和跟踪等等。

DevOps（平台）和（平台内嵌的）自动化发布能力，不仅可以帮助团队将应用的复杂发布过程自动化、可视化、可重现性，同时还能实现组织内部统一的应用发布规范、应用制品规范、制品晋级流程等，将发布标准流程融入到系统中，降低合规检查的成本和人工部署的风险。

研发过程改进缺乏抓手

传统研发作业模式下，缺乏有效的研发过程基础数据、研发过程数据散落在各处没有统一归集无法整体综合分析，过程改进无从下手。

DevOps（平台）和（平台内嵌的）度量分析能力，可以帮助组织和团队将散落在研发工具链中的各种数据统一归集，积累整理有效的研发过程基础数据，整体综合分析。结合研发效能实践的整体优化理念，在有效数据的基础上逐步改进研发能效。

组织级研发管理规范难以落地

无论是传统行业还是科技行业，随着企业经营向上发展，对 IT 的要求必然会越来越高。这体现在 IT 团队规模、应用数量、基础设施数量的增长，数量的增长又带来了管理复杂度和技术复杂度的增长。所以除非是非常小的创业团队，企业必然会产生通过“建立研发管理规范、方法”来向 IT 要效能内在需求。

但中小型的组织往往缺乏组织级研发管理规范，而中大型组织的规范就算制定出来，往往也难以充分跟踪、贯彻执行，最后成为挂在墙上的标语。

通过 DevOps（平台）的建设和 DevOps 实践的应用，可以将组织级的研发管理规范贯彻到项目中的“最后一公里”，从需求流程、协同作业、代码管理、制品管理、制品晋级、发布流程、资源配置等研发过程中核心场景和周边场景涉及的流程规范标准化、系统化、规范化、可视化。

二、企业 DevOps 体系知识精要

DevOps 本质

DevOps 的本质是一种以更快交付价值为目标的优秀软件工程方法合集。了解 DevOps 的本质，并不能让你获得某些诀窍或者具体的工作方法，而是给你一把钥匙，帮助你思考事物的原理，并且在发生新的情况时让我们有所准备，能够找到如何去处理的方法。

敏捷宣言创始人之一 Ron Jeffries 在他的《软件开发本质论》一书的封面上，对软件开发给出的总结是：“追求简约、体现价值、逐步构建”。而这一目标的实现，则依赖“Ron 金字塔”来完成。

《软件开发本质论》第 1 章节选：

价值：所谓价值，就是“那些我们想要的东西”。

我们会自下而上从金字塔的底部开始，在将产品划分为小块的基础上讨论如何指导、组织、计划和构建产品，同时重点关注产品的质量。我们将以此为基础,最终创造价值。

指导：通过组建以创造价值为己任的团队来实现价值的创造，因此需要确保团队成员知道客户需要什么，以及客户留给我们的开发时间。我们通过观察实际构建出的产品来对团队的工作进行指导。

组织：我们需要围绕产品的功能特性来进行组织，因为这些功能特性可以使我们更好地计划，并更快地创造出价值。我们选贤任能,并帮助他们提高技能。

计划：根据所需功能特性的前后顺序来对其进行选择，以此来控制项目的进展，这样就能够及时创造价值。

构建：通过逐个实现功能特性来构建产品。这样就能够频繁地进行价值的交付，同时能够尽早、经常地看到项目的进展。

划分：将功能特性划分为小块，使每一块尽可能小，前提是它们仍然有价值。这样就能够尽早地构建出有用的产品,并在交付日期到来之前对产品进行优化与提升。我们时刻准备交付产品。

质量：采取必要的措施，以确保生产出来的产品设计优秀、品质精良。这样就能够不断、持续、永久地创造价值。

DevOps 原则

我们根据《DevOps 实践指南》（DevOps Handbook）一书的描述，整理了 DevOps 的核心原则。

流动原则

如果我们把价值从生产到生效的过程用流水线来比喻的话，那第一个原则就是要“流动起来”，并且在质量成本等约束条件下越快越好。软件只有在交付给客户/投入使用时，才开始产生价值。所以针对整个工作流程的优化，要围绕全局目标，而不是局部目标。

1. 使工作可见

由于软件本身具备的“隐匿性（invisibility）”，软件研发的成果（可运行的软件）很难在完成前被看清楚。再加上工作项的流转非常容易，可能就是鼠标点点，不同团队很容易因为各种原因而将工作项“踢来踢去”，存在的问题也自然被传递到下游。这些问题都是很难被察觉的，直到工作计划中的检查点、客户交付产品的那一刻、生产环境出现故障。

所以为了能够识别工作在哪里流动、排队或停滞，就需要讲工作尽可能地可视化。通常看板（SprintBan、Kanban 等）是比较好的实现方式。通过 Ban 将各种工作展现出来。

通过将工作项都放进容器（SprintBan），并可视化地展现出来，利益干系人更容易从整体（所有工作项）出发，确认优先级。对团队来说，也能够更聚焦重要的工作，增加工作项吞吐量。

2. 限制在制品数量

软件开发语境下的在制品，指的是未开发完成/交付完成的软件成果物“制品”，又可以进一步泛指为进行中的工作项。

制造业的日常工作是由生产计划预定义好的，生产计划的变更、打断非常显眼，而且代价极高。但软件开发工作却是另一番景象，工作计划安排通常是动态的，或者说经常出现临时的安排打断已有计划。更糟糕的是，软件开发工作被打断的后果和代价似乎并不可见，即便它对生产效率的影响相比制造业更甚。

使用看板管理工作项时，可以非常容易的识别并管理在制品的状态和数量。通过管理并行的工作项，还能更容易发现工作中的阻碍。通常来说，软件开发中相当一部分优先级的冲突是同时给一个人在同一时间段分配了很多工作项导致的；另外就是没有管理好并行工作项间的复杂依赖关系。

3. 减小单批量大小

建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作。降低单个批次工作项的数量，以小批量的模式推进，也是精益中一个非常重要的经验，目的是缩短前置时间和提高交付物质量。

对于（软件开发）技术价值流而言，大批量的副作用和制造业一样。越是偏向瀑布的开发模型，开发成果按照计划时间一次性地集成、测试、发布，会导致问题的集中爆发，引起下游工作环节的大规模混乱。

4. 减少交接次数

在技术价值流流转的整个过程中，会经历不同部门、不同角色的不同人员相互协同才能完成相关的工作，包括需求的流转、代码的流转、制品的流转、环境的配置以及各种支撑的流程和工具。而一项工作在团队建设交接时都需要投入大量的工作，包括沟通协调、不同团队的工作优先级排序、冲突处理等等。在这些过程当中不可避免地会存在信息的丢失、失真和工作项的延时、等待。

5. 持续识别和改善约束点

为了缩短前置时间、提高吞吐量，我们需要不断地识别系统中的约束点，提高工作产能。反之，如果优化约束点之后的工作重心，那么这种优化就是无效甚至负面的，会让下游的工作重心倒逼上游而产生更大的问题。这也是在 DevOps 和精益理论中的所谓“全局优化”和“局部优化”的区别。

在 DevOps 实践中，常见的约束点可能包括但不限于：需求审批、环境准备、代码集成编译、制品部署、测试准备与执行、不合理的架构等。

6. 消除价值流中的困境和浪费

精益中对浪费的定义是“使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为”。TPS 先驱之一的新乡重夫定义了制造业里的 7 中浪费类型：库存、过量生产、过度加工、运输、等待、移动和缺陷。

如果映射到 DevOps 的领域中，我们大致可以如下对应：

• 库存。未交付的在进行中的需求；

• 过量生产：需求蔓延、交付了非必要的需求等；

• 过度加工：过度设计；

• 等待：资源协同过程中存在的人员等待；

• 运输、移动：过多的流程环节、不合理的协作模式等；

反馈原则

我们的目标是建立安全可靠的软件工程体系，这对业务复杂的系统来说尤其重要。常规情况下我们发现问题和纠正问题的时机，是生产过程中发现软件缺陷或阻塞点时候，或是软件投产后在生产环境发生故障时等等。

通过在价值流和组织中建立起快速、频繁、高质量的信息流和反馈机制，可以让系统更安全。在更早的时间，以更小的代价发现并修复问题，在灾难发生之前解决问题，并营造团队的学习氛围。利用问题和失败在实践中学习，而不是惩罚和责备。

1. 在复杂系统中安全地工作

我们必须承认，复杂系统是客观存在的，复杂系统中的故障也是客观存在且无法避免的。所以实事求是地说，我们的目标是建立一套工程体系，让团队能够无所畏惧地工作，敢于发现并提出问题，确保在灾难性后果发生之前，能够快速发现错误并修复错误，并从中学习提升的机制和文化。

2. 及时发现问题

软件研发过程中，经常会出现由于缺少快速反馈机制而导致不好的工作结果。比如典型瀑布模型下的测试工作，要等到代码开发完成以后开始，而在这之前得不到任何需求准确性和软件质量反馈。

反馈回路不但让问题的快速探测和修复成为可能，还能辅助我们分析如何防止问题本身或类似问题的再度发生。在这个过程中，不仅价值交付着得到了保障，团队也得以向学习型组织演进。

3. 群策群力，战胜问题获取新知

群策群力的逻辑源于丰田生产系统中的“安灯绳”。当安灯绳被拉动时，团队领导就能第一时间得知并着手解决问题。如果问题不能在很快的时间内解决，就会停掉生产线，调动整个团队一起协作，找到问题并解决问题。

让所有人参与的原因有二：

• 复杂系统出现的问题，很难完全通过某个个人或者外部工具将问题完整、准确、清晰地呈现出来，特别随着时间的推移。再次面对问题时的信息读取、理解等等都是代价非常大的。只有靠群策群力才能最大程度的消除遗漏。

• 让所有人都参与，能够让团队得到更加深入的实践和知识，把问题处理过程转化为学习过程，有助于提升长期团队价值交付的质量和问题处理效率。③组织开展新工作有助于实现持续集成和部署，这就是技术价值流中的单件流。

4. 在源头保障质量

我们需要价值流中的每个人在他们控制的领域里发现问题并解决问题。通过这种方式，可以把质量控制、安全责任和决策机制都置于开展工作的场景里，而不过分依赖外围高层管理者的审批。“让一线呼唤炮火”。

质量无效的例子：

• 需要其他团队完成一系列本可以需求方自己用自动化可以完成的工作；

• 编写大量含有可以细节，且在写后不久就过时了的文档；

• ……；

5. 为下游工作中心而优化

精益定义了我们必须为两类客户而设计：外部客户，为软件价值付费的人；内部客户，接收我们当前工作输出并进行下一步处理的人。

在技术价值流中，我们不仅应该为外部客户做好功能设计与实现，也应该为内部客户做好非功能性的设计（可测试性、可配置性等）。

持续学习与实验原则

1. 建立学习型组织和安全文化

在复杂系统中工作时，精确地预测往往是不现实的，总会有意外发生。当发生意外时，如果组织的做法是倾向于点名、责罚，甚至羞辱，那结果只会更坏：

• 流程会变得更加复杂以杜绝问题发生；

• 组织会变得更加官僚（而非细致）、信息更闭塞，甚至发生逃避问题责任、滋生自我保全意识等问题。

在技术价值流中，努力打造安全的工作系统，追求健康、充满活力、具备竞争优势的团队和文化，才可能避免这些问题。消除职责，能够有效促进学习型组织的建立。

2. 将日常工作的改进制度化

如果团队没有能力或医院去改进现有流程，那就会持续饱受困扰和折磨，甚至痛苦指数还会与日俱增。因为当团队花费很多精力去实施临时解决方案以应对突发情况时，会产生比平时更多的隐患（技术债务）。

更好的做法是：通过明确预留的时间来改善日常工作，包括预留时间来偿还技术债务、修复缺陷、重构和优化代码和环境、优化工作流程等。通过持续改进，帮助组织更好地完成价值交付、在市场上获取更大的竞争优势。

3. 把局部发现转化为全局优化

一旦在局部范围内取得了成果，就应当把它分享给组织内的其他人，让更多的人受益。特别是将隐性知识（很难通过文档或沟通传递出来的知识）转化为显性知识，从而帮助团队吸取这些专业知识并在实践中应用。

4. 在日常工作中注入弹性模式

低绩效组织的日常是想方设法环节问题，疲于应付问题。高绩效组织则通过改善日常运营，持续地引入张丽提高生产效率，同时在系统中注入更大的弹性，来实现或达到更加的效果。

在技术价值流中，通过缩生产部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时结构架构，都属于在系统中引入类似张丽的做法，也都能提高开发人员的生产效率和应用可靠性。

5. 领导层强化学习文化

领导者帮助一线工作和在日常工作中发现并解决问题，这种方式实际上就是丰田生产系统的核心，也是学习型组织、改善套路和高可靠性组织的核心。

在技术价值流中，这种实验和迭代改进的方法，不但能指导我们改进内部流程，而且还能指导我们不断地进行实验，保证构建的产品能为内部（下游）和外部客户带来价值。

DevOps 全景架构

我们试图从全景业务流程、知识技能图谱两个部分，来概况 DevOps 体系的整体内容。DevOps 全景业务流程，是我们根据自身的理解、产品与客户需求所所绘制的。而 DevOps 知识技能图谱引用了来自 IDCF 组织整理的 DevOps 技能树，发表于其官方网站上。

DevOps 全景业务流程

DevOps 全景知识图谱

三、企业 DevOps 体系实践规划

DevOps 体系建设目标

从中短期规划目标来说：宏观上，我们希望通过 DevOps 体系的规划和建设能够帮助企业提升 IT 效能、更快的业务响应速度、更优质的业务连续性。微观上，我们希望通过可以“平台化、可视化、自动化、数据化”的各种工程实践，帮助技术价值流上的各个工作中心提升工作质量、效率和体验。

从长期规划目标：我们希望借助 DevOps 体系持续改进提升组织流程和工程实践的流动性、反馈效率，并建立学习型组织。逐步从传统管理模式向 IT 敏捷转变，最终达到业务敏捷的目标。

DevOps 体系建设内容

每个企业对于软件研发的组织模式都是有所不同，在不同的组织结构下， DevOps 的规划的内容也会有所不同，其中最大的差异还是由于组织文化、历史沿革、行业特性等因素造成的自身在组织架构和部门间工作边界的差异，具体到工程实践上时，差异反而会小一些。

本小节我们将以一个没有实施过 DevOps 的组织为限定条件，按照 DevOps 体系的业务领域子域作为划分边界，罗列出在做规划时针对不同领域的工作要点清单。

需求管理

1. 建立完整的需求管理过程

工作要点如下：

• 体现需求从最初提出到完成的全过程；

• 体现需求的拆分情况；

• 体现需求的分析、协作、流转情况；

• 体现需求的反馈及状态跟踪过程；

2. 建立有效的需求工件管理机制

需求工件指的得是需求活动的输出物，包括需求文件、测试用例文件。

工作要点如下：

• 需求工件的形式采用 Backlog、User Story 等方法作为核心的沟通介质;

• 需求工件的内容最好要有恰当（足够小）的粒度，以便做到清晰、有效、便于沟通、可协商、可估算;

• 需求及需求工件是有一定弹性的，同时弹性有恰当的边界，能与组织的需求变更流程相适配。

项目/产品管理

工作要点如下：

1. 建立价值导向的敏捷开发管理过程

• 体现敏捷开发方法中利用迭代、看板等方法与方法与工具的能力;

• 体现开发过程中对于不同类型需求的分类管理能力。

测试管理

1. 建立完整的测试管理过程

工作要点如下：

• 体现测试用例的完整结构。包括用例名称、类型、步骤、附件等关键要素，并具备用例分组能力；

• 体现测试计划的完整结构，包括计划名称、关联版本、关联迭代、计划周期、涉及用例集等关键要素；

• 体现缺陷管理能力。包括缺陷的录入、修复、跟踪；

2. 建立完整的测试用例管理机制

工作要点如下：

• 测试用例有完整的编写、验证、管理机制。

• 测试用例在设计结束时即可完成大部分内容，最终在开发结束前全部完成。

• 测试用例在上线前应全部验证通过，并且单元测试等基础类测试用例可以自动化完成。

• 测试用例在其生命周期中应一直保持更新与发布软件版本的需求一致。

代码管理

工作要点如下：

• 具备组织级的现代 SCM 工具，并通过工具实现组织内代码的统一管理及工具运维，实现单一可信数据源。

• 代码分支策略管理。根据具体代码工程的实际情况，可以使用 SCM 工具实现恰当的分支策略。必要场景如能与 DevOps 平台/开发管理平台集成以降低开发工程师使用成本，则更佳。

• 代码版本策略管理。根据具体代码工程的实际情况，可以使用 SCM 工具实现恰当的版本管理能力。必要场景如能与 DevOps 平台/开发管理平台集成以降低开发工程师使用成本，则更佳。

• 具备体系化的代码管理工具运维策略。包括备份与恢复机制、完整性与一致性保障策略。

流水线管理

• 编译构建采用流水线而不是手工方式执行。

• 流水线的实践可以与代码分支管理策略密切配合，最好是通过 DevOps 平台完成可视化的流水线编排、执行、跟踪。

• 有明确的构建规则和管理计划。

• 流水线的日常运作由团队自身负责。

制品管理

工作要点如下：

• 具备组织级的现代制品管理工具，并通过工具实现组织内代码的统一管理，实现单一可信数据源；

• 基于制品管理工具，具备有效的组织级制品库空间规划及使用规范；

• 基于对应的场景，制品的上传、下发、晋级与 DevOps 平台/流水线可以实现自动化的流转；

• 具备体系化的制品管理工具运维策略。包括备份与恢复机制、完整性与一致性保障策略。

部署管理

工作要点如下：

• 使用自动化部署工具，而非通过人工部署；

• 自动化部署工具体现面向应用、服务的自动化部署与编排；

• 自动化部署工具具备脚本自定义能力、脚本参数定义能力、服务部署测了能力；

• 历史部署情况可追溯。

企业流程与合规管理

工作要点如下：

• 在需求、资源申请/释放、部署等与组织内部周边系统有衔接的业务领域，能够平滑对接，满足企业流程要求；

• 对于金融业等存在监管的场景，能够根据具体情况满足其合规要求。

DevOps 体系建设路线

罗马不是一天建成的，DevOps 是作为研发管理之重器，也并非一朝一夕就可以建设好、运用好。对于大多数的组织来说，完整 DevOps 体系的建设和应用之路也需要做好规划，特别是有一些企业对于 DevOps 除了实践应用之外还有过信通院能力成熟度模型的需求，还要为过级评估工作留出充分的时间。在目前很多企业年度预算制的开支框架下，DevOps 项目需要做好规划与路径，做到有明确的短期、场景的目标与实现路径，才能更好地完成项目，达成预期。

四、博云 DevOps 解决方案概览

对于向落地 DevOps 的团队和组织来说，所处行业、组织文化、软件形态、团队现状、内部环境等等因素的不同，都会导致其研发管理和工程实践的不同。而如何在充分考虑现实因素（目标、时间、成本、资源）的情况下，去选择一个切实有效的路径和方案，是落地 DevOps 项目成功的关键。所以对于一个 DevOps 项目来说，并非买一套产品就万事大吉。

站在企业视角，需要一个什么样的 DevOps 服务商？

我们认为，DevOps 是软件研发/脑力创造领域相关工作的 “ERP” ，需要的不仅仅是一套平台，而是包含业务咨询服务、统一平台产品、工具链产品、集成开发服务等等一系列持续的服务。

博云基于自身在金融、工业、企业、政务等行业的经验，总结了一套可以为不同行业客户落地的交付方案，愿意与各个行业的朋友持续交流切磋。

参考资料：

1. 《中国金融业信息技术“十三五”发展规划》（中国人民银行印发）；

2. 《中国银行业信息科技“十三五”发展规划监管指导意见（征求意见稿）》（银监会印发）；

3. 《艾瑞咨询：2020 中国 DevOps 应用发展研究报告》；

4. 工信部信通院微信公众号：中国信通院 CAICT；

5. 高维社区微信公众号：高效运维；

6. 《软件开发本质论》（Ron Jeffries）；

7. 《DevOps 实践指南》（Gene Kim, Jez Humble, Patrick Debois, John Willis）；

8. 《No Silver Bullet》（Brooks, 1986)；

9. https://idcf.org.cn/Home/；

（参考资料按在本文正文中引用的先后顺序排序）

博云 BeyondDevOps 平台开放试用，欢迎扫描下方二维码或点击文末阅读原文申请试用。