应用调研
应用调研主要是针对应用系统(业务系统)的调研,通常可以基于调研模板让应用维护或开发人员提供相关的材料。
应用系统清单
首先应获得一份所有应用系统的完整清单,应用系统清单不是一个简单的名称列表,至少应该包括以下要素:
| 应用系统名称 | 应用系统等级 | 应用系统分类 | 应用系统归属业务部门 | 应用系统维护负责人 | 应用系统开发负责人 |
|---|---|---|---|---|---|
| 每个应用系统一行 |
应用系统名称
应用系统的名称,必须是企业内部已经统一标准化的名称,如果当前企业内部还没有对应用系统名称进行标准化,则建议在这个时间点做好这件事,否则后续工作将会出现很多问题。
不做好应用系统名称的标准化,后续调研、方案设计等工作,会很容易出问题。比如,你无法判断不同人在讨论的“网银系统”、“网上银行系统”、“网银交易系统”、“电子银行系统”、“网银平台系统”等等是不是在讨论同一件事。
应用系统等级
一般根据应用系统的重要程度进行分级,比如分为“重要、次重要、一般”或者“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 分钟 | 否 |
启动顺序
用数字定义整个系统各个模块的启动顺序,如果可以并行,则可以两个步骤定义为相同的数字
启动模块
与 应用调研#应用系统部署信息 中模块信息一致,以模块为单位标示启动的对象
预计耗时
预计该步骤操作的时间
是否关键步骤
标示该步骤是否为恢复业务所必须的步骤,比如对于一个应用系统来说,很多时候高可用架构中的备机,或者某些管理节点、监控节点,不启动也不影响对外服务。这部分内容可以在后续迁移方案设计及应急方案设计时,能够判断哪些步骤可以暂时跳过。
阅读量: