共计 3243 个字符，预计需要花费 9 分钟才能阅读完成。
导读：本文次要总结一下笔者之前做的对于业务存储资源优化的整个过程，正所谓前事不忘，后事之师，心愿以文中的例子为引，可能总结出一些如何防止坑以及如何填坑的方法论。
全文 19135 字，预计浏览工夫 26 分钟
一、业务介绍
为了更好的了解上面介绍的点，先对业务的一些概念进行简略介绍。
- 「百度手机助手」：百度手机助手是在 Android 零碎上的手机利用散发平台，治理开发者上传的 Android 利用，通过转存等解决后将利用散发到 C 端。
- 「增量更新（省流量更新）」：如下面的业务框图所示，开发者将利用传到开发者平台（app.baidu.com), 为了保障下载的稳定性以及速度，助手会将开发者的利用会转存到百度外部的存储服务上，叫做 BOS(Baidu Object Storage)。为了节约用户下载的流量，助手启动了增量更新的能力。增量更新是指新版绝对旧版生成差别包（下文叫 patch 包），在更新软件时，将旧版本的包与差别包合并成为最新版本的过程。绝对全量更新更省流量，升高了用户更新软件的流量老本。
二、为什么优化
在优化的工夫点，整个助手的存储占用曾经达到了几 P 的量，每年的估算费用近千万。从业务上进行数据分析，通过剖析对应业务场景的 mysql 库，库中会记录对应利用的大小。剖析后的大抵数据如下：
这外面会发现利用 patch 包的占用十分大，同时发现存储总量 - 已知存储后，仍有 P 级别的存储是未知的。这里利用 patch 包的存储占用是否合乎预期须要看一下。
所以，为什么优化就有了几个正当的理由：
- 高估算耗费
- 寻找存储去哪了的执著
- 把无用数据清理掉的强迫症
上面就开展整个清理的过程。
三、剖析
优化的第一步就是剖析要怎么优化，把闲置的存储找进去，而后优化它。用普通话来说就是猜。此处的闲置，能够定义为耗费的存储带来的价值不合乎预期。存储的价值是什么？分几局部来说。
- 「利用存储」
对立转存到百度，首先平安，如果应用第三方的服务，存在被移花接木的危险；其次稳固，能够本人对存储以及下载进行优化；最初能够基于外部存储做一下定制化的能力，比方动静追加数据等。利用存储在百度的价值无可替代，简略来说是钱花得值。 - 「利用 patch 包」
对这部分的价值定义，在用户节俭下载流量的场景下有价值，否则没有价值。即如果咱们生成了 patch 包，占用了存储，但用户却没有降级该版本，那么就是没有价值。 - 「不晓得去哪了的存储」
当然要挖出来，看看是哪家妖怪。
有了初步的方向后，要进行更精确的确认，判断收益空间。从上面两个角度进行验证。
- 「存储占比」
整个存储的 object 在优化之前差不多亿 + 条，没有短时间内疾速获取全副 object 的形式，采纳了抽样的办法，拉取了线上 30W 条数据进行初步剖析, 上面是存储空间占用的散布
▲存储空间散布
- 「更新流量的散布」
▲更新流量散布
有了下面的数据，能够从基本面看出，省流量更新的存储耗费更大，然而理论的流量价值却很低，基于此能够确定要对省流量更新的 patch 包下手了。
四、优化思路
就像把大象装进冰箱一样，开门 - 放大象进去 - 关门。优化也不是上来就入手把存储革除，整个过程参考大象装冰箱的思路，分为三步:
4.1 还原全貌
正所谓“知己知彼屡战屡败”，做一件事件升高危险的第一要领，应该是把事件摸清楚。对于存在几年的老业务，如何去摸底，总结下来有几点教训。
- 「外部文档」
无论是技术文档还是需要文档，尽量都去看一遍，同时带着问题看，把本人代入到写文档的视角里，多思考下为什么文档是这样的，这样能够尽可能多的挖掘出一些疑难点。 - 「代码」
外围的代码逻辑肯定要过一遍，工夫越长的代码，补丁可能越多，一些边界的场景都暗藏在代码的小角落。 - 「人」
找到相干的同学 或者 不相干的同学（第三者视角），带着基于文档和代码的疑难进行沟通、询问、刨根问底，补全思维偏差。 - 「产品」
基于产品性能进行回归，将文档和代码进行串联，造成清晰的代码地图。
最初，基于全面的信息梳理，实现基于数据流的业务流程图。整个过程有点像是
《长夜难明》的探案过程，抓住每一个线索，实现最初的拼图。
拼图 1 - 增量更新场景的数据流
从图中，能够看到次要的存储分为三局部，「开发者利用，客户装置利用，省流量 patch 包」。其中 patch 包的生成步骤为：
- 获取开发者已装置利用
- 生成 开发者已装置的利用 和 高版本利用的 patch 包
拼图 2 - 用户装置利用收集
拼图 3 - 增量更新解决
外围的数据处理流程如下：
4.2 制定方案
因为是进行存储优化，那就次要关注梳理出的数据流程各个环节是否能够优化 以及 是否要进行优化。首先，磨刀不误砍柴工，从 BOS 处通过 api 导出全量列表，因为历史积攒，共亿 + 条 object 数据。而后基于原来的增量更新策略 制订出了对应的优化策略。
在梳理计划的过程中，深感我的项目的评估以及继续跟进的重要性。上面举几个例子简略阐明下。
- 最后解决的时候，为了疾速解决用户的增量更新的指标，设计时对全副利用一股脑的生成增量 patch 包，然而并没有思考到用户是否会进行更新的场景，也就是理论的 ROI。实际上只笼罩 top300 更新的利用，就曾经可能占比 93% 的更新申请，然而可能缩小 95% 的存储占用，是非常明显的比照。
- 在初版的策略里并没有思考业务个性，原始的策略是取 top10 版本号的包和用户手机装置的包来进行生成 patch，但疏忽了同一版本号下会同时存在多个包（客户为了推广，同一版本的包会生成 N 个渠道包上传治理），也就是 1 对 N 的场景。
- 原来设计的初衷可能是仅生成最高 10 个版本的 patch 就好了，实际上会放大到生成几百个包，也是十分大的存储耗费。还有原来的 top10 的思考是为了因为 Android SDK 的一些限度，某些低端机型可能无奈装置高版本利用，但随着千元机的遍及，这个策略也能够成为历史了。
在解决的过程发现上文提到的未知的 P 级别空间，发现是原来物理机迁徙，自运维的数据库未迁徙，导致之前的增量包尽管占用了 BOS 存储，然而没有在 db 中发现，评估对业务没有理论用处了，最初一股脑清理掉了（十分爽）。
4.3 执行计划
这是最轻松的过程，外围要留神的是要设计好验证形式和回滚计划。此处不细说了。整个成果从顶峰的 P 级别降到了百 T 级别，排除毒素，一身轻松。
五、总结
以习惯的五问法做一个回顾，总结下整个过程学习到的货色。
5.1 为什么会产生这么大量的有效存储？
程序没有革除，研发反馈产品设计并未思考历史存量问题
5.2 谁应该思考？
研发，集体认为产品和研发的谐和边界是，产品给出要实现的用户性能，技术给出解决方案。产品不必关怀存贮存多久，只须要提出用户的省流量更新须要在什么场景时效，研发基于产品性能来判断 patch 包是否能够归档删除。
5.3 原零碎短少什么？
文档积攒 & 监控 & REVIEW。要做好文档积攒，不便有一天须要对系统优化的时候能看到为什么零碎是这个样子；要欠缺监控，做到心里有数；要定期 review，同一个业务逻辑随着产品的演进有可能就会从就地取材的设计变成历史包袱，放弃凋谢心态，放眼过来，着眼将来。
5.4 该如何防止？
靠你的教训，同时思考对立面。事件都有对立面，很多时候咱们思考问题都只会着眼于眼前看到的点，阳光之下必有暗影相伴，作为研发能够多思考问题的反面是什么，这样能够更全面的思考问题，少留一些技术债。
5.5 如何做的更好？
零碎永远是为产品服务的，然而研发要思考投入产出，不仅要思考研发的投入产出，同时要帮忙产品一起思考产品的 ROI。换个角度去看问题，会发现不一样的技术计划，兴许就会 do better。
举荐浏览：
百度 APP 视频播放中的解码优化
百度爱番番实时 CDP 建设实际
当技术重构遇上 DDD，如何实现业务、技术双赢？
接口文档主动更改？百度程序员开发效率 MAX 的秘诀
技术揭秘！百度搜寻中台低代码的摸索与实际
百度智能云实战——动态文件 CDN 减速
化繁为简 – 百度智能小程序主数据架构实战总结
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
