应用调研

应用调研主要是针对应用系统(业务系统)的调研,通常可以基于调研模板让应用维护或开发人员提供相关的材料。

应用系统清单

首先应获得一份所有应用系统的完整清单,应用系统清单不是一个简单的名称列表,至少应该包括以下要素:

应用系统名称 应用系统等级 应用系统分类 应用系统归属业务部门 应用系统维护负责人 应用系统开发负责人
每个应用系统一行

应用系统名称

应用系统的名称,必须是企业内部已经统一标准化的名称,如果当前企业内部还没有对应用系统名称进行标准化,则建议在这个时间点做好这件事,否则后续工作将会出现很多问题。

警示

不做好应用系统名称的标准化,后续调研、方案设计等工作,会很容易出问题。比如,你无法判断不同人在讨论的“网银系统”、“网上银行系统”、“网银交易系统”、“电子银行系统”、“网银平台系统”等等是不是在讨论同一件事。

应用系统等级

一般根据应用系统的重要程度进行分级,比如分为“重要、次重要、一般”或者“1 级、2 级、3 级”等等。

应用系统分类

可以根据需要,按“生产系统、准生产系统、开发系统”等分类,或者“同城双活系统、同城主备系统、无灾备系统”等不同维度,去进行应用系统的分类。

应用系统归属业务部门

需要明确该应用系统对应负责的业务部门,比如网上银行系统可能归属数字金融部,HR 系统归属人力资源部等等。后续进行业务测试和验证时,可以很容易找到对应部门的负责人员。

应用系统维护及开发负责人

应用系统调研、相关方案讨论和设计,以及迁移的实施,都需要应用系统维护和开发人员的支持。通常,维护人员对应用系统的部署架构、定时任务、应用启停等较为熟悉,开发人员对应用系统的程序逻辑、访问关系等较为熟悉。

应用系统基本信息

针对每个应用系统,调研时需要收集以下信息:

应用系统名称 功能简介 使用用户 使用时段 业务中断影响 中断需通知报备的对象 近期变更计划
每个应用系统一行

功能简介

简要描述该应用系统的主要功能,比如支撑 xx 业务,实现 xx 功能,处理 xx 数据,生成 xx 信息等。

使用用户

该应用系统使用的用户,比如是所有最终用户,或企业内部某个部门,或某些特定人员等等。

使用时段

该应用系统使用的时间,7×24,5×8,或某些特定时间段,比如月初或月底或每月特定时间等等。

业务中断影响

简略描述该系统若中断,将影响的业务,通常会包括该系统本身支撑的业务,以及依赖该系统的其他应用系统相关业务。

中断需通知报备的对象

当该应用系统停机时,是否需要向上级单位进行申报,或需要通知相关的单位或用户。最好还能确认通知报备的方式(正式公文、公告、邮件、电话、短信或其他方式)

近期变更计划

该应用系统在近半年或一年已计划的变更,比如大版本升级、架构调整、灾备或双活改造、系统投产或下线等将会影响迁移的变更。

应用系统部署信息

应用系统部署信息,也就是需要将应用系统的各个模块与基础架构中的服务器、虚拟机等关联起来,明确应用部署架构。

比如常见的 web、app、db 三层架构,需要确认比如 web 服务器部署在哪个服务器,app 在哪个服务器等。一般应用维护人员可以给出的是主机名、IP 地址,再用这些信息与 虚拟化及操作系统调研 中获取的信息进行匹配。

提示

有时候应用维护人员提供的主机名和 IP 地址,可能未必准确,特别是填写时容易出错。比如填写主机名为 app1 和 app2,实际主机名为 app01 和 app02,或者填写的 IP 地址为负载均衡上虚拟 IP 地址等等。此时应经过确认后,以 虚拟化及操作系统调研 中系统抓取的实际数据为准。

应用系统部署架构调研中,还需要特别注意高可用架构的调研,比如是负载均衡、主备架构,以及是通过硬件或软件实现的。如果是主备架构,还需要识别是热备或冷备,当前的主节点是哪一个。

如果当前为跨数据中心部署,也应明确应用系统在多数据中心的部署架构。

应用系统关键数据

应用系统除了程序以外,很重要的是数据。一般分为结构化数据和非结构化数据。识别关键数据,有助于后续设计数据迁移方案和进行数据保护。

数据类型 数据用途 数据容量 数据增长量 数据存储位置 数据存储路径
每种数据一行

数据类型

比如数据库数据、文件类型数据

数据用途

比如业务数据、用户数据、配置数据、临时数据、报表数据等

数据容量

当前该数据使用的容量

数据增长量

以天或月等统计,预计该数据的增长量,比如每天增加 1GB

数据存储位置

该数据当前存储的位置,比如是存储在虚拟机内,在存储设备上,在服务器内置硬盘等。

数据存储路径

该数据在操作系统内的路径目录,比如/data

应用系统关联关系

通常,应用系统不会是孤立的,一般需要与其他系统进行交互,因此需要调研应用系统的关联关系。

本系统模块 本系统端口 访问方向 对端系统 对端系统模块 对端系统端口 是否自动重连
每个连接关系一行

本系统模块

填写需与 应用调研#应用系统部署信息 一致的应用模块所在服务器的主机名或 IP 地址

本系统端口

填写本端应用开放的端口号

访问方向

是本系统访问对端系统 ->,或对端系统访问本系统<-,或双向互访<->

对端系统

对端应用系统的名称

提示

对端系统不仅仅是企业内部的系统,也包括外部的系统,比如其他单位的系统,或互联网上的某些平台。

对端系统模块

填写对端模块的主机名或 IP 地址

对端系统端口

填写对端模块开放的端口

是否自动重连

当该访问关系的一端重启后,另一端是否支持自动重新建立连接,或需要人工介入。

应用系统启停

应用系统的启停,一般主要针对启停的顺序和依赖关系,以及耗时,具体的启停操作步骤、命令,则可以在迁移当日的操作手册中体现。

如下是一个应用系统启动调研的例子

启动顺序 启动模块 预计耗时 是否关键步骤
1 DB 10 分钟
2 APP 5 分钟
3 WEB1 2 分钟
3 WEB2 2 分钟

启动顺序

用数字定义整个系统各个模块的启动顺序,如果可以并行,则可以两个步骤定义为相同的数字

启动模块

应用调研#应用系统部署信息 中模块信息一致,以模块为单位标示启动的对象

预计耗时

预计该步骤操作的时间

是否关键步骤

标示该步骤是否为恢复业务所必须的步骤,比如对于一个应用系统来说,很多时候高可用架构中的备机,或者某些管理节点、监控节点,不启动也不影响对外服务。这部分内容可以在后续迁移方案设计及应急方案设计时,能够判断哪些步骤可以暂时跳过。


阅读量: