企业运维保障体系最佳实践Word文件下载.docx

企业运维保障体系最佳实践Word文件下载.docx

《企业运维保障体系最佳实践Word文件下载.docx》由会员分享，可在线阅读，更多相关《企业运维保障体系最佳实践Word文件下载.docx（12页珍藏版）》请在冰豆网上搜索。

在刚刚过去的双十一，每秒订单创建的峰值达到32.5万笔，每秒支付峰值达到25.6万笔。

相比2016年的17.5万笔和12.5万笔提升近80%。

相比去年的紧张状态，我们今年收到的普遍反馈是比较平稳。

同时，做为阿里巴巴双十一备战的一员，双十一当天切身感受到，喝着茶就把今年的双十一给过了的感觉。

并且业务上也再创新高，达到了1682亿，这是一个非常不容易的技术新高度。

如上图所示，阿里巴巴业务迅速扩展，对于稳定性保障来说非常有挑战性。

从基础架构层面来看：

我们需要保障IDC，网络基础设施，安全，阿里云、阿里通信和钉钉；

从业务层面来看，我们需要保障天猫、淘宝、手淘、蚂蚁金服、AE、飞猪、阿里妈妈、搜索；

以及近期迅猛发展的新零售、大文娱业务，如盒马鲜生，村淘、云零售、优酷、阿里影业、阿里健康等。

今年9月28日，新零售盒马鲜生做了五城十店同开活动，一般来说开一家超市成本很高，而互联网的速度却是，可以一下子开起来，当然盒马鲜生不是就满足于一天可以开10个店的速度，未来是百家店、千家的店的速度。

10月份，阿里云马来西亚区开服。

用不到1年时间，完成数据中心的新建。

并且马来西亚数据中心，也刚好是马老师E-WTP（ElectronicWorldTradePlatform，电子世界贸易平台）真实的落地，速度确实非常快。

11月份，在双十一活动上，有超过100万台天猫精灵智能音箱的售卖。

人工智能业务的发展尚是如此迅猛，而我们也紧跟着业务在思考，人工智能算法的稳定性应该如何去衡量。

从各个维度看，阿里当前的业务面很广、层次很深，因此很难做统一的一致的运维保障方案。

所以，问题就在于，在这样的情况下作为一个目标是要对接整个阿里经济体线上业务稳定性的一个团队来说，GOC应该如何去做。

昨天，魔泊云的副总裁ChristChen在分享中提到，他在2001年经历了一个非常大的故障，原因是一个运维误操作把一个DB搞挂了，而整个Cisco线上会议的服务也就挂了。

当时间滑到16年后，2017年2月28日B厂也因为30分钟无法通过WAP访问的故障导致被约谈；

此外，AWS因一位工程师误操作，导致整个美东一大片区域AWS不可访问。

随着时间，业务复杂度一直在增加，但导致线上故障发生的原因往往没怎么变。

因此，需要我们在万变之中找不变，找到运维保障的钥匙。

随着越来越多的新技术，新业务不断涌现，我想这会是一个新的阶段，这个阶段是一个非常不容易达到的技术广度，而在该技术广度上，无论是人工智能算法、还是大规模基础设施，稳定性运维保障都已经成为一个很难的课题。

当双11办到了第9年的今天，天猫双十一已经成为了互联网的一个超级工程，“超级工程”是一个新的概念。

除了大家熟悉的下单、支付这样的一些场景外，这个超级工程里面还包含了很多新技术，包括客服、搜索，推荐，广告，库存，物流等等。

而这些是所有阿里工程师每天不断创新突破的力量，这是非常不容易的技术速度。

这里面为大家介绍2个点，正好是我们团队做的。

一个是Changefree系统，基于机器智能的changefree保证线上变更有迹可循。

它通过对变更数据进行全文检索加自定义规则引擎，辅以机器学习的手段来自动统计分类，快速定位故障。

这些是官方的表述，但是同比故障的恢复时间我们能够检验得出来，可以提升65%，这是个非常难得的事情。

另一个是时间序列的异常检测算法，基于智能基线的时间序列异常检测算法具有自动学习、自动化监控业务和预警的能力，有了它，业务指标监控的准确率从传统监控策略的40%左右提升到80%。

这2个光荣的上了我们新技术的榜，却是是很难的点。

讲完了现状和挑战之后，我想带大家一起回过头思考一下。

当我们站在这样的一个技术高度、广度以及速度的时候，线上业务的稳定性、连续性以及运维保障方案有没有不同。

当出现故障的时候，或者频繁出现故障的时候，如何保障用户的使用不受影响或者受影响的程度可以降到最低。

二、运维保障体系介绍

我们阿里巴巴的运维保障体系也不是凭空起高楼，也是慢慢迭代出来的，主要学习这两个体系：

一个是ITIL，一个是业务连续性管理，也就是BCM，ISO22301。

我们的运维保障体系，也是脱胎于此。

ITIL侧重于流程和服务，能很好地建立服务目录，但在深度使用过程发现略冗长，不太适合互联网的精益迭代。

GOC最初刚成立的时候，主要是用ITIL，但是随着业务稳定性诉求的不断的更新以及优化和不断增长的时候，需要自建的诉求就自然而然来了。

总的来说，我们希望流程可以再轻便、高效一点，服务之间不再是孤岛，希望服务之间是为了同一个目标，比如：

故障快速恢复。

通过这样一个简单的目标，我们能够去把服务/产品打通，打透。

业务连续性管理，提到业务连续性管理，往往会同灾难恢复一起讲，英文称为BC&

DR（BusinessContinuityandDisasterRecovery）。

一般提到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分钟是几百万的损失，其实影响面是很大的，但是我们觉得在业务低峰期搞搞演练，让大家一直保持对生产环境的警惕，是很有必要的。

这个项目的代号叫虎虎虎。

2、故障发现

这个部分我也提3点：

一个是业务监控。

我相信不同团队、不同公司会有不同的理解。

甚至东西方也有很大的区别，在国外主要用servicelevelagreement，在阿里巴巴主要从用户视角来看业务，比如业务是否不可用，用户体验是否变差。

如果有，那我们就划出4级来，然后告诉你这是风险非常高的级别，那么你必须要做好限流，必须做好降级，必须做好容灾。

这样做，逼着你时刻在关键的功能点或接口上做好日志记录或者做好链路信息上报，从而形成业务日志监控。

业务监控是监控的一种，但核心跟用户体验息息相关的故障等级定义相关联。

这在阿里巴巴特别有用。

例如交易下跌10%，这是2010年定的，已经七年了，一旦发生交易下跌10%，系统稳定性偏低的团队会比较紧张，怕是自己导致的，尽快响应并恢复，否则时间久了，就会发酵成更大的问题。

大家都认同业务监控的重要性，也是我们能够集中力量去恢复很多复杂故障的一个很好的点。

全维度监控，就是说从各个维度上，比如IDC、网络、应用、系统和业务层面。

业务层面我们也分，不是所有的接口都是很致命的接口，有时候我们也会降级。

比如双十一时，会把购物车里面否已收货的状态接口降级掉，你就暂时看不了，但是不会影响你下单和支付。

最后智能监控，核心是为了解决报警不准的问题，一般来说，新上的业务，该业务点很关键，但是量不大且经常抖动，这时候，设置告警阈值会很痛苦。

GOC主要通过智能监控来解决这个问题，通过算法计算基线，然后自动预测异常，而报警可以只设一个相对于预测基线的水位有没有下跌即可，非常方便，而且准确。

这可以帮我们省掉很多问题，因为业务根据其特性在某些情况下往往会有较大的波动，比如10点钟聚划算有活动，肯定会往上涨，中午大家都在吃饭的时候，支付宝肯定会涨，淘宝会跌，周末的量比周一到周五的量大。

这种东西你配一个死的阈值很难搞定，智能监控是比较好的，我们这边使用范围很广。

3、应急响应

为什么会有这个智能，GOC做了非常有挑战的事情，做724小时应急。

一个互联网公司不该设这样一个传统的职位。

大家小区里面门卫是724小时的，我们就相当于是阿里巴巴这些生产系统门卫。

真的是7*24小时去支持我们线上的故障。

当然解决这个问题，我们也想了一个办法，其实这个也是我们从一些前辈的公司学到的，谷歌公司他们也是这么做的。

他们分公司特别多，总是可以找人换过来，goo