做者 | 悟鹏 来源 | 阿里巴巴云原生公众号工具
Kubernetes 在生产环境中的采用率愈来愈高，复杂度愈来愈高，由此带来的稳定性保障的挑战愈来愈大。url
对于基于 Kubernetes 的云产品，稳定性保障已成为基本诉求，稳定性缺陷会给产品带来巨大的损失，如用户流失、用户信心降低、产品迭代速度变慢等。.net
虽然基于 Kubernetes 的稳定性保障很重要，但业界缺乏基于实践的标准化稳定性保障方案，致使一样的问题在同一产品或不一样的产品中重复出现，最佳实践不能应用在更多相同技术栈的产品中，不一样产品造成的稳定性保障最佳实践也不能互补。3d
为此，基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验，尝试造成《Kuberentes 稳定性保障手册》，将稳定性保障最佳实践进行沉淀，使得人人对 Kubenretes 稳定性保障的理论造成全面的理解，相应的工具和服务成为基础设施，复用在相似技术栈的产品中，加速稳定性保障最佳实践的传播、迭代和应用。blog
本篇文章做为《Kubernetes 稳定性保障手册》第一篇文章，抽象稳定性保障中的核心内容，做为稳定性保障最简使用手册。开发
极简手册目标
- 1min 理解稳定性保障目标
- 3min 把握稳定性保障全局视图
- 一站查找稳定性保障推荐工具或服务
稳定性保障目标
- 知足服务或产品对稳定性的诉求
- 加速服务或产品的迭代
稳定性保障检查项
稳定性保障级别
实践
方法论
全局视图
实践流程：get
- 整理运行链路图，标记链路是不是关键链路
- 基于运行链路图，进行可观测性配置
- 基于链路重要程度，进行可控性治理
为了下降实践的成本，须要把握云产品中的元素及交互关系，从基础的元素和交互方面解构复杂系统：产品
-
元素 (2 类)io
- 云产品组件
- 云产品
-
交互 (2 类，共 3 种场景)class
- 云产品内部
- 组件自身
- 组件与组件之间
- 云产品之间
- 云产品与云产品之间
- 云产品内部
以下图：
随着元素数量和交互关系的增多，系统会逐步变得复杂，稳定性保障面临的挑战也会愈来愈大，要避免引入非必要的复杂性。
所以，须要先梳理清楚当前的运行链路图，进行链路重要性分析，并整理组件大图，判断组件的爆炸半径。在此基础上，还须要进行参与人员的 review，避免在人员的投入方面存在单点风险。
运行链路图示例：
链路重要性示例：
云产品间交互示例：
基于上述对系统复杂度、运行链路的分析，面对稳定性保障的问题域，能够有效提出、落地解决方案。
问题处理
实践流程：
- 长期维护角色列表、功能流程图、运行链路图
- 在多个分级的「告警群」中感知问题的发生和恢复
- 在惟一的「问题处理群」中处理问题和复盘问题
对于复杂的系统，一般会有以下的角色关系：
梳理清楚每层的角色，并使得参与同窗能够方便查找目标同窗，会缩短问题处理时间。
问题域
概述
推荐
后续
对于《Kubernetes 稳定性保障手册》，接下来会进行以下的章节细化，分别从方法论和工具/服务的角度进行总结，造成第一版后与你们分享，进行共建：