2021年GOPS全球运维大会深圳站材料学习总结0521

　　上个周末，2021年全球运维大会在深圳召开，对于去年大会材料我也做了详细学习，整体感觉内容会更偏运维侧，因此这次会议只安排了团队两个成员去参加学习，自己刚好周末要开公司月度例会也没去现场参加。只能是后续根据分享材料做下学习和总结。
　　首先说下就分享出来的材料的总体感受，这届大会整体的材料和分享内容和上届比起来没有太明显的提升或新增过多的有价值的亮点和实践。这种会议演讲嘉宾一般还是包括了两个部分，一个是大型集团性企业本身内部的DevOps和AIOps最佳实践，另外一个就是偏Ops厂商的一些产品解决方案宣讲。
　　由于没有现场参加，因此这篇文章整理的内容只能来源于分享的PPT学习，更多的是这些内容触发的我对整个云原生和DevOps发展演进的一些思考。所分享的一些观点也仅仅代表个人观点，不代表演讲嘉宾的观点。521上午主会场
　　上午主会场从分享出来的材料看有些可能涉及到安全性要求没有具体的文档分享，因此仅从公开分享的材料做下学习和整理。
　　基于大规模运维数据的云原生软件多维度分析
　　这个是复旦大学彭鑫教授分享的一个主题内容，开篇就提到了在整个云计算和云原生，微服务发展趋势下，整个IT应用正演化为一个复杂的生态系统。
　　整个软件生态系统核心特点就是规模化，组成复杂，交互复杂，依存关系复杂，监控复杂，而且是一个逐步去中心化，自适应生态系统。
　　这个观点个人相当赞同，整个软件应用就是大规模化，并微服务方式的细粒度化，如果不从软件生态体系角度来思考，无法做好后续运维监控，更加无法做好整体的IT管控治理。
　　在这个个人再次推荐KK的《失控》这本书，即使多年过去，这本书很多思想仍然适用，特别是里面对整个生态，对去中心化架构模式的理解，包括如何在一种看似失控，看似无序的生态体系中找到真正的有序，做到自我生长，自我适应，自我演化。
　　该分享材料里面提到了类似服务链监控和分析，服务依赖关系分析，业务流分析，故障定位和传播分析等。这里面给自己最大的一个思考如下：
　　传统的运维监控分析，即使从资源层抽象到APM的应用和服务层面，但是更多的仍然是技术分析，是技术人员在做。那么势必存在业务链和业务流程和具体的技术服务链之间的割裂。技术人员不懂业务，业务人员也不懂底层技术，导致这种割裂。
　　而我们真正需要的是业务监控和技术监控的高度融合。
　　简单来说业务监控从单纯的业务功能点能够到端到端业务流程，能够快速的跟进业务性能问题或故障定位到具体的技术服务再到具体的资源；反过来，通过技术监控发现的技术故障又能够快速的进行故障影响和传播分析，确定会影响到哪些业务。
　　数字化转型和数字化挖坑
　　这个是腾讯的一个运营部经理分享的内容。
　　首先说明下这个标题取得太大，从分享的PPT内容来看完全驾驭不了。其次即使回到云原生和研发运维一体化这个范畴，单纯从PPT层面看很多内容也介绍得不太清楚。
　　实际上我在前面很多DevOps的文章都谈到过，对于传统的运维部门来讲，在当前数字化转型和云原生发展趋势下，不仅仅是做好研发和运维之间的一体化协同，更加重要的是运维如何走向运营，如何从被动的问题驱动变化为风险驱动，从技术监控变到业务监控，从事后控制变成事前参与。
　　对于研发更多思考的是如何微服务化和CI/CD ，而对于运维角色一定要思考如何由被动变主动，由简单的运维变成技术运营。
　　金融业数字化转型和云原生驱动力
　　这个PPT基本没有看到太多的有价值内容，不清楚是否是由于做了脱密处理的原因。
　　对于金融行业一直是云原生和DevOps推进的一个关键行业，整个数字化和信息化发展水平都相对来说更加成熟，类似平安，招商银行，浦发，中信，各大证券公司基本都是数字化转型和DevOps实践者。
　　当然金融行业的大企业基本也都是自有IT人员，自己在自主建设和实施这块的内容。除了自己做外，对于外部参与的主要供应商主要有神州数码，润和软件，普元等。
　　TDengine时序数据库
　　时序数据库全称为时间序列数据库。时间序列数据库主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。
　　对于时序数据库当前更多的是应用在物联网和云边协同的场景中，由于本身需要支撑的数据结构和数据关联逻辑相对于传统结构化数据库更加简单，因此采用时序数据库可以获得更好的性能和扩展性。
　　在多年前，我们也采用了InfluxDB来做具有明确时间序列特征的资源性能日志KPI监控展示，因此在云原生整个发展中，对于云原生的监控运维领域，很多KPI指标的实时性能监控和分析都可以采用时序数据库来进行关键存储。
　　在下午鼎茂科技的时序数据库产品分析里面也有一张PPT专门谈到了时序数据分析的意义，可以参考，也就是说上面这些实际也是在传统的应用软件领域可能会涉及到时序数据分析的一些关键场景。AIOps最佳实践和解决方案
　　AIOps 自从 Gartner 于2016年提出至今已有一段时间，虽然在顶级互联网及电信企业，已有较多落地，但至今仍无基于生产实践的理论体系及实施指南。AIOps，即 Artificial Intelligence for IT Operations，智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维没办法解决的问题。
　　对于自动化运维阶段，我的核心理解是：
　　自动化运维是基于预先定义好的规则，通过实时的资源和应用性能采集后进行计算，当满足某种规则的时候自动触发相应的可重复执行的运维脚本。
　　而到了智能化运维阶段，可以理解为：
　　智能化运维是在自动化运维基础上，具备了基于人工智能和深度学习等算法，实现规则的自动生成，已有规则的自适应调整的自动化运维。
　　也就是说智能化运维必须具备规则自动生成，自适应调整能力，否则都不能叫做智能化运维，而最多算做自动化运维。而要做到这点，即涉及到AI人工智能里面的机器学习，深度学习方面的内容，如聚类算法，神经网络，预测模型等。
　　智能运维的实用性和易用性探索
　　这个是复旦大学王鹏教授演讲的一个内容，从上图可以看到对于算法能力，数据语义融合，异构数据管理和数据探索是智能运维的核心能力。
　　在去年的GOPS大会上，我印象里面王鹏教授也做过智能运维和日志聚类分析的主题分享，这个材料本身对于构建智能运维体系来说有很大的参考价值。
　　就个人思考来讲，在前期重点去解决日志聚类分析方面的问题，通过日志聚类分析可以进一步完善运维知识库体系，在后期那么就是语义分析和构建运维知识图谱。当运维知识图谱构建得足够完善的时候，基本能做到全面谈到的智能化运维，自适应调整等关键能力。
　　对于运维知识图谱来讲实际包括两个方面的关键，其一是需要构建完整的应用-服务-资源三大核心要素之间的关系和依赖图谱；其次是构建业务问题和技术能力之间的勾稽关系和知识图谱。
　　以上所有目的都是当出现具体业务问题的时候能够马上定位到技术点或资源，而技术出现故障的时候也能够马上分析到具体的业务影响面。
　　运维数字化和智能化
　　擎创科技2016年成立于上海 国内首家专注于智能化运维，是AIOps的解决方案供应商，以AI激活运维数据智慧，助力客户数字化转型 GartnerAIOps领域重点推荐服务商。
　　整个分享的PPT内容和质量还是相当不错，智能运维一个关键点就是数据驱动，数据驱动是将运维从传统的被动运维，从出现问题的工单流程驱动处理，转变为智能化运维，风险驱动的一个关键点。
　　所有当前的整体IT运维不是传统方式下的上一个IT监控系统，实施一个ITSM系统就完事的，而是真正要基于数据驱动思想，将运维转变为运营，将问题故障驱动转变为风险驱动。
　　一个智能运维平台本身就是面向IT或IT运维领域的BI系统。
　　因此可以看到一个智能化运维架构体系，其底层首先是分布式的大数据存储能力，支持结构化，非结构化各种海量异构数据的存储。在数据层上面是关键的算法和规则层，即需要基于运维采集的数据进行计算和加工，并和规则进行匹配分析。最后才是上层的各个监控类应用，问题管理，变更管理等工单运维流程等。
　　对于上图的智能运维能力体系规划比较有参考意义。也就是一个智能运维体系，在应用层重点是智能监控和快速的故障定位和影响分析；在服务层则是智能算法库，规则模式库建设。同时服务层又有效地支撑前台应用。
　　如果没有智能化的算法模式库，那么最多是自动化运维而非智能化运维。
　　金融行业监控系统开源之路
　　这部分主要是Zabbix开源监控软件的介绍，可以看到当前Zabbix应用相当广泛，我们自己也在使用，完全开源。原来重点是资源层，中间件的监控，到6.0版本后也开始支持APM，支持Kurbernetes集群监控等关键内容。
　　当然Zabbix本身APM和服务链监控方面内容相对还是缺少，因此对于服务链监控，APM应用性能监控等还是得配合更上层的APM等监控工具来实现。但是常说的服务器，虚拟机，存储，网络，数据库和应用中间件，JVM，线程池等这些关键内容基本完全包括。通信运营商专场
　　对于电信运营商来说，在云原生和DevOps，AIOps方面基本还是走在行业前列。运营商内部的云原生技术平台基本都包括了DevOps，容器云，监控，能力开放等几个大的能力平台。在前面我做过电信和联通各自云原生平台的对比如下：
　　对于中国移动也自建了自己的云原生平台，主要是磐舟研发管理和DevOps平台，磐基的容器云平台，并且已经在自己的多个子公司全面实施，内部MBOSS域的各大业务系统也在逐步迁移上云。
　　这次GOPS会议，上午电信集团的陈处做了电信上云成果方面的演讲，而下午电信运营商专场则基本全部是联通集团在讲。围绕自己的天宫，天梯，天擎等几个核心技术平台展开。
　　联通天梯DevOps平台
　　天梯平台是以数字化底座为核心组件，由软研院自主研发的一套贯穿需求、研发、测试、发布、生产、治理全生命周期的 DevOps体系工具平台。通过敏捷开发、持续集成、服务治理等方法，为数据化IT中软件交付与效能提升提供端到端的整体解决方案 及体系支撑。
　　简单来说当前电信各家的DevOps平台核心还是三大内容，重点包括了敏捷研发过程管理，CI/CD持续集成和部署，自动化测试和安全管理三方面。
　　天梯平台集成整合了现有工具体系，打通多个系统之间的壁垒，以开发者为中心，为开发人员提供从需求到版本发布的一站式协同开发 服务，该平台将各类系统信息与能力聚合给开发者使用。
　　当我重新思考DevOps的时候，实际我们看到整个研发全生命周期过程的长度远远超过简单的CI/CD，这个不仅仅是前端的需求管理和版本规划，更加重要的是另外一条线，即业务系统注册后的资源申请和技术服务申请，资源和服务申请也应该做到完全的自服务，并和整体的持续交付流程集成在一起。
　　度量实际是整个DevOps最佳实践里面另外一个关键内容，度量是驱动整个软件过程闭环和持续改进的基础，DevOps的度量实际是对传统软件工程和CMMI度量的进一步延伸，增加了对整个CI/CD过程，持续交付能力的度量。
　　天眼实时监控平台
　　天眼是联通整体云原生架构里面的监控平台，实现从资源到服务，从服务到应用和业务的端到端监控能力。一个业务系统即使你没有做微服务转型，还是老的IT架构，实际当前也是支持接入到天眼统一监控。
　　微服务监控三大核心融合贯通：基于Metrics的告警发现异常，通过Tracing定位问 题模块，根据模块具体的Logging定位到错误根源。从当前天眼的监控功能层级也可以看到完全覆盖云计算的三层，从资源到服务，从服务到应用能够做到端到端监控能力。
　　任何一个监控平台，简单来说几个大的核心内容包括：性能和日志的实时和准实时采集和适配能力多种异构数据的大数据存储能力监控规则设置，监控预警触发的算法能力
　　这三个内容后面才是说前端如何可视化展现，各种KPI报表能否灵活配置，可视化大屏能否灵活配置等。这些前端的内容相对更容易实现。
　　天擎能力开放平台
　　这个类似互联网的OpenAPI能力开放平台。实际最早运营商在做PaaS平台的时候就在推能力开放平台，因此从传统PaaS演进到云原生PaaS的时候，同样存在能力开放平台。
　　能力开放平台底层类似采用API网关引擎来实现API接口服务的统一注册和接入，并对接入的服务构建上层的能力接入，能力订购，计量计费，自服务等各种能力。
　　对于能力开放平台，我前面专门写过文章可以参考：
　　从能力开放平台到能力中台构建思考腾讯运维和DevOps专场
　　智能运维，将AI应用于运维领域，基于已有的运维技术数据(日志、指标、事件等信息)，通过机器学习的方式式来解决人工或者单一规则无法完成的事情,涉及到 很多运维场景,监控、效率、安全、成本等方向。
　　蓝鲸当前是腾讯内部的一个大运维平台，包括了相当多的内容，整个蓝鲸平台也开源，但是实际有用太过于复杂，当前外部企业使用这个平台的并不多。
　　我们用下图来做个解释。
　　当前大部分的AIOps重点都在做蓝色虚线框中的自动化监控和基于规则的自动化实时告警，但是告警出来后仍然需要人工分析和判断，并去采取后续的修复步骤。类似红色虚线框的内容。因此如果红色虚线框也能够完全智能化，才是真正达到一个AIOps智能化运维的状态。
　　运维低代码开发平台
　　在这里先谈下日常运维流程自动化的做法。
　　当我们要执行一个涉及到多个步骤的运维自动化流程的时候，一般会自己写脚本，或者采用类似Puppet工具来定制运维脚本，并将各个步骤编排在一起。然后设置定时作业等定时去执行。
　　所以这个时候你可以看到运维自动化脚本往往没有前端界面，其次各个步骤的编排是脚本写好的，无法灵活的组装编排等。
　　因此基于运维的低代码平台实际包括三个方面的关键能力。前端展现界面的快速定制和配置提供类似流水线设计方面的多节点灵活编排抽象底层核心运维能力形成可复用API
　　这三个方面实际就是运维的核心内容。即使第三步可复用API抽象不足，也要优先实现前面两点，那么运维剩下的工作仅仅是对底层任务节点的脚本编写，其它都可以配置。
　　运维DevOps金字塔模型
　　在这里还是简单讲下DevOps整个演进，从最基础的CI/CD能力发展到融合敏捷研发+自动化测试和安全检查是基本要求。其次就是对于大型工程项目，流水线设计需要支撑多级流水线，需要支撑集合检查点，人工审核，需要实现CI/CD过程和生产环境交付发布过程的分离等。
　　最后还有一个京东分享的《数智化时代运维机器人的诞生》这个材料触发我很多思考，后续再专门展开。整个PPT材料脱密后很多内容也有参考价值，但是没有听现场只看PPT很多地方无法了解。
　　注：该文无对应材料分享，勿发求材料的私信。