（转）“在证券行业，技术不重要，不要过分强调！”

“在证券行业，技术不重要，不要过分强调！”——呵呵。

2017-07-24 梁启鸿 券业新力量
券业新力量 | 服务所有券业人的梦想

Vincent
Charlie Landsborough - Love, In A Song

推荐课程

课程主题：《发力PB业务，你需要掌握这5节课！》
报名方式：长按文末海报，识别二维码，获取报名通道~

其实，不仅是传统证券金融业IT，其他绝大部分传统垂直行业IT，就技术前沿性和专业性而言都是距离科技公司颇远的。

不管愿不愿意接受，一个事实是，顶级名校的计算机系毕业生，职业首选肯定是去投奔互联网巨头的研究院、跨国IT公司、创业公司独角兽。

不信？调查一下自己所在金融机构的IT部门看看今年新招毕业生的学校和学历分布，例如看看有没有来自清华北大交大神马的。

在米帝那里，华尔街的投行如高盛、摩根斯坦利、美林等等，因为有品牌效应和丰厚的薪酬，还能吸引到一些不错的IT人才；高盛、摩根都拥有上万的IT人员，其研发的能力也不容小觑。

可是，这些IT组织在IT界的影响力、对业界的技术贡献、自身的总体水平，和Google、Amazon比还是差很远的。

反对的声音

看到这里，作为证券业IT人士的你忍不住跳起来了，你可能会提出两点来驳斥这个“谬论”：

1、“唯学历”观是错误的；

2、拿金融机构IT的水平和互联网巨头比不公平。

首先，你会说“唯学历”观是错误的 – 这个无异议哈，高分低能的多了去了。

燃鹅，我们在这里只是陈述一个“客观指标”，例如一些大券商都喜欢标榜自己的员工平均学历神马的，有些甚至要在微信公众号各种秀员工们的“颜值”。

金融业从外面看是个高大上行业，招募到的年轻人都是高颜值的顶级名校毕业生，非985、211学校的进不来，行业风气如此…

但，金融IT显然是例外（很不中听），因为有浓厚技术爱好和极强能力的计算机系毕业生首选肯定都跑某软亚洲研究院、直接肉身翻墙去米帝、或者起码投奔国内某互联网大厂或某独角兽去了。

话又说回来，其实，一个高度偏科没考上好学校的极客型人才，例如只有高中大专学历，不“唯学历观”的你会招聘他吗？

就算你会，你也得起码经历两次“破格”申请、三度流程、四次人力资源部驳回，最后碰到一位开明的领导，才能“破格”录用他（别问我怎么知道的）。

说到拿金融机构IT的水平和互联网巨头比不公平，那么我们不拿Google来说事。我们说说Netflix（网飞）肿么样？

2016年，Netflix的营收是88.3亿美元，高盛是377.1亿美元。它们分别从营收中拿出了多少投入技术研发没去仔细研究，但以体量来粗略的看，后者的投入再怎么着不可能比前者少。

Netflix开始时就一网上出租录影带和DVD的，后来变身视频娱乐服务商和内容提供商，但过去几年成为Micro Services、DevOps的先驱，提出了Chaos Engineering、Intuitive Engineering的理念，也开源了很多的技术，在互联网甚至传统金融机构都有这些技术的追随者和应用者（Netflix的一些具有“反脆弱”性的技术其实最应该在证券业借鉴），影响了许许多多的工程师。

另一方面，我们中又有谁受过高盛摩根们的高大上牛掰交易系统开发大拿的技术理念影响或者用过他们什么开源技术？

金融机构向来标榜系统运维在高可靠性、稳定性、健壮性方面的牛，可是SRE（Site Reliability Engineering）是Google提出的，云上分分秒秒成千上万次系统升级的能力是亚马逊率先具备的，我们就不扯NoSQL、Deep Learning、Containerization等等这些工具、技术、理念基本来自哪里了。

这里想说的是，证券金融业数字化程度相比其他行业算非常高、业务场景也非常复杂、非功能性系统要求（例如高并发、低延迟、高可用等等）也超级挑战，有钱的投行IT投入也足够大，理论上能诞生可以普惠社会的技术理论和工具，可是最终并没有利用这些条件向技术界反馈反哺、贡献出有价值的技术成果。

正面分析

证券业其实是有孕育牛掰技术的应用场景和环境的。

对交易应用来说，分布式架构15年前就不是新鲜事物，内存数据库的应用是家常便饭，交易消息中间件过去二十年被重写过无数次，高频极速交易在利润的驱使下对技术的运用可以说无所不用其极；甚至在一些科技领域华尔街可以说曾经走在最前沿。

例如80年代末，多核（multi-core） CPU技术都还不知道在Intel哪个实验室里，多个CPU（multi-processor）多路并行运算（Parallel Computing）是超级高大上昂贵的技术，代表了高性能运算（HPC）领域的最高成就，华尔街投行们在利润的驱使下绝对是是率先的运用者，程序猿们甚至已经研究和使用能驾驭多路CPU的编程语言Linda编写交易系统 – 起码十多年后基于同样理论的技术（JavaSpaces）和商用平台（GigaSpaces）才出现。

可是像CAP Theorem、Reactive Manifesto、Micro Services、DevOps、Big Data等等这些技术理论与理念，却没有在这个行业诞生，为啥？

原因不外以下几条。

• 1、首先，是证券业IT对技术的态度。

从证券IT人嘴里听过不止N次语重心长的论调“技术不重要，不要过分强调”，意思是说，行业IT的主要目标是开发、支持业务应用系统，不管用什么技术，只要可靠、稳妥、“成熟”，能把应用系统功能按业务部门要求做出来就行了。

所以，管它用J2EE还是.Net还是其他什么鬼，按时交货、上线不出问题，是最高目标。

事实上，在强监管类型的行业里，一些软件公司只要紧跟监管政策法规，不管用什么古老技术，只要监管机构提出一个新要求就做一个新模块、市场批准一项新业务就做一类新功能，然后卖给无任何开发能力的行业机构们坐地收钱，也就活的很好。所以是不太需要什么技术追求的。

• 2、其次，是金融行业IT总体缺乏开放的习惯与文化，没有行业生态的概念和“协作竞争”（co-petition）的意识。

在互联网里，开放平台、API经济都是老生常谈，在金融业里也许因为行业的特殊性，导致开放非常困难。

例如摩根斯坦利（Morgan Stanley）的IT，起码在90年代初（Google、Amazon还不知道在哪个角落的时候），就已经拥有强大的平台研发团队，自己研发跨Windows、UNIX（N个流派）的UI框架与开发环境MSToolkit，充分运用了很多面向对象设计的最佳实践；为了加快复杂程序的编译速度甚至实现了在SGI（当时最高性能的UNIX Workstation）上的cross-compilation（跨操作系统的二进制代码编译）。

当互联网还处于婴儿期、Netscape（网景）还是明日之星的岁月里，Morgan Stanley的Client Connectivity团队已经向Netscape不谋而合的提出Web服务器（当时还是新生事物）的插件（plugin）理念并率先在FastTrack Server（比Apache还早的Web服务器）上实现。

可是今天这些技术成果都去了哪里？真是应了那句话，“神马都是浮云”了。

不开放的技术没有生命力，既不造福行业，也无法自利利他，无论曾经如何的前沿，最终也被一波波新兴的开源技术替代、拍死在沙滩上。

其实拿着“监管行业特殊性”、“信息安全”这几根鸡毛，是否就可以当作令箭来实行自我封闭？

恐怕未必，开放并不等于“不保密”、“信息不安全”，其实更多是一种文化、习惯、思维问题。

一些技术例如是否可以在行业范围内开放？是否增加透明度和更加安全？co-petition这种“自利利他”的理念，在包括华尔街在内的传统行业，始终缺乏深刻认识。

当然，开放说的容易做起来难。例如互联网曾经的先锋现在的先烈Yahoo，虽然是一家互联网公司，却是一个”放弃了不该放弃的，坚持了不该坚持的“悲催例子。除了放弃收购Facebook的著名案例，在它的”中晚期“，却死守一些古老的封闭的内部自研发技术，不愿意拥抱互联网上开源的技术，整个技术文化都开始更加像一家“传统IT企业”。

• 3、最后，是典型垂直行业通常在IT方面比较“短视” —— 和促进业务没有直接肉眼可见关系的投入，都是拒绝的。

例如假设在一家证券公司里，自己研发一套消息中间件 —— IT团队如果真想干这事，只有在不影响业务型项目的进度的前提下、发挥极其巨大的“主观能动性”、自发自觉加班加点或者躲在家里作为业余兴趣搞，才有机会做个原型，而且因为没有立项，所以把技术成果“变现”的机会甚微。

大部分的大型金融机构也不见得会理解为什么需要自己投入这么基础的技术研发。

一年赚个几百亿美元的、可以算的上金融界Google体量的高盛摩根们，在投入基础技术研发方面尚且有挑战 –——随时面临内部业务部门成本分摊扯皮问题，毕竟不是自定位为“技术公司”。

负责决策的高管们（通常不是程序猿出身）也无法弄明白一套消息中间件的奥妙，要说明白为什么不能用RabbitMQ、ActiveMQ改造一套，或者为什么不合适直接采用Tibco Rendezvous之类，而非得自己研发一个，可以算“秀才遇着兵，有理说不清”，更不要说IT人口舌通常都是笨拙的（现在能把一个技术问题举重若轻的给业务人员、客户、领导说明白，是IT人最最最重要的素质 ——几乎没有之一）。

有些华尔街机构也许已经意识到“技术基因”的问题，近年来开始把自己称之为“科技公司” —— 光说没用，得“移风易俗”注入科技血液，但无论如何也姑且算是迈出了观念上的一步吧。

后果分析

上述对IT的态度、观念与文化，可以说不仅在金融业、在其他非技术行业都是类似的。这种环境下，导致这样一些连锁反应。

IT缺乏专业性。

典型的开发工作是这样的：收集需求 —分析需求 — 整理需求 — 开发（更多是协调外包商开发） — 测试（人肉黑盒子测试）— 部署（人肉部署）。

因为不把自己定位成一个专业软件组织，所以这里每一个环节通常都是比较随意、业余的。

例如“需求分析”当然也不会用到什么OOAD（面向对象分析方法）、不会通过UML从多维度呈现需求的视角、不会有规范的用例场景（Use Case）管理；

例如“开发”环节自然也不会采用领域建模（Domain Modeling）来对业务逻辑进行规范构建、也不会用专业工具作持续集成与代码测试覆盖率自检（code coverage）、也没有严谨的技术架构论证；

例如“测试”环节也没有什么TDD、BDD的方法论或者QE白盒测试；例如“非功能性”的系统指标往往只是上线出现问题才救火补漏…

以为能够快速实现业务逻辑、迫不及待完成任务，却因为软件工程的专业性认识的欠缺，导致开发出来的软件系统非常的不专业。

以纯粹完成业务功能为导向的IT组织，不管是开发商还是金融机构，都有自我定位为“业务部门的搬砖工”的倾向，一切围绕功能需求，机械堆砌代码，技术方面正如欧阳修《卖油翁》里的名句：“唯手熟尔”。

缺乏专业性的IT组织，通常也没有工程师文化，所以是无法吸引到优秀工程师的。

没有优秀的工程师带动与引领，那么团队里就缺乏跨行业的、从其他地方来的新思维、新技术、新理念的碰撞，思想与文化处于一个封闭的无流动性的小池塘中，技术新人就跟着“唯手熟尔”的老司机干，遵循着他自己“土法炼钢”摸索出来的一些“实践”，一代代“薪火相传”，惯性的思维、固化的观念、已经忘记本源的流程，就这么延续下去…

如果能够这么稳定的延续下去，对于一些同志来说当然也是一个稳定职业。

只可惜，靠“唯手熟尔”谋生的日子即将一去不复返了，因为这种工作正是AI的拿手好戏 – 熟手技工们，恭喜你，套用网上常用的“虽然…但是…“句型造句：“虽然你技术很烂，但是你这么个被动搬砖工对金融业务核心也不理解啊”，很快你将成为《人类简史》作者尤瓦尔·赫拉利所谓的“无用阶级”一员。

这里有一个恶性循环：

一个没有工程师文化的组织，吸引不到一流的技术人才，所以就不会有很牛掰的技术，就不会吸引有技术追求的毕业生，就没有技术文化传统与传承，就不会创新，技术债就总是还不清也无暇学习运用最新科技成果，所以就无法吸引到科技人才，所以就不会有工程师文化、所以就吸引不到技术人才…
总结思考

新技术，都是为了更好的解决一些问题而出现的，例如我们常说”语言是思维的外壳“ – 一门新的计算机语言往往用来思考、建模某个领域的问题从而解决它比用其他语言更适合（所以它才会诞生），而容器化技术则对于我们建立DevOps的实践以更好的运维金融业务系统非常有帮助。

畏惧、抗拒新技术的态度无法抵御技术迭代更新越来越快的时代车轮碾压。技术与金融业务的结合，关键在于技术能用得其所。

一支金融科技研发团队，应该是由一群跨界、复合型人才组成的——看到业务创新需求的时候，能想到在自己与时俱进的技术武器库里找到最合适的工具来实现它；看到新技术（例如区块链）出现的时候，能努力联想一些新的业务可能。

为什么在做好金融业务功能的同时，就不能用上最前沿最好玩的技术呢？要知道，这两者并不冲突。

【版权申明丨本文发布经作者授权，转载请联系原作者。】