摘要：2022年3月22日，【全新升级 阿里云ECS CloudOps 2.0来啦！】发布会正式播出，本次发布会上阿里云宣布CloudOps（云上自动化运维）套件全新升级，并发布了CloudOps云上自动化运维白皮书2.0版本。
随着本次产品的升级，阿里云推出了配套的智能化产品方案，即“ECS成熟度评估与洞察（ECS insight）”，它基于用户的ECS多维度的使用数据，从基础能力、成本管理、自动化、可靠性、弹性和安全性六个维度帮助用户分析定位潜在的运维风险，并推荐对应解决方案与最佳实践，全方位帮助企业用户降本增效，提升业务连续性。
阿里云弹性计算高级产品专家马小婷在本次直播中带来了题为《新品介绍：ECS使用成熟度评估与洞察（ECS Insight）》的演讲，以下是她的演讲内容整理：
ECS使用成熟度评估与洞察，简称ECS Insight。顾名思义，ECS使用成熟度评估与洞察是对用户使用ECS的情况，进行分析和评估，然后给出评估后的优化建议。
这个产品是一个数据驱动产品，它的目的是帮助ECS用户能够持续挖掘ECS上的业务风险，结合企业云上运维的最佳实践，进行持续优化，最终实现云上业务的稳定永续。由于ECS使用成熟度评估与洞察的名称比较长，所以后面我们统一简称为“ECS Insight”。
在Cloud白皮书2.0中，我们对CloudOps的定义给出了明确说明，即CloudOps = DevOps x Cloud。因为我们发现95%的企业已经开始使用DevOps进行软件开发和交付，但只有不到20%的企业，真正发挥了云本身的特性和优势，去提升DevOps实践的效率。比如云天然具备高弹性的特性，以及标准化的自服务能力。与此同时，随着FinOps、DevSecOps等概念的盛行，业务的安全性和成本也是DevOps落地过程中不可忽略的重要部分。
在这些背景下，我们提出了CloudOps的概念以及它包含的五个维度，即成本洞察（Cost）、自动化能力（Automation）、可靠性能力（Reliability）、弹性能力（Elasticity）和安全性能力（Security），五个维度简称为CARES。
这也意味着，如果用户在使用DevOps缩短开发周期、提升业务效率的同时，同时希望让业务保持稳定、安全、可靠，且低成本的持续运营，我们就可以从这五个方面入手，进行持续的完善。这与我们希望用户能够提升CloudOps成熟度的出发点不谋而合。
一、CloudOps vs ECS
接下来，让我们看一看CloudOps和ECS Insight之间的关系。上图展示了三部分的内容。
最底层是IaaS层的基础能力，它包含平台侧的基础能力，比如各种计算形态、镜像等服务和用户侧的原子能力，包括资源分组管理，以及Guest OS的个性化配置管理。这些是所有IaaS服务必须提供的能力。
在中间部分，是阿里云提供的CloudOps的产品能力。对于CloudOps定义的CARES五个维度，在每个垂直领域，阿里云都提供了对应的自动化和自服务工具，帮助用户不断提升该垂直领域的成熟度。每个维度的成熟度越高，意味着业务在该领域做的更好，整体业务更稳定、更可靠、更高效、更安全，性价比更高。
比如在成本管理维度，阿里云目前提供了非常丰富的资源付费方式，包括包年、包月、按量预留实例、节省计划等等，用来应对不同场景的需求。对于长期稳定的业务，我们推荐用户采用包年/包月的方式进行购买，这样能够享受长周期优惠。
对于临时测试的需求，我们推荐用户采用按量购买的方式。虽然按量每个小时的单价略高，但它非常灵活，可以随时释放。如果业务存在不同时段的临时需求，且整个业务需求量不小的情况下，我们推荐用户购买节省计划进行抵扣。这样既能享受到随时需要随时创建或释放资源的灵活性，还能够通过节省计划按小时进行抵扣，降低整体的使用成本。
既然有这么丰富的付费方式，在不同阶段我们应该选择什么样的付费方式进行组合，既能够满足不同业务场景的业务负载需求，还能降低整体的使用成本，持续保持超高性价比的优势？这需要用户持续分析和运营。
那究竟该怎么运营呢？基于这些问题，我们就推出了CloudOps的落地实践，即ECS的使用成熟度评估与洞察。它基于用户在CloudOps定义CARES五个维度的使用数据，对该维度的使用情况进行分析，然后提出对应的优化建议，帮助用户持续完善该维度的不足之处，保障业务高效可用、稳定有序。整体来说，ECS Insight是CloudOps定义的落地指南。
二、ECS Insight详细介绍
接下来，我将详细介绍一下ECS Insight这个产品。首先，简单了解一下ECS Insight的工作原理。
ECS Insight是对用户账号下的所有ECS以及关联资源的使用情况进行分析，包括ECS的分布情况，快照的使用情况，ECS、云盘、带宽、各个维度的使用率数据、以及ECS的费用分布等等。通过结合阿里云服务上万家企业沉淀的云上运维最佳实践经验，我们最终会给用户产出两个结果。
一是当前用户在CloudOps多个维度的成熟度现状。每个维度以百分制进行统计，采用扣分制，如果某项没有满足云上推荐的最佳实践，则扣除对应的分数。用户可以查看每个维度的评分项，对应的分值以及是否得分。这个评估结果的更新频次是T+1天。这些用户数据的分析来源，其实是非常丰富的。它不仅包含ECS的操作日志、云监控，还包含用户去的资源管控行为等等。覆盖了用户使用ECS的所有关键指标。
在ECS中，除了CloudOps定义的CARES五个维度以外，我们还增加了一个ECS基础能力维度。因为我们发现，对于云上ECS规模达到一定程度的企业用户而言，ECS对应的规格、可用区、地域分布、以及资源使用率都会影响到整个业务的连续性。所以我们增加了这一部分内容，作为ECS的补充。
二是，对于没有得分项，ECS Insight会明确标识出存在风险的资源，并提供对应优化的最佳实践指南。这些最佳实践自于各个行业，中大型企业的经验沉淀，是大家多年摸索和成长的积累，非常具有参考意义。
了解完ECS的工作原理之后，我们可以快速看一下ECS的产品页面。目前，这个产品还处于测试阶段。用户通过申请后，就可以在ECS控制台，看到自己当前账号下，ECS成熟度评估的报告。
这个报告可以分成三部分，如上图所示。
第一部分是左侧以雷达图展示ECS使用成熟度评估现状的全貌，从ECS的基础能力和CloudOps的六个维度，对用户当前使用ECS的情况进行全面评分，您可以看到总得分以及每个维度的分值。
第二部分是页面上方展示的每个维度的得分详情以及该维度总得分，包括该维度一共包含了多少个评分项，多少项得分，多少项没得分。虽然最终分值和成熟度的匹配，不完全相关，比如80分以上表示高级，79分是中级，但是，分数越高意味着业务在该维度存在的风险较少。目前，每个维度的评分项并不完善，分值分配仍有完善空间。我们后续将持续进行优化，欢迎大家提供反馈建议。
第三部分是页面下方的评分项详情。用户可以经常看得分项或失分项。针对每个失分项，我们提供了失分的原因说明，以及如何进行优化的建议指南。对于非常具体的评分项，我们还会列举具有风险的资源详细信息，包括资源ID、可用区、IP信息等等，从而方便用户快速定位出现问题的资源，并及时采取行动。
接下来，让我们看一下ECS每个维度的产品能力，帮助大家对每个维度成熟度的提升方式有更直接的体验。
首先，看一下ECS的基础能力。虽然CloudOps成熟度中，并没有包含ECS的基础能力，但它与公有云本身的特性密切相关，会直接影响到云上业务的连续性。所以我们增加了这个维度。
大家都知道，公有云上的云服务器都是分为规格族和规格，比如通用型实例、计算型实例、内存型实例。随着芯片、硬件、服务器的演进，实例规格族还在不断的增加。阿里云目前提供的实例规格，已经超过了300种。上图展示了，阿里云提供的不同场景的最新实例规格族，这个图几乎每年都会全部更新一轮。对于一些比较老的实例规格，比如经典网络的实例，它不仅性价比低，而且不支持部分新功能的特性，面临较多的限制。所以我们推荐用户需要跟随着实例规格的演进，持续的更新底层资源的规格，不仅能够提升性价比，还能够保障业务的稳定性，一举两得。
此外，随着资源规模的增加，资源使用者的数量也会逐渐变多。不同用户对于不同资源的使用权限不一样。当资源规模达到一定程度后，如果我们不根据业务单元对资源进行分组和分权管理，不仅会面临资源查找慢的问题，还会因为部分用户权限过大，导致误操作等一系列严重后果。
面对这些痛点，ECS的基础能力从计算、存储、网络和账号管理四个维度，评估ECS以及关联资源的分布情况、使用情况是否合理，及时发现并识别业务在性能高、可用等维度存在的一些潜在风险，并提供对应的优化建议，为云上业务的持续运营，提供指导方针。
总体来说，ECS基础能力的成熟度评估是，识别云上资源管理最基本的分布，使用情况是否合理，从而避免单个资源的常规性风险。
第二部分是成本洞察能力。
前面提到的ECS实例不仅规格繁多，还提供了非常丰富的付费方式。包括包年、包月、按量、抢占式实例、预留实例、节省计划等等。上张展示了不同付费方式，适合的业务场景。如何根据业务的形态，选择性价比最高的付费方式？这非常考验大家的算数能力。
同时，如果企业里存在多个不同的团队，出现一起使用云资源的场景。如果我们不对资源的使用方或团队进行准确的核算和分摊，会导致大量的资源浪费。最终，导致企业的云上支出远远超出预期。这与企业想推进FinOps的初衷，背道而驰。如果我们采用一刀切的方式进行成本控制，势必会影响部分业务的正常发展。如何根据资源的实际使用情况，进行准确识别，并且针对性的进行优化，最终实现成本优化与业务发展两不误是非常重要的。
面对这些问题，成本洞察能力从三个方面提供了分析和推荐。
首先，我们需要帮助用户识别一些闲置或低使用率的资源。推荐用户使用云上灵活的变配、停机、不计费等自服务能力，避免一些显而易见的铺张浪费。
其次，我们推荐用户使用类似于预留实例券、节省计划等权益类产品。对一些临时的按量资源进行抵扣，最终降低这一部分的使用成本。
最后，我们推荐用户借助标签、财务单元、预算管理等工具，进行端到端的成本管理分析，持续优化成本支出，最终实现FinOps的落地。
整体来说，成本洞察能力的成熟度评估是，指导用户更好地利用云上灵活的付费方式和成本管理工具。在避免不必要的成本浪费的基础上，端到端的进行成本的管理。
第三部分，是自动化能力。
不少人对于DevOps一直有一个误解，认为DevOps就是自动化。其实自动化只是实践的一种手段，而且是一个非常重要的手段。为什么自动化如此重要呢？
因为受限于技术能力或业务发展阶段的限制，不少企业的自动化能力目前都严重不足。不少企业靠人海战术支撑，不仅响应周期长，而且容易出现失误。同时，我们也观察到部分用户能通过脚本完成一些基础的运维工作。但这部分脚本大多数是个人独自维护，很难复用或形成规范。
上图展示了，目前在自动化领域的演进方向和现状。欧美企业在IT管理上的自动化的程度更高，主要是因为欧美企业的人工成本高。国内企业的自动化处于偏下水平，大量用户依赖UI控制台、终端工具或脚本进行自动化。
面对这些问题，自动化能力的成熟度评估从三个层面上提供了分析和推荐。
最基础的是，通过控制台或open API的方式，完成基础的资源管控操作。这个能力大多数的用户都能做到。
中级水平意味着用户能够借助自动化工具，完成DevOps中的基础设施及其代码、或运维及其代码的自动化管理，提升类似于CICD等高频管理场景的效率。
在阿里云上，用户可以借助类似资源编排、云助手运维编排等工具，完成应用的发布和部署。它涉及资源交付申请、应用打包分发、以及应用灰度发布等多个环节。如果每个环节都能自动化，可以将整个应用的发布周期从以前的3~5天，缩短到一个小时。
如果需要达到更高级的水平，需要用户组合使用多种自动化的服务和工具。并且形成标准化的运维流程和统一的配置管理平台，最终实现标准化和统一化的运维。
整体来说，自动化能力的成熟度反映了当前用户在ECS管理运维上的自动化的水平。同时也为用户提升自动化水平，提供了对应的路径和工具。用户借助这些自动化工具的使用，能够更高效地解决日常运维的痛点。
第四部分是可靠性能力。
讲到可靠性，大家首先想到的是底层基础设施的稳定性，比如SLA。但是这里存在一个大家都忽略的问题，即底层基础设施的稳定性，只要不是100%，意味着不完全可靠。如果我们将业务的可用性寄希望于单个实例的稳定性是非常不可取的。如果从根源解决问题，应该加强应用构建，使它具备高可用的特性。
同时，在同一个企业里，不同的业务团队对稳定性的诉求不一样。比如一些离线业务的大数据计算集群，可能会要求晚上12点~7点之间业务是不能中断的。对于一些在线服务业务而言，它的高峰期可能是早上9点到晚上10点。在不影响业务可用性的情况下，多个部门对底层变更响应的协同成本实非常高。一旦出问题需要一些自动化的辅助工具，帮助工作人员快速排查和定位。
上图展示了ECS可靠性的能力支撑，ECS的可靠性主要来自两部分。第一部分是，底层基础设施的稳定性。第二部分是，ECS内的稳定性。基础设施的稳定性取决于公有云的地域、可用区的分布、以及单个物理服务器的稳定性。所以要实现初级的可靠性，我们需要将业务尽可能的分散在不同的物理机、不同的可用区进行部署，从而避免大规模故障的风险。
对于ECS内的稳定性，则需要借助高可用架构的保障。我们需要周期性的进行数据备份，需要实时监控实例的性能波动。当实例的性能出现异动时，我们需要快速的自动完成业务切换，提升业务本身和数据高可用的能力。
高级的可靠性则离不开更多维度的实时监控，故障演练、故障注入等工具的支持。这是一个更偏系统工程的建设，工具和能力只是辅助手段，更重要的是多个不同团队的协同。
整体来说，在可靠性的成熟度上，ECS Insight从实例的稳定性、数据的可靠性、性能的可靠性、以及可观测性四个维度进行评估。我们推荐用户先要做到初级和中级的可靠性。目前这四个维度的衡量，基本上可以帮助用户做到初级、中级和部分高级的可靠性。至于更高级的可靠性，则需要配合持续的演练才能达到。
第五部分是弹性能力。
弹性能力是云最基础的优势之一，按需取用按量付费是弹性的本质，也是云的重要特性之一。相比于线下IDC，对于临时大规模的弹性需求，不仅交付周期长，还有可能因为预估不准，导致资源准备不足，最终影响业务效果。对于存在峰谷波动的业务而言，如果提前扩容，会存在资源超配的情况，不仅前期投入高，而且存在大量的资源浪费。如果进行人工扩容，则存在反应慢，可能因为扩容不及时，导致业务受损，最终影响用户体验。
所以如何利用云上灵活的弹性能力，在满足业务需求的同时，避免资源和成本的浪费是至关重要的。ECS Insight的弹性能力从以下三个维度，为我们提供了指导。
最初级的方式是，通过控制台或Open API批量购买或释放按量的ECS实例。这样就能够通过半人工的方式，满足临时的弹性需求。对于明确的弹性需求，ECS建议使用弹性伸缩，实现资源跟随业务的波动，自动进行水平扩缩容。在提升业务高可用的同时，降低使用成本。
在这个基础上，如果用户有更复杂的业务需求。我们可以借助弹性伸缩的生命周期，挂钩弹性强度评估以及实例规格范式的方式，提升业务的弹性、灵活性和韧性，最终实现全自动的、自适应的弹性资源管理，保障在线业务的连续性。
弹性能力是用户判断使用是否合适的，最直接的体现之一。弹性能力的成熟度评估，则反映了用户对云的使用深度。用好了弹性，在某种程度上可以说用户也就用好了云的一半。
最后一部分是安全性能力。
安全问题是一个很难证明，也很难证伪的问题。安全防护不容易直接看到效果，不少企业都存在侥幸心理。一旦安全防护没有做到位，后果也非常严重，轻则业务临时不可用，重则核心数据丢失，损失巨大。基于这个事实，我们观察到不少企业客户的安全意识严重不足。包括对关键业务的关键数据缺少防护意识，导致实例被攻击后，重要的数据被删除，无法找回。
云上安全能力的构建是一个责任共担模式，它需要云厂商和用户一起进行构建。云厂商负责对底层基础设施的安全性进行保障，包括云服务器镜像、支撑云服务器、镜像底层的软硬件服务。除此之外，还包括各个地域和可用区的服务器、网络设备、存储设备等安全性，以及虚拟化系统的安全性。
用户则需要对语音服务器ECS上的操作系统、操作系统里的应用数据、以及应用业务架构的安全性负责。包括环境变量配置，软件应用，数据安全，安全合规等等。如果用户自身不做任何安全防护和措施，完全依赖底层基础设施的安全性，相当于在裸奔。
除了安全意识不足，用户在安全实践的落地层面，也面临门槛高的问题，包括明确制定安全规范，及时扫描并发现不符合安全规范的安全问题等等。在这个维度上，ECS Insight从访问安全、数据安全和应用安全三个维度为用户提供了明确的提升路径。
访问安全关注的是，资源的访问权限和访问审计的问题，包括设置更安全的实例登录方式，为实例访问提供登录审计、防止未授权的访问等等。
数据安全是不少用户面临的问题，与线下机房不同的是，云上数据一旦被删除是无法找回的。因此，养成定期备份重要数据或对高敏数据进行加密，能够大大提升数据的安全性。
应用安全性则是业务持续运行的终极目标，应用安全的保障在访问安全、数据安全的基础上，需要持续的完善应用本身的代码的安全性。以及通过类似WAF、DDOS等安全防护能力进行保障。
整体来说，安全无小事，业务的安全性需要云厂商和用户共同创建。在体系化的构建业务安全时，我们需要从访问安全、数据安全和应用安全等多个维度进行综合考虑。
三、总结与展望
综上所述，ECS Insight产品和CloudOps一脉相承。它从CloudOps定义的CARES五个维度，对用户使用ECS的情况进行全面的分析和评估。结合云厂商的最佳实践，识别各个维度中存在的可优化点，并提供对应的建议来帮助用户进行持续优化。
目前，每个纬度下的能力评估和准确度不够完美。因此在新一年里，ECS Insight会持续在两个方向进行优化。一方面，我们会持续优化并提升CloudOps CARES五大维度评分的准确度，让每个维度的评分能更准确的反映用户的实际情况。这个能力的完善离不开采集更多的ECS指标和使用数据，离不开用户对阿里云的信任和支持。
另一方面，我们将持续完善CloudOps的自服务能力，为用户在云上进行DevOps的实践提供更全面、更智能、更自动化的能力支撑，帮助用户充分利用于本身的优势，助力其业务高质量的交付和安全稳定的运行。
点击链接回看精彩直播，点击链接/扫码还可阅读/下载《CloudOps云上自动化运维白皮书2.0》
