共计 1155 个字符，预计需要花费 3 分钟才能阅读完成。
作者 | 悟鹏
起源 | 阿里巴巴云原生公众号
Kubernetes 在生产环境中的采用率越来越高，复杂度越来越高，由此带来的稳定性保障的挑战越来越大。
对于基于 Kubernetes 的云产品，稳定性保障已成为根本诉求，稳定性缺点会给产品带来微小的损失，如用户散失、用户信念降落、产品迭代速度变慢等。
尽管基于 Kubernetes 的稳定性保障很重要，但业界短少基于实际的标准化稳定性保障计划，导致同样的问题在同一产品或不同的产品中反复呈现，最佳实际不能利用在更多雷同技术栈的产品中，不同产品造成的稳定性保障最佳实际也不能互补。
为此，基于过来的开发实际以及基于 Kubernetes 的稳定性保障教训，尝试造成《Kuberentes 稳定性保障手册》，将稳定性保障最佳实际进行积淀，使得人人对 Kubenretes 稳定性保障的实践造成全面的了解，相应的工具和服务成为基础设施，复用在相似技术栈的产品中，减速稳定性保障最佳实际的流传、迭代和利用。
本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章，形象稳定性保障中的核心内容，作为稳定性保障最简使用手册。
极简手册指标
- 1min 了解稳定性保障指标
- 3min 把握稳定性保障全局视图
- 一站查找稳定性保障举荐工具或服务
稳定性保障指标
- 满足服务或产品对稳定性的诉求
- 减速服务或产品的迭代
稳定性保障查看项
稳定性保障级别
实际
方法论
全局视图
实际流程：
- 整顿运行链路图，标记链路是否是要害链路
- 基于运行链路图，进行可观测性配置
- 基于链路重要水平，进行可控性治理
为了升高实际的老本，须要把握云产品中的元素及交互关系，从根底的元素和交互方面解构简单零碎：
元素 (2 类)
- 云产品组件
- 云产品
交互 (2 类，共 3 种场景)
云产品外部
- 组件本身
- 组件与组件之间
云产品之间
- 云产品与云产品之间
如下图：
随着 元素数量 和交互关系 的增多，零碎会逐渐变得复杂，稳定性保障面临的挑战也会越来越大，要防止引入非必要的复杂性。
因而，须要先梳理分明以后的运行链路图，进行链路重要性剖析，并整顿组件大图，判断组件的爆炸半径。在此基础上，还须要进行参加人员的 review，防止在人员的投入方面存在单点危险。
运行链路图示例：
链路重要性示例：
云产品间交互示例：
基于上述对系统复杂度、运行链路的剖析，面对稳定性保障的问题域，能够无效提出、落地解决方案。
问题解决
实际流程：
- 长期保护角色列表、性能流程图、运行链路图
- 在多个分级的「告警群」中感知问题的产生和复原
- 在惟一的「问题解决群」中解决问题和复盘问题
对于简单的零碎，通常会有如下的角色关系：
梳理分明每层的角色，并使得参加同学能够不便查找指标同学，会缩短问题解决工夫。
问题域
概述
举荐
后续
对于《Kubernetes 稳定性保障手册》，接下来会进行如下的章节细化，别离从方法论和工具 / 服务的角度进行总结，造成初版后与大家分享，进行共建：
