作者 | 悟鹏
来源 | 阿里巴巴云原生
头图 | 下载于视觉中国
Kubernetes 在生产环境中的采用率越来越高，复杂度越来越高，由此带来的稳定性保障的挑战越来越大。
对于基于 Kubernetes 的云产品，稳定性保障已成为基本诉求，稳定性缺陷会给产品带来巨大的损失，如用户流失、用户信心下降、产品迭代速度变慢等。
虽然基于 Kubernetes 的稳定性保障很重要，但业界缺少基于实践的标准化稳定性保障方案，导致同样的问题在同一产品或不同的产品中重复出现，最佳实践不能应用在更多相同技术栈的产品中，不同产品形成的稳定性保障最佳实践也不能互补。
为此，基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验，尝试形成《Kuberentes 稳定性保障手册》，将稳定性保障最佳实践进行沉淀，使得人人对 Kubenretes 稳定性保障的理论形成全面的理解，相应的工具和服务成为基础设施，复用在类似技术栈的产品中，加速稳定性保障最佳实践的传播、迭代和应用。
本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章，以抽象稳定性保障中的核心内容，作为稳定性保障最简使用手册。
极简手册目标
1min 理解稳定性保障目标
3min 把握稳定性保障全局视图
一站查找稳定性保障推荐工具或服务
稳定性保障目标
满足服务或产品对稳定性的诉求
加速服务或产品的迭代
稳定性保障检查项
维度 | 检查项 |
可观测 |
|
可灰度 |
|
可回滚 |
|
可保护 |
|
可控成本 |
|
易于运维 |
|
稳定性保障级别
级别 | 标准 |
L0 |
|
L1 |
|
L2 |
|
L3 |
|
L4 |
|
L5 |
|
实践
1. 方法论
1）全局视图
实践流程：
整理运行链路图，标记链路是否是关键链路
基于运行链路图，进行可观测性配置
基于链路重要程度，进行可控性治理
为了降低实践的成本，需要把握云产品中的元素及交互关系，从基础的元素和交互方面解构复杂系统：
元素 (2 类)
云产品组件
云产品
交互 (2 类，共 3 种场景)
云产品内部
组件自身
组件与组件之间
云产品之间
云产品与云产品之间
如下图：
随着元素数量和交互关系的增多，系统会逐步变得复杂，稳定性保障面临的挑战也会越来越大，要避免引入非必要的复杂性。
因此，需要先梳理清楚当前的运行链路图，进行链路重要性分析，并整理组件大图，判断组件的爆炸半径。在此基础上，还需要进行参与人员的 review，避免在人员的投入方面存在单点风险。
运行链路图示例：
链路重要性示例：
云产品间交互示例：
基于上述对系统复杂度、运行链路的分析，面对稳定性保障的问题域，可以有效提出、落地解决方案。
2）问题处理
实践流程：
长期维护角色列表、功能流程图、运行链路图
在多个分级的「告警群」中感知问题的发生和恢复
在唯一的「问题处理群」中处理问题和复盘问题
对于复杂的系统，通常会有如下的角色关系：
梳理清楚每层的角色，并使得参与同学可以方便查找目标同学，会缩短问题处理时间。
2. 问题域
1）概述
2）推荐
维度 | 项目 | 推荐 |
目标管理 | 业务 SLA | 业务相关，可参考：
|
技术 SLI / SLO | K8s 社区：
| |
可观测性 | 日志 | 开发阶段：
运行阶段：
|
Metrics | 开发阶段：
运行阶段：
| |
巡检 | 后续推出 | |
告警 | 基于日志、metrics、巡检系统配置告警，配置每条告警时，可通过如下问题列表达到举一反三效果：
| |
可控性 | 发布管理 | 后续推出 |
恢复管理 | 实践：
挑战：
| |
混沌工程 | 实践：
| |
定期体检 | 实践：
| |
专项治理 | 复杂度治理 | 梳理：
如非必要，勿增实体。 |
爆炸半径治理 | 实践：
关注：
| |
跌零因子治理 | 实践：
|
后续
对于《Kubernetes 稳定性保障手册》，接下来会进行如下的章节细化，分别从方法论和工具/服务的角度进行总结，形成初版后与大家分享，敬请期待~
更多阅读推荐
无法恢复，欧洲云服务巨头数据中心起火
CPU 空闲时在干嘛？
低代码，让人人都可以是开发者
三探云原生全景图，这次聊聊运行时层
一眼看尽5G江湖，Gartner发布5G网络基础设施魔力象限报告
冯诺依曼架构的 IO 鸿沟，谁能来填补？
