1. 自动化能力Automation
1. 1 自动化能力的基本概念
自动化即是通过运用工具或系统达到减少、甚至是完全取代人工的操作。以完成一个云资源的创建为例，完全人工的操作即在控制台上，完全通过鼠标和键盘在网页上进行操作，以完成资源的创建和购买的目的。
这个创建和购买的过程可能包括10个，乃至20个以上的操作。而自动化的方式，即是减少需要的步骤，从20个步骤，减少到10个，进而减少到5个，3个，甚至1个，最终可以一键完成一个自动化操作。这依然需要人工来触发整个自动化的流程，再进一步，则可以自动触发。如在流量高峰时段，自动创建服务器并部署应用就是一个完全的，100%的自动化的例子，整个过程无需人工参与。
1.2 自动化的业务价值
自动化的业务价值整体可以归纳如下：
• 降低成本，提升效率：现代IT的核心特点即是快，天下武功，唯快不破，效率提升，永无止境。而达成效率提升的最佳手段即在于将重复的、低效的、容易出错误的人工操作转变为自动的、高效的、稳定的自动化操作，同时也将降低员工所需要付出的时间等成本。
• 减少人工错误：当需要人工不断重复地、机械性地完成一项工作时，非常容易造成疲劳，疲倦，从而操作粗心造成错误，很多云上的大事故，都是因为人工的不当操作而造成的。甚至是在故障的处理过程中，因为缺乏标准流程或标准自动化工具，进而导致更大的故障。
• 提升员工满意度：大概没有人会喜欢这种重复的、机械的人工操作，尤其是还可能造成重大事故的情况下。因此提升自动化，则可以提升员工的满意度甚至是幸福感，进而可以提升运维（Ops）的乐趣，让员工可以快乐地工作。
1.3 如何衡量企业运维体系的自动化成熟度
任何事物的成功都离不开客观的数字化，以及相关的衡量指标。依据指标可以清晰地看到自己所处的自动化阶段，自动化的应用程度，以及未来继续发展的方式和目标。
1) 自动化率
统计出日常工作中所需要的所有和开发及运维相关的操作，然后看看其中多少的操作已经是自动化完成的，多少操作是半自动化所完成的，多少操作是手工所需要完成的，分别占比多少，最终可以形成一个全局的饼图。
运维操作自动化占比示例
2) 操作时长和频次
毋庸置疑，自动化的操作速度远大于手工操作。如能记录完成操作所需要的时间，再进行自动化前和自动化后的对比，便可轻易地看出自动化的价值所在。尤其是频繁，复杂的操作，业务价值的体现则会更加明显。现代IT中最为频繁的操作为：
• 环境部署（Infrastructure）
• 环境配置（Configuration Management）
• 应用部署和配置（Application Deployment）
• 日志、报警或故障处理
3) 平均修复时间MTTR
从报警发生到故障被解决，系统被恢复的时间，称之为平均修复时间（Mean Time To Repair），它的公式如下：
平均修复时间=总故障时间÷总故障次数
举例来说，假设一年的总共故障时间是100小时，总的故障次数是12次，则平均修复时间为8.3小时。进一步，则可以根据故障的分类，模块，根因等进行分类，分别进行统计。
特别说明：在严格的情况下，请注意平均修复时间和平均恢复时间的稍许区别，前者不包括从故障实际发生到报警的时间，只是包括故障已经被发现，并且开始进行故障修复的时间，而平均恢复时间包括两者：从故障实际发生到故障报警，和故障报警到故障修复的时间。通常来说，故障报警所需要的时间相当于修复所需的时间而言较短，且占比较少，因此在宽松的语境下，两者会被混用。
4) 高质量的自动化所应具备的特性
除此之外，现代化的自动化还应该考虑以下需求：
• 完备的角色管理和授权体系：毋庸置疑的是，自动化能力将会涉及到所有系统的所有环节，包括核心业务系统，机密数据等操作。越是重要的系统应该越依赖自动化能力而非手工方式，因为人工的处理存在种种的弊病，如因为粗心导致的失误操作等。因此，完备的角色管理和授权体系可以保证重要业务持续运行，以及保证机密数据的安全性。
• 具备审计能力：所有的自动化都应该具备可以被审计的能力，尤其是当所操作的对象是核心业务或机密数据时，更依赖审计能力去保证其安全。其次审计能力也有利于自动化系统本身故障的排查。Cloud上的云产品大多已经接入了Cloud上的审计服务，应该开启这类服务，并时常检查数据的完整性，保证关键的操作都被记录了下来。
• 标准化和平台化：统一的自动化能力是其他特性的重要依赖，标准化和平台化的目的都是为了统一。统一性的管理也有助于平台自身的建设，尤其应该避免建设多个自动化平台。统一的自动化平台也有利于公司统一进行监督和扩展，如要修改审核规则时，更容易落实规则。
5) 自动化能力成熟度模型
如果您希望对所在企业的自动化能力成熟度进行评估，建议至第十章进行“CloudOps成熟度自评”。
1.4 阿里云的自动化能力和产品
1) 第一层：特定场景的自动化能力
适合“中级”的自动化场景和需求。
• 弹性伸缩
｡ 使用场景：当服务器数量需要进行弹性化管理时。
｡ 弹性伸缩服务：弹性伸缩（Auto Scaling）是根据业务需求和策略自动调整计算能力（即实例数量）的服务。您可以指定实例的类型，即ECS实例或ECI实例。在业务需求增长时，弹性伸缩自动增加指定类型的实例，来保证计算能力；在业务需求下降时，弹性伸缩自动减少指定类型的实例，来节约成本。弹性伸缩不仅适合业务量不断波动的应用程序，同时也适合业务量稳定的应用程序。
｡ 使用场景：当需要具备完全自动化的部署能力时，甚至可以达到一键部署。
｡ 资源编排服务ROS：资源编排服务ROS（Resource Orchestration Service）是阿里云提供的一项简化云计算资源管理的服务。开发者和管理员可以编写模板，在模板中定义所需的阿里云资源（例如：ECS实例、RDS数据库实例）、资源间的依赖关系等。ROS的编排引擎将根据模板自动完成所有资源的创建和配置，实现自动化部署及运维。
｡ 产品文档
｡ 使用场景：当某个特定的事件发生时，应该触发的自动化任务。
｡ 说明：事件的来源可以来自Cloud的云产品和服务器，也可以主动发送自定义事件。通常Cloud本身关注的是基础设施（Infrastructure）层，而自定义事件则多是业务系统和业务逻辑层。当事件发生时，可以触发启动相关的自动化任务，如自动检查，自动修复，或者通知某运维人员。事件通知内通常都会包括一些简单扼要的关键信息，如包括实例ID等，这类可以提取出来作为自动化任务的参数。
｡ 使用场景：当需要根据监控报警触发自动化任务时。
｡ 说明：和上述场景类似，区别在于这里的触动来源是报警。通常也可以分为Cloud提供的基础设施（Infrastructure）层的报警和业务系统和业务逻辑层的报警。并以此为触发来源，触发自动化相关的任务。
｡ 使用场景：当需要在预定的时间开始执行的任务。
｡ 说明：和上述场景类似，区别在于这里的触动来源是根据预设的时间，通常允许按日，按周，按月等周期性定时运维。
2) 第二层：通用的自动化能力（原子能力）
适合“高级”及以上的自动化场景和需求。
适合通用的云上运维工作流编排引擎，且应该具备以下能力：
｡ 编排任何云产品Open API的能力，包括打通服务器内部和容器内部。
｡ 丰富的控制手段：并发控制，批量控制，错误控制，暂停控制。
｡ 必要的审批环节：事先审批，事中审批，事后通知。
｡ 支持多种触发方式：定时触发、事件触发、报警触发，手动触发。
｡ 支持代码化，集成版本控制系统如Git即可完成版本管理，以及GitOps，Ops as Code等先进运维理念。
阿里云运维编排OOS即是这样一款具备以上能力的自动化运维平台。
除了云产品管控面的服务能力之外，更应该更进一步，进入到数据面提供运维能力。因此应该具备打通服务器内部运维的能力：
当以上的云产品都无法满足自动化需求时，或需要的自动化能力非常灵活时，则可以依赖最基础的能力，云产品的原子能力 —— OpenAPI、SDK和CLI。
Cloud厂商提供的SDK应该是使用OpenAPI的第一选择，SDK不仅给OpenAPI的调用提供了方便，更包含了诸多API调用的最佳实践等，根据二八原则，如默认配置应该可以满足80%的场景。
除此之外，Cloud厂商提供的CLI也是不二选择，当需要在Shell或脚本语言中快速集成时，或者当需要构建一个PoC类型的自动化项目时，直接使用CLI就可以快速达成目的。且CLI的语法相对而言比较简略，因此更容易上手。
3) 阿里云自动化能力和产品金字塔
4) 阿里云产品和能力与业界工具对照表
2. 弹性能力Elasticity
2.1 弹性能力的基本概念
Gartner从两个维度定义了云服务的弹性能力：
• 从云服务器提供商的角度，云服务的弹性意味着“云服务具备根据需要自动增加或减少系统容量的能力（比如CPU、内存、磁盘和网络带宽），这会给用户带来一种无限算力的感知”。
• 从客户的角度，云服务的弹性指的是云服务具备自动跟随需求的波动变化增加或减少特定服务容量的能力。
弹性能力主要解决在某个具体业务场景下如何实现资源与业务负载波动匹配的能力。当然还有一种更为广义的弹性描述，即云资源支持按需取用，需要时可快速获得，不需要时可随时释放资源的能力，这种能力目前已经成为公有云的能力标配，本文不做更多相关阐述。
弹性能力指的是平台具备根据业务负载变化，及时且独立地增加或减少基础设施资源的能力。其中，资源可以是CPU核数、内存、网络带宽，磁盘，也可以是ECS实例。弹性能力是公有云典型优势之一，根据添加或减少资源的粒度，弹性能力可以细分为以下两类：
• 垂直弹性（vertical elasticity）：主要指的是增加或减少计算资源的某个组件，比如CPU核数、内存大小、网络带宽大小、磁盘空间大小等。
• 水平弹性（Horizonal elasticity）：主要指的是增加或减少相同计算资源的数量。
与弹性能力有关的一个概念是可扩展性（scalability），它通常指的是在不中断服务的前提下，系统具备通过增加当前的硬件资源（向上扩容）或增加额外的硬件资源（横向扩容）的方式应对更高业务负载的能力。与弹性能力总是试图提供与当前业务负载匹配的动态能力相比，可扩展性是一个静态属性，即以增量方式通过提供更多资源来满足负载增加的场景。
当业务负载下降时，弹性能力会动态释放不需要的资源，而可扩展性不会。所以，可扩展性只能满足部分弹性场景的需求，可以看做是弹性能力的一个子集。
2.2 弹性能力的业务价值
对于具有周期性峰谷波动，或者面临偶发临时流量激增的业务而言，如何快速响应避免流量高峰期业务不可用，客户侧的常见需求如下：
• 资源交付的速度：指的是获得资源的周期，包含从发起资源请求到资源交付的周期。
• 资源数量的保障：指的是获得所需资源的成功率，成功率也会影响业务是否受损，比如单次资源扩容需要1000台算力，但因为资源不足导致只能交付500台。
• 资源的交付效率：主要指的是资源从获得到可用的时间周期，交付效率最终会影响业务是否受损；如果资源已经交付，但业务初始化配置的周期较长，则会延长最终上线时间。
• 资源的使用成本：指满足业务计算诉求时的获取成本，当然也包括当资源不再需要时，用户可以释放并且不再收费。
公有云的弹性能力能为业务带来的价值包括：
• 敏捷性：当业务出现激增需求时，在传统模式下，用户需要经过采购、安装、配置等长周期的流程，无法快速响应业务的变化；而云上的弹性能力能帮助企业快速满足计划外的需求，而无需考虑季节性波动。
• 高可用性：对于周期性波动的业务负载，通过自动化的水平扩缩容能力，可以实现跟随业务负载的波动自动创建或释放资源，提升业务的连续性。对于突发的激增流量，云上快速的弹性能力也能在分钟级完成所需资源的交付，大大提升业务的高可用性。
• 节省成本：在传统模式下，所有资源的成本在采购之初就已支出，不管资源是否被使用。而云上资源按量付费的模式允许客户仅需为使用的资源付费，不需要的资源可随时释放。同时，还允许用户跟随波动的实时业务负载需要调整资源的大小，实现成本最优。
• 高效：自动化弹性可以实现根据用户指定的策略或者自适应策略，自动调整资源的数量，完全无需人工参与，不仅能更快地响应业务的变化，而且释放运维人员的维护。
2.3 如何衡量弹性能力成熟度？
1) 如何衡量弹性能力
在衡量弹性能力之前，可以先看看几个典型的弹性业务场景，包括：
• 电商平台：年度大促或周期性促销需要大量的临时资源来保障促销活动的流量洪峰，比如国内的双11大促销、黑五活动，每日秒杀等。
• 社交媒体：类似微博等媒体平台，当出现艺人八卦引发社交用户热议等类似场景时，需要紧急快速扩容，避免服务不可用。
• 在线旅游平台：在长假前一段时间会出现机票酒店查询与订购的请求高峰，比如国庆假长假，春节假期等。
• 在线视频/游戏平台：每天晚上放学或下班后到半夜期间是休闲娱乐的高峰期，平台的访问流量是白天的几倍或几十倍。
• 临时的开发测试：需要快速完成测试资源的交付，并在开发测试结束后释放对应资源。
在评估弹性能力之前，首先需要明确不同业务场景在做弹性化改造过程中面临的一些挑战，具体如下：
• 弹性速度：尽管云上计算资源是按需取用，但资源的交付速度（从资源购买到资源可用的延迟）至关重要。当某个流量洪峰突然出现时，留给资源响应的时间通常不会太长，如果资源无法快速交付，则会直接影响业务的正常访问。
• 弹性成功率：公有云上资源规模庞大，对单个用户而言可以认为是提供无限算力，但不同云厂商在不同地域的资源池规模大小不一。当某个可用区的资源规模有限时，用户可能会遇到因资源不足导致弹性算力无法满足的情况，弹性成功率将直接影响业务的连续性和可用性。
• 弹性效率：对于类似渲染或科学计算等需要大规模算力的场景而言，如果用户分批申请所需算力，只有当全部算力都准备完毕才能开始执行任务，必然会导致部分已申请但未使用的资源浪费，因此，一次性交付大规模算力的效率将大大提升业务的效率。
• 弹性准确性：对于自动响应业务负载波动的弹性场景而言，如果申请的资源需求大于当前业务负载需求，则会出现过度供给带来资源和成本浪费，而如果拥有的资源需求小于当前业务负载需求，则会出现业务服务降级甚至不可用的场景。因此，提供与业务负载匹配的准确资源量，能更好的实现业务与成本的平衡。
• 弹性资源预定：对于非常规的弹性需求，比如类似双十一的年度大促活动或者新游戏开服时，客户在无法确保弹性成功率的情况下，需要额外的弹性资源保障机制以应对预期外的业务流量。
2) 弹性能力分级
云上的弹性能力与资源的使用和成本密不可分，要全面衡量业务的弹性成熟度需要同时从业务的弹性管理能力和资源成本管理两个维度进行。
因此，我们将弹性成熟度分为以下五个等级，对应的能力要求如下：
如果您希望对所在企业弹性能力成熟度进行评估，建议至第十章“CloudOps成熟度自评”。
2.4 提升弹性能力的建议与步骤
要充分利用云上的弹性能力提升业务的可用性，用户可以根据以下步骤对云上业务形态和架构进行分析，并进行相关业务改造，提升业务的高可用性的同时降低成本：
a) 分析并识别业务中负载存在波动的业务模块。
b) 明确不同业务模块对应的负载波动上下限，它们决定了该模块在业务高峰期和低谷期所需资源的数量。
c) 分析负载波动所需资源的数量和对应时间分布，明确所需资源是否能通过自动扩缩容满足，还是需要提前准备，比如类似双11大促的活动，流量会激增几百倍，一定需要提前准备相关资源。
d) 明确不同业务模块在应用层的要求或约束，比如系统初始化要求、会话保持、资源释放时的数据处理要求等。
e) 分析目前不具备弹性能力的业务模块是否可以通过类似弹性伸缩的产品进行改造，提升业务的可用性。
f) 根据业务历史波动规律，配置相关扩缩容策略，并测试是否满足业务负载变化的需求。
g) 持续测试并改进弹性伸缩相关配置，直到与业务波动匹配。
2.5 弹性工具推荐
1) 开源的弹性工具推荐
目前在虚拟机（Virtual Machine）维度的水平扩缩容暂无主流或广泛使用的开源工具，但容器（Container)维度的水平扩缩容则以Kubernetes的调度层弹性组件使用最为广泛。
• Kubernetes的调度层资源主要分为两个维度
｡ Node级别：即多个服务器组成的一个集群资源池。
｡ Pod级别：是Kubernetes中最小的部署单元，代表一个运行的时机应用程序。
Kubernetes的调度层弹性主要是根据业务负载的变化，自动调整应用对一个副本的数量或资源的大小，从而实现调度层的伸缩。Kubernetes的弹性组件分为两类：水平伸缩（HPA）组件和垂直伸缩（VPA）组件。
Kubernetes通过Horizontal Pod Autoscaler组件，根据资源使用率或者自定义指标实现pod副本的自动增加或减少，其工作原理如下：
Kubernetes通过Vertical Pod Autoscaler（VPA）组件，根据容器资源使用率，自动设置CPU和内存调整的请求，允许在pod上进行资源的调整。VPA会基于pod资源的使用情况，自动为集群设置资源占用的限制，从而让集群将pod调度到有足够的资源的最佳节点上，其工作原理如下：
2) 阿里云的弹性工具推荐
阿里云提供了丰富的VM粒度的弹性产品与工具，用户可通过控制台或标准OpenAPI，快速完成业务的接入和结合，提升云上业务的可用性和连续性，同时降低云上成本。
对于单体应用、独立应用、或有状态的应用等场景，随着业务不断升级和变化，用户需要快速升级资源配置以应对业务变化。
例如，某些视频平台的晚上6点到12点是业务高峰期，不论是计算能力还是网络资源，其需求量都会大于之前的水平。此时，客户需要对系统进行配置升级，如升级到性能更高的实例规格、提高带宽配置、扩大磁盘大小等。当高峰期结束时，整体负载下降到低谷状态，出于成本的考虑，企业可以对云服务器进行配置降级，如降低实例规格、降低带宽值等。
阿里云的云资源均提供控制台和标准的OpenAPI，用户可以根据需要自助完成云资源的配置变更。目前，阿里云提供的VM维度的垂直伸缩能力包括：修改CPU核数、内存大小、磁盘大小、公网带宽大小、修改带宽的付费方式等。用户还可以通过运维编排服务（OOS），设置在指定时间或当某个条件触发时自动调整VM的规格，满足各种场景需求。
对于科学计算、图形图像渲染等场景而言，其业务对算力交付的需求通常较高，包括单次任务所需算力规模较大（可能需要几千上万核的算力）、海量算力尽量一次性满足（否则任务也无法正常执行），希望算力成本越低越好等。因此，海量算力快速交付的能力也体现了云厂商的弹性深度体验。
公有云的按量付费模式衍生了一种新的付费形态，叫可抢占式（Spot）实例或竞价实例。Spot实例的本质是把公有云的闲置资源以较低价格（一般是按量付费价格的10%~90%）出售，吸引价格敏感的用户出价购买，价高者得。
Spot实例虽然价格便宜，但因为它采用的是竞价模式，价格会随闲置资源使用波动，也就意味着一旦Spot实例的市场价格超过用户出价或者系统因为库存等需求，该实例就会被平台自动回收，实例上运行的业务就会停止，因此用户的应用需要对这种行为进行适配。对于部分价格非常敏感但容错性较高的业务而言，如果能充分利用Spot实例的特性，就能以较低成本快速完成业务的交付。
阿里云的弹性供应组是一个快速交付ECS算力集群的方案，用户只需要指定所需算力的大小和单位（支持vCPU核数，ECS实例个数，内存数量等），以及可用区和实例规格，弹性供应组会自动去指定的可用区扫描指定实例规格的算力，最终交付指定大小的算力。除了交付算力外，弹性供应组可以在以下几个维度进一步满足个性化的弹性需求场景：
• 精细化的成本控制：对于价格敏感的用户，弹性供应组支持指定算力集群中按量和Spot实例的比例，在确保基础算力的基础上，通过spot实例降低算力集群的总拥有成本。弹性供应组还支持指定实例规格最高出价，以及成本优化类型的交付模式，这样系统会自动在指定可用区下的实例规格中选择价格最低的实例进行交付，进一步降低算力的使用成本。
• 算力自动保持：如果使用了spot实例，当spot实例被回收以后算力集群的总容量会下降。通过弹性供应组的保持模式，当spot实例被回收或者总算力未满足时，弹性供应组会自动寻找算力进行补充，完全无需人工干预。
弹性供应组会根据用户指定的可用区和实例规格进行组合交付
对于分布式应用、无状态应用、大型应用等场景，用户手动指定固定数量的云资源已经无法满足业务快速和剧烈的变化。客户可以借助于阿里云的弹性伸缩服务（ESS），根据业务需求和策略自动调整实例数量，在业务需求增长时，弹性伸缩自动增加实例，来保证计算能力；在业务需求下降时，弹性伸缩自动减少实例，节约成本。
同时，弹性伸缩具备实例健康检查能力，能自动识别并替换不健康的实例，不仅适合业务量不断波动的应用程序，同时也适合业务量稳定的应用程序，保障业务的持续运行。
目前弹性伸缩（ESS）产品提供了以下几个维度的自动化能力，帮助客户自助实现业务的自动化智能化扩缩容，快速提升业务可用性。
• 灵活丰富的扩缩容模式
对于业务负载波动比较稳定的场景，例如在每天中午12点开始业务需求明显增加，每天晚上8点后需求明显减少的场景，用户可以通过定时任务快速完成可预期负载的响应。但对于业务负载变化无明显规律，或者在规律性波动外偶尔有突发负载的场景，需要更灵活的伸缩模式来响应业务波动。弹性伸缩目前提供的扩缩容模式包括：
｡ 手动模式：允许用户手动进行弹性伸缩，包括手动添加、移出或者删除已有的资源。
｡ 固定数量模式：用户设置集群的最小/最大期望资源数量，当实例数量低于下限/超过上限时，系统会自动添加/移出资源，使得资源数量等于下限/上限。
｡ 健康监测模式：系统自动检查计算资源的运行和健康状态，如果发现一台计算资源未处于运行中或处于不健康状态时，弹性伸缩服务会自动移出该资源，并创建一台新的资源进行替换。
｡ 定时模式：用户可以通过创建定时任务，实现在指定时间内自动创建或释放指定4数量的资源。
｡ 指标模式：监控集群中资源的性能指标（如CPU利用率、网络流量均值）波动，当指标当前值超出制定阈值时，自动触发执行资源的扩缩容。
• 完善的业务指标监控矩阵
一般业务负载的波动都与一个或多个业务指标有强关联性，即用户可以通过监控业务负载的一个或多个指标识别到业务的上下波动。阿里云的弹性伸缩服务不仅支持根据伸缩组内集群实例的十几种性能指标进行扩缩容，比如实例的CPU使用率、内存使用率、网络吞吐率等，还支持根据其他产品的指标进行自动扩缩容，比如负载均衡的QPS。
• 弹性自愈的能力
弹性伸缩自带的健康检查能力，会周期性扫描伸缩组内ECS实例的健康状态。如果发现某个实例处于关机状态（不提供正常服务）或实例OS内出现异常导致实例无法正常响应，弹性伸缩服务会自动移除该实例，并创建一个新的实例进行替换，确保业务所需算力。此外，当伸缩组与某个负载均衡关联后，如果负载均衡发现伸缩组内某个实例出现异常，自动将该实例摘除后，弹性伸缩也会自动创建一个新实例，确保算力稳定。
• 有效的成本控制
弹性伸缩目前提供两种方式帮助用户在保障业务可用性的基础上，尽可能降低算力成本。
｡ 一是弹性伸缩支持扩容时同时选择按量和抢占式实例，以及指定两种实例的比例。
｡ 二是弹性伸缩的动态伸缩模式和预测的伸缩模式均可以自动根据业务负载波动自动计算所需算力的调整，实现资源规模与负载需求直接的完美匹配，避免过度供给带来的成本浪费。
• 个性化的弹性管理能力
对于部分无法做到完全无状态的业务负载，比如在扩容时新交付的实例正式承接负载前，需要下载最新的数据或代码，弹性伸缩的生命周期挂钩可以实现扩缩容时的个性化配置。
目前，弹性伸缩支持扩容和缩容两种类型的生命周期挂钩。用户可以创建扩容时的生命周期挂钩，在新扩容出来的实例正式使用前，在实例内做一些自动化的配置任务，比如安装某些应用程序或执行某些脚本。当任务完成之后，才真正将实例投入使用。缩容的生命周期挂钩也是类似的场景，满足多样化的弹性诉求、
对于自动化能力较高的用户，希望监控弹性伸缩的各种行为与结果并与其他系统打通，比如当扩容失败时需要及时感知并自动执行其他任务进行兜底，避免业务受损，可以消费弹性伸缩提供的各种事件和通知渠道。目前弹性伸缩支持扩缩容成功、扩缩容失败等场景的事件，并支持MNS消息队列、云监控等订阅通道，方便用户快速完成接入和打通。
• 超高的弹性成功率
云上计算资源的获取是通过实例具体规格来指定的，比如阿里云的c5.large，c6.large，c7.large等多个实例规格均可以提供2核4GB的算力。如果客户的业务负载对算力没有特殊的要求，比如实例的网络吞吐上限等，在使用弹性伸缩时，可以选择多个可用区和多种符合要求的实例规格，当遇到临时突发流量时，弹性伸缩服务会自动在多个可用区下巡检所有符合要求的实例，尽可能交付所需算力，避免因单个资源库存不足导致业务降级或受损。
• 智能化弹性
对于周期性明显的负载波动，弹性伸缩服务提供了预测伸缩模式，即对业务负载波动历史进行分析建模自动预测业务负载未来2天的变化情况，无需用户配置即可实现在需要的时候自动扩缩容所需算力。目前弹性伸缩的预测伸缩模式仅适用于CPU、内存和网络带宽有明显周期性波动的业务负载。
智能化弹性能力示例
对于类似双11大促、新游戏开服等可能出现非预期流量洪峰的场景，常规弹性无法100%满足要求，为了确保某些业务在特殊阶段的100%可用，客户除了需要提前预估资源外，还需要额外的资源储备，以应对计划外的流量请求。在传统模式下，这些临时额外资源的储备面临2大难题：
• 采购周期长且数量难预估，预估不准可能因资源不足导致业务受损，也可能因资源过多导致成本浪费。
• 因临时突增需求的采购，使用周期较短，后期面临闲置问题。
阿里云提供的资源预定服务，可以同时满足使用时间不定使用时长不定的峰谷弹性需求，和资源使用了稳定且弹性规模较高的周期性弹性需求。
阿里云资源预定服务根据使用场景提供容量预定和弹性保障等不同类型
3. 可靠性能力Reliabilty
3.1 基本概念
可靠性指在一定的时间和条件下，系统无故障运行的能力或可能性，一般用MTBF（平均无故障时间）来衡量。
可靠性常作为非功能性需求在系统设计之初被边缘化甚至忽略，当我们再次提起可靠性时，殊不知已经遭受了重大损失。云上的可靠性建设有着天然的优势：
首先，可靠性需要在架构上具备高可用性，包括应用的多可用区、多地域部署，甚至异地多活；数据靠考虑多副本容灾能力，通过集群或分片方式提高数据的可用性。这些作为云上的基础资源或组件，已被天然支持，唾手可得。
其次，为了进一步可靠性，云还提供了丰富的可观性能力以及自助服务。基于此，用户可用构建多层次的可观测性能力，并基于此实现服务的故障自动发现、自动诊断、以及自愈能力，同时通过混沌工程提前发现生产环境潜在风险。
对比于传统的IDC，云计算的超大规模的数据中心，以及多可用区支持，让用户可基于云以低成本、高扩展、高可靠性快速的构建同城容灾、异地容灾等服务（包括数据）高可用方案。云计算通过虚拟化等技术对客户屏蔽了底层物理硬件，与此同时云厂商通过虚拟化、热迁移等技术，来减少甚至规避物理硬件故障导致的服务受损，进一步提升了用户服务的连续性以及高可用。
在可靠性上投入的成本，远比不做可靠性在产生环境代理的损失小得多。一般情况下，高可靠性、低成本和低复杂度是一个不可能三角，更多的时候我们倾向选择提高可靠性的前提下，在成本和复杂度上适度投入。
3.2 构建可靠性管理能力的业务价值
• 避免损失：根据Statista全球头部企业宕机损失统计，2020年40%的IT企业宕机损失100万美元/小时，比如2019年提升6%，17%的IT企业宕机损失超过500万/小时，构建良好的可靠性能力最直接的收益是尽量避免此类损失。
• 提供确定性：好的可靠性意味着质量匀称，可以提供更长期的确定服务，得到客户的信赖；用户可以在此基础上构建业务，更少去关心不确定的影响，专心做好业务。
• 为业务增值：可靠性在某些服务业务中近似质量，在其它条件相同情况下，好的质量有更高的价值；好的业务（服务）的稳定性是更具竞争力的表现。
3.3 多个层面构建可靠性
云作为基础设施，由于其规模效应积累了大量业务可靠性的经验，并通过产品化方式普惠到每个云上客户。在物理资源层，多地域提供了匀质的资源供给，方便客户根于业务、架构和成本选择最佳资源。
在SaaS层，提供企业级的免运维服务，业务可以按需方便集成到系统中，基本做到开箱即用。可靠性工程涉及部署方式、系统架构、应用拓扑和代码质量等多方面，除了在这些层面不断引入最佳实践进行探索，也需要工程化的方式对整体业务进行观测，并把混沌工程能力常态化引入到日常运行的业务中，做到提前、持续发现隐患，并常态化治理。
1) 构建多地容灾架构
对比于传统的运维，云厂商不仅提供了超大规模的数据中心，同时提供了全球多地域服务，每个地域是完全独立的数据中心，多个地域之间完全独立。而每个地域又有多个可用区，每个可用区之间电力和网络互相独立。云计算有天然的规模化和可靠性优势。
对于可靠性要求较高的应用，通常会做同城多机房部署，避免由于单机房的网络、电力等物理故障导致应用整体不可用。该场景下，在云上，用户可以使用同一个地域的多个可用区来部署，通过多个可用区的互通能力来完成应用间通讯，同时多可用区的物理隔离性极大提升了应用的容灾能力。针对多可用区部署的服务，云服务厂商不仅会在云资源的供给上提供物理隔离的多个可用区，同时也会开放OpenAPI能力来供用户查询并控制各个可用区可用购买的不同类型云资源，用户可用基于OpenAPI服务能力来构建自己的多可用区部署能力。
特大型的重要商业系统，对系统的容灾能力提出了更高的要求，同城多机房解决的是机房维度的单点问题，无法解决某个城市因为天灾人祸导致的城市级的故障。该场景下，在云上可以使用多地域部署，另外，多地域间物理距离适当远一些，避免单地域故障导致服务整体不可用，提升应用的极致高可用。对比于传统的IDC异地容灾方案，云天然的多地域支持会极大简化用户跨地域运营服务的成本。
对于高阶用户，云服务厂商会提供GSLB全球负载均衡以及对应的CDN服务来辅助支撑基础设施的高可用，也会提供自动化运维的Auto Scaling能力，用户可用通过配置Auto Scaling策略来实现自动化的多地域、多可用区自动化部署，保障服务基础设施始终处于高可靠性状态。
2) 数据备份和容灾恢复能力
云服务厂商在数据的高可靠性上具备天然的优势，不仅体现在存储的多副本，数据可靠性极高的SLA保障上，同时以服务化的方式向用户暴露了OpenAPI，用户可利用云厂商提供的快照、镜像等能力，实现数据备份容灾的高可靠性能力建设。
快照能力是云厂商提供的数据备份的核心产品能力，用户可使用快照进行系统盘、数据盘的备份，同时支持增量备份模式，帮助客户节约存储成本。快照支持手动备份与自动备份，推荐使用自动备份方式实现自动快照生成、轮转，对于特定业务场景，可以通过手动方式进行指定快照生成与保留时间，也可以设置为永久保留。当系统出现故障，需要将磁盘（系统盘或者数据盘）数据恢复到历史某一时刻，可以使用快照回滚能力，将指定磁盘回滚，通过快照数据的恢复能力，来提升数据的容灾能力。
同样，用户可用自定义镜像， 将快照的操作系统、数据环境信息完整的包含在镜像中。然后使用自定义镜像创建多台具有相同操作系统和数据环境信息的实例。对于多地容灾架构下，用户实现多地域部署时，可以使用镜像的跨地域复制能力来实现镜像备份的分发，从而实现多地域部署情况下的数据备份。
3) 应用可观测能力
为了帮助用户更快、更直观、更简单的发现系统内部问题，云服务厂商提供了完善的工具与服务化能力，用户基于此来构建不同层次的可观测能力，同时利用云厂商提供的自助服务来快速发现云资源、甚至自身业务服务的问题。
为了支持不同层次的用户需求，云厂商通常会提供以下几大类监控服务能力：云资源监控、应用层APM、业务层监控。
• 云资源监控：应用依赖的底层资源监控，比如资源的CPU、内存、网络等指标的使用率等。通过基础监控，用户可以自助发现云资源发生的异常，这是可观测性最基础的能力。云厂商同时会提供云资源的诊断能力，用户可通过一键发起对云资源的诊断，来自助发现云资源可能存在的问题。更进一步，云厂商会提供运维事件能力，用户基于云提供的EventBridge事件总线，通过自动化编排能力方式感知到云资源的异常事件，并完成自定义的自动化运维动作。
• 应用层APM：基于云资源部署的具体应用场景，包括应用指标性能（Metric）、系统调用链（Tracing）、日志监控（Logging）三个维度，比如应用的JVM指标、线程池监控、RPC服务的成功率、时延、错误率等。
• 业务层监控：应用层监控数据一般通过pull/push方式在数据聚合服务上进行计算，产出业务指标数据。指标数据异常检测也是云上提供的一项基础服务，用户可以选择传统的曲线异动、同比环比异常，甚至高阶的智能基线对比的自动检测能力对业务进行监控。
云资源监控只能发现云资源的问题，对于部署在云上的大规模服务来说，应用层问题的监控和定位能力是更加复杂和困难的。
云上需要有应用维度的监控和定位能力，在应用维度具备标准监控能力，比如服务端应用运行时、线程池、数据库、中间件、接口调用等，在前端应用，具备从页面打开速度（测速）、页面稳定性（JS Error）和外部服务调用成功率（API）等维度监控页面的健康度的能力。从生态角度，这些能力要提供诸如Prometheus、Kubernetes等开源产品形态。
除应用监控外，云上链路追踪Tracing Analysis为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。
云服务厂商会通过产品以服务化的方式来提供日志服务，用户使用日志服务做日志、数据的采集与集成，并基于此做Logging和Metering。用户通过自定义应用系统的内容、格式，并通过日志服务收集，并在日志服务中配置自定义细粒度监控大盘，观测自身业务运行情况，同时配置预警体系，建设用户层问题发现与定位能力。
4) 弹性容错能力
除了在基础设施多地域部署、数据上多副本备份容灾能力外，云服务厂商通常也会提供应用服务的容错能力，帮助用户构建具备弹性、容错能力的分布式系统。
• 弹性容错能力：分布式系统核心的两个弹性容错能力是流控与降级，通过流控来保护应用过载，通过降级来容忍业务部分有损换取整体可靠性。传统的流控方式是人工判断干预，高阶的方式是通过监控体系自动发现热点流量或者异常流量，自动化选择自适应过载保护或者设置自动降级策略并执行。
• 混沌工程与故障演练：混沌工程（Chaos Engineer）是一种提高分布式系统弹性能力的工程实践，通过主动制造故障，测试系统在各种压力下的行为，在生产环境提前识别潜在的故障，避免故障真实发生。
故障演练是遵循混沌工程实验原理的实践之一，其建立了一套标准的演练流程，包含准备阶段、执行阶段、检查阶段和恢复阶段。通过四阶段的流程，覆盖用户从计划到还原的完整演练过程，并通过可视化的方式清晰呈现给用户。结合观测能力和预警能力，通过混沌工程来完成故障巡检、故障注入、以及系统稳态度量。
5) 全面分析方法：FMEA
设计出可靠性高的系统是一个复杂的过程，由于异常场景很多，只要稍有遗落就会存在隐患，根据墨菲定律“可能出错的事情最终会出错”，因此推荐使用FMEA方法对系统做一个全面分析。
FMEA（Failure mode and effects analysis）即故障模式与影响分析，具体分布步骤：
• 给出初始的架构设计图。
• 假设架构中某个组件发生故障。
• 分析故障对系统功能造成的影响。
• 根据分析结果（ROI），判断架构是否需要进行优化。
3.4 可靠性衡量标准
如果您希望对所在企业可靠性能力成熟度进行评估，建议至第十章“CloudOps成熟度自评”。
3.5 工具推荐
1) 阿里云相关工具
从基础设施可靠性、数据可靠性到应用可观测性、APM、自助诊断、弹性容错能力等服务可靠性，阿里云都提供了完备的产品解决方案。用户可以利用这一系列能力，提升自身服务的可靠性。
• 全球化超级数据中心
阿里云基础设施目前已面向全球四大洲，开服运营25个公共云地域、80个可用区，此外还拥有4个金融云、政务云专属地域，并且致力于持续的新地域规划和建设。通过全球化的布局、超级规模的数据中心、持续的投入与深入布局来保障阿里云基础设施坚实、可靠。
从块存储技术角度，阿里云的块存储设备在具备高性能和低时延的优势下，同时提供了极高SLA保障了数据的可靠性，其中云盘采用分布式三副本机制，为ECS实例提供99.9999999%的数据可靠性保证。
从数据备份与容灾恢复角度，阿里云提供了快照2.0技术，提供了更高的快照额度、更灵活的自动任务策略，并进一步降低了对业务I/O的影响，同时增量快照能力可以以更快的快照制作速度和更小的空间占用，帮助用户提升效率并降低成本。
用户可以通过自定义快照策略实现快照自动化备份，以极低的成本完成数据备份，在故障场景，用户可以通过控制台或者OpenAPI来手动或着自动化完成快照回滚、数据恢复。同样的原理适用于自定义镜像，用户可以通过镜像的制作、复制、恢复来完成数据备份、中转、恢复。
阿里云的基础云产品服务比如ECS、RDS、虚拟网络均提供了云资源侧的自助诊断能力，以ECS和DAS诊断为例简单介绍。
｡ ECS自助问题排查：ECS自助问题排查提供的实例健康诊断、操作异常诊断、安全组规则检测、以及网络连通性诊断，可以全方位帮助用户诊断实例的操作系统配置、磁盘状态、网络配置、网络状态等配置异常，同时给予修复建议方案，帮助用户及时处理潜在风险。
｡ 数据库自治服务DAS（Database Autonomy Service）是一种基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务，帮助您消除人工操作引发的服务故障，有效保障数据库服务的稳定、安全及高效。
云监控服务可用于收集获取阿里云资源的监控指标或用户自定义的监控指标，探测服务可用性以及针对指标设置警报。使您全面了解阿里云上的资源使用情况、业务的运行状况和健康度，并及时收到异常报警做出反应，保证应用程序顺畅运行。
• 基础监控：云上云下统一的主机监控解决方案及百余款云产品监控。
• 网络监控：基于私网和公网的网络可用性监控。
• 业务监控：过日志监控、自定义监控把业务数据归集到云上进行统一监控和管理。
日志服务（SLS）是云原生观测分析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。作为云原生观测分析平台。
｡ 数据采集：支持Log/Metric/Trace统一采集，支持服务器/应用/移动设备/网页/IoT等数据源接入，支持阿里云产品/开源系统/云间/云下日志数据接入。
｡ 数据加工：通过灵活语法，在不编写代码情况下支持各种复杂数据提取、解析、富化、分发等需求，支持结构化分析。
｡ 查询分析：提供关键词、SQL92、AIOps函数等多种方式，支持面向文本+结构化数据实时查询分析，异常巡检与智能分析。
｡ 监控告警：具备丰富的可视化组件，可创建所见即所得的交互式分析大盘。同时支持实时可编排的告警功能，可随时随地掌握业务动向。
｡ 日志审计：账户下实时自动化、中心化采集云产品日志并进行审计，支持升级所需合规存储、查询及信息汇总报表。
｡ 投递与消费：与各种实时计算及服务实时对接，并可以实现自定义消费。支持数据投递至存储类服务，支持压缩、自定义Partition以及行列等各种存储格式。
｡ Prometheus监控，云原生时代一站式体验。应用实时监控服务ARMS提供Prometheus全托管式云服务，无需安装运维，一键开启，开箱即用监控大盘。
｡ 分布式调用链查询诊断：同时支持微服务程序HTTP、Dubbo、HSF等接口进行追踪与PaaS调用，如对数据库、NoSQL、MQ等调用进行追踪。
｡ 应用性能实时汇总：可以通过跟踪整个应用程序的用户请求，来实时汇总，组成应用程序的单个服务和资源。
｡ 分布式拓扑动态发现：可以收集您的所有分布式微服务应用和相关PaaS产品的分布式调用信息。
｡ 流量监控与防护：提供包括QPS、并发线程、响应时间（RT）、异常、CPU/load、网络流量等指标的秒级监控能力。同时，提供应用级别的流量控制、应用间的降级隔离、单机自适应过载保护、热点流量探测与防控、脉冲流量削峰填谷、慢方法/SQL的自动熔断、分布式流量控制等。
｡ 网关防护：支持Nginx/Ingress网关层流量控制以及Spring Cloud Gateway、Zuul等常用API gateway的流量防护，从流量入口处拦截骤增流量，防止下游服务被压垮。
｡ 开关预案：支持代码中配置项的动态管理，根据需求为某个应用开启或关闭部分功能，或设置某个性能指标的阈值。通常用于设置黑白名单、运行时动态调整日志级别、降级业务功能等场景。
｡ 混沌工程与故障演练：提供一站式架构分析、故障巡检、故障注入、系统稳态度量等功能，帮助用户增强分布式系统的容错性和可恢复性，帮助系统平稳上云。
｡ 多活容灾：支持分布在多个站点的系统同时对外提供服务，保障故障场景下的业务快速恢复。横向囊括容灾架构的上线、运维、演练、切流、升级到下线的全生命周期。纵向包含业务流量的完整路径，从流量接入，到服务化调用，异步化消息，再到最终数据落库
2) 阿里云与业界相关工具对比/对照表格
