一半以上的新項目，都始于交接。交接期有長有短，交接形式多種多樣。不管怎樣，從客戶關系、團隊工作方式等各方面，交接期都奠定了項目進入穩定交付或維護期的基調。

2020年10月，Thoughtworks的C團隊從客戶團隊交接了一個有近20年歷史的支付網關系統。這個支付網關主要向英語系地區的企業提供信用卡支付，儲蓄卡支付等支付相關的功能，每個月的交易額過億。

2021年1月起，C團隊正式接手該項目的日常運維工作。不僅需要保證系統穩定運行，提供7×24小時On Call支持，還要響應日常業務的需求，同時保證整個支付網關符合支付卡行業數據安全標準(Payment Card Industry Data Security Standard，縮寫為 PCI-DSS)。

在交接的過程中，團隊面臨很多的挑戰，嘗試了很多辦法，同時沉淀了一些經驗。我們將通過這篇文章將經驗和實踐分享出來，希望幫助到更多人。

挑戰

作為一個歷史悠久的“大齡”支付網關，在交接過程中我們遇到了一系列的挑戰，大致可以分為下面兩類：

1. 業務復雜度高

業務上，這個支付網關光是在卡支付的場景下就同時支持8種技術，還有信用卡相關的安全功能，數不清的報表和各種增值服務。

技術上，總共有100多個服務和300多個代碼庫，部署在超過200個EC2上;服務之間耦合嚴重;許多服務沒有部署流水線、沒有測試環境甚至沒有源代碼;經常需要手工操作生產環境數據庫來解決問題;操作系統和軟件包版本非常陳舊等。

項目管理上，沒有總結和沉淀出完整而清晰的業務和技術文檔。

2. 交接內容多、時間短、范圍不明確

交接開始前，團隊接受到的信息只有100多個服務的名字，內容非常有限;交接的時間周期比較緊張(初步計劃只有30個工作日)，沒有足夠的時間去了解到系統的所有功能。

實踐

1. 分階段制定目標、建立重點

我們一般如何衡量一個遺留項目維護的質量呢?

• 短期：至少做到跟前團隊一樣。也就是說，在客戶團隊成員離開時，團隊能具備足夠的知識和技能來處理線上事故和日常業務工作。
• 長期：體現Thoughtworks不一樣的地方。對項目的業務、技術和發展歷史有足夠了解，足以給出一個改進計劃，在未來一個比較長的時間里落地、給客戶帶來更大價值。

鑒于項目的復雜度，在有限的交接期內達到這個目標基本是不可能的。但是如果將時間軸拉長，分階段來實施，就比較容易做出一個切實可行的計劃;同時，也能最大化交接期的價值，讓團隊從第一天起就朝著一個方向努力。

基于此，團隊從實際情況出發，將項目分為三階段：

通過對項目不同階段目標的一致認識，減少了一些團隊在交接期的焦慮與慌亂，從而想出更多創造性的點子，并勇敢的嘗試、反饋、迭代，達到各個階段的目標。

2. 利用C4模型梳理系統架構

通常處理的問題都是業務問題，如果不能把一個個服務放在業務流程中去理解就沒有意義。因此，我們在交接完一個獨立服務或者若干個有關聯的服務后，都會試圖用C4模型畫出他們的C1(System Context Diagram)和 C2(Container Diagram)兩個高級別的圖，以可視化的方式展示出系統輸入、輸出和各服務的依賴關系。

實踐證明，畫圖的過程可以幫助大家更好地吸收碎片化知識，有利于整個團隊將知識匯總和沉淀。同時，相比于反復的解釋說明，圖是一種更有效的語言。

有些比較獨立的模塊相對比較容易畫，但是涉及到不同版本API的支付流程，就需要不斷地獲取更多的信息來完善，反復跟客戶確認。有些環節甚至在交接結束后依舊沒能打通或者沒時間梳理，只能在交接后，作為深入理解期的目標繼續完善。

支付系統C1簡化圖(簡化版)

3. 通過結對在團隊內部分享上下文

在第一階段交接的過程中，我們和客戶團隊是“1+1”的模式進行知識交接，業務知識是像孤島一樣分散在各個成員那里。另外，我們團隊又因為每個人加入項目的時間和技能背景的不同，對一些背景信息、業務上下文、技術實現的掌握有一些差距。

因此，在進入項目交接的第二階段開始，對于大部分的工作內容，我們都通過結對的方式來進行。根據不同的業務和優先級，我們劃分了幾個重要的主題，比如：日常需求相關的任務，PCI 相關的任務和生產環境的變更等。我們會通過專長和對服務的熟悉程度分工結對，讓這兩個人可以成為團隊內相應領域的專家。

這樣的好處有主要有：保證對應的知識能在團隊中傳播開來，消除知識孤島;避免某個成員因為請假導致重要的任務不能進行;重要的線上操作可以多一個人幫忙檢查。

在安排 Primary On Call 和 Secondary On Call 的時候，采取“Dev + DevOps”的組合，保證有足夠的技能應對線上事故。在線上事故發生的時候，兩個人一起結對配合處理。

雖然結對在前期會影響效率，但能確保團隊中至少兩個人熟悉特定的業務，最終可以讓整個團隊擁有響應事故的能力。從現在的結果來看，正是這種結對的形式，保證了整個團隊的“高可用”。

4. 通過線上事故演練提升團隊On Call的信心

7 × 24 小時 On Call 對團隊來說，無疑會是一個非常大的挑戰。在正式接手系統之前，團隊感受到了比較大的壓力。這些壓力一方面是因為大部分項目成員缺少 On Call 的實戰經驗，另外一方面因為在交接的第一階段里，我們缺少對業務實現細節和系統的深入了解。

On Call工程師不僅要參照標準處理流程，還需要在短時間內評估線上問題造成的影響并精準地解決，那么用以前發生過的事故來演練就成了我們在深入理解期的最好的學習方式。

在正式承擔On Call的職責前，我們每個迭代都會有一個模擬線上事故處理的活動，主要流程為：

• 組織者會去從過去的線上故障里挑選一個有代表性的事故來模擬，比如是某一個與其他網關集成服務的事故;
• 團隊約定2個小時來模擬線上事故，組織者還原當時場景，其他成員在不知情的情況下按照自己的理解進行適當的追問;
• 分成兩個小組，根據現有的情況定位問題，并給出解決方案;
• 組織者進行復盤，梳理相關知識點。

通過以上方式，我們得以快速適應On Call的節奏。到現在為止，我們團隊的每個成員都有作為Primary On Call的經驗了。

結語

在交接的三個月里，我們持續地改進交接方式，最終將項目成功地從客戶團隊手中接過。無論是交付主管，還是和我們合作的客戶團隊都對我們的工作提出了稱贊。在摸索交接的過程中，我們嘗試了不同的方式讓我們的交接平滑順利，并將對交接有幫助的實踐分享出來，希望對大家有所幫助。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文