e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

运行无间:阿里巴巴运维保障体系的一种最佳实践

2018/1/20    来源:运维派    作者:吴昌龙      
关键字:阿里巴巴  运维保障  
阿里巴巴全球运行指挥中心,GOC (Global Operations Center)保障阿里经济体的业务稳定运行的核心团队。我们负责了整个阿里巴巴全局生产系统的稳定性。就像业界经常提到谷歌的SRE,我们相当于阿里巴巴的SRE。
    前言
 
    阿里巴巴全球运行指挥中心,GOC (Global Operations Center)保障阿里经济体的业务稳定运行的核心团队。我们负责了整个阿里巴巴全局生产系统的稳定性。就像业界经常提到谷歌的SRE,我们相当于阿里巴巴的SRE。
 
    今天我的分享分为四个部分:
 
    1、稳定性现状及挑战
 
    2、运维保障体系介绍
 
    3、运行无间最佳实践
 
    4、未来的发展及方向
 
    一、稳定性现状及挑战
 
    提到阿里巴巴,不得不说刚刚过去的双十一。在刚刚过去的双十一,每秒订单创建的峰值达到32.5万笔,每秒支付峰值达到25.6万笔。相比2016年的17.5万笔和12.5万笔提升近80%。相比去年的紧张状态,我们今年收到的普遍反馈是比较平稳。
 
    同时,做为阿里巴巴双十一备战的一员,双十一当天切身感受到,喝着茶就把今年的双十一给过了的感觉。并且业务上也再创新高,达到了1682亿,这是一个非常不容易的技术新高度。
 
    阿里巴巴
 
    如上图所示,阿里巴巴业务迅速扩展,对于稳定性保障来说非常有挑战性。从基础架构层面来看:我们需要保障IDC,网络基础设施,安全,阿里云、阿里通信和钉钉;从业务层面来看,我们需要保障天猫、淘宝、手淘、蚂蚁金服、AE、飞猪、阿里妈妈、搜索;以及近期迅猛发展的新零售、大文娱业务,如盒马鲜生,村淘、云零售、优酷、阿里影业、阿里健康等。
 
    今年9月28日,新零售盒马鲜生做了五城十店同开活动,一般来说开一家超市成本很高,而互联网的速度却是,可以一下子开起来,当然盒马鲜生不是就满足于一天可以开10个店的速度,未来是百家店、千家的店的速度。
 
    10月份,阿里云马来西亚区开服。用不到1年时间,完成数据中心的新建。并且马来西亚数据中心,也刚好是马老师E-WTP(Electronic World Trade Platform,电子世界贸易平台)真实的落地,速度确实非常快。
 
    11月份,在双十一活动上,有超过100万台天猫精灵智能音箱的售卖。人工智能业务的发展尚是如此迅猛,而我们也紧跟着业务在思考,人工智能算法的稳定性应该如何去衡量。
 
    从各个维度看,阿里当前的业务面很广、层次很深,因此很难做统一的一致的运维保障方案。所以,问题就在于,在这样的情况下作为一个目标是要对接整个阿里经济体线上业务稳定性的一个团队来说,GOC应该如何去做。
 
    昨天,魔泊云的副总裁Christ Chen在分享中提到,他在2001年经历了一个非常大的故障,原因是一个运维误操作把一个DB搞挂了,而整个Cisco线上会议的服务也就挂了。当时间滑到16年后,2017年2月28日B厂也因为30分钟无法通过WAP访问的故障导致被约谈;此外,AWS因一位工程师误操作,导致整个美东一大片区域AWS不可访问。
 
    随着时间,业务复杂度一直在增加,但导致线上故障发生的原因往往没怎么变。因此,需要我们在万变之中找不变,找到运维保障的钥匙。
 
    随着越来越多的新技术,新业务不断涌现,我想这会是一个新的阶段,这个阶段是一个非常不容易达到的技术广度,而在该技术广度上,无论是人工智能算法、还是大规模基础设施,稳定性运维保障都已经成为一个很难的课题。
 
阿里巴巴
 
    当双11办到了第9年的今天,天猫双十一已经成为了互联网的一个超级工程,“超级工程”是一个新的概念。除了大家熟悉的下单、支付这样的一些场景外,这个超级工程里面还包含了很多新技术,包括客服、搜索,推荐,广告,库存,物流等等。而这些是所有阿里工程师每天不断创新突破的力量,这是非常不容易的技术速度。
 
    这里面为大家介绍2个点,正好是我们团队做的。一个是Changefree系统,基于机器智能的changefree保证线上变更有迹可循。它通过对变更数据进行全文检索加自定义规则引擎,辅以机器学习的手段来自动统计分类,快速定位故障。这些是官方的表述,但是同比故障的恢复时间我们能够检验得出来,可以提升65%,这是个非常难得的事情。
 
    另一个是时间序列的异常检测算法,基于智能基线的时间序列异常检测算法具有自动学习、自动化监控业务和预警的能力,有了它,业务指标监控的准确率从传统监控策略的40%左右提升到80%。这2个光荣的上了我们新技术的榜,却是是很难的点。
 
    讲完了现状和挑战之后,我想带大家一起回过头思考一下。当我们站在这样的一个技术高度、广度以及速度的时候,线上业务的稳定性、连续性以及运维保障方案有没有不同。当出现故障的时候,或者频繁出现故障的时候,如何保障用户的使用不受影响或者受影响的程度可以降到最低。
 
    二、运维保障体系介绍
 
    保障体系
 
    我们阿里巴巴的运维保障体系也不是凭空起高楼,也是慢慢迭代出来的,主要学习这两个体系:一个是ITIL ,一个是业务连续性管理,也就是BCM,ISO 22301。我们的运维保障体系,也是脱胎于此。
 
    ITIL侧重于流程和服务,能很好地建立服务目录,但在深度使用过程发现略冗长,不太适合互联网的精益迭代。GOC最初刚成立的时候,主要是用ITIL,但是随着业务稳定性诉求的不断的更新以及优化和不断增长的时候,需要自建的诉求就自然而然来了。
 
    总的来说,我们希望流程可以再轻便、高效一点,服务之间不再是孤岛,希望服务之间是为了同一个目标,比如:故障快速恢复。通过这样一个简单的目标,我们能够去把服务/产品打通,打透。
 
    业务连续性管理,提到业务连续性管理,往往会同灾难恢复一起讲,英文称为BC&DR(Business Continuity and Disaster Recovery)。一般提到BCM,经常会举2013年东南亚海啸的案例,海啸发生后,某某银行受到了严重影响,从结果看,一周内能否恢复营业,若恢复,说明基本不受影响;但如果1个月才能恢复营业,说明他很有可能需要长达3-5个月的时间来停业整顿;如果2个月还不能恢复,那这个银行距离倒闭的时间就不远了。
 
    传统行业对于业务连续性的诉求,在互联网行业,往往更苛刻,可能10到15分钟,这个业务就很难了。BCM有一个特征,其实它原先画了很多,我们理解BCM是设计一套针对不频发,但确是大灾难的场景下,如何保证业务的连续性。
 
    其实对于互联网行业来说,需求多,变更快,故障是非常频繁的事情,影响面对于业务来说也很大,所以我们希望在BCM里面,加入一些持续优化的因素,而这个ITIL里面是有的。我们把这两个东西结合一起。
 
    保障体系
 
    阿里巴巴的运维保障体系,说白了很简单。这是精减版的草图,简单来说就是全生命周期围绕故障,形成体系闭环,持续改进以及快速的产品支撑落地。
 
    1.故障防范
 
    当公司没开的时候,比如我们明天准备开淘宝了,这时我们可以很轻松地坐在一起,把规范定出来,故障防范的约束定出来。但是很多时候业务起来了,我们还没有及时介入,所以说故障的闭环很可能是业务的已经在做或者稳定性做的不太好的时候,GOC再切入进去。
 
    在故障防范的阶段,GOC重点关注3个点:一个是数据运营;一个是平台管控;一个是日常演练。
 
    首先,看看数据运营。在阿里经济体所有业务中,无论是相似业务还是完全不同业务的稳定性情况,可以简单比较下各个BU稳定性的情况,可以给出一份稳定性建议报告。当具体到某个BU、某条业务线的时候,我们可以具体分析他们的稳定性情况:与去年同比故障数有无增减;故障中多少比例是监控发现的,还是等用户打爆投诉电话后,才慢慢上来处理的;有多少比例的故障是人为失误、变更等形式导致的。
 
    此外,是平台管控。核心产品是ChangeFree,他是阿里巴巴做变更管控非常好的平台,基于数据运营。现在很多故障刚刚发生的时候,变更人还不知道什么情况的时候,几分钟时间就已经发生过一个故障,但通过快速回滚恢复掉了。
 
    这中间有两个点:
 
    第一个点,看变更能否发到线上,期间会有一系列的管控,通过很严格的变更红线来衡量线上变更。
 
    第二个点,看变更到线上后是否符合预期,这是非常关键的点。符合预期不是说是否符合变更人的预期,而是指他是否符合不影响线上业务的预期,这是客户最在乎的,也是我们GOC最关注的。
 
    比如某团队做了一个非核心的边缘变更,但这个变更通过几层链路的传导,可能会传到电商交易的核心链路,那么整个交易就会被阻塞掉,阿里发生过这样的案例。
 
    当出现这种情况,你会发现,没有很好的平台支撑,你是很难找到引发这个故障的具体变更。因为从出问题的点往上回溯的时候往往是最难的,GOC通过大量实际案例,以及算法同学们的努力,我们现在能够解决一些这样的问题。
 
    日常演练我们提日常,经常会有一个反问句,这个也是我在SRE读到的,你到底是愿意圣诞节晚上和老婆、孩子看电视享受节日的时候,突然故障发生了,还是愿意在演练的时候,所有人都在一起,大家来模拟故障,故障一发生大家快速处理,我会选后者。演练很重要,而且需要频繁做,要把他当作日常的事情来做。阿里巴巴这边我们演练就是老板非常看中这个事情。
 
    我们2015年发生过一个527事件,影响特别不好,我们后来通过技术来避免这个问题,叫异地多活和一键切换。但是这个工具是否每时每刻都是有效的,毕竟它的依赖很多,而且它所依赖的东西会因为一些需求的变化而更新。
 
    后来,大老板给我们出了一个难题,让准备一个核按钮,随时都可以按,按一下一个机房就挂了,这是人为造成的而且事先不告诉你,这把我们GOC训练地很警惕。
 
    我们有值班体系,7*24小时值班,这样大老板早上一时兴起就按一下,一个机房挂了,GOC赶紧一键切换掉,然后业务恢复。期间也就1分钟、2分钟。若是交易挂了的话,1分钟是几百万的损失,其实影响面是很大的,但是我们觉得在业务低峰期搞搞演练,让大家一直保持对生产环境的警惕,是很有必要的。这个项目的代号叫虎虎虎。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐