双11幕后超级英雄：新一代运维的价值

“双十一”刚刚结束，其实最紧张的不是商铺理货，也不是网友紧盯大促商品准备秒杀，而是网购幕后的运维人员，他们最担心：什么网络中断、应用卡顿、响应速度慢，服务器宕机……

双十一作为电商 IT 部门的头等大事，大促前，运维人员就需要早早地做好多套预备方案，并时刻紧绷着神经，经历着上百次模拟演练。他们在后端有多少不眠不休的夜晚，不得而知。几年前，一场秒杀让服务器宕机是常态，现在，一秒数十万的订单，服务器依然坚挺。毫无疑问，支撑起这一切的是强有力的技术和运维人一个个不眠的夜晚。

看似简单的双十一背后牵扯到是包括支付、架构、数据库、网络、运维、电力、客服、物流等整个商业配套基础设施的协同和考验。

双十一大促的那些年 运维迈过的坑

天猫双十一大促最早开始于 2009 年，那时候还是淘宝商城，一天的 GMV 只有几千万，而且还没有零点全民疯抢的概念。在大促前工程师们基本上会根据各自的经验判断，比如服务器的当前负载、应用的当前 RT 和 QPS，判断每台服务器最大能支撑多少能力等，然后几个人讨论后就决策拍板，某某核心应用各自要加多少台服务器，到底要加多少服务器，实际上大家的心里没底，实在不放心临时再多申请扩容。总之这个阶段业务量也小，也能应付过去。

后来几年随着天猫品牌的提升，双十一大促逐年爆发，原来的运维方式已经无法适用。业务发展迅速，后端的应用数量也大大增加，各个应用系统之间的调用链路错综复杂。大促前到底要准备扩容多少资源？不能拍脑袋热，因为你申请资源太多会可能被拒绝，申请少了你要承担更大的风险。这时候用线上压测的方式来解决，比如可以直接在生产环境抽取 1 台服务器，通过模拟回放或者直接引入多倍流量做压测，根据压测结果计算出单台服务器的最大可承载能力，然后用数字来说话，去申请扩容。还有就是即使容量规划做到位了，但在零点峰值的时候还是可能会超出预期，系统还是会挤爆。所以又引入了限流和降级，限流就是对各个应用设置一个最大阈值，超过阈值就立刻拒绝新的请求，这样的好处就是保护应用，避免雪崩。还有就是降级，由于应用太多，在大促的期间，可以关闭部分非核心功能，保证交易主流程的能力最大化。那个阶段的压测也不是完全精确的，主要问题是压测的局限性，只是对某个应用做单独压测，但是应用之间是有依赖有关联的，特别是一些共享服务中心，基本上被所有应用都依赖调用，那怎么办呢？后来几年时间又研发出新的压测工具，全链路压测。这个对于容量规划来说，是全新的思路，直接在生产环境上通过模拟复制产生大批的流量，每个环节都会被压测到，并有相应的监控系统配套，来找出瓶颈点在哪里，并迅速优化。而且这个过程被自动化完成。

我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。

 

可见，自动化运维是大势所趋。

零点疯抢背后的运筹帷幄

现在的电商双十一大促活动仍旧延续零点疯抢模式，对于应用系统保障来说，能否顺利扛过前 15 分钟，甚至是前几分钟，成为最核心的保障任务。运维界大咖给出了以下几点建议：能否顺利扛过前 15 分钟，甚至是前几分钟，成为最核心的保障任务。具体给出了以下几点建议：

a. 容量规划。 尽可能在生产环境做压测，只有经历过压测，心里才会有底。

b. 关键应用要支持限流。 零点全民疯狂的流量很可能会超出预期，只有设置好限流才能保护好自身应用，否则出现雪崩式连锁反应。

c. 对非核心功能做降级。 每次双十一会投入大量的资源，基本会往核心交易类应用倾斜，那么非核心功能的降级一定程度上是可接受的。

d. 应急预案。 对可能发生的异常状况提前准备。

双十一大促是最典型的弹性场景

弹性是云计算的最大优势，而大促是最典型的弹性场景。

随着云计算特别是公有云的普及，现在的运维人员基本上无需关注机房、网络、操作系统等底层设施。在不断地演练后，如今的电商平台早已采用弹性可扩展的云计算平台，配合分布式数据，高效的 CDN 分发来实现负载均衡，避免在双十一凌晨高并发状态下崩盘。运维人员将更多精力转移到快速上线，快速迭代，去支持业务发展。

大促活动的流量跟日常完全不在一个量级，完全可以利用云资源的按需使用，来达到扩容的需求，而且在成本上是巨大的节省。除了扩容以外，当然还需要准备应急预案。整理出当天可能出现的异常情况，提前预演。

去年天猫双十一开场仅仅十分钟，世界支付纪录被再次刷新。支付宝公布的数据显示，在零点 9 分 39 秒，支付宝的支付峰值达到 12 万笔／秒，是前年的 1.4 倍，刷新了去年创下的峰值纪录。在支付方式的选择上，花呗和余额宝成为非常受网友欢迎的支付方式，笔数占比分别高达 29% 和 18% 。

经得起巨额交易，玩得起光速秒杀，技术系统抗得住，收益率流动性各种稳妥……只有经得起双十一的终极考验的才算是真正的神器！

智能运维要借助数据和算法才能实现

运维的发展阶段经历了从标准化、工具化、自动化、到现在初露端倪的智能化，每个阶段的发展都代表了生产力和效率的大幅提升，整个趋势是不可避免的。智能时代的运维不是要让运维人员失业，而是对运维效率的提高有着极大的诉求，比如如何在错综复杂的环境中快速定位问题、root cause、甚至是故障预测，避免发生故障，保障应用稳定性。

智能运维要借助数据 (运维数据) 和算法才能实现。首先运维能力的发展不是直接跳到智能运维阶段的，必然经过标准化、工具化、到自动化的发展过程，只有高度完善的自动化才具备基础能力。其次就是数据积累，需要大量的运维数据，可以是日志数据、网络抓包数据、数据库数据等等。还有日常运维产生标注的数据，比如出一次故障后，运维人员会记录下过程，这个过程会反馈到系统，反过来提升运维水平。最后就是算法，到底采用哪类算法模型做持续优化。

天弘基金在运维部门希望通过服务器性能日志采集分析，实时监控应用系统基础资源的使用情况，通过采集客户端 Agent 收集服务器和集群组件的 CPU、内存使用率，以可视化形式展示资源运行状况。

据悉，天弘基金云日志平台项目已开始进行内部推广，在系统正式运行期间得到了用户认可，对用户的具体价值体现在以下几个方面：

运维人员：数据脱敏功能帮助运维人员解放人力；采集资源管控功能可以防止 Agent 程序对服务器和应用产生影响，有效避免灾难性故障发生。

研发人员：日志查询功能可方便快捷的查询日志文件；调用链分析帮助研发人员快速定位故障原因和问题点，协助研发团队优化系统代码并进行架构治理。

业务人员：监控告警功能可及时发现业务故障，最大程度上降低故障响应时间，提升用户服务体验。

管理人员：智能运维可实时掌握服务资源运行情况，并能够预测集群水位，提供基础资源扩容建议。

 

阅读原文请点击: