近期随着业务的改造，新旧交替，不同系统的稳定性问题大量爆发，基于此我们对稳定加大了投入，梳理出来了部分保证系统平稳运行的方法论，在这里做一下分享，切记"稳定性压倒一切".
保障总则保障总则，即保障策略，对于一个系统，如果要做到全方位的稳定性保障，应该具备一下3个硬性条件，脱离这3个条件，很难保证线上业务能够在波谲云诡的大海上长久稳定运行。
- 可感知
- 可预防和应急
- 可快速处理
下面就上面的3个条件，这里做一些细致的说明。
可感知
可感知顾名思义，就是要能够实时的监测到系统的运行状态，任何细微的波动都能反馈出来。可感知最重要的便是监控系统，监控是我们的眼睛，有了他我们才能观察到我们的业务在线上运行的怎么样。
监控体系是感知、预防问题最主要、最有效的手段，主要包括业务监控、应用监控、系统监控。对于监控来说必须保障灵敏性、准确性，在此基础上在配合告警系统，我们就能第一时间发现问题并处理问题，减少故障带来的损失，减少舆论压力，赢得使用方的信赖。此外一些特殊的优先级高的故障应该发送给GOC故障报警，防止工作时间盲区不能及时发现。
业务监控
业务监控突出的是业务场景，业务指标，他和一些硬件指标不同，我们需要有链路追踪功能（trace），要能实时反应一个用户的操作从客户端发起一直到服务端的整个过程，能够没阶段的耗时，花销，调用等信息。方便我们定位故障发生的位置，缩短问题处理时间。当然了这只是最基本的一个监控埋点，对于不同的业务形态，我们还需定义不同的指标。
对于网关层我们关注的是：
PV， UV
业务qps
错误状态码请求量
请求耗时
不通region的流量占比...
对于分布式系统，我们可能更关注：
- set/get等各种指令的qps（不同分布是系统，这块儿不同）
- latency
- slot是否均衡
- error
应用监控
应用监控强调的是一些支撑业务运行的框架或系统的监控信息，他们是业务运行的土壤，常见的监控内容
- JVM：内存、GC、线程、CPU
- 异常：应用的异常数
- WEB URL：应用URL的调用数量、时间、并发情况
- Spring 方法：方法调用数量、时间、并发情况
- SQL：执行次数、时间、并发
- 服务HSF：执行次数、时间、成功率
系统监控
系统监控就是监控我们的硬件资源，这是业务最最最底层的东西，所有的应用都直接或者间接的跑在硬件上。要包括：
- RT(页面平均响应时间)
- LOAD/CPU/MEMORY/DISK/TRAFFIC(网卡流量)
- TCP(各个状态、请求量、retry)/端口监控
- 网络：LVS/交换机流量/带宽容量
- 容量水位：集群的实时QPS水位
异常报警
有了监控不配置告警，那么你的监控系统将不能发挥他的作用，将显得一无是处。
- GOC故障报警配置：需要注意的是一定要和故障等级保持一致，为了避免误报，建议增加多维度监控，如成功率+失败量，成功量+总量组合等。
- 报警阈值必须和故障等级定义保持一致（如P4是下跌10%等），如果有平时波动比较大，请和GOC同学确认故障等级定义的阈值。
- 接入风险预警：曲线下跌接近故障点时，提前在群里推送通知提醒
- 自己感知的报警：P1、P2故障点要有业务自己感知的报警机制，提前发现异常，不要等到GOC推送报警，过于被动
线上巡检
定期的线上巡检，能够提前发现系统的瓶颈，从而在故障发生前消除故障，像资源容量，访问量的增长趋势，访问不均衡等都能在问题出现前得到处理。对于线上巡检：
- 核心页面线上巡检：P1、P2故障点的页面巡检频率需要缩短到分钟级（如15分钟），因为P1、P2故障点一旦发生就是分钟级，迅速下跌
- 页面请求耗时前端监控：前端或测试同学增加核心页面响应时间耗时监控
可预防及应急
强弱依赖
稳定性建设非常重要的一环是梳理出应用、接口的强弱依赖，首先梳理出哪些是强依赖，哪些是弱依赖。强依赖一般指此服务有问题，流程会卡住，直接影响功能，否则为弱依赖。
要有强弱依赖梳理工具，能够查询接口的调用链，根据业务场景去判断哪些接口是强依赖、哪些是弱依赖
强弱依赖接口治理：
- 先去除没有必要、不合理的依赖
- 不影响核心业务的依赖全部变为弱依赖
- 弱依赖：增设降级开关，紧急情况直接降级处理；配置限流
- 强依赖：能加缓存的加缓存；加预案开关 ，可快速止血
限流降级
限流阈值：压测目标达成且压测稳定后，根据压测时段接口的单机qps峰值和压测时段系统的水位来设置；一般是接口单机qps峰值上调20%。线上验证的时候，根据block的次数和系统的水位来决定是否再次调整。
降级：对外部依赖服务接口，要做降级处理
反爬：对异常流量进行拦截和清洗，将其扼杀在门外
针对被第三方调用的接口要做限流处理，以防流量暴增被拖垮；
同时依赖别人的服务接口，也要做一定的降级处理，以免受到抖动等异常的影响。
应急预案
对于线上的故障和异常，我们要设置应急预案，应急SOP，应急工作流能够保证快速恢复，再此基础上我们更应该建设自己的应急预案平台，能够做到一键降级，一键切流。
预案平台要支持switch、diamond、orange等多种配置推送方式，应急情况下可打开预案开关。
预案开关在紧急情况下可快速止血，但是预案在线上使用前必须在日常、预发环境验证通过后，再到线上开启。此外，建议提前挂公告，对消费者有影响的，同步客满，更建议做好产品体验优化，避免降级后带来的大量客诉。
故障演练
我司没周都会有固定时间进行压测，验证节假日或大促的峰值，除此之外还有每个业务团队（包括中间件）也有自己的定期演练计划，最好能够建设自己的故障演练平台，能够全方位的模拟故障。
故障演练隶属于破坏性测试，但其本身的应用范围不仅仅在于测试环节，业务应用相当广泛，谈谈可能存在三种业务。
建立基于SLO（SLA）的故障体系
Google SRE中已经说明绝对的高可用付出的成本极大，零故障系统是不存在的，任何服务都应该给出自己服务风险容忍度，并且应该要采用错误预算的机制来鼓励提高系统可靠性。
通过故障演练来推进建设服务SLA体系（SLA是服务SLO，加上不满足SLO的“处罚”内容），也是一可行路径：
- 任何系统，尤其是底层服务系统，比方说网关类如aserver，中间件类如vipserver，基础设施类如网络设备，都应该提供对外服务能力申明（即SLA），通过故障演练确定具体SLO值，并且采用错误预算方法来定期锤炼服务系统。
- 故障等级制度，应该以SLA为标准激励系统改进稳定性，故障恢复时长满足SLA的重大故障是否可降级，虽然故障发生由天定，但故障恢复处理时长的缩短，从2个小时到30分钟到10分钟，这就标识着稳定性的进步，故障演练平时可锤炼和夯实故障恢复能力。
- 服务系统对外透明服务SLA，本身就对上游系统的依赖提出了要求，因此在系统开发中就会考虑到异常的处理方案，故障演练可检测出不满足“契约”的上游系统，基于此制定不同的服务承诺，如不同应用分组稳定性等级不同。
稳定性建设的评估体系
随着业务飞速发展，部署环境非常复杂，大系统和小系统在同一个机房部署是不可避免的，不同的系统对稳定性诉求其实是不一样的，这主要取决于业务的发展情况和成本控制，不可能一刀切以最高级稳定性要求每个系统。
某些系统（像交易）由于承载的业务量巨大，影响范围很广，因此必须要满足异地多活的容灾要求。但有些业务系统只需要做到同城双机房的容灾能力即可，刚起步的业务系统甚至只需要满足集群层面的稳定即可。我们需要对系统的稳定性能力加以辨别区分，从业务流量、部署结构、可靠性容灾能力建设三方面给系统准确的评分，配合于资源的申请、发布的控制，给业务系统提供量身定制的稳定性保障服务，故障演练为稳定性评估体系建设提供数据支撑。
故障管理的验证闭环
围绕故障生命周期有四个环节，分别是
发现、处理、复盘、验证，故障演练作为故障改进措施验证的有力手段，完善故障周期管理，提高系统稳定性的同时，反向又验证了复盘环节的效能，对改进措施是否有效是否缺失，流程机制是否合理，皆可实现量化管理。
服务治理
应用治理
根据应用对应故障点等级、发布情况、是否外部应用等对应用划分等级，然后针对性进行治理。
智运营团队梳理标准如下：
- P0 面向外部用户并且能够产生P2以上故障的故障点
- P1 能够产生P2以上故障的故障点
- P2 面向外部用户业务的应用
- P3 近三个月有变更并且能够产生P3以下故障点的应用
- P4 发布频次均三个月一次以下，几乎不会产生故障的应用
- P5 待下线,待移交的应用
推动下线
- 对于待下线的应用，请及时下线，一般对于待下线应用都濒临无人维护无人关注的境地，但却存在出现问题的风险。
应用拆分
- 核心应用单元化
- 推动承载多个服务的核心应用进行拆分：如果存在一个服务承载了很多核心功能，服务数高达100+，如果它挂，很多应用都受影响，那这样的应用就属于高风险应用，需要尽快根据业务场景进行拆分。
非法应用
- 理论上所有应用准确来说是所有的变更，都应该可灰度、可监控、可回滚
- 检查是否存在不可灰度、不可回滚，没有接入changefree的应用，此类应用是违法乱纪应用，贸然发布出了问题就是触发研发红线，后果极其严重
核心应用
- 核心应用支持弹性扩容，做最后的兜底
- 理论上建议承载P1、P2故障点的应用在有资源的情况下都升级高配机
- 长时间未发布（2/3个月）：定时进行重启
- 定时检查线上水位，保证维持在一个正常水位
慢SQL治理
这个就专门开一篇文章讲。