开发者社区 > 博文 > 稳定性方法论:可灰度 & 可监控 & 可回滚
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

稳定性方法论:可灰度 & 可监控 & 可回滚

  • 13****
  • 2024-02-23
  • IP归属:北京
  • 4200浏览

       业务系统核心目标是挣钱,系统稳定性建设核心是防止丢钱(丢钱逻辑如下图所示),站在公司的角度看,产品功能建设和系统稳定性是同等重要。

    前段时间写了《 稳定性治理框架 》,该文章在稳定性建设的理论和实践基础上,抽象出稳定性治理的框架,希望建立一个稳定性治理的标准动作、最佳实践。但从读者的反馈上看,有过类似经验的同学深同感触,经验不足的同学没啥感觉,导致这个结果的原因,我反思了一下,认为:概念太粗,落地容易变形。于是,想写一篇文章,把稳定性最重要的东西写出来,于是有了这篇文章。

    通常,导致线上事故的最大诱因是“变更”,“可灰度、可监控、可回滚”的方法论,目标就是降低变更引发的线上事故,其逻辑是:首先,通过灰度手段让变更可控,从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套环境,至少需要100*5=500台机器,利用泳道环境,仅需要部署一套主干环境,用到100台机器,假设每个新环境仅改动到2个应用,那总机器数是100+2*4=108,大大降低机器成本和时间成本。

    • 沙箱灰度

    沙箱的概念在杀毒软件上用的比较多,杀毒软件会搞一个虚拟环境(类似虚拟机),然后将可疑文件放到虚拟环境中运行,然后分析是否有不安全的特征,协助判断是否是病毒、木马。

    在互联网的应用上,变更是导致线上故障的元凶,因此,希望有个类似沙箱的环境,将线上流量引入到该环境进行验证(又不对线上造成影响),验证没问题后,再执行上线。

    在百川系统上,大家做的AB对比,实际上就是沙箱环境,搭建了一个沙箱环境成为A环境,线上环境成为B环境,流量A环境、B环境运行的结果做对比,对比结果准确,才执行上线。

    二、可监控

    监控很重要,它是研发了解线上应用的窗口,其重要性可比眼睛对人的重要性。当系统监控不完善,研发就不能先于客户发现问题,研发的专业度就体现不出来,其实是一种耻辱。

    对互联网公司来讲,监控不仅仅是机器监控,而是包括机器监控、链路监控、网络监控、业务监控等全方位监控,我们可根据应用的重要性配备上不同的监控系统,以便及时发现和处理线上故障。下表总结了京东在每个方向上存在的监控系统:

    分类说明监控平台&官网推荐
    主机监控针对机器的监控,包括cpu、内存、网络等mdc 、统一管控平台、brolly控制台、火眼mdc
    进程监控监控jvm进行,比如CPU、FullGC、yongGC等ump、pfinder、sgmump
    性能监控监控rpc性能,比如tp99、sla、调用量等ump、pfinder、sgm、thorump
    链路跟踪根据tranceId查询到一个请求链路的所有节点,包括rpc调用,db等中间件调用等。pfinder、sgm、catpfinder
    日志监控监控应用运行过程的日志logbook、 diggerlogbook
    网络监控针对网络的监控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是否需要回滚,如果需要,回滚时长多久、回滚期间会不会造成更大影响等。

    • 数据回滚

    新逻辑产生的数据,回滚后是否兼容,是否需要修复数据,修数据的方案是什么等。

    • 其他

    回滚还需要考虑哪些个性化的影响。

    文章数
    2
    阅读量
    724

    作者其他文章

    01 稳定性建设框架