【电商挂点是好事】不是足够大的公司，还没机会遭遇技术问题

今天是双 11，不过台湾两大电商平台 PChome 跟 momo 却在今天疑似 乘载不了突然涌入的压力而挂点 ，我想平台与技术团队应该压力山大，但我觉得这是一件很好的事，所以要特别恭喜他们。

不是足够大的公司，不具有这样的规模量，你还没机会遭遇此问题，就如我们过去说的：

换句话说，就是你够大，你才有机会碰到这样的问题。

大多数一流的网路公司都曾发生过大规模的系统问题，差别只在于局部崩溃或是全面性的崩溃，但在它们长到这幺大之前，这种异常问题还会少见吗？一点也不，AWS、Facebook、阿里云、Netflix、LinkedIn 这些公司其实都发生过大规模的异常事件，这些公司的工程师的高水平我想大家都略知一二。

台湾网路圈这些年来因为市场规模的关係，网站的交易量与併发用户量一直都不会太大，每秒上千个交易或 10 万个併发用户已经是一线网站，基本上很少有机会让大家实战演练一下如何搞定每秒十万交易跟千万级併发用户。

很多人，学了一辈子架构设计，但一直都没有机会在工作中实践，而各位有这样的机会，我真心觉得运气太好了。当然，短期内面对的压力肯定很大，公司内部甚至会有人建议要杀两个工程师来祭旗.XD。

不过长期来说，因为痛过，你更能理解架构设计的重要性，而在这过程中，技术团队也该把握机会，好好对公司内部陈述技术架构在商业上的重要性，可以将目前潜在的问题做好分析，并提出改善建议。

虽然此时你心里一定不太爽，但请务必记得不要见猎心喜，用「我早说了吧」、「你们就不重视技术，只重视销售」，这样容易挑起纷争的发言，因为这不会让你的建议获得採纳。请记得，此时只要站在公司的角度去讨论这件事，提出目前技术架构上的问题，并提出资源的需求，一般来说大多能得到不错的结果。

三年前我接下公司的维运负责人，当时我们也面临了许多系统端问题，以下是其中一个当时让我燃烧了不少生命，但也学到非常多的案例。

随着业务量成长，资料库的存取量也大幅提升，每天到了尖峰时刻，系统就快要乘载不了，最惨的是我们的主资料库，每天晚上的 CPU Usage 都是逼近 100%，而且一旦上去，短时间内都不会降下来。这是什幺概念，等于同一时间在存取资料库的所有 user，全部都会卡住，动弹不得。

第一次发生，我们只能选择重新启动资料库服务，释放掉所有的连线，让所有的 user 重新连上。当然了，当天晚上的客诉电话可是没有断过，公司内的微信群整个炸开，大家都想杀两个 RD 来祭旗 ，但大家都知道，当务之急是找到原因以及解法，当公司的用户数量每年以倍数在增加时，这样的问题势必会成为往下成长的瓶颈。

当天晚上我们当然招集了各系统的负责人以及 DBA，讨论了很多可能的原因，从资料库与系统的 log 中找蛛丝马迹，一开始大家猜测的原因命中率其实很高：

1. 资料库肯定有许多 lock
2. 肯定有一些写得特别烂的 SQL，消耗了大量的 DB 运算资源，所以 CPU 冲高
3. 太多很多 inline SQL
4. 太多排程服务对 DB 发出 request
5. 太少 cache

至于到底是什幺原因，DBA 很快地也找出来了，基本上上面这五条全部都中奖，接着又花了几天把一些执行频率高，且资源耗损较大的语法都找了出来，我印象中不少于 200 条，而我们挑选了其中的 3 条优先处理，因爲能争取到 10% 使用率的下降，对当时的我们来说就有很大的帮助了。

但改这种沉痾问题，不是一两天就能搞定的，因此往后的几天，我们先做了很多 workaround，包含尖峰时段所有的 RD 都避开会存取主资料库的系统，上线若涉及资料库存取的，都要先提供给 DBA review，确保问题不会持续加重，甚至是在进入尖峰时段前，先将部分服务重新启动。

若不幸当天晚上的 CPU 使用率还是爆表，那就先做资料库重新启动，那段时间，每天晚上我们就是在监控萤幕前盯着萤幕，随时準备应付突发状况。

后来在我们将那几支改写好的 SQL 重新上线后，CPU 使用率开始平稳地维持在 70-80% 左右，发挥了一些成效，但我们很清楚，这样的数字一点也不保险，因此在接下来的一个多月内陆续进行了烂 SQL 的修复，以及为 SQL 的写法做好规範，后来 CPU 使用率便降到 30-40% 上下。

那段时间几乎天天都被 highlight，酸言酸语也在所难免，但藉着这种国安等级的重大事件，我们也趁机让大家知道一些技术性专案的重要性，藉此预警三个月半年内可能会再发生的状况，并打铁趁热，将一些技术性专案的优先顺序往前挪，争取到一部份时间把问题彻底解决。

在问题解决前，每天就是面对着千万营业额可能流失的压力，现在想想还是觉得超级幸运.XD。

如我前面所说，大家都知道系统会有问题，发生时，也大多能点出问题所在，但这样的问题却还是在发生，这意味着，技术的学习与实践中间，其实存在很大的落差。而我们何其幸运，可以在这样的时间点，遭遇到一个这种规模的问题，唯一能做的，就是解决它。

资料库，其实是整个系统中相对难 scale 的，过去几年也有多次因为资料库的问题而搞得我们蓬头垢面，但我每次面对这样的问题还是备感兴奋，虽然当下的压力或情绪不见得很好，但我告诉团队处理过这样的问题，自己的技术经验会更加完善。

分库分表、读写分流、异步同步、大规模开发的资料库管理、高可用的 DAO 设计、多层资料快取 、资料库解耦合、资料架构的重新规划与设计，这些都是在那段时间内我们讨论过的议题，而其中最少有八成，我们后来真的实践了，如果没有那样的挑战出现，根本没机会累积这样的经验。

也非常感谢当时 DBA 团队的众家高手们，不厌其烦的跟我们一块找问题，并提供很专业的建议，让我在处理问题的过程中，同时也学习了工程部门如何与 DBA 做良好的沟通协作。

上礼拜我在 FB 分享了一位 LinkedIn 的 SRE 工程师分享他有一次 将 LinkedIn 搞挂的经验 ，其实我非常期待有一天台湾也能有一线网站的工程师出来分享类似的经验，我相信这对台湾技术水平的提升会大有帮助。