我们将DevOps总结为面向服务的交付模式这种交付模式重点聚焦组织文化、可视化、持续交付、技术运营四方面的无偿还能力怎么执行。持续交付覆盖从提交代码到部署到生產环境的全过程技术运营覆盖生产环境等线上环境的管理过程，可视化贯穿服务交付的全过程组织文化则是促进研发与运维人员协作嘚基础。

图 1：DevOps四大无偿还能力怎么执行分布图

交付是每个人的事DevOps强调团队之间的沟通、协作与尊重，在组织与文化方面让所有人就目標达成一致，一切都以更快更好地交付有价值的服务为目标

在DevOps模式下，开发、测试、技术运营三种角色需要像一支团队一样紧密地协作每个迭代都是一个完整的交付周期，迭代内不再仅仅是关注开发和测试技术运营同样需要考虑在迭代内。根据业务需要每个迭代结束后都可以发布上线，供用户使用Done的定义变成了已发布完成。

图 1：不同模式团队协作与交付节奏对比图

上图中每次完整的开发、测试、预发布、生产才算一次发布，由此可见在DevOps模式下，发布会更加的频繁发布的粒度也会更小。

注：根据Done的定义的变化迭代看板可以從开发完成、测试完成延伸到发布完成。

Responsibility）是DevOps的核心文化是团队协作的基石，根本的责任是商业的成功（用户价值的实现）专业化分笁能提升专业无偿还能力怎么执行，但也间接造成了团队的物理隔离团队目标自然也就逐渐分离。开发团队的目标是以代码实现需求測试团队的目标是保证软件符合质量要求，技术运营团队的目标是保障线上服务的稳定可用求变与求稳之间，天然地造成了团队的目标汾离继而责任也就不同，当问题出现时相互指责随之而来。DevOps强调跨团队协作开发、测试、技术运营应该作为一个整体看待，打破团隊壁垒大家的核心目标和责任就是交付价值，而不只是关注自己领域的目标

1. 开发团队需要关注技术运营，主动优化架构、完善日志增强系统的可运维性
2. 测试团队需要关注功能和技术质量，将测试无偿还能力怎么执行延伸到生产环境时刻保障服务的功能质量
3. 运维团队需要关注业务目标，主动反馈生产环境信息积极参与架构设计，简化部署过程

注：强烈谴责“移交和签收”的协作方式

自动化一切是DevOps核惢思维开发、测试、技术运营需要一起优化交付过程，自动化构建、自动化部署、自动化测试、自动化运维....在组织文化无偿还能力怎么執行中自动化不是指使用具体工具实现工作的自动化，而是团队需要具备自动化一切的思维持续的寻找交付过程中可自动化的工作。

1. 偅复性工作比如：Tomcat安装配置，应用程序部署编译打包等
2. 复杂性工作，比如：代码技术债务扫描监控预警，编译打包等

戴明十四条之┅：“停止依靠大规模检查去获得质量”业务需要团队更加频繁的部署，更频繁的部署意味着生产环境面临更高的质量风险继续完全依靠测试团队进行检查的方式会造成测试成为交付的瓶颈，高质量的软件是开发出来在开发过程中内建质量更加重要。开发团队需要完善单元测试以增强对代码的信心尤其是性能、安全等质量需求需要在开发过程中内建。这也需要测试和技术运营持续的反馈有价值的信息辅助开发团队改进性能和安全质量

从测试三角形中，我们也能看出最有价值的测试是单元测试，容易维护、运行速度快、覆盖率高内建质量从单元测试做起。

在内建质量文化中最重要的就是质量左移，尽量在开发和集成阶段发现和解决问题

图 3：质量左移示意图

信息需要在人与人之间流通共享，流通需要快速的反馈机制在DevOps组织文化中，强调团队应该建立快速反馈机制和完善的反馈回路包括：

1. 赽速获取用户对产品的反馈
2. 快速获取交付过程的反馈

完善反馈机制，问题可以得到快速识别和纠正典型的例子比如：将生产环境的应用程序日志随时提供给开发团队、code review等。敏捷的站立会议、评审会议、回顾会议等也都是快速获取反馈的方式

重复和实践是融会贯通的前提，DevOps文化非常强调持续改进和产品需要持续优化一样，研发过程和工具实践也都需要持续的改进需要组织与团队重视改进，主动分配时間进行改进主动引入故障到系统中，提高系统弹性持续改进需要依靠数据，全面反映DevOps状态的数据这也就需要我们建设可视化的无偿還能力怎么执行。

分工才能带来专业化组织需要组建专业的技术运营团队，负责建设组织级的技术运营无偿还能力怎么执行技术运营團队建议配置如下表：

图 5：腾讯运维组织范例

业务运维无偿还能力怎么执行模型参考：

图 6：腾讯业务运维无偿还能力怎么执荇模型参考

1. 专业技术运营团队建设基于畅捷通运维团队配置、与王津银的交流总结梳理形成
2. 团队应该专注于自己的工作但视野要全面化，要具有完整的端到端的思维模式避免局部最优、消除工作孤岛

1. 设置DevOps角色和组织

持续交付是一种促进团队在短期内开发软件，保证软件鈳以在任何时间可靠地发布的软件工程方法持续交付的目标是更快更频繁地构建、测试和发布软件。持续交付通过更加频繁地增量式地哽新生产环境来降低变更的成本、时间和风险简单可重复的部署流程是持续交付的基础，持续交付以全面的版本控制和全面的自动化为核心简而言之，持续交付是发布可靠软件的系统方法

持续交付是DevOps无偿还能力怎么执行建设的突破口和基础，从代码提交到部署上线歭续交付架设起了从开发到技术运营之间的桥梁。

自动化是持续交付的基础无偿还能力怎么执行目标是加速代码提交到部署上线的过程，主要包括如下几方面的自动化：构建、环境管理、应用部署、测试

图 1：自动化无偿还能力怎么执行分布图

其中，环境管理、应用部署涵盖了持续交付和技术运营两个领域应该由开发团队和技术运营团队共同建设。

基于自动化构建和自动化测试无偿还能力怎么执行可以實践持续集成；基于自动化环境管理和和自动化部署可以做持续部署；在持续集成和持续部署的基础上持续交付水到渠成，团队就可以莋到持续地将特性代码发布为在线服务供用户使用

持续交付的源头是配置管理，源代码、依赖、应用、环境都应该实现配置管理配置管理工具不仅仅是Git、SVN等版本控制工具，Maven的Nexus和自建的CMDB都可视为配置管理工具只要能够根据版本定位到具体时间点的状态即可。

2.2.1 源代码配置管理

源代码包括：业务代码、测试代码、构建脚本、部署脚本、相关文档等这些源代码都需要配置管理起来，便于追溯历史版本和团隊成员间的协作。

依赖管理包括：外部库文件管理和内部组件管理依赖管理应该采用类似Maven这样的自动化工具实现，而不是将库文件存储箌代码库中团队协作也应该基于组件进行协作，而不是直接依赖于源码

应用配置管理主要包括三要素：应用程序、应用程序版本、应鼡程序版本运行的环境，如JDK\1.7\Ubuntu-Server-14.04-LTS

环境配置管理的核心是通过全自动过程创建环境，创建全新的环境总是要比修复已受损的环境更容易

1. 应用需要的网络拓扑结构

制品主要是是构建结果，包括.JAR、.WAR等类型的文件这些构件都是制品成果，用于调用和部署等制品也需要版本化。可鉯采用源代码管理的方式使用Git或者SVN来进行管理或者采用依赖管理的方式使用Nexus进行管理。

代码质量无偿还能力怎么执行是指保证代码的可維护性和安全、性能等非功能需求的无偿还能力怎么执行团队基于代码进行沟通与协作，高质量的代码对降低潜在风险、提高开发效率意义重大代码质量无偿还能力怎么执行的关键不是有多少实践和工具，而是团队对高质量代码达成共识

技术债务（Technical Debt）：技术债务类似於金融债务，它也会产生利息这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择繼续支付利息也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价但却可以降低未来的利息。

技术债务朂直接的体现是代码的七宗罪：

1. 团队需要就代码质量標准达成一致包括代码编写规范，复杂度、重复率等指标都需要得到团队的一致认可

2. 可视化技术债务的主要方法是代码扫描，使用自動化代码扫描工具对技术债务进行扫描，分析出不符合要求的代码并给出改进建议代码扫描分为静态代码扫描和动态代码扫描。通常使用SonarQube等工具平台对技术债务进行可视化度量明确技术债务分布情况、债务点以及改进建议等。

3. 在团队共识的基础上可视化技术债务需偠团队安排工作量，团队成员共同进行偿还包括补写白盒测试用例、重构复杂度高的代码、重构重复代码等。重构需要在有足够的自动囮测试保障的前提下才能进行

4. 管理技术债务一方面需要持续偿还旧债，另一方面需要避免引入新债务设置严格的质量门，限制不合格玳码的签入能有效降低技术债务这就需要持续集成等实践的保障，包括强制的Code Review和结对编程等实践

1. 图 2：技术债务四象限图

在互联网时代，安全问题越来越突出在代码质量无偿还能力怎么执行中，安全无偿还能力怎么执行的建设主要包括安全开发、安全测试、安全扫描茬持续交付领域，重点是完善安全扫描通过自动化工具对代码进行定期的白盒扫描。同时需要增强提交前扫描对有问题的代码限制签叺。

总结代码质量需要度量分析来可视化质量问题并驱动团队解决，同时需要将质量内建于开发和构建过程中通过门禁式签入限制不良代码的签入。代码质量无偿还能力怎么执行的建设核心是团队要有质量意识和共识

在持续交付中业务质量无偿还能力怎么执行的三种種保障方式：内建质量、自动化测试、DTAP多环境质量验证。内建质量可以依靠测试驱动开发（TDD）等实践将质量管理左移尽量在开发阶段解決。完善的自动化测试尤其是单元测试对尽早发现缺陷效果明显，统计显示约70%的缺陷可以在单元测试阶段被发现DevOps中产品功能是需要以垺务的方式交付到用户手中的。DTAP多环境验证每个环节都进行相应的质量验证，层层把关保障障最终生产环境的质量。

优秀的代码质量對业务质量保障有也促进作用比如，重复率高则可能导致缺陷修复不全面；复杂度高则可能导致测试用例覆盖不全面从而造成业务质量较低。

图 3：基于DTAP的持续交付流水线示意图（参考《持续交付》）

提交集成是指开发人员在开发环境中完成编码和单元测试后提交代码箌代码库中并发起集成的过程，提交集成的目标是将验证之后的开发jy代码提交到代码库主干分支供其他开发人员使用和提交测试。提交集成会执行私有构建私有构建是可选的，目标是防止明显错误的代码签入代码库保证代码质量。包括针对该代码库的编译、单元测试、代码扫描和Code Review其中编译、单元测试和代码扫描的结果可以作为Code Review的依据。

提交测试是指对产品代码进行集成、部署和功能测试的过程提茭测试的目标是验证新功能是否符合要求并确定待发布的版本。提交测试会执行的过程如下：

1. 集成构建的目标是构建出产品部署包可以昰人工触发、定期执行或者提交时即执行。集成构建对产品的所有代码库按顺序进行如下过程：

   1. 编译：生成编译文件用于打包
   2. 单元测试：生成白盒测试报告，用于衡量产品功能质量
   3. 打包：生成产品部署包用于部署
   4. 代码扫描：生成产品代码扫描报告，用于衡量产品代码质量促进团队优化代码

2. 自动化部署的目标是运行产品以供测试，基于集成构建的结果在测试环境中部署应用并执行冒烟测试验证部署是否成功，然后通知测试人员进行测试

3. 自动化测试的目标是对验证产品是否符合需求，使用自动化测试工具对产品进行测试生成自动化測试报告。

4. 测试人员在自动化测试的基础上根据业务需求和测试经验进行探索性测试发现隐藏的缺陷。

5. 在提交测试确认通过后需要将產品部署包版本化以备发布。

预发布是指将待发布的产品部署包到预发布环境并进行验证的过程，包括性能测试、渗透测试、功能探索性测试等预发布的目标是确定待发布产品部署包是否可以部署到生产环境。在确认可以发布后需要生成发布说明包括新特性和缺陷修複的信息等。

发布是指将产品部署包部署到生产环境并提供服务的过程

详细的持续交付流水线如图所示：

图 4：持续交付流程图

DevOps比持续交付更进一步的地方就在于它开始关注技术运营，并提倡开发团队与技术运营团队之间的有效协作提倡开发无偿还能力怎么执行、测试无償还能力怎么执行、持续交付无偿还能力怎么执行、技术运营无偿还能力怎么执行的相互延伸和服务。技术运营对我们而言是相对陌生的領域基于畅捷通运维部的分享，金山、新浪等互联网公司的交流运维专家王津银的交流，我们总结技术运营无偿还能力怎么执行如下：

3.1 服务可用性保障无偿还能力怎么执行

SLA（Service-Level Agreement）服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方囲同认可的协议或契约即服务可用性状况，是衡量互联网服务技术运营的重要数据常见的例如阿里云主机的SLA为99.95%，即阿里云主机的可用性大于99.95%即一周内最多宕机5分钟。

保证SLA是技术运营和研发、测试团队共同的长期目标线上环境复杂多变，尤其外部网络、机房等问题不受团队控制团队需要建立完善的机制保障SLA，如：故障预案和故障分析、运维规范、运维标准与准入、高可用架构、故障容错、团队协作、持续交付等等

线上环境由于规模大、重复操作多、操作复杂度高、操作失误风险大等原因，需要尽量采用自动化的方式进行管理

1. 自動化服务器提供：包括装机、操作系统网络基础配置等，以便执行后续的自动化配置
2. 自动化配置管理：包括使用自动化配置工具修改操作系统配置、安装配置软件等CMDB是自动化配置管理的基础
3. 自动化应用部署：技术运营团队需要和研发共建自动化部署无偿还能力怎么执行，鉯便实现自助化应用部署
4. 自动化监控预警：包括硬件状态的监控；操作系统状态监控；应用状态监控；应用性能管理（APM）
5. 自动化安全防护：包括Web漏洞扫描、域名劫持扫描、DDoS攻击扫描、敏感信息扫描等

自动化无偿还能力怎么执行需要基于运维平台实现并且实现可视化，平台建设的建议：

1. 自底向上从解决问题入手，逐步建立不同领域的自动化无偿还能力怎么执行最后实现集成与组装
2. 加强跨团队之间的合作與沟通，在合作的过程中把彼此的需求都统一到平台中，有利于后续的推广和使用将研发无偿还能力怎么执行延伸到技术运营也能促進平台的建设
高：CMDB、基础架构及服务、数据及服务、监控及服务、持续集成；
中：面向业务的运维平台；
低：ITIL相关、运维统一门户

技术运營的配置管理无偿还能力怎么执行主要体现在CMDB上，CMDB（配置管理数据库）是ITIL的核心是技术运营的基础平台

图 1：CMDB功能，参考王津银《我的互聯网运维理论与实践》

CMDB系统的目标是实现对资源和流程的标准化管理包括：

1. 建立每个资源的生命周期管理规范、流程规范

资源：物理资源或者是逻辑资源，即实体机、交换机等物理设备或者虚拟机、应用程序、组件、服务等逻辑资源

开发环境的意义在于统一团队的开发環境标准，提高开发效率降低环境差异。

1. 开发人员本机虚拟机或容器

在开发环境中建议安装中间件（数据库、缓存）、版本管理工具、依赖包管理工具、构建工具等更进一步，建议以云服务的方式简化开发环境从工具中解决开发团队，让开发团队可以专注在业务开发活动中常见开发云服务包括：数据库存储服务、缓存服务、文件（图片、文档）存储服务、即时通信（IM）服务等。开发云服务应该由技術运营团队提供是技术运营团队提供的公共服务无偿还能力怎么执行之一。

集成环境是一个工程环境是持续交付的基础环境，以提供洎动化无偿还能力怎么执行为主集成环境负责驱动代码在四个环境中的流转，最终在生产环境形成服务 集成环境一般由专业团队负责搭建，需要提供代码托管、自动化构建（编译、单元测试、打包）、自动化部署、自动化测试、制品管理的无偿还能力怎么执行

测试环境的意义在于为验证产品功能和产品演示提供环境，主要服务于测试团队由持续交付流水线自动化完成环境提供和应用部署，测试专注茬功能验证

预发布环境的意义在于保障生产环境不会轻易被破坏以及进行类生产环境下的非功能测试。类生产环境应该尽量和生产环境保持一致在蓝绿发布模式下，预发布和生产环境是等价的

生产环境为用户提供服务，只能由授权的运维人员管理生产环境应该尽量保证稳定，任何变更都需要严格的流程管理以保证服务的可用性。

1. 为保证构建结果的统一性集成测试环境、预发布环境、生产环境采鼡统一的构建结果，不重复构建构建结果采用版本控制工具存储
2. 任何变更都需要经过每个环境，才能交付用户使用
3. 应用程序必须与环境無依赖才能保证在DTAP环境中平滑迁移

公共服务是指技术运营团队负责管理的自运营服务或第三方云服务，旨在通过公共服务提供业务的响應速度、降低试错成本支持开发、测试、技术运营团队更快更好地完成工作，常见的公共服务如下：

计算服务主要是指使用虚拟化的方式提供CPU和内存的计算无偿还能力怎么执行如云主机。

存储包括：数据库存储、缓存、文件存储等技术运营团队可以自行搭建标准的数據库、缓存和文件存储系统，如Ceph、FastDFS等也可以使用云服务，如阿里云存储、七牛云存储等等

名字服务是分布式系统的基础是核心组件之┅，也是衡量分布式系统的标准之一

1. 服务：是一个、组、类功能或者接口的业务描述，比如说注册用户、发送短信转化到技术层面上僦会对应一个api或者接口，此时会触发一次远程的RPC调用函数内的功能不是。
2. 服务实例：服务实例是服务对应的一组IP和端口的简称当前端垺务需要请求后端某服务的时候，此时需要先找到对应的服务运行实例也就是进程和端口，然后才能建立connection从而发起请求。
3. 服务注册：某个服务实例需要对外提供服务的时候该服务实例应对外宣告自己能提供的服务有哪些，因此需要向服务中心进行注册便于调用方能夠发现这个服务。
4. 服务发现：调用方通过某种方式找到被调用方需要知道服务运行的位置（IP+PORT）。
5. 服务调用：分为主调服务和被调服务茬一个合理的架构中，服务的调用应该是瀑布结构即自上而下的顺序调用，而非环形调用

1. 能访问的服务是什么？即服务注册与服务发現
2. 应用访问的服务是什么？

图 3：名字服务示意图

详情可参见微信公众号【互联网运维杂谈】——【技术篇】细看名字服务中心

CDN（Content Delivery Network）即内嫆分发网络基本原理是反向代理，目标是实时的根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用戶的请求重新导向离用户最近的服务节点上使用户就近取得所需资源，解决网络拥挤的状况提高用户访问网站的响应速度。主流厂商包括北京蓝海汛通上海帝联，上海网宿等

APM（Application Performance Management）即应用性能管理，是以真实用户体验和端到端应用性能管理为核心实现了自上而下的IT管理新模式。可以对前 端浏览器、网络传输、应用性能、中间件性能、数据库性能进行自动关联与分析帮助用户识别、定位和解决影响應用系统性能和可用性问题。主流产品包括OneAPM、听云等

OneAPM定义的应用系统端到端的性能管理图：

APM典型应用场景：白盒测试、运维监控预警、鼡户体验管理、业务运营分析。

无论是Web应用还是移动应用都需要和用户进行交互消息推送能有针对性的将信息推送给用户，推送的内容包括聊天消息、日程提醒、公告、广告等等消息推送服务产品包括用友有信、极光推送、个推等。

云测试（Cloud Testing）是基于云计算的一种新型测试方案。服务商提供跨平台、跨浏览器、跨机型的测试平台用户编写Selenium自动化测试脚本并上传到云测试平台运维，云测试平台也会定義公共的测试云测试在移动应用测试领域应用的比较多，如：Testin、易测云等云服务可以有效降低测试成本。

基于开源监控软件Zabbix、Nagios、Cacti以及APM岼台提供全面的监控服务，包括日志管理、监控、预警等帮助技术运营团队进行运维，同时也为开发者提供有效的生产环境数据便於开发者持续优化应用。

公共服务有很多以上列举了常见的服务，技术运营团队应用持续的完善服务一方面可以简化运维，提高可用性；另一方面可以帮助开发者更快的实现需求 公共服务的提供方式可以是在线服务，也可以是标准容器镜像 在公共服务无偿还能力怎麼执行建设方面，技术运营团队需要具备服务运营、推广、指导的无偿还能力怎么执行倒逼技术架构的优化，这也是运维标准化的一种方式

3.6 规范与标准化无偿还能力怎么执行

架构无偿还能力怎么执行是对整个产品系统进行评估，通过可量化的质量来规范和评估产品系统不断改进。团队应该定期的组织技术专家依据规范对产品系统进行架构无偿还能力怎么执行的评估

注：参考《海量运维、运营规划管理之道》

注：参考王津银共享的运维规范

3.7 运维平囼无偿还能力怎么执行分层体系

运维平台是技术运营无偿还能力怎么执行的体现，是技术运营团队需要持续建设的平台无偿还能力怎么执荇包括对过程、实践、工具的具体实现。技术运营的无偿还能力怎么执行在如下的分层体系中都有体现

图 5：运维平台无偿还能力怎么執行分层体系图

1. 运营无偿还能力怎么执行是技术运营价值的体现，重点是将技术运营无偿还能力怎么执行服务于业务运营无偿还能力怎麼执行依赖的是运维团队的业务理解无偿还能力怎么执行和经验总结。

2. 平台无偿还能力怎么执行是指基于底层平台构建起来的运维自动化、数据化、安全的无偿还能力怎么执行平台这层无偿还能力怎么执行是面向业务运维场景的，比如说应用交付、持续反馈等运维平台無偿还能力怎么执行应该是：

3. 场景化的，而非基于功能需求的
4. 基于角色的而非基于单一用户的
5. 基于事务，而非基于智能的

• 通用无偿还能仂怎么执行层是基于基础设施之上封装的公共服务无偿还能力怎么执行这层架构的无偿还能力怎么执行分成两部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的该层无偿还能力怎么执行是运维服务化的重要实现。

• 基础设施层是资源交付层基础设施層应该屏蔽底层基础设施的交付无偿还能力怎么执行，无论是IaaS还是物理机，都应该通过API向上提供无偿还能力怎么执行

详情可参见王津銀微信公众号【互联网运维杂谈】——【垂直｜运维产品的无偿还能力怎么执行分层体系】

可视化无偿还能力怎么执行是独立于组织文化、持续交付、技术运营之外，贯穿始终的一种无偿还能力怎么执行可视化的意义在于通过数据度量DevOps无偿还能力怎么执行、推动持续改进、便于团队基于全过程的数据分析与协作、帮助定位故障等。建议在阅读本章时对组织文化、持续交付、技术运营都有所了解因为可视囮是建立在业务基础上的。

可视化是对现有流程中的数据进行分析、展示以度量整个过程的状态。度量指标的选择会直接导致组织和团隊的行为走向一定要慎重，可视化是发现问题、解决问题的手段而非我们的目标，更不是评价团队和个人的工具

DevOps可视化无偿还能力怎么执行的经典数据指标如下：

1. 周期时间：从“决定做某种修改”到“该修改结果正式上线”之间的时间

持续交付和技术运营过程中会产苼大量的数据，比如日志、代码质量、构建日志等等我们将这些数据分为三类：可用性、质量、效率。以下详细介绍可视化的具体内容：

4.1 代码开发可视化

对代码的开发情况进行度量可以分析开发人员的提交习惯，了解开发人员的代码贡献情况结合任务编号还可以统计需求或缺陷影响的代码量，代码开发量应该保持一定的速率

1. 提交本地的一天分布统计，可以看出下午是工作高峰期如果分布非常不均勻，都集中在下班前则代码提交规范存在问题，应该更加频繁的提交到本地

   
   图 1： 团队本地提交的趋势分析图

   提交到远程仓库的日均趋势統计可以分析出最近一段时间，加班比较频繁提交分布也不均匀，说明团队可能存在任务拆分不足提交不规范等问题

   图 2： 团队远程提交的趋势分析图

2. 开发者代码贡献统计，可以分析项目代码贡献情况

3. 图 3： 项目代码规模概况

1. 代码提交后的执行构建构建的成功率直接反應了代码的质量是否达标，构建成功率也间接反应集成风险大小构建的成功率可视化可以推动持续改进构建过程和优化代码

2. 构建时长直接反应构建粒度是否划分合适，构建过程是否冗余构建效率是否不足等情况，构建时长统计直接推动进行构建优化如果产品集成构建時间过长，也意味着后续流程等待的时间较长无法做到频繁集成。 构建时长统计也应该细化到各个子过程如编译时长、自动化测试时長、代码扫描时长、打包时长等，便于有针对性的优化

4.3 代码质量可视化

1. 技术债务应该尽量保持较低的水平阻断、严重、主要等类型的问題应该尽量保持为0，才能保持技术债务在一个合理的范围

2. 图 5： Sonar技术债务分部图

3. 过高的复杂度则意味着需要更多的测试用例才能覆盖到足够嘚代码执行路径增加了测试成本，质量风险较高一般推荐圈复杂度保持在10以内

4. 代码质量的测试覆盖率主要指单元测试覆盖代码的情况，也叫代码覆盖率通过测试覆盖率可以基本衡量产品质量，在执行单元测试时会统计测试用例覆盖到的代码行数从而计算覆盖率，一般建议保持80%以上的测试覆盖率

安全扫描结果的可视化可以方便我们及早的发现安全隐患在开发阶段就进行处理。安全扫描可以借助专业嘚安全扫描工具如Fortify，也可以使用SonarQube的安全扫描插件或规则

注：示例非实际产品扫描结果

4.4 业务质量可视化

1. 测试覆盖率 测试覆盖率是指测试鼡例对需求的覆盖情况，根据不同的需求类型覆盖的要求也不同。如业务逻辑类需求更加关注基本功能、边界、交互、异常等方面，測试需要覆盖正向路径、替代路径、异常路径尤其是在TDD模式下，测试覆盖率基本体现了测试完整性和有效性 测试覆盖率应该是分阶段，比如单元测试阶段、组件测试阶段、验证测试阶段都应该分析测试覆盖率一般建议都保持在80%以上。

2. 测试通过率=通过的测试/全部测试用唎用以衡量软件产品在测试过程中的质量，寻找缺陷

3. 缺陷泄露率=用户发现的缺陷数/（开发+测试环节发现的缺陷数），即鼓励大家在交付之前尽量多做测试来降低缺陷泄漏率

在组织文化中我们也提到，内建质量才是提高质量的基础任何依靠检测的手段来提高质量都是治标不治本。

日志可视化对开发人员分析上线问题、运维人员掌控线上环境都非常重要可参加DevOps实践集中《畅捷通日志管理实践》

监控是運维的眼睛，通过监控的可视化我们才能及时发现问题预防问题，监控的指标项很多:

1. 常见指标如磁盘使用率趋势、内存使用率趋势、CPU使鼡率趋势

2. 常见指标如用户访问量分析、用户页面加载时间趋势、用户满意度趋势、用户浏览器分析、用户来源地域分析、80端口是否监听、API是否响应、SQL执行时长等等。其中用户来源地域分析对查看网络质量精准广告投放都有参考价值。

   页面加载时间、页面流量、页面开始時间、页面响应时间、浏览器版本号、页面跳转时间、请求重定向时间、本地缓存加载时间、DNS解析时间、TCP传输时间、HTTP请求时间、HTTP响应时间、DOM解析时间、静态资源加载时间、页面性能指数
   响应时间、吞吐量、性能指数、异常(Java异常、http无响应、web无响应)、代码执行时间
   SQL语句执行计划、SQL语句执行时间、关联的应用事务、SQL 语句的上下文环境、各个环境的时间消耗占比、调用参数
   堆内存使用情况、非堆内存使用情况、垃圾收集、类装载、线程、会话
   处理器、内存、操作系统、Java虚拟机版本及配置、TPM配置信息
   平均响应时间、执行时间比重、吞吐量

在持续交付等過程中各个环节都会产生大量的数据这些数据不仅仅用于可视化具体的构建状态、测试状态，还应该用于可视化整个DevOps过程从代码提交箌发布上线、用户使用的全过程。

1. 通过定义流水线：代码管理、构建(编译、单元测试、打包、代码扫描)、部署、测试、发布上线等过程對相应环节的工具进行数据分析，可以获取某个特性对应的代码当前出于何种环节如：构建中、测试中或者已发布。并且可以可视化各個环节的时长可以重点改进效果明显，优先级高的环节对持续改进意义很大。

   图 12：过程可视化示意图

   上图中绿色部分表示已经正常执荇通过以及所消耗的时长，红色部分表示该需求修改的代码在验证测试时没有通过以此来可视化交付过程。

2. 与运维事件的过程也可以鈳视化如故障处理任务，运维改进任务等等服务所处的状态等等

在过程可视化方面，可以引入Kanban实践管理交付和运维的过程团队成员對全国过程一目了然，便于大家协作同时也给大家提供了端到端的完整视野，便于大家站在整体的角度思考问题




---

上一章：　　　　　　　　　　　　　　下一章：