共计 11407 个字符，预计需要花费 29 分钟才能阅读完成。
简介：台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。
![上传中 …]()
作者 | 韩堂、柘远、陶醉
起源 | 阿里巴
前言
台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。
长夜有穷，真水无香。领略过了 K8s“身在江湖”的那种触目惊心以及它那生态系统的繁花似锦，该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的！
在 K8s 高可用畛域有一个问题被大家所熟知，那就是 K8s 单集群规模带来的 SLO 问题，如何继续保障？明天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。
ASI 单集群规模撑持超过社区的 5000 台，这是个十分有意思且具备极大挑战的事件，对须要进行 K8s 生产化的同学，甚至具备 K8s 生产化教训的同学来说，肯定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的倒退之路，随同着业务的增长和翻新带来的每一次集群规模增长，都在逐渐使咱们的压力和挑战产生量变。
ASI：Alibaba Serverless infrastructure，阿里巴巴针对云原生利用设计的对立基础设施，ASI 是阿里公共云服务 ACK 的阿里团体企业版。
大家晓得 K8s 社区只可能撑持五千个节点，当超过这个规模时，会呈现各种性能瓶颈问题，比方：
- etcd 呈现大量的读写提早。
- kube-apiserver 查问 pods/nodes 延时很高，甚至导致 etcd oom。
- 控制器无奈及时感知数据变动，如呈现 watch 数据提早。
以电商场景为例，100 节点增长到 4 千节点的时候，咱们提前针对 ASI apiserver 的客户端和服务端做了大量的性能优化，从 apiserver 客户端的角度优先拜访本地 cache，在客户端去做负载平衡；apiserver 服务端次要做了 watch 优化和 cache 索引优化；在 etcd 内核上利用并发读晋升单 etcd 集群读解决能力，基于 hashmap 的 freelist 治理新算法进步 etcd 存储下限，基于 raft learner 技术来进步多备能力等等。
从 4 千节点增长到 8 千节点，咱们又做了 qps 限流治理和容量治理优化、etcd 单资源对象存储拆分、组件标准全生命周期落地通过客户端的标准束缚升高对 apiserver 的压力和以及穿透到 etcd 的压力等等。
终于迎来 8 千节点增长到上万节点的时刻，咱们开始热火朝天地发展 etcdcompact 算法优化；etcd 单节点多 multiboltdb 的架构优化，apiserver 的服务端数据压缩，通过组件治理升高 etcd 写放大等；同时开始打造常态化的压测服务能力，继续答复 ASI 的 SLO。
这些例子在高可用挑战中司空见惯，列出的能力也只是其中一小部分，你兴许很难看到能力之间的关联和底层的演进逻辑。当然，更多的能力建设积淀到了咱们的零碎和机制当中。本篇文章会作为一个开始，以综述的模式分享咱们在建设 ASI 全局高可用体系中的几个要害局部，再往后会有针对性地对进行技术点和演进路线的详解。如果大家有什么问题或者心愿理解的局部，欢送在评论区留言。
ASI 全局高可用概述
高可用是个比较复杂的命题，任何日常的变动例如服务降级、硬件更新、数据迁徙、流量突增等都可能造成服务 SLO 受损，甚至不可用。
ASI 作为容器平台，并非孤立存在，而是与云底层及公共服务造成齐备的生态系统。要解决 ASI 的高可用问题，须要纵观全局，找出每层的最优解，最终串联组成最优的整体解决方案。波及到的层面包含：
- 云根底相干治理，包含可用区的抉择，布局和硬件资产的治理
- 节点的治理
- ASI 集群治理
- 公共服务
- 集群运维
- 利用研发
特地是在 ASI 这个场景下，要撑持的业务集群数量宏大，波及到的研发运维人员泛滥，性能公布频繁的迭代开发模式以及业务品种繁多带来的运行时的复杂多变，相比其余容器平台来看，ASI 高可用面临更多的挑战，其难度显而易见。
ASI 全局高可用设计
如下图所示，现阶段高可用能力建设整体策略以 1-5-10（故障 1 分种发现、5 分钟定位、10 分钟止损）为指标牵引，重视将能力积淀到零碎或机制中，让 SRE/Dev 可能无差别的 oncall。
尽量避免产生问题、尽快发现、定位及复原问题，是实现目标的要害，为此咱们将 ASI 全局高可用体系的实现分三大部分开展：一是根底能力建设；二是应急体系建设；三是通过常态化压测以及故障演练等实现上述能力的保鲜和继续演进。
通过 3 个局部的轮转驱动，实现一个 ASI 全局高可用体系的构建，其顶层是 SLO 体系和 1-5-10 应急体系。在应急体系和数据驱动的体系背地，咱们建设了大量高可用根底能力，包含进攻体系、高可用架构降级、故障自愈体系、以及继续改良机制。与此同时，咱们建设了多个基础性平台为高全用体系提供配套能力，如常态化故障演练平台、全链路仿真压测平台、告警平台、预案核心等等。
全局高可用根底能力建设
在建设全局高可用能力之前，咱们的零碎在迅速倒退和变动下一直呈现事变和险情，须要隔三差五去应急，导致让问题追身的场面，并且追身后没高效应对的伎俩，面临着几个严厉的挑战：
- 如何在架构和能力下来晋升咱们的可用性，升高零碎产生故障的概率和影响面？
- 如何在外围链路性能和架构上做一些冲破，可能撑持这么复杂多变的业务场景和业务增长的通用需要？
- 如何让问题不再追身，做好预防工作，防止应急？
- 如何在应急产生时，可能疾速发现，疾速诊断，疾速止损？
针对这些问题，并且总结出以下几个外围起因：
- 可用性能力有余：在团体场景下，组件一直在变动，一直减少零碎的压力和复杂度，ASI 在生产可用性的能力上缺失，如限流降级、负载平衡等，组件容易乱用造成低级谬误，影响集群可用性。
- 零碎风控和 pod 爱护能力有余：在人为误操作或零碎 bug 时, 容易造成业务 pod 无辜受损或者大面积受损。
- 容量危险：集群数量几百，组件靠近一百；另外历史问题因 podCIDR 和节点 IP 数的配置，大多 ASI 元集群的节点规模被束缚在 128 台以内，随着业务疾速倒退，对容量危险而言存在较大挑战。
- 单集群规模受限，加上横向扩大能力有余影响业务倒退：单集群一直增长规模，以及业务类型变动，组件变动都对单集群撑持的最大规模产生影响，对 SLO 继续稳固产生影响。
1. 高可用根底能力顶层设计
针对这些解决的问题，咱们做了高可用根底能力的顶层设计，这些根底能力建设整体次要分为几个局部：
性能优化和高可用架构建设：次要是从性能优化和架构降级的角度来晋升整个集群撑持的业务类型和业务量。
组件标准全生命周期治理：次要从标准的角度在组件的整个生命周期去落地，从出世启用和集群准入开始，到每一次变更，到下线整个生命周期都要避免组件乱用、横蛮成长、有限收缩，管制组件在零碎可接受范畴之内。
攻防体系建设：次要从 ASI 零碎自身触发，在从攻打和进攻的角度来晋升零碎的平安，进攻和风控能力。
上面针对咱们的一些痛点进行几个要害能力建设的形容。
2. K8s 单集群架构的痛点
- 对 ApiServer 的掌控能力不够，应急能力有余，咱们本人的经验，历次集群 Master 出现异常的次数超过 20+，历次复原工夫最长超过 1 小时。
- ApiServer 是 APIServer 集群的单点，爆炸半径大。
- 单集群规模大，Apiserver 内存水位比拟高，压力来源于频繁的查问，写入更多更大的资源对象。
- 在业务层短少跨机房的容灾能力，当 ASI 不可用的时候，只能依赖 ASI 的恢复能力。
- 集群规模的继续扩充，离线工作的大量创立和删除对集群的造成更大压力。
这外面从两个大的角度能够去进步集群架构的可用性，除了在单集群进行架构优化以及性能冲破外，还要通过多集群这样的横向扩大能力去撑持更大的规模。
- 一是通过联邦这样的多集群能力来解决单集群的横向扩大能力以及单地区跨集群容灾能力。
- 另外一个单集群自身的架构还能够从隔离和优先级策略的架构角度来进行差异化 SLO 保障。
3. ASI 架构降级落地
1）APIServer 多路架构降级
- 外围计划就是通过对 apiserver 进行分组，通过不同的优先级策略进行看待，从而对服务进行差异化 SLO 保障。
-
- 通过分流以升高主链路 apiserver 压力（外围诉求）
- P2 及以下组件接入旁路 apiserver，并能够在紧急情况（如本身稳定性收到影响）下，做整体限流。
- 旁路 apiserver 配合主链路做蓝绿、灰度（次级诉求）
- 旁路 apiserver 能够应用独立版本，减少新性能灰度维度，如应用独立的限流策略，如开启新的 feature 性能验证。
- SLB 灾备（次级诉求）
- 旁路 apiserver 能够在主 apiserver 产生异样时，对外提供服务（需 controller 自行切换指标地址）。
2）ASI 多集群联邦架构降级
目前张北核心的一个机房就几万节点，如果不解决多集群的治理问题，带来的问题如下：
- 容灾层面：把外围交易利用的核心单元部署在一个集群的危险是很大的，最坏状况下集群不可用导致整个应用服务不可用。
- 性能层面：对于业务来说，如因外围利用在某一时点应用时极其敏感而设定各种单机最大限度、CPU 互斥独占保障，如果都部署在一个集群的话，会因为集群节点规模限度，导致利用产生重叠，造成 cpu 热点，性能不满足要求；对于 ASI 管控 Master 来说，单集群无限度扩充，性能总会呈现瓶颈，总有一天会无奈撑持。
- 运维层面：当某个利用扩容发现没资源，SRE 还得思考节点加到哪个集群，额定加大了 SRE 集群治理的工作。
因而 ASI 须要达成对立的多集群治理解决方案，帮忙下层各个 Pass、SRE、利用研发等提供更好的多集群治理能力，通过它来屏蔽多集群的差别、不便的进行多方资源共享。
ASI 抉择基于社区联邦 v2 版本来开发满足咱们的需要。
4. K8s 集群遭逢规模增长带来的极大性能挑战
在一个大规模的 K8s 集群中性能会遇到哪些问题呢？
- 首先是查问相干问题。在大集群中最重要的就是如何最大水平地缩小 expensive request。对百万级别的对象数量来说，按标签、namespace 查问 Pod，获取所有 Node 等场景时，很容易造成 etcd 和 kube-apiserver OOM 和丢包，乃至雪崩等问题产生。
- 其次是写入相干问题。etcd 实用场景是读多写少，大量写申请可能会导致 db size 持续增长、写性能达到瓶颈被限速、影响读性能。如大量的离线作业须要频繁的创立和删除 pod，通过 ASI 链路对 pod 对象的写放大，最终对 etcd 的写压力会放大几十倍之大。
- 最初是大资源对象相干问题。etcd 适宜存储较小的 key-value 数据，在大 value 下，性能急速降落。
5. ASI 性能瓶颈冲破
ASI 性能优化的方向
ASI 的性能优化能够从 apiserver 客户端、apiserver 服务端、etcd 存储 3 个方面来进行优化。
- 客户端侧，能够做 cache 优化，让各个 client 优先拜访本地 informer cache，也须要做负载平衡优化，次要包含对 apiserver,etcd 的负载平衡。同时针对客户端的各种优化，能够通过组件性能标准，在组件启用，准入的时候进行校验是否满足。
- APIServer 侧，能够从拜访层，缓存层，存储层 3 个档次进行优化。在缓存层，咱们重点建设了 cache 的索引优化以及 watch 优化，在存储层上重点通过 snappy 压缩算法对 pod 进行数据压缩，在拜访层上重点建设了限流能力。
- etcd 存储侧的优化，咱们也从几个方面做了很多工作，包含 etcd 内核层面各种算法优化工作，还有通过将不同资源拆分到不同 etcd 集群的能力实现了根本的程度拆分能力，同时也在 etcd server 层做 multi boltdb 的扩大能力晋升。
6. K8s 集群的预防能力单薄
在 K8s 中，kube-apiserver 作为对立入口，所有的控制器 /client 都围绕 kube-apiserver 在工作，只管咱们 SRE 通过组件的全生命周期进行标准束缚卡点改良，比方通过在组件的启用和集群准入阶段进行了卡点审批，通过各个组件 owner 的全面配合革新后，大量的低级谬误失去防备，但还是有局部控制器或局部行为并不可控。
除了基础设施层面的故障外，业务流量的变动，是造成 K8s 十分不稳固的因素，突发的 pod 创立和删除，如果不加以限度，很容易把 apiserver 打挂。
另外非法的操作或代码 Bug 有可能造成业务 pod 影响，如不非法的 pod 删除。
联合所有危险进行分层设计，逐层进行危险防控。
7. ASI 单集群的预防能力增强
1）反对 API 拜访层的多维度（resource/verb/client）精细化限流
社区晚期采纳的限流形式次要通过 inflight 管制读写总体并发量，咱们过后在 apf 没有进去之前就意识到限流能力的有余，没有能力去对申请起源做限流。而 apf 通过 User 来做限流（或者说要先通过 authn filter）存在一些有余，一方面因为 Authn 并不是便宜的，另外一方面它只是将 API Server 的能力按配置来做调配，并不是一种限流计划和应急预案。咱们须要紧急提供一种限流能力，以应答紧急情况，自研了 ua limiter 限流能力，并基于 ua limiter 简略的配置形式实现了一套限流治理能力，可能很不便在几百个集群当中进行默认限流治理，以及实现应急限流预案。
上面是咱们自研的 ua limiter 限流计划和其余限流计划的具体比照：
ua limiter、APF、sentinel 在限流上的侧重点是不一样的：
- ua limiter 是依据 ua 提供一个简略的 QPS hard limit。
- apf 更加侧重于并发度的管制，思考的是流量的隔离和隔离后的公平性。
- sentinel 性能全面，然而对于公平性的反对并没有 APF 全面，同时复杂度有一些过高。
思考咱们现阶段的需要和场景，发现 ua limiter 落地最为适合，因为咱们通过 user agent 的不同，来对于组件进行限流。当然后续进行更加精密的限流，还是能够思考联合应用 APF 等计划进一步增强。
限流策略如何治理，数百套集群，每套集群规模都不太一样，集群节点数、pod 数都是不同的，外部组件有近百个，每个组件申请的资源均匀有 4 种，对不同资源又有均匀 3 个不同的动作，如果每个都做限流，那么规定将会爆炸式增长，即使做收敛后保护老本也十分的高。因而咱们抓最外围的：外围资源 pod\node、外围动作（创立、删除、大查问）；最大规模的：daemonset 组件、PV/PVC 资源。并联合线上理论流量剖析，梳理出二十条左右的通用限流策略，并将其纳入到集群交付流程中实现闭环。
当新的组件接入，咱们也会对其做限流设计，如果比拟非凡的，则绑定规定并在集群准入和部署环节主动下发策略，如果呈现大量的限流状况，也会触发报警，由 SRE 和研发去跟进优化和解决。
2）反对业务 POD 级别的精细化限流
所有 pod 相干的操作都会对接 Kube Defender 对立风控核心，进行秒级别、分钟级、小时级、天级别的流控。该全局风控限流组件，履行核心端部署，保护各场景下的接口调用限流性能。
defender 是站在整个 K8s 集群的视角，针对用户发动的或者零碎主动发动的有危险的操作进行防护（流控、熔断、校验）和审计的风控系统。之所以做 defender，次要从以下几个方面思考：
- 相似 kubelet/controller 这样的组件，在一个集群中存在多个过程，任一繁多过程都无奈看到全局的视图，无奈进行精确的限流。
- 从运维视角，扩散在各个组件中的限速规定难以配置与审计，当局部操作因为限流起因失败时，排查链路过长影响问题定位的效率。
- K8s 面向终态的分布式设计，每个组件都有决策的能力，那么就须要一个集中的服务对那些危险决策进行风控。
defender 的框架图如下所示：
- defender server 是 K8s 集群级的服务，能够部署多个，其中一个 active，其余 standby。
- 用户能够通过 kubectl 配置风控规定。
- K8s 中的组件，例如 controller，kubelet，extension-controller 等，都能够通过 defender sdk 接入 defender（改变很小），在进行危险操作前申请 defender 进行风控，依据风控后果决定是否持续该危险操作。defender 作为一个集群级的风控防护核心，为 K8s 集群的整体稳定性进行保驾护航。
3）数字化容量治理
在只有几个 core 集群的场景下，依附专家教训治理容量齐全能够轻松搞定，但随着容器业务的疾速倒退，笼罩泛交易、中间件、新生态、新计算以及售卖区等业务在接入 ASI，短短几年工夫就倒退了几百个集群，再倒退几年数以千计万计？如此多的集群依附传统的人肉资源管理形式难以胜任，人力老本越来越高，特地是面临诸如以下问题，极易造成资源使用率低下，机器资源的重大节约，最终造成局部集群容量有余导致线上危险。
- 组件变更一直，业务类型和压力也在变动，线上实在容量（到底能扛多少 qps）大家都不得而知，当业务须要增大流量时是否须要扩容？是否横向扩容也无奈解决问题？
- 晚期申请容器资源随便，造成资源老本节约重大，须要基于容器老本消耗最小化明确领导应该正当申请多少资源（包含 cpu，内存及磁盘）。同一个地区，同一个元集群的业务集群，一个集群节约了资源就会造成其余集群资源的缓和。
在 ASI 中，组件变动是常态，组件容量如何自适应这种变动也是一个十分大的挑战。而日常的运维及诊断须要有精准的容量数据来作为备容撑持。
因而咱们决定通过数据化领导组件申请正当的（成本低，平安）容器资源。通过数据化提供日常运维所须要的容量相干数据，实现备容，在生产水位异样时，实现应急扩容。
目前咱们实现了水位监控、全量危险播报、预调度、profile 性能数据定时抓取、进而通过组件标准中推动 CPU 内存以及 CPU 内存比例优化。正在做的包含自动化的规格倡议，节点资源补充倡议，以及自动化导入节点，联合 chatops 正在打造钉群“一键备容”闭环。另外还在联合全链路压测服务数据，得出各个组件的基线比照，通过危险决策，进行公布卡点，确保组件上线平安。同时将来会联合线上实在的变更，来继续答复实在环境的 SLO 体现，精准预测容量。
全局高可用应急能力建设
高可用根底能力的建设能够为 ASI 提供强有力的抗危险保障，从而在各种危险隐患呈现时，尽可能保障咱们服务的可用性。然而在危险呈现后，如何疾速染指毁灭隐患，或者在高可用能力无奈笼罩的故障呈现后，进行有序止损，就变成了一个十分具备技术深度和横向复杂度的工程难题，也让 ASI 的应急能力建设成为咱们十分重要的投入方向。
在建设应急体系之初，咱们的零碎因为迅速的倒退和变动，一直呈现的事变和险情，显著的暴露出过后咱们面临的几个重大的问题：
- 为什么客户总是早于咱们发现问题？
- 为什么复原须要这么长的工夫？
- 为什么同样的问题会反复呈现？
- 为什么只有几个人能解决线上的问题？
针对这些问题，咱们也进行了充沛的脑暴和探讨，并且总结出以下几个外围起因：
- 发现问题伎俩繁多：只有 metrics 数据作为最根本裸露问题的伎俩。
- 定位问题能力不足：只有多数监控大盘，外围组件的可观测能力建设水平没有对立。
- 复原伎俩不足体系：线上问题的修复须要长期敲命令，写脚本，效率低且危险大。
- 应急短少体系标准：不足与业务方联动，工程师思维重大，不是以止损为第一指标，对问题重大度不足意识。
- 长期问题不足跟踪：线上发现的隐患，或者事变复盘的跟进项，不足继续跟进能力，导致反复踩坑。
- 不足能力保鲜机制：业务变动十分疾速，导致一些能力在一段时间后，进入一个“不会用也不敢用，也不能保障肯定能用”的难堪地步。
1. 应急能力建设顶层设计
针对这些亟待解决的问题，咱们也做了应急能力的顶层设计，架构图如下：
应急能力建设整体能够分为几个局部：
- 1-5-10 应急体系：针对线上呈现的任何突发危险，都能做到“一分钟发现，五分钟定位，十分钟复原”的底层能力和机制。
- 问题追踪跟进：针对线上发现的所有危险隐患，无论重大与否，都能继续跟踪推动的能力。
- 能力保鲜机制：针对建设的 1-5-10 能力，鉴于其应用频率比拟低的实质个性。
2. 应急能力建设子模块建设
针对顶层设计中的每个子模块，咱们都曾经做出了一些阶段性的工作和成绩。
1）一分钟发现：问题发现能力
为了解决无奈早于客户发现问题的难题，咱们的工作最重要的指标就是要做到：让所有问题都无处遁形，被零碎被动发现。
所以这就像是一场持久战，咱们要做的，就是通过各种可能的伎俩去笼罩一个又一个新的问题，攻占一个又一个城池。
在这个指标的驱使下，咱们也总结出一套十分卓有成效的“战略思想”，即「1+1 思维」。它的外围观点在于，任何发现问题的伎俩，都可能因为对外部的依赖或者本身稳定性的缺点，导致偶发的生效，所以必须有可能作为互备的链路来进行容错。
在这个核心思想的领导下，咱们团队建设了两大外围能力，即黑盒 / 白盒报警双通道，这两个通道的各有各的特点：
- 黑盒通道：基于黑盒思维，从客户视角把 ASI 整体当做黑盒，间接收回指令，探测正向性能；比方间接扩容一个 statefulset。
- 白盒通道：基于白盒思维，借助零碎外部裸露进去的各种维度的可观测性数据的异样稳定来发现潜在问题；比方 APIServer 的内存异样上涨。
黑盒通道对应的具体产品叫做 kubeprobe，是由咱们团队脱胎于社区 kuberhealthy 我的项目的思维上进行更多的优化和革新造成的新产品，并且也成为咱们判断集群是否呈现重大危险的重要利器。
白盒通道的建设绝对更为简单，它须要建设在齐备的可观测数据的根底之上，才可能真正施展它的功力。所以为此咱们首先从 metrics、日志、事件 3 个维度别离基于 SLS 建设 3 种数据通道，将所有可观测数据对立到 SLS 上治理。另外咱们也建设了告警核心，负责实现对以后上百套集群的告警规定的批量治理，下发能力，最终结构了出了一个数据齐备，问题笼罩宽泛的白盒告警零碎。最近还在进一步将咱们的告警能力向 SLS 告警 2.0 迁徙，实现更加丰盛的告警性能。
2）五分钟定位：问题根因主动定位能力
随着线上问题排查教训的不断丰富，咱们发现有很多问题会比拟频繁地呈现。它们的排查办法和复原伎俩根本曾经比拟固化。即使某个问题背地的起因可能有多种，然而随着线上排查教训的丰盛，根本都能够缓缓迭代出对这个问题的排查路线图。如下图所示，是针对 etcd 集群不衰弱的告警设计的排查路线：
如果把这些绝对比拟确认的排查教训固化到零碎中，在问题呈现后能够主动触发造成决策，势必能够大幅缩小咱们对线上问题的解决耗时。所以在这个方面，咱们也开始了一些相干能力的建设。
从黑盒通道方面，kubeprobe 构建了一套自闭环的根因定位系统，将问题排查的专家教训下沉进零碎中，实现了疾速和主动的问题定位性能。通过一般的根因分析树以及对失败巡检探测事件 / 日志的机器学习分类算法（继续开发投入中），为每一个 KubeProbe 的探测失败 Case 做根因定位，并通过 KubeProbe 内对立实现的问题严重性评估零碎（目前这里的规定仍比较简单），为告警的严重性做评估，从而判断应该如何做后续的解决合适，比方是否自愈，是否电话告警等等。
从白盒通道方面，咱们通过底层的 pipeline 引擎的编排能力，联合曾经建设的数据平台中的多维度数据，实现了一个通用的根因诊断核心，将通过各种可观测数据从而排查问题根因的过程通过 yaml 编排的形式固化到零碎中，造成一个根因诊断工作，并且在触发工作后造成一个问题的诊断论断。并且每种论断也会绑定对应的复原伎俩，比方调用预案、自愈等等。
两种通道都通过钉钉机器人等伎俩实现相似 chatops 的成果，晋升 oncall 人员的解决问题速度。
3）十分钟复原：复原止损能力
为了可能晋升运行时故障的止损复原速度，咱们也把复原止损能力的建设放在第一优先级，这个方面咱们的外围准则是两个：
- 止损能力要系统化，白屏化，可积淀。
- 所有以止损为指标，而不是以找到相对的根因为指标。
所以在这两个准则的驱使下，咱们做了两个方面的工作：
- 建设预案核心：中心化积淀咱们所有的止损能力到零碎中，白屏治理，接入，运行。一方面也能够将以前散落在各个研发手中或者文档中的预案对立收拢核心端对立治理，实现了对预案的中心化管控。另一方面预案核心也开发了反对用户通过 yaml 编排的形式来录入预案的能力，从而实现低成本接入。
- 建设通用止损伎俩集：依据过往历史教训，联合 ASI 的特有个性，建设多种通用的止损能力汇合，作为应急时的重要抓手。包含了组件原地重启，组件疾速扩容，controller/webhook 疾速降级，集群疾速切换只读等等罕用性能。
4）问题继续跟踪机制 BugFix SLO
针对不足跟进能力的问题，咱们提出了 BugFix SLO 机制。正如名字所形容的那样，咱们认为每个发现的问题都是一个要被修复的“Bug”，并且针对这种 Bug 咱们做了一下工作：
- 一方面，定义了一系列分类办法保障问题可能明确到团队和具体的一个负责人。
- 一方面，定义解决优先级，即解决这个问题的 SLO，L1 – L4，不同优先级代表不同的解决规范，L1 代表必须当天内迅速跟进并且解决。
每两周，通过过来一段时间收集的新的问题，咱们会产出一份稳定性周报，进行问题解决水平的通晒以及重点问题的同步。另外也会在每两周进行一次全员拉会对齐，对每个新问题的负责人确定，优先级确认进行对齐。
5）能力验收保鲜机制
因为稳定性危险是绝对低频产生的，所以对稳定性能力的最好的保鲜伎俩就是演练，所以在这个根底之上咱们设计或者参加了两种演练计划，别离是：
- 常态化故障演练机制
- 生产突袭演练机制
【常态化演练机制】
常态化故障演练机制的外围目标在于以更频繁的频率对 ASI 零碎相干的故障场景以及针对这个故障的恢复能力进行继续验收，从而既发现某些组件的在稳定性方面的缺点，也能够验收各种复原伎俩预案的有效性。
所以为了可能尽可能晋升演练频率，咱们：
- 一方面开始建设本身的故障场景库，将所有场景进行入库，分类，治理，保障场景的覆盖面够全面。
- 另一方面同质量保证团队单干，充分利用其 chorus 平台提供的注入故障能力将咱们的设计场景一一落地，并且配置为后盾继续运行。咱们还借助该平台灵便的插件丰盛能力，将平台同咱们的告警零碎，预案零碎进行 API 对接，在故障场景被触发注入后，能够齐全通过后盾主动调用的模式残缺的针对这个场景的注入、查看、复原都通过后盾运行实现。
鉴于常态化演练的演练频率如此之高，咱们通常在一个专用的集群中进行继续的后盾演练场景触发，以升高因为演练带来的稳定性危险。
【生产突袭演练机制】
常态化故障演练即使做的再频繁，咱们也不能齐全保障在生产集群真的呈现同样的问题，咱们是否可能以同样的形式进行应答；也没有方法真正确认，这个故障的影响范畴是否与咱们预期的范畴统一；这些问题最基本的起因还是在于咱们在常态化故障演练中的集群个别是没有生产流量的测试集群。
所以在生产环境进行故障模拟才可能更加实在的反馈线上的实况，从而晋升咱们对复原伎俩的正确性的信念。在落地方面，咱们通过积极参与到云原生团队组织的季度生产突袭流动，将咱们一些绝对简单或者比拟重要的演练场景实现了在生产环境的二次验收，与此同时也对咱们的发现速度，响应速度也进行了侧面评估，不仅发现了一些新的问题，也为咱们如何在测试集群设计更合乎线上真实情况的场景带来了很多参考输出。
写在最初
本篇仅作为开篇从整体上介绍了 ASI 全局高可用体系建设上一些摸索工作以及背地的思考，后续团队会针对具体的畛域比方 ASI 应急体系建设，ASI 预防体系建设，故障诊断与复原、全链路精细化 SLO 建设和经营、ASI 单集群规模的性能瓶颈冲破上等多个方面进行深刻的解读，敬请期待。
原文链接
本文为阿里云原创内容，未经容许不得转载。