一、什么是控制台
接下来将与大家分享ECS控制台体验的演进过程，以及近期上线的一系列最新AI工具的功能。
首先，明确一下控制台体验的含义。用户体验是指用户在使用产品时，对其完整链路的整体感受，包括心理、情绪、行为以及反馈等方面。作为一个基础产品的管控运维平台，在设计控制台体验时，需要考虑的因素更为复杂。
从用户的角度来看，他们可能更关注视觉交互、功能点以及我们提供的引导和反馈。然而，对于负责设计控制台的我们来说，底层的考虑因素则更为多样。由于这是一个tob的运维平台，可靠性和安全性是核心要点。控制台的可用性SL保证应与用户的云服务器标准一致，因为核心操作如启停、防火墙设置等，一旦管控行为不可用，将对用户业务造成严重影响。此外，传统上会考虑性能、易用性等平台都会关注的因素，而效率也是作为面向企业的工具平台所必须重视的。同时，还需要确保UI的一致性，以及B端控制台在使用链路上的向上兼容和整体一致体验。
二、体验
1.体验--因人而异
ECS控制台作为阿里云最基础的产品控制台，其用户群体覆盖广泛，且用户间的资源量和角色差异较大。在此重点讨论两类资源体量以及两种角色的用户。因为我们的AI能力目前一期是着重针对这四类用户进行建设的。
从资源体量上看，个人开发者在使用控制台链路时，最核心的诉求是简单易用和快速上手。他们对我们控制台的需求和反馈往往非常直接。有时候做体验会有一些没有太强的成就感或沮丧感。因为体验做好了，用户是默不作声的，而当你收到的反馈往往都是用户对你不好的体感。在企业级用户层面，针对的是整个资源量体量比较大的这部分用户，他对控台的功能的丰富度的要求和涉及到核心的底层的一些开放的参数的要求是比较高的。由于它操作的便利性，在定制化、批量化、自动化上面的要求也会更高。还有两类的角色也是弹性计算工具链路中比较高频涉及到的。一个是资源管理员，另外一个是资源架构师。他们的核心诉求是针对于OS或ROS这两款产品的诉求。这是不同角色对控制台管控体验的不同要求。
2.体验--贯穿全链路
在做管控平台时，不仅要考虑到角色和体量的不同，还要考虑整个体验链路的覆盖度，在不同的售前、售中、售后，管控服务针对不同的用户有没有提供最佳的体验实践。在售前，可能更多是比较高频的场景，不是所有的都是。可能更多的是像选型场景，它的痛点和诉求会比较多。对于开发者或企业级用户，他的诉求也会有比较大的差异的。在售中，更着重于整个购买的链路，在售后是自动化运维的能力。
所以针对一系列的链路以及角色，围绕着这些链路和角色建设了一系列的产品AI助手能力。涵盖了云助手、workbench、ECS、ROS、OS的能力，也针对于不同的产品进行了一期的建设。
三、售卖助手--AI的能力
1. AI的能力
无论是个人用户或大型企业，在购买ECS的时候，都会在某些场景下或是需求下产生一些困惑，比如不同的规格之间的性能差异，对比当前的业务场景，应该使用哪种规格会更加合适。因为有时候有些用户对于自己的场景，可能在性能或安全性上面是有一些增强要求的。但是阿里云的规格又是丰富多样的，那么当前的场景到底是不是需要买一款网络增强型，安全增强型？因为涉及到成本的考虑问题。在这时会使用户很纠结。对此助手会从几个维度通过借助AI的能力智能的分析用户的应用场景。用户可以在他的应用场景的话术中，得到相对来说比较详细的信息。
比如你的应用的整体的计算力，对网络的并发要求，或你的一些事物、并发以及数据的上传和下载量。都可以通过话术，然后告诉我们如何分析应用场景，并给出更匹配的、性价比高的场景的规格。也可以针对特殊的要求，比如要求AMD或处理器的特殊要求。并且也会根据用户的偏好，用户可以在话术中针对性的比如希望价格优先。默认是以性价比的平衡能力给大家做推荐，包括优惠策略，而且也会实时的在AI的输出能力中去集成，尽量的给大家推荐最适合你的、性价比高的规格的能力。除此以外，如果用户给我们的是比较具象的场景。我们不仅仅给你的规格的一些推荐，还会根据你的场景，对于你在存储网络以及安全上面，甚至防火墙的配置上，给出一定的建议和意见。
2.Demo
demo的场景相对来说没有那么复杂。
比如在EC的售卖业有这样的快捷按钮，可以直接去唤起售卖的推荐小助手，在此输入你的场景。比如一个中小型企业，需要开发一款软件，它的用户量是多少，有没有一些特殊的要求，甚至可以看到有一些用户的真实的案例是希望海外访问，有这样的需要比如两分钟内有多少的连接数或数据上传数。这都可以根据具体的场景，给予相对来说性价比更高的规格推荐。这是真实的AI输出的性能速率。我们会给出规格以及对规格的解释，还有推荐的理由，并且给出一些其他的相关建议。该功能目前是灰度开放。在九月内会全线对外用户开放。希望都能够来试用，提出你的问题以及场景，便于我们能更好的优化。
四、控制台提供的AI助手能力
用户在使用控制台时，经常会对一些专用名词或约束规则感到困惑，甚至在执行操作时对报错message不理解。并不能完全的理解我们给予他的信息。这种情况的下，用户可能会去求助于文档，或社区搜索，甚至是提供单给客服要求与解答。但前两者提供的信息可能比较松散，需要用户自己去甄别哪一条信息更加的正确和官方；而客服的链路耗时则相对较长，不能高效解答问题。有了后台的AI助手，可以看到底层的知识库体系，集合了最高频或更通用的内容方案。还结合了本团队输出的定制化的解决方案。并且会在整个AI的agent prompt里设定，会有一些侧重点。或做一些准确率的校正来给用户推出更加精准和适配的解决方案。
五、ECS
1.ECS--控制台划词释义
包括唤起方式，希望给用户更加快捷的换血方式。即你觉得控台上的任何的对于文案不解的地方，只要通过滑词的方式就能够唤起AI小助手。在控制台的右侧会有一个侧边栏，上面也会有全局的唤起窗口。针对唤起，除了针对文案的检索和解析、知识库。还有一个比较大的优化点是，因为所有的控制台，它所处的页面的上下文信息，会带入到检索的AI的信息里边。并会针对性的知道你在执行操作的时候遇到的文案的困惑，或在推荐页面，甚至是售卖页的特定的页面场景下。针对于，比如你划了一个可用区比较通用的文案。它在不同的场景会知道你可能遇到的疑惑，或你希望得到的解答的维度，这其实是不一样的。所以我们会根据上下文信息做更精准的方案回复。
2.ECS--实例诊断
实例诊断是比较高频常用的功能。这个功能目前核心的底层和ES控台左侧菜单的实例异常问题的入口目前是一样的，但借助AI的能力，它能够提供更便捷的窗口和诊断。因为很多用户并不能完全的从功能入口里面进入到这里的路径。甚至之前很有用户就吐槽这个功能，即在里面进去的时候，并不能快速的帮他诊断问题，反而又要回答他一系列的“到底是性能问题、网络问题还是安全组问题”。需要用户做一系列的前置的选择才能做精准诊断。而这次的AI实例诊断集成，做了用户简化的工作。不需要精准的输入问题维度，我们就会针对用户实例的一百多项的常用检测项快速的帮你做一键诊断，定位出核心的问题。而且你还可以根据诊断的报告内容做二次发问。也就是说，如果你对这个报告报出来的异常有任何不理解，可以在这里快速的进行AI的二次发问和解答。这样能够把用户的问题诊断的链路做到更加的便捷和精准。
3.ECS--云助手命令助手
除了这两款命令助手相关的workbench。还有云助手以及所有控制台和命令相关的IDE或panel，都集成了命令AI小助手的公共组件，它不是用侧边的差的窗口的方式去和用户交互。而是直接在IDE的输入行里边，可以直接用快捷键，或to tip图标，唤起交互的入口。能够非常便捷的对文本信息获取或发问。而且也可以快速的一键命令推荐，insert到IDE里面，甚至是work book界面。即在这个界面中可以快速的划词。比如你在执行某些脚本和命令的时候，对里面的报错不是特别的理，可以让他对他进行二次的翻译和分析。甚至是用云助手的脚本从别的地方copy过来，那么他为什么是这样的一个流程，或部分的脚本命令具体在做什么事情？它也可以通过ID中划词的方式，直接对这段脚本进行翻译和解释。帮助你可以所谓的无文档化，或无门槛的使用快速的脚本化工具。
六、面向架构师和资源运维AI模板助手原理
后面的两款AI是部署在IOSOOS上的。它主要面向架构师和资源运维这两种角色人群，针对IOS和OS给他们提供的信息的工具能力。但是IOS和OS两款产品，它们都是模板化的部署和运维工具。关于模板，大家就会觉得有学习和理解的成本。所以这也是这两款工具在应用和普及过程中遇到的比较大的阻碍。所以我们想充分利用AI的能力，让大家既享有这两款自动化工具的编排能力，又无需花费过多的学习和上手成本。
七、AI模板助手原理
RIG技术能力，又叫搜索增强生成能力。他有一个generator，会根据知识库体系和AI能力生成用户的需求反馈模板。还会针对检索能力不断的做修正和增强。根据AI生成能力做一系列的校验。甚至是用dry down的方式看这个模板是不是有效的模板。然后等到最后从模板的静态校验和动态校验都已经通过的前提下，给用户关于权限属性以及价格的确认。如果用户不确认，可以再做一次反复的校验。如果用户确认了，可以针对于前面的模板创建相对的模板，甚至是资源站，帮助用户创建资源部署的task，以及去做下一步的运维工作。
八、ROS--模版助手
这是一个简单的demo，它直接在我们的ROS的创建模板的页面上面，即AI生成的快速入口。
他会根据你的需求生成资源站，一遍一遍的做一些vue data的校验来确定。因为AI的模型对于这种比较复杂的场景，有时候会有一些幻觉或错误。通过IG的方案不断的校验和修正它，来保证最后的输出结果是正确的。
九、OOS--模版助手
OOS模板其实也是一样的。会根据这个模板执行。它除了是生成模板，还可以根据执行模板错误给出错误校验的诊断和提示。因为弹性计算的控制不仅仅只有ECS控台，还有一系列的工具化的平台。这些工具化平台的设计以及研发，都是为了更好的辅助大家做自动化或精细化、高级化的部署和运维。但是往往是由于这样的学习和使用门槛，导致大家觉得跨度到这里来比自己去EC控制台手动操作更加复杂。所以我们希望能够借助AI的能力，让这些工具能越来越多的被大家使用和熟悉。能够真正的利用工具来善其事，提高大家的运维效率。
十、简洁版
我们做了一个针对于资源量较少的用户的简洁版的控制台。为什么要做这个简洁版？因为我也经常会受到大家的吐槽，说“你们控制台又改了，太讨厌了。我特别不希望你们改控制台，我刚刚熟悉了，你们又把菜单给变了，把功能给挪了。”看到这种吐槽，我们也觉得很抱歉。但是所有体验优化，也是来源于另外一部分用户的吐槽，或是更大一部分用户的吐槽，觉得在这个地方的链路和体验不够好，要我们去优化它，但确实是众口难调。然后针对于资源量小的用户，发现它的集中吐槽点在于它对整个界面的复杂度。没用的功能太多，入口太深，不好找，这些吐槽是比较集中化的。这些小用户到底在干嘛？是不是需要给他提供更多的应用能力？当我们思考了一轮下来，会发现应该先解决用户最核心的痛点。对于这部分的用户痛点，控制台并不是非常高频使用的平台。但是当他遇到问题时，需要的是真的解决问题，而且是快速解决问题的平台。他要的是简单快捷。你先把这个核心的需求满足了，再给我提其他的需要的能力。
简洁版控制台的设计。
首先不打破现有控制台的用户的使用体验。所以给他switch的入口。在左侧的菜单上我们会有一个切换。现在是灰度开放的，后面会加大灰度给到用户可以去体验。它不是强制大家去使用，你可以选择你到底是要简洁版还是继续停留在标准版。那么从简洁版控制台的界面上来说，做了一个比较大的简化工作。我们会看到左侧菜单只有核心的实例镜像、网络安全组这些核心的资源入口，而且这个操作链路是以你的实例出发的，当然这个简洁版主要面向的是资源量少的用户。有了简洁版，就不需要通过从概览或者实例列表页，然后再做实例详情页这样一步步的操作。如果你的资源量在5台以下的话，你的实例可以通过tab快速切换。然后可以快速看到所有的实例，以及最核心的信息内容。包括用户经常做的链接，或copy的IP，看一下基础监控信息这些能力信息都可以在这里去快速的看到，不需要做更下一步的重量工作。
还有一个比较大的优化是安全组。很多用户吐槽安全组，操作起来很不便利，需要一步步的周到才能去编辑规则。对于安全组防火墙的编辑做了一个比较大的简化。是不管你实例上是有一个安全组还是多个安全组，一切都是以规则来做的信息展示。因为对你来说，这个实例上的规则才是真正影响到实例可访问性的关键因素。你可以一目了然的看到所有的规则列表，并且快速的添加相应的规则，不需要care到底是交到哪个安全组里面。这是一个比较大的链路。还有一个是实例的一键诊断，AI能力也做到这一点。不需要你做任何的前置选择，只需要通过快速的一键诊断，就能帮你的实例做全面的基础体检，排查更多的问题。包括菜单和信息也是可以定制化的。我们给予了你最精简的默认视图，这是为了满足用户又想简便。但是还会有我所需要的信息可能不在你的默认视图里。为此我们给到了用户一些充分的定制化能力，让其可以开启这些你所需要的高频信息的展示能力。
十一、控制台体验发展
对于后台的体验发展，主要有三个维度。它不是一个排他的眼镜，会发现他可能也是一个叠加的过程。比如从最早的devo ops，进行的是工具化、流程化，还有交付集成的建设。在最近两年，经常提到的clubs。Clubs更多是强调推荐用户如何的更好的使用自动化、弹性以及安全可恢复性的一些能力。包括在E测控台的使用成熟度页面，。怎么样才能更好的维护和管理你的云资源？我们现在朝着的一个新方向叫chat ops。chat tops的核心是希望给用户极简的体验、个性化的服务和智能方面叠加的推荐能力。其实可能大家会担心将来chat会不会替代前端的开发工作。chat会替代前端的工作，但它替代的不是你前端的开发工作，它替代的是UI这部分的工作。它不是降低你的开发成本，而是让你没有开发成本。因为用户已经不需要复杂的GOI模式进行管控和操作了。
最后我希望大家能够积极的适应控制台的AI能力。从而可以及时的收到大家的信息反馈。
