那些年我们一起犯过的错 - 旁观者 - 博客园
阶段性小结: 错误是我们的财富
对于事故处理,我们遵从航天二十字诀: 定位准确、机理清楚、可以复现、措施有效、举一反三。
“丰田生产体系”与航空航天的这个原则是相通的,如果对待错误的态度是开诚布公的,那么整套系统就能从中学习,能取得进步。
我们坚持每错必查、错了又错就整改、每错必写,用身体力行告诉每一个新员工直面错误、公开技术细节、分享给所有人,长此以往,每一次事故都会变为我们的财富。
我的错误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-