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

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

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

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

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

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

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

  （编辑：应用网_丽江站长网）

  【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!