DB32T 金融机构信息科技系统运行维护自动交付规范.docx
- 文档编号:1870328
- 上传时间:2022-10-24
- 格式:DOCX
- 页数:13
- 大小:22.70KB
DB32T 金融机构信息科技系统运行维护自动交付规范.docx
《DB32T 金融机构信息科技系统运行维护自动交付规范.docx》由会员分享,可在线阅读,更多相关《DB32T 金融机构信息科技系统运行维护自动交付规范.docx(13页珍藏版)》请在冰豆网上搜索。
DB32T金融机构信息科技系统运行维护自动交付规范
DB32T金融机构信息科技系统运行维护自动交付规范
本标准起草单位:
苏州银行股份有限公司、中国人民银行苏州市中心支行、中国人民银行盐城市中心支行。
本标准主要起草人:
张小玉、李微羽、张振兴、许燕刚、姜静、卜家怡、钱卫星、魏晋、周秋亭、谢凯、黄海、石刚、周桢骑。
金融机构信息科技系统运行维护自动交付规范
范围
本文件规定了金融机构信息科技系统运行维护自动交付过程中的术语和缩略语、总述、环境管理、数据管理、配置管理、构建与持续集成、测试管理、部署与发布管理及度量与反馈。
本文件适用于江苏省各金融机构单位提升运行维护自动交付能力的建设。
规范性引用文件
下列文件对于本文件的引用是必不可少的。
凡是注日期的引用文件,仅所注日期的版本适用于本文件。
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T28827.2-20__信息技术服务运维维护
GB/T32399-20__信息技术云计算参考架构
GB/T32400-20__信息技术云计算概览与词汇
GB/T33136-20__信息技术服务数据中心服务能力成熟度模型
YD/T2441-20__互联网数据中心技术及分级分类标准
总则
持续交付是一种持续的将各类变更(包括新功能、缺陷修复、配置变化、实验等)安全、快速、高质量地落实到生产环境或用户手中的能力,信息科技系统运行维护自动交付是持续交付的必要手段,在应用软件集成交付环节,从环境管理、数据管理、配置管理、构建与持续集成、测试管理、部署与发布管理、度量与反馈七个方面(如表1所示),保证软件持续顺畅、高质量的对用户完成发布。
表1自动交付分级技术环节
持续交付
环境管理
数据管理
配置管理
构建与持续集成
测试管理
部署与发布管理
度量与反馈
环境类型
选择
测试数据管理
版本控制
构建实践
明确测试分层策略
部署与发布模式
度量指标
环境构建
数据变更管理
变更管理
持续集成
代码质量管理
部署流水线
度量驱动改进
环境依赖与配置管理
自动化测试
环境管理
环境类型选择
研发环境的种类宜具有齐备性,并能满足不同阶段业务需求的能力,具体要求如下:
宜建立全面的测试与灰度环境包括:
开发环境,技术测试及业务测试环境以及灰度发布环境等;宜根据业务与应用的需要,弹性分配各类环境。
环境构建
应从交付过程和交付速度中体现生成方式和交付能力,具体要求如下:
环境构建宜通过自动化来完成;环境准备时间小时级,如环境的构建可以通过容器化快速交付,则环境准备时间分钟级;环境的构建宜通过自服务的资源交付平台来完成;环境宜根据业务及应用架构弹性构建。
环境依赖与配置管理
通过环境所依赖的内容的识别和管理,以及环境变更的有效跟踪反馈的方法,宜确保环境的一致性和受控,具体要求如下:
宜通过配置管理工具实现操作系统级别的依赖管理,如操作系统版本、组件版本、程序包版本等;以应用为中心,建立服务级依赖的配置管理能力,如依赖的关联服务,数据库服务、缓存服务、关联应用服务等;环境和依赖配置管理宜实现代码化描述;宜具备实例级的动态配置管理能力,根据业务和应用架构弹性变化。
数据管理
测试数据管理
数据来源
通过测试数据的生成方式,可产生用以满足不同测试类型需求的数据来源,具体要求如下:
导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集;部分测试用例专属的测试数据宜按需通过模拟或调用应用程序API的方式自动生成。
数据覆盖
通过测试数据对于各种测试类型需求的支持能力可实现数据覆盖,具体要求如下:
宜建立体系化测试数据,进行数据依赖管理,覆盖全部测试分层策略要求的测试类型;测试数据宜覆盖安全漏洞和开源合规等需求场景;宜定期更新机制,持续优化数据管理方式和策略。
数据独立性
测试数据在测试执行各阶段的完整性和一致性,不应受到其他任务执行结果的影响,以确保数据独立性,具体要求如下:
测试数据宜明确备份恢复机制;宜实现测试数据复用和保证测试一致性;宜对测试数据分级,形成元数据和测试用例专用数据;测试用例的执行不应依赖其他测试用例执行所产生的结果数据,每个测试用例宜拥有专属的测试数据,具备明确的测试初始状态。
数据变更管理
变更过程设计
通过数据库相关信息的更新方法和实现机制确保变更过程,具体要求如下:
数据变更宜作为软件发布的一个独立环节,单独实施和交付;宜使用自动化脚本完成标准的数据变更;宜将数据变更纳入持续部署流水线,经人工确认后自动完成;应用程序部署和数据库变更宜解耦,可单独执行;宜建立持续优化的数据管理方法,持续改进数据管理效率。
兼容回退
通过数据库变更的向下兼容性以及回退变更的能力和方法确保兼容回退,具体要求如下:
宜建立数据库和应用的版本对应关系,并持续跟踪版本变更;每次数据变更宜提供明确的回退机制,并进行变更测试,如提供升级和回退自动化脚本;数据变更宜具备向下兼容性,支持保留数据的回退操作和零停机部署。
数据监控
通过对数据变更过程的日志、状态、指标的收集、分析及决策的能力确保数据监控,具体要求如下:
宜收集和分析数据变更日志,实现变更问题快速定位;宜针对不同环境和重要程度对数据变更建立分级监控机制;宜对数据变更进行监控,发现和修复异常变更;宜持续监控和优化数据变更机制。
配置管理
版本控制
版本控制系统
通过记录一个或若干文件内容变化,能够查阅特定版本修订情况的版本控制系统,具体要求如下:
宜使用统一的版本控制系统;宜将全部源代码纳入版本控制系统管理;宜将配置文件、构建和部署等自动化脚本纳入版本控制系统管理;宜建立健全的版本控制系统管理机制,包括:
代码库命名规范、备份与可用性保障机制、权限专人专岗管理等;宜将数据库变更脚本和环境配置等纳入版本控制管理;版本控制系统相关操作宜以自动化的方式实现,而非手工操作;宜建立针对版本控制系统的度量与监控机制;宜将软件生命周期的所有配置项纳入版本控制管理;宜持续优化版本控制系统。
分支管理
通过对软件研发过程中的分支和集成策略的管理(分支策略代表了研发协作方式)实现分支管理,具体要求如下:
分支可以频繁地向主干合并;主干随时可进行指定版本的测试和发布;可以针对不同业务和技术要求,选用不同的分支策略,在指定时间发布;特性代码可按需合并到主干进行验证和发布;宜建立持续优化的分支管理机制。
制品管理
通过对软件研发过程中生成产物的管理,即作为最终交付物完成发布和交付的制品管理,具体要求如下:
宜使用统一的制品库管理构建产物;应具备清晰的存储结构且有唯一版本号;宜通过统一的制品库地址进行构建产物分发;应将依赖组件纳入制品库管理;制品库读写应建立清晰的权限管控制度;宜对制品库完成分级管理以建立体系化的制品库管理策略,包括:
备份与恢复机制、制品库完整性与一致性保障机制等;宜持续优化制品管理机制。
单一可信数据源
通过信息数据模型和关联模式,保证每个数据元素只存储一份,确保数据的一致性的单一可信数据源,具体要求如下:
开发测试部署环节所用到的源代码应来源于统一版本控制系统;版本控制系统和制品库应作为单一可信数据源,覆盖部署环节;单一可信数据源应贯穿整个研发价值流交付过程;在组织内部宜开放共享,建立知识积累和经验复用体系。
变更管理
变更过程设计
通过变更的触发条件和实施手段,覆盖完整生命周期的变更过程,具体要求如下:
应建立包括代码和基础设施配置项的基线;应使用统一的变更管理系统,所有配置项变更由变更管理系统触发;应针对重点变更内容进行评审;宜记录代码变更管理信息;应建立变更的分级评审机制;变更管理过程宜覆盖从需求到部署发布全流程;针对每次变更内容宜进行评审,尽可能使用自动化手段;宜建立可视化变更生命周期,支持全程数据分析管理。
变更追溯
通过变更相关信息和状态的识别和查询,包括变更人员、变更时间、变更原因、变更内容等进行变更追溯,具体要求如下:
应清晰定义版本号规则;宜实现制品和代码基线的关联,可追溯指定版本的完整源代码信息;宜实现版本控制系统和变更管理系统的自动化关联,信息双向同步和实时可追溯;变更依赖关系宜被识别和标记;宜实现数据库和环境变更信息的可追溯;宜实现从需求到部署发布各个环节的相关全部信息的全程可追溯。
变更回退
通过将变更恢复到变更之前状态的变更回退,具体要求如下:
宜实现变更管理系统和版本控制系统的一同回退,保证状态的一致性;回退操作宜实现自动化;宜自动化回退全流程的所有变更包括变更依赖;宜准备经过验证且可接受的其它补偿或应急措施以应对不适用回退的场景。
构建与持续集成
构建实践
构建方式设计
通过源代码转变为可运行程序的方法和过程的构建方式,具体要求如下:
宜采用脚本实现构建过程自动化;宜定义结构化构建脚本,实现模块级共享复用;构建脚本应由专人统一维护(可兼职);宜实现构建方式服务化,可按需提供接口或用户界面,将构建能力赋予整个研发团队;宜按场景实现构建过程可视化编排;宜持续优化构建服务平台,持续改进服务易用性。
构建环境搭建
通过构建实际运行过程的设备和资源依赖的载体的构建环境,具体要求如下:
宜建立独立的构建服务器,多种任务共用构建环境;构建环境配置应实现规范化;宜建立独立的构建资源池;宜持续改进构建环境以提高构建效能。
构建计划明确
通过构建被触发的方式,频率和编排过程,具体要求如下:
宜细分构建类型,如发布构建、测试构建;宜明确定义构建计划和规则,并在团队内共享;宜实现定期自动执行构建和代码提交触发构建。
明确构建职责
通过构建相关工具,系统和过程的责任主体职责,具体要求如下:
构建工具和环境宜由专门团队维护并细分团队人员职责;宜构建实现自服务,将构建能力赋予全部团队成员,并按需触发构建实现。
持续集成
搭建集成服务
通过持续集成运行的系统和环境,以及集成团队的职责划分的集成服务,具体要求如下:
宜搭建统一的持续集成服务;宜组建专门的持续集成团队,负责优化持续集成系统和服务模板;宜实现持续集成服务化和自助化,研发团队可自行使用持续集成服务;宜持续优化和改进团队持续集成服务,提升组织交付能力。
集成频率设定
研发编写的源代码向代码主干分支合并过程的方法和实施频率,具体要求如下:
研发人员宜具备每天向代码主干集成一次的能力;研发人员宜具备每天多次向代码主干集成的能力,可按需集成任何变更(代码,配置,环境)。
集成方式明确
通过代码集成的触发条件和集成过程中的环节及输入输出的集成方式,具体要求如下:
在部分分支上宜进行每天多次的定时构建;每次代码提交宜触发自动化构建,构建问题通过自动分析,精准推送相关人员处理;每次代码提交构建宜触发自动化测试和静态代码检查;发现测试问题宜自动提醒;测试结果应作为版本质量强制要求,如采取质量门禁等方式强化主干代码质量;应实现持续集成下的自动化测试分级,如单元测试、SIT、UAT。
测试管理
明确测试分层策略
分层方法选择
通过测试体系按照不同的测试对象,类型进行分类聚合的方法,每一层对应了特有的测试需求分层方法,具体要求如下:
宜采用接口/服务级测试对模块/服务进行覆盖全面的接口/服务测试;宜采用探索性测试方法对需求进行深入挖掘测试;系统宜全面进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试;宜采用代码级测试对核心模块的函数或类方法进行单元测试;宜采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试;宜采用测试驱动开发的方式进行代码级、接口级测试(TDD);宜采用验收测试驱动开发的方式进行用户/业务级的UI测试(BDD/ATDD)。
分层策略建立
通过基于测试分层策略对每部分的测试比重和投入,以及覆盖度等的划分策略分层策略,具体要求如下:
宜建立测试分层策略;测试设计宜对接口/服务级测试为
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- DB32T 金融机构信息科技系统运行维护自动交付规范 金融机构 信息 科技 系统 运行 维护 自动 交付 规范