目录
2.1.2 PDCA 管理模型建设DevSecOps阶段内容
2.1.2.3.2.1 建设DevSecOps平台应遵循的策略
2.1.2.3.2.2 DevSecOps平台是技术路线选型原则
2.1.2.3.2.3 DevSecOps平台构建是应关注的两个方面
一、大中型企业DevSecOps建设概述
1.1 概述
与中小型企业相比，大中型企业的DevSecOps建设明显要复杂许多。这种复杂度与业务规、业务种类、人员数量、组织分工等因素是息息相关的。面对这些复杂的因素，在开展DevSecOps建设时，通常采用PDCA管理思路来制定建设规划，跟踪规划落地进度，以推动DevSecOps安全建设，达到企业在安全领域的战略目标。
二、大中型企业DevSevOps 建设规划思路
2.1 PDCA 管理模型
2.1.1 PDCA管理模型图
如上图所示，整个DevSecOps建设的PDCA环，从 组织架构、管理流程、技术平台、人员及组织保障等多个层面，将DevSecOps建设划分为4个阶段。下面就分别来介绍，在每一个阶段如何开展大中型企业的DevSecOps建设。
2.1.2 PDCA 管理模型建设DevSecOps阶段内容
2.1.2.1 建立DevSecOps管理机制
开展DevSecOps建设，首先要做的是建立DevSecOps管理机制，管理机制主要包含DevSecOps组织架构、人员、岗位分工、管理制度与规范等。一般来说，第一步建立DevSecOps管理机制与第二步开展现状调研评估是循序渐进、并行推进、不断细化的过程。 类似于项目管理，在DevSecOps建设规划的最初，企业高层指定一个人总体负责DevSecOps工作，由这个人去组建DevSecOps建设团队，制定调研计划，分析调研结果。再基于调研的结果之上，明确管理组织架构、人员角色分工、管理流程界定等工作。最开始建立的DevSecOps管理机制通常是建立宏观的管理机制，组织架构上仅明确一两个人专职负责DevSecOps建设及大体的分工，管理制度上明确企业在DevSecOps上的方针策略及未来战略目标，管理要求上明确组织协同、运营机制和参与DevSecOps建设中的关键周边干系人。有了这些基础，常态化的计划制定、进度跟踪、调研推进就可以开展了。等流程调研、技术路线、已有安全控制措施调研清楚了，再基于这些之上，明确新的流程如何流转、技术路线如何管控，新的安全控制措施如何嵌入等。最后，形成可落地的实施指南、操作规范、技术指引。 这样，制定出来的管理机制，才是既符合企业实际情况，又符合企业未来发展的管理要求。
2.1.2.2 开展现状调研评估
现状调研是所有IT建设规划中必不可少的一个环节，在前文中提及的中小型企业需求调研方法对大中型企业仍然适用。不同的是，在这里需要重点介绍一下现状调研的内容。
在开展现状调研时，现有流程、技术路线、安全机制是需要调研的重点。
2.1.2.2.1 调研现有流程
现有流程主要包含如下内容。
2.1.2.2.1.1 产品管理流程
当前的产品管理流程是什么样的，产品形态是如何定义的，尤其是产品迭代演进与版本控制是如何做的，产品管理过程中的关键评审是否开展，是否有信息化系统承载。
2.1.2.2.1.2 研发管理流程
当前软件研发管理模型是什么样的，如使用敏捷模式还是使用瀑布模式，需求管理、架构设计、代码开发、测试管理、版本发布的流程分别的什么样的，有哪些角色参与其中，有哪些底线型的要求和标准被用来管理研发过程，是否工具与流程融合等。
2.1.2.2.1.3 运维管理流程
现在运维管理是否有标准的流程，使用哪些工具，当前自动化程度如何，最常见的安全问题有哪些，有哪些痛点需要解决等。
除了上述三个关键的流程之外，根据企业研发组织或职能的不同，还有质量管理、项目管理、技术管理等流程，需要根据实际情况，有选择性地去做调研。
2.1.2.2.2 调研现有技术
现有技术需要调研的内容主要包含
2.1.2.2.2.1 技术路线
当前的技术路线选型有哪些，都有哪些版本，分别在哪些关键业务上使用。针对技术路线的使用和分布，最好能形成清单。
2.1.2.2.2.2 依赖组件
主要是指当前在使用的技术路线所涉及的依赖库，针对这些依赖库的来源如何管理的，是否有公共的依赖库。版本升级时，是否有统一的可信仓库，如内部可信的yum源。
2.1.2.2.2.3 镜像管理
是否有统一的镜像管理流程或系统，镜像的质量管控是什么角色在做，镜像与实例的致性如何去审核的，镜像的更新发布流程是什么样的等。
现有技术的调研非常关键，它是DevSecOps规划中做出技术决策的依据。例如，未来在DevSecOps平台要做自动化部署，当前运维工具是Ansible还是Puppet，这将直接影响DevSecOps的规划决策。调研时，要根据了解到的情况，实时地调整调研范围，以期获得更精准的信息。
2.1.2.2.3 调研现在安全机制
现有安全机制需要调研的内容对安全人员来说相对比较熟悉，主要有:
2.1.2.2.3.1 安全卡点
当前安全卡点与流程是如何融合的，都有哪些卡点，分别在哪些流程的哪些环节中，卡点的输入输出是什么，数据是如何闭环的。
2.1.2.2.3.2 安全工具
当前已有的安全工具有哪些，都是谁在使用，使用效果如何，存在哪些问题需要优化。
当现有流程、现有技术、现有安全机制这三块内容调研清楚之后，接下来的后续措施、急需解决问题的优先级也就清楚了。同时，基于调研的结果持续对之前的DevSecOps管理机制进行优化，明确整体的DevSecOps流程，参与DevSecOps各角色及其分工，细化操作手册和实施指南，制定执行文件模板 等。
开展现状调研是做好DevSecOps规划，安全融入现有流程的基础，这一步不可以省略。
2.1.2.3 实施DevSecOps安全建设
调研完之后，即可以开始DevSecOps建设规划，考虑如何推进DevSecOps在业务中的落地。在整个建设规划的内容中，有三个事项需要和读者重点讨论。
2.1.2.3.1 赋能培训
首先要介绍的是赋能培训。在第一步已明确的DevSecOps管理机制通过第二步的深入调研后得到优化。常规状态下，此时的体系文件基本形成，为了便于后续的落地实施，需要在企业内部开展多轮安全赋能培训。
2.1.2.3.1.1 培训内容说明
DevSecOps组织架构与分工、战略规划、实施指南是需要和全员同步的，需要让参与DevSecOps建设的各个角色了解哪些人、哪些岗位需要参与其中，实施指南如何使用，存放在IT信息化系统的什么位置，如何获取，DevSecOps建设未来不同阶段的大体演进是什么样子的。
2.1.2.3.1.2 培训管理人员
针对研发管理人员，需要通过培训让其深入理解当前的DevSecOps流程设计，流程上有哪些关键卡点，这些卡点对原有的流程或交付会产生什么样的影响，他们需要关注哪些数据，从管理角度是如何考核这些研发管理者的。
2.1.2.3.1.3 培训技术人员
对于研发技术人员，需要通过培训让其了解平台规划的节奏和平台已有功能的使用变化对他们的考核指标有哪些，帮助文档在什么位置，帮助渠道有哪些，如何获取帮助等。
2.1.2.3.1.4 培训运维人员
对于运维人员，需要通过培训让其了解运维流程如何与DevSecOps平台融合，依赖库、镜像库如何管理、如何更新，运维人员如何获取或更新这些库中的组件或镜像。
只有这些参与其中的角色把整体流程了解清楚了，各方利益相关的指标了解清楚了，操作规则掌握了，后续的工作才好推动；否则，在推动的过程中，也会返工，重新开展安全赋能培训的工作。
2.1.2.3.2 DevSecOps平台建设
接着来介绍DevSecOps平台建设。DevSecOps平台建设是本书的重点，规划设计者可以详细阅读后续章节内容来了解其中技术细节，再结合实际情况做出合适的规划。
2.1.2.3.2.1 建设DevSecOps平台应遵循的策略
建设的节奏建议遵循的三个策略:同步规划，分步建设；先分段建设，再全线贯穿；先固化，再工具化，最后自动化、数据化、智能化。
2.1.2.3.2.2 DevSecOps平台是技术路线选型原则
平台建设时的技术路线选型参考我的后续文章内容，主要原则是：先选择开源产品，完成CI/CD管道的搭建，建立基础的自动化管道和流程，再逐步升级为企业版或自研替代。在决定是否采用DevSecOps时，可以先尝试使用公有云产品构建DevSecOps平台能力，然后再开源产品或自研产品，逐步构建企业私有化的DevSecOps平台能力。
2.1.2.3.2.3 DevSecOps平台构建是应关注的两个方面
在构建DevSecOps平台能力时，需要重点关注以下两个方面：一是DevSecOps的黄金管道流程编排模板，另一个是基础设施即代码的代码化模板。
- 关注DevSecOps的黄金管道流程编排模板
在设计DevSecOps的黄金管道流程编排模板时，正确的顺序的是先根据当前业务的技术路线提供一套通用的流水线模板(如Java语言的Maven构建模板)，再根据不同的业务特点，构建其他的流水线模板(如Node.js流水线模板、Spring+Tomcat流水线模板)。只有这样的模板越多，平台用户使用起来就越方便，效率也越高，平台运营也越轻松。
- 关注基础设施即代码的代码化模板
基础设施即代码跟自动化运维、安全策略代码化、安全基线自动化是相关联的。如果配置管理工具不成熟，技术路线选型不够收敛，部署方式、部署路径千奇百怪，则自动化工作将很难。所以，在规划时，需要根据调研的结果，看未来运维侧的变化，制定切合实际的DevSecOps建设规划。
2.1.2.3.3 落地管控措施
最后介绍落地管控措施。落地管控措施是为了配合DevSecOps在各业务、各部门的落地而制定的管理策略和推广策略，是为了加快DevSecOps推进速度，保障DevSecOps管理策略在执行层面不打折扣而制定的。一般来说，这些落地策略与建设计划是相配套的。例如，在没有持续集成/持续交付平台之前，DevSecOps流程在落地层面该如何设置，覆盖的范围大概有哪些，推进的节奏是什么样的;等到持续集成/持续交付平台已经完成建设，DevSecOps流程在平台中如何流转，平台能力先在哪些项目试点，逐步推进的节奏是什么样的。除了落地策略与建设计划相配套之外，落地策略还需要与研发侧达成共识。DevSecOps落地是需要其他部门配合的，光靠安全部门无法完成，所以落地策略本身和策略的推进节奏都需要与周边部门达成共识，比较好的做法是，与周边部门的节奏保持一致，在周边部门的工作基础之上同节奏推动DevSecOps落地。
2.1.2.4 审计与监督
审计与监督工作是DevSecOps建设和落地的组织级保障，通常与企业的组织运转模式相结合的。
2.1.2.4.1 绩效考核的制定
这其中典型的就是绩效考核，即考核方式和KPI指标如何制定，制定之后哪些人来完成这些指标，高层级的指标如何向低层级拆解。指标的周期性进展谁去跟踪，过程数据谁去采集，出了问题如何考核，谁去考核。这些想清楚了，审计与监督的工作基本也理清楚了。
2.1.2.4.2 研发组织内部评比
除了绩效考核的数据之外，很多时候或场景达不到绩效考核的标准，这时可以采用数据晾晒的方式促进研发组织内部评比。例如，通过审计手段来收集DevSecOps落地过程中产生的过程数据，通过对这些过程数据的分析对结果进行排名，并在一定层面上公开数据晾晒，暴露已发现的问题，推动外部部门及时调整并修正，以保证多个组织都向着既定目标推进。
好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
4697
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
