书名：978-7-115-60113-1
ISBN：DevSecOps企业级实践：理念、技术与案例
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 陈能技
责任编辑 孙喆思
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
DevSecOps在DevOps的基础上融入安全底线思维，是软件工程领域的前沿理论。本书系统地阐述企业实践DevSecOps所需的理论、技术和方法，首先从软件工程发展趋势，尤其是敏捷、DevOps等领域的发展趋势出发，结合DevOps实践、DevSecOps相关报告和标准，循序渐进地阐述DevSecOps理念；然后解读DevSecOps最佳实践，根据DevSecOps最佳实践涉及的重点阶段和相关技术讲解平台设计与工具应用，并结合开源、云原生等领域的流行工具介绍DevSecOps工具链及平台建设方法；最后以作者的实战经验和业界的实践案例介绍DevSecOps的实施方法。
本书适合有DevSecOps转型需求的国内IT从业人员阅读，包括项目管理、开发、测试、运营、安全等相关工作的IT从业人员，同时也适合作为IT培训机构和高校教授先进软件工程理论及开发运营模式的教材。
我们正处于“VUCA”[不稳定（volatile）、不确定（uncertain）、复杂（complex）和模糊（ambiguous）]时代，企业也处于一个易变、不确定、复杂、模糊的环境。在这样的环境下，IT在企业数字化转型过程中发挥着越来越重要的作用，越来越多的企业开始拥抱敏捷，拥抱DevOps。“没有网络安全就没有国家安全”，我国近几年陆续出台了《中华人民共和国网络安全法》《中华人民共和国密码法》《中华人民共和国数据安全法》等安全方面的法律法规。随着国家对安全越来越重视，DevSecOps应运而生。
DevSecOps思想源自DevOps但超越了DevOps，它凝聚了国内外软件工程领域专家多年来的探索和实践精华，代表了IT领域最新的发展趋势。它在DevOps的基础上融入安全底线思维，企业采纳DevSecOps方法和相关技术是符合数字化发展趋势和安全合规要求的。
本书从DevSecOps基础、DevSecOps最佳实践、DevSecOps平台设计与工具应用以及DevSecOps相关的实践案例等方面，系统地阐述了企业采纳DevSecOps实践所需的理论、技术与方法。
在本书的写作过程中，我得到了中国信息通信研究院（简称信通院）、极狐信息技术有限公司（简称极狐GitLab）和开源GitOps产业联盟（简称OGA）的大力支持。本书关于DevSecOps领域发展趋势的内容，很多数据来源于信通院和极狐 GitLab 发布的调研报告和白皮书。在介绍DevSecOps相关的理论框架时，我参考了很多信通院发布的相关标准和成熟度模型，在此感谢信通院郭雪、吴江伟等领导对本书出版做出的贡献。信通院在云原生、DevOps、DevSecOps等领域牵头制定了相关标准和白皮书，为产业发展做出了很大的贡献。
本书关于DevSecOps平台设计与工具应用的内容，极狐GitLab提供了不少参考素材，在此感谢极狐GitLab公司的陈悦、张扬、彭亮和刘峰对本书出版做出的贡献。GitLab是业界广泛采纳的DevOps工具，常用于构建企业工具链。在本书定稿之际，恰逢极狐GitLab公司获得A轮融资，在此表示祝贺，并对他们联合云原生计算基金会、信通院成立 OGA 以及在推动中国开源DevOps生态建设方面做出的贡献表示感谢。
本书关于安全架构、入侵与攻击模拟等新技术领域的内容，我参考了好朋友霍光先生的公众号文章中的相关内容。霍光先生是一位安全界的老兵，他一直在关注国外最新的安全技术趋势和动态，经常给我很多启发。在此感谢他对本书出版做出的贡献，以及在安全技术研究方面的持续努力。
本书关于网络安全网格架构的内容得到了云帧公司的袁桥老师的支持。袁桥老师是国内第一个完整深入理解Gartner提出的网络安全网格架构（CSMA）趋势并创新性地基于流量微探针UniProbe实现CSMA的人。在此感谢他对本书出版做出的贡献，以及在安全技术研究方面的持续努力。
本书的写作得到了 OGA 的大力支持，写作之初成立了本书编委会，编委会成员郭雪、吴江伟、陈悦、张扬、彭亮、刘峰、刘则、陈贺等人在各自的领域都耕耘多年，他们为本书提供了写作素材、内容修改建议，在此向他们表示衷心的感谢。
在本书出版过程中，极狐GitLab公司陈悦、罗天璐等人付出了大量的时间与精力，做了很多资源协调和后勤保障等方面的工作，人民邮电出版社编辑孙喆思及其同事在书稿的编辑处理等方面付出了大量时间与精力，在此向他们表示衷心的感谢。
本书提供如下资源：
● 本书思维导图；
● 异步社区7天VIP会员。
要获得以上资源，您可以扫描下方二维码，根据指引领取。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区（https://www.epubit.com/），按书名搜索，进入本书页面，点击“发表勘误”，输入勘误信息，点击“提交勘误”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给本书的责任编辑（sunzhesi@ptpress.com.cn）。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”（www.epubit.com）是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者在线交流互动，以及传统出版与数字出版的融合发展。
“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域多年的发展与积淀。异步图书面向IT行业以及各行业使用IT技术的用户。
DevSecOps是开发、安全和运营的一体化，是DevOps概念的延展和理念的提升。为了更好理解DevSecOps，我们首先应该理解DevOps的含义。
DevOps起源于开发和运营的融合，通过合并开发与运营实战，消除隔离，让团队统一关注点，聚集于提升产品交付的效能，是一种新型的软件生产与交付的协作方式。
软件行业的发展至今不足百年的时间，相比传统行业，尤其是工业，成熟度还不算高。软件工程的学者和从业人员一直在摸索成熟的行业解决方案，从早年的软件质量工程、能力成熟度模型集成（Capability Maturity Model Integration，CMMI）到前几年流行的敏捷、精益等方法，无不在尝试解决软件行业的诸多痛点，但是效果不是很理想，这印证了Fred Brooks所说的“没有银弹”。Fred Brooks在 1987 年发表的一篇关于软件工程的经典论文“No Silver Bullet—Essence and Accidents of Software Engineering”，该论文强调真正的“银弹”并不存在，而所谓的“没有银弹”是指没有任何一项技术或方法可以让软件生产力在10年内提高10倍。
Brooks的理念触碰了软件行业的本质问题之一：软件工程的生产力。生产力是衡量某行业发展水平的重要指标，观察当今软件行业的发展水平，生产力低下，生产过程为手工作坊模式。例如，某移动运营商客户的业务运营支持系统（Business & Operation Support System，BOSS）因为系统规模庞大、业务逻辑复杂、业务流程关联性强、业务操作步骤多，致使新需求无法快速、高效、准确地得到满足，往往一个需求需要经过2～3个月的开发才能上线。而软件行业衍生出所谓的“外包行业”存在价格无序竞争和管理混乱等问题，导致软件的生产力水平低下。
DevOps思想可以说是敏捷开发思想的延伸和扩展，接下来我们来回顾一下敏捷开发思想的发展历程，以便更好地理解DevOps和软件工厂的理念。
谈敏捷开发思想就不得不谈瀑布模型。瀑布模型的问题在于，它假设项目只经历一个过程，而且架构是优秀且易于使用的，设计是合理可靠的，编码实现在测试过程中是可以随时修改和调整的。换句话说，瀑布模型假设错误全发生在编码实现阶段，因此在单元测试和系统测试中修复代码缺陷很容易。瀑布模型的价值交付方式如图 1-1 所示，在系统验证完成之前，瀑布模型的价值交付是基本处于不可用状态的半成品，对最终用户而言价值为零，无法及时反馈。随着时间的推移，在整体系统交付客户的阶段才体现出可用价值，但是往往在这个阶段会暴露出很多前期阶段隐藏的问题和缺陷，这些问题和缺陷很难在后期阶段进行更改，尤其是需求、架构层面的问题和缺陷。
图1-1 瀑布模型的价值交付方式
从项目管理的角度来看，它将各种工作角色隔绝，人们无法看到各个职责之间的关联性，更侧重于将工作扔到“瀑布”下游团队。因此，各个团队更像“我们与他们”式的独立团队，这带来的结果就是，“现在的”工作是“我们的”，“以后的”工作是“他们的”。
2007年，比利时的独立IT咨询师Patrick Debois开始注意开发团队和运营团队之间的问题。当时，他参与了比利时一个政府下属部门的大型数据中心迁移项目，在这个项目中，他负责测试和验证工作，他既要和开发人员一起工作，还要和运营人员一起工作。他第一天在开发团队要保持敏捷的节奏，第二天又要以传统的方式维护这些系统，这种工作环境的切换令他十分沮丧。他意识到开发团队和运营团队的工作方式和思维方式有巨大的差异：开发团队和运营团队处于不同的工作模式和环境，又坚守着各自的利益，所以同时在这两种环境下工作经常经历各种冲突。作为一个敏捷的拥趸，他逐渐明白了如何改进自己的工作。
2008年6月，O'Reilly公司举办了首届Velocity技术大会，这次大会主要围绕Web应用的性能和运营展开，分享在构建和运营Web应用时提升其性能、稳定性和可用性上的最佳实践。大会吸引了来自Austin的几个系统管理员和开发人员，他们对大会中分享的内容十分感兴趣，因此记录下了所有的演讲内容，并分享到一个名为The Agile Admin的博客上，博客内容以敏捷在系统管理工作中的应用为主。同年8月，Patrick在Agile Conference 2008上结识了Andrew Shafer，他们一起建立了一个名为Agile System Administration的谷歌讨论组。这个阶段可以认为是DevOps在业界的思潮萌芽阶段。
2009年6月，在第二届Velocity技术大会上，来自Flickr的John Allspaw和Paul Hammond一起做了一个题为“10+ Deploys Per Day：Dev and Ops Cooperation at Flickr”的演讲，用Flickr的实践证明了Dev和Ops可以有效地协同工作，共同提升软件交付的效能。Patrick Debois受此大会的启发，发起了名为DevOpsDays的会议，会议很成功，业界持续讨论相关话题。由于推特有字符数的限制，因此大家就把推特上的话题#DevOpsDays简写成了#DevOps，于是DevOps一词便在社区中慢慢传播开了。这个阶段可以认为是DevOps在业界的崭露头角阶段。
关于DevOps相关的方法、技术和实践，可以参考笔者编著的《大规模组织DevOps实践》一书。
在理解了软件工程实践方法从瀑布到敏捷、DevOps的发展之后，我们来看看DevOps实践方法的3个原则和5个理念。
在DevOps领域开创性的著作《DevOps实践指南》中，合著者Gene Kim、Jez Humble、Patrick Debois和John Willis描述了支撑DevOps的3个原则。他们通过研究制造行业内成功的生产线和软件开发的最佳实践，为软件工程行业建立了这些原则。
● 第一个原则是使用从左到右的流程流。在这一原则下，构成高效率流程的重点是将代码审查、单元测试、自动化测试等质量保障手段集成到部署流水线中，从而降低交付版本的风险。
● 第二个原则是使用从右到左的反馈机制，允许开发人员和运营人员预测和解决问题，而不是等待问题在生产环境中发生。
● 第三个原则是提供一个持续学习和实验的环境，允许开发人员和运营人员不断改进开发和运营，作为流程的一个嵌入部分。
在《DevOps实践指南》发布之后，Gene Kim的《独角兽项目：数字化转型时代的开发传奇》将DevOps的原则扩展为5个共同定义DevOps核心价值的理念。
● 第一个理念是DevOps团队具有局部性和简单性。为了能够独立地为客户构建、测试和部署价值，DevOps团队需要避免依赖大量其他团队、人员和流程。每个DevOps团队都可以做出自己的决定，而无须其他人的批准。DevOps促进了组件的解耦以简化开发和测试，并建议将数据实时提供给需要数据的人以高效完成任务。
● 第二个理念是DevOps团队必须专注、流畅和快乐。这意味着他们必须摆脱阻碍他们完成任务能力的限制：同时从事多项活动或在从事一项活动时受到多次干扰。受到这种限制的个人不太可能达到高标准，如果团队能够不受干扰地专注于个人行动，他们就会从流畅的工作中获得快乐。这有助于团队为客户创造价值。
● 第三个理念是DevOps团队应改善日常工作。这一理念侧重于减少技术债务，包括安全漏洞。技术债务如果得不到解决，将会增加到让大多数或所有日常工作都围绕它来交付功能、修复缺陷和减轻风险的程度。因此，团队日常工作的很大一部分必须涉及投资开发人员的生产力和减少技术债务。在《DevOps实践指南》中，Gene Kim确定了4种类型的工作：业务相关的（如创建新功能）、IT、基础设施改进和计划外工作。计划外工作会分散团队的注意力，并表现为大量的技术债务。
● 第四个理念是DevOps团队不应该害怕开放和诚实。这是心理安全的本质，与其发展出一种“责备、重名誉和羞耻”的团队文化，不如让个人能够直言不讳，且不必担心受到影响。在DevOps团队中加强开放文化很重要，这样问题一旦出现，就会暴露并被修复。
● 第五个理念是DevOps团队应以客户为中心。DevOps团队有两种类型的客户：外部（从交付给他们的功能中受益的付费客户）和内部（在价值流中承接前者交付物的下游个人或团队，例如运维人员就是开发人员和测试人员的下游）。通过关注输出的直接消费者，有更多的机会获得即时反馈，从而带来更好的客户体验。
DevOps不是某个作者或专家想象出来的管理框架或产品，而是诞生于解决实际问题的过程。目前，不同组织应用DevOps试图解决的问题主要有3类：缩短市场响应时间、减少技术债务和消除系统脆弱性。
传统IT部门遵循“为成本而优化（optimize for cost）”的模式，而DevOps组织遵循“为速度而优化（optimize for speed）”的模式，具体包括减少批量大小、减少交接次数、持续识别和消除损失、自动化所有例行的运维工作、实现团队内部专业人员可替换、拥有自给自足的团队，其中自给自足的团队包含产品人员、开发人员、测试人员、运维人员、安全人员等，即上线产品不需要依赖外部团队。
技术债务是在团队成员选择一个非最优的方案来解决问题以缩短开发时间时产生的。这是一个自然的过程，问题是累积的非最优方案将导致IT产出逐步退化，从而导致产品质量降低。
DevOps追求持续重构程序代码，重视在操作中取得的经验以及与构造新功能同等重要的、用来消除之前所造成的瓶颈的工作。DevOps强烈推荐“尽可能频繁地直面问题”，以防出现这样一种情况：每个人都知道问题就在那儿，却没有人着手去处理。
在组织中，与业务收益相关的最重要的系统往往是最脆弱的。由于业务中断的风险高，系统对停机零容忍，以及持续发生的变更和改进与这些系统关联紧密，因此降低这些系统的脆弱性非常困难。
DevOps以一种激进的方式反对脆弱性：完全消除。在DevOps中，代码和系统作为一个整体，在某个时刻是全功能的，如果接下来的变更破坏了性能，就要马上回滚并让系统恢复正确工作。DevOps的实践会有意地将混乱和不稳定因素引入生产环境，目标IT系统必须以独立和快速的方式做出反应，探测到故障并恢复系统的正常运作，在理想情况下用户是无感知的，当然也不会丢失数据。
在了解了DevOps的实践方法和价值之后，我们来看下DevOps近几年的发展情况和趋势。
根据中国信息通信研究院（简称信通院）发布的《中国DevOps现状调查报告（2021年）》（受访企业以互联网企业、金融企业、运营商等为主），我们可以发现如下信息。
中国企业DevOps落地实践成熟度向全面级继续扩张。调查结果显示，目前成熟度处于全面级的企业占35.40%，同比增长8.84%；16.53%的企业成熟度处于优秀级；0.87%的企业成熟度处于卓越级。
超八成企业已在不同程度上实践敏捷开发，同比增长近三成。调查结果显示，在采用DevOps的企业中，32.24%的企业已经使用敏捷开发了一段时间；28.82%的企业已有一半以上的团队具备较高水平的敏捷开发能力；22.04%的企业的所有团队已经熟练掌握敏捷开发。
超六成企业能够在项目过程中实现调整需求顺序或置换需求。调查结果显示，36.88%的企业在项目过程中可以定期调整需求顺序和置换需求；15.95%的企业在项目全程随时可以调整需求顺序和置换需求，并实现全过程可视化管理。
企业广泛采用实体化敏捷团队，并以持续交付更多业务价值为发展方向。调查结果显示，超七成企业具有实体化敏捷团队，同比增长两成。
Sprint迭代成为继发布计划、看板/任务板、每日站会之后第四位应用超半数的敏捷管理实践。调查结果显示，Sprint迭代、发布计划、看板/任务板、每日站会这4位应用占比分别为51.38%、67.01%、66.14%和62.43%，而2020年的应用占比分别为40.47%、60.06%、52.96%和57.91%，普及程度明显提高。
超半数企业培训或实践过Scrum和看板敏捷管理理论。调查结果显示，培训或实践过Scrum和看板敏捷管理理论的企业占比分别为53.88%和50.00%。
持续集成是最受欢迎的敏捷工程实践，与自动构建、单元测试、持续部署一起占据敏捷工程实践的前四。这4种敏捷工程实践在所调查的企业中的采用占比分别为85.16%、81.61%、81.53%和80.66%
企业重视采用需求和项目管理工具、协作工具以及文档知识库工具提升开发效率与质量。调查结果显示，在需求和项目管理工具方面，49.67%的企业使用Jira；在协作工具方面，52.24%的企业使用微信，45.96%的企业使用钉钉；在文档、知识库工具方面，31.34%的企业使用Confluence。
多数企业将源代码、应用配置、构建和部署自动化脚本均纳入版本控制系统进行统一管理。调查结果显示，31.81%的企业将源代码、应用配置、构建和部署自动化脚本均纳入版本控制系统；23.43%的企业将源代码、应用配置、构建和部署自动化脚本、数据变更脚本、环境配置等均纳入版本控制系统；仅有2.32%的企业将源代码分散在本地自行管理。
近九成企业将构建产物纳入统一制品库进行规范管理，同比增长一成，并且企业对制品晋级管理关注度上升。调查结果显示，26.05%的企业将构建产物以唯一版本号纳入统一制品库进行规范化管理；30.62%的企业将构建产物、构建依赖组件等所有交付制品纳入统一制品库进行规范化管理；17.14%的企业将所有交付制品纳入统一制品库进行规范化管理，并且实现制品晋级管理；13.55%的企业将所有交付制品纳入统一制品库，实现制品晋级管理，并且具有完善的开源合规的制品管理。
大部分企业的变更管理过程逐渐清晰，但是具备统一的工作项管理系统的企业仅三成，这导致企业变更过程可视化和全过程数据分析能力不足。调查结果显示，30.71%的企业已建立代码基线，有统一的工作项管理；29.02%的企业所有代码变更均关联工作项；19.29%的企业已使用统一的工作项管理系统并贯穿软件生命周期；10.09%的企业已支持可视化变更生命周期和全程数据分析管理。
企业自动化构建能力普及，提交即构建采用率为66.30%。调查结果显示，14.57%的企业已实现代码提交自动触发构建，不同分支的代码构建频率可根据团队需要自定义调整；31.13%的企业实现代码提交自动触发构建，且按需制定构建计划，团队可自定义调整；20.60%的企业仅实现代码提交自动触发构建。
企业自动化构建能力进步升级可以推动企业构建频率提升。调查结果显示，在采用人工构建的企业中，75.12%的企业构建频率为不定期执行构建，构建周期长；在采用脚本实现自动化构建的企业中，25.59%的企业能够实现每日自动构建，构建周期明显缩短；在支持多种构建方式、持续优化构建服务平台的企业中，62.41%的企业具备代码提交自动触发构建、不同分支的代码构建频率根据团队需要自定义调整的能力。
企业持续集成平台自服务化，助力组织级交付能力提升。调查结果显示，19.03%的企业有专门的持续集成团队负责维护持续集成平台；24.67%的企业实现持续集成平台自服务化；而31.18%的企业已经在此基础上提升组织级交付能力，实现能够持续优化和改进团队的持续集成服务。
近三成企业已实现每天多次向代码主干集成，较去年增长10%。调查结果显示，27.74%的企业每天多次向代码主干集成，即可按需集成；23.89%的企业任何变更（代码、配置或环境）都会触发完整的持续集成流程；20.97%的企业每天至少一次向代码主干集成。
软件质量被企业持续关注，持续集成问题普遍在1天内完成修复。调查结果显示，近九成企业能在1天内修复持续集成问题，其中，25.78%的企业一般能在半天到1天内修复持续集成问题；25.49%的企业能在半天内完成修复持续集成问题；22.22%的企业能在半小时内完成修复持续集成问题；10.09%的企业能在10分钟内修复持续集成问题。
近七成企业的团队已实现代码扫描、单元测试和接口测试自动化，但模糊测试、混沌测试和全链路测试等仍待提升。调查结果显示，68.79%的企业实现了代码扫描自动化；68.50%的企业实现了单元测试自动化；64.29%的企业实现了接口测试自动化。
测试阶段持续左移，越来越多的企业使用单元测试，并且接口/服务级测试覆盖率高。调查结果显示，26.34%的企业以单元测试为主，接口/服务级测试覆盖率高；24.31%的企业的接口/服务级测试在接口开发完成后进行；20.13%的企业测试在开发前介入，代码级和接口/服务级测试均在代码开发时同步进行。
虚拟机和容器技术被广泛应用。调查结果显示，超过八成的企业使用了虚拟机和容器技术，同比增长约5%。
近五成企业实现部署发布自服务化。调查结果显示，45.46%的企业实现部署发布自服务化，仅有3.78%的企业人工完成所有环境的部署。
超七成企业的持续交付流水线包括构建、部署和测试等多个环节。调查结果显示，43.65%的企业的持续交付流水线中包括自动化构建、部署、测试等环节；另外，17.23%的企业的持续交付流水线可以直通生产环境；14.57%的企业在此基础上实现了智能调度，并持续优化。
近五成的企业变更前置时间小于1周。调查结果显示，7.99%的企业变更前置时间小于1小时；11.55%的企业变更前置时间为1小时到1天；21.28%的企业变更前置时间为1天到1周。
部署频率为1周到1个月一次的企业占比超六成，同比增长近一成。调查结果显示，6.19%的企业平均1天到1周在生产环境部署一次；28.25%的企业平均1周到2周在生产环境部署一次；32.90%的企业平均2周到1个月在生产环境部署一次。
GitLab、Maven、Jenkins和Docker是实践较广泛的持续交付工具。调查结果显示，这4种工具应用占比分别为53.45%、59.33%、64.20%和55.48%。
企业监控管理趋于完备，自动化、智能化决策能力亟待增强。调查结果显示，超过八成的企业具备全面的监控管理能力，监控已覆盖至系统、应用与接口日志等；仅二成的企业实现了监控告警平台的智能化与自动化决策。
近七成企业实现统一的标准化的监控数据采集管理，部分具备数据采集传输保障及智能化分析运维全生命周期数据的能力。调查结果显示，仅有19.48%的企业的数据监控管理现状是分散的；34.25%的企业具有统一的标准化的监控数据采集、存储及应用；17.44%的企业具备监控大数据的基础运维能力；12.12%的企业具备用智能化技术分析运维全生命周期数据的能力。
企业持续重视事件与变更管理能力建设，可视化能力不足问题仍然突出。调查结果显示，目前占比最多的是有完善的事件与变更管理流程的企业，占比 37.00%，同比增长 14.21%；23.49%的企业具备覆盖全生命周期的事件与变更管理能力，流程与场景部分实现自动化和可视化；10.55%的企业深度规范化，部分场景实现智能化技术应用。
不足四成企业具备自动化配置管理系统/平台，企业智能化配置管理和关联分析能力较弱。调查结果显示，18.77%的企业具有自动化配置管理平台；13.70%的企业具备智能识别配置对象的关联关系的能力，其配置信息能为技术运营活动提供决策支持；仅有 9.11%的企业具有智能化配置管理，支持场景智能生成配置对象的关联规则和提供准确的决策依据。
企业重视容量和成本管理的关联分析、柔性服务及灵活管控能力。调查结果显示，超七成企业支持全生命周期的容量和成本管理，同比增长近一成，其中35.04%的企业具有技术运营全生命周期的容量和成本管理，有规则和流程支持；25.34%的企业具备灵活管控成本的能力；15.21%的企业支持全链路的容量管理能力。
超三成企业结合监控实现自动化扩缩容的高可用管理，同比增长两成。调查结果显示，16.74%的企业能够结合监控自动扩缩容，自动梳理系统拓扑结构；20.82%的企业实现了动态扩容自动化，并采用分布式缓存、分表分库等技术，实现了同城多机房实时数据备份、异地数据备份；仅有10.68%的企业实现了全面自动化和智能化的高可用管理。
业务连续性管理能力仍待健全，半数企业恢复时间目标（Recovery Time Objective，RTO）在 99.9%以下。调查结果显示，21.99%的企业具有基础的业务影响分析与业务风险分析能力，故障恢复时间较长；29.18%的企业整体RTO达到99.9%；19.66%的企业整体RTO达到99.95%；13.70%企业整体RTO达到99.99%；仅有8.08%的企业整体RTO达到99.995%。
仍有近三成企业处于快速处理关于用户体验的投诉问题的阶段，对用户体验管理的重视程度应继续加强。调查结果显示，仍处于快速处理关于用户体验的投诉问题的阶段的企业占比26.56%，同比下降 14.52%；27.33%的企业具有端到端全链路事件埋点，提升部分场景的用户体验；9.73%的企业引入人工智能技术，建立业务领域级别的用户体验类知识图谱或专家系统。
自动化运维工具可以帮助企业更稳定、更安全和更高效地完成监控、分析和服务保障。调查结果显示，Elastic、Zabbix、Grafana、Logstash和Prometheus是较受欢迎的5种自动化运维工具，其应用占比分别为43.01%、36.58%、34.25%、30.41%和29.32%。
Spring Boot和Spring Cloud仍占据当前企业为实现微服务所选择的技术的前两席。调查结果显示，有超过四成企业使用Spring Boot或Spring Cloud实现微服务，使用Spring Boot和使用Spring Cloud的企业占比分别为54.94%和44.23%，同比分别增长23.72%和10.26%。
近七成企业应用架构由专业人士设计，仍有超两成企业应用架构按经验简单拆分成若干可独立开发和编译的功能模块。调查结果显示，19.52%的企业应用架构由专业人士设计和进行模块拆分，各模块可以通过本地进程间通信独立部署；25.95%的企业应用架构由专业人士设计，对设计质量有明确的度量流程，应用各模块通过网络进行通信、独立部署和运行；18.78%的企业应用架构由专业人士设计，能够将系统复杂度降到最低，对应用架构拆分情况形成持续反馈与改进机制。
多数企业均有接口规范和管理流程，越来越多的企业使用统一的接口开发与管理平台。调查结果显示，仅有 1.53%的企业无接口规范和管理流程；34.33%的企业有接口规范和管理流程，并强制实施；27.69%的企业有接口规范和管理流程，使用统一的接口开发和查询平台；14.48%的企业有接口规范和管理流程，使用统一的接口开发与管理平台，并实现各个模块自动注册接口相关信息和自动校验。
超七成企业的应用可实现不同程度的自动扩缩容，部分企业能够根据系统部分特征自动生成扩缩容策略。调查结果显示，24.90%的企业可人工修改应用部署配置，由系统实现应用的自动扩缩容；根据应用的部分特征指标自动生成扩缩容策略、采用自动化方式进行扩缩容的企业占比28.51%，同比增长6.42%；具有多维度自动扩缩容策略、采用自动化方式按需进行扩缩容占比20.03%，同比增长6.20%。
企业重视应用故障修复能力建设，超六成企业具有统一的故障修复平台。调查结果显示，31.00%的企业有统一的日志规范、统一的故障修复平台，可利用工具辅助分析故障；18.22%的企业的应用日志支持全链路追踪，单个应用系统可自动处理部分故障，同比增长6.87%；12.81%的企业的应用日志支持图形化展示全链路追踪信息，实现了自动预警、故障定位和故障自动修复。
超六成企业实现了对整体应用性能管理的优化设计。调查结果显示，33.78%的企业对整体应用性能进行了系统化的、全方位的设计；15.30%的企业支持性能循环管理，建立了制度化的性能设计流程；12.39%的企业建立了完善的性能设计流程，并支持对性能指标的自动化实时分析。
五成以上的企业尝试实践DevSecOps。调查结果显示，53%的企业引入了DevSecOps。
企业关注安全能力建设，近五成的企业有专业安全团队，较去年增长一成。调查结果显示，42.48%的企业具有专门的安全管理团队与安全主管，其中23.01%的企业具有高级别的安全管理组织及不同方向的安全专家团队，仅有13.63%的企业具有对行业作出突出贡献与业界影响力较大的安全专家团队。
企业关注代码安全性、安全测试与漏洞扫描、第三方开源库的安全性、设计符合安全标准和规范等方面的安全内容，外部威胁与攻击、个人信息保护也受到企业重视。调查结果显示，关注代码安全性（76.46%）、安全测试与漏洞扫描（73.10%）、第三方开源库的安全性（66.73%）、设计是否符合安全标准和规范（64.25%）、数据安全（63.89%）、需求是否包括安全相关需求（59.65%）、安全监控（57.88%）、外部威胁与攻击（56.64%）以及个人信息保护（54.51%）这 9 个方面的安全内容的企业均超过半数。
企业自动化安全测试持续向全流程覆盖演进，可帮助企业尽早发现问题，避免安全风险。调查结果显示，55.09%的企业在代码开发阶段添加了自动化安全测试，同比增长14.51%；50.79%的企业在构建与集成阶段引入自动化安全测试，同比增长10.79%；49.66%的企业在质量保证（Quality Assurance，QA）/测试阶段引入自动化安全测试；42.83%的企业能够在应用架构设计阶段就引入自动化安全测试。
源代码静态安全检测、容器镜像安全扫描和Web应用防火墙（Web Application Firewall，WAF）成为企业应用较广泛的DevSecOps技术实践。调查结果显示，这3种DevSecOps技术实践具体应用占比为52.57%、44.25%和42.30%。
半数企业具有完善的数据安全管理要求和流程，但自动化、智能化地识别、预测和处置数据安全风险的能力不足。调查结果显示，26.59%的企业具有数据安全管理要求和数据安全管控机制；34.43%的企业具有完善的数据安全管理要求和流程，可对数据进行全生命周期安全管理，并具有自动化数据安全管理工具。
九成以上企业在软件开发过程中进行安全需求管理，但企业的自动化管理能力和智能化威胁建模能力亟待提升。调查结果显示，27.35%的企业进行安全需求分析和安全设计评审；22.65%的企业具有完善的威胁建模分析方法；24.29%的企业对安全需求进行自动化管理，具有标准化的威胁建模方法和工具以及标准化安全功能组件；21.63%的企业在软件开发过程中的安全管理具备智能化能力；仅有4.08%的企业在软件开发过程中无安全管理。
超六成企业具有完善的安全测试工具链，并实现对源代码、依赖组件及配置的安全管理。调查结果显示，26.86%的企业具有完善的安全测试工具链，并部分集成到流水线，安全测试结果可自动化展示；23.11%的企业持续集成/持续交付（Continuous Integration/Continuous Delivery，CI/CD）流水线中自动化集成较完善的安全测试工具，具有集中的漏洞管理平台；16.48%的企业将安全管理纳入开发交付全过程，并具有智能化的全过程安全交付平台。
企业重视对安全运营监控平台的建设，但智能化运营安全风控平台的感知、决策及处置能力不足。调查结果显示，29.84%的企业具有安全运营中心（Security Operation Center，SOC），具备完善的情报监测、威胁发现、告警及应急响应流程；25.42%的企业具有安全监控及告警管理平台，定期进行安全扫描和漏洞修复；16.53%的企业具有智能化运营安全风险管控平台，可智能化感知、决策和处置运营过程风险等。
安全工具百花齐放，其中代码安全工具、主机安全工具及Web安全工具等应用较广，容器安全、交互式应用安全测试和网络流量分析技术等应用率较低。调查结果显示，代码安全工具Coverity、主机安全工具绿盟、代码安全工具Fortify以及Web安全工具AppScan是企业应用最为广泛的4种安全工具，占比分别为32.74%、31.86%、23.36%和23.36%。
尽管DevOps包含IT领域的大量技术和方法，但是它更多是一种协作文化和企业管理的理念和思路，也正因如此，DevOps的应用框架不是一成不变的，它会随着技术和工具的发展而不断革新，不断适应新的软件开发环境和市场需求。整体来看，未来DevOps应用发展将呈现自动化、数据化、一体化、智能化四大趋势。这四大趋势分别对应目前软件开发和运营领域人工参与较多、量化指标不够清晰、开发运营链条有待完善和智能化程度尚待提高这4个主要问题。DevOps应用的最终目标是最大限度地减少人对无意义、重复工作的参与并提高软件开发和运营工作的有效性。
● 自动化。尽管自动化的开发和运营流程在我国已经过多年沉淀，但目前IT部门仍有大量的任务是通过人工完成的，这加大了出错的可能。DevOps在未来将通过与机器人流程自动化（Robotic Process Automation，RPA）相结合，进一步提高开发运营效率。
● 数据化。随着DevOps工具的自动化升级，企业将能够从软件开发和运营过程中收集到更多一线数据，然后通过整理和分析生成指导未来IT工作的有效信息，形成“开发—数据—开发效能提升”的工作闭环。
● 一体化。一体化的DevOps平台和统一标准的工作流更加符合IT从业人员的提效需求。目前在软件开发和运营市场以及相关领域的开源社区中已经存在大量获得广泛认可的工具，然而这些工具在过程衔接和平台适配方面还有很大的提升空间。
● 智能化。目前人工智能在诸多领域的应用都体现出显著的人工替代效能，即利用机器替代重复性的工作，这与DevOps在软件工程领域的目标高度一致。人工智能在DevOps领域的运营将进一步提升IT从业人员的工作效率和体验。
在 1.4.1 节我们提到：中国企业 DevOps 落地实践成熟度向全面级继续扩张。这离不开国内DevOps领域的标准化水平提升，本节将介绍国内DevOps领域相关的标准规范。
目前业界尚未对DevOps的规范达成一致。2013年，OASIS（Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织）推出的TOSCA（Topology and Orchestration Specification for Cloud Applications，云应用拓扑编排规范）反映了DevOps的思想。2018年，DevOps标准项目——“研发运营一体化（DevOps）能力成熟度模型”在中国通信标准化协会立项成功，信通院牵头制定和发布了总体架构、敏捷开发管理、持续交付、技术运营、应用设计等部分的标准。
DevOps能力成熟度模型覆盖端到端软件生命周期，是一套体系化的方法论、实践和标准的集合。DevOps能力成熟度模型的总体架构可划分为3部分，即过程（包括敏捷开发管理、持续交付、技术运营）、应用架构（包括应用设计、安全风险管理）和组织结构（包括评估方法、系统和工具），如图1-2所示。
图1-2 DevOps能力成熟度模型总体架构
下面介绍DevOps能力成熟度模型定义的相关内容。
（1）敏捷开发管理从需求管理、计划管理和过程管理3个维度，关注需求到开发阶段的有序迭代、灵活响应和价值的快速交付，具体如下。
● 需求管理细分为需求收集、需求分析、需求与用例以及需求验收4个方面。其中，需求收集从单个需求点、需求全貌、需求的管理、人员机制和工具能力5个维度进行评估；需求分析从需求内容与形式、需求协作、需求的管理、人员机制和工具能力5个维度进行评估；需求与用例从需求与用例编写、需求用例验证、需求与用例的管理、人员机制和工具能力5个维度进行评估；需求验收从需求验收频率、需求验收范围、需求验收反馈效率、人员机制和工具能力5个维度进行评估。
● 计划管理细分为需求澄清与拆解、故事与任务排期以及计划变更3个方面。其中，需求澄清与拆解从需求澄清的时间、内容的完备性、协作情况、人员机制和工具能力5个维度进行评估；故事与任务排期从排版要素、排版容量、排版管理、人员机制和工具能力5个维度进行评估；计划变更从变更决策、应对变更、减少变更、人员机制和工具能力5个维度进行评估。
● 过程管理细分为迭代管理、迭代活动、过程可视化及流动以及度量分析4个方面。其中，迭代管理从迭代时间周期、迭代协作机制、迭代流程改进、人员机制和工具能力5个维度进行评估；迭代活动从迭代活动约定、迭代活动时间约定、迭代活动范围、人员机制和工具能力5个维度进行评估；过程可视化及流动从过程可视化、过程价值流动、迭代过程改进、人员机制和工具能力5个维度进行评估；度量分析从度量粒度、度量范围、度量驱动持续改进、人员机制和工具能力5个维度进行评估。
（2）持续交付关注软件集成交付环节，通过配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理、度量管理领域的能力建设和工程实践，保证软件持续、顺畅、高质量地完成发布，具体如下。
● 配置管理细分为版本控制、版本可追踪性两个方面。其中，版本控制从版本控制系统、分支管理、构建产物管理、单一可信数据源4个维度进行评估；版本可追踪性从变更过程、变更追溯、变更回滚3个维度进行评估。
● 构建与持续集成细分为构建实践、持续集成两个方面。其中，构建实践从构建方式、构建环境、构建计划和构建职责4个维度进行评估；持续集成从集成服务、集成频率、集成方式和反馈周期4个维度进行评估。
● 测试管理细分为测试分级策略、代码质量管理以及测试自动化3个方面。其中，测试分级策略从分层方法、分层策略和测试时机3个维度进行评估；代码质量管理从质量规约、检查策略、检查方式和反馈处理4个维度进行评估；测试自动化从自动化设计、自动化开发、自动化执行和自动化分析4个维度进行评估。
● 部署与发布管理细分为部署与发布模式、持续部署流水线两个方面。其中，部署与发布模式从部署方式、部署活动、部署策略和部署质量4个维度进行评估；持续部署流水线从协作模式、流水线过程和过程可视化3个维度进行评估。
● 环境管理从环境类型、环境构建以及环境依赖与配置管理3个维度进行评估。
● 数据管理细分为测试数据管理、数据变更管理两个方面。其中，测试数据管理从数据来源、数据覆盖、数据独立性和数据安全4个维度进行评估；数据变更管理从变更过程、兼容回滚、版本控制和数据监控4个维度进行评估。
● 度量管理细分为度量指标、度量驱动改进两个方面。其中，度量指标从度量指标定义、度量指标类型、度量数据管理和度量指标更新4个维度进行评估；度量驱动改进从报告生成方式、报告有效性、报告覆盖范围和反馈改进4个维度进行评估。
（3）技术运营关注软件发布后的环节，涉及运营成本服务、高可用架构服务、用户体验服务、客户服务、监控服务、产品运行服务和运营数据服务，保障良好的用户体验，打造持续的业务价值反馈流。
（4）应用设计主要从API、应用性能、应用扩展、故障处理4个维度进行评估，良好设计的应用架构有助于系统解耦和灵活发布，也是高可用系统的核心能力。
（5）安全风险管理主要从控制通用风险、控制开发过程风险、控制交付过程风险、控制技术运营过程的安全风险4个维度进行评估，端到端的安全考量和全局规划，可以让安全发挥更大的价值，并真正助力全价值链。
（6）评估方法是通过各个维度的指标打分之后评价企业在DevOps成熟度方面能达到的级别，具体如下。
● 1级：初始级，在组织局部范围内开始尝试DevOps活动并获得初期效果。
● 2级：基础级，在组织较大范围内推行DevOps实践并获得局部效率提升。
● 3级：全面级，在组织内全面推行DevOps实践并贯穿软件生命周期获得整体效率提升。
● 4级：优秀级，在组织内全面落地DevOps并可按需交付用户价值达到整体效率最优化。
● 5级：卓越级，在组织内全面形成持续改进的文化并不断驱动DevOps在更大范围内取得成功。
（7）系统和工具主要从项目与开发管理、应用设计与开发、持续交付、测试管理、自动化测试、技术运营6个维度进行评估。
2020年，信通院发布了《DevOps解决方案标准》，该标准规范了DevOps解决方案平台及工具应具备的服务能力，覆盖了项目管理域、应用开发域、测试域、运营/运维域和安全能力等应用开发运营全生命周期的能力子域，其中每个子域包含数个二级模块，每个二级模块力求描述覆盖开发运营解决方案中的某个环节或工具，如图1-3所示。整个标准包含34个二级模块，共计550个能力要求项。该标准根据平台及工具满足的能力要求项，将DevOps解决方案平台及工具具备的服务能力分为3个级别：基础级、增强级和先进级。34个二级模块的描述如下。
需求管理：在开发过程中对用户需求进行管理。
任务管理：对不同开发阶段的任务进行管理。
文档管理：对架构设计、操作手册、产品说明等文档材料进行管理。
缺陷管理：对发现和解决软件生命周期内发生的缺陷的过程进行管理。
度量管理：对开发运营过程中的可执行指标进行提取和量化。
项目管理：对多个关联项目进行集中管理与协调管理。
版本迭代管理：对集成版本进行管理。
知识库：提供成员知识共享的平台，用于企业知识管理，通过可协作文档将知识积累沉淀，提高企业运营效率。
图1-3 应用开发运营全生命周期的能力子域与二级模块
集成开发环境：解决方案提供的开发环境，开发人员可以开箱即用进行应用的开发。
代码托管：为开发人员提供在线代码托管服务。
代码评审：对完成开发的代码进行评审、审批的流程。
编译构建：为开发人员提供将源代码转换为可执行程序的能力。
流水线：解决方案提供的可视化、可定制的自动化流水线编排能力。
部署发布：为应用部署提供标准化和自动化的能力以及对发布到生产环境的过程进行管理。
移动端发布管理：将客户端安装包推送到用户移动端的能力。
制品管理：管理软件源代码编译构建后的产物的能力。
用例管理：对测试过程中涉及的用例进行管理。
数据管理：对测试过程中涉及的数据进行管理。
代码扫描：对代码进行安全检查的能力，通过对代码进行质量检查，提供改进意见，保证代码开发阶段不因为代码漏洞影响整个建设。
接口测试：对API的功能、性能和安全性进行测试。
UI测试：对UI风格、通用性、准确性、美观性和易操作性进行测试。
适配测试：对应用的移动端适配性进行测试。
单元测试：对开发过程中某个模块、某个函数或某个类进行正确性检验测试。
性能测试/客户端性能测试：通过借助特定的系统或工具对客户端平台或程序进行测试。
资源管理：对应用发布运行期间所需的IT资源进行调度和管理，以保证IT资源的高效利用。
监控管理：在开发运营过程中对应用、资源、配置等不同状态进行采集、分析和可视化。
变更管理：对整个请求生命周期内的变更请求进行管理，旨在最大程度地减少因实施变更而对现有IT服务造成的不良干扰，确保使用标准化方法和步骤来处理变更。
日志管理：对开发运营过程中应用日志、业务状态日志进行收集、管理和分析。
配置管理数据库：存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相连，它支持流程的运转，发挥配置信息的价值，同时依赖于相关流程保证其数据的准确性。
故障管理：对应用发生的故障进行管理，旨在尽快恢复正常服务运营。
身份认证：对用户提供身份认证能力，便于人员安全管理。
安全审计：对与安全有关的活动和执行关键操作行为的相关信息进行识别、记录、存储和分析。
权限控制：开发运营平台可对不同用户、角色进行功能和权限的控制，对不同的租户进行资源有效隔离。
高可用：通过故障检测、数据备份等手段保障可用性。
2018年ITSS（Information Technology Service Standards，信息技术服务标准）发布了《信息技术服务开发运维技术要求》，规定了信息技术服务开发运维的技术要求，包括产品应具备的功能、应满足的性能要求以及应提供的集成接口，架构如图1-4所示。该要求适用于如下场景：
● 信息技术服务开发运维工具的开发、测试或选择；
● 评价信息技术服务组织的开发运维整体技术支撑能力；
● 可单独选择进行评价的模块，包括源代码审查、SQL审查、单元测试、持续集成、持续部署、性能测试、数据环境管理、制品库管理、接口管理等。
根据图 1-4，DevOps产品应包括持续规划、持续集成、持续部署、持续测试和持续反馈的基础功能模块，具体如下。
● 持续规划模块应通过自身实现或整合工具平台的方式具备项目管理、需求管理、开发任务管理和API管理的能力，从而达到对业务需求的变化进行持续变更管理的能力。
● 持续集成模块应通过自身实现或整合工具平台的方式具备版本管理、编译构建、代码审查和单元测试的能力。
● 持续部署模块应通过自身实现或整合工具平台的方式具备发布管理、脚本管理、制品库管理和编排调度的能力。
● 持续测试模块应通过自身实现或整合工具平台的方式具备测试管理、测试自动化的能力。
● 持续反馈模块应通过自身实现或整合工具平台的方式具备报表管理、KPI（Key Performance Indicator，关键绩效指标）管理的能力。
另外，DevOps产品还应具备用户管理、权限管理、通知管理、基础设施管理等功能。
图1-4 信息技术服务开发运维技术要求架构
DevOps产品应从架构设计的角度适当分层，如业务服务层、工具服务层、数据服务层、度量层等。业务服务层应包括如下内容：
● 应支持组件的自定义模型、组件参数输入与输出定义；
● 应支持业务链路的用户自定义组装；
● 应支持3种以上业务链路驱动策略，如定时驱动、人工驱动、变更驱动等；
● 应支持业务链路分权控制，不同的角色只能管控它所归属的业务链路信息；
● 应支持业务链路的状态、运行日志和运行结果的实时查看；
● 应支持业务链路运行记录的摘要信息查看和详细信息查询；
● 应支持业务的审核、管控；
● 应支持信息或者运行结果变更后的信息通知，至少支持一种通知方式，如电子邮件、短信、微信等；
● 应支持数据交互推送或者定时加载这两种模型；
● 宜支持业务链路的第三方API调用；
● 宜支持与管理流程结合，实现信息双向互通；
● 宜支持业务链路节点的定时模型；
● 宜支持标准化的API服务模型；
● 宜支持数据度量、自动计算和聚合；
● 宜支持业务链路的节点重置、暂停、终止、再次运行等业务操作。
工具服务层应包括如下内容：
● 应支持工具根据业务请求动态驱动；
● 应支持工具所生成的日志信息的采集；
● 应支持工具运行的状态以及结果数据的分析与采集；
● 宜支持工具的负载均衡；
● 宜支持工具热插拔模型，增加或者减少工具不会对平台架构产生任何影响；
● 宜支持日志过大而进行数据分片传输模型；
● 宜支持工具心跳服务，避免工具僵死而引发业务中断。
数据服务层应包括如下内容：
● 应支持不同的业务节点的数据独立存储；
● 应支持运行结果业务信息的关联存储；
● 应支持数据逻辑的存储；
● 应支持业务统计数据的存储；
● 应支持数据一致性的管理；
● 宜支持数据订阅服务；
● 宜支持动态数据的模型存储；
● 宜支持数据消费接口的拉取。
度量层应包括如下内容：
● 应支持不同组件架构的项目质量的度量，例如部门、产品、系统和项目的分层度量；
● 应支持整体业务链路的过程度量，例如从需求、设计、集成、部署、测试和运维整体度量；
● 应支持不同版本或者每次代码提交之间的数据横向度量，例如一个分支多次提交后的质量的度量趋势等；
● 宜支持度量问题的自动创建和自动关闭；
● 宜支持质量与人之间进行关联，支持人的行为分析，例如将质量的问题与人进行关联，分析具体的人的开发质量、代码习惯等；
● 宜支持跨项目度量分析，分析和度量企业或者不同部门之间的共性问题。
