做网站要求的分辨率是什么意思,室内设计装修用啥软件,做透水砖的网站,游戏开发学习昨天下午#xff0c;微软给大家放了个假。Windows又双叒死机了。不过#xff0c;这一次不是几台机器#xff0c;而是全球大范围宕机。这一刻#xff0c;大家都是“正蓝旗”。 蓝瓶的#xff0c;效果好#xff01; 现在根本原因已经找到#xff0c;绝大多数人的机器都已修…
昨天下午微软给大家放了个假。Windows又双叒死机了。不过这一次不是几台机器而是全球大范围宕机。这一刻大家都是“正蓝旗”。 蓝瓶的效果好 现在根本原因已经找到绝大多数人的机器都已修复。根本原因在于一家名为CrowdStrike的安全公司在例行更新时部署了错误的配置文件到Windows上。
这个错误也是由于另一个比较少见的错误引起的。CrowdStrike软件使用了微软部署在美国中部的云服务Azure但刚好这个数据中心出现了异常。 这个异常就导致了CrowdStrike在获取配置时导入了错误的配置信息。这些错误信息下发后软件终端基于错误的配置运行就会在Windows终端额外加一个名为csagent.sys的驱动而这个驱动存在bug会导致系统陷入蓝屏死循环。
这个错误导致航司、银行和交易所受到重大影响后面是否会面临巨额赔偿还不清楚但微软股价已受严重冲击。
目前还不清楚国内有多少从事交易的机构和个人受影响但是这也给我们量化人提了一个醒你构建的交易系统它安全可靠吗我们应该如何构建自己的量化交易系统使得它即使遇到类似的问题也能保持稳定运行
这里提几条建议。 第一一定要达成高覆盖的单元测试和CI/CD流程。一定要意识到任何软件、硬件系统都是有bug的。在你构建量化交易系统时一定要达成高覆盖单元测试和CI/CD流程。
单元测试不仅仅是在我们开发阶段帮助我们确保各个模块的功能正确更重要的是它设置了一组基准可以帮助我们确定在时刻发生变化的环境下系统的各项功能仍然满足基准运行要求。
正如这次CrowdStrike案例所显示的那样即使你的交易系统并没有升级就像这次的Windows,但交易系统依赖的第三方组件比如数据源Pandas或者Numpy等仍然可能升级。我们的交易系统在接受任何升级前都要确保升级后的系统仍然完全能通过我们所有的测试用例。
像CrowedStrike这样的软件其实他们平常的测试也是很严格的但为什么还会出现这样的故障这里固然有比较偶然的原因这次是Azure的故障引起但是很可能CrowedStrike的测试没有经过CI/CD的覆盖。只有实现了CD这样才能保证连部署也被测试覆盖到才会尽量减少错误。
传统上量化团队都是金融专业的人领导的他们可能缺乏软件工程的经验不太懂测试、CI/CD这些专业知识正因为这样我写完《Python高效编程实践》这本书之后特地请了两位金融界的大咖来推荐。因为自己做量化金融有好多年了知道这个领域非常需要系统化的软件工程方法来确保软件质量。 第二关闭一切自动更新。生产环境下一切自动更新都是非常危险的必须关闭。只有经过严格测试的更新才能应用。
第三更新系统时一定要使用灰度部署。
在部署上CrowedStrike这次也犯了一大错误就是没有实现灰度部署。实际上安全软件权限很高一旦出错往往就会引起很严重的故障。因此灰度部署就格外重要。
如果CrowedStrike实现了灰度部署比如一开始只部署1%的机器并且监控升级后的情况收集数据是灰度发布的一部分然后在没有错误报告的情况下再逐步扩大推送范围就完全可以避免出现这么重大的事故。
灰度发布同样适用于量化系统。2012年8月1日骑士资本在纳斯达克交易所部署了一个新的交易软件但是由于没有充分测试该软件在激活时触发了一系列错误的交易指令导致公司在45分钟内损失了约4.4亿美元。最终导致了它被Jefferies Group收购。 骑士资本案例报告 事后分析如果正确地实施了灰度发布完全可以避免这样的错误。 如果有杠精这件事比较复杂。一言以蔽之不是没有实施灰度发布而是没有正确地实施灰度发布。 据说做期货的往往是90%的时候都在赚钱但就是不到1%的极端情况让你跳了楼。
第三构建可控的系统。 如果你的交易信号系统构建在AI模型之上那么风控模型就一定不要构建在黑盒子之上一定要设置熔断机制到点无条件地止损当然这会引起其它家的量化也跟进止损但换个角度如果你跑得太晚那么被埋的就是你自己。
第四再先进的系统也不能无人值守。即使有了全自动的量化系统也不要把手工交易员都裁了。如果你去看三峡大坝的发电厂你会发现发电是高度自动化的但电脑显示屏前的值守人员仍然会严格倒班。
