2019可信云大会 | 牛晓玲:《研发运营一体化(DevOps)能力成熟度模型系列标准 第4部分: 技术运营》权威发布

2019年7月2日16:35:00 发表评论 15 浏览

尊敬的各位女士们、先生们,大家下午好!我是来自中国信息通信研究院,和研究所,云计算部的运维业务主管牛晓玲,今天分享的议题是研发运营一体化能力成熟度模型第四部分技术运营部分的权威发布。今天内容主要包括以下四个方面,第一是研发运营一体化能力成熟度模型的背景,第二部分是系列标准体系的介绍,第三是技术运营标准内容的解读,第四部分是对未来的展望。

2019可信云大会 | 牛晓玲:《研发运营一体化(DevOps)能力成熟度模型系列标准 第4部分: 技术运营》权威发布

首先,先看一下标准体系框架的全景图。一般新的领域产生之后,首先都会有一些术语和定义,然后会有总体的框架,告诉大家这个领域的框架是怎么样的。在云计算的框架下面,我们有云计算的运营标准,运维类的标准,还有云计算与IT风险管理、云计算服务类和技术类、软件产品类、性能类、云计算安全,还有我们各种各样的行业规范,金融行业、通信行业、电力行业等等。可以看到,研发运营一体化能力运营成熟度模型,整个系列标准是在一体化运维标准体系下面。

关于DevOps的历史可能大家都非常清楚,我不多赘述。但关于标准的背景您可能不太清楚,我们是在2017年12月份在CCSA立项整个DevOps体系的标准,在2018年4月份,完成第2到5部分的征求意见稿,同时立项第8部分系统工具和技术要求的标准。在6月29号,第1到7部分发布了第一版征求意见稿。在同年7月份,由我代表中国代表团去联合国ITU进行国际标准的立项,虽然立项过程非常坎坷,需要有20多个国家,190多个参会代表,全票通过才算通过国际标准,在经过两周多轮的讨论,最终结果是好的,DevOps标准最终立项成功了。在2018年9月份,DevOps系列标准行标号正式下达,在CCSA官网上可以查询到。2019年7月,也就是现在我们发布了技术运营部分。大家可以看到,征求意见稿已经在2018年6与就完成了,为什么现在才发布,因为这个标准开始之初争议很大,在后来将近小一年的时间里,经过多次的改动,终于成稿。在未来,我们可能会继续做一些相关行业研究的白皮书、调查报告、验证性的评估,并且持续推进国际标准化、国内标准化,不断的更新我们的标准。

这是我们研发运营一体化能力成熟度模型的整体框架,刚才的是云计算体系整个的框架,这个是我们的研发运营一体化能力成熟度模型框架,总共分为八个部分。这个标准牵头单位是中国信通院,我们联合业界多家社区、单位,包括云计算开源产业联盟、高效运维社区、百度、阿里、腾讯、京东、中国移动、电信、中国银联等等单位都参加这个标准的编写。目前进展是2018年6月份,第一次全量的征求意见稿已经发布, 2018年7月份也是在联合国成功立项。技术运营这个部分是将于第三季度可以正式开始试评估。

接下来,我们看一下第二部分敏捷开发管理,这部分更多涉及到三个维度。第一是我们的价值交付管理,包括我们需求的工件,比如说需求的内容和形式,包括用例怎么编写,怎么验证,包括用例管理等等都会在这一部分定义。需求活动,比如我们对需求做一些分析,还有需求的验收反馈、改进等等。第二是敏捷的过程管理,就是我们如何体现价值和流动,包括我们的一些交付和需求的能力、交付的质量,还有我们的交付的反馈和度量,是否满足我们的需求。第三是敏捷的组织模式,更多的是面向人员,包括角色职责、角色和角色之间是如何进行协作。还有我们的团队的组成,包括团队整个的工作模式,包括团队和团队之间是如何协作的,这个是我们第二部分敏捷开发管理重点描述的内容。

第三部分是持续交付,大家知道持续交付是软件工程的核心工程实践,这部分也是目前最成熟部分。它包括配置管理、版本控制、变更管理、构建与持续集成、包括构建事件、构建集成,还有测试管理,包括三部分,分层策略、代码质量管理和自动化测试。部署与发布管理,我们会考虑到,部署与发布模式、部署的流水线等内容。环境管理,包括环境的类型,环境的构建和配管等等。数据这部分会着重在测试数据管理和数据变更方面。度量和反馈,我们会验证是否有度量体系、度量的指标,度量反馈做的如何,在持续交付这部分,有没有关联分析等等,这些都是我们比较关注的一些点,也是企业现在做的比较有疑惑的地方。在这里特别说一下,一会展文老师也会分享他的内容,招商银行是目前我们评估过的一些企业里,度量这块做的最好的企业,大家也可以多请教一下展文老师。

接下来说到我们的第四部分,我们先来弄清楚几个概念。第一是IT服务管理,也就是ITSM, Gatner给出的定义是通过一套服务级别协议SLA,保证IT服务质量协同的流程,包括系统开发管理,网络管理,变更管理等等一些流程理论实践。它是以客户和服务为导向,典型的系统包括CRM、ERP系统等。第二个是IT运维管理,就是指单位IT部分采用相关的方法,手段、技术、文档等等,对我们的软硬件的环境,包括我们的IT业务系统以及人员进行综合性管理。第三是IT运营管理,对于IT运营管理,虽然英文是一致的,但中文环境下有两个不同的含义,后面我会详细解释。IT运营管理,其实是指在企业推行信息化建设的过程中,不仅要有支撑的信息技术和平台,同时我们要注重管理,只有平台和管理二者相结合,才是我们的IT运营管理,这是IT运营管理的介绍,至于IT运营管理现在没有一个机构有权威的定义。第四个就是我们的技术运营概念,我们定义为它是运营能力建设的一个过程,包括监控管理、事件与变更管理、配置管理、高可用管理和业务连续性管理等,它其实是以业务为核心,交付稳定、安全、高效的技术运营服务,从而引领企业的成功,这是我们给出技术运营的概念。

总结一下,这几个概念。第一个就是我们是先有ITSM,之后才有ITIL,ITIL使ITSM得到关注和发扬,它的最核心流程是来自于ITIL。ITIL的运维化是ITSM,DevOps的运维化是ITOM。

接下来我们看一下如何从IT运维到运营,虽然只有一字之差,但是却大不相同。第一个就是面向的对象不同, IT运维面向的是基础设施,包括软硬件的维护,故障的排除,它是为了保障IT系统正常运行,关注于IT系统的稳定、可靠、安全。而技术运营则是面向业务和用户,它要求我们的IT系统要更加精细化,自动化和智能化,同时架构也要适应用户的体验效率和效益,总体来说,IT运维是指导让企业如何活着,技术运营是让企业如何活的更好。

第四部分技术运营是包含了有七个大的能力域。第一就是我们的监控管理,第二就是我们的事件变更管理,第三是配置管理,第四是容量与成本管理,第五是高可用,第六是业务联系性的管理,第七是用户体验管理。接下来我后面会对每一个部分进行详细的解读。

这个是我们的标准的部分示意图,标准共有七个大的能力域,下面有35个子指标,每个指标分为一到五级,包括三种评估方法,第一种是人员访谈,第二种是材料审查,第三种是现场演示。

这是我们一级的要求,比如说监控管理部分需要具备一些基础的监控,事件与变更,具备基本的规范,配置管理可以依靠人工,能力和成本需要有一些基础业务指标汇聚等等。二级我们要求企业要实现自动化和脚本化,监控要覆盖更多的监控对象,包括有完善的事件和管理的规范。配置管理要有统一系统,容量与成本要覆盖全生命周期,这是二级的要求。三级,你要更加精细化和平台化,可以看出,我们现在这个标准里的二级已经是国内领先的水平了。四级我们要求完全实现精细化和部分的智能化,需要开始尝试部分的智能的一些能力了。比如说监控管理,需要实现智能化,大部分业务场景中实现无人化、自愈和自改进的能力。五级卓越级目前是没有企业能够实现,我们需要完全的智能化,基本无人为参与,要实现智能决策,包括事件和管理,大部分场景都要进行智能化支撑才能算作达到智能化了。

详细地看一下每个能力域,第一个能力域就是监控管理,分为几个部分,第一部分就是监控的数据采集。第二是我们的数据管理。第三是对数据的应用三个部分。一级要求具备一些基本的数据采集能力,比如CPU,磁盘使用率等。二级需要能采集系统的日志、应用日志等等。三级要求我们有统一的数据采集平台,并且兼容多种多样的采集方式。因为四级和五级比较难达到,所以我重点说一下一到三级。

数据传输这块,一级都是比较基础的,能够进行一些基本数据传输即可。二级需要支持单份数据多份订阅。三级要支持多种传输以及容灾的方案。数据管理这块,我们又分为数据的接收、处理和存储三方面,也是非常全面。一级是能够实现数据接收,二级是要进行数据的清洗、转发、丢弃、复制等。三级需要有统一的数据上报,并且支持文本、字符串和加密的协议等等。在数据处理方面,一级需要简单的进行一些数据源的处理,包括异常数据的识别能力。二级要自定义数据的四则运算、分类、聚类等。三级要实现计算数据处理延迟小于一分钟,要求还是比较高的。对于数据存储方面,一级需要有基本的数据存储,二级要有统一的数据存储,再到三级要支持高并发的查询、冷热的数据分离等等。数据应用,我们又分为数据存储服务、告警与监控,告警收敛和相关联。可视化管理,一级要有在线图表展示,第二级要求能够自定义这些图表,三级要有一些智能的分析和数据指标下钻能力怎么样。

第二个大部分就是事件与变更管理。事件包括了事前事中和事后,事前一级要求对事件进行简单的分类。二级要求对问题和事故进行进一步的分析和梳理。第三级就是实现场景和组织的可扩展能力,包括要实现平台化。事件的处理,一级就是故障出来以后,能够快速相应,处理即可。二级要有一些应急响应和故障处理止损的意识,包括提前防范。三级就是重大的事故快速决策,一些合理的止损管理流程,包括要有一些预案和预防机制。事后要求一级能做到基本的记录、分析通报,二级就是改善相关机制正确找到原因,三级就是要进行一些分析,包括持续跟踪,要形成闭环。变更管理部分,分为变更流程的管理,需要做到部分风险的可控,具备规范的、流程化的管理,三级不仅要有完善的变更管理和发布规范,还要兼顾质量和效率度量。配置管理这部分,主要是包括配置对象和配管数据。

高可用管理分两部分,第一就是应用的高可用,第二是数据的高可用。应用的高可用又可分为弹性能力,一级要求能梳理这些应用服务之间的调用关系,负载均衡支持多种算法等。二级要有应用服务间调用关系治理平台。三级要实现自动化的动态扩容能力等。柔性能力只要是指健壮性,一级要求有一些基础的健壮性,二级要求健壮性比较好,包括硬件故障,非常不易出现,基本上不出现故障。第三就是你的软硬件的故障基本不会产生业务中断,这是我们三级的要求。对于数据的高可用分为缓存的高可用和数据库的高可用。缓存主要是针对热点的数据使用缓存进行加速等能力。二级是要有持久化和可存储备份的节点。三级要实现主节点宕机可以自动化切换至备份界点。然后是,我们的业务和连续性管理这块,分为风险管理,危机管理和应急管理,看起来几个词很像,但其实我们关注点和内容是不一样的。第一个风险管理,更关注于故障恢复时间等能力,业务影响分析我们会对基础业务影响进行分析,业务风险我们会对基础业务风险进行分析。包括二级可能我们要分析有没有严重的一些安全运行的隐患,容量能不能满足业务增长的需求,这是我们风险管理的能力要求。危机管理这块,包括灾备管理和组织机制,比如说灾备的演练时间,通常灾备在企业的演练时间一般是半年一次,二级要求你要间隔小于半年,同时要预期时间内完成且结果符合预期等。三级灾备管理要基于多机房架构,短时间快速切换且对业务的影响最小化。应急管理包括应急演练和组织机制。组织机制是要求一级有基础的管理体系,二级就是组织更加完备,三级就是管理层要参与进来。

容量与成本管理,我们分为容量的管理和成本的管理。容量管理一级要有基础设施的监控和告警,第二部分是业务容量,最后一部分就是我们的用户体验管理,包括业务认知管理和用户的体验管理。比如说业务认知,我们又分为业务学习考核,体验数据管理,采用基础采集工具,全面收集,二级要求端到端全链路用户事件的数据埋点规划等。最后是体验优化管理,不断优化用户体验管理,这是我们的七个大的能力域,35个子的指标项,所有的评估的内容一到三级的能力要求。

这是我们评估的流程,周期大概是这样的,我们先报名申请,然后企业会根据材料进行自评,企业也需要自己准备一些自己的材料,材料通过之后,我们安排专家进行现场的评估,然后出具报告,专家团对报告进行复核,然后会有一个外部专家的评审会,验证你这些结果是不是是否有问题,最后我们会为通过的企业颁发相应级别的证书,大致周期算下来是两个月左右。

这是我们的企业基本信息表,需要企业自行填写,包括企业名称、资质、牌照等等,这个是需要企业自己提供的。

这个是自评表,需要企业会根据这些情况对企业内部情况进行自评,看看自己在什么样的位置。

这是我们的一些部分的核心编写人员,有腾讯的专家、京东的专家、银联、中行、太平洋保险、电信运营商等等,这只是部分,其实这部分标准编写专家30多位,覆盖范围也比较广,包含了各行各业,所以标准的通用性还是非常强的。

这个是我们线下的一些会议研讨活动,每月进行一到两次的专家的研讨会,因为我们有八个标准,会持续不断的进行内容的滚动更新。

再说一下未来,未来我们主要会主推第五部分,应用设计架构,比如包含应用设计的接口、性能、扩展和故障处理的能力。第六部分安全能力风险管理,安全这块和我们说的安全体系不一样,这个安全主要是指总体安全,包括人员的管理,包括工具,代码和第三方合作的安全,包括整个DevOps能力成熟度的体系架构,涵盖开发过程的安全风险,交付过程的风险,以及技术运营过程的风险等。

第八部分是我们的系统和工具部分,也有七个域,其实我们的系统和工具是完全按照DevOps工具链来进行设置的,包括项目开发管理,持续交付,自动化测试,测试管理的一些工具,包括技术运营,应用设计开发、安全等等。

这是我们的系统工具的图谱,我们也收集到了很多国外、国内的工具,也欢迎更多的国内的一些工具厂商加入到我们的这个工具图谱当中来,如果你企业也是做DevOps工具的,欢迎也来跟我反馈。

谢谢,欢迎关注二维码下载标准。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: