文章目录
稳定性是什么
“稳定性” 在 Baidu 搜索的内容中，并没有一个确定的描述，而总会给出一堆手段谈如何保证稳定性。我认为“稳定性”是一个比较抽象的表达，服务挂了是不稳定，有 bug 报错了也是不稳定，超时也是不稳定。不过这确实是一个比较容易和非研发人员沟通的词汇，容易理解。
“稳定性” 英文表达为 Robustness（鲁棒性），在 wikipedia 中的描述为：
In computer science, robustness is the ability of a computer system to cope with errors during execution and cope with erroneous input.
意思就是软件在遇到执行错误或输入异常时维持正常运行的能力，即软件对错误的容忍度。
根据错误的来源，可以将故障分为三类：
- 硬件故障
——例如磁盘故障或网络线路故障等。
-
软件故障
——例如软件中的错误。
-
用户错误
——以与预期不同的格式输入数据。
概念梳理
常与稳定性一起讨论的还有可用性（Availability）和可靠性（Reliability）
可用性
指的是规定时间内能够正常运行的能力。 通常用来衡量系统正常运行并提供服务的时间所占的百分比。一般公司在系统可用性的要求在99.9%——99.99%之间，即：全年宕机时长在50分钟——500分钟之间。Availability = Uptime ÷ (Uptime + downtime)
造成服务不可用的诱因可以分为不可预期和可预期的。
不可预期故障：
主要包括系统故障、数据及存储介质故障、服务器故障（自然灾害、电力故障等）。
可预期故障
主要包括日常操作、定期维护和升级。
可靠性
指系统在一定时间内满足一定性能标准并产生正确输出的概率。实际上和稳定性的要求是一致的。
总体看稳定性是包括可用性的，稳定性多以 SLA 作为量化的约定，SLA是对一个服务可靠程度的相对量化的约定。其中就可以包括服务可用时长、接口响应时间(如99分位)、错误率、集群吞吐率等等。
SLA
Service-Level Agreement 的缩写，意思是服务等级协议。
服务的 SLA 是服务提供者对服务消费者的正式承诺，是衡量服务能力等级的关键项。
服务 SLA 中定义的项必须是可测量的，有明确的测量方法。
| SLA项 | 含义 | 测量方法 | 示例 | 服务级别 | 接口级别 |
|---|---|---|---|---|---|
| 请求成功率 | 测量周期内服务成功应答的请求占总请求数的百分比 | (成功应答请求数/总请求)*100 | >99% | 是 | 否 |
| 可用性 | 测量周期内，服务可用时间所占百分比，可用性分三个等级。1.99.999%-99.9999%，这个是可用性最高的服务，一年累计不可用时间为5.256分钟-31.536秒，这类服务不可用会影响到用户使用，比如登录2.99.99%%-99.999%，一年累计不可用时间为52.56分钟-5.256分钟，出现不可用时会影响用户的操作，间接面向用户的服务3. 99.9%-99.99%，一年累计不可用时间为8.76小时-52.56分钟，出现服务不可用时不会影响用户的使用。 | (服务在线时间/统计周期总时间)*100 | Level 1 | 是 | 否 |
| 数据一致性 | 服务消费者调用服务接口写入数据后马上调用服务接口读取，是否可以读到写入的数据内容，包含三个等级1.强一致2.弱一致3.最终一致 | 调用资源创建接口，调用资源查询接口获取创建的数据 | 最终一致 | 是 | 否 |
| 吞吐量 | 每秒钟处理的请求数，对于服务集群建议给出总体吞吐量的计算方式，比如集群吞吐量=吞吐量*服务实例数，如果难以给出，则至少要给出典型的集群实例数情况总体吞吐量 | 统计服务每秒处理的请求数量 | 200 | 是 | 可选 |
| TP50请求延迟 | 服务运行周期内50%的请求延时地域定义的值 | 使用百分位计算方式 | 100ms | 是 | 可选 |
| TP99.9请求延迟 | 服务运行周期内99.9%的请求延迟地域定义的值 | 使用百分位计算方式 | 200ms | 是 | 可选 |
实现路径
- 事前：故障预防，这里需要考虑的就是怎么通过预先的设计，最大限度的保证质量，预测风险并降低风险，提升稳定性。
- 事中：应急处置，出了问题以后怎么处理，快恢手段有哪些，流程是什么。
- 事后：复盘改进，事后肯定要总结经验，举一反三解决同类的问题，不要被同一棵石头绊倒两次。
风险识别
- 已知的故障
- 有出现的告警
- 用户支持的反馈
- 可能存在的性能问题，或者一些慢 SQL 等
- 服务间的强弱依赖
- 一些功能的缺失
- 服务单点
- 内部和外部/离线和在线业务的相互影响
- 服务容量的不足
- 基建发布或扩容等发布操作会影响业务的情况
- 线上配置/环境/网络等的变更
- 安全问题（数据安全）
- 系统或流程的问题，如没有文档，没有沉淀，只在某些人的脑袋里面
- 一些已知的，明确的技术债务
风险控制
- 前端降级：应对后端服务不可用或后端服务异常等风险；
- 缓存降级：应对存储不可用或下游服务不可用等风险；
- 主备切换：应对主存储不可用等风险；
- 业务隔离：应对多业务接入时，单个业务引起的整体服务不可用的风险；
- 应用限流：应对多业务接入时，单个业务引起的整体服务不可用的风险；
- 整体限流：应对大流量突发的风险，保障部分用户可用；
- 容量评估及提前扩容：应对大流量突发的风险，保障一定程度流量下的业务稳定性；
- 全链路压测：应对整体链接容量不一致的风险，防止单点容量风险；
- 线上问题及用户反馈清理：应对系统中小的风险引起的大风险，如一些系统 BUG，一些没有测出来的问题等等；
- 线上告警及时处理：应对系统中小的风险引起的大风险，如一些系统 BUG;
- 扩缩容演练：应对容量冲击时基建没有准备好的风险；
- 定期压测及容量评估：应对系统演化过程中，代码变更，模块变更导致的容量变化；
- 性能优化：应对系统中某些服务的性能问题导致的风险；
风险无法完全消除，但是可以通过以上方法开展专项检查、修正，尽可能减小出现问题的可能性。此外，随着功能迭代，这些检查需要定期执行，毕竟稳定性是一个长期的工作。
大促保障
大促保障和日常保障相比，具有高并发流量、短保障周期的特点，对系统性能与保障时间有明确要求（一般为2个月左右）。
大促保障总结为以下六步：
- 系统链路&业务策略梳理（System & Biz Profiling）
- 产出对应业务域所有核心链路分析，技术&业务强弱依赖、核心上游、下游系统、资损风险。
- 根据业务活动预估大促体量和时间、人力排班，应急情况打法策略产出。
- 监控（Monitoring）
- 检查监控（业务监控、应用监控、系统监控）指标是否缺漏，阈值、时间、告警人是否合理，是否关联预案。
- 容量规划（Capacity Planning）
- 追求风险最小化和成本最小化之间的平衡，为了达到这两者的最佳平衡点，需尽量精准计算系统峰值负载流量，再将流量根据单点资源负载上限换算成相应容量，得到最终容量规划模型。
- 根据经验（历次大促）或根据业务流量转化率及业务量预估本次大促流量。
- 重点关注系统流量薄弱点（如DB）流量。
- 另外准确流量分布需要通过压测统计。
- 应急响应（Incident Response）
- 进行实战沙盘演练，以历史真实故障CASE作为应急场景输入，模拟大促期间紧急状况，旨在考验值班同学们对应急问题处理的响应情况。
- 输出作战手册用于精细化梳理大促中的应急策略，即便是对业务、系统不熟悉的轮班同学，凭借手册也能快速响应处理线上问题。分为事前事中事后：
事前
1）前置检查事项清单
大促前必须执行事项checklist,通常包含以下事项：
- 集群机器重启 or 手动FGC
- 影子表数据清理
- 检查上下游机器权限
- 检查限流值
- 检查机器开关一致性
- 检查数据库配置
- 检查中间件容量、配置(DB\缓存\NoSQL等)
- 检查监控有效性（业务大盘、技术大盘、核心告警）
- 每个事项都需包含具体执行人、检查方案、检查结果三列数据
2）前置预案
域内所有业务&技术前置预案。
事中
1）紧急技术&业务预案
需要包含的内容基本同前置预案，差异点如下：
- 执行条件&恢复条件：具体触发阈值，对应监控告警项。
- 通知决策人。
2）应急工具&脚本
常见故障排查方式、核心告警止血方式(强弱依赖不可用等)，业务相关日志捞取脚本等。
止血策略包括：限流、降级、摘流、切流（单元切流或切换备份）。
3）告警&大盘
应包含业务、系统集群及中间件告警监控梳理结果，核心业务以及系统大盘，对应日志数据源明细等数据：
- 日志数据源明细：数据源名称、文件位置、样例、切分格式。
- 业务、系统集群及中间件告警监控梳理结果：关联监控指标（链接）、告警关键级别、是否推送GOC、是否产生资损、是否关联故障、是否关联预案。
- 核心业务&系统大盘：大盘地址、包含指标明细(含义、是否关联告警、对应日志)。
4）上下游机器分组
应包含核心系统、上下游系统，在不同机房、单元集群分组、应用名，可用于事前-机器权限检查、事中-应急问题排查黑屏处理。
5）值班注意事项
包含每班轮班同学值班必做事项、应急变更流程、核心大盘链接等。
6）核心播报指标
包含核心系统&服务指标(CPU\LOAD\RT)、业务关注指标等，每项指标应明确具体监控地址、采集方式。
7）域内&关联域人员通讯录、值班
包含域内技术、TL、业务方对应排班情况、联系方式(电话)，相关上下游、基础组件(DB、中间件等)对应值班情况。
8）值班问题记录
作战记录，记录工单、业务问题、预案(前置\紧急)（至少包含：时间、问题描述（截图）、影响分析、决策&解决过程等）。值班同学在值班结束前，进行记录。
事后
1）系统恢复设置事项清单(限流、缩容)
一般与事前检查事项清单对应，包含限流阈值调整、集群缩容等大促后恢复操作。
2）大促问题复盘记录
应包含大促遇到的核心事件总结梳理。
-
测试（Testing）
- 事后总结（Postmortem）
稳定性整体评估
可靠性
- 有遵照标准化的部署流程，包括功能测试阶段、UAT测试阶段再到生产上线
- 有遵照应用分类做高可用性部署
- 两地三中心（同城多活）部署
- 数据中心内部应用高可用部署（接入层、应用层、持久化层）
- 可靠的依赖关系管理，避免依赖项失效
- 有清晰的服务间或外部服务依赖列表；
- 每个依赖项，是否都有备份、回退方案或防御性缓存；
- 有微服务（或模块）接口变更列表；
- 有稳定可靠的路由和服务发现机制
- 服务配置了健康检查和探活机制；
- 服务的健康检查结果真实可靠；
- 服务失效后，路由能够准确切换流量；
- 有使用断路器来应对反复出现异常的实例；
- 有服务分级与降级设计
- 明确的服务（模块）分级，明确的降级条件
- 有服务（模块）的、前端页面的降级控制开关，预先定义的降级逻辑
- 预定义大规模流量压力时的降级控制流程
- 有流量控制设计
- 合适的限流算法（固定窗口、漏桶、令牌）
- 流控策略（API网关、服务入口、中间件服务）
高性能
- 应用在发布前已通过压力测试
- 已识别出单个微服务实例（单体应用）资源需求与吞吐量的平衡点
- 平衡点上的资源需求CPU内存外部资源（数据库连接数、文件描述符限制、日志配额等）
- 平衡点上的吞吐量（QPS）
- 高效率的服务间通信
- 协议（报文封装效率）
- 路径
- 方式（阻塞、非租塞）
- 合理使用中间件，提升读写效率
- MQ
- Cache
- 数据库网关
伸缩性
- 使用专门的硬件，或支持资源隔离
- 微服务配置了严格的CPU、内存限制
- 单体应用使用专门的VM或者物理机
- 已预估流量增长规模
- <质>总请求用户数量级，业务流量预测
- <量>具体的QPS、RPS数
- 服务可伸缩
- 清晰的流量拓扑
- 服务失效后，流量是否能够路由到其他IDC
- 依赖项可伸缩
- 清晰的依赖项列表
- 依赖项是否可伸缩或已预留足够资源
- 数据存储可伸缩
- 数据库HA（主备切换）方案
- 数据分库
- 数据分片（分表）
容错与灾备
- 清晰的各层级故障域隔离策略
- 线程
- 进程
- 集群
- 用户
- 识别潜在故障场景，并做好故障应对方案
- 基础设施故障
- 网络故障
- 平台层故障（中间件、日志、监控、负载均衡等）
- 服务内部故障
- 服务依赖项故障（SLA不达标等）
- 识别并消除单点故障问题
- 提供软件和部署架构图，确定是否存在单点故障
- 故障点是否能被移除，或者对它们进行缓解
- 故障演练，通过所有计划测试流程和探索式测试
- 单元测试
- 集成测试
- 端到端测试
- 压力测试
- 探索式测试
- 有实施故障探测和制定对应补救策略
- 回滚（部署引起）
- 备份（依赖项失效）
- 监控告警（探测预警）
- 服务都配置了故障恢复策略
- 遵照故障的事件响应机制
监控
- 确定关键性度量指标，以及是否已被监控
- 服务级别指标
- 基础设施级别指标
- 平台级别指标
- 中间件级别指标
- 适当的日志
- 日志等级合理
- 明确定义微服务日志配额，日志保存时间
- 可参考的调用链指标，以及调用链监控
- 易理解的仪表盘
- 已包含关键性度量指标
- 能准确反映服务健康状况
- 有效可操作的告警
- 每个度量指标都设置了告警
- 告警分级设置合理的阀值：正常、警告、严重
- 告警应该可操作（若T1团队无法立即对告警采取行动，就不设告警）
- 有告警处理的文档（包含常见问题的缓解、排查流程）
- 开发人员轮班待命
文档化
- 最新的、集中式的文档
- 服务描述文档
- 服务对外API接口列表
- 服务软件、部署架构图，架构评审记录
- 服务处理的数据流程图
- 服务依赖项，依赖项监控仪表盘链接
- 监控关键指标，仪表盘链接，告警阀值设置信息
- 服务T2开发人员排班信息，联系方式
- 服务常见问题，以及其诊断、缓解和解决方法
参考
https://ljchen.net/2019/09/19/应用可靠性保障评估/