上篇# 稳定性建设 -高可用系统建设的必备知识-上 上给大家介绍了，稳定性建设的意义 指标 和稳定性建设的事前，应该怎么做，下给大家介绍代码发布后应该怎么做和出问题应该怎么复盘
稳定性治理-事中
发布
发布内容checklist
包括不限于
- 明确是否有外部依赖接口，如有请同步协调好业务方；
- 发布前配置确认包括配置文件、数据库配置、中间件配置等各种配置，尤其各种环境下的差异化配置项；
- 二方库发布顺序，是否有依赖；
- 应用发布顺序；
- 数据库是否有数据变更和订正，以及表结构调整；
- 回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略；
- 生产环境回归测试重点 Case。
- 灰度计划
变更审批
包括不限于
- 数据库变更审批
- 配置变更审批
- 代码变更审批
- 网络变更审批
代码发布
- 必须分批发布
- 核心应用第一批和第二批之间必须间隔
- 核心应用第一批必须通过流水线发布，即流程从1%~100%逐步放量
发布后checklist
- 确定变更和配置是否全部下发完成
- 跟进验收结果
- 持续关注生产告警
可观察性
监控
- 硬件状态，网络状态（流量）、操作系统、虚拟机
- 服务层面：来源PV、依赖调用PV、响应时间、异常数、限流及各种业务数据
- 中间件：MYSQL Redis MQ等
- 宏观层面：流量的来源和损失
业务监控
系统请求量类告警
我们预估一个服务的处理能力是QPS 1w，当请求量超过1w的时候，就肯定需要告警，或者当请求接近1w的时候，就需要告警，给开发同学一个时间提前准备
假设，当我们预估正常的请求量都在10以上，那么我们就需要设置一个低于10的QPS告警，这类告警阈值需要考虑清楚，避免低峰期间无效告警。
系统耗时类告警
我们预估一个服务的最大处理RT 50ms，那么当1分钟超过50ms，就需要告警；
假设，针对某些对外服务的业务，请求方超时设置30ms，则意味着我们需要对这些进行告警，当平均耗时超过30ms时，需要告警，这意味着上游业务都是失败的。
系统异常类告警
我们预估对外服务的接口，能够容忍的一个系统失败数10，那么当失败数超过10，就需要告警（这类告警很容易变成无效告警，所以需要根据业务发展进行调整）；
同样，某个业务可能容忍的失败数比较大，直接用本系统的失败告警，但是有些业务可能请求数比较小，但是业务还很重要，这个时候需要针对这些业务细粒度设置告警阈值。
针对请求量和异常类次数告警，
可以采用周同比的方式，去设置一些震荡比率，触发告警。比如异常次数周同比增幅20%，可能认为系统存在未知问题，需要定位。
告警
告警的作用
- 预测故障：故障还没出现，但存在异常。监控系统根据流量模型、数据分析、度量趋势来推算应用程序的异常趋势，推算可能出现故障的问题点。
- 发现故障：故障已经出现，客户还没反馈到一线人员。监控系统根据真实的度量趋势来计算既有的告警规则，发现已经出现故障的问题点。
- 定位故障：故障已经出现，需要监控系统协助快速定位问题，也就是根因定位(root cause)。此时是需要协调公司内生态圈的多个组件的，例如：链路追踪系统、日志平台、监控系统、治理平台(限流熔断等)，根据监控系统所告警出来的问题作为起始锚点，对其进行有特定方向的分析，再形成 ”线索“ 报告，就可以大力的协助开发人员快速的定位问题，发现故障点。
- 故障恢复：故障已经出现，但自动恢复了，又或是通过自动化自愈了。这种情况大多出现在告警规则的阈值配置的不够妥当，又或是第三方依赖恰好恢复了的场景。
怎么做告警
合理配置告警级别
根据影响的程度配置合理的告警级别 不同级别采用不同的告警方式和响应策略
按时梳理
按时梳理去除不合理 和无用的告警 ，梳理告警级别，告警阈值防止告警过多导致抓不住关键点 告警过多精神也会松懈
复盘
- 告警响应 处理时间 出现次数 出现频率 避免有告警无人管的问题
- 梳理告警处理sop 形成沉淀文档 避免处理问题手忙脚乱无从下手和提高处理问题效率
告警内容
告警要直接可以定位问题 足够的简单，不能模糊不清
降噪
告警要可以降噪 防止系统出问题 一直重复告警 从而忽略了别的关键告警信息
告警响应
告警要可以响应 不能只是发送 要可以选择处理中 处理中的消息 一定时间不在重复发送
告警人员
首先提醒值班人员，然后根据阈值，逐级上报，响应即跟踪问题
日志
- 代码初始化时或进入逻辑入口时：系统或者服务的启动参数。核心模块或者组件初始化过程中往往依赖一些关键配置，根据参数不同会提供不一样的服务。务必在这里记录 INFO 日志，打印出参数以及启动完成态服务表述。
- 编程语言提示异常：非预期异常或失败，打印ERROR级别日志，预期的失败异常，使用WARN级别日志级别。
- 业务流程预期不符：项目代码中结果与期望不符时也是日志场景之一，简单来说所有流程分支都可以加入考虑。取决于开发人员判断能否容忍情形发生。常见的合适场景包括外部参数不正确，数据处理问题导致返回码不在合理范围内等等。
- 系统/业务核心逻辑的关键动作：系统中核心角色触发的业务动作是需要多加关注的，是衡量系统正常运行的重要指标，建议记录 INFO 级别日志。
- 第三方服务远程调用：微服务架构体系中有一个重要的点就是第三方永远不可信，对于第三方服务远程调用建议打印请求和响应的参数，方便在和各个终端定位问题，不会因为第三方服务日志的缺失变得手足无措。
- 打印日志，必须要有traceid，便于调用链查询
故障演练
制定故障演练方案和编排演练场景，模拟应用、网络、
依赖服务、硬件、中间件、数据库等故障，考核系统健壮性以及故障
恢复时间，同时评估应急方案有效性
紧急预案
在进行线上oncall的时候要根据问题出现的频次 将问题的处理流程完整记录下来
全链路压测
在服务数量增多到一定程度，出问题的可能性越来越大，现在各种常见的架构手段，高可用手段都是为了提升系统的可用性，给用户提供更好的体验。而全链路压测则相当于对服务进行一次体检，了解当前系统的状况定义：基于线上环境和实际业务场景，通过模拟海量的用户请求，来对整个系统链路进行压力测试
目的：验证新功能的稳定性验证峰值流量下服务的稳定性和伸缩性对线上服务进行更准确的容量评估找到系统瓶颈并且进行优化
指标
压测极限标准load不超过 (机器核数* 0.6)网卡流量不超过网卡容量的0.6，超过的话可能延迟比较大
请求超时不超过请求总量的十万分之一
QPS不低于预估的85%，否则需要优化，或者给出合理的解释
全链路压测好处
真实流量，数据为线上流量的录制。测试环境为生产环境，最大限度减少误差
方式
http流量 Nginx 日志
rpc服务治理框架支撑
方式
导入流量
识别流量标记流量导入流量采用上述记录的流量，加上压测标识，需要底层数据库中间件，mq等基础中间件支持
具体实现可以参考以下文章
http://www.uml.org.cn/test/202105214.asp
全链路跟踪
可以参考以下文章
https://tech.meituan.com/2022/07/21/visualized-log-tracing.html
稳定性治理-事后
故障复盘
目的 避免下次再重复犯相同或类似问题，不是简单总结，也不是追责
要求 找到靶心、溯源事实、深层挖掘、事故
一般包括以下几部分
事故影响 描述事故原因和影响访问数据
处理过程 按照时间线从问题发现到结束处理 详细记录处理问题过程
事故原因 直接原因 根本原因 和 如果事故处理时间较长还需要分析处理时间过长的原因
事故反思
- 还原事实
- 问题反思 做错了什么 作对了什么
- 原因分析 可以采用5y分析法
- 重来改进 开始做（新增改进的方案）、优化做（优化原执行步骤）
改进措施 改进措施分类：监控报警完善、流程制度补充、容灾/容错能力提升、沟通机制搭建、技术升级改造、应急预案完善等方面
定级定责
Case Study
可以建立知识库方便学习其他团队高可用建设思路或者线上故障，从而提高团队的系统设计能力，避免踩坑。，