話題背景

在企業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庫等，然后再通過遷移工具進行在線遷移升級