Shell's Home

May 27, 2015 - 1 minute read - Comments

程序的持续更新

今天有个朋友来问我sql2000的问题,数据库装好后各种,总之就是不能用。我说我已经很久不用sqlserver了,就算用,也绝对是用2008而不是2000。不过我还是给了一点小意见——重装整个系统再重装sqlserver呢?结果他和我说,就是重装惹的祸。

这是一个很老的业务系统,数据库只能用sql2000。整套系统运行了很久都没有维护了,基本就是硬盘坏了换硬盘,也没有多的烦恼,很轻松。但是最近CPU挂了,连带主板也有问题。这类的老主板+老CPU不好买,所以干脆用新件起系统。但是windows系统更换主板后无法直接识别,所以系统要重装,牵连sql server要重装。装完了远程就始终无法连接,要不然就是能连但是不能写。

我靠还有这种事?当年不是用一样的系统组合,一样的安装盘,一样的维护人员。为啥今天就出问题?

结论是不知道。但是这个事情不能因为不知道就不做,所以问我有啥想法没。

我问他能不能升级,告诉说没戏,应用绑死了。整个系统必须用sql 2000,而操作系统只能是winxp和win2003。好家伙,这三个都是超过维护期限的,连漏洞补丁都没了。那这个没救了。。。

想到帮另一个朋友维护的系统,也有类似烦恼。在老版本的php上写的系统,在新版本的php+mysql组合上就无法执行。所以必须安装老版本的CentOS。而老版本CentOS是有退役期限的——一个系统也不可能常年累月做下去吧。所以未来如何,一样很发愁。类似的事情数不胜数,甚至包括我自己写的某个系统,用了老版本的sqlalchemy导致升级不上去。

有一类系统,需求不经常变更,系统压力很小,使用场景很专一,结果就是代码几乎不需要维护的可以一直用下去。不得不说,这种系统比其他系统是简单多了也幸运多了。但是再耐用的代码,也是有服役期限限制的——一般和整台机器的寿命差不多,也就是7-10年。超过这个期限后,还要运行老系统,就要看负责是不是找的到人维护了。语言可能很少有人用,组件可能不能升级,牵连到系统都是老的,没有维护没有补丁。新设备上能不能装出来,有没有驱动都很难说。要照10年前的情况维护,还不如大量搜购老部件接着维护电脑比较痛快。

银行在上个世纪用COBOL写了大量代码,直到今天还在维护——但是代价也很大。银行不得不自己维持了COBOL的一整套生态系统,以至于我提到COBOL几乎就和银行话上等号。(当然,这也和COBOL本身和适合做这类工作有关)

如果没有银行那么大财力的话,要维护这种小系统,在短期内相当占便宜。但是如果在长期,万一出点问题,能不能搞定就有点存疑了。所以我建议维护这种系统的人,每五年做一次检讨,看看系统是不是重做一下,或者做一下兼容性升级,重写部分代码以便于在新系统上执行。这样也许不需要太大精力,就可以让整个系统顺利的再撑个5年。

无论如何,指望像房子一样,建好后就一直可以使用,不碰到灾害不碰到意外就可以用个几十年。这种事情对于程序来说几乎不可能了。程序更像是汽车,一旦过了20年,要找老部件就非常困难了。合理的选择还是弄个新的吧。

试题设计的原则 携程本次问题分析

comments powered by Disqus