“双十一”刚刚结束，其实最紧张的不是商铺理货，也不是网友紧盯大促商品准备秒杀，而是网购幕后的运维人员，他们最担心：什么网络中断、应用卡顿、响应速度慢，服务器宕机……
双十一作为电商 IT 部门的头等大事，大促前，运维人员就需要早早地做好多套预备方案，并时刻紧绷着神经，经历着上百次模拟演练。他们在后端有多少不眠不休的夜晚，不得而知。
看似简单的双十一背后牵扯到是包括支付、架构、数据库、网络、运维、电力、客服、物流等整个商业配套基础设施的协同和考验。
双十一大促这些年，运维领域迈过了哪些坑？智能化运维初露端倪的今天，企业又该如何布局？带着这些疑问，Info 采访了袋鼠云首席运维专家林杰，他此前支持过淘宝网，天猫，共享业务，无线事业手机淘宝，聚划算等 BU 业务运维，对运维领域有着自己独到的见解。
双十一大促这些年 运维迈过的坑
林杰回忆：天猫双十一大促最早开始于 2009 年，那时候还是淘宝商城，一天的 GMV 只有几千万，而且还没有零点全民疯抢的概念。在大促前工程师们基本上会根据各自的经验判断，比如服务器的当前负载、应用的当前 RT 和 QPS，判断每台服务器最大能支撑多少能力等，然后几个人讨论后就决策拍板，某某核心应用各自要加多少台服务器，到底要加多少服务器，实际上大家的心里没底，实在不放心临时再多申请扩容。总之这个阶段业务量也小，也能应付过去。
后来几年随着天猫品牌的提升，双十一大促逐年爆发，原来的运维方式已经无法适用。业务发展迅速，后端的应用数量也大大增加，各个应用系统之间的调用链路错综复杂。大促前到底要准备扩容多少资源？不能拍脑袋热，因为你申请资源太多会可能被拒绝，申请少了你要承担更大的风险。这时候我们是用线上压测的方式来解决，比如可以直接在生产环境抽取 1 台服务器，通过模拟回放或者直接引入多倍流量做压测，根据压测结果计算出单台服务器的最大可承载能力，然后用数字来说话，去申请扩容。还有就是即使容量规划做到位了，但在零点峰值的时候还是可能会超出预期，系统还是会挤爆。所以又引入了限流和降级，限流就是对各个应用设置一个最大阈值，超过阈值就立刻拒绝新的请求，这样的好处就是保护应用，避免雪崩。还有就是降级，由于应用太多，在大促的期间，可以关闭部分非核心功能，保证交易主流程的能力最大化。那个阶段的压测也不是完全精确的，主要问题是压测的局限性，只是对某个应用做单独压测，但是应用之间是有依赖有关联的，特别是一些共享服务中心，基本上被所有应用都依赖调用，那怎么办呢？后来几年时间又研发出新的压测工具，全链路压测。这个对于容量规划来说，是全新的思路，直接在生产环境上通过模拟复制产生大批的流量，每个环节都会被压测到，并有相应的监控系统配套，来找出瓶颈点在哪里，并迅速优化。而且这个过程被自动化完成。
可见，自动化运维是大势所趋。
零点疯抢背后的运筹帷幄
现在的电商双十一大促活动仍旧延续零点疯抢模式，对于应用系统保障来说，能否顺利扛过前 15 分钟，甚至是前几分钟，成为最核心的保障任务。林杰给出了以下几点建议：
a. 容量规划。 尽可能在生产环境做压测，只有经历过压测，心里才会有底。
b. 关键应用要支持限流。 零点全民疯狂的流量很可能会超出预期，只有设置好限流才能保护好自身应用，否则出现雪崩式连锁反应。
c. 对非核心功能做降级。 每次双十一会投入大量的资源，基本会往核心交易类应用倾斜，那么非核心功能的降级一定程度上是可接受的。
d. 应急预案。 对可能发生的异常状况提前准备。
双十一大促是最典型的弹性场景
弹性是云计算的最大优势，而大促是最典型的弹性场景。
随着云计算特别是公有云的普及，现在的运维人员基本上无需关注机房、网络、操作系统等底层设施。在不断地演练后，如今的电商平台早已采用弹性可扩展的云计算平台，配合分布式数据，高效的 CDN 分发来实现负载均衡，避免在双十一凌晨高并发状态下崩盘。运维人员将更多精力转移到快速上线，快速迭代，去支持业务发展。
大促活动的流量跟日常完全不在一个量级，完全可以利用云资源的按需使用，来达到扩容的需求，而且在成本上是巨大的节省。除了扩容以外，当然还需要准备应急预案。整理出当天可能出现的异常情况，提前预演。
去年天猫双十一开场仅仅十分钟，世界支付纪录被再次刷新。支付宝公布的数据显示，在零点 9 分 39 秒，支付宝的支付峰值达到 12 万笔／秒，是前年的 1.4 倍，刷新了去年创下的峰值纪录。在支付方式的选择上，花呗和余额宝成为非常受网友欢迎的支付方式，笔数占比分别高达 29% 和 18% 。
经得起巨额交易，玩得起光速秒杀，技术系统抗得住，收益率流动性各种稳妥……只有经得起双十一的终极考验的才算是真正的神器！
天弘基金基于日志数据分析的高效运维
对于天弘基金来说，如何确保余额宝在双十一的流动性和收益率平稳是一大挑战。
线上系统最常规的问题定位方式，就是日志分析了。接下来我们以余额宝为例，重点剖析天弘基金在日志数据分析领域是如何突破的？
此前，天弘基金一直使用开源的 ELK 日志方案，研发和运维人员通过 ELK 对日志数据进行处理，使用日志文件进行查询检索。随着应用场景的不断深入，以及内部人员需求的不断增加，天弘基金希望通过日志分析来解决运维和应用相关的新问题，在这方面，选择和袋鼠云合作。具体包括以下几个方面：
一、数据脱敏
天弘基金存有大量的个人用户信息，日志文件中都会保留个人和银行卡四要素信息，这些数据都属于个人隐私，原有 ELK 方案无法屏蔽这些敏感数据，不能从根本上解决问题。以往开发人员需要查看日志的时候，旁边都必须跟着一个运维人员，在运维人员的监督下才可以查看日志。仅仅在查日志这样一个简单过程中，都需要多浪费一个运维人员的时间，不仅协同工作效率低，且不能解放运维人员的监督工作。
袋鼠云日志数据脱敏功能，可以通过简单的设置解决这一问题。安全管理员选择日志文件中需要脱敏的字段，以表达式匹配的方式进行转换，系统将自动过滤转换成脱敏后的信息，同时，结合权限控制功能，对无权查看日志原文的用户自动屏蔽敏感数据信息。
金融客户对日志中的敏感数据进行脱敏是常见需求。诸如银行卡、身份证、手机号等等，标识用户身份的信息脱敏。袋鼠云日志除了支持这些常规数据的脱敏，还支持自定义脱敏规则。通过自定义脱敏规则，可以增量添加用户所需的任意脱敏规则。
二、采集资源管控
天弘基金所有线上业务的服务器资源，都必须保证 24 小时不间断对外提供服务，并且业务和应用程序都要保证高可用。任何外部程序或第三方应用都不能影响生产环境的稳定运行，所有部署在服务器上的程序，都不能对应用系统具有侵入性。同时，部署在服务器上的采集程序也要经过严格的压力和性能测试，确保采集程序不会对业务系统产生任何影响。
袋鼠云日志在产品设计之初就开始考虑如何最大程度降低日志采集客户端对服务器的影响。云日志通过对 Agent 采集程序的资源管控，从资源限制到异常终止提供安全保障。
第一层：资源限制
袋鼠云日志将 Agent 的运行占用资源进行严格限制，例如：CPU 占用率不能超过 5%，内存占用率不能超过 100M，带宽占用不能超过 500KB/s，该阈值可以通过页面自由定制。一旦资源限制开启，Agent 将会在该阈值允许范围内运行。如果有日志量暴增的情况发生时，Agent 也会自动进行资源抑制。
第二层：Agent 自刎
当发生极为特殊的状况，导致资源限制失效，Agent 占用资源超出设定阈值，袋鼠云日志的 Agent 会通过自刎机制将进程终止，充分保障业务系统的安全性。在系统稳定后，重启并恢复 Agent，可将之前遗漏的日志进行重新采集，保证日志数据不丢失。
三、调用链路分析
天弘基金的业务系统采用分布式架构设计，并引入蚂蚁金融云的 Sofa 框架进行开发，Sofa 框架可以通过配置来实现日志文件的生成，每个系统都生成大量的调用链路日志。这些日志原本没有利用价值，但通过日志分析可以发现，基于日志的分布式调用跟踪系统，其关键核心在于调用链，为每个请求生成全局唯一的 ID（Traceld），通过它将不同系统的“孤立的”调用信息关联在一起，还原出更多有价值的信息。
如何利用这些日志来帮助用户进行分析是云日志要解决的问题，经过一段时间对 Sofa 日志文件的研究，袋鼠云日志成功将其中的调用链路进行解析，以可视化的方式为用户呈现各中心之间的调用关系，以及接口的调用成功失败次数、调用耗时等关键信息。
调用链路具体的应用场景包括以下几个方面：
A. 定位异常统计耗时
通过调用链路在业务异常日志的错误信息中找到 TraceID，在系统中可以看到调用链中具体的情况，在调用链上更加直观地定位到问题，层层排查后确定问题的所在。
B. 调用链下钻报表
对于分布式调用跟踪系统而言，不仅仅提供调用链功能，同时可以监控所有中间件的具体情况。因此，在形成调用链的过程中也会形成一份详细的调用监控报表，与其他监控的不同之处在于：该监控报表是带有上下钻取功能。因为调用链可以形成各种维度的报表，不仅可以看到服务的情况，还可以查看其调用服务的情况，掌握清晰的调用链信息。
C. 全链路分析
全链路与调用链的区别是：全链路是一个应用全局的概念，而调用链是单体调用的过程。分析全链路的价值主要体现在以下几点：
链路拓扑形态分析： 通过应用之间的调用拓扑关系，分析调用过程的来源和去向，识别不合理调用来源；
依赖梳理和容量估算： 识别易故障点 / 性能瓶颈、接口出错率等问题；根据链路调用比例、峰值 QPS 评估容量；
研发和管理人员可以快速通过以上视图定位故障或问题节点，并通过节点查看详细的接口调用分析与统计数据，用户可以很方便的找出问题所在。
全链路分析跟踪的最大优势在于，所有分布式应用之间的关系都是透明的，每个交易或订单请求在日志分析的基础上，都可以进行追本溯源，无需人工进行协查，有效降低运维和研发人员的排障时间成本。
智能运维要借助数据和算法才能实现
运维的发展阶段经历了从标准化、工具化、自动化、到现在初露端倪的智能化，每个阶段的发展都代表了生产力和效率的大幅提升，整个趋势是不可避免的。智能时代的运维不是要让运维人员失业，而是对运维效率的提高有着极大的诉求，比如如何在错综复杂的环境中快速定位问题、root cause、甚至是故障预测，避免发生故障，保障应用稳定性。
林杰认为：智能运维要借助数据 (运维数据) 和算法才能实现。首先运维能力的发展不是直接跳到智能运维阶段的，必然经过标准化、工具化、到自动化的发展过程，只有高度完善的自动化才具备基础能力。其次就是数据积累，需要大量的运维数据，可以是日志数据、网络抓包数据、数据库数据等等。还有日常运维产生标注的数据，比如出一次故障后，运维人员会记录下过程，这个过程会反馈到系统，反过来提升运维水平。最后就是算法，到底采用哪类算法模型做持续优化。
天弘基金在运维部门希望通过服务器性能日志采集分析，实时监控应用系统基础资源的使用情况，通过采集客户端 Agent 收集服务器和集群组件的 CPU、内存使用率，以可视化形式展示资源运行状况。
而袋鼠云智能运维解决方案基于自研的数据库管控、日志分析和大数据平台，可为天弘基金 (余额宝) 提供整体的运维解决方案。目前一期已接入数十个核心应用，服务器规模数百台，日志数据日增量达到 T 级规模，帮助其实现了日志集中管理、日志分析、业务全链路、故障定位、数据脱敏等应用场景。故障发现、定位及恢复效率大大提高，提升系统稳定性。
据悉，天弘基金云日志平台项目已开始进行内部推广，在系统正式运行期间得到了用户认可，对用户的具体价值体现在以下几个方面：
- 运维人员：数据脱敏功能帮助运维人员解放人力；采集资源管控功能可以防止 Agent 程序对服务器和应用产生影响，有效避免灾难性故障发生。
- 研发人员：日志查询功能可方便快捷的查询日志文件；调用链分析帮助研发人员快速定位故障原因和问题点，协助研发团队优化系统代码并进行架构治理。
- 业务人员：监控告警功能可及时发现业务故障，最大程度上降低故障响应时间，提升用户服务体验。
- 管理人员：智能运维可实时掌握服务资源运行情况，并能够预测集群水位，提供基础资源扩容建议。
写在最后：
截至 11 月 12 日零点，2017 年天猫“ 双十一 ”交易额定格在 1682.69 亿元人民币。不断创新高的销售额、交易峰值、支付峰值，这些惊人数字的背后倚仗的是怎样的技术体系？智能化正逐渐走入 IT 行业乃至社会生活的各个方面。未来，利用大数据关联分析与机器学习技术为运维系统赋予人工智能，提供从故障预防到故障定位、再到故障闭环的智能保障能力。或许到那个时候，运维工程师也可以轻松玩转双十一，妥妥的购物买买买啦！
作者：谢然
原文来自微信公众号：高效开发运维
本文链接：https://www.yunweipai.com/23756.html
网友评论comments