查看原文
其他

明日控股 IT 基础架构转型深度访谈:战略、选型、实践

为客户着迷的 志凌海纳SmartX 2023-06-03

在大众贸易领域,明日控股走在传统行业数字化建设的前沿,通过引入先进的架构夯实数字化建设的能力,为产业上下游客户提供原料交易、金融衍生品、信息源头、供应链金融、智慧物流、全球供应链等全方位一站式增值服务。


通过和明日控股 CIO 沈琪敏的三次深度访谈,我们将为您介绍明日控股 IT 基础架构转型的战略规划、选型过程与部署实践。


全文约五千字,阅读大概需要 8 分钟。


战略篇



大家好,我是来自明日控股集团信息中心的沈琪敏。我们公司成立于 1998 年,通过在整个行业二十年的深耕,我们目前位于全国塑化分销领域的头部地位,去年的营收大概在 650 亿元,员工在 1000 人左右。


我们提供的服务,主要是物流服务、资金服务、供应链金融服务和金融衍生品服务,服务的下游客户大概有 2 万家。我们企业的愿景是成为全球最具合作价值的塑化产业链服务商。


明日控股目前能够保持每年 30% 的增速,其实与我们在 2018 年提出的数字化战略是息息相关的。我们的三化战略包含数字化、金融化和国际化,数字化其实是排在三化战略的第一位,对于我们这样的传统企业具有举足轻重的作用。


传统贸易是通过商品的价差获得盈利,现在的贸易是靠衍生品工具的辅助来控制风险,这对数字化的能力提出很高的要求。


我们通过数字化去夯实我们企业的竞争实力,去服务好我们下游的客户,包括为上游的供应商提供服务,我觉得这是我们明日控股的核心竞争力。


我们在 2018 年提出数字化战略,战略的核心是以数据来驱动业务,从战略的提出到战略的执行再到战略的落地,其实我们是分了三个方面。


第一个方面是赋能,我们认为数字化最终还是要为业务来服务,提供业务价值,为上下游提供更好的服务,提升我们内部业务和管理运作的效率,提升供应链的效率来降本增效。


第二个我们比较关注架构的建设,数字化的引领是以架构优先为原则,不是以应用优先。我们认为技术架构是一个底座,只有把平台建设好,才能够在平台上去扩展很多的应用,达到我们赋能业务的目的,当然这个架构包括我们基础架构的建设。


第三方面是组织建设,我们认为数字化应该包含组织的建设,包括我们数字化的执行力、领导力,怎么样去统一思想,怎么样去让我们整个组织范围内的人员,全部有具备数字化的思维。我认为这三个方面是我们数字化,从战略的提出到落地的路径。


2009 年之前我们是以 ERP 为核心的集中管控平台的建设,我们那时候系统比较单一,主要是围绕供应链和财务两套系统去开展,那个阶段其实对我们企业来说是最基础的支撑作用。


从 2009 年到 2015 年,我们开展的第二个阶段是 ERP 升级工作的项目建设,我们围绕着用友 NC 的集中管控式平台,把更多的管控、把供应链效率在每一个环节的流程优化提升到了新的高度。


第三个阶段其实是我们数字化爆发前的探索阶段,从 2015 年开始,我们和 Salesforce 合作、和 Oracle 合作,去做 CRM 的系统和 BI 系统的建设,把我们整个业务应用的前端从 ERP 系统中剥离出来,通过 IT 更敏捷的服务去实现我们业务的管控,或者是规则化的梳理,达到 IT 敏捷服务业务的目的。


第四个阶段是 2019 年开始,我们去做整个 ERP 的升级和 BIP 的建设,这个阶段里我们重新定义了整个战略,提出了 IT 加互联网的技术架构路线。


我前面也讲到我们平台的建设,其实还是通过和 Oracle 两期的咨询定义了我们未来整个数字化的支撑,即必须是要在先进的技术架构的基础上去开展。


在这个基础平台上,我们再去建立很多的应用,包括我们业务能力中心的建设和平台能力建设。当然在这个过程中外围辅助的很多系统,我们也是同时在开展建设,包括期货管理、销售决策、期货交易、外围系统集成,有物流公司、有银行的集成、有券商的系统集成。


数字化发展的第四个阶段,我们已经形成了外围系统的集成,内部中心能力的建设,很好地解决了组织架构的调整,包括风控能力的建设,包括我们对下游服务商及时提供数据服务的场景的满足。


选型篇



顾大众贸易的整个行业领域,我觉得我们明日控股是走在整个传统行业数字化建设的前沿。


很多企业还是在解决数字化建设第一阶段业财一体化的过程,我们不光是在解决业财一体化的过程,还在解决业财资一体化、业财资税档一体化的建设过程,我们为了去夯实数字化建设的能力,愿意去采用先进的技术架构、先进的基础架构。


从 2015 年到 2019 年的跨越,我们在技术底座的选型上其实也是做了很大的突破。当然我们对云服务的理解,其实也是比较深刻的,包括纯 SaaS 的 Salesforce 的云、Orcale 的本地化部署的私有云。


我们其实一直在思考怎么样去把云做私有化,因为我们在公有云上确实遇到了一定的瓶颈,我们把核心的业务放在公有云端的时候,因为公有云服务的一些不稳定性,影响了我们整个业务的开展。我们在选择和用友合作做 BIP 项目建设过程中,我们毅然决定是需要去掌握基础架构。


当然在项目选型的过程中,其实我们也看过很多方案,包括公有云的方案、物理机的方案、超融合的方案、私有云的方案、还有虚拟化的方案。


之所以不选择公有云,刚才我也讲过了,确实是公有云有一定的局限性;物理机方面,我们当时是采用了云原生微服务的架构,物理机的部署量是非常大的,第一个方案给到我们的时候,第一个阶段就要提供 70 个物理机,当然只是考虑了生产环境,如果我们要从生产环境、测试环境、开发环境多环境这样去考虑,物理机数量可能会要达到 200 个左右。


虚拟化我们也看过像 VMware 虚拟化的建设方案,我们认为存在成本的投入过高以及我们不能掌握核心能力等问题,所以我们当时没有考虑 VMware。


至于私有云,因为我们也是集团集中管控型的企业,私有云上虽然有更多的服务,但是像收费、标准、或者是安全、数据备份这些功能,我们觉得在最初的一个阶段里,没有考虑到这么深。


我们是要考虑更专业,更突出地解决我们对硬件资源的需求,因为我们还是在一个摸索和初创的阶段,我们认为超融合可能是更适合我们,在对硬件的性能或者资源配置模糊的状态下,开展核心重量级的云原生微服务架构平台的建设。


从我们实际的案例来看,从当初 70 个虚拟机这样的规划,后来瞬间发展到了 200 个虚拟机,如果我们选择了公有云,70 个虚拟机和 200 个虚拟机的成本投入差异是非常大的,而且我们也要考虑上云下云的成本,还有安全、周边投入的成本,都是我们需要综合去考虑的。


我们在实施的过程中,原来可能是为了一个项目做的,在看到了超融合的优势和作用后,我们会把很多周边的应用都慢慢地放到超融合中。


我们后期又开展了数据中台,把数据中台的环境又放到了超融合集群中,我们还有其他的应用。包括人事的应用、财务的应用、期货管理的应用,很多的应用其实都是放到了超融合里面。


我们内部也是有比较严格的分工,我是给我们的高层去做规划决策的支持和建议,我们也有专业的技术团队,包括架构师。


当时我了解到参与选型的厂商,可能有华为、深信服、H3C、SmartX,那么在选型过程中我们其实也是做了很多轮。


我们最终选择 SmartX 有几个原因,第一个原因是 SmartX 在金融行业领域的案例,我是比较看重这一点,因为金融毕竟对我们这样的传统企业来说,对厂商的选型、整体的实力、数字化转型,肯定是走在我们传统企业的前面,所以他们怎么样去深入应用 SmartX,这是我比较看重的。


金融的客户可能不会把所有的核心应用放在 SmartX 上面,但是会把相对重量级的应用逐步往 SmartX 上去做迁移,我觉得这是我在当时做选型的时候比较关注的一点。


第二点 SmartX 系统的界面,包括操作感觉是比较简单简洁。我个人认为如果是作为一个专业厂商,专业领域会做得比较深而不是做的很广。我认为 SmartX 在整个技术线,或者未来基于超融合技术线的拓展,肯定是更加专业的。


当然我们也在某些方面提出了很严苛的要求,打个比方,我们事先要求厂商提供测试机给到我们,然后在测试机上真正的去部署生产环境,同时我们也是要求在机器的下单过程中,保证一定的数量、质量和速度,那么在机器到了之后,其实我们是需要把测试环境中的应用实例,迁移到我们新购的集群当中去,这个过程中就要提供很好的服务去做支撑。


因为我们项目其实也是周期很紧,那么在这个过程中,我们真的是需要服务商去提供 24 小时的服务,这样的平台对我们来说也是一个学习的过程,我们前面可能也没有接触过超融合平台,学习也是互帮互助的过程。


我们的项目建设像是打仗一样,基本上是需要 24 小时的服务的保障。我们切换的过程都是在凌晨两三点,这样的一种时间段去做好我们应用的迁移,我觉得也是很不容易。当然首要的一个前提,是在 BIP 整个平台的迁移过程中,不能在应用层、数据层各个方面出现任何的问题。


实践篇



第一期项目的方案,其实是我们选择了 5 个节点去支撑 BIP 平台一期的项目,当然前面我也提到我们从 70 个虚拟机的一个规划,其实慢慢跑到了 200 个虚拟机这样一个资源瓶颈的点。


我觉得这也是对平台很重要的考验,因为在资源没有得到很好保障的前提下,我在超融合基础架构的平台上,跑了这么多虚拟机,我觉得从另一个方面,其实是对这个平台的信任。


整个数据中台一期的测试环境,其实我们也是放在了 5 个节点的 1 个集群里面,当然还有其它我讲到的应用环境,包括期货、人事、财务、外围应用等。


这个集群里面将近有 200 个虚拟机,发现了很多时候内存不够、硬盘不够,在这个过程中我们是去做了内存的升级和硬盘的扩容,大概在 4 个月之后,我们马上又增加了 1 个节点。


在这个过程中,也是可以感受到 SmartX 快速的服务,因为应用是爆发式的需求,SmartX 怎么样去保障性能的稳定和安全,我觉得在第一期项目上体现的非常充分,这也为我们在二期项目建设的过程中,仍旧去选择 SmartX 奠定了一个基础。


当时其实我作为一个给高层的决策者我也在思考,是不是可以搞多套的超融合集群,把核心业务的数据放在 SmartX 上,把周边的应用切出来,放到其他的超融合平台。


我们也只有一个专业的运维人员,如果是去选择多套的超融合品牌,可能对我们的学习成本,包括我们管理上的便捷程度,都会造成影响,所以综合考虑,我们二期也是继续和 SmartX 合作去深入开展。


二期我们规划的是把数据中台、大数据的平台,放到 SmartX 基础架构上,当时我们采用了三个节点,组成另外一个独立的集群,去支撑数据中台的生产应用。


为什么说一定要把业务和数据分离,当然我们当时也考虑是不是可以 6+3 组成 9 个节点的集群,但是整个集群里面,有业务中台也有数据中台,而且都是高并发高服务的情况,会产生 IO 资源的抢占。


我们当时是毅然决定第二期节点配合着我们应用的需要,把数据中台的生产环境放到了我们的第二期项目的三个节点里面。


我们和 SmartX 的合作从 2019 年底开始,大概是两年的时间,从 2021 年就到了第三期的合作阶段,第三期的合作对于我们来说非常关键和重要,因为我们到了 BIP 5.0 平台的升级过程中。


我们在业务能力的建设也是到了一个新的阶段,包括对平台性能的要求,对前端业务、核心业务响应的阶段,当时我们也是一直在考虑,怎么样去满足核心平台基础架构建设的需要。


当然有了前面这两期的项目合作,我们对整个 SmartX 平台的性能,包括各方面的服务、保障我们是相当认可的,所以说在第三期项目的合作过程中,我们毫不犹豫还是继续选择和 SmartX 合作,去建我们第三期的项目,把我们业务中台的整套 BIP 架构放到了第三套集群里面。


第三套集群里我们选择了 4 个节点全闪的方案,当然这过程中也是有很多的原因。第一为什么要选择全闪的方案,其实很多时候我们也想规避在业务应用建设过程中的性能问题,我们可以在超融合的平台上提供最优质的硬件配置,去规避到底是硬件问题还是软件问题,到底是硬件性能不足、还是软件调优不够,那么压力测试可能会非常顺畅。


在项目实施的过程中,我们也感受到硬件像闪存这样的方案,为我们平台的性能提供了很好的保障,在软件没有调优的过程当中,硬件上去之后,对我们前端用户界面级的应用感受。其实马上就有了一个量级的提升。


我们通过三期项目的建设,基本上形成了 6+3+4 三个集群组成的基础架构平台。


回过头来去看,如果当时选择公有云的方案,我觉得这个水平,预估可能会是在每年 250 万,我们选择了本地化超融合方案的投入,整体来看是接近 300 万,对于我们每年 2,000 万的数字化投资来看,目前占比还算是比较小和可控的。


当然在运维的过程中,我们统一了超融合集群平台和基础架构,我们专业的运维人员也很容易去上手这样的平台,而且可以把三个集群里面的所有虚拟机管理地很好。


我们目前来说只有一个专业的技术运维人员,因为企业的实际情况也不可能去招很多运维人员,在从单集群到多集群到几期的递增过程中,我觉得在运维这个层面上,也体现了平台的简洁,高效敏捷的功能。


在整个过程中,我觉得运行还是相对比较稳定,硬件有可能会出现硬盘的损坏、更替的情况,出现过两三次,我觉得这是正常情况。


在这样的情况下,服务商能够很快地去响应我们问题的处理,不影响整个业务正常运营开展,我觉得这方面也是得到了很好的一个验证,验证了整个基础架构平台的稳定性和服务响应的及时度。


我们现在集群部署还是在比较单一的数据中心体系之内,我们现在的社会环境、IT 环境,包括安全环境,其实是越来越复杂,那么下一个阶段我们也在考虑,我们异地容灾的备份怎么样去做,保证业务连续运营的条件下,怎么样去做好异地的容灾和备份,需要在技术层面、底层层面去提供很好的支撑。


推荐阅读:


点击阅读原文,了解更多 SmartX 行业客户超融合部署实战。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存