服务稳定性建设
第一步：梳理现状
- 服务的功能有哪些，对线上业务的影响如何。
- 对服务进行定级，确定是否为重保服务。
- 确定服务请求量级(峰谷特征)，是否受节日影响，是否受其他接口波动影响。
- 确定服务部署现状，如是否多机房，是否多集群，是否有灾备预案等等。
- 梳理上下游，确定服务依赖拓扑，重点确定服务强弱依赖关系。
- 梳理上下游服务的超时配置，重试配置，熔断，限流配置等。
如果一个下游服务 b 不可用会导致上游服务 a 不可用，则 a 强依赖 b。 如果下游服务 b 不可用会导致上游服务 a 部分功能受影响，但主体功能仍然可以工作，并且业务可短暂接受这种影响，则 a 弱依赖 b。
第二步：问题发现能力
监控报警
- 检查监控大盘，看是否能覆盖可能出现的问题。常用的监控报警指标包括
服务稳定性
服务拉空率
vv计数
异常指标计数（比如由于某个特定原因对内容进行过滤的量级等）
错误日志计数
RPC调用错误计数
- 通过调整报警阈值，检查报警规则是否生效，能否准确发出消息或拨打 oncall 同事电话。
容灾演练
模拟故障，通常是模拟网络故障。检查自适应容灾是否生效，以及手动降级预案是否生效。
压测
通过压测寻找资源瓶颈，可能的瓶颈包括
- 当前压测服务自身资源瓶颈，cpu，内存等。
- 下游服务资源瓶颈。
- 依赖存储瓶颈。
如果当前压测服务与其他服务共享下游服务或存储，则可能需要联合压测。
压测可以通过线上流量集中的方案来实现，也可以使用提前录制流量的方案来实现（前提是请求没有副作用）。 如果是写接口，还可以考虑创建影子表等方式来进行压测。
问题定位与处理能力
- 服务日志要完整。这一点依赖研发工作经验，以及 code review 的负责程度。
- 内部整理 case 排查指南，问题记录与分享，每周组织学习。
- 设立 oncall 机制，创建 oncall handbook。
- 当发现问题时，需要有明确 sop，并通过演练确保所有人都能处理线上事故。
当线上出现事故时，有两种可能，一种是用户反馈发现问题；一种是监控报警发现问题。
无论是哪种情况，首先要对问题严重性有一个基本的判断。（这个也依赖经验和组内分享，比如少量的服务调用报错报警，可能只是网络抖动，但如果用用户反馈说他的账户余额不对，则可能就很严重了）
如果判断出来这是一个需要处理的线上问题，第一步要找同学帮忙，立即成立应急小组，明确分工。比如A同学负责拉群（需要周知到各个职能线），建立会议，并建立事故处理文档；B同学负责定位问题；当然，如果明确知道发生事故前有线上操作（通常都有），比如有代码上线，动态配置，实验开启等，一律先进行线上止损（回滚，或关闭实验）。
事故应急处理负责人需要实时同步事故处理进展。
事故后需要有复盘和todo。
需要有机制check todo落实。