接上篇：
二、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等安全防护能力进行保障。
整体来说，安全无小事，业务的安全性需要云厂商和用户共同创建。在体系化的构建业务安全时，我们需要从访问安全、数据安全和应用安全等多个维度进行综合考虑。
接下篇：https://developer.aliyun.com/article/1223124?groupCode=ecs
