目前随着云化技术的发展，采用分布式架构的新核心业务系统成为大部分银行的选择，在新系统切换上线之后运维工作是如何进行的？存在哪些问题与痛点？Q：面向分布式核心业务系统，您当前在生产运维的最大挑战和诉求有哪些？摘选回复1：1.计算资源和数据库资源需求量大，物理机上线量大，占用机房机柜资源多，对整云的规模造成挤占。2.出于外部机构对于交易链整体耗时的要求，分布式核心对延时较为敏感，需优化不合理的路径。摘选回复2：首次使用分布式方式部署核心系统，运维方式都比较新颖，存在一定的磨合期和适应期，需要在最短时间内掌握相关运维手段和方式，以应对生产故障事件尽快解决。摘选回复3：1、分布式核心业务系统架构下，系统组件间相互依赖、虚拟机和容器基础资源使用数量相较于小型机数量指数增加，这对于监控、自动化运维、业务流管控都提出了更高要求。Devops需要更熟练的应用才能做好基础资源的使用和下发。2、分布式核心业务系统的改造与国产化（XC、关基）同步进行，从以前标准化比较高的IOE 国外厂商设备和软件栈切换到国产化设备软件，特别是分布式数据库、系统厂商自研的中间件平台产品，这些产品没法做到大规模使用、高强度业务测试的情况，如果让运维团队较快熟悉并上手主动运维（不依赖厂商力量）成了很大的问题。3、对于一般核心业务系统使用年限为5-10年，当前这样分布式核心业务系统是否可以在厂商的不断迭代下完成生命周期的演进，保证运维支持及时有效，并且在容量管理的基础上做到合理的资产投入，也是生产运维的重要的考量点之一。摘选回复4：1.运维工作量大：信创改造尤其明显，目前是两地三中心，面对分布式系统，要做3次部署工作量巨大。2.运维压力大：一个系统多的时候有百台以上的服务器，出现告警后要定位问题难度较大，需一线隔离，二线拉上技术人员应急处置，经常在半夜处理问题。3.运维平台功能较少，没法直观查看服务器状态等信息。4.不够智能：误报问题多，运维平台只能通过配置，不能智能分析是不是管理系统引起的或是节假日引起交易量下降等。5.数据同步：A类系统要求高，需要准实时数据同步，对数据同步及备份要求高。摘选回复5：管理的系统节点太多，无统一视图，节点定位困难。Q：请说明下您当前生产环境应用部署流程及部署工具平台现状是怎样？存在哪些痛点？摘选回复1：软件中心项目组提出应用上线需求，数据中心各部审批资源需求，调度部组织各部和项目组开上线会并派变更单，设备部在**云aop平台创建ECS资源和安装镜像，网络部创建SLB和域名资源，系统部创建数据库和中间件，安全部回收运维账号，最后交付项目组。摘选回复2：传统的使用云管平台，新的使用**云，目前正在部署中。存在测试环境和生产环境不一致的情况，需要打通相关环节。资源性能容量9都是一个痛点，存在冷热不均匀的情况，需要提高总体使用率，或者动态扩容缩容的能力。摘选回复3：依赖自研的运维支撑平台，实现配置变更的自动化、标准化、图形化，针对Paas层业务资源可以通过服务目录自动下发，把对于组件的配置、监控、运维做到了统一管理，优化配置中心、注册中心能力实现业务自动化负载和调度，提供灰度发布、蓝绿发布的能力可以分配次完成业务升级、轮替、版本回退、故障隔离，实现系统有效稳定运行。摘选回复4：生产环境应用部署流程：1.上线前项目组完成本车投产内容的安全扫描等工作，将版本推送至行内版本机。2.版本机进行二次安全扫描，无问题后，待投产版本点前下发至目的机器。3.系统经理使用项目组提供的自服务流程完成应用部署，其中也有特殊情况，如首次部署则需要手工部署。4.部署后进行投产后验证，数据快照及版本封存等操作。部署工具平台现状：使用了自研的部署工平台，用自服务流程即可。存在痛点如下：1.自服务脚本需项目组在VT环境验证，平台无法准确知道语句是否有问题，这里说是命令是否正确，和业务逻辑无关。平台过于落后了，需要升级一下。2.平台性能问题：在较大的投产点会存在严重的卡顿问题，存在推包至服务器失败的情况严重，点了自服务后，无法进行变更，严重影响生产安全。Q：面向分布式核心业务系统，当前是否有统一的生产运维平台？告警及问题定位是如何处理的？摘选回复1：依赖云平台各产品告警和应用交易告警。摘选回复2：正在建设新一代云平台。告警使用数据库管理平台、应用可用性监控、网络solorwinds监控等手段来告警及定位。摘选回复3：传统的生产管理平台已经无法满足分布式技术的复杂运维要求，分布式核心系统的复杂性和多样性需要有统一管理平台。告警和问题定位依赖  核心业务系统的从硬件到软件的可观测性监测系统的建设，包括涉及基础设施层、应用软件层、业务层，囊括告警、日志、业务配置及状态，借助分布式架构的熔断、隔离机制实现单元内业务自愈和流量切换并减少故障半径。摘选回复4：有统一的生产运维平台。告警生成一般分为两种情况：1.硬件本身问题，通过监控平台发现后，完成定位。监控平台会首先初步隔离处理，相关工程师立刻接入完成修复或替换，重新接入，监控无问题后，形成事件工单，对问题梳理和复盘完成结束工单，完成处理。2.系统本身问题，这里的情况就复杂很多，发现问题一般是通过交易监控平台的安全基线判断是否系统正常工作，安全基线是AI学习和系统经理配置共同设定，发现问题会先拉会，会上有系统负责人，技术部门人员及上下游系统人员一起参加，带问题修复后，完成处理。这里就会有考核等，完成处理。Q：当前是否有应用AI手段来提升运维能力？如果有请具体说明相关的场景摘选回复1：已部署ds、大数据运维等AI手段辅助运维，用来收集产生相关报表或回答日常运维问题，也能自动在相关社区目录里自动检索。摘选回复2：通过AI 手段优化常规预警，对告警、日志做根因分析合并，减少告警输出，提供有逻辑性指向的重要告警。通过周期性分析，提供各类资源、性能的预测，实现长周期符合业务实际的容量管理。可以提供更多自定义、多维度的拖拽视图展示，方便运维人员的日常管理和操作。摘选回复3：有使用AI手段来提升运维能力，具体场景如下：1.自主学习安全基线，通过系统一段时间的运行数据，及服务器的使用情况，生成安全基线。对发现系统异常情况有很大帮助。2.预测机制，AI会根据往期事件形成机器可能出现的问题，如更换硬件，或预测CPU、内存会在多久后形成瓶颈。3.辅助定位问题，将日志输出给AI，初步定位问题。4.日志监控，AI读取error日志，辅助系统经理监控系统情况。摘选回复4：通过AI分析现状，出现网络节点故障的可能性，辅助运维原贴链接