文章
- 产品
- 文章
本文以某股份制商业银行同城灾备数据中心搬迁为例，从数据中心布局、功能关联的宏观视角截取搬迁项目中需求分析和方案架构两个片段重构技术模型，以自身经历与思考讲一些朴素的规律，为市场上快速增长的、规模较大的数据中心搬迁需求分享新华三的咨询服务见解。
当前监管部门正在推动金融机构高质量发展，中小型银行广泛、深入的应用金融科技，坚持创新驱动发展理念，切实履行服务实体经济使命，加速数字化转型，积极适应数字经济蓬勃兴起地大势。
某股份制商业银行（以下简称为某银行）的数字化转型起步很早，是科技创新和服务创新的先行者。为了更好的支撑数字化业务发展，某银行对标先进同业，持续改造升级IT基础设施，持续加强业务连续性的建设，取得了突破性进展。
某银行同城灾备数据中心位于总行办公楼内，建成之初功能定位是生产数据中心。鉴于业务快速增长导致机房空间狭小、供电需求过大和消防安全隐患增加等成为信息科技和业务发展的瓶颈。一年前将主要生产系统迁移至总部基地数据中心之后，按照监管要求建设业务连续性管理体系，数据中心功能由生产中心变更为灾备中心。
2023年初总行办公楼退租，需将同城灾备数据中心内的生产系统、管理系统迁移至总部基地机房（自建），灾备系统、运维系统以及IT设备迁移至运营商机房（租赁），重构容灾关系，剩余的老旧设备盘点后入库。如图1所示。
在此背景之下，实施同城灾备数据中心机房整体搬迁，要求对用户的影响降到最低，保证系统业务连续性，确保搬迁过程中数据和应用系统的绝对安全。
项目成功的重要标志是：完整地恢复灾备功能，更新容灾管理体系，持续符合监管要求，需要专业容灾技术团队来保障项目成功。
因为系统之间有紧耦合关系，需要采用逻辑迁移、物理搬迁和重新部署多种搬迁方式渐进的解耦，通过搬迁还原系统部署的灵活性。
• 为满足监管要求，租赁机房要选对地址，对灾备功能的恢复至关重要。《银行业信息系统灾难恢复管理规范》（JRT 0044-2008）要求同城灾备数据中心与生产数据中心的距离在数十公里以内，可以支持实时数据复制和应用双活。
• 协同调研搬迁涉及的3个机房，统筹搬迁需求。重点调研同城灾备数据中心，深入调研生产数据中心和租赁机房。生产业务、灾备体系和监管要求使得3个机房之间有密切的关联性。只有统一调研，才能系统、完整地获取搬迁需求。调研信息的度、准确性决定了搬迁方案的科学性、合理性与可行性，进一步决定项目能否成功。
− 从项目管理视角看，牵涉内外部众多的干系人，事务繁杂琐碎，必须要抓好项目管理，制定实施计划，统一调度资源，统一管控，协同推进各项工作。这是搬迁成功的基本保证。
− 从技术视角看，涵盖了IT技术和容灾技术，改造升级IT基础架构，必须要制定搬迁设计和操作规范，以技术的标准化来应对搬迁环境的复杂性和不确定性。
− 从运维管理视角看，搬迁属于重大变更，需要对既有的运维管控机制和流程进行必要的优化和改进，更好的适应搬迁后的系统环境。
鉴于某银行搬迁项目的特殊性，搬迁需求分析方法和模型也应有所调整，采用立体、和关联的视角，面向3个数据中心，重点调研应用系统、IT环境和机房环境，统计对接资源，识别搬迁的制约因素，将丰富的调研材料按照搬迁策略以业务和灾备功能恢复为中心进行梳理、分析、归纳后得出初步搬迁需求，再通过访谈或研讨会议确认最终搬迁需求，如图2所示。本文侧重业务和ICT的需求分析。
− 业务属性：使用部门及用户，访问方式，服务时间，日常服务等级，外部合约要求，业务数据，中断影响等。
− 应用属性：应用名称与类型，运维负责人，重要性级别，关联关系，物理部署架构及资源配置，应用启停顺序和启动方式，是否需要升级，业务耦合关系等。
• ICT环境调研，分析架构优化方向，分析设备利旧，应用部署解耦，统计资源需求，优化搬迁批次。
• 应用调研。应用部署区域，融入被迁移应用，按照应用系统类别、重要性级别部署到对应的功能区域，维护应用部署的规范性。
• 机房环境调研与改造，包括机房空间勘察、功能区域规划、机柜布局设计、设备落位设计、线缆设计、供电设计和物流通道设计等，梳理改造需求。
如图3所示搬迁方案架构设计的主要依据，一是遵循总部基地数据中心（生产中心）和租赁机房（同城灾备）的功能定位，二是通过调研与访谈后确定的搬迁需求。
搬迁方案架构设计对准搬迁目标，按照业务和ICT特点设计搬迁流程、合理划分搬迁批次制定搬迁操作规范、风险评估与应急预案，共同构成搬迁方案的顶层设计，通过项目管理和技术管控的协同，推进3个机房分批次搬迁实施。
搬迁项目重复性动作较多，每一批次搬迁完成后迭代更新持续优化，如批次的微调、操作标准和应急预案的更新。
如图4所示，从IT服务角度看，数据中心迁移搬迁一般分为现状调研与分析、制定搬迁策略、规划方案架构、分批次方案设计与实施、回顾与收尾等五个阶段，五个阶段按顺序进行，其中前三个阶段是数据中心迁移搬迁项目成功的关键。没有现状调研与分析就不可能对搬迁有准确的认知和理解，就不可能制定统揽全局的正确策略，没有正确策略指导产生的方案架构就不会有好的顶层设计，有可能导致计划外业务中断、数据丢失和设备损坏等高风险事件发生，甚至项目延期。顶层设计做好了，项目成功，指日可待。
• 搬迁策略，在充分理解业务、应用和IT环境的基础上，遵守成本效益分析原则，合理规划搬迁目标、范围、批次和搬迁方式，以及搬迁周期。
− 批次划分是难点。综合多种因素权衡后才能形成最终批次划分建议，首先从业务视角审视业务连续性，错开业务高峰时间，避开跑批或监管报送的时间；其次考虑应用重要性等级、业务关联性、部署耦合关系和对接资源许可；最后还要考虑对接ICT设备和人力资源配置
− 搬迁改造是重点，租赁机房环境改造并通过监管验收，ICT架构改造。这些需要提前做计划、报预算、采购和实施。
− 每批次回顾：重点分析流程效率、操作规范的适宜性和人力资源的充分性，分析时序合理性，以持续改进；监测系统和设备运行状态，收集系统运行日志；解决遗留问题，如更换故障设备、调整备件等。
1.操作手册面向应用、数据库和灾备关系的启停操作，在批次实施流程的驱动下，明确每一步骤的操作任务、操作对象、操作步骤和操作结果，辅以操作前置条件、操作历时和操作人。
2.设备标识。目的是在设备物理就位后能够快速进行硬件系统恢复，标签要体现设备型号、用途、安装位置和连接关系。要做到设备标签、线缆标签的明确性、唯一性和易用性。
3.设备断电供电规范。要保障系统正常停止和启动，设备正常启动不损坏，数据不丢失。要制定设备下架断电顺序和上架加电顺序。
经过前面多批次的搬迁，扫清了外围应用及设备，双活流量全部迁移至总部基地生产中心，隔离了搬迁对用户的影响。搬迁进入了攻坚阶段。
某银行第三批次搬迁系统数量最多、设备最多和难度最大，搬迁灾备核心业务区、网银区、灾备重要业务区及其他区功能区域部署的系统及设备。以第三批次核心业务系统恢复为例说明搬迁时序设计的目标、约束条件和推进逻辑。
• 核心业务系统（CBS）、企业服务总线（ESB）、统一客户服务平台（UCP）、二代支付系统和网银跨行支付系统在中断后12小时内恢复。
• 交通管制要求。政府交管部门规定大型车辆23:00之后方可进入城区，限制了小型机和存储等大型设备的物流运输时间，限制了设备上架与恢复时间，最终限制了业务恢复时间。
−ICT基础架构恢复人员，细分为网络、安全、存储、小型机、X86服务器及虚拟化、数据库和中间件等多个操作小组，网络、小型机和虚拟化平台人力配备要考虑轮班。
• 灾备核心业务区以核心业务系统恢复作为主键，识别搬迁操作的关键路径，时间倒排，资源和人力投入到关键路径上。
• 遵循IT恢复逻辑。网络、存储和虚拟化平台作为共享基础环境，恢复操作设置在关键路径上。各业务系统使用的服务器及专用设备跟随业务恢复优先级操作。
• 照顾周边，并行推进，争取最大协同。设备下架、运输、上架与连线等操作遵循业务恢复优先级的前提下，并行操作，复用人力和物流资源。核心业务系统恢复时序设计如图5所示。
从22:00停服至次日10:00，核心业务系统优先恢复，企业服务总线（ESB）、统一客户服务平台（UCP）、二代支付系统和网银跨行支付系统在12小时内陆续恢复。保证了业务连续性，保障了合规性。
搬迁历时四个月，搬迁ICT设备约800台，迁移省内外分支行、人行银监局等对外机构、广域网和互联网的4家运营商提供的数十条互联专线，搬迁交易类、运维类和管理类系统约60套。在项目实施过程中保障了业务连续性，实现了应用和数据的安全，并满足了监管要求。
1. 用搬迁时间窗口同步优化了同城灾备中心的ICT基础架构，减少了重大变更导致的业务中断时间，保障了IT部门对运维的考核绩效。
2. 按照交易系统的重要性级别，采用云计算技术改造数据中心ICT架构，升级了数字化底座，提升了ICT架构服务能力，保障交易系统重要性稳定合规运行。
3. 在运维管理区引入SDN技术作为试点，为核心区和网银区传统网络的大规模SDN改造探索路径和解决方案。
4. 拆除运维系统与交易系统的物理部署资源的耦合关系，改善业务灵活性，更好地促进敏捷业务的发展，保障了互联网金融业务同城双活部署，提升用户体验。
5. 运维方面，建立同城灾备中心资产台账，更新了IT设备资产状态，优化运维流程，上线智能化运维工具，从传统运维模式向数字化运维方向迈进。