想做个网站 怎么做,网站开发竞争对手分析,琼海做网站公司,清新区住房和城乡建设局网站简介#xff1a; 台湾作家林清玄在接受记者采访的时候#xff0c;如此评价自己 30 多年写作生涯#xff1a;“第一个十年我才华横溢#xff0c;‘贼光闪现’#xff0c;令周边黯然失色#xff1b;第二个十年#xff0c;我终于‘宝光现形’#xff0c;不再去抢风头…简介 台湾作家林清玄在接受记者采访的时候如此评价自己 30 多年写作生涯“第一个十年我才华横溢‘贼光闪现’令周边黯然失色第二个十年我终于‘宝光现形’不再去抢风头反而与身边的美丽相得益彰进入第三个十年繁华落尽见真醇我进入了‘醇光初现’的阶段真正体味到了境界之美”。 作者 | 韩堂、柘远、沉醉 来源 | 阿里巴巴云原生公众号
前言
台湾作家林清玄在接受记者采访的时候如此评价自己 30 多年写作生涯“第一个十年我才华横溢‘贼光闪现’令周边黯然失色第二个十年我终于‘宝光现形’不再去抢风头反而与身边的美丽相得益彰进入第三个十年繁华落尽见真醇我进入了‘醇光初现’的阶段真正体味到了境界之美”。 长夜有穷真水无香。领略过了 K8s“身在江湖”的那种惊心动魄以及它那生态系统的繁花似锦该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的 在 K8s 高可用领域有一个问题被大家所熟知那就是 K8s 单集群规模带来的 SLO 问题如何持续保障今天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。 ASI 单集群规模支撑超过社区的 5000 台这是个非常有意思且具备极大挑战的事情对需要进行 K8s 生产化的同学甚至具备 K8s 生产化经验的同学来说一定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的发展之路伴随着业务的增长和创新带来的每一次集群规模增长都在逐步使我们的压力和挑战发生质变。
ASIAlibaba 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 架构升级落地
1APIServer 多路架构升级
核心方案就是通过对 apiserver 进行分组通过不同的优先级策略进行对待从而对服务进行差异化 SLO 保障。 通过分流以降低主链路 apiserver 压力核心诉求 P2 及以下组件接入旁路 apiserver并可以在紧急情况如自身稳定性收到影响下做整体限流。 旁路 apiserver 配合主链路做蓝绿、灰度次级诉求 旁路 apiserver 可以使用独立版本增加新功能灰度维度如使用独立的限流策略如开启新的 feature 功能验证。 SLB 灾备次级诉求 旁路 apiserver 可以在主 apiserver 发生异常时对外提供服务需 controller 自行切换目标地址。2ASI 多集群联邦架构升级
目前张北中心的一个机房就几万节点如果不解决多集群的管理问题带来的问题如下
容灾层面把核心交易应用的中心单元部署在一个集群的风险是很大的最坏情况下集群不可用导致整个应用服务不可用。性能层面对于业务来说如因核心应用在某一时点使用时极其敏感而设定各种单机最大限制、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 中的组件例如 controllerkubeletextension-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一分钟发现问题发现能力
为了解决无法早于客户发现问题的难题我们的工作最重要的目标就是要做到让一切问题都无处遁形被系统主动发现。 所以这就像是一场持久战我们要做的就是通过各种可能的手段去覆盖一个又一个新的问题攻占一个又一个城池。 在这个目标的驱使下我们也总结出一套非常行之有效的“战略思想”即「11 思想」。它的核心观点在于任何发现问题的手段都可能因为对外部的依赖或者自身稳定性的缺陷导致偶发的失效所以必须有能够作为互备的链路来进行容错。 在这个核心思想的指导下我们团队建设了两大核心能力即黑盒/白盒报警双通道这两个通道的各有各的特点
黑盒通道基于黑盒思想从客户视角把 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 我们做了一下工作
一方面定义了一系列分类方法保证问题能够明确到团队和具体的一个负责人。一方面定义解决优先级即解决这个问题的 SLOL1 - L4不同优先级代表不同的解决标准L1 代表必须当天内迅速跟进并且解决。
每两周通过过去一段时间收集的新的问题我们会产出一份稳定性周报进行问题解决程度的通晒以及重点问题的同步。另外也会在每两周进行一次全员拉会对齐对每个新问题的负责人确定优先级确认进行对齐。
5能力验收保鲜机制
由于稳定性风险是相对低频发生的所以对稳定性能力的最好的保鲜手段就是演练所以在这个基础之上我们设计或者参与了两种演练方案分别是
常态化故障演练机制生产突袭演练机制【常态化演练机制】
常态化故障演练机制的核心目的在于以更频繁的频率对 ASI 系统相关的故障场景以及针对这个故障的恢复能力进行持续验收从而既发现某些组件的在稳定性方面的缺陷也可以验收各种恢复手段预案的有效性。 所以为了能够尽可能提升演练频率我们
一方面开始建设自身的故障场景库将所有场景进行入库分类管理保证场景的覆盖面够全面。另一方面同质量保证团队合作充分利用其 chorus 平台提供的注入故障能力将我们的设计场景逐个落地并且配置为后台持续运行。我们还借助该平台灵活的插件丰富能力将平台同我们的告警系统预案系统进行 API 对接在故障场景被触发注入后可以完全通过后台自动调用的模式完整的针对这个场景的注入、检查、恢复都通过后台运行完成。
鉴于常态化演练的演练频率如此之高我们通常在一个专用的集群中进行持续的后台演练场景触发以降低因为演练带来的稳定性风险。 【生产突袭演练机制】
常态化故障演练即便做的再频繁我们也不能完全保证在生产集群真的出现同样的问题我们是否能够以同样的方式进行应对也没有办法真正确认这个故障的影响范围是否与我们预期的范围一致这些问题最根本的原因还是在于我们在常态化故障演练中的集群一般是没有生产流量的测试集群。 所以在生产环境进行故障模拟才能够更加真实的反应线上的实况从而提升我们对恢复手段的正确性的信心。在落地方面我们通过积极参与到云原生团队组织的季度生产突袭活动将我们一些相对复杂或者比较重要的演练场景实现了在生产环境的二次验收与此同时也对我们的发现速度响应速度也进行了侧面评估不仅发现了一些新的问题也为我们如何在测试集群设计更符合线上真实情况的场景带来了很多参考输入。
写在最后
本篇仅作为开篇从整体上介绍了 ASI 全局高可用体系建设上一些探索工作以及背后的思考后续团队会针对具体的领域比如 ASI 应急体系建设ASI 预防体系建设故障诊断与恢复、全链路精细化 SLO 建设和运营、ASI 单集群规模的性能瓶颈突破上等多个方面进行深入的解读敬请期待。
原文链接 本文为阿里云原创内容未经允许不得转载。
