云上自动化运维CloudOps系列沙龙演讲合集.pdf

封面页（待分享）卷首语 实现和保障系统的高可靠性和高稳定性，是上云后大家最关注的两项重要指标。如何通过云上的自动化 CloudOps 产品体系持续地提高可靠性和稳定性，是研发和运维需要共同努力的重要方向；持续提升可观测性则是达成目标的最直接和最有力的手段之一。因此，阿里云弹性计算 CloudOps 系列沙龙，将以“可观测性与可靠性”作为第一弹的主题，分享相关思考与实践。自动化即是通过运用工具或系统达到减少、甚至是完全取代人工的操作。在研发效能与运维工作中，自动化是降低成本、提升效率必不可少的方式，自动化还能减少人工带来的错误，提升团队满意度。因此，阿里云弹性计算云上自动化运维CloudOps 系列沙龙，将以“自动化与智能化”作为第二弹的主题，分享相关思考与实践。资源效能与研发效能是企业运营过程中必须关注的话题，高效能甚至能成为一家企业的核心竞争力。充分利用云的弹性和自服务工具，企业将能大幅度地优化成本、提升资源与研发效能。因此，阿里云弹性计算云上自动化运维 CloudOps 系列沙龙，将以“效能提升与成本优化”作为第三弹的主题，分享相关思考与实践。目录 可观测 才可靠.7 一、弹性计算云上可观测性能力构建.7 1.why Observe.8 2.Observability on Cloud.10 3.Beyond Observability.14 4.Future.17 5.Q&A.18 二、云上可观测能力：问题的发现与定位实践.20 1.云服务器可观测能力价值.20 2.使用自服务工具定位和分析典型问题.22 3.集成诊断实现自动化运维.28 4.展望.29 5.Q&A.29 三、可靠性保障必备：云上如何进行混沌工程.31 1.混沌工程方法.31 2.弹性计算混沌工程实践.36 3.系统评价和混沌工程工具.41 4.Q&A.42 四、云上跨可用区容灾和异地多活最佳实践.44 1.系统容灾.44 2.主流容灾架构.46 3.弹性计算在容灾上的实践.49 4.云上容灾建设.52 5.Q&A.54 自动化 才高效.56 五、应用管理：云上资源 DevOps 最佳实践.56 1.云上资源管理和运维的工具.56 2.应用分组维度资源的管理.57 3.应用分组维度资源的运维和监控.60 4.Q&A.62 六、基于事件的自动化运维最佳实践.64 1.为何事件如此重要.64 2.让事件通知更有效.67 3.事件驱动的运维架构.70 4.云上托管事件运维.72 5.Q&A.73 七、如何实现应用的持续发布.75 1.持续发布总结.75 2.持续发布建设路径.77 3.云上持续发布实践.78 4.应用持续发布.80 5.Q&A.81 高效能 才经济.82 八、如何快速搭建低成本高弹性的云上应用.82 1.云上应用资源选择.83 2.云上应用搭建考虑因素.83 3.弹性-稳定性低成本云解决方案.86 4.应用资源管理最佳实践.91 5.Q&A.94 九、如何实现资源高效运维与云上成本分析.95 1.企业资源管理面临问题.95 2.高效实现资源运维路径.96 3.高效运维及成本分析实践.97 4.场景标签设计实践.99 5.Q&A.103 十、云上成本优化实践.104 1.云上成本控制的必要性.105 2.付费方式与资源规格选型.107 3.提升资源利用率.114 4.成本管理.116 5.Q&A.119 弹性计算云上可观测性能力构建 7?一、弹性计算云上可观测性能力构建 作者：杨泽强，阿里云弹性计算 SRE 技术专家 2022 年 7 月 4 日，【可观测，才可靠云上自动化运维 CloudOps 系列沙龙_第一弹】正式推出，实现和保障系统的高可靠性和高稳定性，是上云后大家最关注的两项重要指标。如何通过云上的自动化 CloudOps 产品体系持续地提高可靠性和稳定性，是研发和运维需要共同努力的重要方向；持续提升可观测性则是达成目标的最直接和最有力的手段之一。阿里云弹性计算 CloudOps 系列沙龙也将“可观测性与可靠性”作为第一弹的主题。本次沙龙直播覆盖四天，首位分享的嘉宾是阿里云弹性计算 SRE 技术专家-杨泽强，他带来的主题分享是 弹性计算云上可观测性能力构建，以下是他的演讲内容整理，供阅览。弹性计算云上可观测性能力构建 8 1.why Observe 可观测最早起源于农业时代气象观测，后来的电气时代、自动化时代都存在可观测性产品。控制理论中的可观察性指系统可以由其外部输出推断其内部状态的程度，系统的可观察性和可控制性是数学上的对偶概念。以汽车为例，在驾驶过程我们无法直接感知到汽车系统的内部状态，而通过仪表盘可以获知当前发动机的转速、速度、油量以及其他系统的运行状态。软件工程里，通过采集 logs、metrics 和 traces 三个维度来理解系统内部状态，即为可观测性。弹性计算云上可观测性能力构建 9 可观测性对于软件全生命周期有着极大价值。可以通过可观测性查看当前系统负载、异常链路、异常情况以及报警等；可以基于可观测性做预警，再基于预警进行分析，从而尽可能降低故障感知时间和定位时间，最终缩短故障 MTTR。可观测性是软件系统稳定性保障的基础。而从软件工程整个视角看，可观测性能够提供的远不止稳定性保障。软件工程最早期的需求分析阶段，可以通过可观测性进行容量预算评估；CI 阶段可以进行研发质量控制，比如构建成功、测试覆盖率等；交付过程中，可以通过可观测性对交付质量进行保障；同时成本和安全也能通过可观测性得到有效控制。从软件的整个生命周期来看，如何构建自己理想的可观测性模型并没有标准答案。但是从单体应用或分布式用到微服务等典型的软件架构来看，可以抽象出一个标准模型，如上图，由下至上分为 5 层：资源层：包括主机、存储、网络、Runtime 等。平台层：包括 RPC、DB、消息、缓存、调度等。应用层：包括可用率、时延、错误数、流量、饱和度、日志等。产品层：包括订单量、订单成功率、生产成功率、生产耗时等。客户层：包括业务延续性、SLA、拨测等。客户层是最容易被忽视但极具价值的一层。我们需要更多关注到客户业务的连续性、从用户视角如何使用可观测能力等。弹性计算云上可观测性能力构建 10 当前，可观测性技术体系的生态和产品已经十分丰富。Logging 侧有 Logstash、iLogtail、SLS 等，Metrics 侧有 Prometheus、Grafana、Kibana 等，Tracing 侧有Elastic、Opentemeletry、Skywalking 等。构建可观测性过程中如何选型没有标准答案，需要根据自己的实际需求来选择。2.Observability on Cloud 2011 年，弹性计算可观测性上云的最初阶段，可观测性体系缺失，主要为单体应用模式，只有几个监控预警。弹性计算云上可观测性能力构建 11 2016 年，预警接入阿里自研监控平台，主要实现方式是传统的监控系统以及基于时序数据库的 metrics 采集和展示系统。2019 年，阿里开始逐步将 ECS 核心应用搬到云上，基于云构建体系，包括云监控和 SLS。2021 年，阿里开始了云原生改造，目前已经完成 90%左右的改造。另外，我们也整在云原生的基础上将技术体系改为开源的标准技术体系。云上的弹性、可靠性以及天然具有多地域隔离等特性，为监控平台提供了极大的优势。另外，云原生的技术一直紧跟业界最新开源标准，其方案足够通用、足够先进，这也是自研平台研发节奏无法相比的。基础设施的监控主要通过云监控和 ARMS 两个产品来承载。ARMS 是一个 APM 工具，负责采集机器的 node 指标。平台层包含诸多中间件、数据库等。此前，往往需要对接很多不同系统，而在云上，ARMS 提供的原生技术 eBPF 可以无缝采集全部指标，比如黄金三指标、数据库、MySQL 等，最终生成标准的 metrics 数据。应用层的黄金三指标、可用率、时延、错误率、调用次数等，可以通过 ARMS 和 SLS相互补充来构建。业务层 ECS 实例的生产成功率、耗时等数据，是基于 ARMS、SLS 的 trace 能力和metrics 能力来构建。弹性计算云上可观测性能力构建 12 客户层主要基于 ARMS 和 SLS 构建。我们需要从认知上进行转变，可观测性除了可以提供给 PM 使用，还可以提供给运营人员、财务人员以及管理者使用，它对于不同角色的意义和价值也不一样，这也是可观测性的价值所在。上图为 ECS 整体的升级方案 老平台的 Monitor 和 Sunfire 迁移到云原生，主要为将基础监控迁到 CMS 云监控，将业务监控、应用监控迁到 ARMS，trace 能力也会从最原始的日志编排服务迁到ARMS trace 和基于 SLS 的日志库编排能力里。除了云原生的开源技术标准，我们还基于基础能力自研了自动化运维体系，比如告警、故障诊断和快速恢复等。底层能力使用 SLS 和 ARMS 对外的 Open API 来构建。可观测性比较好的观测视角是应用视角。另外，我们也基于一些业务的特殊性，从业务维度构建可观测性，比如 ECS 有集群，则基于 cluster 维度来构建可观测性。构建完所有的可观测性后，我们还构建了统一的预警平台和自动化运维能力。弹性计算云上可观测性能力构建 13 左侧最初的 Monitor 和 Sunfire 基于 log 构建，右边最新的可观测性系统是基于Prometheus 和 Grafana 标准的开源方式构建。实现了从自定义多样性到云原生，从繁芜复杂到标准简化的转变。以监控预警为例，上图左侧为上云之前的监控预警体系，由阿里集团监控、Sunfire监控平台和 SLS 告警构成。上云后的监控预警体系如右侧所示。基于Metrics数据可以产生标准化的数据计算，比如计算影响面。运维操作里的数据也可以通过动态计算得出，可以查看原始堆栈、弹性计算云上可观测性能力构建 14 现场的关键指标、变更等。另外，我们还基于原生 API 构建了 owner 精准推送、预警标准化操作等能力。3.Beyond Observability 从软件生命周期视角看，CI 过程中会有每日构建和测试以及实时管理大盘；自动化发布会基于 Prometheus metrics 数据格式做自动化卡点；运行期提供了自动化运维和 Chat Ops；当前，我们正在进行基于可观测性来建设安全度量和成本控制。以效能和质量为例，DevOps 环中较为核心的两个环节是持续集成和持续交付，这也是直接影响软件工程质量的两个因素。弹性计算云上可观测性能力构建 15 在持续集成方面，有 CI Dashboard，每次输入代码都会触发 CI，计算出代码行覆盖率、分支覆盖率、全复杂度以及成功或失败等状态，如上图右侧所示。在持续交付方面，自动化发布的难点在于如何授信，因此我们实现了金丝雀发布。此外，我们认为发布过程中也需要可观测性，因此，我们将发布阶段的一些核心指标通过 metrics Dashboard 进行展示。同时会配合应用维度的 metrics 提供原子能力以及发布系统的卡点，以实现发布自动化。上述功能的本质为将可观测性左移，从软件工程运行期的可观测性移到代码发布和交付阶段，以保障交付代码质量。可观测性的大部分应用场景是运维场景，比如查看容量、水位、预警等指标。上图为上云之后可观测性在运维方面的应用。弹性计算云上可观测性能力构建 16 此外，可观测性还可运用于混沌工程，它是混沌工程的核心依赖。混沌工程的核心是故障演练机制，对服务注入故障，以查看是否出现异常。注入故障的前提为系统为稳态，这需要依赖于可观测性体系查看 metrics 指标来确保。其次，探索可能导致不稳定的因素时，需要通过可观测性来对比差异点，通过查看内部哪些系统、哪些环节有问题，发现内部真正隐患，实现提前的故障隐患挖掘。成本管理和安全可观测是我们正在探索的两个场景 如何降低成本是管理者关注的重点之一。首先需要明确当前成本，上云之后可能会有混合云场景或多云场景，需要从多个地方查看财务及数据。可以通过可观测性获取系统水位、资源消耗等情况，以进行下 弹性计算云上可观测性能力构建 17 一步的成本优化。比如使用 SLS 会有很多日志存储，可以通过可观测性查看 SLS 使用率、哪些索引消耗资源等。安全可观测性要求将安全前置，通过可观测性提前发现安全隐患，比如是否存在异常流量和异常攻击等，通过逐步迭代完善安全体系。4.Future 未来，可观测性的发展趋势为标准化与多样化。可观测性将从多样化产品逐步转化为标准化的开源标准模型。Loging、metris、tracing 三个方面开源以及商业化的产品已经非常丰富。然而，可选择空间越大，做出决策或最佳实践的难度也更大。因此我们认为未来需要尽快建立可观测性的标准体系，比如 tracing 的 OpenTelemetry，metrics 的 Prometheus，多数据源展示的Grafana。阿里云也提出了OPLG模型，其中O为OpenTelemetry，P为Prometheus，L 为 Loki，G 为 Grafana。多样化指可观测性的应用领域将呈多样性发展。从最初只观测单体应用，到后来的监控 APM 并逐渐衍生出各种各样的监控场景，实现万物可监控、可观测。弹性计算云上可观测性能力构建 18 5.Q&A Q：可观测性具体应用于软件开发的哪个阶段？A：传统的可观测性一般应用在运维阶段，关注线上的系统水位、监控运行等。而现在可观测性有左移趋势，在软件的架构设计、CI、CD 阶段都有应用，比如提供了 CI大盘，交付和发布过程中有 metrics 指标的获取和自动化拦截。Q：如何获取可观测性不同维度的数据？A：资源和平台层，开源的eBPF天然具备采集数据的能力，能够采集MySQL、Redis、Kafka 流量、node 数据等。产品侧的数据需要通过一定的开发工作来采集。Q：阿里云的可观测体系建设使用了哪些商用产品？A：有 SLS 和 ARMS 两个产品。SLS既有logging功能，也有trace功能，另外它也可以构建metrics和dashboard，提供了完整的闭环。ARMS 目前没有 logging，只有 metrics 和 tracing，但它的优势为费用低于 SLS。另外 ARMS 提供了完整的 APM 工具链，不仅是 metric 这种数据，还有 insight 数据，比如可以看 JVM 的指标并进行分析，还提供了 Arthas 的 profile 能力以及智能识别系统异常的能力。Q：Prometheus、Grafana 链路与 ARMS 之间存在何种关系？A：没有直接关系。ARMS 提供了托管 Prometheus 的服务，与 Grafana 实验室有商业合作，Grafana 的部分能力会直接托管在阿里云 ARMS 上。ARMS 基于这两个托管能力，结合其本身的链路追踪服务，可以很好地将三者进行结合，产生 1+12的效果。Q：实现端到端监测需要统一哪些指标体系？A：首先，链路的核心指标不能丢，包括资源、平台、应用等。其次，trace 指标也是必要的，将端到端的链路串联起来是技术难点，可以通过OpenTelemetry、Skywalking 等产品来实现。此外，黄金三指标、web 服务基于用户侧的拨测能力以及用户视角的可观测性路径也是必要的。弹性计算云上可观测性能力构建 19 以购物下单为例，用户视角的完整链路应该为从 C 端发起请求到下单完成支付整个链路相关的网关监控、支付监控、订单监控等串联而成，并且这些指标能够进行统一展示。今天的分享和互动就到这里，谢谢大家。云上可观测能力：问题的发现与定位实践 20 二、云上可观测能力：问题的发现与定位实践 作者：郝晨栋，阿里云弹性计算技术专家 2022 年 7 月 4 日，【可观测，才可靠云上自动化运维 CloudOps 系列沙龙_第一弹】正式推出，第二位分享的讲师是阿里云弹性计算技术专家-郝晨栋，他带来的分享主题是云上可观测能力：问题的发现与定位实践，以下是他的演讲内容整理，供阅览。1.云服务器可观测能力价值 云上可观测能力：问题的发现与定位实践 21 云服务器可观测性指客户能够感知到服务器内部运行情况的能力，从而保证云上资源的可靠性。与传统 IT 运维相比，上云 IT 的使用方式和运维方式发生了一些变化。比如，传统 IT运维场景下，客户会自购机房、自购机器，操作的是硬件资源；而上云后，客户通过 OpenAPI 操作各种计算资源。同时，传统场景下，业务规模受限于机房或物理机；而得益于云上的弹性能力，客户能够轻松将业务规模扩大到上百台或上千台服务器。上云后的运维也增加了诸多挑战和难度，需要云服务器的可观测性来解决。云服务器可观测的价值主要有以下三点：提升问题定位效率。通过自助服务快速定位问题，能够做到有据可依。简化运维。方便在掌握云服务器的运行细节。提升资源可靠性。及时掌握云服务器客户 OS 内部以及底层状态，避免黑盒。阿里云针对提升云服务器的可观测能力提供了很多主流工具集，包含健康诊断、系统事件、云监控、ARMS 和操作审计。这些工具虽然定位和角度不一样，但其目的都是一致的，即为了让客户清晰感知到当前实例的健康状态，帮助快速发现问题，降低运维成本。云上可观测能力：问题的发现与定位实践 22 2.使用自服务工具定位和分析典型问题 自服务工具 On-demand self-service 指用户能够自助获取计算资源或服务，而不必与服务供应商打交道。客户在云上经常面临的典型问题有比如实例无法启动、实例无法连接、操作不生效等。传统场景下，客户只能提交工单寻求售后支持，问题解决速度取决于客服对问题的理解程度或回复效率。而在自服务场景下，我们将典型的客户问题全部收纳到健康诊断工具集里，客户可以在控制台上自助发起诊断，进行问题解决，只需分钟级即可定位问题。云上可观测能力：问题的发现与定位实践 23 实例无法启动一般有两方面原因：其一，操作系统内问题，比如客户操作系统中病毒，一些关键文件被破坏或删除，客户的误操作导致操作系统一些核心系统服务没有开机启动，Fstab 文件配置错误，也可能是镜像与规格冲突导致。针对操作系统内问题，目前健康指南工具可以快速定位问题，并将对应修复方案推送给客户。其二，云平台底层问题，此类问题较为少见，主要有库存不足、宿主机告警、控制系统异常、虚拟化异常以及磁盘扩缩容衣长等。针对此类问题，诊断工具会向客户推送人工服务直达入口。同时，针对一些较为严重的错误，会向客户推送问题上报入口，如果运维团队确认客户上报的问题非常严重，会主动触发运维动作，且步骤对客户完全透明。实例无法启动的情况下，阿里云诊断工具如何实现对实例操作系统内部的探测？以个人电脑操作系统为例，比如个人电脑坏了以后，通常会使用 U 盘作为修复盘，启动时进行调整，启动 U 盘再进行重装系统或修复，最后将修复盘卸载，电脑即可正常启动。诊断工具的工作原理类似，如上图左下方所示。如果客户操作系统无法正常启动，诊断工具会为客户挂载一块修复盘，并且会生成用于登录修复盘的临时密码等。修复盘挂载好以后，自动为客户启动实例，原先的系统盘会作为数据盘挂在现在的实 云上可观测能力：问题的发现与定位实践 24 例下，然后进行实时探测。如果发现问题，会给客户推荐具体的修复方案，客户可以根据修复方案解决问题。原先系统盘内的问题解决以后，将修复盘卸载，即可正常启动，整个流程对客户完全透明。实例无法远程连接主要原因为 ECS 两个服务器之间无法连通以及 ECS 实例与公网IP 无法连通。诊断工具支持三种类型输入，可以选择 ECS 实例、网卡或公网 IP。诊断工具会列出发起端和目的端之间的关键路径，比如实例账户本身状态、实例操作系统、当前实例所在交换机等关键路径，依次探测每个关键路径是否连通，最终得出结论。关键路径可以分为两大类，实例配置类和操作系统内配置，其中实例配置类包括实例欠费、Vswitch 未放行流量、实例被锁定等；操作系统类主要借助云助手实时下发开源诊断命令，如果发现操作系统内存在问题，则会在修复方案里告知用户。网络连通性诊断报告里会显示无法连通的关键路径及其原因。云上可观测能力：问题的发现与定位实践 25 实例变更操作不生效指客户在控制台上做了一些变更，但结果与预期不符。这一类的问题难度较大，变更动作非常多，没有生效的原因也非常多。目前自服务诊断工具已经支持的诊断能力有云盘扩容未生效、重置密码不生效、实例变配不生效以及实例续费失效。比如客户云盘超过容量，在控制台上做了扩容，从 40G 扩容到 100G。控制台上已经显示为 100G，但依然需要客户进入 OS 里做一些扩容命令才能真正生效，否则会导致业务受损。诊断工具有专门针对云盘扩容的专项诊断，如果发现客户实际生效磁盘与扩容大小不一致，会给用户推送扩容建议，避免客户业务受到损害。还有一类实例变更操作不生效是由于客户对产品规则不熟悉导致，诊断工具会给客户推送现在的产品规则。云上可观测能力：问题的发现与定位实践 26 上述典型问题都需要依靠客户在控制台上主动发起诊断，属于被动服务。而自服务能力背后的主动探测工具是对账系统。如果客户在云上使用的服务与实际运行的不一致，则会影响业务。因此，可以通过对账工具来保证客户在控制台上看到的与实际运行值一致。比如会比对控制台上客户看到的 IP 与实际 IP 是否一致等。通过客户主动发起诊断，再加上自服务工具背后的主动服务，来确保客户可观测到的数据与实际运行一致。上图为自服务诊断工具的诊断能力总览和用户场景 诊断能力主要分为两大类，分别是问题排查和规则类：问题排查类又细分为操作系统和云平台类，目前已有大约 80 多种诊断能力。产品规则类目前已经提供了 30 多种能力。云上可观测能力：问题的发现与定位实践 27 阿里云平台诊断分析依赖于阿里云底层的数据采集。阿里云在全球有接近 30 多个地域、上百个可用区，每时每刻都有实时数据被采集上来，比如物理机、IDC 有机房、操作性能、串口日志等。这些基础日志是健康诊断工具的输入，有了这些底层数据，诊断才能做数据清洗、聚合计算、抽取与异常相关的特征，最后产出诊断根因。另一部分诊断能力与操作系统内客户的关系较为密切，通过在实例内安装云助手服务实现。客户发起诊断时，通过云助手在客户实例上执行开源脚本，进行实时数据收集，包括负载类和配置类，比如实时探测当前客户 OS 内的 CPU、内存、iOS 等负载类，或 DHCP、IP 等配置类。阿里云平台诊断和操作系统内诊断两大能力共同组成了健康诊断服务。目前健康诊断服务已经输出到控制台上供云客户使用，也输出到内部给云产品使用，近期也将推出 OpenAPI。云上可观测能力：问题的发现与定位实践 28 3.集成诊断实现自动化运维 对于没有自己运维平台的中小型客户，我们推荐直接在控制台上使用诊断产品，既方便又快捷，诊断产品还提供了诸多详细方案供客户参考。对于有自己运维系统的中大型用户，建议通过 API 的形式集成到自己的运维系统中，高效便捷。比如可以将监控系统与诊断做整合，监控系统发现实例负载不正常时，会直接调用诊断 API 并根据诊断结果做处理；可以将诊断服务集成到巡检系统里，每天对一些集群的核心实例做实时诊断，如果有异常则及时更换或扩容；可以将诊断服务集成到后台运维系统里，供值班人员使用，比如 RDS 实例发起诊断时，也可以同时对 ECS 层面发起诊断。云上可观测能力：问题的发现与定位实践 29 此外，诊断产品还结合了运维编排能力，开放了很多运维编排的公共模板，可以快速实现定时运维、事件驱动型运维，也提供了批量操作的能力，比如批量发起诊断或跨地域发起诊断等，以上能力都可以在 OS 控制台上直接使用公共脚本来实现。同时，还支持 ECS 产品根据诊断按结果来触发操作，比如诊断结果为当前实例负载过高，可以触发创建新实例或升配；如果诊断结果为云盘容量已经占满，可触发扩容命令等。4.展望 自服务诊断工具期望成为 ECS 产品问题定位和排查的总入口。近期我们会发布健康诊断的 Open API，目前也正在密集开发更多的诊断能力。此外，在阿里云官方社区里也有建立了技术圈，供业内同仁在专业上的交流分享。5.Q&A Q：自动诊断后为什么不执行自动修复？A：我们曾做过一些自动修复的尝试，但效果并不好。首先，部分修复动作存在风险；其次，修复动作可能需要用户授权。云上可观测能力：问题的发现与定位实践 30 因此，最终我们决定只将修复方案方提供给客户。Q：问题发现和定位的精准度如何？A：诊断工具无法做到全面覆盖，目前主要以保证发生频率较高的问题为主。问题来源有三个渠道：第一类为客户工单，从发生频率较高的问题里评估哪些可以集成到诊断工具里；第二类是定期拜访一些 GC3 以上的客户；第三类是平时团队内部的管控值班周报。今天的分享和互动就到这里，谢谢大家。可靠性保障必备：云上如何进行混沌工程 31 三、可靠性保障必备：云上如何进行混沌工程 作者：秦隆，阿里云弹性计算技术专家 2022 年 7 月 4 日，【可观测，才可靠云上自动化运维 CloudOps 系列沙龙_第一弹】正式推出，第三位分享的讲师是阿里云弹性计算技术专家-秦隆，他带来的分享主题是 可靠性必备保障：云上如何进行混沌工程，以下是他的演讲内容整理，供阅览。1.混沌工程方法 可靠性保障必备：云上如何进行混沌工程 32 传统的系统运维方式下，我们通常只关注系统主干流程、业务流程，而忽略旁路系统或底层架构。系统发生报警时很大可能性是由我们不关注的部分引起，从而导致运维人员无法很好地应对。发生较大规模故障时，可能需要拉齐各个业务域人员共同进行故障处理，但人员来自不同业务，负责和擅长方向也不同，无法很好地协同工作以及高效地处理故障。业务系统的治理运维级别可根据不同业务系统层级分为四层：业务系统：业务开发人员最擅长或最常涉及的系统，比如开发代码。关联业务：指同公司或同部门开发的一些二方依赖。中间件及基础组件：一般开发人员不再关心此层。基础设施层：运维人员对其较为熟悉，开发人员几乎不参与此层的运维。各个技术分层会面临不同的问题。业务系统最常见的问题为代码 bug、突发流量以及发布中间态问题。关联业务层面对的问题是业务在遇到问题时会出现何种表现，比如关联业务宕机时，可能会出现关联业务依赖报错或 RT 突增；如果关联业务中出现代码 bug，则为逻辑错误。可靠性保障必备：云上如何进行混沌工程 33 中间件和基础组件遇到的问题大多为中间件不可用、慢 SQL、RDS 故障或消息延迟等。物理基础设施层遇到问题大多为系统宕机或网络方面，包括网络不通、网络丢包、延时增加甚至整个机房不可用等问题。为了解决以上不同技术层级所遇到的未知问题，我们引入了混沌工程，从四个方面进行验证：容量：明确了系统容量，才能明确系统能够承受多少用户或多少调用。系统复杂度：随着系统老化，系统会包含越来越多隐患。业务和技术的更新迭代也会导致技术欠债越来越多，链路越来越长，排查手段更欠缺。可用性：世界上没有 100%可用的系统，任何系统都有可能出错。可用性即系统出错时会有什么样的表现。人和流程以及人员协作效率问题：是系统故障处理中最不稳定的因素。混沌工程所有演练场景都来源于故障。总结出故障后，先在验证环境试水。随后，成熟的 case 可以转为线上环境演练。演练完成之后，进行复盘，总结系统需要解决的问题，这是混沌工程最终要达到的目标，即从演练中得到可以优化的点并进行优化。最后将所有稳定的 case 聚集起来，总结成混沌工程自动化 case 集。集合会稳定运行在线上系统，做线上系统性能和复杂度的回归，防止某些改动对系统稳定性或可用性造成影响。可靠性保障必备：云上如何进行混沌工程 34 混沌工程的实践分为经典四步：第一步：定义和测量系统的稳态。要明确系统在什么样的条件下可以支撑什么样的请求，或系统在稳定运行时是什么样的表现。比如，系统在 1000QPS 时可以稳定提供服务。第二步：创建假设。在系统稳定状态中找到有可能对系统稳定性造成影响的变量。比如，假设缓存不能正常服务，系统仍然可以在 1000QPS 时提供服务。第三步：将假设模拟成现实世界中可能发生的事件。比如针对缓存无法正常服务，在现实中生活中可能发生事件有：缓存服务器网络 down 或缓存系统强行淘汰。第四步：证明或反驳假设。比如缓存无法正常服务后，造成系统不稳定，最大 QPS是否还能达到 1000。若结果为系统 QPS 依然可以达到 1000，则说明系统稳定性至少在模型 case 里可以通过；若结果为 QPS 无法达到 1000，比如在 QPS 为 200 时系统已经不稳定，则可由此找到系统瓶颈点，进行治理。可靠性保障必备：云上如何进行混沌工程 35 混沌工程的实践有 5 个原则：建立一个围绕稳定状态行为的假说：混沌工程要关注系统在发生不稳定事件时能否正常工作，而不是试图验证系统如何工作。多样化真实世界的事件：首先，要对真实可能发生的事件进行实验，无需关心不可能发生的事件。其次，要尽可能多地枚举出系统中可能发生问题的点，发生概率高或已经发生过的事件优先级靠前。在生产环境中运行实验：弹性计算的初期也无法在生产环境中运行实验，原因为系统稳定性不高，且可观测性不佳，在线上注入故障时无法很好地观测影响范围。比如在代码隔离但数据不隔离的环境中实验时，完全无法测出系统真实的瓶颈点，因为任何微小的改变、任何与线上不同的点都会影响最终结果的准确性。所以我们提倡在生产环境中运行实验，能最大化验证发生问题时系统的表现。持续自动化运行实验：将性能作为回归的一部分，不仅需要功能的回归，还需要自动化的性能回归。最小化爆炸半径：当有足够强大的可观测性之后，要控制演练可能对系统造成的影响。演练的目的应该是验证系统薄弱点，而不是将系统彻底击溃。因此要控制演练范围，将影响降到最小，尽量不对线上用户造成过大影响。可靠性保障必备：云上如何进行混沌工程 36 2.弹性计算混沌工程实践 进行压测时我们为每个用户的每个 API 都设置了调用 QPS 上限，即流控。压测场景下所有用户的叠加较为稳定，但系统里依然有不稳定的点。第一，虽然对用户有流控，但流控未经验证，只有用户在阈值内调用才能保证功能可以完成，对系统没有太大压力。第二，单个接口或整个应用总容量未知；而单用户调用能保证系统稳定。由于单一调用来源不同的用户调用峰值叠加，会导致系统后端压力过大，导致波峰系统出现问题。上述流程总结起来可分为四步：建立较为稳定的系统。埋下问题系统容量未知。用户将现实环境中可能发生的问题触发，即同一平台不同用户的突发调用。结论为系统无法承受压力，最终导致故障。上述流程中存在四个需要解决的问题：系统容量未知导致严重后果、流量峰值下系统的表现未知、产生流量洪峰的原因未知、系统崩溃后的处理流程未知。而为了探索系统稳定性，需要将未知转变为已知。可靠性保障必备：云上如何进行混沌工程 37 因此我们引入了压测，主要分为三个步骤：第一步：基线。定义系统瓶颈以及压测停止条件。第二步：实际压测。压测一般以 API 为入口，可能是外部 API、内部以及内部调用，分为三种压测方式：简单暴力压测：主要针对一些非常简单的 API，单独的 API 调用即可对系统施加压力，并发调用接口，达到压测目。逻辑流程类压测：调用之前会经过一些资源准备，不能单独调用接口，也称为带上下文语义的接口，接口有状态。将接口和创建实例或查询实例进行编排，对每个实例编排出串行流，对串行流进行并行压测，最后组成逻辑流程类压测case。线上回放压测：用于针对更复杂的 case 或内部调用 case。第三步：自动化压测。将稳定 case 和对系统危害不大 case 统一成自动化 case 集，根据基线设置自动告警。当自动化压测回归发现某一接口不符合之前预测的基线时，会自动告警，做到系统性能回归，最终解决前文提到的四个问题：针对系统容量未知导致严重后果，设置了系统容量基线，通过将压力打到系统极限从而确定系统能力；可靠性保障必备：云上如何进行混沌工程 38 针对产生流量洪峰的原因未知，测试时通过假设峰值、多用户模拟以及流控放开实现。在实际生产生产环境中，明确系统能力之后，可以通过用户流控计算来解决洪峰来源未知问题，将流控阈值设置到合理区间。针对流量峰值下系统的表现未知，在压测到系统瓶颈时，即可发现系统瓶颈时的表现。针对系统崩溃后的处理流程未知，会通过压测形式做突袭，检测业务人员是否能够针对大流量场景快速稳定地处理，减少故障时的发现-定位-恢复时长。故障演练和可观测性密不可分，可观测性建设比较完善时，才能将故障演练注入到线上系统，才能控制系统爆炸面。可观测性分为四层：业务层：包括结果 mock、JVM OOM、业务逻辑异常以及应用内 CPU 满。依赖业务层：针对依赖业务，有专门的业务接口监控，对自己以及内部依赖都会有一部分 SLA 协议。中间件和基础软件层：有针对中间件业务的监控，比如缓存命中率、慢 SQL 监控或网络状态监控。服务器层：有业务探活以及网络状态监测。针对不同层有不同的故障演练方式。比如业务层的 mock 需要拉齐所有业务域人员，要在业务层监控，还需要关注 VM 的内部；对于依赖业务，比较注重 RT 升高、结果mock 或结果报错等；中间件和基础软件层可能面对的问题有比如缓存变慢、击穿、慢 MySQL、无法连接等；弹性计算作为基础设施提供商，更关注服务器层，弹性计 可靠性保障必备：云上如何进行混沌工程 39 算在每一个地域上线时，管控系统都需要经过多可用区、宕机、演练，验证管控系统的多活可用，因此服务器层有很丰富的演练经验。故障演练的步骤如下：第一步：故障演练的理念是尽量增加系统雪崩和不稳定事件，而这与开发人员日常的理念是冲突的。因此，首先要让大家接受故障演练，由专业的演练小组安排固定的演练时间以及清晰的演练安排，拉齐所有业务参加。第二步：日常演练组织。日常演练组织中事件的选择原则为频发问题优先、风险由低到高。其次，先在低风险环境中试水，在隔离环境确认影响，在低风险环境中进行破坏性实验和大型故障模拟，比如影响完全不可控的故障需要在低风险环境中进行，较为稳定的 case 或可以确认影响的 case 方可进行线上环境演练。线上环境演练时，一般需遵循发现-定位-恢复流程。第三步：突袭。突袭有红蓝军演练和一键演练。其中红蓝军演练较为保守，会在演练小组里抽取一部分对演练 case 比较熟悉的人员，作为红军参与故障演练，不定期在系统中注入问题；其他所有业务人员为蓝军，负责验证问题的发现-定位-恢复时间。一键演练是较为激进的方式，通常由业务领导角色直接注入故障，演练所有业务人员的故障处理流程。成熟度非常高的系统方可实现一键演练的目标。第四步：总结和改进。总结和改进是混沌工程中故障演练和压测的最终目标。通过故障演练和压测确定系统极限，包括系统水位极限、运维响应极限、问题发现极限 可靠性保障必备：云上如何进行混沌工程 40 以及系统恢复极限，明确系统表现、问题处理流程；记录不可用节点以及性能瓶颈，最后将不可用节点抽取为改进目标项，责任到人做系统稳定性改进。弹性计算系统作为超大规模的分布式系统，其混沌工程与简单的混沌工程有何区别？多套环境部署。弹性计算有 20 套高可用部署以及多套环境规划，因此我们希望有自动化跟踪系统可以自动化进行 case 覆盖和 region 覆盖。内聚和耦合节点多。需要规划的依赖非常多，需要拉的业务方也很多。解决方法为拉入更多业务域，根据优先级安排先做哪些演练。海量实时调用。演练时需要面对非常大的流量系统，流量无法短暂停止，因此演练时如果造成一部分系统不稳定，在线上将会放大为非常严重的故障，可以通过灰度演练、SLA 以及熔断降级规避问题。接口功能多。希望通过自动化演练实现 case 覆盖，自动化回归 case 可以每天自动回归线上系统，回归系统性能变化。可靠性保障必备：云上如何进行混沌工程 41 3.系统评价和混沌工程工具 混沌工程系统成熟度从纵向可以分为 5 个等级：第一级：多为起步系统，为单环境、单地域部署，只能在开发和测试环境中进行演练。第二级：具备初步的多可用区部署，可以注入稍复杂的故