话题背景
在企业IT基础设施中，一些系统可能因长时间运行而未能及时更新和维护，导致它们逐渐变得过时且不再可靠。这些年久失修的系统可能存在以下问题：硬件老化、软件过时、安全性漏洞频发、性能瓶颈以及不支持新的业务需求。这些问题很有影响日常运营效率。
那么有同事提出了该疑问：我们正计划对一款运营系统进行收拢和下线处理。然而，由于该系统已经长时间未进行维护，加之团队成员的频繁变动，导致许多功能的具体用途和背后的设计逻辑已经变得模糊不清。为了确保下线过程的顺利进行并最大程度地减少潜在风险，我们应该采取什么措施来重新梳理和了解这款系统的各个方面呢？
那今天就让我们来一起聊聊“年久失修的系统到底该如何做迁移？”
鹅厂工程师的看法
一、
\ dol-数据挖掘工程师 /
既然是要收拢下调的运营系统，应该主要功能都有替代平台了。
以我个人收拢/升级改造 N个老运营系统的经验，可以从以下几个方面着手：
1. 收入口：主要有下面两类
- 运营平台页面：可以通过页面访问流水（web服务器日志之类）搜集目前的用户，可以联系用户提示要关站。如页面流水定位不到用户，可以把入口页面（一般是登录页）替换成告示页，页面加上oa登录拉取用户（自己弄个html页面加个api通过太湖获取下用户，不麻烦），提示平台要迁移做好指示，同时保留一个到当前平台的跳转链接，这样搜集一段时间访客。后续关站之前也可以用这个告示页提示已关站。
- 对外的api：可以查api的监控上报，这个一般不包含人，但是可以追查上游主调ip，在通过ip找服务负责人确定api的用途和范围，是否可以下线以及替代功能api。如果没有监控上报，只能tcpdump转包捕获api调用排查调用来源ip和大致内容。
2. 查出口：主要有
- 调外部api：绝大多数api调用是为了当前平台为了完成自己功能，伴随用户访问的产生的，随着当前平台入口被拦住，这些调用会消失。需要留意平台有无类似cron任务，通过调用外部api给其他平台同步数据/状态，不过这类同步的状态/数据实际随着当前平台没有了访问量，一般也就没用了，不用太关心。
- 数据库被外部系统依赖：这种比较麻烦，只能看配置文件找用到的数据库，再联系paas平台找除当前平台以外的使用方。如果数据库连接信息hard coding到服务里面，只能是抓包大法了，相对来说抓包和分析也更麻烦。
流程上可以分为以下几个步骤：
- 先做收入口，没有用户访问/api调用了就关站（关闭页面/api入口，不下线服务，可以通过设置iptable或者其他服务器层面的操作）。
- 关站状态保持一段时间（1个月），等待可能的用户投诉，沟通解决这些遗漏点，提供替代功能。以及可能第三方系统依赖当前系统的api或者数据库 投诉没有（新）数据了之类的问题。如果只是想收拢运营平台，可以暂时不下线依赖的数据库。
- 以上问题都木有了，备份代码，服务程序和资源彻底停服。以上的流程可能会有反复，例如关站了发现有功能，有不少用户暂时没有替代，又要打开。不建议上来就看平台代码，运营平台的特点是逻辑零散，依赖复杂，历史包袱重，从代码梳理ROI太低。
二、
\ johnson-研发工程师 /
- 拔掉网线
- 看谁会找上门
若：
- 没人来找，宣布下线完成
- 有人来找，插上网线...
找日志或者监控信息，看进站出站流量，搜集页面访问和后台调用情况；没有的话，考虑在前后端配置一些监控来采集信息，然后监测之；找到DB，捋一遍数据的最后更新日期，事务日志等信息，帮助对访问情况做一个大致的估计；通过前序获得的信息，找到用户群体，搞清楚系统的功能，判断是否能下线，讨论下线后的后续接续方案等等....
三、
\ xavier-开发工程师 /
如果是针对收拢下线旧系统迁移用户到新系统的场景，个人建议可以尝试以下几个步骤：
1. 信息收集
- 收集现有系统的相关文档，如开发文档、tapd需求、用户手册等，尽可能理解旧系统的需求场景。
- 系统日志收集分析，对旧系统做一些日志埋点，识别系统的高频功能操作场景及用户信息。
2. 策略及实施
- 优先级排序，根据业务功能重要性，为各个功能模块设置下线优先级、时间表和里程碑。
- 信息沟通，根据前期收集的用户信息，建立支持渠道，及时通知目标用户旧系统下线时间节点及平替迁移方案，后续也可即时响应用户下线过程中遇到的各种问题。
- 风险管理，识别下线过程可能存在的风险点，并制定相应的应对措施。
注意事项：
- 在整个过程中要保持与关键利益相关者(核心目标用户)的沟通渠道，确保项目的顺利进行。
- 考虑到用户可能的迁移成本，下线的过程可能存在反复，要有相应的措施预案，耐心协助用户顺利完成迁移。
四、
\ esword-架构工程师 /
- 透视出系统页面/API与调用用户的关系，重新管理用户组
- 重新开发一套系统和接口，灰度关闭旧接口
五、
\ sai-开发工程师 /
1. 快速了解系统功能：找到访问来源和核心功能分布
从系统的访问来源上看，一般可以分为两类：后台API调用、WEB页面访问
(1) 通过日志分析平台，找到最近3个月的核心API+访问IP
- 根据API访问排行，着重从访问量大的接口开始，做为核心API
- 访问IP是为了找到访问方，便于下面的统一拉群通知
- 如果现状没有接入日志分析平台，可以先从后端增加一些简单的日志：API名称、访问IP、输出输出日志
(2) 拆分系统功能类型：从任务流的设计上看，系统任务分为两大类：同步任务，异步任务。
- 同步任务：一个任务接口内，直接获取到执行结果
- 异步任务：创建任务、监控任务执行结果
2. 进一步了解功能：通过绘制流程图、DB日志、代码日志加深系统理解
(1) 用流程图梳理：核心API内的大致访问关系链，加深对系统链路的理解
(2) 通过DB的访问日志，可以找到使用的表，通过表结构和数据内容进一步了解系统功能
如果是云数据库，以腾讯云数据库为例，可以在控制台导出后端链接数据库的日志（增删改查日志）
(3) 在核心API内，增加详细日志
- 当前系统访问其他外部API打印日志
- 定要打印输入输出日志，切换一旦遇到异常，可以快速比对处理
- 核心API内不，补充更多详细日志，加深对系统功能理解
(4) 在进一步了解系统功能过程中，整理输出相关文档，准备下线
3. 切换访问来源，平滑下线
(1) 下线前
- API用户：根据IP在公司的服务器管理平台上找到服务器负责人，拉群通知
- WEB用户：强制弹窗提示公告，当天用户使用的时候，需要点击确认知晓
(2) 下线中
- 整理替换指引，给到用户做参考。
比如：api替换指引，WEB页面替换指引
- 统计当天访问量，标记下线切换完成
整理输出访问的在线表格，逐步跟进切换下线结果
六、
\ keson-生态技术工程师 /
可以先本地升级下，更新下系统内核和驱动lib库等，然后再通过迁移工具进行在线迁移升级
