那些年我们一起犯过的错 - 旁观者 - 博客园

阶段性小结： 错误是我们的财富

对于事故处理，我们遵从航天二十字诀： 定位准确、机理清楚、可以复现、措施有效、举一反三。

“丰田生产体系”与航空航天的这个原则是相通的，如果对待错误的态度是开诚布公的，那么整套系统就能从中学习，能取得进步。

我们坚持每错必查、错了又错就整改、每错必写，用身体力行告诉每一个新员工直面错误、公开技术细节、分享给所有人，长此以往，每一次事故都会变为我们的财富。

 

 

我的错误1—做好被攻陷的准备：刚接手工作几个月，黑客入侵

很多年前，没想到我刚刚到任几个月，数据库就被黑客下载了。

过程是这样的：

凌晨2:46，黑客通过某地IDC机房里的一台肉鸡，仅仅两次尝试输入管理后台登录地址后，就准确地输对了，说明此黑客清楚我们的后台登录拼写规则，否则不可能在7秒内依次尝试很难的拼写。

登入8分钟后，他利用 FCKeditor 版本2.4.2以下的PHP版上传文件漏洞，上传了多个 php 文件。

然后，他种了一个 rootkit，即在 include 文件夹下放了一个 lndex.php，浏览这个 php 就可以从网页上修改操作系统 root 帐号的密码。

总之，黑客在凌晨3点到6点之间，在那台宿主机上密密麻麻地放了很多 php 文件上来，并修改了很多系统文件。

 

几天后，黑客又从那个肉鸡来了，访问他之前在服务器上种下的 rootkit。

然后，可能利用他从服务器上代码配置文件中看到的数据库用户名和密码，备份数据库并下载。

 

尾声：

内部IT系统的后端：

-在服务器端，日志文件里不要存储用户或商户的敏感信息，如登录密码、银行卡号、身份证号，曾经有一个知名公司的工程师为了调试方便，将用户的信用卡卡号和卡密记在日志文件里，但白帽子们发现能访问到这个日志文件……

-我们认为数据库有可能被盗走，所以要做到即使被拿走，也不要给客户和用户造成损失，所以数据库存取这些商业敏感信息时需要做高强度的对称加解密。

-工程配置文件只允许存储加密后的数据库登录密码，同时部署人员和开发人员都不允许掌握明文密码。

 

内部IT系统的前端：

-登录做两步验证；

-禁止多点登录；

-从框架上做好防 XSS+SessionHijacking+CSRF+SQLi……

-我们认为第三方很有可能拿到我们的平台登录权限（通过 session hijacking，或通过内部人），所以即使在合法用户登录状态下，敏感字段的展示要有遮挡，修改或查看敏感信息的时候要输入短验验证身份；

-内部IT系统的 robots.txt 内容必须是：『User-agent: * Disallow: /』，禁止搜索引擎收录。

 

点题：

我的态度是：放眼一年、三年、五年、十年，你的系统一定会被人攻陷，你的数据一定会被人拿走，往往是几个初中级安全漏洞，再加上一次社会工程学，就能成功渗透，并不需要高危漏洞。所以要做好灾难即将来临的准备，即使被攻陷，被拿走，也不要给商户和用户带来二次伤害。

 

 

别人的错误3—工具与风控：骑士资本集团的覆灭

2012年的时候，骑士资本是美国股票市场最大的经纪商，分别占有纽交所和纳斯达克 17% 的市场份额。

骑士资本的电子贸易部门管理的平均日交易量超过 33 亿股，交易额高达210 亿美元。

截止到 2012 年 7 月 31 日，骑士资本拥有高达 3 亿6500 万美元的现金及现金等价物。

 

在8月1日之前，骑士资本按照纽交所的项目计划，更新了算法程序 SMARS，它从交易平台接收大订单，然后根据买家或卖家的股票交易数量把大订单拆分成合适的小订单。

 

这次更新去掉了一些过时的代码，如 Power Peg，虽然它已经 8年没有用过了，但实际上 Power Peg 模块一直处于待命状态，只要系统的某一个特殊的参数被设置为「YES」，该模块就会被调用用来交易。

 

程序员开发了一个新的 RLP 模块，取代之前的 Power Peg 模块。取代后，之前那个特殊的参数被设置为「YES」，意思是使用 RLP 模块。

 

听起来是不是让人担心？

 

不用担心，测试完全通过，虽然更新后的代码沿用了以前用来激活 Power Peg 模块的标识符，但代码非常可靠。

 

7月27日到7月31日，骑士资本把 SMARS 软件手动部署到公司为数不多的服务器上。

一共才 8 台。

不幸的是，漏了一台服务器。

因为没有其他技术人员对部署过程做复查，所以没有人发觉第 8 台服务器上的 Power Peg 代码并没有被移除。

所以这台服务器上并没有 RLP 模块，只有 Power Peg 模块。「Power Peg」模块在被停用后的第10年被启动了。

 

灾难正在一分一秒地迫近。

 

2012年8月1日早上9点30分开盘后，很多交易员感觉到异乎寻常的事情发生了，某些个股涌现出大量不符合常理的订单，而且没有停止的迹象。

 

这个系统竟然没有断开的开关。

 

于是乎，在 45 分钟之内，骑士资本执行了超过日均交易额 50% 的订单，导致部分股票市值上升超过 10%，带来的连锁反应是其他股票价格暴跌。

 

由于没办法断开系统，也没有相关情况的预案说明，魂飞魄散的程序员只能在每分钟交易 800 万股的生产环境里调试。

 

因为没有能在线上发现问题，所以回滚了代码。

 

情况反而恶化了。

 

原本只是第 8 台上的 Power Peg 在疯狂地工作。

现在另外 7 台服务器上的 Power Peg 也加入了进来。

 

最后，骑士资本的技术人员和纽交所一起终于想办法终止了交易系统，然而已经过去了 45 分钟。

 

灾难现场，一片狼藉。

 

在这 45 分钟里，

对于内行人来说，骑士资本建立了 80 支个股 35 亿美元的净多头仓位和 74 支个股 31 亿 5000 万美元的净空头仓位。

对外行人来说，骑士资本在 45 分钟内亏损了 4 亿 6000 万美元，而上文提到，骑士资本仅有 3亿6500万美元的资产，这意味着骑士资本破产了。

 

骑士资本集团在整个事件中犯下的错误有哪些呢？

1，Power Peg 模块在停用时并没有从系统中删除，而是保留在系统里成为僵尸程序。

2，运维工程师手工部署，没有交叉验证，操作重大失误。

3，他们的风险管理完全是事后管理，缺乏事前控制。虽然对公司的敞口设置了限额，但超过限额时交易系统无任何限制。

4，他们的风险管理工具PMON，是一个事后的风险管理工具，完全依赖于人工监控。当交易量较大时，该系统还会有延迟，产生错误的报告。所以在灾难发生的时候，业务人员没有快速定位到敞口的来源，也没有意识到问题的严重性。

 

点题：

1，工具： 假定人的错误是不可避免的，上线部署就应该是自动化的，而且是可重复的过程，尽量排除人为因素的干扰。 如果你常年靠手动发布，总有一天会大难临头。

2.风控： 你的业务保障平台，你的风控管理系统，是你的最重要的伙伴，不要轻视它，在关键时刻，它会救你的命。

 

最后，我们再呼应一下主题：

第一，

『我得到正确判断的办法，

通常是先收集各种错误判断的例子，

然后仔细考虑怎样避免得到这些下场。』

——《穷查理宝典2》查理·芒格

 

第二，

错误是我们的财富。

我们坚持每错必查、错了又错就整改、每错必写的RCA制度，

用身体力行告诉每一个新员工直面错误、公开技术细节、分享给所有人，

长此以往，每一次事故都会变为我们的财富，而不是包袱。

 

-EOF-