全球Windows机器蓝屏，作为量化人，我的检讨来了

昨天下午，微软给大家放了个假。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模型之上，那么，风控模型就肯定不要构建在黑盒子之上，肯定要设置熔断机制，到点无条件地止损（当然这会引起其它家的量化也跟进止损，但换个角度，如果你跑得太晚，那么被埋的就是你自己）。
第四，再先辈的体系，也不能无人值守。即使有了全主动的量化体系，也不要把手工交易员都裁了。如果你去看三峡大坝的发电厂，你会发现，发电是高度主动化的，但电脑表现屏前的值守职员，仍旧会严格倒班。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。