GOPS-2020全球运维大会深圳站DevOps相关材料学习（201213）

今天准备整理下GOPS-2020全球运维大会DevOps深圳站和DevOps相关的一些演讲材料。这篇文章不会大量去引用演讲材料的内容，而是基于这些材料对我们自己的DevOps平台建设，云原生解决方案实践相关内容进行对比分析和总结。

对DevOps的重新回顾

首先看下DevOps的定义：

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

对于DevOps的提出已经很多年，其主要的推动来自两个方面：

• 业务和需求驱动下，推动敏捷方法论，更快的发布和交付。
• 技术和运维部门需要衔接，在PaaS和容器技术发展下进一步推动自动化。

虽然是研发，测试QA，运维交付三方交融的地方为DevOps的内容，但是可以看到DevOps本身更多的是要解决两大类协同和自动化的问题

其一是开发部门和QA的协同

实际上该问题基于多年前已有的每日构建，持续集成方法论就可以解决。在DevOps里面我们也看到这部分协同更多的是敏捷研发最佳实践进行融合。

其二是开发部门和运维部门的协同

该问题的解决当前由云平台，微服务架构，容器技术发展推动的自动化发布和监控运维。注意在持续集成的时候我们只解决了自动化部署问题，但是没有解决持续交付的问题。而在DevOps里面需要同时解决持续集成和面向用户的持续交付能力。

那么DevOps真正的核心是啥？

最能够体现DevOps核心思想的还是上面这个图，Dev和Ops本身是两个团队，不同的职责分工，但是通过上面的双环图可以看到，两者真正融合起来，进行紧密协同。也就是在DevOps持续集成和交付里面经常提到的关键词。 研发运维一体化。

因此，如果一个组织实施DevOps过程实践，最终研发和运维的协同问题还是没有解决，比如出现大量的人为沟通，频繁的版本部署失败和回退，运维问题无法快速跟踪定位等，那么这个DevOps实践就是失败的，不论你使用了什么先进的工具和技术支撑。

在传统的软件开发中，研发和运维协同本身的问题体现在交付过程不清楚，版本部署经常失败，交付版本质量不高经常重复打补丁版本发布，研发交付的软件无法更好的进行监控和性能分析，运维人员发现问题无法快速故障定位等。

任何协同都是双向的，对于研发运维协同则完全可以从两个方面进行理解。

研发->运维：提升交付过程能力

简单来说就是研发要高质量，高效，可持续的交付软件产品。

传统方式下，测试完成后构建一个部署包，走部署或版本发布申请，运维基于部署申请和部署流程进行部署。但是经常出现部署不成功的情况，这个时候又需要手工回退。或者说部署成功了，但是用户使用时候发现功能出现问题，而研发一排查发现了版本构建分支搞错了，或者交付给运维部署的版本并不是UAT测试的版本。

整个交付过程能力提升，一个首要点就是要以构建完成的二进制部署包或容器镜像进行持续交付。确保测试的版本就是交付的版本。其次是整个交付过程能够自动化的尽量自动化，减少人为操作带来的失误。最后是提升自动化测试能力，确保交付产品的质量。

所以你可以看到关于这块的大量实践，包括：

• 持续集成和持续交付
• 灰度发布和自动化版本回滚
• 自动化测试
• 静态代码检查

简单来说研发-》运维协同核心就是提升交付过程能力，符合运维团队的输入，或者运维可以舒舒服服的接管交付的内容。

运维->研发：提供运维和运营能力

从运维到研发方向来说，核心则是提升整个软件产品的运维和运营能力。在DevOps当前成熟度模型单独提出了技术运营的概念。运营简单来说就是一个软件产品的上线后运行，运维人员不再是做简单的资源运维，而是变成了软件应用的运营，通过运营去驱动软件的持续优化和改进。 运维是被动的，而运营是主动的。

运维人员要能够主动发现问题，那么就应该是 风险驱动，而不是问题驱动 。简单来说一个资源层出现的故障或问题，可能在应用层已经积累了1个小时，1天或者更长的时间。整个问题的传导本身也是从最终的业务应用->服务->资源。那么整个的运营监控也必须从应用到服务链到资源全部覆盖，将很多性能问题或潜在隐患及时的发现并解决。

要做到这点， 软件应用必须具备更好的可运维属性。

如何提升可运维属性能力？本次大会有分享提到即在整个软件研发过程管理中，需要引入运维治理的角色，同时将运维评审工作迁移，确保产品设计开发具备可运维属性。

在一个小型应用开发或运维流程不规范的企业，开发人员往往对生产环境发现的问题还能够登录生产环境进行随意的配置修改，查看日志，或者Debug。但是在一个正式上线的系统，生产环境往往受到严格的管控，所有事情开发都不应该有权限。

那么运维发现的一个问题，开发如何去解决？

可以试想下一个对你黑盒的生产环境，你无法Debug，无法查看日志，所有的内容都需要运维人员手工提取给你分析，你也无法在生产环境Debug，在这种场景下排查问题简直就是灾难。这个还没有谈到上到容器云后，所有的容器节点都在动态分配和变化的复杂情况。

正是因为如此，软件在设计开发和实现过程中就必须考虑可运维属性，可监控属性，要方便运维人员去监控和排查问题， 要实现应用-服务-资源全覆盖的性能监控和分析框架。

所以我们在构建DevOps的时候，必须回答软件上线后如何支撑可运维属性？这个如果支撑不好，那么运维到研发的协同会出问题。

在当前的微服务架构和持续集成最佳实践中，可以看到，我们期望达到的一个目标是对于软件的可运维属性能力是类似Sidecar这种方式动态配置和附属到软件上的，只要软件安装标准的开发框架进行开发，那么可运维属性就能够植入。

当然即使这样，很多应用功能级别的日志管理和记录能力，仍然需要开发人员在开发的时候就考虑清楚，这个属于软件非功能性质量的关键内容。

软件过程和质量

如果谈DevOps的三要素协同，即Dev， Ops和QA间的协同。对于QA在我原来谈DevOps的文章也谈到，这个应该是QA和QC，即软件质量保证+软件质量控制。一个是管软件过程，一个是管软件质量，而对于常说的软件静态代码检查，自动化测试等属于QC的内容。

如果将这里的QA理解为测试，那么就需要回顾开发，测试和运维三者之间的协同关系。

对于传统的协同方式我们可以简化描述：

开发编译构建并部署一个版本到测试环境
开发通知测试进行测试
测试验证并提交Bug
开发修改后重新构建版本并通知测试
测试验证通过
开发准备版本发布申请和部署包通知运维
运维进行生产环境部署

简单来讲就是传统方式存在大量往复方式的协同，而在DevOps持续集成下希望的是流水线式的协同，即测试完了不再流转回开发，而是可以直接流转到运维，进行生产环境交付。

在实施DevOps过程的时候，在前面文章就提到必须实施研发过程管理的IT工具支撑，同时这个研发管理工具还需要和持续集成过程，和容器云部署进行紧密的协同和打通。

如果实施完DevOps，你还发现三者存在大量无谓的往复式的协同和沟通，那么整体项目的实施也可以讲是比较失败的。

全链路质量管理

在京东的一个分享材料里面提到了全链路质量管理，这个概念很重要。即质量不是简单的理解为测试或者代码静态检查等。质量是一个覆盖整个软件研发生命周期的事情。

基于这点再来回顾DEV，OPS和QA三者关系更加清楚。

即更加应该将QA理解为在整个Dev和Ops进行产品全生命周期协同过程中的质量质量管控和过程支撑能力。也就是说 没有质量保证的DevOps过程本身没有意义 。

在需求阶段就需要考虑需求的质量，比如进行需求技能培训，需求评审，基于原型驱动现场用户确认方式开发等，都是提升需求质量的方式。在开发阶段就需要考虑开发质量，开发的质量不是测试出来的，而是设计出来。及时到了部署交付阶段，也需要考虑如何提升版本发布质量，减少发布故障和版本回退的情况。

团队重点的需求，设计，开发，测试，运维各个岗位角色都需要有质量意识，为质量负责，而不是单纯的叫质量控制放到测试阶段，或者泄漏到用户使用阶段。

容器云

谈DevOps一般都会谈到微服务和容器云，也就是软件基于微服务架构思想进行开发，通过容器云进行托管和交付是一种默认推荐方式。

上图是一个典型的容器云平台架构。

即DevOps得部署和交付过程需要和容器云平台进行集成，比如调用Kurbernetes标准的API接口来实现基于容器的应用部署和托管，基于容器的弹性扩展调度。

但是容器云并不是一个完整的PaaS平台，在实施DevOps的时候一定要注意到是单个项目级别还是组织级别实施。如果是组织级的实施，一定需要组织级的共性技术服务能力平台，比如常说的流程引擎，4A，消息，缓存等共性技术服务能力。

即共性技术服务能力需要从单个应用移出，下沉到PaaS平台中。这样在构建PaaS平台的时候实际包括两个关键部分的内容。

• 基于Kurbernetes和Docker的容器云平台
• 共性技术服务能力平台（消息，缓存，数据库，中间件）

即共性技术服务能力平台越强大，DevOps实施越从单个项目提升到组织级能力，组织级本身的管控能力越强大，当然带来的问题是单个应用基于组织级能力和资源，标准规范进行研发交付的依赖和约束也就越多。

测试平台和自动化测试

个人观点，在DevOps实践中并不适合再搞一个独立的测试服务管理平台。虽然很多大的互联网会建设自己的测试平台，包括全链路压测，但是对于传统企业数字化转型和DevOps过程实施，大部分没有必要单独构建这个测试平台。

拿测试平台来说实际上也包括两个方面的内容，其一是底层集成的各类自动化测试，性能测试，安全质量测试工具集。其二是覆盖测试设计，测试执行，测试保证总结的测试全生命周期流程管理。

在整个敏捷研发思路里面，测试和开发是一体化的。即需求条目化形成用户故事后，测试是基于用户故事设计测试场景，基于测试场景细化测试用例，同时提交基于该需求点的缺陷并进行验证。

也就是说整个测试过程和研发过程紧密结合，很难完全分开到两个独立平台进行管理。最好的方式仍然是在敏捷研发过程管理平台上拓展必要的测试管理能力。

全链路压测

单链路指一个业务线。全链路压测是一个模拟线上环境的完整闭环。全链路压测希望的就是完全模拟整个线上生产环境，能够发现整个生产架构中某个节点或环节存在的问题点。

全链路压测平台往往包括了压测环境，压测基础数据准备，压测流量模型，流量发起，问题定位五大关键内容，在这里不再展开。

京东全栈测试平台

上图是京东穹天测试平台的一个功能架构图可以参考，同时公布了一个可以互联网访问的演示环节地址，大家可以登录访问看下有哪些具体的功能。

http://qttp-demo.jd.com

里面有很多功能设计在进行DevOps平台中测试模块功能的时候也可以参考。

DevSecOps

2012年， Gartner创建了“DevSecOps”概念，其原始术语为“DevOpsSec”。 DevSecOps旨在将安全性嵌入开发过程的每个部分。这意味着将应用安全思维模式转移到开发团队。

可以看到DevSecOps和AIOps都是DevOps本身发展的一个延伸趋势，对应这块内容暂时不展开描述，感兴趣的可以到网上搜索相关资料。

运维和AIOps

一个完整的DevOps过程，如果从软件全生命周期来说包括了开发过程，运行过程和运营运维过程。开发过程重点是敏捷研发过程管理，运行态重点是容器云，运维态重点是集中化的运维监控平台。

对于运维我原来谈过三方面的内容：

1.运维流程的自动化：包括了巡检，事件问题管理，变更管理，版本发布等
2.运维配置库：最基本的运维配置管理库，从物理资源到逻辑资源到源代码库到服务库
3.运维监控的自动化：包括整体自动化数据采集，监控预警，性能分析，后续触发的自动管控操作

而今天再谈运维，应该有两个重点。

其一是原来基于ITIL的一套运维流程管理平台仍然是必须，这个是讲用户反馈的问题，需求，监控发现的问题需求，形成清单转到研发，研发计划版本修复，最终发布修复形成闭环的一个关键点。即传统的ITIL+研发PMS协同形成完整的闭环流程。

其二是监控本身应该是分层的，从运维走向技术运营，则需要从问题驱动变化到风险驱动，主动去发现系统瓶颈和性能问题。因此需要构建应用->服务->中间件->资源的完整分层监控体系。并各层管控KPI性能指标相互影响，依赖和制约的勾稽关系。

基于日志的自动聚类分析

这个是AIOps智能化运维的一个关键内容，特别是一个大型企业上线的集中化业务系统，一天往往就产生上100G以上的日志数据，及时错误或异常警告数据也几十万条。

单独靠人去检索和分析这里面有价值的信息几乎不可能。

比如大量告警日志都是关于Socket Time Out的，但是告警日志行信息的时间不同，告警的IP地址不同。这个时候我们需要通过日志聚类快速的分析出来这些大量日志实际在说一件事情，即连接超时的事情。

不论哪种聚类方法，实际上有两个关键因素

• 其一是解析和拆分的粒度，即文本串如何拆分？
• 其二是线性相似度比较，什么相似度水平才聚合。

通过日志聚类分析，我们可以更加快速的从海量日志中定位和分析问题，找寻日志中有价值的信息，并有针对性的去分析和改进。

从简单的FAQ到知识图谱

具体发现的问题和解决方案是1对1严格对应的吗？答案显然不是，一个问题往往可能基于不同的场景情况存在诸多的解决方案，需要逐个去分析和排查。

其次，当运维同时发现了多个问题，比如资源符合大，应用性能响应缓慢，内存溢出等，那么这些问题之间有无关联和勾稽关系？哪个是因，哪个是果？这个也必须要搞清楚，否则你就进入了解决问题的错误路径。

而这个就需要我们从单纯的问题到答案的FAQ构建过渡到知识图谱构建，知识图谱要回答的是基于问题和解决方案之间的文章知识结构和展开问题，需要回答的是多个问题或问题KPI指标之间的构建关系和相互影响依赖关系问题。

包括广东亿讯分享材料里面也谈到故障图谱，即基于提取的业务场景相关的运营数据，通过图计算引擎进行处理，生成以拓扑图为核心的故障图谱，包括软件拓扑信息，指标数据，告警数据和日志数据。

智能运维体系架构

上图为擎创科技讲到的智能运维体系架构，这个架构图大家会感觉很熟悉，即智能运维做到后面会变成一个基于运维场景的大数据分析平台。

或者可以理解为 AI算法+大数据分析平台的一个融合。

而且这个平台本身还具备在持续不断的运维过程中进行学习和积累，不断对自己的AI算法模型进行自我修正的能力。只有这样才能够真正称得上是一个AIOps。

即我在前面谈到的，基于人手工设定的规则进行自动化运维和告警分析不是智能化运维，只有能够自动通过学习形成规则或对当前规则进行调整，才是真正的智能化运维。

同时在分享材料里面提到了智能运维检索的三原则和六步骤，可参考：

平安科技-智能化运维

在前面谈智能化运维少谈了一个内容，即智能化运维本质是基于场景的，智能运维不能脱离场景。而实际的场景在平台分享材料谈到三个方面，即智能检测，智能定位，智能预测。基于底层大数据平台和运维中台的能力建设，来服务上面三个关键场景。

平安科技分享的这个材料个人认为具备很好的实操价值。实际上在我们SOA项目建设和SOA治理管控能力提升中本身也在考虑这两个方面的内容。

其一是如何对服务运行，中间件运行，资源运行监控的各个KPI性能指标数据进行更好的智能检测和定位，发现差异和突变点。其二则是如何对海量的日志信息进行聚类分析，找到关键的问题点并进行优化。

腾讯运维分享-故障定位分析

给出了要给故障定位和分析的双向分析方法，值得参考。其一是向上影响评估分析，简要分析对用户侧的影响，以便上升决策。其二是向下故障初因分析，初步判断故障点，不要分析故障的根本原因，优先判断可恢复故障的操作。

可以简单的举个例子来说明双向分析的一个思路。比如当前我们收到到数据库服务器的一级异常告警，数据库状态不正常。

向上分析：服务运行不受影响，服务新增变更操作受影响，同时会导致大量消息在消息中间件堆积。
向下分析：数据库磁盘损坏导致数据库异常。

当进行了详细故障定位分析后，我们才知道如何采取后续操作。

中国银行分享-故障管理

MTBF：Mean Time Between Failure，平均故障时间间隔，系统正常运行
MTTR：Mean Time To Repair， 故障平均修复时间，系统发生故障

整个应急目标即是提升MTBF，降低MTTR。

度量分析

前面谈到了研发运维一体化，并通过流程支撑来形成研发和运维的闭环。在形成闭环后还有一个关键就是这个闭环流程如何持续优化改进？

即DevOps的过程效能如何优化？

在DevOps实践里面经常会强调组织和团队文化改进，另外一个重点则是要形成数据驱动的度量意识改进。虽然说不能完全依赖数据，但是数据往往可以更加客观的反映现状。

效能包括效率和质量，不是简单的自动化。

比如在实施DevOps后，我们通过流水线实现了整个持续集成和交付的自动化过程，最终流水线执行效率很高，自动化效果也完全达到，那么是否研发效能就高？

而经过详细度量数据分析，你会发现交付产品的代码缺陷避免很高，同时需求变更率也很高，这显然说明了我们软件交付质量有问题，需要改进。这个改进不是简单的自动化能够解决的，完全需要进一步提升人员技能，提升类似需求评审，代码评审等工作往往才能够改进。

既然DevOps的三要素有个重要的QA要素，那么就需要考虑不仅仅是解决自动化和生产率问题，而是要关注质量问题。软件质量提升不是简单的自动化就能解决的。