研发运营一体化能力成熟度模型-应用设计
研发运营一体化(DevOps)能力成熟度
一、什么是DevOps?DevOps是一种在软件开发和交付过程中将开发和运维团队紧密结合起来的方法和理念。
它的目的是通过不断改进流程、工具和文化，实现开发和运维过程的高效协作，并快速交付高质量的软件产品。
二、什么是DevOps能力成熟度评估?DevOps能力成熟度评估是一种方法，用于评估组织的DevOps实践的成熟度。
它旨在帮助组织确定其当前的DevOps实践的强项和弱点，并提供指导和建议，以改进其DevOps实践，从而实现更高效的开发和交付。
三、DevOps能力成熟度模型DevOps能力成熟度模型是一种框架，用于描述和指导DevOps实践的成熟度。
它基于一系列最佳实践和指南，包括敏捷、持续交付、自动化、监控和反馈等方面。
它通过五个不同层次的成熟度来描述组织的DevOps实践：起步阶段、重复阶段、定义阶段、管理阶段和持续改进阶段。
四、如何进行DevOps能力成熟度评估？进行DevOps能力成熟度评估需要以下步骤：1.了解DevOps能力成熟度模型并选择评估工具。
2.评估组织当前的DevOps实践，包括其开发、交付、运维和监控等方面。
3.确定组织在DevOps实践中的强项和弱点，制定基于评估结果的改进计划。
4.执行改进计划并监控其效果，随着时间的推移对实践进行迭代和改进。
五、DevOps的优势和挑战DevOps的优势包括：1.提高软件交付速度，将软件产品更快地推向市场。
2.改进软件质量和可靠性，通过自动化测试、代码审核等工具降低错误率。
3.减少软件开发和运维成本，提高资源利用效率。
4.增强开发和运维团队之间的协作，改善团队文化和工作效率。
然而，DevOps实践也面临一些挑战：1.需要组织文化和管理的变革，包括企业文化、组织结构和流程等方面的变革。
2.需要团队具备一定的技术和工具的储备和使用水平。
3.需要适应不断变化的需求和市场竞争力。
六、结语DevOps是一种协同工作的理念，强调团队协作、自动化和持续改进。
研发运营一体化能力成熟度模型-应用设计
研发运营一体化（DevOps）能力成熟度模型第5 部分：应用设计The capability maturity model of DevOpsPart 5: Application Design目录前言 (II)研发运营一体化（DevOps）能力成熟度模型第5 部分：应用设计 (1)1范围 (1)2规范性引用文件 (1)3术语 (1)3.1软件架构 Software Architecture (1)3.2应用程序 Application (1)3.3运行时环境 Runtime Environment (1)3.4软件包 Software Package (1)4缩略语 (1)5应用设计 (2)5.1应用接口 (2)5.2应用性能 (4)5.3应用扩展 (6)5.4故障处理 (8)A (11)A (11)附录 A （规范性附录）五级度量指标定义 (11)参考文献 (12)前言研发运营一体化是指在IT软件及相关服务的研发及交付过程中，将应用的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成。
帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。
本标准是“研发运营一体化（DevOps）能力成熟度模型”系列标准的第 5 部分应用设计，该系列标准的结构和名称如下:第1部分：总体架构第2部分：敏捷开发第3部分：持续交付第4部分：技术运营第5部分：应用设计第6部分：风险管理第7部分：组织结构研发运营一体化（DevOps）能力成熟度模型第 5 部分：应用设计1范围本标准规定了研发运营一体化（DevOps）能力成熟度模型中应用设计能力的成熟度要求。
本标准适用于：a)具备 IT 软件研发、交付、运营能力的组织实施 IT 软件开发和服务过程的能力进行评价和指导；b)可供其他相关行业或组织进行参考；c)可作为第三方权威评估机构衡量软件开发交付成熟度的标准依据。
能力成熟度集成模型
能力成熟度集成模型一、引言能力成熟度集成模型（Capability Maturity Integration Model，简称CMMI）是一种软件开发过程改进模型，旨在帮助组织改进其软件开发过程。
CMMI最初由美国国防部开发，是一个用于评估和改进组织的软件和系统工程能力的标准。
二、CMMI的历史CMMI最初是由美国国防部在20世纪80年代末和90年代初开发的。
该模型最初是作为软件成熟度模型（Software Capability Maturity Model，简称SCMM）而创建的。
SCMM旨在帮助组织评估和改善其软件开发过程。
随着时间的推移，SCMM逐渐演变为CMMI，并扩展到包括系统工程和产品开发等领域。
三、CMMI的结构CMMI包括五个不同的成熟度级别：初始级别、可重复级别、定义级别、管理级别和优化级别。
每个级别都包含多个过程区域（Process Area），每个过程区域都涵盖了特定方面的最佳实践。
1. 初始级别初始级别是一个非常基础的水平，它表明组织没有一个定义明确的软件开发过程。
在这个级别，软件开发过程通常是不稳定的、不可预测的和不受控制的。
这个级别的目标是建立一个基本的软件开发过程框架。
2. 可重复级别可重复级别表明组织已经建立了一个稳定的软件开发过程框架，并且已经开始记录一些基本度量。
在这个级别，组织能够重复执行其软件开发过程，并且能够识别和解决一些常见问题。
3. 定义级别定义级别表明组织已经建立了一个完整的、标准化的软件开发过程，并且已经将其文档化。
在这个级别，组织能够根据其定义的流程来管理项目，并且能够识别和解决更高层次的问题。
4. 管理级别管理级别表明组织已经实施了一些度量和分析技术，以便对项目进行管理和改进。
在这个级别，组织能够使用数据来支持决策，并且能够实施持续改进计划。
5. 优化级别优化级别表明组织已经实现了一个持续改进的文化。
在这个级别，组织能够识别并解决更高层次的问题，并且能够不断改进其软件开发过程。
《研发运营一体化(devops) 能力成熟度模型 11部分
《研发运营一体化(devops) 能力成熟度模型11部分研发运营一体化（DevOps）能力成熟度模型是一种用于评估组织在DevOps实践方面的成熟度的方法。
通过这个模型，组织可以了解自己在DevOps实践中的优势和不足之处，并制定相应的改进计划。
本文将从五个大点来阐述研发运营一体化能力成熟度模型的重要性和其具体内容。
一、引言概述研发运营一体化能力成熟度模型是帮助组织评估和改进DevOps实践的一种方法。
它可以帮助组织了解自己在DevOps实践中的成熟度，并提供指导以改进组织的DevOps能力。
二、正文内容2.1 持续集成与持续交付持续集成和持续交付是DevOps实践的核心。
在这一部分，我们将详细阐述持续集成和持续交付的重要性以及如何实施它们。
其中包括建立自动化的构建和部署流程，实现代码质量和自动化测试，以及快速反馈和迭代。
2.2 自动化测试与质量保证自动化测试和质量保证是确保软件质量的关键环节。
在这一部分，我们将介绍如何建立自动化测试框架和流程，包括单元测试、集成测试和端到端测试。
同时，我们还将讨论如何确保测试覆盖率和质量标准。
2.3 基础设施即代码基础设施即代码是通过代码来管理和配置基础设施的一种方法。
在这一部分，我们将详细介绍基础设施即代码的概念和原则，并讨论如何使用工具和技术来实现基础设施即代码。
2.4 日志和监控日志和监控是保证系统稳定性和可靠性的关键环节。
在这一部分，我们将讨论如何收集、存储和分析日志数据，以及如何建立监控系统来实时监测系统的性能和健康状况。
2.5 团队协作与文化团队协作和文化是DevOps实践成功的重要因素。
在这一部分，我们将探讨如何建立高效的团队协作和沟通机制，以及如何营造积极的DevOps文化。
三、总结通过研发运营一体化能力成熟度模型，组织可以全面了解自己在DevOps实践中的成熟度，并制定相应的改进计划。
在持续集成与持续交付、自动化测试与质量保证、基础设施即代码、日志和监控以及团队协作与文化这五个大点中，组织可以逐步提升自己的DevOps能力，从而实现更高效、更稳定和更可靠的软件交付。
人工智能研发运营一体化能力成熟度模型
人工智能研发运营一体化能力成熟度模型引言：随着人工智能的快速发展，越来越多的企业开始重视人工智能技术的研发和应用。
然而，人工智能的研发和应用并不是一件简单的事情，需要企业具备一定的成熟度和能力。
因此，建立一种能够评估人工智能研发运营一体化能力的成熟度模型，对于企业提升自身竞争力具有重要意义。
一、背景介绍人工智能研发运营一体化能力成熟度模型是指通过评估企业在人工智能领域的研发和运营一体化能力，判断企业在该领域的成熟度水平。
该模型可以帮助企业了解自身的发展状况，找到改进的方向，提升核心竞争力。
二、成熟度模型的构成人工智能研发运营一体化能力成熟度模型由多个维度和指标组成，包括以下几个方面：1. 研发能力：研发能力是企业在人工智能算法、模型和技术方面的能力。
这包括企业是否具备相关的研发团队和专业人才，是否有自主研发的能力，以及是否能够将研发成果转化为实际应用。
2. 数据能力：数据能力是指企业在数据采集、处理和分析方面的能力。
这包括企业是否具备丰富的数据资源，是否能够高效地处理和分析数据，并从中挖掘出有价值的信息。
3. 运营能力：运营能力是指企业在人工智能应用和运营方面的能力。
这包括企业是否能够将人工智能技术应用于实际业务中，是否能够从中获取商业价值，并且是否能够持续改进和优化运营效果。
4. 管理能力：管理能力是指企业在人工智能项目管理和团队管理方面的能力。
这包括企业是否具备有效的项目管理方法和流程，是否能够合理分配资源，以及是否能够有效地管理团队并激发团队成员的潜力。
5. 创新能力：创新能力是指企业在人工智能技术方面的创新能力。
这包括企业是否能够持续创新并引领行业发展，是否能够将最新的人工智能技术应用到实际业务中，以及是否能够推动行业的变革和创新。
三、应用案例以某互联网公司为例，该公司通过使用人工智能技术改进推荐算法，提高用户粘性和购买转化率。
在研发能力方面，该公司拥有专业的算法团队和工程师，能够自主研发和优化推荐算法。
《系统与软件工程 开发运维一体化 能力成熟度模型》国标
《系统与软件工程开发运维一体化能力成熟度模型》国标（原创实用版）目录1.系统与软件工程概述2.开发运维一体化的概念与意义3.能力成熟度模型的定义与作用4.我国《系统与软件工程开发运维一体化能力成熟度模型》国标的主要内容5.国标的实施与影响正文一、系统与软件工程概述系统与软件工程是一门关注如何设计、开发、运行和维护软件系统的学科，旨在通过科学的方法、技术和工具提高软件开发的效率和质量，降低软件系统的运行和维护成本。
随着信息技术的快速发展，软件系统在各行各业中发挥着越来越重要的作用，系统与软件工程也成为了企业和组织竞争力的重要组成部分。
二、开发运维一体化的概念与意义开发运维一体化（DevOps）是一种软件开发和运维的实践方法，旨在加强软件开发人员（Dev）和运维人员（Ops）之间的协作与沟通，提高软件开发和运维的效率。
DevOps 的核心理念是“持续集成、持续部署、持续监控”，通过自动化和流水线化的方式，实现软件开发和运维的无缝衔接，从而降低软件开发的周期，提高软件质量，提升用户满意度。
三、能力成熟度模型的定义与作用能力成熟度模型（Capability Maturity Model，简称 CMM）是一种评估和改进组织软件开发过程的框架，通过对组织在软件开发过程中的各个环节进行评估，帮助组织识别存在的问题，并提供改进的方法和途径。
CMM 分为五个等级，从初始级到优化级，反映了组织在软件开发过程中的成熟程度。
四、我国《系统与软件工程开发运维一体化能力成熟度模型》国标的主要内容我国《系统与软件工程开发运维一体化能力成熟度模型》国标在借鉴国际成熟度模型的基础上，结合我国软件产业的实际情况，提出了一套适用于开发运维一体化的成熟度模型。
该国标主要包括以下几个方面：1.开发运维一体化的成熟度等级及其特征2.开发运维一体化的过程领域及其关键过程3.开发运维一体化的评估方法和评估指标4.开发运维一体化的改进策略和实施指南五、国标的实施与影响《系统与软件工程开发运维一体化能力成熟度模型》国标的实施，对于推动我国软件产业的发展，提高软件开发和运维的效率具有重要意义。
《研发运营一体化(devops)能力成熟度模型》能力成熟度评估证书
研发运营一体化（DevOps）能力成熟度模型，是当前软件开发行业中被广泛应用的管理工具之一，能够有效评估企业在DevOps实践中的成熟度，以及制定提高成熟度的具体实施计划。
在本文中，我们将深入探讨DevOps能力成熟度模型，并对其评估证书进行全面介绍和分析。
1. DevOps能力成熟度模型概述DevOps能力成熟度模型是一种通过评估企业在软件开发、测试、部署和运维等方面的成熟度，来帮助企业改善和优化研发运营流程的管理工具。
这一模型基于一系列的最佳实践和标准，旨在帮助企业实现研发运营一体化，提高交付速度和质量，降低成本，增强灵活性和创新能力。
2. 能力成熟度评估证书介绍能力成熟度评估证书是在经过DevOps能力成熟度评估后，企业所获得的认可证书。
这一证书是对企业在DevOps实践中所取得成就的肯定，也是企业参与和推动DevOps转型的重要标志。
根据评估结果，企业可以获得相应的成熟度等级认证，如初级、中级、高级或尖端水平，并获得相应的证书和奖励。
3. DevOps能力成熟度模型的评估流程在进行DevOps能力成熟度评估时，一般包括几个主要阶段：确定评估范围和目标、搜集相关数据和信息、分析和评估数据，制定改进计划和持续改进。
评估过程需要全面深入地了解企业的研发运营现状，精准分析各个环节的瓶颈和问题，并结合最佳实践提出具体改进建议。
4. 个人观点和理解在我看来，DevOps能力成熟度模型是非常重要的管理工具，它可以帮助企业识别瓶颈和问题，提高交付效率和质量，推动组织的数字化转型。
评估证书作为对企业转型成果的认可，可以激励企业持续改进和提高成熟度水平。
在总结回顾本文中对DevOps能力成熟度模型和评估证书的介绍和分析后，我们可以看到它对企业研发运营一体化的重要性和实际应用。
期望企业能够认真对待DevOps能力成熟度模型的评估，不断提升自身在DevOps转型上的实践水平，获得更多的证书和成绩认可，推动企业实现可持续发展和成功。
中国电学学会 业务研发安全运营一体化能力成熟度模型标准
中国电学学会业务研发安全运营一体
化能力成熟度模型标准
根据中国电子学会标准编制工作计划，经标准编制单位的辛勤努力，现已形成团体标准《业务研发安全运营一体化能力成熟度模型》（标准号：JH/CIE230-2022）的征求意见稿。
该标准旨在帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。
《业务研发安全运营一体化能力成熟度模型》共分为5个级别，每个级别中按照不同程度说明，呈现递进的方式，高级别内容宜包含低级别内容，无需重复引用。
具体而言，级别1为初始级，指在组织局部范围内开始尝试DevOps活动并获得初期效果；级别2为基础级，指在组织较大范围内推行DevOps实践并获得局部效率提升；级别3为全面级，指在组织内全面推行DevOps实践并贯穿软件全生命周期获得整体效率提升；级别4为优秀级，指在组织内全面落地DevOps并可按需交付用户价值达到整体效率最优化；级别5为卓越级，指在组织内全面形成持续改进的文化并不断驱动DevOps在更大范围内取得成功。
为确保标准撰写的全面性、合理性和实用性，现面向社会各界公开征求意见。
业内专业人士可填写《标准征求意见汇总处理表》，于2023年7月15日17:00前反馈至联系人邮箱。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
研发运营一体化（DevOps）能力成熟度模型第5 部分：应用设计The capability maturity model of DevOpsPart 5: Application Design目录前言 (II)研发运营一体化（DevOps）能力成熟度模型第5 部分：应用设计 (1)1范围 (1)2规范性引用文件 (1)3术语 (1)3.1软件架构 Software Architecture (1)3.2应用程序 Application (1)3.3运行时环境 Runtime Environment (1)3.4软件包 Software Package (1)4缩略语 (1)5应用设计 (2)5.1应用接口 (2)5.2应用性能 (4)5.3应用扩展 (6)5.4故障处理 (8)A (11)A (11)附录 A （规范性附录）五级度量指标定义 (11)参考文献 (12)前言研发运营一体化是指在IT软件及相关服务的研发及交付过程中，将应用的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成。
帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。
本标准是“研发运营一体化（DevOps）能力成熟度模型”系列标准的第 5 部分应用设计，该系列标准的结构和名称如下:第1部分：总体架构第2部分：敏捷开发第3部分：持续交付第4部分：技术运营第5部分：应用设计第6部分：风险管理第7部分：组织结构研发运营一体化（DevOps）能力成熟度模型第 5 部分：应用设计1范围本标准规定了研发运营一体化（DevOps）能力成熟度模型中应用设计能力的成熟度要求。
本标准适用于：a)具备 IT 软件研发、交付、运营能力的组织实施 IT 软件开发和服务过程的能力进行评价和指导；b)可供其他相关行业或组织进行参考；c)可作为第三方权威评估机构衡量软件开发交付成熟度的标准依据。
2规范性引用文件下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
[1] YD/T1171-2001IP网络技术要求——网络性能参数与指标[2] YD/T1823-2008IPTV业务系统总体技术要求YD/T1489-2006数字蜂窝移动通信网移动流媒体业务总体技术要求[3]3 术语下列术语和定义适用于本文件。
3.1软件架构 Software Architecture软件架构是计算系统的软件架构是解释该系统所需的结构体的集合,其中包括软件元素,元素之间的相互关系和二者各自的属性。
3.2应用程序 Application指研发团队生产的可基于运行时环境运行的软件包。
3.3运行时环境 Runtime Environment运行时环境指应用程序进入运行态的软件环境，包括操作系统、中间件、计算机程序设计语言编译器、计算机程序设计语言解释器、环境变量、SDK 等非研发团队的应用程序产出。
3.4软件包 Software Package通过计算机程序设计语言编写并生成的可运行计算机的代码集合。
4缩略语下列缩略语适用于本文件。
DevOps a portmanteau of development and operations 一组过程、方法与系统的统称JSON JavaScript Object Notation JS 对象标记HTTP HyperText Transfer Protocol 超文本传输协议MTTF Mean Time To Failure 平均失效前时间MTTR Mean Time Between Failures 平均恢复前时间RPC Remote Procedure Call 远程过程调用TCP Transmission Control Protocol 传输控制协议XML eXtensible Markup Language 可扩展标记语言5应用设计DevOps技术能力包括开发技术、测试技术、运维技术等能力，其中开发技术中最核心的是应用设计相关技术，应用设计的分级技术要求包括：应用接口、应用性能、应用扩展和故障处理，如表1所示。
表1 应用设计分级技术要求5.1应用接口是指软件系统不同组成部分衔接的约定。
5.1.1接口规范是指通过接口标准化制定统一的规范和处理方式，降低接口的复杂度，减少接口对接的工作量，从而提升应用交付的速度和效率。
5.1.1.1传输协议指应用系统间传输数据所用的协议，例如TCP、HTTP、RPC等。
5.1.1.2数据协议指应用系统间传输的数据所采用的格式，例如 JSON、XML、私有协议等。
5.1.1.3内容管理指应用系统间传输的数据内容有统一的标准管理，例如JSON数据应该包含哪些字段。
表2 应用接口5.1.2接口管理接口规范是指利用统一的接口规范约束各个系统按照统一的标准规范操作，并对应用系统提供的接口进行管理，主要内容包括接口查询和权限控制，如表 2 所示。
5.1.2.1接口查询应用系统需要查询其它应用系统提供的接口，应确保接口符合规范。
5.1.2.2权限控制应用系统对外提供的接口，需要进行权限控制，例如部分敏感数据的访问。
表3 接口管理5.2应用性能应有性能是对应用实际性能（Real Performance，与感知性能 Perceived performance 相对）和可用性（Availability）的度量，是衡量应用服务水平的重要指标。
5.2.1实际性能实际性能是指用户实际体验的性能，例如在正常载荷或者最大载荷情况下平均响应时间。
通过两个指标进行度量，如下：a)应用在一定载荷（Load，例如请求数/秒、事务数/秒、页面数/秒）情况下对最终用户请求的响应时间；b)应用在一定载荷情况下计算资源消费情况，包括CPU、内存、IO、网络带宽等。
通过计算资源消费情况判断计算资源是否支持指定的载荷，或者建立资源消费情况基线，在应用生命周期中追踪应用性能变化。
5.2.2可用性可用性是指在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。
它是产品可靠性、可维护性和维护保障性的综合反映。
可用性一般通过冗余和故障转移的方式获得。
5.2.2.1 系统可用性是指系统服务不中断运行时间占实际运行时间的比例。
5.2.2.1.1 系统可用性指标系统可用性指标定义为：MTTF/(MTTF+MTTR) * 100% ，其相关的两个指标定义如下：MTTF： mean time to failure，平均失效前时间，也就是平均正常运行的时间。
MTTR： mean time to restoration，平均恢复前时间,也就是平均故障时间。
表4 应用性能5.3应用扩展应用程序在达到最大负载时，能够支持以下方式进行扩展，以保证系统稳定运行。
如表 5 所示。
应用扩展性是应对高并发的重要手段，扩展包括三个维度，如下：a)X轴–是否支持水平扩张（容量扩展），应用可以复制多个实例，共同提供服务；b)Y轴–是否支持垂直扩展（服务资源），将应用的不同模块部署在不同的进程中；c)Z轴–是否支持数据扩展（数据存储），将数据分散在多个存储单元中；应用系统的容量需求会随着业务的发展而增加，容量扩展与应用架构相关，当应用架构具备容量扩展的能力，才能完成容量扩展操作。
表5 应用扩展5.4故障处理故障处理（Troubleshooting）是指在系统失效、停止响应或出现异常时识别、规划和解决系统问题的过程，帮助修理和恢复系统。
在系统运行过程中，由于运行环境的变化、软件本身的缺陷等原因，可能造成系统运行故障。
在系统出现故障时，要求运维人员能够快速发现和解决故障，即快速的故障处理。
故障处理过程循环包括五个步骤，即故障发现、故障追踪、故障解决方案设计、故障排除和故障记录。
复杂系统往往由多个子系统构成，任何一个最终用户的操作可能涉及多个子系统之间复杂的协作，故障发现、追踪和排除是一个复杂的过程，快速故障处理需要应用设计提供基础故障处理能力。
应用设计从以下几个方面支持故障处理过程，包括日志（记录故障现场）、监控（发现故障）、故障追踪（定位故障）和故障修复，如表 6 所示。
5.4.1日志日志是指对系统运行过程的记录，分为开发日志和业务日志。
开发日志是记录代码调用过程和状态，例如JAVA 程序员一般用log4j 工具输出开发日志。
业务日志是对用户业务操作行为及结果的记录，一般需要设计独立的工具进行支持。
业务系统拆分为多个子系统后，如果需要了解整个业务的运行情况，需要综合多个子系统的监控信息，将多个子系统的监控信息关联起来才能得出业务整体的运行状态信息。
通过监控标准化制定统一的监控规范、监控对象、监控数据，监控系统能够将多个子系统上的监控信息关联起来形成业务整体监控信息。
5.4.2监控应用设计需要支持将系统的运行情况实时展示监控信息。
系统能够通过工具随时查看当前系统的运行情况；以便系统运行出现故障时，研发、测试、运维人员等能够及时的获取整个系统的运行情况，进行快速的故障判断和处理。
根据运维提供的监控规范、监控对象、监控指标，应用设计需要支持运维系统能将分散在多个子系统上运行情况实时的展现出来，并关联起来形成整体监控信息，保证系统可监控。
5.4.3故障追踪故障追踪是指应用设计能够支持对实时监控或其它方式获得的问题进行调用链分析，定位故障根源，为故障处理提供依据。
例如，对于复杂的分布式系统，一个客户请求涉及来自多个机器的多个进程的多个服务协作，故障的定位是一个复杂过程。
5.4.4故障修复故障修复是指应用设计支持自动修复常见的故障，例如流量突增、硬件损坏、网络拥塞等，当故障发生时，系统除了进行告警外，还能够自动采取一定应对措施及时处理，降低故障影响范围和程度，减少故障影响时长。
对于一些不常见的故障，支持人工故障修复。
在故障处理完成之后，还需要记录故障，以便后期进行故障分析和积累故障管理知识。
表6 故障处理附录A （规范性附录）五级度量指标定义。