业务系统核心目标是挣钱，系统稳定性建设核心是防止丢钱（丢钱逻辑如下图所示），站在公司的角度看，产品功能建设和系统稳定性是同等重要。
前段时间写了《 稳定性治理框架 》，该文章在稳定性建设的理论和实践基础上，抽象出稳定性治理的框架，希望建立一个稳定性治理的标准动作、最佳实践。但从读者的反馈上看，有过类似经验的同学深同感触，经验不足的同学没啥感觉，导致这个结果的原因，我反思了一下，认为：概念太粗，落地容易变形。于是，想写一篇文章，把稳定性最重要的东西写出来，于是有了这篇文章。
通常，导致线上事故的最大诱因是“变更”，“可灰度、可监控、可回滚”的方法论，目标就是降低变更引发的线上事故，其逻辑是：首先，通过灰度手段让变更可控，从0%的影响逐渐放量到100%影响；其次，通过监控手段观察变更是否准确，如果准确了，灰度放量才能继续；最后，如果出现不可控的情况，能够立刻回滚，立刻止损，避免长时间影响客户。
一、可灰度
可灰度是指线上变更能够支持灰度发布，百度百科对对灰度发布的定义是：灰度发布又名金丝雀发布，指在黑与白之间，能够平滑过渡的一种发布方式。 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
各大厂常用的灰度发布种类有：机器灰度、AB灰度、链路灰度、沙箱灰度等，下面展开讲解：
•机器灰度
一个应用一般会部署多台机器，流量大的应用机器甚至50台以上，先上一台观察是否正常，验证通过后再上其他机器，这个过程叫机器灰度。这种灰度的优劣势如下：
优势 劣势 简单，几乎没有开发成本和学习成本。 ①验证难道大，难以将验证过程的请求打到“新上线的机器”上； ②存在小规模故障风险，“新上线的机器”如果有bug，会小规模影响线上业务。•AB灰度
线上的代码成为A分支，待上线的代码成为B分支，通过请求中的某个参数（如用户ID等）与配置中心（如DUCC等）的配置进行比对，命中则走B分支，不命中则走A分支，这种灰度叫AB灰度。
伪代码如下：
……………………………………………………………………………………………………
…………………………………………原代码……………………………………………
……………………………………………………………………………………………………
void function(long userId){
/**
新需求，此处要求修改逻辑
*/
call methodA();
do something;
}
void methodsA(){
do something
}
……………………………………………………………………………………………………
…………………………………………新代码……………………………………………
……………………………………………………………………………………………………
private List<Long> config = new ArrayList();
void function(long userId){
/**
灰度控制，仅指定的用户进入新逻辑
*/
if(config.contains(userId)){
call methodA_new();
}else{
call methodA();
}
do something;
}
void methodsA(){
do something;
}
void methodsA_new(){
do something;
}
优劣势分析：
优势 劣势 ①比较简单，5分钟就可以学会。 ②可以指定用户验证，先验证测试账户，再验证小流量商户，再逐渐放量，可避免线上故障。 ①难以应对复杂需求，假设一个需求改动100个方法，通过AB灰度控制就显得很乱了； ②需要上2次线，第一个加灰度控制，第二次去灰度控制。其他重要说明：
AB灰度一定要控制好放量的节奏，而且每次放量都需要经历“自测”和“线上高峰期”验证，放量节奏的最佳实践是：测试商家 -> 1个商家 -> n个商家 -> 1% -> 5% -> 10% -> 30% -> 100%。
•全链路灰度
线上的代码是默认链路，新代码是灰度链路，给小部分流量染色，让染色流量走到灰度链路，这个过程叫全链路灰度。全链路灰度的示意图如下：
优劣势分析：
优势 劣势 ①容易验证，by功能的灰度验证过程，研发能够很方便去验证是否符合预期；②代码侵入少，相对AB放量代码要简洁很多，也无需二次上线。 ①需要依赖公司的基建能力，小团队难以搞定，比如对于京东，需要JSF平台、JMQ平台分别支持流量染色能力，以支持同步和异步调用。其他重要说明：
在研发、测试过程中，经常发现环境不够用的情况，链路灰度的愿意应用到测试环境上，叫做“泳道环境”。举个例子：一个系统有100个应用，如果要部署5套环境，至少需要1005=500台机器，利用泳道环境，仅需要部署一套主干环境，用到100台机器，假设每个新环境仅改动到2个应用，那总机器数是100+24=108，大大降低机器成本和时间成本。
•沙箱灰度
沙箱的概念在杀毒软件上用的比较多，杀毒软件会搞一个虚拟环境（类似虚拟机），然后将可疑文件放到虚拟环境中运行，然后分析是否有不安全的特征，协助判断是否是病毒、木马。
在互联网的应用上，变更是导致线上故障的元凶，因此，希望有个类似沙箱的环境，将线上流量引入到该环境进行验证（又不对线上造成影响），验证没问题后，再执行上线。
在百川系统上，大家做的AB对比，实际上就是沙箱环境，搭建了一个沙箱环境成为A环境，线上环境成为B环境，流量A环境、B环境运行的结果做对比，对比结果准确，才执行上线。
二、可监控
监控很重要，它是研发了解线上应用的窗口，其重要性可比眼睛对人的重要性。当系统监控不完善，研发就不能先于客户发现问题，研发的专业度就体现不出来，其实是一种耻辱。
对互联网公司来讲，监控不仅仅是机器监控，而是包括机器监控、链路监控、网络监控、业务监控等全方位监控，我们可根据应用的重要性配备上不同的监控系统，以便及时发现和处理线上故障。下表总结了京东在每个方向上存在的监控系统：
分类 说明 监控平台&官网 推荐 主机监控 针对机器的监控，包括cpu、内存、网络等 mdc 、统一管控平台、brolly控制台、火眼 mdc 进程监控 监控jvm进行，比如CPU、FullGC、yongGC等 ump、pfinder、sgm ump 性能监控 监控rpc性能，比如tp99、sla、调用量等 ump、pfinder、sgm、thor ump 链路跟踪 根据tranceId查询到一个请求链路的所有节点，包括rpc调用，db等中间件调用等。 pfinder、sgm、cat pfinder 日志监控 监控应用运行过程的日志 logbook、 digger logbook 网络监控 针对网络的监控 NP、DNP网络监控 NP 数据库监控 针对数据库的监控，包括cpu、load、磁盘利用率等指标 易维、CleverDB、noah平台、myops、DBS、数据库智能诊断系统、火眼 易维 中间件 针对redis、mq等中间件平台的监控，默认都需要开启并使用。 JSF 、JMQ2、JMQ4、蜂巢、dap、clove、物流网关 每个中间件平台的监控，都需要使用 业务监控 针对业务的监控，比如可以监控订单的同比、订单未闭环、对账场景等。 前哨 前哨 安全监控 针对安全的监控 神盾 神盾 web端监控 针对web端的监控，比如监控方法的端到端性能、比如埋点等 DEEPLOG 、子午线、烛龙、Watchtower、sgm-console-web、奇点 deeplog、子午线 app端监控 针对app端的监控，包括性能监控、crash监控等 SGM（移动端）、子午线、shooter、鹰眼 crash、奇点、烛龙 SGM（移动端）、子午线 大数据 针对大数据的使用和监控平台 dp、bdp、烽火台、imonet、京东动力 dp对于监控来讲，核心指标是“漏报率”和“误报率”，而这2个指标是相互制约的，当把“漏报率”搞得极致则“误报率”会高，引发“狼来了”的现象，当把“误报率”搞到极致则“漏报率”会高，因此，需要平衡好这两个指标，可以这么定目标：误报率小于20%，漏报率小于20%。
三、可回滚
可回滚是兜底，谁也不能保障代码100%无bug，当线上出现问题时，“先止损，后查问题”是最佳实践，最快的止损方法是：灰度放量回滚，能够做到秒级恢复。但是，如果灰度放量回滚无法解决，那就需要触发兜底动作：回滚。
从个人情感角度出发，研发同学是不希望回滚的，但从客户角度出发，是不能接受线上长时间不可用，因此，可回滚是必须的，对线上的每一次变更，如果不能做到“可回滚”，是不可以上线的。
可回滚，绝对不是简简单单的操作应用回滚，而是要从多个角度评估是否可回滚、回滚后需要做什么，包括：
•应用回滚
应用是否可以操作回滚，如果涉及多个应用，回滚的顺序是什么等。
•数据库DDL回滚
数据库表的DDL是否需要回滚，如果需要，回滚时长多久、回滚期间会不会造成更大影响等。
•数据回滚
新逻辑产生的数据，回滚后是否兼容，是否需要修复数据，修数据的方案是什么等。
•其他
回滚还需要考虑哪些个性化的影响。