其实，不仅是传统证券金融业 IT，其它绝大部分传统垂直行业 IT，就技术前沿性和专业性而言都是距离科技公司颇远的。不管愿不愿意接受，一个事实是，顶级名校的计算机系毕业生，职业首选肯定是去投奔互联网巨头的研究院、跨国 IT 公司、创业公司独角兽。不信？调查一下自己所在金融机构的 IT 部门看看今年新招毕业生的学校和学历分布，例如看看有没有来自清华北大交大神马的。
在美国，华尔街的投行如高盛、摩根斯坦利、美林等等，因为有品牌效应和丰厚的薪酬，还能吸引到一些不错的 IT 人才；高盛、摩根都拥有上万的 IT 人员，其研发的能力也不容小觑。可是，这些 IT 组织在 IT 界的影响力、对业界的技术贡献、自身的总体水平，和 Google、Amazon 比还是差很远的。
看到这里，作为证券业 IT 人士的你忍不住跳起来了，你可能会提出两点来驳斥这个“谬论”。
“唯学历”观是错误的
拿金融机构 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 定理、响应式宣言、微服务、DevOps、大数据 等等这些技术理论与理念，却没有在这个行业诞生，为啥？原因不外以下几条。
从证券 IT 人嘴里听过不止 N 次语重心长的论调，“技术不重要，不要过分强调”。意思是说，行业 IT 的主要目标是开发、支持业务应用系统，不管用什么技术，只要可靠、稳妥、“成熟”，能把应用系统功能按业务部门要求做出来就行了。所以，管它用 J2EE 还是.Net 还是其他什么鬼，按时交货、上线不出问题，是最高目标。
事实上，在强监管类型的行业里，一些软件公司只要紧跟监管政策法规，不管用什么古老技术，只要监管机构提出一个新要求就做一个新模块、市场批准一项新业务就做一类新功能，然后卖给无任何开发能力的行业机构们坐地收钱，也就活得很好。所以是不太需要什么技术追求的。
金融行业 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 企业”。
典型垂直行业通常在 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 的实践以更好的运维金融业务系统非常有帮助。畏惧、抗拒新技术的态度无法抵御技术迭代更新越来越快的时代车轮的碾压。
技术与金融业务的结合，关键在于技术能用得其所。一支金融科技研发团队，应该是由一群跨界、复合型人才组成的——看到业务创新需求的时候，能想到在自己与时俱进的技术武器库里找到最合适的工具来实现它；看到新技术（例如区块链）出现的时候，能努力联想一些新的业务可能。
为什么在做好金融业务功能的同时，就不能用上最前沿最好玩的技术呢？这两者并不冲突。
梁启鸿，早期在 Morgan Stanley 等华尔街投行从事交易系统技术研。此后创办游戏公司及任雅虎北京研究院首席架构师。2012 年回归金融业加入本土券商广发证券任 IT 董事总经理兼首席架构师。目前为金融科技创业公司凡泰极客（FinoGeeks）联合创始人。
今日荐文
点击下方图片即可阅读
智能化运维、Serverless、DevOps、AIOps......CNUTCon 全球运维技术大会将于 9 月 10-11 日在 上海光大会展中心大酒店 举办，12 位大牛联合出品，揭秘智能时代下的新运维，更有 Google、eBay、IBM、阿里、百度、腾讯、携程、京东、华为、美团等知名互联网公司一线技术大咖分享他们在运维技术实践过程中遇到的坑与经验，推荐学习！点击“阅读原文”了解更多精彩！
