财富源代码

10.2 带跳扩散过程：财富曲线不是光滑函数2020年4月20日，一个在字节跳动做数据仓库的工程师在午休时间打开手机看了一眼行情，然后他把嘴里的那口饭咽了整整十秒钟才吞下去。他持有的某只挂钩国际原油价格的银行理财产品，在前一个交易日收盘时净值还是正数，经过一个周末——准确地说，经过美国时间周一的交易日——净值变成了负数。不是跌到了零，是跌穿了零。他不仅亏光了在这只产品上的全部本金，还倒欠银行一笔钱。

10.1 内核恐慌：当“唯一解”遇上“无解”1998年9月23日下午，长期资本管理公司的合伙人们聚集在纽约郊区那间著名的玻璃会议室里，面对着一个他们所有模型都无法解释的数字：当天他们又亏掉了5.5亿美元。坐在会议桌首座的约翰·梅里韦瑟——这位所罗门兄弟公司前副主席、华尔街最负盛名的债券交易员——用他那一贯平静到近乎冷酷的声音向在座的合伙人提出了最后一个请求：在美联储介入之前，还有谁认识能拿出十亿美元的朋友？

9.6 版本发布日志：用Changelog记录你的认知升级2018年，一个在GitHub上维护着五千多Star开源项目的工程师，在项目的第五个年头做了一件他称之为“考古”的事。他花了一个下午，把项目从第一个commit到最新release之间的所有变更日志重新读了一遍。他看到了v0.1版本的README，里面写着“这是一个实验性项目，API极其不稳定，请不要在生产环境使用”。他看到了v1.0版本的Release Notes，里面标注了第一个破坏性变更——他把核心接口的参数顺序改了，导致所有老用户必须修改代码才能升级。他看到了v2.0版本的Migration Gu

8.7 反脆弱的终极防线：从防崩溃到在崩溃中受益2014年，纳西姆·塔勒布在伦敦政治经济学院给一群金融工程专业的研究生做了一场后来被传阅了无数次的讲座。他开场问了一个问题：风会熄灭蜡烛，也会让森林大火烧得更旺。你是蜡烛，还是森林大火？

8.3 杠杆的时序违例：短债长投是毁灭的根源2022年秋天，一个在字节跳动做推荐算法优化的工程师做了一笔让他至今不敢翻开那个账户交割单的交易。他当时看好一家港股的AI公司，觉得估值已经跌到了历史最低位，技术护城河在行业内几乎无可替代。他自己手里有六十万本金，全部在那只股票上被套着，浮亏大概百分之二十。他用自己名下的一套还完贷款的房子做抵押，从一家股份制银行拿到了一笔八十万的一年期消费贷，年化利率四点几，按月付息，到期还本。他用这笔钱在那只股票继续下跌的过程中分批补仓，平均成本比最初建仓价低了将近百分之三十。

8.1 边界值测试：你的系统在极端输入下会怎样2015年夏天，一个在阿里巴巴做中间件开发的工程师在股灾到来之前做了一件事，让他在之后整整两年里成为整个团队里心态最稳定的那个人。他没有预测到股灾。他只是在2014年底，花了两个小时把他家当时的财务状况扔进了三个他自己编的极端场景里跑了一遍。第一个场景是大盘跌一半，第二个场景是他被裁，第三个场景是前两个同时发生。跑完之后他发现，如果前两个场景同时发生，他家的流动资金会在第九个月归零。他盯着那个数字看了几分钟，然后打开手机银行，把原本计划投进股市的一笔钱转进了应急储备金账户，把储备金从覆盖九个月提升到了覆盖

5.2 设计你的低通滤波器：定投和长期持有的传递函数1976年，苹果公司刚成立不久，乔布斯和沃兹尼亚克在车库里组装第一批Apple I电脑。如果你在那年买了一台Apple I并持有到今天，它的拍卖价格已经超过了90万美元。但更有意思的数据不是这台机器本身升值了多少倍，而是如果你在1976年随便选了某一天看了一眼苹果的股价——假设它当时上市的话——你看到的那个数字，和今天苹果公司成为全球市值最高企业之一这个事实之间，隔着四十七年、超过一万七千个交易日里每一次开盘和收盘的跳动。这四十七年里，苹果经历过1985年乔布斯被赶走，经历过1997年濒临破产股价跌到不到

4.6 单元测试的重构：把交易策略封装成可独立验证的函数2010年5月6日，华尔街的闪电崩盘发生之后，美国证监会的调查人员花了将近五个月时间才定位到灾难的触发点。最终的调查报告里有一段描述，让所有写代码的人看完都会后背发凉：引发连锁崩盘的那个算法交易程序，在设计的时候只用了一年的历史数据做回测。那一年是2009年。如果你还有印象的话，2009年是金融危机之后全球央行集体放水、资产价格单边上涨的一年。在那个数据集里，任何做多策略都会显得聪明绝顶。

4.2 Crash Dump：当你的交易爆仓时，先保存堆栈信息2017年，GitLab发生了一次史诗级的线上事故。一位运维工程师在例行维护时，意外地在错误的数据库实例上执行了一条删除命令。当他意识到自己删错了数据库的那一瞬间——用他自己的话说——“我的大脑一片空白，耳朵里只剩下心跳声”。然后他做了一个让所有同行都捏一把汗的动作：他开始在极度恐慌的状态下尝试各种恢复操作。他手忙脚乱地敲命令，试图从备份里恢复数据，但备份脚本在过去几个月里一直静默失败，最新的可用备份是六个小时之前的。更致命的是，他在慌乱中跳过了LVM快照的常规保存步骤，直接在主库上操作，导致最后一份可以

3.4 Nginx 负载均衡——动态再平衡的反人性纪律2017年，一个做SRE的朋友在凌晨三点被报警电话叫醒。他负责的某个核心服务突然开始大量返回502错误。他迷迷糊糊地打开笔记本，登录到Nginx服务器上看了一眼日志，发现后端有一台应用服务器的响应时间在逐步升高，最终超过了Nginx设置的超时阈值。Nginx主动把这台服务器从upstream列表里摘掉了，把流量重新分配给剩下三台健康的服务器。整个过程中，用户只感觉到了大概30秒的轻微卡顿，没有全站崩溃，没有数据丢失，没有上热搜。

3.2 异地多活与冗余阵列——指数基金的工程学之美2015年夏天，阿里云的一个可用区因为施工挖断了光纤，导致整个可用区的部分服务中断。如果你当时用的是部署在这个可用区里的单节点云服务器，你的应用就直接挂了，你只能等光纤修好。但如果你按照阿里云的最佳实践，把服务部署在多个可用区，并且挂了负载均衡，你的用户甚至可能完全没感知到这次事故——流量在几秒钟之内就被自动切换到了另一个可用区的健康节点上。

我是有底线的