稳定性是一项很重要的工作，对于 ToC 客户来讲，虽然客户容忍度高，但是舆情传播快；对于 ToB 客户来说，客户容忍度低，如果出现故障造成的损失也高
三个阶段 #
一般情况下，稳定性需要关注三个阶段：事前、事中、事后，即事故发生之前的预防、发生事故时的紧急处理以及发生事故后的复盘。
事前 #
大部分的事故来源都是变更，因此需要重点关注变更，控制变更（在重要日期或节日时封网等手段）。同时，也要设计合理的发布流程，如果发布过程中出现问题能够及时发现定位止损。而在事前，需要做好的可以包括三点：可监控、可灰度、可回滚。
可监控 #
监控是通过实时采集系统运行状态、性能指标及业务数据，形成可视化的监控体系，为问题发现、根因定位和容量规划提供数据支撑。
监控可以关注变更内容以及相关的流量是否有异常，关联业务是否异常。这里的可监控包括
- 影响上层业务的监控大盘。
- 接口的性能指标以及数据库存储等依赖资源的指标
- 上下游服务的核心指标
在变更后，需要及时关注监控，观察变更后的各指标是否符合预期。
可能存在的问题：
- 变更未观测或观测时间过短
- 监控粒度没有覆盖，未对变更或者灰度做针对，导致无法发现问题
- 缺少服务上下游关联业务的监控。
- 性能监控未覆盖，只关注了功能。
可灰度 #
将新功能或变更分批、分流量逐步发布，通过小范围验证降低全量风险。旨在识别没有在测试阶段发现的问题，同时控制影响面，避免影响全局。
灰度可以关注灰度方案以及灰度场景是否都有覆盖，通常可以根据可接受故障的范围来设计第一批灰度的范围。灰度策略可以设计灰度时间又长到短，放量比例由小到大。
可回滚 #
当变更引发故障时，能迅速回退至稳定版本，最小化业务损失。
这一步骤需要关注变更回滚怎样操作，以及操作是否及时，时效性。回滚方案是否对上下游依赖产生影响。一般会在发布前确定回滚的标准，视情况在发布前验证回滚方案。对于发布来说错峰发布，防止回滚耦合。
事中 #
发现 #
通过动态监控与数据反馈，及时发现系统、业务或流程中的异常信号，缩短问题暴露的时间窗口。主要是为了避免问题扩大化，为后续定位和止损争取时间
发现的前提就是可监控，需要关注监控是否完备，可以对整体业务、服务、接口不同的层面划分监控，确定不同的响应范围、响应等级。
同时也要关注报警的有效性，灵敏度，关注度，防止报警过多、噪声大，以及灵敏度低导致的发现问题延迟高。
定位 #
基于异常现象，快速定位问题根源，区分是技术故障（如代码缺陷）、流程漏洞（如审核缺失）还是外部因素（如网络攻击）
这里需要关注定位工具、手段是否完备，问题排查效率是否高。可以做到变更记录可以快速检索，
止损 #
通过技术或业务手段，快速阻断问题扩散，减少损失。
需要关注的是是否有止损手段，止损手段执行的时效性，是否对其他业务或功能有影响，避免产生连锁反应。止损或事故过程产生的脏数据怎样及时清理或恢复。
需要建立事故通知机制，及时通知受影响的用户或业务方。及时建立止损小组或者执行止损方案。
事发后及时根据监控告警以及事故场景确定应急预案，减少决策成本时间。对一些事故可以建立链路级别的预案，在发生事故后及时切换链路。
也需要确立应急责任人，手机信息以及决策，防止意见不一致导致的应急延迟。
事后 #
对于事后，则需要关注事故后的复盘，需要根据定位、复盘、改进来完成闭环，将故障变为系统稳定系提升的契机。需要关注为什么会出现故障，事故的原因，应急过程是否存在效率低响应慢等问题，如何进一步提升效率。以及事故之后的问题修复，确定是否有监控等稳定性改进的空间。