为什么一家传统券商选择将交易系统容器化？(6)

南怀瑾在某本著作里举过一个剃头匠悟道的例子 – 无论何种行业,技艺追求到极致可能悟到的道理都是共通的.《黑天鹅》和《反脆弱》的作者塔勒布本人也许算的上是这样的一个触类旁通的好例子 – 由金融而“悟道”于哲学(起码被称之为本世纪有影响力的思想家之一).

IT领域不知道有无类似的人物,诸如面向对象设计、架构设计模式、敏捷开发领域的大师级人物Martin Fowler等,显然是抽象思维特别强的人,能够对复杂的技术世界进行“模式识别”而作出一些深刻思考.

在技术世界里,我们一向强调方法论,可是有时候也需要形成“世界观”、“信仰”.在无数次的项目危机管理、技术故障攻坚、运维救火之后,IT人也许应该对“世间唯一不变的是变化本身”有深刻体会,从而接受“拥抱不确定”的观念.

IT界面对变化与不确定性的态度,这十多年来看也是一个有趣的演变：

• 直到本世纪初,很多项目管理及软件工程的方法论,依然强调所谓的“Change management”(变更管理),通过组织(“变更委员会”)、流程来“管理”业务系统需求方不断提出的需求管理,视需求变化为项目延误、系统不稳定的根源,以项目“按时”交付为终极目标,可以说这些方法论本质上“厌恶“变更.
• 互联网风起云涌后,出于应对瞬息万变的激烈竞争、在线高效运营的刚需,接受“需求变化是常态”、对变更友好的“敏捷”(Agile)方法被自然而然引入到日常项目中,成为过去十年的主流方法论,并且终于把传统企业IT牵引其中(例如广发证券IT启动金融电商系列项目研发前的第一件事就是先把敏捷实践建立起来 – 对口的方法论才可能带来对的结果).
• 然而,绝大部分企业的敏捷实践都局限在垂直业务线的项目团队里,而运维作为一个维护全企业IT生产资源的横向平台型组织,通常被排除在敏捷实践之外.

  敏捷迭代方法解决得了业务需求变更的问题,解决不了系统上线后各种突发性的变化 – 故障的及时解决、版本的迅速更新(业务部门总是迫不及待的)、在线经营的瞬间生效(运营人员分分秒秒催着)…

  在一切都嫌慢的“互联网时间”里,运维貌似成为最后掉链的一环,以“稳健”为主导的运维团队与“进取”的研发、运营团队无可避免产生冲突

• 时至今天,随着“把基础设施数字化”的云计算的普及,一个新的方法论 – DevOps,闪亮登场.之所以说这是一个方法论,是因为它绝不仅仅是“Dev + Ops”这样简单粗暴的把开发工程师和运维工程师捆在一起,用“同一个项目组”、“同一套KPI”来强迫他们分享“同一个梦想”了事.

  它是在APM(应用性能监控)、Infrastructure As Code(可编程运维)、Virtualization(虚拟化)、Containerization(容器化)等等这些云计算时代的产物出现后,基于新的技术工具、技术理念而自然产生的.

  持续集成(Continuous Integration)、持续交付(Continuous Delivery)、持续运维(Continuous Operation)是DevOps的具体环节和手段,它相当于把一条纯数字化链路上不同的参与者关联到一起 – 无论是开发工程师还是运维工程师,最终都不过是身份稍微差异的Information worker.

DevOps可能不仅仅是个概念、方法论、技术新名词,它是伴随云计算自然发生的.但它的接受与运用,对于传统企业的IT,尤其是“维稳”为主导思想的受监管行业的IT,可能是一种文化冲击.

传统IT甚至是今天的很多技术相对前沿的互联网公司,依然把团队拆分成“运维”、“开发”,在组织结构层面建立相互制衡,以避免开发团队的“冲动冒进”导致生产系统的不稳定,但运维职能往往变成一种“权力”(privilege)- 系统的迭代更新都需要获得运维“审批”,这本身显然就是一个“脆弱系统”,因为对变更是绝不友好的.在技术进步、时代变迁的大环境下,这种过去合理的做法,早晚变成一个将要被颠覆的存在.

无论如何,我们认为割裂的讨论一个高性能运算(HPC)的技术系统(如证券交易系统)的容器化、“云化”是不够的,DevOps是构建“反脆弱”技术系统的方法论(起码到目前为止.也许将来有新的思维出现),也是我们系统能力的天然一部分.

我们从软件研发的视角、证券交易的视角来看待云计算,深感把促进基础设施数字化、运维代码化的容器化技术,运用到交易系统技术中,是天作之合 – 假如运用得当的话,结合机器学习和智能算法,能帮助我们构建一些“反脆弱”的技术方案(既然有能下围棋的阿尔法狗,我们是否也可以开始憧憬懂得自救的运维狗?).

可以看到的潮流脉络是,世界是越来越数字化的、变化是越来越频繁的、而IT是需要拥抱变化的,云计算则只是这个潮流里完全符合趋势而自然出现的技术阶段.

有一天Oracle、SAP、各种著名与非知名的专业软件都把它们自身的产品基于容器来构建(例如一个多进程组成的数据库实例里的进程各自运行在自己的容器中),也许对于行业监管者、企业技术决策者而言,云已经无需概念上的存在,而能被毫无质疑的接受.

但是这一天到来之前,大部分企业也许可以先尝试调整一个对云服务友好的财务制度 – 项目立项的时候,硬件预算按CPU核数、内存量、存储量来报算,有形的物理机器不再作为资产稽核到各条业务线各个项目组,一切物理硬件归IT.制度和文化,往往才是隐形的决定因素,不是吗?

文章出处：InfoQ

（编辑：ASP站长网）