一、业务云上面临的问题

本次分享主题云上DevOps自动化最佳实践。在当前的大环境下，更好的控制成本和进行运维提效，帮助业务进行更自动化以及更低成本的使用云计算。下面带来使用阿里云产品的一些方法和技巧，在用云上云和管云的阶段更加的轻松以及更有效率。首先随着云计算作为基础设施服务越来越多的客户，如何使用好云逐渐成为云企业的头部挑战。

困扰大家最多的问题主要是进行成本管理和运维的成本提效，自动化的落地可执行可复制的实践方案进行治理，让企业从花钱买效率到管理换效率的转变，在云上的业务会面临问题，在企业最初上云的过程当中，更关注云安全以及企业上云的成本效益，逐步的开始到全面上云到逐步上云的阶段，逐渐的关注成本效率和弹性，通过成本效率和弹性的的关注提升集成效率，开始关注企业内部的系统和云上的系统进行集合，能够更好的提升企业的云资源的优化使用，进行一个成本控制。

随着企业用云的深入之后，开始把关注点转化为变得更自动化，持续的用云，更好的利用云的创新性帮助企业做业务决策和战略目标的规划。不同阶段的关注点反映企业在上云的成熟度和战略目标，从最初的安全成本到逐渐的转向为效率弹性，再到持续的深度的运营阶段，各个方面都持续的进行一个关注之后，今天的重点会落脚在进行成本管理，效率管理和弹性。

 

二、云上成本管理治理流程

成本管理连续多年基本上都是成为云挑战Top3的问题，更有甚至于连续两年已经成为上云过程当中最关注的问题，从成本管理介绍。开始发现上云的成本管理随着不断的越深入，越发现问题的本质不简简单单是技术问题，也不简简单单是业务问题，它是跟组织业务流程技术都是息息相关的，从ECS的视角做好成本管理事情，首先做好成本管理分四步，在用云的初始阶段，推荐大家尽量的充分利用云的付费类型的特点，通过组合付费类型的方式达到能够降低成本的目标，比如可以通过预付费的实例覆盖基本不变的诉求，通过按量和抢占式的实例覆盖动态变化的部分。

通过选择合适的付费方式之后，要进行一个合适的规格的选择，弹性计算推出非常多的实例规格，可以覆盖各种各样的场景，要结合业务的特点进行实例规格的选择，比如这里面列出在大数据的场景推荐一天的g8y实例，在数据库的场景推荐英特尔的g8I实例，在客户推广搜索推广场景，推荐AMD的g8a实例，以及在一些web场景的话，更推荐经济型的e实例和通用算力型的u实例进行使用。在资源的付费类型和规格的选择之后，还要关注资源的使用率，资源的使用率要结合业务的判断进行资源使用率的基准。如果出现资源的使用浪费的时候，可以通过变配还有动态的调整以及停机等方式降低成本，从而实现成本的最大化的使用。

前面讲的三步其实都是在资源维度上做好成本管理，接下去在资源的成本费用层面上，进行更好的成本管理，首先可以通过资源的成本分析，通过资源的预算管理异常管理等方式进行成本的分析，反向的驱动资源的付费类型和资源规格的选择，通过把成本管理融入到日常的管理当中，通过不断的实践循环可以形成降低成本的效果。要进行成本降低的效果需要更好的进行成本分析。

接下来进行更好的成本分析。首先通过人财物进行企业管理的，云上是通过产品管理的，企业的管理和云上的管理之间就会存在差异，把企业的管理和云上的管理进行连接，同时企业有不同的角色，比如运维管理者，可能更关注的是运维的成本，要更好的控制运维成本。

对于财务人员更关注的是财务成本，对于企业的管理者更关注的是整个企业的人效以及经营运行的成本，如何让各不同的角色能够更好的进行管理。首先可以简单的通过标签进行资源的多维度的标记，比如企业的管理者可以通过资源企业的部门信息，将资源的部门标签给打上来，这个时候可以看到企业的人效情况，同时不仅关注企业的人效情况，企业还有很多的项目，可以通过项目标签把企业的项目的人效情况进行识别，这样就可以通过不同维度的识别，更好的看到企业在不同维度的成本情况，通过成本情况以后责任下发，通过各个业务单元责任成本自治的方式实现成本的全企业的管理。

标签不仅能够实现这种信息标识和分类标识的作用，它还可以进行一些关联串联，包括协同能力，比如企业可能存在多账号，比如多个账号之间要统一管理，管理标签可以实现多账号之间的统一协调管理，同时还存在多个账号，但是不同部门之间标准是不一样的，也可以通过不同的账号之间设计不同的策略，实现不同账号之间的差异性管理。

成本管理的标签能够助力企业的成本分析管理，接下来看标签是如何助力资源的高效管理的，图中非常明显的可以看得到是通过应用标签的资源分析，从成本分析的图中，零售业务系统的费用是最高的，零售系业务系统的业务成本占比是最高之后，要持续的进行分析，通过使用率结合业务的基准判断，如果磁盘使用率低可以通过容量变更或，使用率过高可以通过容量的扩容，通过资源的变配选择合适的规格进行资源的使用。同时存在资源浪费的时候，可以通过释放或者停机，如果还想保留数据的时候，可以通过节省停机模式释放计算资源，固定公网IP以及镜像的许可证的方式以达到成本降低的效果。

刚才讲的都是从资源成本分析，在使用云的时候，也提供非常丰富的付费类型，当使用折扣的方式，既想利用云的灵活性，同时又想享受折扣的时候，使用折扣型的一些资源的时候，要关注使用的折扣型资源的使用率和覆盖率，通过持续的关注反向的驱动，驱动付费类型的选择，驱动资源的选择，通过把成本管理融入到日常的流程当中，实现成本的有效控制。标签可以助力成本的管理，进行标签的设计，首先标签设计目的是为帮助企业更好的进行管理，比如运维人员希望能够更高效地进行资源管理，面向业务可理解打一个标签的目的是为后续的成本管理运维管理。

第二要进行规模化的复用，比如企业部门维度实际上只有一个维度，不需要很多的各种团队设计部门的维度，可以通过规模化的复用对后续的管理运维安全成本等各个的场景里面进行应用，通过应用之后，就可以很明确的知道设计的分类背后的价值是可衡量的，它能够给企业带来成本效益。通过这样的目标之后，进行标签设计，才能够帮助企业更好的进行费用管理。

首先要先定义标签分类，要进行标签件的设计，比如企业的管理者设计企业的管理叫做业务单元，业务单元的目的是为将成本能够变成业务责任制，设置业务单元分类，设置完分类之后定义对应的值，定义值的规范，企业的业务单元确定业务单元是明确的，要定义业务单元里面允许哪些范围进行管理，第三需要定义资源的应用范围，也就是资源到底是针对ETC有效，还是针对整个阿里云的所有资源有效，定义需要应用的范围,结合应用场景，看定义的范围以及标签线标签值它要作用的场景,比如比较常见的要进行运维管理，需要后续要自动化，要定义应用的分类，成本管理通过业务单元进行成本管理。

安全管理需要通过把资源分摊到责任人，需要归属者的设计进行安全管理，通过这样就可以把整个标签设计设计出来，并且应用到对应的场景实践里面。这个时候会存在更多的业务，比如作为另外一个更多的业务的时候,财务人员视角和运营人员的视角是不一样的，需要有独立自己的更多的分类的设计，通过这样的设计就可以把不同角色下的标签能够更好的分类起来，在设计过程当中进行一个标签实践之后，讲键值的设计可以为后续的成本管理做数据准备。在设计的过程当中要关注设计本身规范进行设计，首先要求在设计的值就设计的分类是尽可能忽视的，比如要设计部门值可以用英文的department，可以用中文的部门，但是不能同时用，只需要用一个分类分清楚类别以及定义，所以最好是对应的分类是要忽视的。

第二个是集体详尽原则，当在设定分类的时候，希望能够覆盖所有的资源，肯定不是管三种产品的资源,要覆盖全产品的资源进行管理。第二在设计值的时候，需要一个有限值原则，在设计的时候需要关注对应的值能够应用的范围，因为越多的值会带来一些管理的难度,第三在设计的时候，要精简件的设计，之前说要结合自己的业务设计分类，这个时候又说要精简件的设计，实际上是从管理的最佳实践上来讲，企业通常的管理分类维度一般都不会超过十个，基本上十个都能涵盖在各个业务方面的分类。

另外是要考虑未来的变化带来的影响，比如当设计分类之后，设计部门的分类组织会调整，部门的值会发生变化，背后的成本分摊和安全管理也发生变化，需要考虑对应的变化带来的影响。这里有个事例，这是某客户在管理非常多的地域以及非常多的云产品的时候，进行更好的资源管理的事例的特点，比如经常会遇到的项目管理，大部分的企业都会基于项目制进行项目的开发，利用项目进行成本责任制，或者是项目的资源管理以及资源基于项目的权限管控管理，可以通过标签简单的配置之后就能够实现这样的逻辑。

第二经常会遇到的需要应用管理，把业务系统里面的应用和云上的应用相关联应用，标签应用就可以实现的逻辑。通过这样的原则，可以看到进行更好的标签设计，有一个客户案例，客户在没有标签设计之前需要做成本管理，它的成本是混在一起的，无法分摊到对应的部门，或者是项目组和业务线，整个分账分不清楚，突然的决定会导致成本无法跟业务关联，无法更好的帮助业务提效，包括管理者或者CTO，无法看清楚成本的构成，无法进行成本优化，这个时候进行资源的达标之后，可以将资源分到各个部门。比如某营销类公司可以分成市场部、品牌部、广告部和公关部进行资源的分类，进行资源的管理和控制。比如品牌部在部门分类之后，可以进行根据不同的品牌进行分类，看每个品牌的成本效益，资源费用和成本效益之间的关系。可以更好的进行成本的控制，对于广告部可能就是项目责任制，在管理广告部的资源的时候，可能就要通过项目的方式把资源分摊清楚，分摊清楚之后，可以看到每个项目的人效情况，就能够更好的将项目和资源以及成本包括效益挂钩在一起。

这是一个简单的企业的费用管理，如果是大型企业或者是较复杂的企业，在管理的过程当中进行成本管理，首先较复杂的企业推荐用资源目录进行企业的组织的设计，通过企业的组织设计之后，将子公司是用独立的账号管理的，好处是相当于独立账号的成本天然的就是可以独立管理的，同时可以通过资源目录对整个企业的资源进行统一的管理，可以通过标签对资源更精细分类的管理，通过标签对部门或者对应用业务进行更精细的管理，同时可以通过标签的规范，在不同的场景下可以针对不同的账号设定不同的规范原则，把成本分摊到组织架构下更好的把成本优化掉，以及更好的降低成本的效果，也就是需要把成本就是集成到日常的管理当中，才能够更好的进行成本规划。

接着来进行成本优化。首先前面提到要充分的利用云的弹性来满足自身的业务要求，ECS的弹性快速的使用,推荐用户使用弹性伸缩产品解决弹性的诉求，弹性伸缩产品是阿里云弹性的最佳实践产品，它为了解决弹性而帮助用户减少人工的介入，以及更好的降低成本满足业务的变化。同时通过弹性能够轻松的实现定时动态、手动等的伸缩模式实现不同场景的诉求，同时提供丰富的产品功能提供不同场景下的弹性能力。比如可以结合多规格、多可用区、多付费类型的方式，实现付费类型的特点，以及资源券的结合，实现成本的降低以及控制。

业务可以结合自己的特点选择对应的组合实现成本的优化。成本管理在上云的时候选择合适的付费类型，选择合适的规格，监测资源的利用率，通过成本分析进行成本控制，反向的驱动资源的管理，将成本的管理融入到日常的流程当中，实现更好的降低成本的目的。云上的用户除了关注成本和弹性之外，还非常的关注效率。从效率的维度上进行资源管理,这个是DevOps自动化的成熟度的演进路径，首先分为三步，首先要将资源细分到最小的粒度，细分到最小的粒度是比如运维人员可能关注的最小粒度就是应用，对于安全人员关注的最小粒度可能就是资源责任人，不同的角色可以设置自己的最小的粒度，同时结合一些工具类的产品实现在资源管理资源部署以及自动化生产的流程当中实现部分流程的自动化，从而实现团队业务的流程自动化，在不断的业务自动化之后，要全面的进行业务的场景的升级自动化，要结合多个工具产品，结合业务的流程实现全面的业务自动化，从而实现自服务化以及智能化的效果。

着重下面两个部分介绍利用云上的工具提升能效。前面介绍在成本管理的实践当中，标签不仅可以进行成本管理，同时运维也可以通过标签的细分之后，通过分组进行资源的部署，应用的管理，资源的运维以及持续的集成和持续的部署，接下来在四个方面展开介绍，利用云上的产品实现对应的这几个方面。在云原生越来越盛行的今天，快速的在云上搭建k8s系统，成为越来越多用户关注的问题，资源编排可以帮助用户轻松的搞定，只需要一个Json或者是可视化的编辑器，简单的配置之后就可以初始化资源，并完成所有资源的生产。比如在中间场里面，可以看到一个k8s集群涉及到的资源非常多，包括ECS内的网关ELB等等各种资源，定义资源的依赖关系和初始化方案，只需要一键就能在任何地域和账号把k8s的集群创建出来，做到基础设施及代码的效果。而且也有官方的模板，包括通过自定义的模板实现资源的快速的自动化的部署。在部署的时候只需要通过设置标签的方式，就可以实现应用的资源交付。

除了在资源部署的维度上，在日常的过程当中，会遇到日常发布的问题，利用云上的工具实现一次蓝绿发布或者金丝雀的发布，可以通过系统运维管理实现减批量的滚动发布能力，只需要通过标签实现任何一批资源的发布，分批之后，通过执行更新镜像或者拉取应用的方式就可以完成发布，发布之后可以根据结果选择继续回滚还是重试，通过这样的过程就可以持续多批的完成整个发布工作，只需要简单的几个参数配置就可以完成，无需构建一整套发布系统，也可以通过云校或者是开源的工具进行持续部署的自动化，这个是日常的发布。在更多的场景里面，除了资源交付和自动化部署之外，在日常的扩容当中以及日常运维还有安全补丁以及故障运维的场景里面，可以结合云上的工具实现各种场景的自动化。

比如在安全补丁层面上，可以利用系统运维编排场景的补丁管理，能够实现安全补丁保障系统的安全，包括一些故障的场景可以通过告警的异常或者异常的事件，通过监控事件的方式对异常的资源进行自动化的运维，比如同级等等。通过前面介绍资源交付集成的部署，持续的集成和持续的部署，在资源的多场景里面，可以看到实现资源的自动化的部署。

 

三、新功能发布

接下来看对应的产品新功能发布。首先标签是可以实现资源的成本管理，包括运维管理的基石，保障标签的规范管理有几个场景，第一个就是上云有很多的云资源在使用，保障资源能够规范的使用，可以通过标签策略场景，只需要设置一个标签策略之后，通过标签策略的设置就可以满足在增量生产的时候，如果它不符合规范，就不让生产，这个时候就防止增量不规范资源的产生。第二个对于存量资源，可以通过存量资源的检测，把不规范的资源统一的检测出来，可以通过不规范的检测实现对于资源的标准化的治理。这个就是标签策略产品。

接着看在云上的资源使用过程当中，看到会经常遇到一个问题，比如想使用关联的资源，使用关联资源的时候会存在问题，使用ECS要关注EIP和磁盘，这个时候提供一个产品包，就是在ECS发生和从资源发生绑定关系，或者是主资源发生标签变化的时候，可以通过资源的继承自动的管理，也就是在管理资源的时候，可以简简单单的管理对应的总资源，就可以实现从资源的对应的标签跟随能力，这个就是通过资源关系的配置节省整体的管理成本，而且非常简单，它只需要开启，不需要额外的操作。

接下来是资源部署的能力，在资源部署的时候会有一个问题，要了解非常多的语法知识，这个时候不想了解语法知识，有办法结合资源诉求，就快速的帮生产出一个可运行的模板，只需要在运维编排地里面通过语言化的描述，比如想生产一台ETS，包含Vivi switch以及安全柱，它就会自动化的生成对应可执行的模板，并且自动的校验和检测，自动的修复实现可用的模板，大大降低资源编排过程当中的使用门槛。接下来就是系统运维编排场景，系统运维管理场景系统运维管理提供很多的扩展程序，能够帮助用户在实现开发环境的安装，应用软件的安装，还可以结合一些业务场景自定义模板，实现业务的搭建的简便性，快捷配置支持多地域的同步配置，可以消除配置的漂移，实现运维的多地域的应用，能够帮助客户在各个应用场景的使用，不包括一键的安装软件快速配置，能够将数百台的ECS实例的安装从数个小时提升到10分钟。

简单总结，在成本方面可以通过标签进行精细的成本分析，在弹性伸缩方面可以利用弹性实现弹性降本的目的，在自动化方面可以结合资源编排实现基础设施及代码,助力资源交付的自动化。在系统运维管理方面，可以借助系统管理实现持续的集成和持续的部署的自动化，自动化不仅仅是产品的使用，更是组织业务流程多方面的有效结合，企业可以利用介绍的最佳实践帮助提效，助力企业在上云用云管云的阶段的效率提升。

 

四、实例运维通道全终端统一界面

下面介绍实例运维通道多力云上运维自动化智能化。包括以下四个方面，当前实例为通道产品所面临的挑战，在解决挑战所做的一些工作，分享客户的案例，最后总结以及对未来的展望。首先是实例运维通道目前所面临的挑战，归纳成四个方面，第一使用周期比较长，实例运维通道贯穿用户实例的全生命周期，从实例的购买到最后的释放，用户都需要频繁的登录实例完成工作，因此这就需要产品要足够的简单。第二终端产品比较多，需要支持像Linux操作系统， windows操作系统，还有一些容器终端，像SK SS，都需要使用运维通道执行一些运维操作，因此运维通道需要兼容庞杂的协议。

第三就是操作比较复杂，用户使用运维通道主要是执行一些复杂的指令操作，比如像应用的发布，应用可能是Java应用或者高量的应用，又比如需要执行一些监控用的脚本，这些脚本都各种各样非常复杂，因此需要将这些复杂的操作可以归纳成简单的自动化的工具方便大家使用。但是能够抽象和归纳的工作毕竟是有限，因此还需要探索借助AI更好的辅助客户。最后就是交互场景比较复杂，客户除了阿里云中控台的直接客户，还有一些多云集成商，还有大集团客户，他们也需要使用运维通道登录实例，这样交互场景就不仅仅是阿里云控制台，还可能是竞争方的内部系统，因此交互场景会比较复杂，这也对产品造成一定的挑战。

首先通过统一的操作界面，在这个界面上可以自动的识别用户登录的终端类型，不需要用户手动选择，从而简化用户的操作。目前支持以下多种协议的登录方式，首先可以使用像ROP协议登录用户的windows机器，使用SSH协议来登录 Linux机器，借助云助手可以实现免密登录，可以使用ACK的协议实现容器的终端登录，还支持在内网环境下代理ACS下的EPS和load balance，用户就不需要在应用机器上挂载弹性EIP公共IP，就可以实现安全的登录自己的APP和TCP应用，可以降低用户的运维成本。

目前这个协议已经在计算槽当中上线，服务众多的上市产品，比如之前比较火的像帕鲁等等。经过努力，多个终端产品目前已经实现用户的跨越式的增长，比如沃克曼奇目前的累积客户已经超过了百万，累计登录的终端目前已经超过了千万，每天用户数已经是大概几万级别，还有云助手，包括使用云助手进行免密的终端登录，还有命令执行，目前它的日活和周活都已经超过几万的级别，它的月活已经突破了10万。最后还有购物单工具，购物单工具目前还没有大规模的推广，但是目前它的日活和周活都已经破千。在简化客户使用的运维通道登录实例的基础之上，还对用户的运维操作进行归纳，做成自动化工具方便客户使用。

比如在2020年左右，推出一个用户资金任务计划，客户可以在界面上编排一些简单的运维监控脚本，部署在产品之上，可以定义它的执行计划，比如定时执行或者周期执行。在今年和阿里云的ATP平台进行合作，进一步对客户的常用的应用操作进行深层次的定制，比如 Java应用的一键式的运维工具，可以使用工具完成对 Java用的spread memory的down，还有purple能力，客户只需要在界面上进行简单的操作,就可以完成它以前可能需要几十分钟才能完成的操作，未来会继续推出更多更丰富的应用能力，包括像对Golang Rust的语言的等等一些能力。右边就是操作示意图，下面就是在整个运维操作结束以后，可以它会自动跳转到ATP平台，展示它的运维结果。

除了对运维操作进行简化，还和像OOS和TXT合作简化用户的服务发布。比如OOS可以先借助TAG应用服务器打标签，从而实现应用发布的批次。还可以借助云助手在服务器上发布和执行脚本，从而实现服务的分批启动，同时还能利用云助手实时监控应用的运行状况，实际上应用的动态的扩容，这些操作都可以使用OOS的脚本编程化实现，这样既可以简化用户的发布应用的操作，同时也可以保证最大的灵活性。即使归纳很多用户的运维操作，极大的方便客户的使用，毕竟精力有限，也不可能覆盖所有的场景。所以借助现在比较火的大圆模型更好的智能的辅助客户。

下面在这方面做两个工作，左边是直接在界面上集成现在的2020的大圆模型，用户可以直接在界面上输入一些需求。比如需要找出当前某一个文件夹下面所有的有八个信息的可执行文件，将他们的第八个信息当中的原文件的文件夹重定要到其他的目录，现在就可以很方便的在界面上直接输入需求， AI助手就会返回想要的定位脚本。首先可以不需要切换到界面的搜索引擎，同时像使用搜索引擎还要筛选答案。这样非常的慢，右边是现在阿里云的Golang的合作，这个产品可以更进一步实现对终端产品的自助诊断，比如客户在AI助手下面一句话，机器执行非常的慢，内存有问题诊断机器内存，这样就可以自动唤起Golang的终端机器发起内存诊断，并且将最终的诊断报告和诊断建议展示给客户，这样使用起来非常的方便。

上面这些工作都是在阿里云控制台上所做的工作，但是还有一些客户不能登录阿里云控制台，但是他们也有一种需求，就是他们需要登录服务器，执行它的运维操作，比如云集成的服务商的三方客户没有阿里云账号，并且阿里云机器也没有公网IP，他是否可以登录阿里云机器执行运维操作，还有像一些大型企业的应用开发人员，他们不可能给每一个应用开发人员都配置阿里云账号，帮助他们管理阿里云上的机器，于是开放Open API,在它的内部系统登录阿里云机器，左边是使用Open API实现内部系统，使用客户在内部系统登录阿里云机器的示意图。

首先客户可以登录自己的内部系统，点击相应的服务器，点击登录，内部系统就会调用Open API反馈一次性的链接，用户收到一次性链接，从立项直接将流量打到问题机上，问题再进行一个合法性的校验，校验成功以后就返回登录成功的界面，这样就实现流程，左边是Open API两个比较重要的参数，一个就是需要登录的实例的信息，像它的实例ID Vpc Host Port后台信息，另外就是它的账号信息，主要是表示它是阿里云账号，还是一次性的登录账号。除了使用阿里云控制台，还可以Open API，现在还只是一种本地化的登录方式，最近推出一个可爱的客户端，这个产品主要是服务有多账号需求的客户。

比如一些大型集团有很多的账号，管理的大量的资源，如果需要在阿里后台管理这些机器和登录机器，可能操作起来非常复杂，它需要反复的登录登出等等。但现在可以直接下载可爱的客户端，它的本地一次性配置多个账号，在有需要的时候可以简单的一键切换。目前客户端可以看到现在提供的和阿里云控制台是一样的体验，可以使用客户端工具登录服务器，上传下载文件，还有执行一些命令的脚本等等，下面是产品的介绍文档，最后分享购物案例和使用数据，比如推出的Open API,,目前已经有像阿里云的idsi HPC产品，蚂蚁集团还有外部客户，像之前山东某医疗科技公司，他们的客户主要是一些医生，这些医生有时候需要登录公司的服务器，在服务器上查看视频和图像数据，但是这些医生是没有机器的阿里云账号，并且服务器也没有供IP，于是他们就找到我们，就借助 Open API帮助客户登录服务器查看相关数据。

刚刚介绍的一键式的自助运维服务，目前这个功能还没有对外宣传，但是已经有一些客户通过一些官方文档自己使用，比如杭州的某算法科技公司，他们就使用自助运维定位线上的加盟应用的内存泄露问题。第三个是推出的AI助手，虽然推出不久，但是目前每天的量也已经有500家了，累计销量已经超过3万，最后就是一个客户端工具，客户端工具现在没有对外大规模宣传，但是每周的下载量也已经超过2000家，它的周活也在4000家。相信未来会有越来越多的客户选择本地化工具运用服务器。下面是一个视频展示最近推出的一键式加稳用的自助运维，使用这个通道在几分钟之内完成加稳用的包括所有的memory的工作，视频时间大概4分半。

这边先需要确认使用的Java命令的路径，这个地方可以填进程名字或者ID，需要填写存储的地址，是用OSS存储dump出来的文件，自动跳转到ATP平台展示分析结果。刚才是对12进行担保，现在可以对ATP进行担保，最后再展示Perf，这个就是演示的视频。最后整个演讲做总结以及展望，把它归纳成四个方面。持续的引进客户端工具，使它更加的简单和灵活。目前支持使用Open API登录用户实例，未来会继续扩大编程半径，不仅能编程登录，同时也能变成运维能力，同时开放更多的运营能力，包括持续集成 CICD等等。在此之上会持续的接入更多的应用场景，不仅是支持目前的多种协议的登录终端，甚至还会登录一些虚拟终端，比如像开发机和Client，客户就不需要购买实例就可以直接使用Cloudshell开发机运维和管理集群资源等等。在此之上会继续的归纳总结用户的常见的运维操作，将这些做成更加简单易用的开发工具，开放出去方便大家的使用。同时也会加大在智能化方面的投入，我们相信未来随着积累的客户的运维数据越来越多，AI助手会更加的智能，用户使用起来也会更加简单。