昨晚的事件，对tqsdk来说，应该算是一次不小的事故。
看了一个坛友的帖子，对于其中的建议，坦白来说我是不置可否的。是否收费，收多少，怎么收，是tqsdk考虑的事情。但事情昨晚发生时，迟迟未见有效解决，对于已经购买了专业版的朋友来说，是一次打击，你也总不能跟他说，其实收费不贵，比其他某某程序来说是比较少的，但这不是出事故的理由，对吧。
因此，我也想在自己了解的范围内，谈谈对于昨晚这次事件的个人看法。首先事先声明一下，本人非程序员，也不是专业投资者，算是一个半路出道，妄想凭程序化做点懒投资的……人，而已吧。
1、tqsdk应注意灾备。主服务器要有冗余服务器，主备同时在线，加上负载平衡等等，在服务出现重大故障，无法对外提供可靠服务时，应能立即自动切换，对外提供无扰服务。重大故障，包括硬件及软件。我了解的一般的服务器都是虚拟的，无论其重启、切换都是非常快的，对用户来时基本上是不会察觉到的。
2、tqsdk程序升级上架前应该有更完备的测试程序。相对于之前各个版本也出现或多或少或大或小的bug来说，昨晚的事件明显不属于bug了。究竟是程序方面的问题，还是部署问题，应该都要严格把控，因为毕竟是用在实际生产环境中的，出现问题可能是灾难性的。
3、即使因为各种原因，存在无法解决灾备或者排除程序问题方面的困难，那至少在升级前的备份方面应该考虑好，至少在出现问题，又没法立即解决的情况下，也能快速地回滚到前一版，至少前一版是正常的，不至于造成更大的影响，问题接下来可以慢慢再查。
4、tqsdk备用服务器应该能提供与主服务器全部的功能。昨晚出现问题后，tqsdk迅速给出一个解决方案，就是连接到备用服务器，这个人员速度应该来说是值得称赞的。但是备用服务器不能使用query函数，这个让我有点费解。因为恰恰我的程序用到了query，因此昨晚也懒得改程序（主要是本人技术还差，短时间想把query全部去掉，难度太大），就让程序死了一个晚上。在我一直以来的印象中，备就是主的copy，或者主是备的子集，如果只能完成主的部分功能，算哪门子的备，不合格，顶多只能算是降级备胎。或者，我建议将上一版程序作为这个备胎（不是“备”）的程序，不要一起升级，这样是不是可以解决一些问题呢？
以上是个人的一些浅见，不对或者不合理的，大家看过就算了。
刚刚看了一下，程序运转正常了，总算是松了一口气，但仍是任重道远，不是吗？
