研发运营一体化能力成熟度模型-应用设计

上传人:nj****e 文档编号:148233287 上传时间:2020-10-17 格式:DOCX 页数:14 大小:85.03KB
返回 下载 相关 举报
研发运营一体化能力成熟度模型-应用设计_第1页
第1页 / 共14页
研发运营一体化能力成熟度模型-应用设计_第2页
第2页 / 共14页
研发运营一体化能力成熟度模型-应用设计_第3页
第3页 / 共14页
研发运营一体化能力成熟度模型-应用设计_第4页
第4页 / 共14页
研发运营一体化能力成熟度模型-应用设计_第5页
第5页 / 共14页
点击查看更多>>
资源描述

《研发运营一体化能力成熟度模型-应用设计》由会员分享,可在线阅读,更多相关《研发运营一体化能力成熟度模型-应用设计(14页珍藏版)》请在金锄头文库上搜索。

1、研发运营一体化(DevOps)能力成熟度模型第 5 部分:应用设计The capability maturity model of DevOpsPart 5: Application Design目 录前言II研发运营一体化(DevOps)能力成熟度模型 第 5 部分:应用设计11 范围12 规范性引用文件13 术语13.1 软件架构 Software Architecture13.2 应用程序 Application13.3 运行时环境 Runtime Environment13.4 软件包 Software Package14 缩略语15 应用设计25.1 应用接口25.2 应用性能45.

2、3 应用扩展65.4 故障处理8A11A11附录A (规范性附录) 五级度量指标定义11参考文献12II前言研发运营一体化是指在IT软件及相关服务的研发及交付过程中,将应用的需求、开发、测试、部署 和运营统一起来,基于整个组织的协作和应用架构的优化,实现敏捷开发、持续交付和应用运营的无缝 集成。帮助企业提升IT效能,在保证稳定的同时,快速交付高质量的软件及服务,灵活应对快速变化的 业务需求和市场环境。本标准是“研发运营一体化(DevOps)能力成熟度模型”系列标准的第 5 部分 应用设计,该系列标准的结构和名称如下:第1部分:总体架构第2部分:敏捷开发第3部分:持续交付第4部分:技术运营第5部

3、分:应用设计第6部分:风险管理第7部分:组织结构研发运营一体化(DevOps)能力成熟度模型 第 5 部分:应用设计1 范围本标准规定了研发运营一体化(DevOps)能力成熟度模型中应用设计能力的成熟度要求。 本标准适用于:a) 具备 IT 软件研发、交付、运营能力的组织实施 IT 软件开发和服务过程的能力进行评价和指导;b) 可供其他相关行业或组织进行参考;c) 可作为第三方权威评估机构衡量软件开发交付成熟度的标准依据。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文 件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文

4、件。1YD/T1171-2001IP网络技术要求网络性能参数与指标2YD/T1823-2008IPTV业务系统总体技术要求33术语YD/T1489-2006数字蜂窝移动通信网移动流媒体业务总体技术要求下列术语和定义适用于本文件。3.1 软件架构 Software Architecture软件架构是计算系统的软件架构是解释该系统所需的结构体的集合,其中包括软件元素,元素之间的相 互关系和二者各自的属性。3.2 应用程序 Application指研发团队生产的可基于运行时环境运行的软件包。3.3 运行时环境 Runtime Environment运行时环境指应用程序进入运行态的软件环境,包括操作系

5、统、中间件、计算机程序设计语言编译 器、计算机程序设计语言解释器、环境变量、SDK 等非研发团队的应用程序产出。3.4 软件包 Software Package通过计算机程序设计语言编写并生成的可运行计算机的代码集合。4 缩略语下列缩略语适用于本文件。DevOpsa portmanteau of development and operations一组过程、方法与系统的统称JSONJavaScript Object NotationJS 对象标记HTTPHyperText Transfer Protocol超文本传输协议MTTFMean Time To Failure平均失效前时间MTTRMe

6、an Time Between Failures平均恢复前时间RPCRemote Procedure Call远程过程调用TCPTransmission Control Protocol传输控制协议XMLeXtensible Markup Language可扩展标记语言5 应用设计DevOps技术能力包括开发技术、测试技术、运维技术等能力,其中开发技术中最核心的是应用设计 相关技术,应用设计的分级技术要求包括:应用接口、应用性能、应用扩展和故障处理,如表1所示。表1应用设计分级技术要求应用设计应用接口应用性能应用扩展故障处理传输协议实际性能水平扩展日志数据协议可用性垂直扩展监控内容协议故障追踪

7、接口治理故障修复5.1 应用接口是指软件系统不同组成部分衔接的约定。5.1.1 接口规范是指通过接口标准化制定统一的规范和处理方式,降低接口的复杂度,减少接口对接的工作量,从 而提升应用交付的速度和效率。5.1.1.1 传输协议指应用系统间传输数据所用的协议,例如TCP、HTTP、RPC等。5.1.1.2 数据协议指应用系统间传输的数据所采用的格式,例如 JSON、XML、私有协议等。5.1.1.3 内容管理指应用系统间传输的数据内容有统一的标准管理,例如JSON数据应该包含哪些字段。表2应用接口级别传输协议数据协议内容协议1各应用系统分别对外提供不同的传输协议,例如 A 系统提供 HTTP、

8、B 系统提供二进制,C 系统提供 RPC各应用系统分别对外提供不同的数据协议,例如 A 系统对外提供 XML 数据,B 系统对外提供 JSON 数据各应用系统分别对外提供不同的内容协议,例如同样是JSON 格式,A 系统 Json 数据键命名风格是下划线,B 系统Json 数据键命名风格是驼峰式2各应用系统约定了统一的传输协议,例如指定采用 HTTP传输协议各应用系统约定了接口间传输的数据协议,例如指定数据协议为 XML各应用系统约定了接口间传输的内容协议,例如 Json 的命名规范,最大长度等3各应用系统约定了统一的传输协议和协议规范,例如采用 HTTP 协议时,指定Content-Type

9、 、Connection等 header 的配置各应用系统约定了统一的数据协议和数据规范,例如采用 XML 格式时,哪些信息用属性表示,哪些信息用元素表示各应用系统约定了接口间传输的内容协议规范,例如指定JSON 数据必须包含这些字段: requestID , caller ,source,time,response4提供了统一的接口开发库或者开发包,各应用系统统一使用开发库或者开发包来完成协议解析和处理提供了统一的数据编解码开发库或者开发包,各应用系统统一使用开发库或者开发包提供了统一的内容编解码开发库或者开发包,各应用系统统一使用开发库或者开发包5提供了统一的开发框架,开发框架集成了协议处

10、理,可以通过简单的方式就能够对外提供接口,例如通过SpringBoot 的RestController 注解方式提供接口提供了统一的开发框架,开发框架集成了协议处理,可以通过简单的方式就能够对外提供接口,例如通过 SpringBoot 的注解方式提供了统一的开发框架,开发框架集成了协议处理,可以通过简单的方式就能够对外 提 供 接 口 , 例 如SpringBoot 的注解方式5.1.2 接口管理接口规范是指利用统一的接口规范约束各个系统按照统一的标准规范操作,并对应用系统提供的 接口进行管理,主要内容包括接口查询和权限控制,如表 2 所示。5.1.2.1 接口查询应用系统需要查询其它应用系统

11、提供的接口,应确保接口符合规范。5.1.2.2 权限控制应用系统对外提供的接口,需要进行权限控制,例如部分敏感数据的访问。表3接口管理级别接口查询权限控制接口规范管理1各应用系统自己维护接口文档,通各应用系统对外提供的接口没有自行定义的格式的过邮件或者即时通信的方式传送接口文档权限控制能力接口规范,接口规范相对松散。2提供统一的接口查询平台,各个应用系统开发人员在这个平台上手工填写自己系统的接口信息各应用系统自己实现基本的访问控制权限有统一的接口规 范,但接口由标准自由定义。例如: 无标准的 XML ,Json3提供统一的接口查询平台,各个应用系统开发人员可以从代码导出接口信息,然后发布在接口

12、信息查询平台各应用系统自己实现了访问控制和细粒度的数据控制权限有统一的接口规 范,接口遵循相应的标准规范。例 如:wsdl,swagger.io4提供统一的接口查询平台,各个应用系统开发人员可以从代码导出接口信息,然后发布在接口信息查询平台各应用系统自己实现了访问控制和细粒度的数据控制权限a) 有统一的接口规范,接口遵循相应的标准规范。b) 接口规范由统一的基础设施中心化管理。例如:依照规范设立的集中式 APIGateway5提供统一的接口平台,各个应用系统可以自动注册接口相关信息,接口平台可以自动测试接口是否符合规范要求。提供统一的接口权限管理平台,平台统一管理接口的访问控制权限和数据控制权

13、限。a) 有统一的接口规范,接口遵循相应的标准规范。b) 接口规范由 API 按照标准的方式去中心化管理。例如: 依照规范设立的分布式服务网格(Service Mesh)5.2 应用性能应有性能是对应用实际性能(Real Performance,与感知性能 Perceived performance 相对)和可用性(Availability)的度量,是衡量应用服务水平的重要指标。5.2.1 实际性能实际性能是指用户实际体验的性能,例如在正常载荷或者最大载荷情况下平均响应时间。通过两个 指标进行度量,如下:a) 应用在一定载荷(Load,例如请求数/秒、事务数/秒、页面数/秒)情况下对最终用户请

14、求的 响应时间;b) 应用在一定载荷情况下计算资源消费情况,包括CPU、内存、IO、网络带宽等。通过计算资源 消费情况判断计算资源是否支持指定的载荷,或者建立资源消费情况基线,在应用生命周期中 追踪应用性能变化。5.2.2 可用性可用性是指在要求的外部资源得到保证的前提下,产品在规定的条件下和规定的时刻或时间区间 内处于可执行规定功能状态的能力。它是产品可靠性、可维护性和维护保障性的综合反映。可用性一般 通过冗余和故障转移的方式获得。5.2.2.1系统可用性是指系统服务不中断运行时间占实际运行时间的比例。5.2.2.1.1系统可用性指标系统可用性指标定义为:MTTF/(MTTF+MTTR) * 100% ,其相关的两个指标定义如下: MTTF: mean time to failu

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > IT计算机/网络 > 云计算/并行计算

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号