【弹性计算技术公开课】-CloudOps云上运维季系列课程，首节课程由阿里云弹性计算高级产品专家马小婷主讲，课程主题为《CloudOps云上自动化运维，助力云上业务高效、稳定运行》，课程涵盖：云上业务持续运行面临的挑战、ECS自动化运维（CloudOps）的产品大图解析、ECS使用成熟度评估与洞察（ECS insight）等相关内容。
1. 云上业务持续运行面临的挑战
大多数企业上云第一步就是购买算力，即云服务器。不同行业和规模的客户，由于他们的能力和行业属性有所区别，故对云服务器的诉求也不一样。根据阿里云ECS客户的调研和反馈，我们发现ECS客户在使用ECS的过程中，面临的主要问题大致可以分为以下五个方面：
∙ 成本问题：当前大环境下，不少企业对成本优化的诉求非常强烈。由于云上是按需付费的服务模式，即我们使用了多少资源，就要为所买的资源付费，这与传统的提前一次性采购所有服务器的模式不一样，不受约束的按需购买就非常容易出现资源浪费的问题。如果我们不能对云上的资源进行很好的成本管理，很容易出现云上的资源成本超出线下支出的情况。所以，如何在不影响业务持续正常发展的基础上进行成本管理和优化是不少企业面临的首要挑战。
∙ 效率问题：提效降本总是相伴相随的，资源的成本是显而易见的，但人效的问题很多时候却无法直接衡量或看得见。众所周知，自动化是提升运维效率的最佳方式，但自动化工具的建设和维护成本也是隐含成本。与线下IDC相比，云服务提供商也提供了丰富的工具和能力来帮助企业提升云服务器的运维效率，而如何利用工具或者服务能力降低云上资源的维护和管理成本，是不少企业面临的痛点。
∙ 稳定性问题：虽然云上客户无需管理和维护底层物理基础设施，但并不意味底层基础设施是100%可靠的。虽然目前阿里云提供了业界领先的单实例SLA，即99.975%，但也不意味着底层基础设施100%不会出问题。站在业务应用的视角上来看，我们要做的是构建并提升整个应用的稳定性和可靠性，而不是单纯的依赖单个ECS实例的稳定性来保障整个系统的稳定性诉求。同时，当底层服务的稳定性出现任何问题时，我们业务侧如何快速恢复，缩短业务受损的时间，这也是ECS客户在云上面临的重要挑战。
∙ 可用性问题：对于类似电商、社交平台等行业的客户而言，上云带来的最大便利性是资源便捷的可获取性以及云上的深度弹性。在线业务一般都会面临明显的峰谷波动，而服务的可用性是业务的重中之重，尤其是在业务高峰期的时候，我们需要快速的创建大量资源来满足临突发的流量需求，确保服务的可用性。但如何更好的利用云上弹性来实现业务的高可用，是不少客户在真正落地过程中面临的问题。
∙ 安全合规问题：安全问题是不少企业在上云时最为关心和担心的问题，这也是很多人对云直接的条件反射，即很多人认为上云意味着所有数据都托管在公有云服务提供商上，那是不是所有人都可以访问我的资源？是不是业务很容易被攻击？那我的数据安全是否有保障？尤其是银行类或证券类类的客户，他们对数据的安全和合规尤为关注。其实云上也提供了非常丰富的安全能力，包括数据安全、计算安全、应用安全、操作系统安全，来保障业务在云上运行的安全可靠，但如何利用这些安全能力设计一个符合安全规范和合规的应用体系，是不少企业面临的痛点。
以上五个问题是目前ECS客户面临的主要问题，接下来我们一起看一下它和行业内客户面的问题是否具有一定的相似性。
前面我们介绍了ECS客户所面临的云上运维的五大挑战，回归到整个行业维度，根据上图展示的Flexera 2023年State of the cloud report分析报告可以看到，对于大型企业，面临的Top 3的挑战是：管理云上成本、资源/技能不足 、 多云管理和安全问题。对于中小企业，面临的top 3的挑战是：管理云上成本、安全问题和合规问题。但对于所有企业而言，大家面临的最主要的问题还是：管理云上成本、安全问题和资源/技能不足等问题。
对于管理云上成本和安全这两个痛点，相信很多人都是有目共睹的。关于资源/技能不足的问题，我想详细展开介绍一下。与线下IDC相比，云上除了提供标准的各种算力外，它还提供非常多的标准化的自助服务能力，用户可以通过控制台或者OpenAPI自助使用。这意味着云上的运维方式和传统的运维方式是不一样的。我们不再需要像过去一样，从零开始什么都自己来构建，而是需要基于云厂商已经提供的能力，提升运维效率和体验。所以，在技能和资源方面，我今天的分享就是要告诉大家，我们有什么样的能力能够帮助大家解决什么样的问题，提升大家对云厂商能力的认知，让大家站在云厂商的肩膀上专注于业务本身价值的高效交付。
综合Flexera的行业分析报告与ECS客户面临的主要问题，我们可以看到，所有企业在云上进行业务运营时面临的挑战无非是以下五个：
成本管理：这里我用的是成本管理，而不是降成本，因为抛开管理讲优化和降本是非常简单粗暴的。成本管理的终极目标是以合理的成本来保障业务的正常运行，做到既不浪费也不短缺。
自动化提效：自动化是运维从诞生之初就一直追求的目标，所有运维人员都知道自动化可以提效，但是正如flexera分析，由于资源或能力的缺失，不少企业的自动化的能力和水平并不是很高，所以借助云上原生能力快速提升自动化能力和水平，也可以缓解业务所面临的挑战。
弹性高可用：对于电商、社交媒体等在线服务而言，会存在业务的明显峰谷波动，业务的高可用离不开资源的弹性。在业务高峰期，我们需要根据实际的业务需求快速扩容资源，满足突发流量需求，这在互联网行业是非常明显的痛点。在传统模式下，所有资源的准备和购买都需要提前规划和采购，如果是超出规划以外的计算资源，就很难满足了。而云上最大的特征之一就是提供了非常快的弹性速度，以及“深不可见”的弹性容量。但如何充分利用云上弹性能力来提升业务的高可用是很多线上业务面临的挑战。
稳定可靠：对于游戏类客户而言，业务的稳定性是重中之重，尤其是在游戏开服的前期，如果出现机器宕机，导致部分玩家突然被强制下线影响了游戏体验，会直接影响游戏的体验和口碑，严重情况下还可能会导致几千万上亿的宣发投资“打水漂”。所以如何利用云上的可观测能力、监控报警的能力以及故障演练的能力来提升整个业务的稳定性以及整个应用的可靠性，也是现在很多线上客户所面临的挑战。
安全合规：安全性和合规其实是两个方向。正如前面所说的，安全问题是很多客户在上云初期就持有的顾虑，前面的Flexera分析报告也印证了这一点，说明云上安全的重要性始终处于C位。但如何体系化地提升安全能力，尤其是基于云上默认已经提供的安全能力来构建安全体系是很多客户所关注的。至于合规，主要以银行、证券等金融行业为主，包括物理隔离、数据安全等，它需要端到端体系化的合规解决方案。
以上就是我们发现的云上业务持续运营面临的五大挑战。
2. ECS自动化运维（CloudOps）的产品大图
首先，看一下CloudOps的基础概念。很多人在听到CloudOps的时候可能会好奇它究竟是什么，我们听说过DevOps、FinOps、AIOps，那CloudOps是什么呢？
顾名思义，CloudOps其实就是云上自动化运维，和FinOps一样是一种运维理念。CloudOps = Cloud x DevOps, 强调的是充分利用云本身的特性更好地实践DevOps，加速业务价值的快速稳定交付，它的核心点是强调了云本身的特性，而不需要我们重复性的开发。云本身的特性包括云的高弹性、高度标准化、高自动化和自助服务模式等，这就意味着用户能够根据自己的需要按需取用，不需要依赖任何其他能力的支持。
CloudOps定义了企业在上云、用云以及管云过程中重点关注的五个维度，它和我们前面说到的云上客户常见的五个痛点是相呼应的，分别是成本Cost、自动化Automation、 可靠性Reliability、弹性Elasticity、安全性 Security，缩写为CARES。
另外，CloudOps是阿里云提供的一套自动化运维套件的总称。为了持续提升客户业务在云上的可靠性和稳定性，阿里云提供了非常丰富的自动化工具，帮助客户实现云上DevOps全流程的可感知、可控制以及可衡量的能力，持续帮助客户解决成本、效率、稳定性、可用性、安全性的问题。比如，成本优化工具解决的就是成本的问题，自动化能力解决了自动化运维提效的问题，可靠性能力可以用于提升业务的稳定性、缩短业务受损时长，弹性能力解决了应用的可用性问题，安全合规能力提升了业务的安全性。
所以，CloudOps既是一种运维理念，也代表了阿里云在围绕运维体验为大家提供了一套标准化的工具的总称。
上图右侧是去年发布的CloudOps云上运维白皮书2.0的内容，欢迎大家扫描文末二维码进行下载和阅读。
接下来我将介绍一下ECS CloudOps套件。CloudOps这个名字听上去非常抽象，它究竟代表了什么样的工具，能够解决什么样的问题，以及它过去十年是怎样发展的呢？上面这张图可以给大家一个详细的说明。
2010年，阿里云发布了第一款云服务器，这也是阿里云提供的第一款云产品。2014年阿里云推出了第一款CloudOps产品，弹性伸缩服务，它能够根据业务的峰谷波动自动进行ECS资源的水平扩缩容，在需要时扩容，在不需要时缩容，既解决了应用可用性的问题，也解决了使用成本的问题。
2015年，阿里云推出了资源编排ROS，它是第一款IaC（Infrastructure as Code，简称IaC）的产品，它提升了整个IasS层资源的部署效率。比如，一个正常的业务架构，它可能包含多种云产品，包括LB、VPC、ECS、RDS等等。在传统购买模式下，我们需要单独购买每个产品，再去做一些配置。通过ROS我们可以一次性交付这些资源，如果这些资源需要跨地域部署，我们也可以把这个应用架构在另外一个地域快速拉起来。
2016年，阿里云推出了标签Tag，它的功能是对所有的云资源打标签分组，只有打完多维度的标签之后，我们才能根据多维度对资源进行更精细化的管理。标签Tag解决了管理的效率问题，也解决了安全的问题，还可以帮我们做多维度的成本分析来优化成本。
2017年，阿里云推出了弹性供应APG，它能够大规模交付ECS的算力，尤其是spot的算力，它解决了交付效率和交付成本的问题。
2018年，阿里云推出了云助手，它是ECS自动化运维的通道。云助手是ECS内部安装的一个插件，通过这个插件用户可以在不需要登录ECS的情况下，就能执行远程命令完成对资源的配置。它对标开源的ansible工具，是做大规模批量运维的基础，解决了效率和安全的问题。
2019年6月，阿里云推出了服务器迁移中心SMC，它能够帮助用户在不停机的情况下，一键把应用和数据迁移上云，同时也能实现业务跨可用区迁移。
2019年7月，阿里云推出了运维编排OOS，它是云上统一的自动化运维平台，能够提供定时任务、批量任务以及工作流等编排工作，解决了效率和安全性的问题。
2020年，阿里云推出了镜像构建服务，它能够帮我们做镜像的定制和自动化的构建，能够实现镜像的持续集成，还解决了DevOps里的持续集成的问题，提升了持续集成的效率。
在提供了这么多自动化能力的基础上，2021年阿里云推出了自动化运维套件CloudOps的概念，它是一站式DevOps的实践工具集，包含了我们前面提到的所有的自动化工具。
2022年阿里云发布了一个新的产品叫应用管理，以应用的维度打通DevOps的全流程。
以上就是阿里云CloudOps套件过去十年的发展历程。
前面主要介绍了CloudOps套件的核心产品，但它包含的产品远不止这些，还包含很多小的工具。上图展示了目前阿里云ECS CloudOps全部的产品。
最底层是服务于IaaS层的所有资源，可以分成两大块：平台侧基础能力包括计算形态、基础镜像、基础安全防护，客户侧的原子能力包括Guest OS管理、资源分组管理等等。
对于IaaS层基础资源的管理，我们提供的所有CloudOps能力可以分成五个维度。
成本优化方面，CloudOps提供了支持多种付费方式，也提供了一些成本优化的基础能力。
自动化服务方面，CloudOps提供了运维托管、批量自动化、运维通道的能力，包括刚刚提到的云助手。除此之外，我们还提供类似于VNC workbench的访问通道。
可靠性服务方面，CloudOps提供的能力也分成四个维度：最底层是资源的可观测能力，包括实例的健康状态、云监控，它能够对资源最底层的Metrics进行持续的观测。在此基础上，CloudOps还提供了事件服务，当底层出现问题的时候，我们可以通过事件的方式来通知到用户。此外，CloudOps还提供了自助问题排查的能力，能够从实例内外部的所有配置上给用户做问题的定位和排查，快速缩短业务受影响的时长。最后，CloudOps还提供了应用的管理来提升整个应用的可靠性。
CloudOps在弹性服务方面的能力也可以分成两个维度。最底层是根据业务需求进行弹性的扩缩容，包括弹性伸缩，能去做水平的扩缩容，此外还支持垂直的升降配，能够做预测性的扩缩容。同时，CloudOps还提供了弹性保障的能力，当业务有计划性的大规模的资源诉求的时候。比如双十一这种情况下，很多电商或者平台都会去做活动，所有服务都会有额外的算力需求。为了保证当时的业务需求能够得到资源的保障，用户可以借助CloudOps的资源预留或者购买一些预留实例进行资源锁定的，来保证业务在最高峰期，它的资源能够得到响应和保证。
安全合规服务方面主要围绕实例安全和操作安全。实例安全包括基础设施安全、数据安全、网络安全、GuestOs安全；操作安全包括访问控制、操作审计。在这两方面，CloudOps都提供了对应的产品能力。
以上五大维度最终服务于整个ECS的全生命周期运维。在此基础上，阿里云推出了一个新产品，ECS使用成熟度评估与洞察（ECS Insight）。它在这五大维度的基础上，识别客户在使用ECS的过程中面临的风险，提供优化推荐的建议，帮助业务持续提升在这五个维度上的能力。
下面我将围绕CARES这五个维度，分别举一个例子，让大家对每个工具的使用方式和适用场景有更直观的体感。
第一个是成本管理。线下我们在做资源的分权和分账的时候，更多的是依赖于个人所属的组织关系。在云上，我们可以通过标签服务，对云资源的使用方和所属的部门进行详细的标识，帮助用户对具有相同特征的云资源进行分类、搜索和聚合，提升资源的管理效率。
那么标签是什么呢？
标签本质上就是一个键值（Key：Value），我们的云资源最多可以绑定20个标签。举个例子，我们可以根据资源所属的地域、部门以及使用环境进行多维度的区分。因此，我们可以创建三个标签，对于每个资源，我们根据这三个维度对资源进行打标。一旦完成了打标，我们就可以从标签的视角来看详细的分类了。比如打完标之后，我们就能快速的查看北京地域所包含的资源有哪些，信息科技部这个部门包含的资源有哪些，生产环境的资源是哪些。我们也可以组合来看，北京地域下信息部的生产环境包含的资源是哪些。
除了查看资源外，我们还可以对这些打完标的资源进行多维度分析。比如，我们能通过阿里云的费用中心，查看打了特定标签资源的账单和费用支出是怎样的，这是我们进行成本优化的前提。
此外，一旦我们给每个资源打了标签，我们就可以通过身份认证管理RAM功能，来指定基于标签的策略。通过这种方式我们可以制定一些标签策略，对资源的创建和管理等等合规行为进行限制。比如，我们希望限制环境=生产部门的标签资源，它只能通过什么样的方式购买，或者什么样的人才能购买环境=生产环境的资源。这样既能使整个账号下的所有资源管理是符合规定的，也能限制未来新创建的资源也符合我们所制定的合规和成本的限制。
通过标签我们就能实现资源的分账和分权，提升整个资源在成本和安全维度上的管理的效率。
第二个是自动化。这里主要介绍一下使用运维编排OOS+云助手，实现大规模资源的管理。运维编排本质上是一个云上自动化任务编排的平台，它能够提供自动化任务的管理和执行。所谓的自动化任务包含批量操作、定时运维任务、事件驱动的自动化操作、跨地域操作等。最终，运维编排提供的是一个类似于自动化任务的管理平台，它能够实现基础设施运维即代码的能力。
而云助手是一款针对ECS的原生自动化运维通道，它是安装在ECS里面的一个插件。通过云助手，我们可以在不需要密码也不需要登录实例的情况下，在实例内部做一些命令的执行、文件的上传下载、批量任务执行等等。同时，云助手还能将非阿里云的服务器注册为阿里云的托管实例。在完成托管以后，我们就可以通过运维编排的工具，对阿里云的机器和非阿里云的机器进行统一的编排，实现混合云统一管理的场景。
上图下侧是通过运维编排实现蓝绿发布例子。在DevOps的过程中，当应用出现了新版本的时候，我们需要把业务的新版本逐步更新上线，这也就意味着我们需要对老版本的ECS进行逐步的升级，确保在业务在不中断的情况下完成新版本的升级。在传统模式下，我们只能自己写脚本或者手动实现，不仅效率低，而且容易出错。
通过运维编排，我们可以把一组老版本的ECS打上同一个标签，运维编排可以分批次的把这些ECS实例从负载均衡上卸载，并通过镜像更新的方式或者执行脚本的方式，分批次把目标ECS进行升级。在升级的过程中，可能需要先把ECS从负载均衡上解绑，更新版本，更新完之后再把ECS挂载回原来的负载均衡上对外提供服务。如果这个过程失败了，我们可以进行回滚。当第一批ECS执行完毕后，我们可以观察一段时间，确保没有问题后再进行第二批ECS进行重复的操作进行升级，直到最后一批资源被替换成新版本，这个滚动升级才结束。
与之前手动或脚本方式相比，通过运维编排我们只需要指定好需要分几个批次对这些资源进行升级、升级的方式以及在这个过程中我们要执行哪些额外的操作。运维编排会自动的把这个版本进行升级，提升整个应用的发布效率。
第三个是可靠性。阿里云提供了非常多精细化的运维能力来提升整个应用的可观测性和可靠性。可观测性解决了异常提前识别的能力，而可靠性是提升了整个应用的可靠性。虽然阿里云提供了业界领先的SLA，即单个实例的SLA在99.975%，而跨AZ多实例的可靠性的SLA是99.995%，但我们也无法说ECS是100%可靠的。如何进一步提升应用的可靠性呢？这里我们主要提供了三个能力。
第一，系统事件。阿里云在过去十几年服务上万家企业客户的经验中，沉淀了非常完善的故障预测机制和热迁移能力，当发现底层宿主机存在软硬件异常时，通过热迁移将其上的ECS无感地迁移到健康的宿主机上去，避免单个ECS实例不可用，最终实现了阿里云单个实例SLA为99.975%，业界领先。虽然单个实例的SLA非常高，但并不意味着ECS是100%可靠的。当ECS因为底层基础设施出现异常的时候，比如ECS底层的宿主机出现宕机，影响了上面的ECS，阿里云会及时的给用户推送运维事件，告诉用户，方便用户快速的感知基础设施的问题。同时，阿里云的故障预测能力识别到ECS底层宿主机的潜在宕机风险，如果ECS无法通过热迁移进行规避，阿里云也会通过主动运维事件（也叫计划内运维事件）提前通知用户，让用户选择业务低谷期进行响应。所以系统事件反映的是对底层基础设施可靠性的可观测能力。
第二，部属集。如果应用对底层基础设施的可靠性非常敏感，我们可以通过部署集来指定集群里的ECS在不同宿主机上的分布策略。比如我们可以指定ECS尽量打散在不同的宿主机上，这样能降低单台宿主机出现的问题，给整个业务集群带来的风险的影响面。
第三，ECS诊断工具。诊断工具可以一键扫描并识别ECS Guest OS的内部异常和外部风险。ECS外部问题主要包括ECS的售卖状态、安全组的配置策略、管控的状态是否正常；内部异常包括Guest OS系统配置、重要文件配置、常见服务状态等。通过ECS的诊断工具，我们能够快速的定位并解决ECS无法远程连接、无法启动、性能受损、重复宕机的问题等。
借助这三个能力，我们就能快速地提升应用的可观测性和可靠性，够缩短业务的受损时长。
第四个是弹性。这里主要介绍一下通过弹性伸缩提升应用高可用的能力。弹性能力其实是云最基本的能力，也是最能体现云厂商实力的能力。弹性伸缩是根据业务负载的波动自动调整算力的管理服务，所以它所支持的扩缩容的模式越多，能够适配的场景也越多。目前，阿里云的弹性伸缩支持定时的模式、动态的模式、手动的模式、智能模式等组合使用，来更好地匹配业务的变化方式。弹性伸缩支持配置多个可用区和多种实例规格，这样能够避免应用经受单个可用区出现问题时候的高可用能力。
给大家看一个简单的例子，对于线上服务而言，在传统的方式下，如果是人工的方式去响应，它会存在一些问题。如果我们前期按照峰谷的方式配备资源，我们就会发现在业务低谷期时，就会产生严重的资源浪费。反之如果出现了超出业务需求的场景下，我们也会出现资源不足的情况。同时当业务的变化比较频繁的时候，如果我们需要人工去介入，那么整个人工介入的时效性以及数量规划的要求是很高的。人工响应也会比较慢，一旦人工没有及时响应或者判断失误，就会导致业务受损。所以，在这种情况下，弹性伸缩可以很好地解决这个问题。
此外，我们在弹性伸缩过程中组合使用按量和spot实例能够进一步的降低成本，但它的确也是有门槛的。因为spot实例的成本非常低，但它只有一个小时的保护期。如果超过了一个小时，就需要根据市场的价格波动来决定用户是否能继续使用该实例了，如果出价低于它的市场价，这个spot实例可能会被回收。
目前，弹性伸缩组可以和负载均衡包括SLB、ALB、NLB进行自动的联动，也可以和RDS、PolarDB、ADB等数据库进行自动关联。我们只需要通过伸缩配置和启动模板来指定伸缩组每次扩容出来的实例长什么样，以及通过伸缩规则指定扩缩容的时间。在这个过程中，弹性伸缩就会根据业务的波动自动的进行扩缩容，最终让资源的量和业务的负载波动进行完美的匹配，实现业务的高可用，同时也能够降低使用成本。
第五个是安全。ECS的安全能力是需要云厂商和客户共同构建的，所以云上的安全能力遵循责任共担的模型。云厂商负责云本身的安全性，即云厂商需要对底层的基础设施和操作系统之上的虚拟化和云产品负责，它是ECS所依赖的底层基础设施。而客户负责云上的安全，即客户则需要负责和配置使用ECS所有相关的配置来提升ECS本身的安全性。
要体系化建设ECS的安全能力，首先需要了解ECS的系统架构。上面这张图其实展示了ECS的完整架构，分成上下两大部分，与前面提到的云厂商和客户各自负责的范围是对应的。
底层是基础设施，比如地域、可用区、硬件设备，它包括计算资源、服务器、存储、网络设备等硬件设备，还有底层虚拟化的软件服务，这是ECS依赖的基础设施。这部分的安全性是由云厂商来保障。
上层就是ECS实例本身，也是客户直接能看到并能管理操作的部分。实例操作系统内属于客户的范畴，云厂商无权查看或访问实例内的数据，所以，ECS实例本身的安全需要客户自己来把控。从业务角度来说，ECS实例也会分成几层，包括最底层的Guest OS，即镜像和操作系统，应用程序，然后是客户数据等。
因此，要提升ECS本身的安全性，我们可以把它分成几个方面。
∙ Guest OS安全，主要指的是操作系统的安全。比如我们使用的镜像有没有进行安全加固，我们是否需要使用等保合规的镜像，这是操作系统安全的基础。
∙ 访问安全，主要指的是哪些用户能够访问ECS，哪些用户不允许访问，访问的时候是否要使用非root的账号等。访问安全决定了实例是否会被非授权访问。
∙ 网络安全，更多指的是做网络的隔离和网络的访问控制。比如VPC的网络隔离，ACL的访问控制，以及安全组的安全规则的限制，来提升整个网络的安全。
以上几个安全性更多是单个垂直维度，如果我们想提升ECS的数据安全，它就涉及到端到端的安全体系建设，包括对计算中的数据进行加密，对数据的落盘、存储进行加密，以及当灾难出现的时候，能够做到快速恢复数据等。由于这部分属于客户的数据范围，需要客户自己进行配置，但阿里云在这个维度上也为用户提供了非常多自动化的能力，来帮助用户提升ECS在云上的安全性。
通过前面五个维度的介绍，我相信大家对CloudOps在成本、自动化、可靠性、弹性、安全合规，这五个维度能够帮大家解决的问题有了一个初步的了解。但还有一个产品我没有介绍，就是ECS使用成熟度评估与洞察，下面我们来看一下这个产品能够帮大家解决什么问题。
3. ECS使用成熟度评估与洞察（ECS Insight）介绍
ECS Insight是一站式的业务风险识别与修复中心，它是CloudOps一脉相承过来的产品。ECS Insight从CloudOps定义的CARES五大维度出发，基于客户在云上沉淀的最佳实践和当前客户在ECS的使用情况，最终分析当前客户在ECS上存在的业务风险，并提供优化推荐。只不过ECS Insight在CloudOps的五大维度上，增加了基础能力，作为阿里云的额外补充。
所以，它的工作原理是对整个账号下以ECS为核心的相关资源的使用情况进行分析，包括对资源的分布、权益类的服务、工具的使用情况等。为了提升风险识别的完整性，我们需要覆盖更多的资源类型，并对这些资源的使用情况进行全方位和长周期的数据采集和分析，之后我们结合云上企业在行业的最佳实践，给用户提供指南。
最后ECS Insight的产出包含两个部分：
第一部分是刚刚提到的CARES五大维度再加一个ECS的基础能力，从六大维度上给用户提供对应分值的评估。第二部分是在这些分值评估中，我们会识别这些问题的严重程度，并针对每个程度给用户推荐优化建议。对于一些高危项和警告项，我们希望用户尽快修复。而对于一些提示项和不适用项，我们会建议用户忽略。这就是ECS Insight的大概工作原理。
接下来我将给大家看一下ECS Insight的一个简单的Demo。
ECS Insight这个产品在2023年3月份做了第一次的版本发布。上面的截图是一个老版本的视图，它可以分成三个大模块。第一个是对整个账号下的ECS的使用成熟度进行全面的评估，能够看到当前的账号，在各个维度上的分数以及分布情况；第二个是对于失分项的概况；第三个是快速了解失分项，以及对应的最佳实践，及时进行风险修复。
在此基础上，我们计划在今年的10月份对ECS Insight进行第二次的版本迭代。上面的截图是新版本的UI视觉，这个新的视觉和旧版的一样也分成了三个大模块。首先，还是对整个成熟度进行全面的评估，之后我们会在失分项这里，根据问题的严重程度进行分别的展示；对于高危项我们会呼吁用户尽快修复，否则真的会对业务造成一个比较严重的影响；对于警告项，我们需要及时的采取行动；对于不适用项用户是可以忽略的。
对于这些高危项，我们在新的版本里面增加了一些内容。第一个是告诉用户受影响的资源是哪些，第二个是它带来的风险是什么，第三个是我们把修复建议写的更明确。
在这个基础上，用户可以对于失分项展开看它的详情。比如这个评分项的评分规则是怎样的、当前的问题是什么以及修复受影响的资源有哪些。在这里，对于受影响的资源我们也提供了快捷的操作入口，方便用户快速的采取修复行动，降低整个业务受影响的时长。
下面我将对ECS Insight各个维度的能力进行一个简单的介绍，方便大家快速地了解ECS Insight在每个维度上能够识别什么样的风险，以及能够帮我们解决什么样的问题。
首先看一下ECS的基础能力。这一部分主要在计算、存储、网络、账号与资源管理这四个维度，来看一下当前的ECS和关联资源的分布是否合理，在性能和高可用维度是否存在风险，并且提供优化建议。这个能力评估来源于以下三大客户痛点：
第一，ECS实例规格繁多且不断演进。目前为止阿里云提供了超过1000种实例规格，而且每年还会推出新的实例规格。同时对于一些老的规格，比如经典网络的实例，这些实例不仅性价比低，而且对于一些实例的新特性它们无法使用。那么在这种情况下，如果我们持续的保有老规格，不仅性价比比较低，而且限制也会比较多。
第二，云盘类型和性能无法满足要求。阿里云早年推出的高效云盘或者老的本地盘，它们已经非常久远了，且已经无法满足当前业务读写的性能要求了。如果我们没能对这些老旧磁盘或者性能偏低的磁盘进行及时的升级，也会导致业务受到一定的影响。
第三，大规模资源管理复杂。如果我们的资源只有一两台倒还好，当我们的资源规模达到一定程度之后，我们想要对资源进行快速地查找，以及对于资源的管理也会面临挑战。所以在这种情况下，我们如何进行一些比较精细化的管理，避免一些误操作，也是我们面临的风险。
基础能力就是基于以上三个维度识别ECS当前面临的风险，并且提供优化建议。
第二个是成本洞察的能力。正如前面所说的，大家对云上成本的管理和优化都有非常强的诉求。但如何进行成本管理和优化，其实是很多客户的痛点。云上客户在成本管理面临的痛点包括：
第一，ECS付费方式和实例规格繁多。阿里云提供了包年包月、按量、抢占式、预留实例券RI、节省计划SP等多种付费方式和权益，方便用户灵活选择。但如何选择和业务形态最匹配的实例规格，并且能够根据业务的波动判断当前的实例规格和业务的形态是否最匹配，来实现业务的高可用，同时降低成本。
第二，无法快速根据不同维度核算成本支出。因为在云上是很多用户共同使用这个账号，不同的团队/人员，在创建资源的时候可能没有按照标准进行打标和分类，就会导致我们无法根据不同的维度快速的核算成本。所以如何快速的识别这一部分风险，并对它进行区分是目前客户面临的第二大痛点。
第三，实践FinOps持续优化成本面临数据不足。成本的持续优化离不开资源历史使用率的数据支撑，存储和分析大量历史数据面临门槛高、数据不足等多个问题。
在这个基础上，ECS Insight成本洞察的能力，它也分成了三个层级来给用户做风险的识别和推荐。
∙ 初级是识别闲置或低使用率资源，推荐用户通过降配、停机不计费等方式进行优化，避免资源浪费。
∙ 进一步是借助权益类产品，比如通过预留实例RI、节省计划SP等权益产品，进一步降低按量资源的使用成本。
∙ 更进一步就是借助标签、财务单元、预算管理等多种工具，进行成本精细化分析与优化，端到端持续管理并优化成本。
以上就是ECS Insight在成本管理方面的产品能力。
第三个是自动化的能力。它主要解决的用户痛点包括以下三个：
第一，自动化能力不足，从前面Flexera的分析报告也可以看到，很多客户就是因为能力或资源不足，导致很多的日常运维都需要人工操作，或者需要自己写脚本来做，那么就会导致整个操作周期长，很多脚本无法正常维护的问题，还容易出现误操作，导致运维风险非常高。
第二，脚本难统一维护或形成规范，如果运维团队的管理不规范，每个运维脚本都会由每个工程师独立去维护，整个操作是不透明的，很容易出现和预期不符的误操作，最终导致运维风险。
第三，自服务能力缺失，在传统的模式下，基本上所有的日常运维都需要运维团队的人工响应，这样研发团队就很难自助地完成一些简单的运维。比如，我想要做一个发布，我想要申请一个资源，就都需要去和运维团队打交道。这就会使协同的成本非常高，效率非常低。
面临以上问题，ECS CloudOps提供了非常多的工具，但我们如何选择并使用这些工具来解决问题呢？这就是ECS Insight在自动化维度给大家提供的产品能力。它分为以下三个层级：
∙ 初级就是通过控制台或OpenAPI完成资源的基础管控操作，包括资源创建、释放、排障等。
∙ 中级就是借助云上自服务工具，比如云助手、资源编排等，实现自动化管理。
∙ 进入高级阶段后，用户可以组合多种自服务工具，实现统一的标准化运维。
在自动化能力这一部分，ECS Insight的推荐能力属于nice to have的能力，但并不意味着没有用自动化的能力就不好，而是说如果我们有一些高频的场景，我们推荐用户使用对应的工具实现提效降本。
第四个是可靠性的能力。前面提到了，很多时候在云上运维团队不再需要负责底层服务器的购买、管理、监控，但并不意味着我们底层的基础设施是100%可靠的。那么在这个基础上，我们如何提升整个应用的可靠性，常见的痛点包括以下三个：
第一，应用的高可用能力不足。比如我们本身是一个在线的业务，我们本身不具备高可用的架构。这就会导致整个应用的可靠性是依赖于单个资源的可靠性的，这种行为就是不可取的。
第二，无法满足差异化的稳定性诉求。对于不同的运维团队，它对于层基础设施的诉求是不一样的。尤其对于一些核心业务，它对于底层基础设施的变更、维护、特定的窗口是会比较高的。那么我们和各个团队的协同成本也会比较高，而且还会存在无法支持和响应的情况。
第三，问题定位周期长。当底层/业务出现问题的时候，我们整个问题的定位周期是比较长的，我们也缺少一些自动化的工具进行常规的问题排查，或者提前进行故障的演练。
在这个基础上，ECS Insight提供的可靠性的评估能力也分成了以下三个维度：
∙ 初级的稳定性是需要将基础设施资源部署在多个可用区，避免大规模故障。
∙ 中级的稳定性要求客户对关键数据周期性进行备份，提升数据的高可用水平，同时对核心业务在多地域进行部署，提升应用的高可用架构。
∙ 高级的稳定性要求对应用进行多维度的监控，结合可观测工具、故障演练、故障注入等方案对应用可靠性进行验收。
在这三个维度上，我们也提供了对应的风险识别。比如识别当前实例维度的稳定性面临哪些风险，数据维度的可靠性面临哪些风险，性能维度的可靠性面临哪些风险。通过这些实例、数据、性能维度的风险，我们就能够从最底层消灭稳定性的风险，提升整个应用的可靠性。
第五个是弹性能力。弹性能力更多的是解决了资源交付的效率问题，同时还解决了成本的问题。正如前面介绍的，我们对于传统模式下临时弹性的需求，它的交付周期是比较长的。如果我们做好管理，就会存在很大的资源浪费，导致整个成本偏高。而且扩容的时机和业务如果匹配的不好，不仅会导致业务受损，还可能存在资源浪费。
所以在这个维度上，我们也会对用户在弹性维度上的使用情况进行分析。包括以下三个维度：
∙ 初级的弹性手动或半自动满足临时弹性需求：包括通过控制台或OpenAPI批量交付或释放按量的ECS实例，满足临时突发的弹性需求。
∙ 中级的弹性能自动根据业务波动进行资源管理，包括根据业务关键指标的波动，自动创建或释放认为指定数量的资源，但是无法满足超出预期的资源需求。
∙ 高级的弹性要求全自动化地弹性资源管理，即根据业务负载与当前资源的偏差，自动计算资源缺口，并动态调整资源进行自动化响应，实现业务高可用和低成本的双重价值。
弹性能力对于大多数用户/在线业务来说它有强诉求，对于部分用户来说，他可能并不没有那么强的诉求。所以这里的评估需要用户根据自己的业务特征来做，再去做进一步的判断。
第六个是安全性的能力。用户的痛点包括以下三点：
第一，安全意识不足。云上的安全性需要客户和阿里云共同来承担。在这种安全责任共担的模式下，我们也发现很多时候用户的安全意识是不足的。对于一些关键业务的关键数据，他们缺少安全防护的意识。所以就会导致实例被攻击了，很多重要的数据被删除了，而且找不回来了。
第二，日常运维操作缺少安全审计与限制。日常的安全尤其是线下的安全，它的运维操作是缺少安全审计的，但在云上我们可以通过开启一些能力来保证，来对ECS所有的高危操作可审计、可追溯。
第三，安全实践落地门槛高。DevSecOps听上去很美好，但在落地过程中如何体系化的构建是非常难的。
ECS Insight的安全能力也是分成不同的维度给用户提供了安全风险的识别和安全最佳实践的规范。
∙ 初级的安全是实例访问安全，包括对于资源的访问设置更安全的访问方式，并支持对各种方式访问资源的行为进行安全审计，实现ECS的安全访问。
∙ 中级的安全是数据安全，包括通过定期数据备份和数据加密的能力，提升关键业务和高敏数据的安全性。
∙ 高级的安全是应用安全，包括通过安全组端口访问规则、漏洞自动化修复、以及WAF、DDOS等能力端到端提升应用的安全性。
在这里ECS Insight会对当前ECS的使用情况和配置情况进行分析和扫描，最终给出风险的提醒。这些问题需要用户自己手动配置，阿里云是无法帮用户配置的。因为它们属于客户自己的范畴。
4. 总结与展望
经过前面的介绍，相信大家已经对CloudOps的产品能力以及CloudOps的概念有了比较深刻的认知，下面我们进行一个总结。
从前面的内容可以看到，ECS Insight使用成熟度评估与洞察和CloudOps之间是互相支撑的关系，CloudOps是ECS提供的一系列的原生工具。希望帮助用户在成本、自动化、可靠性、弹性和安全性各个维度的能力。而且这些是原生的工具，用户可以通过标准的OpenAPI或者通过控制台就能快速的使用，真正的服务业务，进行高质量的业务交付。ECS Insight其实是以CloudOps为基础，从五大维度上对我们当前业务面临的风险进行了分析，并且给出了指定化、定向的优化推荐的方案，来帮助业务降低这几个维度的风险，提升服务的成熟度。
未来，我们将持续完善CloudOps的这些服务能力，更好地服务用户，做云上DevOps的深入实践。如果用户对这部分内容不了解，也可以通过ECS Insight这个产品来了解当前自己业务存在的风险，并通过工具解决风险，实现整个云上业务的安全、稳定、高效、永续。为了更好地帮助用户提升云上DevOps实践效率，缩短开发周期提升业务效率的同时，也能让业务保持稳定、安全、可靠，且低成本地持续运营，阿里云弹性计算团队独家出品的【弹性计算技术公开课_CloudOps云上运维季】正式启动。阿里云弹性计算团队十三位产品专家和技术专家共同分享云上运维深度实践，详细阐述如何利用CloudOps工具实现运维提效、弹性降本。该系列共10节直播课程，在阿里云官网、阿里云微信视频号、CSDN官网、阿里云钉钉视频号、阿里云开发者微信视频号同步播出，本次课程由战略合作媒体CSDN独家支持。
