张安安-CMDB 大模型赋能下的证券行业持续部署实践

CMDB大模型赋能下的证券行业持续部署实践 张安安DevOps架构师 姓名：张安安 公司职位：中金财富证券有限公司DevOps架构师 目前主要负责中金财富DevOps平台的建设和管理，参与制定中金财富DevOps管理规范，明确分支管理，代码评审，制品管理，工程管理等细则，并将规范结合到DevOps平台。同时赋能公司各个团队的工程教练，一起落地持续集成，持续部署相关规范 01为 什 么 基 于C M D B大 模 型建 设 持 续部 署 02基 于C M D B大 模 型 的 持 续 部 署优 势 03建 设 持 续 部 署 过 程 中 遇 到 的问 题 04心 得体 会 PART 01 为什么基于CMDB模型建设持续部署 1.什么是持续部署 持续部署概念 DevOps中的持续部署是一种软件开发实践，旨在自动化软件的发布和部署过程，以实现快速、频繁且可靠的软件交付，通过自动化工具和流程来实现，将开发人员和运维团队紧密结合在一起，提高交付速度和响应能力。 持续部署与传统手工部署相比具有的优势 •能够更频繁地将新功能推向市场，快速响应客户需求•稳定可靠的自动化部通过自动化监控和反馈机制提供了更多的可见性和透明度，使得团队可以更好地了解软件开发和部署过程中的情况署流程，可以减少人工干预，降低部署错误的风险•持续部署通过自动化流程和工具集成，促进了开发团队、运维团队和其他相关团队之间的协作和交流•通过自动化测试等手段，更早发现和解决问题，同时节省了时间和人力成本，提高了整体的生产效率，使需求可以更快地交付到生产环境中，达到快速交付 2.公司现状 Q突出的问题 公司架构混乱 1.不能清晰查看公司各个团队应用与应用，应用与部署资源之间的关系，无法合理规划和调整公司各个团队应用以及资源的部署策略2.大部分系统架构不能适应业务变化，无法快速调整和扩展 上线变更风险不可控 1.缺乏各个业务系统的基本信息，重要系统变更难以找到对应关联系统的负责人、部门领导审批，导致上线变更后上下游系统报错 2.重要系统便跟没有编写变更方案，或者编写了变更方案，但是未经过运维负责人，风险管理部等审批3.存在少量需求临时不上线，但未重新提交上线变更单 开发与运维人员协作效率低 1.多应用发布，需要很多人工干预（例如确定各个应用部署、脚本执行顺序等），部署效率较低2.运维人员未参与部署计划评审，且使用工具存在差异 结合公司现状，我们发现持续部署无法解决公司存在的所有突出问题，由此我们引入基于CMDB大模型，结合两者的优势 PART 02 基于CMDB大模型的持续部署的优势 优势1：统一公司系统架构 通过对团队进行深入调研，我们得到CMDB六层架构（系统-子系统-环境-应用-集群-模块）可以适用绝大部分团队。通过持续部署平台固化操作流程，让接入平台的系统默认适配CMDB六层架构 系统拓扑 基于统一的系统架构，CMDB可以提供关于系统、子系统、环境、应用以及模块的详细信息•我们生产各个系统拓扑图，方便用户可以详细查看应用与应用、应用与部署资源之间的关联关系•根据系统拓扑图，合理规划和调整应用以及资源部署策略 优势2：架构支持调整和拓展 •当需要新建一个k8s集群发布部署单元时，用户可以通过持续部署CMDB模型的新建流程自动创建•当业务发生变化，例如荣超某k8s集群需要迁移时，用户可以提交OA审批单，审批单会自动获取CMDB当前集群负责人，业务负责人进行审批，审批通过之后，则成功修改CMDB属性，同时平台将对应集群移到到指定节点下 优势3：充分暴露上线变更风险 上线范围评审 持续部署平台从DevOps平台同步需求清单，质量内建报告等评审材料，然后从CMDB模型获取项目经理，产品经理等人员信息，自动生成上线范围评审单，依次对需求范围，报告等进行评审如果某一需求临时不上线，则需重新选择制品，提交上线范围再次评审 上线变更评审 重要系统上线范围审批通过之后，继续从CMDB模型自动获取相关系统运维负责人，产品负责人，部门领导等信息发起OA变更申请单，对上线方案，变更策略，风险，时间等进行评估，评估通过之后方可执行生产部署 优势4：复杂场景编排 发布单元：由持续集成流水线编译构建之后，打包生成的制品产生 部署单元：单个发布单元结合资源环境构成的最小应用。发布单元被部署在某个环境后则被称之为部署单元。一个发布单元可能对应多个部署单元 编排流程 •维护模块（部署单元）相关部署相关信息之后，针对单个部署单元即可执行部署 •针对复杂应用部署，用户就可以根据项目需要，编排此次服务各个部署单元串行及并行顺序。以应用A（包含数据库、后端、前端）为例，需要同时变更虚拟机以及K8S容器，顺序为先变更数据库，再变更后端，最后变更前端，则可以按下图进行编排 优势5：增强开发与运维之间协作 统一使用持续部署平台作为开发、SIT测试、UAT测试，生产环境的部署工具，开发人员与运维人员一起参与建设部署流程（自动接入监控告警，CMDB信息的自动同步与更新等） 提升效率与质量 重要系统变更，开发人员需编写详细的变更方案，阐明实施方案，验证方案，应急方案等，运维人员必须参与评审 CMDB提供了关于基础设施、应用配置等方面的准确信息，确保开发和运维过程基于一致的应用配置数据，提高沟通效率 上线变更过程中，此次变更相关的所有记录都可以追溯，确保生产部署流程，部署脚本等都在测试环境得到充分验证 基于CMDB中的配置信息建立监控基线，当某个指标超过基线值，则及时通知运维人员和开发人员，从而能快速解决 PART 03 建设持续部署过程中遇到的问题 难点1：公司系统架构难以统一 主要问题 公司团队众多，不同业务领域有不同的需求和特点 大团队系统规模较大，业务复杂，统一架构难度较高 开发，测试，运维等不同角色视角不同，关注的重点不同，对部署的理解以及重视程度也不同 如果系统架构由平台统一创建，则需要配合团队实时调整，维护量过大；如果完全由用户自主创建，则系统架构最终将各不相同，难以建立关联关系。通过DevOps团队内部讨论，最终我们选择通过持续部署平台固化流程，协助用户创建系统架构。用户可以自主新建和调整架构，但还是遵循CMDB六层架构的规范，从而保证用户接入持续部署平台，就默认使用CMDB六层架构 依据平台实现架构统一 •系统：项目立项成功之后，持续部署平台自动同步并创建•子系统：项目立项成功之后，在持续部署平台自动创建审批单，平台管理员审批通过后即可自动创建对应工程（包含持续部署，gitlab，Artifactory，SonarQube等）•基于子系统，用户通过持续部署新建流程，自主创建环境、应用、集群、模块 难点2：确保CMDB数据准确性 如何确保CMDB数据准确性 作为自动化运维最重要的基础，必须保证数据准确性，才能发挥CMDB数据的价值，如何保证CMDB数据准确成为重中之重 平台自动检查 通过以下4项指标定期对数据进行审核，输出数据质量报告。对不符合要求的数据，通知对应owner进行修正。实现数据质量从人工分析转为自动检查、人工审核的方式 •属性完整性:：检查CMDB模型的必填字段是否存在空值•属性规范性：检查资源字段是否符合管理规范要求，比如字段长度，字段类型等•关联完整性检查：检查CMDB模型的关联关系，例如模块没有关联主机或服务实例，则存在异常•关键信息变更需进行审核：关键信息的修改，平台会主动发起OA审批，相关人员审批通过之后，修改成功 PART 04 心得体会 心得体会 1.明确部署全流程准入准出 用户推广过程中，需明确发布流程各个阶段的准入准出，不同角色各司其职，相互协同，完成持续部署全流程，减少不必要的延误和错误 心得体会 2.培养公司内部文化 团队成员需要学习和接受持续部署之初，会接触很多规范，培养DevOps文化之后团队成员才能明白自动化、团队协作以及遵守部署规范的重要性，并积极参与其中 团队成员一开始对于这种新的工作模式和流程存在一定的抵触情绪。需要通过组织培训、分享成功案例，知识库，公众号等方式多方位宣传，才能让大家逐渐理解和接受持续部署的理念，从而积极践行 积极鼓励团队成员提出自己的想法和建议，共同参与到持续部署的运作中来；同时鼓励团队成员分享技术知识、经验教训和最佳实践，提升公司整体的能力水平。 高效运维社区DevOps时代 荣誉出品 感谢大家观看