哈喽~又见面了大家!上两期我们说到了数据在数智化转型中的重要性以及监控在数智化转型中的角色,戳这里↓↓↓,一键回放精彩内容
2023企业数智化转型的正确打开方式是什么?他这样说(一)https://mp.csdn.net/mp_blog/creation/editor/132278203
2023企业数智化转型的正确打开方式是什么?他这样说(二)https://mp.csdn.net/mp_blog/creation/editor/132299174
这期分享我们把目光对准金融机构,将从银行的角度,带大家看看银行分布式核心智能运维体系的建设。话不多说,我们往下看。
一、云原生催生新需求
随着分布式、云原生的快速发展,新一代核心业务系统的建设呈现出井喷一般的态势。新核心带来的改变,不单单是从应用上做分布式,从基础设施到全栈的技术更新,都在经历颠覆性的变化,特别是业务对象,它不再是面向交易本身而是以客户为中心无处不在的场景服务。因此银行的业务需求变化更迭更快,这就要求开发更加敏捷、态势感知更加智能、故障定位速度更快、系统安全平稳性更高。
二、开发及运维的挑战与难点
1.DevOps组织设计难度大
新型科技交付管理体系的构建是复杂的工程,要在传统瀑布式交付向新型敏捷化交付的转型过程中,将面临技术、流程、管理和运维再造等多重挑战,这个不是一蹴而就的事情。
2.业务复杂度高
分布式微服务体系下业务需要综合考虑应用服务的拆分和数据切分的规划,具体按什么维度、什么算法去拆是一项难度系数很高的工作。
3.技术复杂度高
引入全栈式分布架构之后,整体技术的复杂度相比集中式更为复杂,对开发人员的要求更高,尤其是分布式事务的处理机制以及快速定位分析问题。
4.业务功能变更频繁
微服务化可以应对快速的市场需求变化,满足整体快速的开发和交付节奏。这要求银行需要具有OpenAPI的能力,能够迅速地与第三方场景平台进行对接,形成生态闭环,并且在高频的业务变更下,要保持高可靠、高可用和高性能。
5.专业人员相对匮乏
由于新的分布式核心业务系统复杂性高、技术迭代快,能够全面掌握相关技术,又懂业务的人员在市场端相对匮乏,需要边走边培养,坚持长期积累和迭代更新。
6.服务数量比较多
微服务化拆分后,服务的数量非常多,管理难度非常大,作为企业级资产,其功能边界的划分和共享发布都是一个很大的挑战。
三、如何应对以上难题
1.运维左移
由于新核心与老运维脱节,新核心交维衔接困难,因此在新核心体系构建的初期,如果能够左移到运维的规划阶段,是保证银行新核心业务系统稳定的理想做法。这里的核心主旨是把运维体系也作为整个核心系统建设的关键项,放到规划当中,而不是当新核心体系建成后,再对运维体系进行规划建设,以免出现数据中心无法接维的情况。
2.同步建设
书同文,车同轨。在新核心系统建设的同时,运维体系的构建也要同步进行,包括部门的组建、流程的确立、标准规范的制定、数据中心的对接、各项场景能力的打造等。这样在最终交付的时候,会是全生命周期的、完整的新核心体系,而不是单纯的一个业务系统,会使得以后的业务运营和管理真正的平稳高效。
3.数据治理前置
同步建设过程中的标准规范制定是比较重要的一环,即早期就提前做好数据治理的准备工作。由于新核心系统的建设早期还如同一张白纸,如果能根据规划,把运维数据标准(包括运维数据字典、日志规范、指标规范、错误定义等)同步制定出来,会让系统正式运营以后所产生的数据成为极具价值的固定资产。最终形成由敏捷开发平台和智能运维平台组成底座,支撑新一代分布式核心业务系统的稳定三角结构。
总而言之,作为新型的交付体系,新一代核心业务系统承载着数百个业务应用场景,DevOps敏捷开发平台为满足市场,不断开发新的业务功能,为核心业务系统提供动力。应对如此频繁的生产,同步建设智能运维平台的优势即初见成效,数据标准规范的一致更使得运维分析、定位、排障能力大幅提升,全面保障运营的高效平稳。
擎创科技,Gartner连续推荐的AIOps领域标杆供应商。公司致力于协助企业客户提升对运维数据的洞见能力,优化运维效率,充分体现科技运维对业务运营的影响力。
行业龙头客户的共同选择
了解更多运维干货与技术分享
可以右上角一键关注
我们是深耕智能运维领域近十年的
连续多年获Gartner推荐的AIOps标杆供应商
下期我们不见不散~