熊节:“东软”争议背后,更关键的问题却被长期忽视
来源:观察者网
2022-09-08 07:34
观察者网:根据目前披露的信息,成都核酸系统崩溃,问题可能出在哪里?
熊节:就核酸系统来说,它的数据写入并不复杂,从检测量推算,平均下来也就是每秒300左右的并发,这放在IT系统里面来说压力不算大。有很多常见的IT系统,比如银行、支付、电商等系统都能够很好承载这种水平的压力。所以就单纯从技术上来说,核酸检测系统的压力负载不算特别大的。
从目前的情况来看,是新旧系统切换,又恰好赶上了全市的静态化管理,需要三天三次核酸检测,所以就出现了问题。对于“东软”这套新系统,我认为它是在非功能性需求没有得到充分验收的情况下紧急上线,所以才出现了系统崩溃不能响应的情况。
一般来看,如果在这种负载量较大的情况下,测试和验收做得不充分,就可能导致系统在之前小范围试用的时候运转良好,但是一旦到了全市大范围使用的时候,经受不住压力考验继而崩溃。我觉得这是一个比较明显的问题。
核酸检测采样(新华网资料图)
观察者网:您提到了系统验收的问题。除却微观个案,从宏观的角度看,类似的情况在数字化系统建设过程中是否也存在呢?除了验收,在数字化建设项目中还存在哪些亟待关注的短板和不足?
熊节:核酸检测系统其实挺有代表性的。这两年新冠疫情的影响,某种意义上也推动了我们国家数字化建设的发展,迫使我们上线了很多重要的数字化系统,健康码、行程码、核酸码都是典型的例子。
同时,它也暴露出来我们数字化建设过程当中的一些短板。因为数字化系统,尤其是软件系统,它和传统的工程建设系统有很大的区别。
第一,对于数字系统的产物交付,很多甲方的处理边界是模糊的。软件产品交付给甲方以后,甲方是不是真正拥有了这个软件系统,其实经常是很成问题的。甲方经常名义上拥有了一个软件,实际上完全对这个软件没有控制。
它体现出来的现象之一就是,甲方采购一个系统以后,就会形成对厂家的严重绑定和依赖。如果想进行后续的维护,找其他厂家来做就非常困难,因为厂家都会有自己的技术门槛、技术壁垒,这给甲方的选择造成很大的约束。
第二,甲方对软件研发的过程缺乏管控。在软件系统的采购中,或多或少都存在这个问题。这不是说我们没有软件工程的标准方法,或者是没有项目监理之类的角色,但是实际上的情况就是我们这个行业里面,软件工程方法都是比较浮于纸面的,包括甲方自己的验收和第三方的监理也存在这一问题。
对于不少甲方和监理而言,他们管理的更多是流程,管理的是文档,很少有甲方或者监理有能力进入到系统的源代码里面去,去了解系统的整个建设过程到底是怎么在发生的。
这就带来第三个问题,就是对软件研发的质量缺乏管控。我们可以用建筑行业做一个类比,比如说甲方单位要修个大桥,那么监理肯定要关注建设过程中的若干质量要求,包括设计的质量、施工的质量等等。可大量软件项目的质量把控其实做得是非常皮毛的,如果我们把软件系统类比为一座大桥的话,很多软件项目的验收就是一辆车在桥面上开过一次,项目就验收了。
这种现象在建筑行业中是不可想象的,甲方起码得验收最终交付的建筑跟当初的设计是否吻合,起码得验收大桥的结构是斜拉还是桥墩、有几个桥墩、桥墩的结构强度是否符合要求……然而有很多软件项目,甲方根本没有去验收软件的架构设计是否得到了实施,就好像验收大桥的时候根本不看有几个桥墩,找辆车开过去就验收了,因为甲方并没有能力去了解这个软件的架构到底是什么样的。
比如这几年流行“微服务”的概念,这个技术术语代表的是一种软件架构的风格,有很多的厂家会在自己的方案里面写:我们采用了微服务架构,所以我们这个软件很先进。但是绝大部分的项目里面,甲方没有能力对架构进行验收,他根本没法知道这个软件到底是不是采用了微服务架构。
我觉得这是一个很严重的问题。几年前某外企曾经采购过一家中国软件公司开发的软件,乙方也号称是微服务架构,结果甲方有一位从美国来的架构师在会议现场打开系统源代码来检验,指出乙方并没有采用微服务架构。像这样的技术能力,我国大部分非IT行业的甲方是不具备的,因此就留下了更大的“忽悠”的空间。
在具体的项目开发过程中,还有一些其他的问题,比如说企业间的层层转包,企业内部的层层下发,任务最后可能下发到技术能力有限的一些年轻程序员手中,甚至还可能是根本不具备相应能力的“无证程序员”手中,而经验丰富的程序员大部分都是在忙售前阶段的工作,逐渐远离软件开发第一线。这可能就把一些潜在的性能隐患和安全隐患埋到系统里面,再加上前面我们说的甲方的验收质量把控又没做到位,那么这些隐患可能就一直埋下去,最终在正式使用时爆雷。
观察者网:从这些案例出发,您能否为我们总结一下数字化新基建给传统的项目采购和管理机制带来了哪些新的挑战?
熊节:软件项目的招标一般来说是百万千万这样的规模,相对于建筑工程来说,金额没那么大,但是水很深。刚才我们也提到了一点,数字化新基建的软件项目往往有很大的依赖性和绑定性,一个厂商做了一个系统以后,其他的厂家很难在它的基础上去加强完善。
于是,我们就会看到一个现象:一些厂商的系统价格很便宜,甚至是不要钱,它们去投标政府采购的项目,凭借价格优势中标之后就可以长期拿项目。因为只要它们的系统打进去之后,在这上面需要做增强、扩展的时候,政府没办法找别家公司。
因为政府作为甲方,也没有能力掌握源代码,所以二期、三期工程就必须得找同一家来干,你找其他家干不了。于是很多厂商找到了一种绕开公开招投标的方法:一期工程以很低的价格进入,价格低到可以不用公开招投标,然后在二期三期不断做增强,把真正想做的功能放进去,整个工程的金额变得越来越大。由于厂商很容易在软件里设置技术门槛,后面二期三期工程其他厂家很难接手,往往就会变成定向采购。这种现象确实可能会带来更多的不透明的操作,甚至更多的腐败空间。
新基建 资料图
另外一些挑战就是我刚聊到过的,甲方在技术能力上面的缺失。当然甲方不必是技术专家,传统的基建项目也是这样。但是我们要看到这里面有一个相对性,传统的基建项目里,甲方就算不是专家,他对基建的了解程度也是相当深的。可我们看到不少数字化新基建的软件项目,问题严重到可以说是乙方想怎么做就怎么做,最后乙方很简单地跑一下基本功能就完成验收,性能、压力、安全性等非功能需求和软件架构设计质量、研发过程质量、代码质量等内部质量都无法验收。
这是一个很严重的问题,它会造成大量表面光鲜的“豆腐渣”工程在数字化建设中被验收、被使用,对于我们打牢数字化新基建的基础是非常不利的。
观察者网:考虑到这些情况,您觉得各方该如何共同应对此类新挑战?
熊节:我国目前在数字化建设上处于国际领先地位,在全球来说都是逐渐走进了无人区的感觉。进入新的领域以后,就必然会有新的挑战。我觉得这里面除了采购服务的政府部门、参与其中的技术企业要付出努力、积极应对挑战外,还应该有学术界、行业组织和官方标准机构的介入与通力合作。
首先对于数字化系统采购的甲方来说,提升自身的技术能力是必须的。我国当前大张旗鼓开展数字化建设,那么甲方就必须形成与数字化新基建建设相配套的能力。
其次从乙方来说,我觉得从事数字化新基建项目的企业需要做些事情去提高自己的透明度,把研发过程和质量保障过程透明出来,让甲方能看到、能看懂,能够对系统进行有效的质量检验。对乙方企业来说,把原来“黑箱操作”的研发过程和质量保障过程透明出来,这肯定是让渡了自己的短期利益,但同时也是对行业的贡献,也会给自己打开更大的机会之门。
比如华为,它过去几年在国外被打击得比较狠,英国政府要求他们自证软件可信,给他们造成了很多麻烦,但是也倒逼他们发展出了一整套软件可信机制。现在华为就有了这个能力,能证明自己的软件质量是可靠的,性能和安全是过关的,并且甲方也能理解这个验证过程。
同理,国内其他软件厂商是不是能自发地建立起一套机制,主动提升自己的能力和透明度,增加自己在行业内、在社会上的信誉,我觉得这也是需要考虑的。
第三个角度,制定标准的机构和高校,应该考虑去做一些更贴近实际的东西。现在信息技术发展太快,这使得制定标准的机构和高校有点赶不上节奏。比如说行业里流行CMMI认证和ISO认证,我坦率说,这些认证是比较不落地的。对于一线的软件开发者来说,他每天写的代码是不是合乎专业技术水平的要求,是不是达到了应有的质量标准,在这些认证里其实都是空白的,目前行业里也没有充分的管理。
因此,我觉得制定标准的机构和高校也应该考虑把这个事情做得更细更落地一些,真正落到源代码上去。最终软件的质量是落到源代码上,光管文档管流程是管不好软件质量的。那么怎么能建立一套第三方的、中立的、真正扎实有效的过程和质量标准,怎么把这些标准和指导落到源代码上去,这也是一个需要长期解决的问题。
智慧城市运营管理中心(新华网资料图)
第四个角度,目前国内自发的技术社区比较少,我想或许可以组成一个政府、高校、标准制定机构、技术公司、从业人士多方通力合作的交流平台。在此基础上,或许能有一些具备技术能力的、中立的第三方监理和质量监管机构和机制出现。
今天行业里没有这样能落到技术细节上的第三方监理存在,就会导致乙方“又当球员又当裁判”的局面。比如说成都市卫健信息中心提前预判到了核酸检测信息系统会有性能压力,要求东软证明系统性能过关,但是谁有能力进行性能测试呢?实践中就还是东软自己做性能测试,提交性能测试的报告,那么东软就又当球员又当裁判了,因为甲方没有这个能力来开展性能测试,或者验证乙方提供的性能测试报告是否真实。
如果有一家具备技术能力的第三方监理存在,这个第三方就可以站在中立角度估算一组性能指标,开展独立的性能测试,从而给甲方提供更可靠的质量保障。当然这里面还会有利益纠葛,监理机构也有腐败的可能性,但是我们应该首先允许这样的第三方出现,进而再去思考完善之策。
除了性能问题以外,数据安全也是一个非常重要、但是又技术性很强、甲方很难验收的领域。尤其是像核酸检测系统这样全是公民关键隐私数据的系统,应该以什么方式去确保这些系统在采购、设计、研发、上线实施、运维的整个过程当中,考虑了如何保障了公民个人隐私数据安全,并切实地把这些考量落实到了软件系统中,这也是数字化时代一个严峻的挑战。
一方面我们会有越来越多数字化系统的需求,其中很多系统会在相当紧急的情况下开发上线,另一方面每一个考虑不周全的数据接入点都会增加公民关键隐私数据泄露的风险。如何切实地提高全行业数字化系统研发的可信能力,是未来整个IT行业需要应对的挑战。
本文系观察者网独家稿件,文章内容纯属作者个人观点,不代表平台观点,未经授权,不得转载,否则将追究法律责任。关注观察者网微信guanchacn,每日阅读趣味文章。
打开APP查看239条评论
评论239条
红色彗星
2022-09-08 09:44
来自四川省
武所谓
2022-09-08 09:01
来自上海市
以上全错,责任全在甲方(此处政府仅指有具体考核压力的基层政府,不包含没有考核压力或者仅有“民心”考核压力的顶层政府,下略)
这种全责,更多是政府资源硬约束的结构性问题导致的,而非某个特定人或人群的主观错误
同样的问题,已经不是第一次发生了,上一次是铁总的12306
12306当年第一次上线的时候,和今天成都核酸码瘫痪的原因一模一样:真实流量远超预定的设计标准
当一件事的量级发生变化的时候,并不是直接堆积资源就可以解决的,而是底层架构就要有所不同
简而言之:蚂蚁不可能简单等比放大到大象那么大,如果蚂蚁越长越大,那么它的结构就会越接近大象
同样的道理:如果预期核酸码流量堪比火车票,那从一开始,你就要采用更贵的分布式架构,留足租用云服务的费用,而不能想当然的认为可以搞十几个机柜的中心架构应付了事。
但这种先知般的一步到位,只适用于市场机制调控的企业,因为一步到位的本质是权衡偏向短期效益还是长期效益。
更关键的是淘汰机制:企业如果决策错误,就会被自然淘汰,从没有人会质疑这一点。
而政府则不可以,政府不会被市场机制淘汰。政府实际运作者的选择压力主要来自“花钱太多”的指责或者根本就是没钱,而效果的评估则远远没那么重要。
这就指向了政府行为的一个基本逻辑:永远选择理论可行方案里花钱最少的那个——这种选择逻辑的风险期望最低。
“我也想给人民最好的——如果我有钱的话”,这是政府心里想说而不能说的痛。
东软的事情,即便最后查出来有一些“人的问题”,也不是这类问题的根本矛盾所在
也因此,东软的事情,绝不会是最后一次,它会在今后日子里反复以各种形式出现
是的,本人从事过银行,银联,银监会项目。三者甲方态度截然不同,银行主要看业绩,对软件设计要求很高,架构先进,可靠是他们最优先考虑的,业务时效性远超系统上线时效性,技术部门只是提供业务支持,连系统上线时间都控制不了。 银联业务独立性差很多,虽然业务部门也有话语权,但技术部门权利也不小,与银联主业是互联互通有关,业务离不开技术部门支持。银监会就不一样了,所有开放计划围绕央行文件转,从需求到开发时间都定的死死的,对开发速度要求很高,准时准点完成上级要求就行,其他的都是乙方的问题,对系统架构不敏感,你给做出来就行了。政府部门就更差了,前三者都还有合格的技术人员配合乙方,政府部门就是看运气,只能说上下限差距太大,不好把握。东软这事不好下结论说谁的错,毕竟不知道内情。但是东软推脱网络问题,大概率是没说实话。政府唯一可以造成的网络问题就是没有拿钱开通大带宽专线网络,但当前情况显然不缺这点钱。封城前紧急上线新系统,个人感觉还是政府命令,根据我的工作经历,银行和银联这类机构都不会冒险上新系统,宁慢不错。只有政府机构才会宁错不慢。可能两者都有错,东软销售和政府负责人一个敢吹一个敢干,下面的技术人员除了默默背锅,只能看着奖金和工资飞走。
扶风缘
2022-09-08 11:03
来自四川省
红霞映雪
2022-09-08 08:56
来自辽宁省
此评论已被屏蔽
作为一名六年工作经验的IT行业从业人员,我想说你这个才真是外行,阿里的软件技术能力在国内都是一流的,很多知名的开源软件都是阿里提供的,比如dubbo、nacos、springcloudalibaba全家桶,淘宝每年应对那么大的并发请求也不是其它公司能够做到的,做软件开发的都知道腾讯、阿里才是国内技术实力最强的,东软不过是一个外包公司,除了项目经验丰富之外还有啥?当然我说的都是基于Java技术栈开发的软件系统,其他工业软件不在我说的范围内。
天刚破晓
2022-09-08 11:31
来自四川省
接触过很多体制内单位外包的软件项目,如果用一个比较容易理解的概念来形容这些项目的共同缺陷,可以把它们统称为沉没式交付。即交付的同时,就意味着该项目的全部或大部已经沉没。
沉没的内涵是什么呢?主要有两层。第一层是不可见。即一个项目,绑定一个乙方(开发商),这个乙方所设定的软件框架和技术规范,在交付后即不可见了。因为甲方不懂,也不关心;甲方也不要求乙方将技术框架一同交付。所以这部分就彻底沉没了……长期的惯例,导致连乙方自己也不在乎,反正收完钱,基本就算完事了,维护维护,拖个两三年,就彻底翻篇了。第二层内涵,就是缺陷被彻底忽略了。无论使用过程种有多不合理,多么不靠谱,体制内的软件通常都是软件比人优先,人要去适应软件,连提意见反馈和迭代优化的过程都没有。长期以往,乙方也习惯了,能简化就简化,什么异常处理,什么压力测试,什么风险评估,都给简化掉了。反正甲方只要领导点头,比一切都重要。
所以,很多时候,这种沉没式交付的后果,就是看似信息化了,其实很多都是水货或者残次品,真要较真,百分之百替代传统工作流程和功能,没几个敢的。走过场的占绝大多数。
举个看得到的例子:中国移动的IPTV机顶盒,全国到处都有。就那个机顶盒的UI和操作,那叫一个变态的难用啊……简直令人发指。但这就是一个全国商用的系统,产品级的,水平大致相当于米家机顶盒UI的30%吧。
钱塘潮
2022-09-09 02:57
来自香港特别行政区
机械攻城狮
2022-09-08 11:41
来自辽宁省
现在可不是谁也不能说,现在恰恰是谁都能说,谁都愿意说,说东北什么时候变成政治正确了,有些人就是靠说东北博眼球,表面看像个恨国党,实际上为了显示自己的地域优越感。我就问为什么天津疫情系统也崩没人说是软件公司问题,东软因为跟这事有关天天被拉出来分析,你给我分析分析原因呗
东软是靠日本软件外包起家的,当年日本成本高,国内信息化几乎全部都是外包大连做的,大连懂日语的不少,你懂的,当年起家时候根本没法和印度竞争的,有了这个打底,才有后来东软的国内地位,东软的10大股东中可以发现,第三大股东正是日本阿尔派电子(中国)有限公司,日本ALPINE株式会社也成为东软第一个国际客户,后来慢慢扩大到整个日本系统的。当然了,日本IT是个啥操行大家都懂,东软在这种外包系统下水平自然不如印度的。但是在国内的语言壁垒还在,还能做出大量市场来。
印度的IT业,可能其技术水平不高,程序员水平也不高,但是其流程非常规范的,写的代码和备注什么非常完美,各种细节都比较清楚,便于其理解,我的亲身体会是,印度人的代码基本上二十个人的代码看起来都是一个人写的,非常规范,中国三十个人的代码感觉四十个人写的,印度IT从当年给美国解决千年虫问题开始就是定位很准确,就是给西方打下手,做软件的富士康,做点边缘的脏活累活,解决客户的需求,几十年下来行之有效,做好服务业不是那么容易的,现在西方狠多的报表报告甚至律师的状纸都是印度人写的,服务已经多年了。
实际上中国外包的软件还算做的好的,因为外包给钱多,国内自己做的软件因为盗版多没有收入,那个就更乱,中国软件的问题前有盗版后有微软,而盗版才是最大最大的问题,我希望就这个契机解决一下软件发展问题吧。
活的京男博士
2022-09-08 08:33
来自北京市
这专家说得非常克制了,在很多“甲方”中,信息化部门本身就是边缘化的,这种边缘化部门中充斥着非信息化背景的工作人员,甲方人员只能做些事务性管理工作,签个合同盖个章,写个报告开个会完了,需求全靠具体使用的业务部门提供,模型设计等一概不懂,技术全靠乙方。就这样的,其实还算过得去的,最要命的是根本就没有信息化政务管理服务的思维,把老衙门那一套弄到信息化领域。结果就是平时糊弄做系统,用时系统糊弄你。
娄山木刀
2022-09-08 11:16
来自广东省
政府这个“甲方”当得很窝囊,不懂技术,被忽悠然后被要挟。
本来以为搞个投标竞标,搞点竞争,项目自然而然就质量又好价格又低。结果却被低价进入的供应商设置隐性门槛要挟,窝囊窝囊。
在数字化信息化的大趋势下,“甲方”需要加强技术能力,防止被忽悠被要挟。同时对设置隐性门槛的企业要有相应的法规制度,严厉打击,从而促进竞争。