话题背景
那今天就让我们来一起聊聊“年久失修的系统到底该如何做迁移?”
鹅厂工程师的看法
1
dol-数据挖掘工程师 /
既然是要收拢下调的运营系统,应该主要功能都有替代平台了。
一. 收入口:主要有下面两类
先做收入口,没有用户访问/api调用了就关站(关闭页面/api入口,不下线服务,可以通过设置iptable或者其他服务器层面的操作)。 关站状态保持一段时间(1个月),等待可能的用户投诉,沟通解决这些遗漏点,提供替代功能。以及可能第三方系统依赖当前系统的api或者数据库 投诉没有(新)数据了之类的问题。如果只是想收拢运营平台,可以暂时不下线依赖的数据库。 以上问题都木有了,备份代码,服务程序和资源彻底停服。 以上的流程可能会有反复,例如关站了发现有功能,有不少用户暂时没有替代,又要打开。不建议上来就看平台代码,运营平台的特点是逻辑零散,依赖复杂,历史包袱重,从代码梳理ROI太低。
2
johnson-研发工程师 /
1.拔掉网线
2.看谁会找上门
若:
没人来找,宣布下线完成
有人来找,插上网线...
找日志或者监控信息,看进站出站流量,搜集页面访问和后台调用情况;
没有的话,考虑在前后端配置一些监控来采集信息,然后监测之;找到DB,捋一遍数据的最后更新日期,事务日志等信息,帮助对访问情况做一个大致的估计;通过前序获得的信息,找到用户群体,搞清楚系统的功能,判断是否能下线,讨论下线后的后续接续方案等等....
3
xavier-开发工程师 /
如果是针对收拢下线旧系统迁移用户到新系统的场景,个人建议可以尝试以下几个步骤:
一:信息收集
收集现有系统的相关文档,如开发文档、tapd需求、用户手册等,尽可能理解旧系统的需求场景。
系统日志收集分析,对旧系统做一些日志埋点,识别系统的高频功能操作场景及用户信息。
二:策略及实施
优先级排序,根据业务功能重要性,为各个功能模块设置下线优先级、时间表和里程碑。
信息沟通,根据前期收集的用户信息,建立支持渠道,及时通知目标用户旧系统下线时间节点及平替迁移方案,后续也可即时响应用户下线过程中遇到的各种问题。
风险管理,识别下线过程可能存在的风险点,并制定相应的应对措施。
注意事项:
在整个过程中要保持与关键利益相关者(核心目标用户)的沟通渠道,确保项目的顺利进行。
考虑到用户可能的迁移成本,下线的过程可能存在反复,要有相应的措施预案,耐心协助用户顺利完成迁移。
4
esword-架构工程师 /
5
sai-开发工程师 /
二、进一步了解功能:通过绘制流程图、DB日志、代码日志加深系统理解
6
keson-生态技术工程师 /
🎁互动福利🎁
评论区分享你对“年久失修的系统如何做迁移?”的看法
随机抽取5位同学送出30Q币
近期好文:
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...